Synology-Forum.nl
Packages => 3rd party Packages => Topic gestart door: Briolet op 24 augustus 2018, 23:51:32
-
In juni van dit jaar is de teksteditor nano (https://www.nano-editor.org/news.php) naar versie 2.9.8 geupdate
Ik zag net dat ook het Syno package nu in deze versie beschikbaar is. Er zit echter een bug in dit package. Nu updaten van 2.9.5 naar 2.9.8, blijft het package aangeven dat het is "Stopgezet"
[attachimg=1]
Vervelend. Maar als ik inlog, blijkt nano toch aktief te zijn. Blijkbaar loopt alleen de interne test van het package niet dat kijkt of hij actief is. (Het start-stop-status script geeft alleen een 'exit 3' als resultaat bij een status check. Dus ongeacht de status hetzelfde resultaat.
Edit: Nog een bug. Ook het changelog (https://synocommunity.com/package/nano) dat je in package center ziet klopt niet. Dat is nog die van de vorige versie.
-
Ja, dat was naar aanleiding van mijn verzoek gisteren om ook docker64 architectuur te ondersteunen.
Ging wel erg snel ;)
-
In juni van dit jaar is de teksteditor nano (https://www.nano-editor.org/news.php) naar versie 2.9.8 geupdate
Ik zag net dat ook het Syno package nu in deze versie beschikbaar is. Er zit echter een bug in dit package. Nu updaten van 2.9.5 naar 2.9.8, blijft het package aangeven dat het is "Stopgezet"
(Link naar bijlage)
Vervelend. Maar als ik inlog, blijkt nano toch aktief te zijn. Blijkbaar loopt alleen de interne test van het package niet dat kijkt of hij actief is. (Het start-stop-status script geeft alleen een 'exit 3' als resultaat bij een status check. Dus ongeacht de status hetzelfde resultaat.
Edit: Nog een bug. Ook het changelog (https://synocommunity.com/package/nano) dat je in package center ziet klopt niet. Dat is nog die van de vorige versie.
Misschien beter een issue te melden bij de SynoCommunity in plaats van hier.
Daar moeten ze het package aanpassen om dat in orde te maken.
-
Al gedaan als comments bij de commit.
-
Misschien beter een issue te melden bij de SynoCommunity in plaats van hier.
Maar echt toegangkelijk is die community niet. Op hun website op SynoCommunity.com kom je nergens en op hun github locatie wordt je ook niet veel wijzer. Als je via het package op auteur zoekt, zie je dat de laatste commit van Dr-Bean, de maker van dit package, 10 februari 2017 was. Dat is volgens mij alleen voor de building software van packages en niet het nano pakket zelf.
-
Hier vind je de laatste info over het package.
Staat zoals je al aangaf een fout in de change log comment van de laaste build
https://synocommunity.com/package/nano
Hier kun je een Issue aanmaken voor de SynoCommunity.
https://github.com/SynoCommunity/spksrc/issues
-
Beide linken ken ik. De eerste staat in mijn eerste post, en
de tweede is alleen voor issues in de building software van packages. Niet voor de packages zelf.
Ik zie dat binnen dat GitHub project ook de pakketten zitten. Ik was misschien op het verkeerde been gezet doordat Dr-Bean al 18 maand geen contributie gedaan heeft. Daardoor nam ik aan dat Nano ergens anders gehuisvest was.
Ik zie dat nano hier (https://github.com/SynoCommunity/spksrc/tree/master/spk/nano) zit. Zal eens een git-clone doen.
$ git clone https://github.com/SynoCommunity/spksrc.git
Cloning into 'spksrc'...
remote: Counting objects: 28736, done.
remote: Total 28736 (delta 0), reused 0 (delta 0), pack-reused 28736
Receiving objects: 100% (28736/28736), 11.96 MiB | 5.68 MiB/s, done.
Resolving deltas: 100% (14960/14960), done.Dat is de code van alle packages in de community. Nog geen 30 kB :D
-
Dr-Bean heeft al heel lang niets meer van zich laten horen.
En die issues gaan natuurlijk alleen over de packages, maar in dit geval was het ook het package waar een probleem mee is en niet de applicatie.
Verder kun je ook een issue aanmaken als je denkt dat er een nieuwe versie van de applicatie is en dus het package ge-update moet worden met een nieuwe build.
Er is momenteel nog maar een persoon actief in de SynoCommunity en die kan niet alle packages in de gaten houden of er misschien nieuwe versies van applicaties zijn en er dus een nieuwe build van zo'n package nodig is.
Dus een issue aanmaken in zo'n geval helpt.
En nee dat is niet alle code, dat is enkel de spkrsc, ofwel de code om de packages te builden.
De source code wordt tijdens het builden van hun orginele bestemming opgehaald, daarmee worden de packages voor alle architecturen gebouwd en de .spk's worden op de Package Server neergezet en staan dus niet op github.
Enkel packages die van source runnen, zoals in Python geschreven applicaties kunnen zichzelf updaten en hebben geen nieuwe package nodig als er nieuwe releases van applicaties uitkomen
-
Ik zie het. Voor Nano (en andere packages) staat de code er zelf niet in. Alleen bepaalde overkoepelende data. Ik zie voor Nano alleen pre- en postinstal code staan. Daar zit geen fout in.
Alle andere script code die ik in het package op de nas aantref komt dan blijkbaar uit een meer algemene pool voor het aanmaken van packages. Maar dan zou zo'n fout ook andere pakketten kunnen raken.
-
Ik zal er straks eens naar kijken, maar als er een fout in zit dat zit het in het start-stop-status script.
Die is voor ieder package anders want dat is de interface richting de applicatie.
Daar zal wel een foutje inzitten dat de status niet goed wordt gecheckt waardoor het package center denkt dat het package gestopt is.
EDIT:
Heb er even naar gekeken en er zit helemaal geen start-stop-status script bij en dan bevat het package enkel de template en dat werkt niet.
Ik heb het issue al gemeld bij de SynoCommunity.
-
Alleen heeft dat SSS script er nooit in gezeten en met vorige pakketten werkte het wel. Die template zal dan wel vernieuwd zijn. Ik heb al lopen zoeken naar dat default SSS script, zodat ik er zelf een oudere versie in kan zetten.
Gevonden. Het default script is volgens mij "mk -> spksrc.service.non-startable". Als ik met git de geschiedenis bekijk heeft D-Bean daar ooit zelfs de naam Nano in gezet met exit code 0 bij een status opvraag. Anderen hebben daar soms hun eigen pakketnaam in gezet en 19 juli 2018 heeft Yves Martin die code in 3 veranderd. Misschien nodig voor een ander pakket. Als ik de exit code op 0 terug zet, kloppen de resultaten weer.
De oplossing is natuurlijk niet zitten te knoeien met het default script, maar het script in het pakket zetten, zoals veel andere pakketten doen. Want met dit default script gaan er nog meer pakketten mis bij nieuwe aanmaak.
-
In de spkrsc van nano moet een correct SSS script staan anders krijg je de template.
Als je de .spk download en uitpakt dan zie je onderstaand SSS script staan en dat is de template.
#!/bin/sh
case $1 in
start)
exit 0
;;
stop)
exit 0
;;
status)
exit 0
;;
log)
exit 1
;;
*)
exit 1
;;
esac
Meestal wordt er bij start in de SSS een pidfile gemaakt en bij het status deel wordt dan gekeken of die pid nog draait.
-
Met de aanpassing naar 0 ziet het pakker er weer goed uit:
[attachimg=1]
Alleen het aanpassen van de foute update info werkt niet. Die haalt hij blijkbaar altijd uit de externe bron
-
Als je de .spk download en uitpakt dan zie je onderstaand SSS script staan en dat is de template.
Vreemd als dat de template is. Want op de nast staat bij status toch echt een "exit 3". Tenzij ze het pakket intussen aangepast hebben, maar dat zou slordig zijn zonder aanpassing van het versienummer.
Edit: Ik het het pakket ook nog eens gedownload en zie toch iets anders:
#!/bin/sh
case $1 in
start)
exit 0
;;
stop)
exit 0
;;
status)
exit 3
;;
log)
exit 1
;;
*)
exit 1
;;
esac
-
Ik denk dat ze slordig geweest zijn want ik heb het package zojuist gedownload en gekeken en wat ik gepost het staat in dat SSS script.
En nee 0 is ook onjuist.
Als Nano dan bijvoorbeeld crashed dan blijft het package center denken dat hij gewoon draait want dat script retourneert altijd 0.
Zoals ik al zei moet het SSS script na het starten van Nano de pid opvragen en die in een pidfile (nano.pid) wegschrijven.
Bij het status commando moet dan die nano.pid gelezen worden en aan linux gevraagd worden of die pid nog actief is.
Uit de developers guide wat de return codes moeten weergeven.
0: package is running.
1: program of package is dead and /var/run pid file exists.
2: program of package is dead and /var/lock lock file exists
3: package is not running
4: package status is unknown
EDIT.
Blijkbaar heel slordig want ik heb het package voor een DS116 gedownload en daar zit in wat ik gepost had, dus die returned een 0.
-
Alleen kan nano eigenlijk niet crashen. Het voegt alleen een commando toe aan de shell. (net als python, git en nog een paar andere pakketten) Er draait geen process dat actief is. Ik moet toegeven dat een echte test beter is, maar voorheen stond hier een 0 en dat werkte altijd goed.
-
Ok dan zou 0 goed zijn.
Blijkbaar zijn niet alle packages rebuild.
-
Nog iets wat me opvalt. Als ik in package center op de nas kijk, staat de download telling voor dit pakket op nul. Terwijl ik weet dat er meerdere mensen dit pakket gedownload hebben. (Ik zowel via het package center als rechtstreeks). Dus er klopt nog iets niet.
-
Het wordt steeds vreemder.
Als ik de .spk download en installeer krijg is een package waar 0 in staat en als ik vanuit het package center installeer dan staat er een 3.
Misschien dat er een propagatie delay in de release zit of een foutje ergens.
Ik geeft het op, gebruik nano toch niet.
-
Ik denk dat nano ook meer interessant is voor mac gebruikers dan voor windos gebruikers. Op windows kun je via winscp relatief simpel bij files op de nas komen. Voor de mac bestaat er geen gratis versie van winscp. Je bent dan veroordeeld tot de ingebouwde tekst editor van DSM. en dat is vi.
vi is een ramp. zelfs als ik wil stoppen moet ik steeds de handleiding opzoeken. :P
Op de mac gebruik ik nano, dat daar standaard aanwezig is sinds OSX 10.4. De versie 2.0.6 van nano !! nano is een afsplitsing van pico. pico heeft vroeger ook op de mac gestaan, maar tegenwoordig start het pico commando gewoon de nano editor. Blijkbaar vonden de Apple ontwikkelaars nano ook handiger.
Terug naar de bugs in het package. Ze zijn alleen cosmetisch. Ik hoop wel dat ze dit oplossen voor een volgende release.
Nano zelf heeft de laatste 12 maand 10 updates gehad. Yves kan dus ook met updaten wachten totdat nano een update krijgt. Gezien de activiteit van de ontwikkelaars van nano gedurende het laatste jaar, zal die update er wel vlot komen. ;)
-
De bug is echt een fout in alle packages die geen deamon hebben draaien zoals Nano, ffmpeg, python enz.
Al die packages retourneren nu een 3 in plaats van een 0.
Maar packages die niet startable zijn (gespecificeerd in de INFO file) moeten als status een 0 retourneren ook al runnen ze niet echt.
In dat geval krijgen ze in het package center de status "Installed" en is de enige optie "Uninstall".
Is zoals je al zei cosmetisch, maar kan voor de minder tech savvy gebruikers behoorlijk verwarrend zijn.
-
Ik ben nog eens door die packages heengelopen. Het VIM pakket is er ook een die alleen een shell command toevoegt. Daar zit wel een eigen "start-stop-status" status script in de source. In de source heet de file "dsm-control-sh" en wordt blijkbaar bij het builden van het pakket naar het start-stop-status script gecopieerd. Vim geeft een 'status 1' terug. Die reageert net zo fout als nano.
Andere voorbeelden van packages zonder deamon zijn perl en PHP. Dit zijn meer standaard Synology pakketen en die retourneren ook een status 0. Dat is dus de norm.
-
Er is momenteel nog maar een persoon actief in de SynoCommunity en die kan niet alle packages in de gaten houden of er misschien nieuwe versies van applicaties zijn en er dus een nieuwe build van zo'n package nodig is.
Dus een issue aanmaken in zo'n geval helpt.
Tja... Als ik kijk naar de grote hoeveelheid openstaande PRs dan baart dit mij zorgen. SynoCommunity is een waardevolle bron van pakketten, maar verschillende pakketten bouw ik nu maar zelf omdat de repo ernstig achterblijft.
-
Je zou ook kunnen meewerken aan de synocommunity ?
-
Dat heb ik meermaals overwogen. Maar ik heb niet de capaciteit om dat helemaal zelf te gaan trekken, en deelbijdragen lijken, gezien de PR en issue backlog, weinig motiverend.
Dus, als je up-to-date packages wilt voor bv. less, nano en owncloud, laat maar weten. Als SynoCommunity interesse heeft, idem.
-
Goedkoop.
Je hebt nooit een poging gedaan iets bij te dragen.
-
Sorry Ben, dan heb je de PRs en issues niet goed doorgelezen.
Maar de bottom line is: ik bouw wat ik zelf nodig heb en ik ben volgaarne bereid dat te delen. Maar ik ga er niet mee leuren, daar heb ik geen tijd en energie voor.
-
We nemen een proef op de som. Ik heb een PR uitgezet met de fixes voor nano. Zien wat er gebeurt.
-
Er is afgelopen weekend al enige diskussie, in een geloten bug melding van Mesa57, geweest met de samenstelling van dit pakket. Het precieze probleem is bekend. Omdat het vooral cosmetisch is, weet ik niet of Yves zin heeft om direct weer een release te doen voor een dergelijk kleine bug.
Ik heb ook geen idee hoeveel werk het is om dit pakket voor alle architecturen te updaten. Het is wel belangrijk dat dit in de repro zelf gefixed wordt zodat het goed gaat bij een volgende release. Ook voor andere pakketten want deze bug is medio juli in de repro geslopen voor meerdere pakketten zonder startbare code. (Alle pakketten zonder eigen SSS script)
-
Ik had het al geregeld met de SynoCommunity en de spksrc wordt aangepast voor packages die geen "daemon" mode hebben (die dus niet continu draaien).
Gaat nog even duren want alle packages moeten nagelopen worden waar dat voor geld.
Deze PR is dus een beetje mosterd na de maaltijd plus dat dit natuurlijk voor al die packages geregeld moet worden en een PR voor alleen Nano is dus vrij zinloos.
-
Dit is ook verwarrend/vervelend/storend:
[attach=1]
-
Maar om die 5 in een 4 te veranderen kun je nano juist mooi gebruiken want local version staat in je local INFO file. ;)
Bij mij staat er wel een 4, dus is niet elk pakket hetzelfde. Op zich vreemd. Als je merkt dat je het nummer verkeerd ingevuld hebt, dan doe je alle oude toch ook over?
In elk geval lost zich dat vanzelf op als revision 5 uitkomt. :lol:
-
Dit is ook verwarrend/vervelend/storend:
(Link naar bijlage)
En waarom blijf je maar herhalen wat @Briolet al in z'n eerste post had geschreven?
-
Zucht.
Ik bouw een nano pakket en geef het versie 2.9.8-5. Dat is dus een hogere versie dan in de repo.
Ik installeer dit pakket.
En dan geeft Package Center vervolgens aan dat er een nieuwer pakket is, met versie 2.9.8-4.
Ik vind dat verwarrend.
Het gaat dus niet over de verkeerde release notes waar al uitgebreid over is geschreven.
-
Hij haalt die changelog tekst van de website van de SynoCommmunity en niet uit je package.
Dat krijg je als je handmatig een package installeert, terwijl hetzelfde package in een repro staat.
-
We dwalen een beetje af van het nano onderwerp...
Dat krijg je als je handmatig een package installeert, terwijl hetzelfde package in een repro staat.
Vreemd. Ik heb bv. een eigen build van ownCloud, 10.0.9-30. Deze rapporteert bij zowel installed als newest deze versie, terwijl de 'nieuwste' repo-versie voor zover ik kan nagaan 8.1.12-8 is.
-
Dan heb je de naam veranderd en ziet hij het niet als hetzelfde package.
Huidige versie haalt hij uit de INFO file van het package, maar changelog en anders versienummers komen van de repro.
-
Het was me idd opgevallen dat als je het changelog, lokaal verbetert, hij toch het foute log op de repro laat zien.
De melding "newest version" is geen vergelijk tussen de lokale versie en die op de repro, maar gewoon de versie op de repro. Dat is de laatst gepubliceerde versie. Hij doet, terecht, niets met de versienummers die je zelf aanmaakt. Dat zijn nml geen officiële releases.
-
Waar "verbeter" je dan lokaal de changelog?
De INFO file heeft helemaal geen changelog variable beschikbaar.
-
Bij mij stond hij wel degelijk in de INFO file:
changelog="Update to 2.9.8"
Maar die info wordt niet getoond. Wel die op de repro, wat op zich ook zinvoller is. Je wilt de changes zien van de laatste versie en niet van wat je al hebt.
-
"Changelog" is geen geldig veld voor de INFO file en wordt dus gewoon genegeerd.
Alle geldige INFO velden kun je vinden in paragraaf 3.2 van de "The 3rd Party Developer Guide" die je hier kunt vinden.
https://www.synology.com/en-global/support/developer#tool
-
In elk geval is er gisteren een versie 5 van dit package uitgebracht, waar deze bugs opgelost zijn. Yves heeft zich van de kritiek toch iets aangetrokken, omdat zijn eerste reactie was dat dit te klein was om een nieuwe release te rechtvaardigen.
-
Ik heb een PR aangeleverd waarin ook het SSS probleem (generiek) werd opgelost. Dat gaf de doorslag.
-
Ik snap dat je jezelf graag schouderklopjes geeft, maar dit had ik al na de eerste melding van @Briolet met de SynoCommunity geregeld.
En zoals ik toen al meldde zat er wat tijd in omdat het voor meer package gedaan moest worden en even uitgezocht voor welke packages.
-
Als elke poging om een constructieve bijdrage te leveren op deze wijze wordt bejegend, is het niet verrassend dat
Er is momenteel nog maar een persoon actief in de SynoCommunity
-
Ik zag dat nano niet meer tussen de packages bij de SynoCommunity staat. Hij is nog wel handmatig te downloaden via “https://synocommunity.com/package/nano”.
Ik kon de reden niet vinden, maar dit is waarschijnlijk omdat nano nu gebundeld is in hun package "SynoCli File Tools (https://synocommunity.com/package/synocli-file)". Een pakket dat op 2019-09-26 geïntroduceerd is. SynoCli File Tools provides a set of small command-line utilities: less, tree, ncdu, jdupes, rhash, mc (midnight commander), nano, file, detox, pcre2, rmlint, rnm.
Heeft iemand er al ervaring mee?
Version 1.2-4
1. Update Midnight Commander to 4.2.25
2. Update openssl to 1.1 (mc).
3. Add links to pcre2grep and pcre2test.4. Update jdupes to 1.19.0
5. Update less to v563.
6. Update nano to 4.9
7. Update ncdu to 1.15.1
8. Update RHash to 1.4.0
9. Update rnm to 4.0.9
Ik zie in de releasenotes van nano dat deze editor de laatste twee jaar een grote versiesprong gemaakt heeft. Ze zitten inmiddels bij 5.3 (releasenotes nano (https://www.nano-editor.org/news.php))
ps: Op de Mac met OS Catalina staat nog steeds versie 2.0.6. ;)
-
Ik heb nano er toch maar af gegooid en dit nieuwe pakket geïnstalleerd. nano 4.0 ziet er grafisch net zo uit als de oude 2.9.8. Dat zal dus snel wennen. ;)
-
Mooi, dan kan ik mijn eigen nano en less packages afdanken.
Indien relevant: EERST de less, nano en Diagnosis Tools packages verwijderen, dan pas SynoCli File Tools installeren. Er zitten nl. overlappende programma's in.
-
less had ik nog nooit gebruikt, maar het is inderdaad een mooi alternatief voor 'dir'. Vooral bij het bekijken van grote files of het monitoren van actieve logfiles.
Ik zie er meer commando's bij zitten die net iets handiger zijn dan de default commando's. Het zijn natuurlijk allemaal comando's die de actieve leden van de SynoCommunity missen binnen dsm. Hetzelfde geld voor de andere 3 vergelijkbare pakketten van hen.