From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: location@lists.ipfire.org Subject: Re: Upload libloc to Debian Date: Tue, 05 Jul 2022 15:28:28 +0100 Message-ID: <1A4374F1-A42A-4A64-8787-BC14BDEDD7E3@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2870684253452240142==" List-Id: --===============2870684253452240142== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Jochen, Apologies for the late reply. I am quite busy with travels this week and load= s of other things, so please bare with :) > On 2 Jul 2022, at 07:57, Jochen Sprickerhof wrote: >=20 > [resent for the location mailing lits] >=20 > Hi Michael, >=20 > * Michael Tremer [2022-07-01 14:19]: >> Hello Jochen, >>=20 >> Thank you for your email. >>=20 >> The best place to get in touch with our team is our mailing list over here: >>=20 >> https://lists.ipfire.org/mailman/listinfo/location >>=20 >> However, I am not sure if you prefer to talk about this matter in private = for the time being. >=20 > Fine with me, added to Cc. >=20 >>> On 1 Jul 2022, at 13:14, Jochen Sprickerhof wro= te: >>>=20 >>> Hi Stefan, >>>=20 >>> I'm a Debian Developer and F-Droid team member. One part of the F-Droid t= ooling is called issuebot [1] a bot to automatically check new app submission= s. 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 basi= s if you agree and would have some questions: >>=20 >> That sounds great! >>=20 >> First of all, we would like to have more users to libloc. So far we have b= een trying to work together with some projects and that has been great cooper= ations, but our time is of course limited, so I am very happy to hear, that y= ou found our little piece of software and went ahead and integrated it. >>=20 >>> - What is the license of the database itself, i.e., what is hosted here? >>>=20 >>> https://location.ipfire.org/databases/1/ >>=20 >> The database itself is licensed under CC-BY-SA 4.0. >>=20 >> 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. >=20 > 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-frie= ldy to read. I added the file to the directory: https://location.ipfire.org/databases/COPY= ING 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=3Dlocation/lo= cation-database.git;a=3Dsummary >=20 >>> - Would it make sense to package the database along with the library? >>=20 >> 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 alre= ady have Tor using it, and there are patches for Suricata (the latter might n= ot be packaged for Debian yet either). >=20 > Suricata seems to be there: >=20 > https://packages.debian.org/sid/suricata >=20 > I did a quick grep in the source but did not see references to libloc, do y= ou 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. >>=20 >> I believe that Debian is doing the same with clamav which has a meta packa= ge with a version of the database. I think following that would make sense fr= om my point of view. >=20 > Sounds great, I see that the updated puts the file in >=20 > /var/lib/location/database.db >=20 > But I don't see where it is used. The libloc-database package would probabl= y install to /usr/share/libloc-database/database.db. Would it be easier if li= bloc 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 tem= porary 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 w= ork. 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? >=20 >>> - According to the Debian Python policy the Python package needs to be re= named to python3-location. It would simplify the transition if you could do t= he same in your package repo and add a transition package [3]. >>=20 >> Oh, I named it that way because that is how Python packages were usually n= amed in Debian. We can of course absolutely change this. >>=20 >> Would you be up for sending a patch for this? >=20 > 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 doe= s not allow us to host the database on there since it is too large - so we tr= y 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= =E2=80=99t really solve. Maybe you can help us with those, too: https://bugzi= lla.ipfire.org/show_bug.cgi?id=3D12468 >=20 > I was not able to reproduce this, could you send me a log of when this happ= ens? > 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 Debia= n build system and so this is what we put together :) Any improvements are gr= eatly appreciated. >=20 >>> - Similar I would propose to merge the location-importer package into the= python package (for the library part) and the location package (for the bina= ry). >>=20 >> 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 spli= t it, because regular users won=E2=80=99t need it. >=20 > Oh, that does not seem to be modeled in the package. Is the location-import= er by normal users of libloc? Otherwise I would propose to add a suggest to P= ostgreSQL only. That is true. We use a database wrapper around psycopg2 which is what should = be added here: https://git.ipfire.org/?p=3Dlocation/libloc.git;a=3Dblob;f=3Dsrc/python/loc= ation/database.py;h=3D5d79941515cf830f81d4aff4a1897c4525d99e82;hb=3DHEAD >> I don=E2=80=99t have any hard feelings on changing this. What is your moti= vation for the change? >=20 > We try not to split the packages into too small parts in Debian. Agreed. >=20 >>> - Finally, are you interested in help maintaining the lib in Debian? >>=20 >> Yes, absolutely. We have been calling for people to help us getting the li= brary into distributions, because we currently do not have the man power to d= ig into the intricacies of the build systems of all the major distributions. = Hence we need you! >>=20 >> But we are of course here to help, test, fix bugs and what ever else needs= to be done. >>=20 >> What else does this entail that I didn=E2=80=99t cover, yet? >=20 > 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 t= eam. In addition there can be multiple Uploaders listed who effectively maint= ain the package as well (this is due to history reasons). We could use use tr= acker.debian.org as the team, i.e.: >=20 > Maintainer: libloc maintainers >=20 > And add however of you want as Uploaders. Note that you would have to ask m= e 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 distr= ibutions as possible. However, we cannot manage those on our own. There are j= ust too many out there with all very different build systems, requirements an= d so on. > Also I would put the Debian packaging on >=20 > https://salsa.debian.org >=20 > Where most Debian packages are hosted. I'm happy to guide you if you want t= o help with it. Yes, please! -Michael >=20 >> Thanks for getting in touch! >>=20 >> -Michael >>=20 >>>=20 >>> Cheers Jochen >>>=20 >>> [1]: https://gitlab.com/fdroid/issuebot >>> [2]: https://gitlab.com/fdroid/issuebot/-/issues/61 >>> [3]: https://wiki.debian.org/RenamingPackages --===============2870684253452240142==--