1132 replies to this topic

[littlesat]

Dit lijkt mij ook een logische oplossing -> 

Ergens helemaal geen logische oplossing... Waarom zou je het pakketje belasten met extra data...? Bij de veel paketjes hebben we voorgecompileerde en de sources hebben er -src bij staan in een apart pakketje... Eigenlijk zou dit hier mogen gebeuren.. 

[Loui (PD1LOI)]

Dit lijkt mij ook een logische oplossing -> 

Ergens helemaal geen logische oplossing... Waarom zou je het pakketje belasten met extra data...? Bij de veel paketjes hebben we voorgecompileerde en de sources hebben er -src bij staan in een apart pakketje... Eigenlijk zou dit hier mogen gebeuren.. 

Wil jij dan eens kijken waar het fout gaat? En melden wat wij moeten doen! en eventueel aanpassen waar dat mogelijk is zodat het eindelijk een keer goed gaat? Ik had met de oude versie van HetWeer nooit geen probleem, als ik hier iets veranderde werd dat s'nachts bij de bouw proces gewoon uitgevoerd.

Edited by Loui (PD1LOI), 27 September 2016 - 09:07.

[Pedro_Newbie]

Ik heb een pull request gedaan met een kleine aanpassing in het postrm gedeelte. https://github.com/E...91ee3fd70d597de
Dit is overgenomen van diverse voorbeelden in github zoals b.v. deze (random gekozen) https://github.com/o...ackspirit.hd.bb

Misschien werkt dit, zo niet dan houdt het voor mij ook even op.

[Rob van der Does]

Dit lijkt mij ook een logische oplossing -> 

Ergens helemaal geen logische oplossing... Waarom zou je het pakketje belasten met extra data...? Bij de veel paketjes hebben we voorgecompileerde en de sources hebben er -src bij staan in een apart pakketje... Eigenlijk zou dit hier mogen gebeuren.. 

Daar gaan we weer: niemand bij PLi weet hoe het moet, maar voorstellen van anderen worden bij voorbaat afgewezen. Terwijl die bewezen goed werken en voor iedereen duidelijk zijn.

Ik wordt er wel een beetje moedeloos van; kijk eens hoeveel tijd en energie er nu is gaan zitten uitsluitend en alleen om binnen de structuur van de Open plugins het zaakje voor elkaar te krijgen, en met vrijwel geen resultaat.

Ik begin er steeds meer voor te voelen gewoonweg weer met een IPK te gaan slepen. Dat werkt altijd en iedereen begrijpt precies wat er moet gebeuren.

[littlesat]

Dank je Pedro...

 

Ik kan het alleen niet mergen...

Edited by littlesat, 27 September 2016 - 11:17.

[WanWizard]

Die kan moeilijk gemerged worden, daar zit de hele commit history vanaf 2013 nog een keer in.

[Pedro_Newbie]

Dank je Pedro...
 
Ik kan het alleen niet mergen...

Omdat het niet goed is of heb je er geen toegang toe of ben je nu niet in de gelegenheid?

 

Ik zie nu net Wanwizard zijn post.

Ik had de boel geforked en toen wat aanpassingen gedaan. Maar als één van jullie die kleine toevoeging met de hand kan doen....

Edited by Pedro_Newbie, 27 September 2016 - 13:51.

[Pedro_Newbie]

Je ziet, ik ben er duidelijk niet in thuis in dit pull gebeuren. Hoe had ik het het beste kunnen doen?

[Erik Slagter]

Ik zou ook liever iets generieks zien, maar het probleem is dat je aan een file nooit kunt zien of deze het resultaat is van het installeren en gebruiken (zoals de pyo files), of dat deze er door de gebruiker is neergezet en dus moet blijven staan.

 

Dit kun je m.i. alleen maar in CONTROL oplossen, want dat is de enige plek waar je precies weet wat er wel en niet tot de package behoord.

Het package systeem zou van elke .py file die hij opruimt, moeten kijken of er een bijbehorende .pyo file is. Die zou veilig verwijderd kunnen worden. Maar geen goede oplossing omdat het specifiek is voor python en omdat het aannames doet.

 

Ik weet een betere oplossing, maar ik weet niet of python daarin meewerkt. Je zou een schadow-filesysteem-boom ergens onder /var (o.i.d.) moeten hebben, waar de gegenereerde .pyo's terecht zouden moeten komen. Je zou die boom dan klakkeloos moeten kunnen verwijderen, omdat er alleen gegenereerde .pyo's zouden staan, geen .pyo's uit packages zonder source (naughty...). En enigma zou dan niet naar deze schaduw-boom moeten kijken om vast te stellen of een plugin is geinstalleerd.

 

Sowieso files aanmaken in directories die door een package manager worden beheerd is niet echt "schoonheidsprijs".

Edited by Erik Slagter, 27 September 2016 - 13:58.

[WanWizard]

Daar gaan we weer: niemand bij PLi weet hoe het moet, maar voorstellen van anderen worden bij voorbaat afgewezen. Terwijl die bewezen goed werken en voor iedereen duidelijk zijn.
Ik wordt er wel een beetje moedeloos van; kijk eens hoeveel tijd en energie er nu is gaan zitten uitsluitend en alleen om binnen de structuur van de Open plugins het zaakje voor elkaar te krijgen, en met vrijwel geen resultaat.
Ik begin er steeds meer voor te voelen gewoonweg weer met een IPK te gaan slepen. Dat werkt altijd en iedereen begrijpt precies wat er moet gebeuren.

 

Rustig aan allemaal.

 

Littlesat zegt alleen maar dat OpenPLi er in het verleden voor gekozen heeft om sources en binaries in twee separate packages aan te bieden.

 

Deze opmerking is hoe dan ook hier echter helemaal niet relevant, ik heb een redelijk aantal ipk's in de feed bekeken, en die bevatten allemaal zowel de py als de pyo file. Dus ik vraag me af welk probleem hier nu opgelost moet worden, dat verklaard in ieder geval wel waarom die plugins wel allemaal keurig opgeruimd worden.

 

Het is overigens wel zo dat de ipk van "hetweer" GEEN pyo's bevat, en dat is dan wel weer raar. Anderen (pak bijvoorbeeld de MeteoViewer) hebben ook geen pyo's in de repo, maar die zitten wel in de ipk.

 

Dus ik denk dat we het "verkeerde probleem" aan het oplossen zijn (even los van de generieke opmerking van Erik, maar dat lossen we zo maar niet op vrees ik).

[cobus]

Maar laatst werd er gezegd dat de py eruit moeten of ik snap het niet meer.

[catastrofus]

Klopt, de pyo's bedoel je waarschijnlijk want die zouden toch automagisch opnieuw gemaakt worden als de py's geraakt werden.

[WanWizard]

Nee, cobus was correct.

 

Voor onze core packages (uit de enigma2 repo) is het zo dat we twee packages hebben: een gewone met de pyo's en alle andere relevante files, en eentje met de suffix "-src", waarin de py's zitten. Met het idee dat niemand normaal de source nodig heeft, en het ruimte spaart (het is helemaal in het begin, met boxen als de 800 en 7025 en hun beperkte flash, zo geimplementeerd).

 

Op zich een prima idee, maar voor zover ik zien kan is dat voor geen enkele andere repo zo geimplementeerd. Als we dat willen, prima, maar dat moet dat centraal en in een keer gebeuren, en daar moet een plugin bouwer geen last van hebben (even los van bepaalde eisen t.a.v. de structuur van de plugin).

[Pedro_Newbie]

Ja als de pyo's gewoon in de github staan en overgenomen worden dan hadden we de helft van de bijna 600 postings weg kunnen laten. Dan installeert en de-installeert de package zonder problemen.
Alleen Openpli wil geen "vreemde" pyo's (en .po's) in de package. Dat was ook het probleem met de backupsuite waar overduidelijk deze bestanden worden geweerd door het bitbake recipe, zoals hier (zie de laatste regels): https://github.com/O...-backupsuite.bb
 

DESCRIPTION = "Backup Suite"

LICENSE = "GPLv2"

LIC_FILES_CHKSUM = "file://usr/lib/enigma2/python/Plugins/Extensions/BackupSuite/GNU_LICENSE.txt;md5=8aab2037d6ccded90e5a3a3849bc60dc"

SRC_URI = "git://github.com/Pedro-Newbie/BackupSuite.git"

SRCREV = "${AUTOREV}"

inherit gitpkgv

S = "${WORKDIR}/git"
SRC = "${S}/usr/lib/enigma2/python/Plugins/Extensions/BackupSuite"
DEST = "${D}/usr/lib/enigma2/python/Plugins/Extensions/BackupSuite"

PV = "20+git${SRCPV}"
PKGV = "20+git${GITPKGV}"
PR = "r0"

RDEPENDS_${PN} = "mtd-utils mtd-utils-ubifs ofgwrite"

FILES_${PN} = "/usr/lib/enigma2/python/Plugins/Extensions/BackupSuite"

do_install_append() {
    install -d ${DEST}
    cp -rp ${SRC}/* ${DEST}
    # remove the files we do not want in our package
    find ${DEST} -name '*.pyo' -exec rm {} \;
    find ${DEST} -name '*.po' -exec rm {} \;
}

[Erik Slagter]

 

Zou je dit recept eens willen proberen en na het installeren kijken of de postrm werkt?

MMODULE = "HetWeer"
DESCRIPTION = "HetWeer plugin"

require openplugins-replace-pli.inc

require openplugins-distutils.inc

require assume-gplv2.inc

PLUGINPATH = "/usr/lib/enigma2/python/Plugins/Extensions/${MODULE}"
do_install() {
        install -d ${D}${PLUGINPATH}/Images
        cp -r ${S}/plugin/* ${D}${PLUGINPATH}
        chmod a+rX ${D}${PLUGINPATH}
}

pkg_postrm() {
    rm -rf /usr/lib/enigma2/python/Plugins/Extensions/HetWeer
}

FILES_${PN} = "${PLUGINPATH}"

Is er iemand van Openpli die iets over het bovenstaande kan zeggen of het werkt of kan werken?

Dit moet je dus niet doen, zoals ik eerder zei. Weggooien van files moet je aan de packet manager overlaten.

[Erik Slagter]

Het zou heel "simpel" zijn om in de plugins alleen .pyo's aan te bieden. Dan worden er geen files gegenereerd en hoeven ze ook niet bij het verwijderen van de package weer expliciet opgeruimd te worden.

 

Maar dat willen we niet omdat we om twee redenen alleen sources willen zien:

 

- Je weet wat je draait, geen verrassingen, achterdeurtjes, etc.

- Iets wat gecompileerd is in een omgeving hoeft nooit 100% goed te draaien op een andere omgeving. Met python speelt dat iets minder dan met echte executables, maar ik kan me voorstellen dat tussen 2.7 en 3.0 dat niet zomaar uitwisselbaar is.

 

Vandaar dus.

[Pedro_Newbie]

Is het niet zo met de pyo's en de py's dat als beide aanwezig zijn en de py wijkt af van de pyo er een gewoon een nieuwe pyo gegenereerd wordt? Dat is toch altijd zo als je iets aanpast in de py dat bij een herstart de verschillen worden gezien en er een nieuwe pyo gemaakt wordt?
Dus het leveren van de py en pyo moet dan toch geen probleem zijn.
Ik zie anders niet zo snel een elegante oplossing omdat de package manager die de boel moet opruimen niet weet wat er opgeruimd moet worden.
 

Dit moet je dus niet doen, zoals ik eerder zei. Weggooien van files moet je aan de packet manager overlaten.

Dat lijkt mij nog altijd beter dan een plugin verwijderen en de pyo's achterlaten. Het lijkt dan net of de plugin nog geïnstalleerd is en zal dan in veel gevallen een enigma crash veroorzaken bij het opstarten.

Het LIJKT mij op dit moment de beste oplossing om:
- de structuur van E2Openplugins te laten voor wat het is;
- de plugin HetWeer weer gewoon onder een normale github repo te plaatsen met de volledige boomstructuur en de bestanden op zijn plek zoals in een normale ipk inclusief de pyo's;
- een GNU_LICENSE.txt file toevoegen, b.v. die uit de BackupSuite (i.v.m. de hash)
- een bitbake recipe aanmaken: openpli-oe-core/meta-openpli/recipes-openpli/enigma2-plugins/enigma2-plugin-extensions-hetweer.bb;
- in het bitbake recipe opnemen:

DESCRIPTION = "Het Weer"
LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://usr/lib/enigma2/python/Plugins/Extensions/HetWeer/GNU_LICENSE.txt;md5=8aab2037d6ccded90e5a3a3849bc60dc"

SRC_URI = "git://github.com/<HIER DE JUISTE NAAM>/HetWeer.git"

SRCREV = "${AUTOREV}"

inherit gitpkgv

S = "${WORKDIR}/git"
SRC = "${S}/usr/lib/enigma2/python/Plugins/Extensions/HetWeer"
DEST = "${D}/usr/lib/enigma2/python/Plugins/Extensions/HetWeer"

PV = "20+git${SRCPV}"
PKGV = "20+git${GITPKGV}"
PR = "r0"

FILES_${PN} = "/usr/lib/enigma2/python/Plugins/Extensions/HetWeer"

do_install_append() {
	install -d ${DEST}
	cp -rp ${SRC}/* ${DEST}
}

Dan lijkt het mij dat het hele probleem voor eens en altijd getackeld is.
Voorbeeld en GNU_LICENSE.txt is hier te vinden: https://github.com/P...ons/BackupSuite
Bitbake recipes: https://github.com/O...enigma2-plugins
en het recipe voor de BackupSuite: https://github.com/O...-backupsuite.bb (laatste 3 regels voor de } verwijderen)

Edited by Pedro_Newbie, 27 September 2016 - 16:24.

[Rob van der Does]

Op zich een prima idee, maar voor zover ik zien kan is dat voor geen enkele andere repo zo geimplementeerd. Als we dat willen, prima, maar dat moet dat centraal en in een keer gebeuren, en daar moet een plugin bouwer geen last van hebben (even los van bepaalde eisen t.a.v. de structuur van de plugin).

Dat is precies zoals bij ViX alle plugins op de feeds aangeboden worden (uiteraard met uitzondering van de IPK's die als pakket in de 3rd-party feeds staan). In het context-menu van de plugin browser kies je of je (ook) de src's als downloadables wilt zien. Zo niet zie en krijg je alleen de plugins met daarin de (door het bouwproces gecompileerde) pyo's (en uiteraard de eventuele andere bestanden en mappen). Zo ja, dan zie je alle plugins 'dubbel': eenmaal als plugin en eenmaal als SRC-pakket.

Volgens mij een prima systeem. Maar toen ik eerder aangaf dat het plugin-bouwproces de python-bestanden zou moeten kunnen compileren kreeg Littlesat zowat een rolberoerte. En hetzelfde gold voor Erik toen het ging om het plaatsen van de pyo's in de repro.

Kortom: ik weet nu ook niet meer (of eigenlijk: nog steeds niet) wat nu de (door PLi) gewenste situatie is.

Wat me wel verbaast is dat dit allemaal onbekend terrein lijkt te zijn, terwijl de open plugins toch al enige tijd bestaan en gebruikt worden.

[WanWizard]

Dan heeft 'ie je vast verkeerd begrepen, want zover ik zien kan staat er in geen van de "E2Open" repo's pyo files, en toch zitten die files wel in de ipk's. Het is dus niet waar dat die pas bij aanroepen vanuit source worden gecompileerd.

 

Ik denk dat er nu twee discussies door elkaar lopen: hoe het nu is, vs hoe het in een perfecte wereld zou moeten zijn. Waarbij het dan volgens mij ook nog zo is dat de opmerking van Erik (wij willen dat alles in source wordt aangeleverd) volledig los staat van wat er in de ipk terecht komt (waarvan littlesat zegt dat er alleen pyo's in horen te zitten, en de source in een apart pakket).

 

Allemaal mooi die theorie, maar tot op heden werkt het dus niet zo, dus moeten er m.i. twee dingen gebeuren:

- er moet door OpenPLi een ei gelegd worden over de manier waarop plugin ipk's gebouwd moeten worden.

- het bouwproces moet worden aangepast zodat ALLE ipk's op die manier worden gebouwd.

[WanWizard]

Wat me wel verbaast is dat dit allemaal onbekend terrein lijkt te zijn, terwijl de open plugins toch al enige tijd bestaan en gebruikt worden.

 

Mij niet, zoals ik al eerder postte, dit is gewoon in de afgelopen 10 jaar organisch gegroeid, waarbij jantje methode A gebruikt, en pietje methode B.

 

Dat los je op met een meer professionele/zakelijke manier van ontwikkelen, maar zou zit dit hobby team nu niet in elkaar. Helaas (imho).