debian "fork" ?

[devZer0]

debian "fork" ?

[r00t-]

it's winter holiday season,when hackers get time to do hacker stuff? ;)
i dislike switching this conversatiom to german, unless maybe everybody agrees it's helpful to get this resolved quicker...

@devZer0:
it's not exactly obvious what needs to happen here,
also you are mixing two separate issues:

• the obsolete dailab respository getting too much exposure
• the desynced debian packaging
• (and maybe the existence of the "fork", which was the original subject of this issue)

== as for dailab:
i think the obviously best thing to do here is to contact dailab and ask them to do something about this.
(did we have a contact there? @juriglx ? )

• set their repository archived/readonly to make it ovious it's stale: https://github.blog/2017-11-08-archiving-repositories/
• add a pointer to volkszaehler's fork as the recommended one

also:

• we might want to remove the fork relationship to dailab/libsml, if we want to avoid us pointing to it: https://docs.github.com/en/free-pro-team@latest/github/setting-up-and-managing-your-github-profile/why-are-my-contributions-not-showing-up-on-my-profile#commit-was-made-in-a-fork
• a bug against the debian package was actually filed, but got zero responses from the maintainer :( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946525

== as for the packaging (and the "fork"):
the obvious required step is to merge the packaging changes from the "fork" back into ours, so that it could be used directly.
nothing stops us from doing that ourselves.
i already documented half of the required steps above: https://gist.github.com/r00t-/94d4f964beb032e2ac6806d0f292ffc6

also, checking the libsml bug-reports at debian, i saw this:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=957478
(created #90 to avoid further chaos in this thread)
that also got zero response in the 5-6 months it's been marked "crtical",
and if that is not fixed, libsml will be out of debian with the next release anyway.
(i suggest we help with that, will try to at #90 )

@Ampelbein: are you alive? 😱

[andig]

Ping @Ampelbein

[Ampelbein]

That is the packaging repository for the Debian package. The packaging for most packages is maintained on Salsa to make use of the integrated CI infrastructure related to Debian packages (autopkgtests, reproducible builds, ...). I have updated the Information to mention the Volkszähler Repository as the source.

Since the libsml copyright mentioned the "DAI-Labor" it seemed to me that github/dailab is the canonical source.

Also the copyright file in the volkszähler repo, https://github.com/volkszaehler/libsml/blob/master/debian/copyright, says:

"It was downloaded from:

https://github.com/dailab/libsml"

which adds to my confusion.

[andig]

@Ampelbein we already have bits and pieces of debian packaging in this repo but they are unmaintained. Is it necessary to create a downstream fork for this purpose? If yes I‘d propose to remove the packaging part here to avoid confusion and make our readme even clearer.

Will wait for answer and pepare pr.

[andig]

I think we can do either or. If you need the fork fine, but then we should cleanup the debian packaging stuff here as its obsolete. Otherwise happy to accept PRs here- your PRs would probably get pushed right through as we do not have active debian maintainers on the team.

Anyway I still have cleaning the readme on my list.

[andig]

well, it's not strictly necessary to have a full fork, it just makes things easier. I will have a look and create some pull requests to bring the packaging parts in this repo to a more usable (for Debian and it's derivatives) state.

ping @Ampelbein any news on this? I would appreciate if we could have a clear status regarding debian packaging being part of this repo or not.

[andig]

Tbo, there‘s absolutely no reason for that fork at all. We‘re typically pretty quick to react to PRs and the debian code is unmaintained anyway. So why not just maintain it here instead of a less-maintained downstream repo?

[devZer0]

für das nächste debian ist unter "Externe Ressourcen:" scheinbar immer noch auf das dailab repo verlinkt, und das beschert dem dailab repo unter google weiter treffer-quote. erscheint bei "libsml" suche auf google immer noch als top-treffer. was doof ist, da es nicht als obsolet zu markieren ist.

kannst du das bitte mal ändern für unstable und testing @Ampelbein ?

https://packages.debian.org/source/sid/libsml
https://packages.debian.org/sid/libsml-dev
https://packages.debian.org/sid/libsml1
https://packages.debian.org/source/bullseye/libsml
https://packages.debian.org/bullseye/libsml-dev
https://packages.debian.org/bullseye/libsml1

ich werde sonst ein debian bugticket submitten müssen.

dieser fork ist jetzt 5 jahre am start und immer noch verweisen debian paketseiten auf das alte dailab repo, was sicher dazu beiträgt, das man bei google-suche nach "libsml" immer noch zuallererst beim dailab repo rauskommt und das volkszähler libsml repo garnicht erst erwähnung findet... ich finde das sehr unerfreulich.

[devZer0]

i wrote an email to nadim el-sayed from dailab, he seems to be last person at dailab who was involved in libsml project. hope he can help archiving the repo.

[narc-Ontakac2]

@devZer0 A reason to prefer deb over rpm is raspbian. If it is packaged for Debian it is - as far as I understand it - automatically in raspbian.

[andig]

Sieht so aus. Und VZ wird nirgendwo erwähnt. Schade :/

…

Am 14.04.2019 um 02:54 schrieb devZer0 ***@***.***>: do i see this right and this is a "real" fork of libsml ? https://salsa.debian.org/amoog-guest/libsml/commits/master https://packages.debian.org/source/sid/libsml — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[andig]

Hier gings los: volkszaehler/vzlogger#331 Ich muss zugeben dass ich unter „packaging“ etwas anderes verstanden hatte. Viele Grüße, Andreas

…

Am 14.04.2019 um 02:54 schrieb devZer0 ***@***.***>: do i see this right and this is a "real" fork of libsml ? https://salsa.debian.org/amoog-guest/libsml/commits/master https://packages.debian.org/source/sid/libsml — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[devZer0]

da das debian projekt weiter (via https://packages.debian.org/source/sid/libsml ) das dailabl libsml referenziert ist es kein wunder daß man bei eingabe libsml auf google weiterhin zuallererst auf der dailab seite landet. vor allem wenn man bedenkt wie viele distros sich alle aus debian ableiten. das sind schon ein paar...

ich hatte diesen andreas vor einer ganzen weile angemailt um ihn über den offiziellen fork zu informieren und er hatte leider nicht auf die mail reagiert.

könntest du oder jemand anderes aus dem vz projekt ihn bitte auch nochmal anmailen ?

wenn er nicht reagiert wäre mein vorschlag ein debian bugticket dafür aufzumachen und "öffentlich" um stellungnahme bitten um diesen fork zu begründen.

ich finde eine package maintainership zwar super und sehr lobenswert, meine aber auch oft wahrgenommen zu haben , daß in debian ganz gerne eigene versionen/patches gepflegt werden anstatt sich nur rein um das packaging zu kümmern (und patche allenfalls in form von kompatibilitätskleber einfliessen zu lassen) und anstatt alle patche bei denen es sinn macht upstream zu schicken damit auch andere davon profitieren.

das finde ich umso absurder, wo doch libsml bereits dabian packaging instructions enthält.

kurzum:
wenn man in debian unbedingt einen "fork" pflegen will sollte das m.E. im libsml readme stehen daß es wenigstens für die, die beim "richtigen" libsml gelandet sind transparent ist.

vielleicht gibt es argumente für diesen fork - und wenn - dann gehört das öffentlich gemacht. und wenn es die nicht gibt, ist es eigenbrödlerei

[devZer0]

selbst unstable bezieht scheinbar noch den code aus dem dailab repo. mindestens dort sollte man doch eigentlich die vz version erwarten können

https://packages.debian.org/unstable/libsml-dev

[r00t-]

the debian way would be to file a bug (there isn't one currently).
https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;src=libsml
point out that dailab is not maintaining libsml any longer, and suggest to use our fork as upstream.

actually i see some references to vokszaehler in his "fork":
https://salsa.debian.org/amoog-guest/libsml/commit/e1c5786fac455f0de0a6ad75035627c1603fb0e7

has anybody compared his tree to ours and can tell what the actual differences are?
(i might try to do that otherwise)

[r00t-]

the differences are really only related to packaging:
https://gist.github.com/r00t-/94d4f964beb032e2ac6806d0f292ffc6

[andig]

@r00t- would be great if you could open the ticket

/cc @Ampelbein would be great if you could explain whats going on here. Would appreciate credits for volkszaehler!

[r00t-]

@Ampelbein:
i think the confusion arrises because while "DAI-Labor" funded the initial development, they are not maintaining it anymore. (note that last commit in their repo being from 2012.)
this should probably be made more obvious.
there should be some emails documenting that status, looking...

[r00t-]

somewhere around here:
https://marc.info/?l=volkszaehler-dev&m=142061668515625&w=2

[devZer0]

Also the copyright file in the volkszähler repo, https://github.com/volkszaehler/libsml/blob/master/debian/copyright, says:

"It was downloaded from:
https://github.com/dailab/libsml"

which adds to my confusion.

ouch. that explains a lot. :(

thanks for feedback andreas.

so, i think it's not yet as transparent as it should be that libsml is not maintained in dailab repo anymore but in volkszaehler repo

[Ampelbein]

Hi,

well, it's not strictly necessary to have a full fork, it just makes things easier. I will have a look and create some pull requests to bring the packaging parts in this repo to a more usable (for Debian and it's derivatives) state.

[devZer0]

ping @Ampelbein from me, too

[devZer0]

on https://packages.debian.org/de/buster/libs/libsml1 i can see via http://deb.debian.org/debian/pool/main/libs/libsml/libsml_0.1.1+git20180125-1.debian.tar.xz , that there is no difference to this repo besides contents of the debian subfolder.

so - if debian packaging is maintained separately within the debian project, i don't see the point why this repo should contain outdated/orphaned debian packaging files

i vote for removal of that subdirectory in official libsml git, as packaging stuff is mostly distro-specific stuff/tasks, anyway (and why should we prefer debian?)

what do you think @andig @Ampelbein ?

[devZer0]

on that page: https://packages.debian.org/de/buster/libs/libsml1 i still see https://github.com/dailab/libsml being linked (below "Externe Ressourcen:") , which may explain why dailab repo still apears top when searching for libsml via google (i'm wondering about that for quite a while)

please can you change that to https://github.com/volkszaehler/libsml @Ampelbein ?

[devZer0]

please someone read https://lists.volkszaehler.org/pipermail/volkszaehler-users/2019-December/013808.html 🙈

[Ampelbein]

on that page: https://packages.debian.org/de/buster/libs/libsml1 i still see https://github.com/dailab/libsml being linked (below "Externe Ressourcen:") , which may explain why dailab repo still apears top when searching for libsml via google (i'm wondering about that for quite a while)

please can you change that to https://github.com/volkszaehler/libsml @Ampelbein ?

I can't change that in buster, since buster is already released. But I can change it in Unstable (and thus in the next release). Github also shows that this repo is a fork of the dailab repo, which I guess contributes to the wrong google results.

[devZer0]

ok, so we cannot do anything about that, but please at least, can you change it in https://packages.debian.org/source/bullseye/libsml and https://packages.debian.org/source/sid/libsml ?

thank you!

[devZer0]

if there is maintained debian packging inside main libsml repo in the future, i would like to see rpm based packaging for redhat/centos, too

typically, packing is something which often is being done at the distro level. that does not mean that i think it MUST be done there.

i have no problem if someone does personal fork of libsml to add packaging stuff for his favourite distro, but i have a problem with outdated stuff inside the main repo which is only fixed elsewhere - and i have a problem with distro info pages pointing to outdated source.

there is enough of such out there (all those "i fix it for myself and don't care for upstream..." or "i don't care where this is from, go search yourself...") on the net and i'm really really sick of that.

[devZer0]

leider immer noch nicht gelöst @Ampelbein @andig @r00t-

wer nach libsml sucht landet weiterhin NICHT beim volkszähler projekt.

[devZer0]

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946525

things start getting annoying. i really dislike if bugtickets rot for years and nobody cares.

@Ampelbein , are you a responsible debian maintainer working with opensource community ?

what should we do next @andig @r00t- ?

[andig]

Can we ask debian to remove unmaintained module? Seems we saw this one coming...

[r00t-]

i'd like to point back at my previous post:

== as for the packaging (and the "fork"):
the obvious required step is to merge the packaging changes from the "fork" back into ours, so that it could be used directly.
nothing stops us from doing that ourselves.
i already documented half of the required steps above: https://gist.github.com/r00t-/94d4f964beb032e2ac6806d0f292ffc6

so why not make an MR, instead of spending so much time discussing?

once we are there, we could ask @Ampelbein to simply switch to that (if we can also promise to include any required updates switftly.)
or maybe check if we or anybody of us could take over maintainership of the package at debian.
(i have no idea how debian handles those processes, somebody should investigate.)

i also still think that it's not so useful if we merily claim to be the official source for libsml,
specifically to make a decision for debian easy, it would be best if we could get some official endoresement from dailab,
ideally by them closing their repo and pointing to us as successor.
did anybody try to contact them? other than via @juriglx (who is probably not with them anymore, but might know who to talk to.)

[r00t-]

actually, if you look here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=957478
you can see that https://github.com/volkszaehler/libsml/pull/92/commits (my commit, even if trivial)
has made it into debian (via ubuntu: https://launchpad.net/ubuntu/+source/libsml ),
without involvement of the maintainer.
(as i had pointed out before, that was a critical bug that would have led to the package not being included in the next debian release.)

[devZer0]

nadim did archive the repo and wrote to me, that theres nothing he can do more for now. think that is an progress. hope it will be relevant regarding google ranking

[r00t-]

he did leave your issue as the only open one, which is something:
dailab#14

maybe you should have pointed him to github's web-based editor, that would have allowed to edit the repo contents/README.md without having to bother with git tools.
(or maybe we should have made an MR that updates the repo, long ago...)

[devZer0]

on that page: https://packages.debian.org/de/buster/libs/libsml1 i still see https://github.com/dailab/libsml being linked (below "Externe Ressourcen:") , which may explain why dailab repo still apears top when searching for libsml via google (i'm wondering about that for quite a while)
please can you change that to https://github.com/volkszaehler/libsml @Ampelbein ?

I can't change that in buster, since buster is already released. But I can change it in Unstable (and thus in the next release). Github also shows that this repo is a fork of the dailab repo, which I guess contributes to the wrong google results.

@Ampelbein , we now have 4.10.2021 and the package-info pages under https://packages.debian.org/source/bookworm/libsml and https://packages.debian.org/source/sid/libsml still point to the dailab repo. which is wrong.

[devZer0]

no response from adrian bunk, either.

giving up with this.

not worth to waste any more bit of energy getting this fixed.

Gesendet: Montag, 04. Oktober 2021 um 23:36 Uhr
Von: [email protected]
An: [email protected]
Betreff: please fix wrong reference to dailab/libsml ( libsml (0.1.1+git20180125-1.1) )

Hello,

regarding #72 , could you perhaps fix the wrong reference/linkage to the github repo at https://packages.debian.org/source/bookworm/libsml and https://packages.debian.org/source/sid/libsml ?

the homepage still points to the old and outdated dailab repo, whereas https://github.com/volkszaehler/libsml is the correct/official one.

waiting for more then 2 yrs now to have this fixed...

furthermore, having unmaintained debian packaging stuff upstream does not make sense for me, too (see #72 (comment) ).

wouldn't it be better to delete the debian packaging stuff upstream and maintain separately in the debian projecet - or maintain it upstream completely - instead maintaining it at two places ?

regards
roland