Hello Jochen,
Apologies for the late reply. I am quite busy with travels this week and loads of other things, so please bare with :)
On 2 Jul 2022, at 07:57, Jochen Sprickerhof libloc@jochen.sprickerhof.de wrote:
[resent for the location mailing lits]
Hi Michael,
- Michael Tremer michael.tremer@ipfire.org [2022-07-01 14:19]:
Hello Jochen,
Thank you for your email.
The best place to get in touch with our team is our mailing list over here:
https://lists.ipfire.org/mailman/listinfo/location
However, I am not sure if you prefer to talk about this matter in private for the time being.
Fine with me, added to Cc.
On 1 Jul 2022, at 13:14, Jochen Sprickerhof jochen@sprickerhof.de wrote:
Hi Stefan,
I'm a Debian Developer and F-Droid team member. One part of the F-Droid tooling is called issuebot [1] a bot to automatically check new app submissions. We plan to integrate libloc into issuebot [2] and would like to upload it to Debian for that. I've found your packaging work and would use it as a basis if you agree and would have some questions:
That sounds great!
First of all, we would like to have more users to libloc. So far we have been trying to work together with some projects and that has been great cooperations, but our time is of course limited, so I am very happy to hear, that you found our little piece of software and went ahead and integrated it.
- What is the license of the database itself, i.e., what is hosted here?
The database itself is licensed under CC-BY-SA 4.0.
We selected this, because it is the same license that Maxmind used to use, and there has been a debate on the Debian-legal list which concluded in that being the best license that we can use for this.
That sounds great, could you add a licence file to it, maybe?
The license is part of the database file. That is however not very human-frieldy to read.
I added the file to the directory: https://location.ipfire.org/databases/COPYING
We host a plaintext dump where any changes can be seen easily over here which also includes the full license text: https://git.ipfire.org/?p=location/location-database.git;a=summary
- Would it make sense to package the database along with the library?
First of all, it would be great to have some help to get the library into Debian. That would help us a lot to integrate it into other software. We already have Tor using it, and there are patches for Suricata (the latter might not be packaged for Debian yet either).
Suricata seems to be there:
https://packages.debian.org/sid/suricata
I did a quick grep in the source but did not see references to libloc, do you know how it is integrated?
Not yet. Patches have been submitted but so far have not been reviewed.
In IPFire we do this: We ship a recent-ish version of the database that we update every time we update libloc. That way, users have at least a base to start from, but the updater will update that file very soon.
I believe that Debian is doing the same with clamav which has a meta package with a version of the database. I think following that would make sense from my point of view.
Sounds great, I see that the updated puts the file in
/var/lib/location/database.db
But I don't see where it is used. The libloc-database package would probably install to /usr/share/libloc-database/database.db. Would it be easier if libloc uses that path as a backup if the one in /var is not there or should the package add a symlink to be overwritten by the updater?
The updater would overwrite that symlink since it downloads the file to a temporary location, verifies it with the key, and then replaces the old file. So that would work.
We could also search in a backup location. That would not be a lot of extra work. I am just wondering whether that is very intuitive or whether that would lead to confusion?
Does the build system not support overwriting that file at all?
- According to the Debian Python policy the Python package needs to be renamed to python3-location. It would simplify the transition if you could do the same in your package repo and add a transition package [3].
Oh, I named it that way because that is how Python packages were usually named in Debian. We can of course absolutely change this.
Would you be up for sending a patch for this?
Sure, as a patch to the list or a pull request on Github?
Please use this list only. We have our tools integrated to it, and GitHub does not allow us to host the database on there since it is too large - so we try to keep the home of the project on our own infrastructure.
That might be a lot easier since you are already an expert with the Debian packaging system. We have been fighting a couple of problems that we couldn’t really solve. Maybe you can help us with those, too: https://bugzilla.ipfire.org/show_bug.cgi?id=12468
I was not able to reproduce this, could you send me a log of when this happens? How do you build the package? With the debian/build.sh?
Yes, we wrote a little helper script to do this.
As mentioned before, I personally have very limited experience with the Debian build system and so this is what we put together :) Any improvements are greatly appreciated.
- Similar I would propose to merge the location-importer package into the python package (for the library part) and the location package (for the binary).
We tried to keep the main package as small as possible. The importer part is not very large, but it does have a dependency to PostgreSQL. Hence we split it, because regular users won’t need it.
Oh, that does not seem to be modeled in the package. Is the location-importer by normal users of libloc? Otherwise I would propose to add a suggest to PostgreSQL only.
That is true. We use a database wrapper around psycopg2 which is what should be added here:
https://git.ipfire.org/?p=location/libloc.git;a=blob;f=src/python/location/d...
I don’t have any hard feelings on changing this. What is your motivation for the change?
We try not to split the packages into too small parts in Debian.
Agreed.
- Finally, are you interested in help maintaining the lib in Debian?
Yes, absolutely. We have been calling for people to help us getting the library into distributions, because we currently do not have the man power to dig into the intricacies of the build systems of all the major distributions. Hence we need you!
But we are of course here to help, test, fix bugs and what ever else needs to be done.
What else does this entail that I didn’t cover, yet?
This is primary a questions how is listed as a maintainer for the package. Packages in Debian need exactly one maintainer which could be a person or a team. In addition there can be multiple Uploaders listed who effectively maintain the package as well (this is due to history reasons). We could use use tracker.debian.org as the team, i.e.:
Maintainer: libloc maintainers libloc@tracker.debian.org
And add however of you want as Uploaders. Note that you would have to ask me or an other Debian Developer to actually upload the package.
That sounds good to me. Our goal is to make libloc available in as many distributions as possible. However, we cannot manage those on our own. There are just too many out there with all very different build systems, requirements and so on.
Also I would put the Debian packaging on
Where most Debian packages are hosted. I'm happy to guide you if you want to help with it.
Yes, please!
-Michael
Thanks for getting in touch!
-Michael
Cheers Jochen