* Re: Upload libloc to Debian [not found] <82DB10C8-A848-42EF-B395-3E27205E81D8@ipfire.org> @ 2022-07-02 6:57 ` Jochen Sprickerhof 2022-07-05 14:28 ` Michael Tremer 0 siblings, 1 reply; 27+ messages in thread From: Jochen Sprickerhof @ 2022-07-02 6:57 UTC (permalink / raw) To: location [-- Attachment #1: Type: text/plain, Size: 6014 bytes --] [resent for the location mailing lits] Hi Michael, * Michael Tremer <michael.tremer(a)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(a)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? >> >> https://location.ipfire.org/databases/1/ > >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? >> - 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? >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? >> - 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? >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? >> - 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. >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. >> - 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(a)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. Also I would put the Debian packaging on https://salsa.debian.org Where most Debian packages are hosted. I'm happy to guide you if you want to help with it. >Thanks for getting in touch! > >-Michael > >> >> Cheers Jochen >> >> [1]: https://gitlab.com/fdroid/issuebot >> [2]: https://gitlab.com/fdroid/issuebot/-/issues/61 >> [3]: https://wiki.debian.org/RenamingPackages > [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Upload libloc to Debian 2022-07-02 6:57 ` Upload libloc to Debian Jochen Sprickerhof @ 2022-07-05 14:28 ` Michael Tremer 2022-07-06 7:41 ` Jochen Sprickerhof 0 siblings, 1 reply; 27+ messages in thread From: Michael Tremer @ 2022-07-05 14:28 UTC (permalink / raw) To: location [-- Attachment #1: Type: text/plain, Size: 8236 bytes --] 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(a)jochen.sprickerhof.de> wrote: > > [resent for the location mailing lits] > > Hi Michael, > > * Michael Tremer <michael.tremer(a)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(a)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? >>> >>> https://location.ipfire.org/databases/1/ >> >> 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/database.py;h=5d79941515cf830f81d4aff4a1897c4525d99e82;hb=HEAD >> 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(a)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 > > https://salsa.debian.org > > 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 >>> >>> [1]: https://gitlab.com/fdroid/issuebot >>> [2]: https://gitlab.com/fdroid/issuebot/-/issues/61 >>> [3]: https://wiki.debian.org/RenamingPackages ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Upload libloc to Debian 2022-07-05 14:28 ` Michael Tremer @ 2022-07-06 7:41 ` Jochen Sprickerhof 2022-07-06 8:29 ` Michael Tremer 0 siblings, 1 reply; 27+ messages in thread From: Jochen Sprickerhof @ 2022-07-06 7:41 UTC (permalink / raw) To: location [-- Attachment #1: Type: text/plain, Size: 4275 bytes --] * Michael Tremer <michael.tremer(a)ipfire.org> [2022-07-05 15:28]: >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 Nice, thanks. >> 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? I guess that depends on how well known the location is and if users could mess with the file such that it would be good to have some program logic with a fall back. >Does the build system not support overwriting that file at all? In principal you can overwrite the file if you have the rights on the system (for example the updater running as root) but you should not modify (non configuration) files installed though a package manager. For one dpkg --verify would complain and also it could produce non deterministic results if a new package version would overwrite the file again with a maybe older version. I guess the symlink should work, will test it. >>>> - 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. Patch attached. >>> 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. debian/build.sh uses sbuild so there could be logs from the old runs on your system, still. If you could have a look for one with the problem, that would help a lot. >>>> - 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/database.py;h=5d79941515cf830f81d4aff4a1897c4525d99e82;hb=HEAD Ah, that's much easier, you can add python3-psycopg2 to the Depends: field of the location-importer package in debian/control. For Debian I would still propose to merge the packages, should we do that in your packages as well? Cheers Jochen [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-Rename-Python-package-to-python3-location.patch --] [-- Type: text/x-diff, Size: 3195 bytes --] From cf627c7101131d720ec0e2296edbfdc343ed65b6 Mon Sep 17 00:00:00 2001 From: Jochen Sprickerhof <git@jochen.sprickerhof.de> Date: Tue, 5 Jul 2022 23:30:29 +0200 Subject: [PATCH] Rename Python package to python3-location To comply with the Debian Python policy. Also add a transitional package with the old name. --- debian/control | 16 +++++++++++++--- ...python.examples => python3-location.examples} | 0 ...n-python.install => python3-location.install} | 0 debian/rules | 6 +++--- 4 files changed, 16 insertions(+), 6 deletions(-) rename debian/{location-python.examples => python3-location.examples} (100%) rename debian/{location-python.install => python3-location.install} (100%) diff --git a/debian/control b/debian/control index 4b1407a..660f759 100644 --- a/debian/control +++ b/debian/control @@ -54,7 +54,7 @@ Architecture: any Pre-Depends: ${misc:Pre-Depends} Depends: - location-python (= ${binary:Version}), + python3-location, ${misc:Depends}, ${python3:Depends} Multi-Arch: same @@ -66,14 +66,14 @@ Architecture: any Pre-Depends: ${misc:Pre-Depends} Depends: - location-python (= ${binary:Version}), + python3-location, ${misc:Depends}, ${python3:Depends} Multi-Arch: foreign Description: Tools to author location databases This package contains tools that are required to build location databases -Package: location-python +Package: python3-location Architecture: any Section: python Pre-Depends: @@ -82,6 +82,16 @@ Depends: ${misc:Depends}, ${python3:Depends}, ${shlibs:Depends} +Replaces: location-python (<< 0.9.14-1~) +Breaks: location-python (<< 0.9.14-1~) Multi-Arch: foreign Description: Python modules for libloc This package contains Python bindings for libloc + +Package: location-python +Depends: python3-location, ${misc:Depends} +Architecture: all +Priority: optional +Section: oldlibs +Description: transitional package + This is a transitional package. It can safely be removed. diff --git a/debian/location-python.examples b/debian/python3-location.examples similarity index 100% rename from debian/location-python.examples rename to debian/python3-location.examples diff --git a/debian/location-python.install b/debian/python3-location.install similarity index 100% rename from debian/location-python.install rename to debian/python3-location.install diff --git a/debian/rules b/debian/rules index 05b88fd..8c252ec 100755 --- a/debian/rules +++ b/debian/rules @@ -22,7 +22,7 @@ override_dh_systemd_enable: override_dh_install: dh_install # lintian: unknown-file-in-python-module-directory - rm debian/location-python/usr/lib/python3*/site-packages/_location.la + rm debian/python3-location/usr/lib/python3*/site-packages/_location.la # linitan: binaries-have-file-conflict (d/location-importer.install) - rm debian/location-python/usr/lib/python3*/site-packages/location/database.py - rm debian/location-python/usr/lib/python3*/site-packages/location/importer.py + rm debian/python3-location/usr/lib/python3*/site-packages/location/database.py + rm debian/python3-location/usr/lib/python3*/site-packages/location/importer.py -- 2.36.1 [-- Attachment #3: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Upload libloc to Debian 2022-07-06 7:41 ` Jochen Sprickerhof @ 2022-07-06 8:29 ` Michael Tremer 2022-07-07 5:46 ` Jochen Sprickerhof 0 siblings, 1 reply; 27+ messages in thread From: Michael Tremer @ 2022-07-06 8:29 UTC (permalink / raw) To: location [-- Attachment #1: Type: text/plain, Size: 5431 bytes --] Hello, > On 6 Jul 2022, at 08:41, Jochen Sprickerhof <libloc(a)jochen.sprickerhof.de> wrote: > > * Michael Tremer <michael.tremer(a)ipfire.org> [2022-07-05 15:28]: >> 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 > > Nice, thanks. > >>> 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? > > I guess that depends on how well known the location is and if users could mess with the file such that it would be good to have some program logic with a fall back. It slightly varies where distributions put those database files. We could simply make a list and let the module try to open a few unless a specific path has been provided. >> Does the build system not support overwriting that file at all? > > In principal you can overwrite the file if you have the rights on the system (for example the updater running as root) but you should not modify (non configuration) files installed though a package manager. > For one dpkg --verify would complain and also it could produce non deterministic results if a new package version would overwrite the file again with a maybe older version. > > I guess the symlink should work, will test it. This is what I expected. However, if —-verify complains, shouldn’t it complain about the symlink, too? >>>>> - 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. > > Patch attached. Thank you. That looks good. >>>> 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. > > debian/build.sh uses sbuild so there could be logs from the old runs on your system, still. If you could have a look for one with the problem, that would help a lot. Sorry, I forgot to mention that I asked Stefan to upload those log files to the ticket. He should let us know on here when he has done so. >>>>> - 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/database.py;h=5d79941515cf830f81d4aff4a1897c4525d99e82;hb=HEAD > > Ah, that's much easier, you can add python3-psycopg2 to the Depends: field of the location-importer package in debian/control. > For Debian I would still propose to merge the packages, should we do that in your packages as well? Yes, I wouldn’t want any discrepancies here and be as consistent as possible. So, would you be up for submitting a patch for this as well? Ultimately, I am not even sure if there is any point in keeping those build scripts around in our repository. There should only be one set of packages available and if that is part of the distribution already, I do not see any reason why we should have our own set of packages, too. Best, -Michael > > Cheers Jochen > <0001-Rename-Python-package-to-python3-location.patch> ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Upload libloc to Debian 2022-07-06 8:29 ` Michael Tremer @ 2022-07-07 5:46 ` Jochen Sprickerhof 2022-07-08 9:13 ` Michael Tremer 0 siblings, 1 reply; 27+ messages in thread From: Jochen Sprickerhof @ 2022-07-07 5:46 UTC (permalink / raw) To: location [-- Attachment #1: Type: text/plain, Size: 1348 bytes --] * Michael Tremer <michael.tremer(a)ipfire.org> [2022-07-06 09:29]: >This is what I expected. However, if —-verify complains, shouldn’t it complain about the symlink, too? No, I create the symlink in the maintainer scripts: https://salsa.debian.org/debian/libloc/-/blob/master/debian/location.postinst https://salsa.debian.org/debian/libloc/-/blob/master/debian/location.postrm >Yes, I wouldn’t want any discrepancies here and be as consistent as possible. > >So, would you be up for submitting a patch for this as well? Attached. >Ultimately, I am not even sure if there is any point in keeping those build scripts around in our repository. There should only be one set of packages available and if that is part of the distribution already, I do not see any reason why we should have our own set of packages, too. Agreed, though I will upload the package to Debian unstable from where it will transition to testing to be part of the next Debian version (bookworm). You probably want to provide packages for the older Debian versions, still. I've uploaded first versions here: https://salsa.debian.org/debian/libloc https://salsa.debian.org/debian/libloc-database Note that these target Debian unstable and will probably not build on older Debian versions. Testing and comments welcome. Cheers Jochen [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-Merge-location-importer-into-location-package.patch --] [-- Type: text/x-diff, Size: 3283 bytes --] From 9de4bdb6a221c5fa66f97e1272342b6e18404f7a Mon Sep 17 00:00:00 2001 From: Jochen Sprickerhof <git@jochen.sprickerhof.de> Date: Wed, 6 Jul 2022 10:40:42 +0200 Subject: [PATCH] Merge location-importer into location package --- debian/control | 27 +++++++++++++-------------- debian/location-importer.install | 3 --- debian/location.install | 1 + debian/rules | 3 --- 4 files changed, 14 insertions(+), 20 deletions(-) delete mode 100644 debian/location-importer.install diff --git a/debian/control b/debian/control index 660f759..89cac4f 100644 --- a/debian/control +++ b/debian/control @@ -57,22 +57,12 @@ Depends: python3-location, ${misc:Depends}, ${python3:Depends} +Replaces: location-importer (<< 0.9.14-1~) +Breaks: location-importer (<< 0.9.14-1~) Multi-Arch: same Description: CLI utilities for libloc Commands to determine someone's location on the Internet -Package: location-importer -Architecture: any -Pre-Depends: - ${misc:Pre-Depends} -Depends: - python3-location, - ${misc:Depends}, - ${python3:Depends} -Multi-Arch: foreign -Description: Tools to author location databases - This package contains tools that are required to build location databases - Package: python3-location Architecture: any Section: python @@ -81,9 +71,10 @@ Pre-Depends: Depends: ${misc:Depends}, ${python3:Depends}, - ${shlibs:Depends} + ${shlibs:Depends}, + python3-psycopg2, Replaces: location-python (<< 0.9.14-1~) -Breaks: location-python (<< 0.9.14-1~) +Breaks: location-python (<< 0.9.14-1~), location-importer (<< 0.9.14-1~) Multi-Arch: foreign Description: Python modules for libloc This package contains Python bindings for libloc @@ -95,3 +86,11 @@ Priority: optional Section: oldlibs Description: transitional package This is a transitional package. It can safely be removed. + +Package: location-importer +Depends: location, ${misc:Depends} +Architecture: all +Priority: optional +Section: oldlibs +Description: transitional package + This is a transitional package. It can safely be removed. diff --git a/debian/location-importer.install b/debian/location-importer.install deleted file mode 100644 index eaae79d..0000000 --- a/debian/location-importer.install +++ /dev/null @@ -1,3 +0,0 @@ -usr/bin/location-importer -usr/lib/python3*/site-packages/location/database.py -usr/lib/python3*/site-packages/location/importer.py diff --git a/debian/location.install b/debian/location.install index 25d9b6f..716f0de 100644 --- a/debian/location.install +++ b/debian/location.install @@ -1,4 +1,5 @@ usr/bin/location +usr/bin/location-importer var/lib/location/signing-key.pem src/systemd/*.service /lib/systemd/system/ src/systemd/*.timer /lib/systemd/system/ diff --git a/debian/rules b/debian/rules index 8c252ec..6ec8d8a 100755 --- a/debian/rules +++ b/debian/rules @@ -23,6 +23,3 @@ override_dh_install: dh_install # lintian: unknown-file-in-python-module-directory rm debian/python3-location/usr/lib/python3*/site-packages/_location.la - # linitan: binaries-have-file-conflict (d/location-importer.install) - rm debian/python3-location/usr/lib/python3*/site-packages/location/database.py - rm debian/python3-location/usr/lib/python3*/site-packages/location/importer.py -- 2.36.1 [-- Attachment #3: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Upload libloc to Debian 2022-07-07 5:46 ` Jochen Sprickerhof @ 2022-07-08 9:13 ` Michael Tremer 2022-07-08 9:58 ` Jochen Sprickerhof 0 siblings, 1 reply; 27+ messages in thread From: Michael Tremer @ 2022-07-08 9:13 UTC (permalink / raw) To: location [-- Attachment #1: Type: text/plain, Size: 2473 bytes --] Hello Jochen, Wow. I am impressed how quick you are. That is the spirit! Thank you so much! > On 7 Jul 2022, at 07:46, Jochen Sprickerhof <libloc(a)jochen.sprickerhof.de> wrote: > > * Michael Tremer <michael.tremer(a)ipfire.org> [2022-07-06 09:29]: >> This is what I expected. However, if —-verify complains, shouldn’t it complain about the symlink, too? > > No, I create the symlink in the maintainer scripts: > https://salsa.debian.org/debian/libloc/-/blob/master/debian/location.postinst > https://salsa.debian.org/debian/libloc/-/blob/master/debian/location.postrm Ah, that is something I didn’t think of :) >> Yes, I wouldn’t want any discrepancies here and be as consistent as possible. >> >> So, would you be up for submitting a patch for this as well? > > Attached. I merged this patch and the one from your previous email into master. I didn’t rebuild the packages, yet, as there is probably no need. >> Ultimately, I am not even sure if there is any point in keeping those build scripts around in our repository. There should only be one set of packages available and if that is part of the distribution already, I do not see any reason why we should have our own set of packages, too. > > Agreed, though I will upload the package to Debian unstable from where it will transition to testing to be part of the next Debian version (bookworm). You probably want to provide packages for the older Debian versions, still. Yes, at least we need to support stable at the moment to make it easier to use libloc. But that creates a couple of problems for us: I don’t really want to provide packages for unstable and bookworm then, because should use the “official” packages. But I do want to be absolutely compatible with unstable. See below... > I've uploaded first versions here: > > https://salsa.debian.org/debian/libloc > https://salsa.debian.org/debian/libloc-database > > Note that these target Debian unstable and will probably not build on older Debian versions. Testing and comments welcome. And that is the problem then… Would it be a good idea to merge all your changes into our Git repository? Is it long term a good idea to keep debian/ in our repository? In theory that could go as soon as bookworm becomes stable. Any pointers what would be a good idea to do here? -Michael > > Cheers Jochen > <0001-Merge-location-importer-into-location-package.patch> ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Upload libloc to Debian 2022-07-08 9:13 ` Michael Tremer @ 2022-07-08 9:58 ` Jochen Sprickerhof 2022-07-08 11:02 ` Michael Tremer 0 siblings, 1 reply; 27+ messages in thread From: Jochen Sprickerhof @ 2022-07-08 9:58 UTC (permalink / raw) To: location [-- Attachment #1: Type: text/plain, Size: 1885 bytes --] * Michael Tremer <michael.tremer(a)ipfire.org> [2022-07-08 11:13]: >I didn’t rebuild the packages, yet, as there is probably no need. It would be great to provide new packages at some point to ease the transition to the new package names but there is still time. Once users of the ipfire packages upgrade to the new version (which should work seamlessly), updates to the Debian version will be no problem as well. >I don’t really want to provide packages for unstable and bookworm then, because should use the “official” packages. > >But I do want to be absolutely compatible with unstable. See below... What do you mean by "absolutely compatible"? The package names and content are the same and Debian tooling will take care that the packages are compatible with the other packages in unstable. >> I've uploaded first versions here: >> >> https://salsa.debian.org/debian/libloc >> https://salsa.debian.org/debian/libloc-database >> >> Note that these target Debian unstable and will probably not build on older Debian versions. Testing and comments welcome. > >And that is the problem then… The comment was for the Debian source package not software using the library later. I don't see a problem here. >Would it be a good idea to merge all your changes into our Git repository? No, as commented above that would not work when building the package for older Debian versions. You could probably use debhelper from buster-backports to build them if you want. >Is it long term a good idea to keep debian/ in our repository? Debian encourage upstream not to provide a debian/ directory but our tooling filters them anyhow so it is not important. >In theory that could go as soon as bookworm becomes stable. Currently you provide packages for buster and bullseye, I guess you want to keep those. Cheers Jochen [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Upload libloc to Debian 2022-07-08 9:58 ` Jochen Sprickerhof @ 2022-07-08 11:02 ` Michael Tremer 2022-07-08 12:56 ` Jochen Sprickerhof 0 siblings, 1 reply; 27+ messages in thread From: Michael Tremer @ 2022-07-08 11:02 UTC (permalink / raw) To: location [-- Attachment #1: Type: text/plain, Size: 2831 bytes --] Hello, > On 8 Jul 2022, at 11:58, Jochen Sprickerhof <libloc(a)jochen.sprickerhof.de> wrote: > > * Michael Tremer <michael.tremer(a)ipfire.org> [2022-07-08 11:13]: >> I didn’t rebuild the packages, yet, as there is probably no need. > > It would be great to provide new packages at some point to ease the transition to the new package names but there is still time. > Once users of the ipfire packages upgrade to the new version (which should work seamlessly), updates to the Debian version will be no problem as well. I have a couple of open bugs to fix and will soon release a new version. Hopefully in the next few weeks. And then build new packages. >> I don’t really want to provide packages for unstable and bookworm then, because should use the “official” packages. >> >> But I do want to be absolutely compatible with unstable. See below... > > What do you mean by "absolutely compatible"? Have the same set of packages with the same dependencies. So basically provide what is in unstable, just compiled for buster and bullseye. > The package names and content are the same and Debian tooling will take care that the packages are compatible with the other packages in unstable. > >>> I've uploaded first versions here: >>> >>> https://salsa.debian.org/debian/libloc >>> https://salsa.debian.org/debian/libloc-database >>> >>> Note that these target Debian unstable and will probably not build on older Debian versions. Testing and comments welcome. >> >> And that is the problem then… > > The comment was for the Debian source package not software using the library later. I don't see a problem here. > >> Would it be a good idea to merge all your changes into our Git repository? > > No, as commented above that would not work when building the package for older Debian versions. You could probably use debhelper from buster-backports to build them if you want. > >> Is it long term a good idea to keep debian/ in our repository? > > Debian encourage upstream not to provide a debian/ directory but our tooling filters them anyhow so it is not important. We just added it so that we could develop the packaging and where hoping to pass it off to the distribution like we did now. So it was always only supposed to be something temporary. >> In theory that could go as soon as bookworm becomes stable. > > Currently you provide packages for buster and bullseye, I guess you want to keep those. Yes, I was just hoping that the tooling will build on those as well and I just have to run the build :) Since I don’t know enough - barely anything really - about the Debian packaging system, maybe I am asking stupid questions. I will poke around a little bit more. Potentially Stefan already has a plan :) -Michael > > Cheers Jochen ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Upload libloc to Debian 2022-07-08 11:02 ` Michael Tremer @ 2022-07-08 12:56 ` Jochen Sprickerhof 2022-07-13 12:12 ` Michael Tremer 0 siblings, 1 reply; 27+ messages in thread From: Jochen Sprickerhof @ 2022-07-08 12:56 UTC (permalink / raw) To: location [-- Attachment #1: Type: text/plain, Size: 1208 bytes --] * Michael Tremer <michael.tremer(a)ipfire.org> [2022-07-08 13:02]: >> What do you mean by "absolutely compatible"? > >Have the same set of packages with the same dependencies. So basically provide what is in unstable, just compiled for buster and bullseye. Ah, makes sense. >> Currently you provide packages for buster and bullseye, I guess you want to keep those. > >Yes, I was just hoping that the tooling will build on those as well and I just have to run the build :) I've just tried that. For bullseye it just works, for buster you need these extra sbuild arguments: sbuild --extra-repository="deb http://deb.debian.org/debian buster-backports main" --build-dep-resolver=aspcud So yes, you could merge the salsa changes but please keep the location-python and location-importer packages in debian/control to ease transition (I don't plan to upload those to Debian). I've attached a patches for both. >Since I don’t know enough - barely anything really - about the Debian packaging system, maybe I am asking stupid questions. I will poke around a little bit more. Potentially Stefan already has a plan :) No worries, I'm happy to explain Debian :). Cheers Jochen [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0002-Use-buster_backport-for-new-debhelper.patch --] [-- Type: text/x-diff, Size: 1368 bytes --] From 1fd501718f354043ad4b898f5165bcfa3656b3db Mon Sep 17 00:00:00 2001 From: Jochen Sprickerhof <git@jochen.sprickerhof.de> Date: Fri, 8 Jul 2022 14:01:51 +0200 Subject: [PATCH 2/2] Use buster_backport for new debhelper --- debian/build.sh | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) mode change 100644 => 100755 debian/build.sh diff --git a/debian/build.sh b/debian/build.sh old mode 100644 new mode 100755 index a11f3a3..a1f6b6c --- a/debian/build.sh +++ b/debian/build.sh @@ -38,6 +38,9 @@ main() { local release for release in ${RELEASES[@]}; do local chroot="${release}-${host_arch}-sbuild" + if [ "${release}" = "buster" ]; then + local buster_backport=( --extra-repository "deb http://deb.debian.org/debian buster-backports main" --build-dep-resolver=aspcud ) + fi mkdir -p "${release}" pushd "${release}" @@ -62,7 +65,7 @@ main() { cp -r "${tmp}/sources" . # Run the build process - if ! sbuild --dist="${release}" --host="${arch}" --source "sources/${package}"; then + if ! sbuild --dist="${release}" --host="${arch}" --source "${buster_backport[@]}" "sources/${package}"; then echo "Could not build package for ${release} on ${arch}" >&2 rm -rf "${tmp}" return 1 -- 2.36.1 [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #3: 0001-Improvements-from-Debian-packaging.patch --] [-- Type: text/x-diff, Size: 34330 bytes --] From 6b71da731f0892b78a15f40d8fb42ee5054b2536 Mon Sep 17 00:00:00 2001 From: Jochen Sprickerhof <git@jochen.sprickerhof.de> Date: Fri, 8 Jul 2022 13:47:39 +0200 Subject: [PATCH 1/2] Improvements from Debian packaging --- debian/compat | 1 - debian/control | 80 ++--- debian/copyright | 513 +++++++++++++++++++++++++++++++- debian/libloc-dev.install | 1 + debian/libloc1.install | 1 + debian/libloc1.symbols | 2 + debian/location-perl.install | 1 - debian/location.install | 7 +- debian/location.manpages | 1 - debian/location.postinst | 14 + debian/location.postrm | 15 + debian/python3-location.install | 2 +- debian/rules | 32 +- debian/watch | 2 +- 14 files changed, 599 insertions(+), 73 deletions(-) delete mode 100644 debian/compat delete mode 100644 debian/location-perl.install delete mode 100644 debian/location.manpages create mode 100644 debian/location.postinst create mode 100644 debian/location.postrm diff --git a/debian/compat b/debian/compat deleted file mode 100644 index f599e28..0000000 --- a/debian/compat +++ /dev/null @@ -1 +0,0 @@ -10 diff --git a/debian/control b/debian/control index 89cac4f..918c0f6 100644 --- a/debian/control +++ b/debian/control @@ -1,40 +1,40 @@ Source: libloc Maintainer: Stefan Schantl <stefan.schantl@ipfire.org> -Section: misc +Section: net Priority: optional -Standards-Version: 4.3.0 +Standards-Version: 4.6.1 Build-Depends: - debhelper (>= 11), - dh-python <!nopython>, - asciidoc <!nodoc>, - intltool (>=0.40.0), - libpython3-dev <!nopython>, + debhelper-compat (= 13), + dh-sequence-python3, + asciidoc, + intltool, libssl-dev, libsystemd-dev, - python3-dev:any <!nopython>, pkg-config, + python3-all-dev, systemd, - xsltproc <!nodoc>, - docbook-xsl <!nodoc>, - git, + xsltproc, + docbook-xsl, Rules-Requires-Root: no Homepage: https://location.ipfire.org/ -Vcs-Git: https://git.ipfire.org/pub/git/location/libloc.git -Vcs-Browser: https://git.ipfire.org/pub/git/location/libloc.git +Vcs-Git: https://salsa.debian.org/debian/libloc.git +Vcs-Browser: https://salsa.debian.org/debian/libloc +Description: IP geolocation query library + libloc is a lightweight library to query the IPFire Location database and + determine the location of someone else on the Internet based on their IP + address. Package: libloc1 Architecture: any Section: libs -Pre-Depends: - ${misc:Pre-Depends} Depends: ${shlibs:Depends}, - ${misc:Depends} -Recommends: - location (= ${binary:Version}) + ${misc:Depends}, Multi-Arch: same -Description: Location library - A library to determine the location of someone on the Internet +Description: ${source:Synopsis} + ${source:Extended-Description} + . + This package provides the shared library. Package: libloc-dev Architecture: any @@ -42,42 +42,46 @@ Section: libdevel Depends: libloc1 (= ${binary:Version}), ${misc:Depends}, -Suggests: - pkg-config Multi-Arch: same -Description: Development files for libloc - Install this package if you wish to develop your own programs using - libloc. +Description: ${source:Synopsis} (development files) + ${source:Extended-Description} + . + This package provides the headers and development files needed to use libloc + in your own programs. Package: location -Architecture: any -Pre-Depends: - ${misc:Pre-Depends} +Architecture: all Depends: python3-location, ${misc:Depends}, - ${python3:Depends} + ${python3:Depends}, +Recommends: + libloc-database, Replaces: location-importer (<< 0.9.14-1~) Breaks: location-importer (<< 0.9.14-1~) -Multi-Arch: same -Description: CLI utilities for libloc - Commands to determine someone's location on the Internet +Description: ${source:Synopsis} (CLI utilities) + ${source:Extended-Description} + . + This package provides CLI utilities based on libloc. Package: python3-location Architecture: any Section: python -Pre-Depends: - ${misc:Pre-Depends} Depends: ${misc:Depends}, ${python3:Depends}, ${shlibs:Depends}, python3-psycopg2, -Replaces: location-python (<< 0.9.14-1~) -Breaks: location-python (<< 0.9.14-1~), location-importer (<< 0.9.14-1~) +Replaces: + location-python (<< 0.9.14-1~), +Breaks: + location-python (<< 0.9.14-1~), + location-importer (<< 0.9.14-1~), Multi-Arch: foreign -Description: Python modules for libloc - This package contains Python bindings for libloc +Description: ${source:Synopsis} (Python 3 bindings) + ${source:Extended-Description} + . + This package provides the Python 3 bindings for libloc. Package: location-python Depends: python3-location, ${misc:Depends} diff --git a/debian/copyright b/debian/copyright index 3bd7654..2877361 100644 --- a/debian/copyright +++ b/debian/copyright @@ -4,14 +4,516 @@ Upstream-Contact: Michael Tremer <michael.tremer@ipfire.org> Source: https://location.ipfire.org/download Files: * -Copyright: 2017-2019 IPFire Development team <info@ipfire.org> -License: LGPL-2.1 +Copyright: 2017-2022, IPFire Development Team <info@ipfire.org> +License: LGPL-2.1+ + +Files: m4/* + src/test-address.c + src/test-as.c + src/test-country.c + src/test-database.c + src/test-libloc.c + src/test-network-list.c + src/test-network.c + src/test-signature.c + src/test-stringpool.c +Copyright: 2006-2008, Diego Pettenò <flameeyes@gmail.com> + 2017-2022, IPFire Development Team <info@ipfire.org> + 2012, Lucas De Marchi <lucas.de.marchi@gmail.com> + 2006-2008, xine project +License: GPL-2+ + +Files: src/perl/lib/* +Copyright: 2019, Stefan Schantl +License: Artistic-or-GPL + +Files: m4/ax_prog_perl_modules.m4 +Copyright: 2009, Dean Povey <povey@wedgetail.com> +License: FSFAP + +Files: m4/ld-version-script.m4 +Copyright: 2008-2015, Free Software Foundation, Inc +License: FSFULLR + +Files: tests/data/* +Copyright: 2017-2022, IPFire Development Team <info@ipfire.org> +License: CC-BY-SA-4 Files: debian/* -Copyright: 2019 Stefan Schantl <stefan.schantl@ipfire.org> -License: LGPL-2.1 +Copyright: 2022, Jochen Sprickerhof <jspricke@debian.org> + 2019, Stefan Schantl <stefan.schantl@ipfire.org> +License: LGPL-2.1+ + +License: Artistic-or-GPL + This library is free software; you can redistribute it and/or modify + it under the same terms as Perl itself, either Perl version 5.28.1 or, + at your option, any later version of Perl 5 you may have available. + . + On Debian GNU/Linux systems, the complete text of the GNU General + Public License can be found in '/usr/share/common-licenses/GPL' and + the Artistic Licence in '/usr/share/common-licenses/Artistic'. -License: LGPL-2.1 +License: CC-BY-SA-4 + http://creativecommons.org/licenses/by-sa/4.0/ + . + Attribution-ShareAlike 4.0 International + . + ======================================================================= + . + Creative Commons Corporation ("Creative Commons") is not a law firm and + does not provide legal services or legal advice. Distribution of + Creative Commons public licenses does not create a lawyer-client or + other relationship. Creative Commons makes its licenses and related + information available on an "as-is" basis. Creative Commons gives no + warranties regarding its licenses, any material licensed under their + terms and conditions, or any related information. Creative Commons + disclaims all liability for damages resulting from their use to the + fullest extent possible. + . + Using Creative Commons Public Licenses + . + Creative Commons public licenses provide a standard set of terms and + conditions that creators and other rights holders may use to share + original works of authorship and other material subject to copyright + and certain other rights specified in the public license below. The + following considerations are for informational purposes only, are not + exhaustive, and do not form part of our licenses. + . + Considerations for licensors: Our public licenses are + intended for use by those authorized to give the public + permission to use material in ways otherwise restricted by + copyright and certain other rights. Our licenses are + irrevocable. Licensors should read and understand the terms + and conditions of the license they choose before applying it. + Licensors should also secure all rights necessary before + applying our licenses so that the public can reuse the + material as expected. Licensors should clearly mark any + material not subject to the license. This includes other CC- + licensed material, or material used under an exception or + limitation to copyright. More considerations for licensors: + wiki.creativecommons.org/Considerations_for_licensors + . + Considerations for the public: By using one of our public + licenses, a licensor grants the public permission to use the + licensed material under specified terms and conditions. If + the licensor's permission is not necessary for any reason--for + example, because of any applicable exception or limitation to + copyright--then that use is not regulated by the license. Our + licenses grant only permissions under copyright and certain + other rights that a licensor has authority to grant. Use of + the licensed material may still be restricted for other + reasons, including because others have copyright or other + rights in the material. A licensor may make special requests, + such as asking that all changes be marked or described. + Although not required by our licenses, you are encouraged to + respect those requests where reasonable. More_considerations + for the public: + wiki.creativecommons.org/Considerations_for_licensees + . + ======================================================================= + . + Creative Commons Attribution-ShareAlike 4.0 International Public + License + . + By exercising the Licensed Rights (defined below), You accept and agree + to be bound by the terms and conditions of this Creative Commons + Attribution-ShareAlike 4.0 International Public License ("Public + License"). To the extent this Public License may be interpreted as a + contract, You are granted the Licensed Rights in consideration of Your + acceptance of these terms and conditions, and the Licensor grants You + such rights in consideration of benefits the Licensor receives from + making the Licensed Material available under these terms and + conditions. + . + . + Section 1 -- Definitions. + . + a. Adapted Material means material subject to Copyright and Similar + Rights that is derived from or based upon the Licensed Material + and in which the Licensed Material is translated, altered, + arranged, transformed, or otherwise modified in a manner requiring + permission under the Copyright and Similar Rights held by the + Licensor. For purposes of this Public License, where the Licensed + Material is a musical work, performance, or sound recording, + Adapted Material is always produced where the Licensed Material is + synched in timed relation with a moving image. + . + b. Adapter's License means the license You apply to Your Copyright + and Similar Rights in Your contributions to Adapted Material in + accordance with the terms and conditions of this Public License. + . + c. BY-SA Compatible License means a license listed at + creativecommons.org/compatiblelicenses, approved by Creative + Commons as essentially the equivalent of this Public License. + . + d. Copyright and Similar Rights means copyright and/or similar rights + closely related to copyright including, without limitation, + performance, broadcast, sound recording, and Sui Generis Database + Rights, without regard to how the rights are labeled or + categorized. For purposes of this Public License, the rights + specified in Section 2(b)(1)-(2) are not Copyright and Similar + Rights. + . + e. Effective Technological Measures means those measures that, in the + absence of proper authority, may not be circumvented under laws + fulfilling obligations under Article 11 of the WIPO Copyright + Treaty adopted on December 20, 1996, and/or similar international + agreements. + . + f. Exceptions and Limitations means fair use, fair dealing, and/or + any other exception or limitation to Copyright and Similar Rights + that applies to Your use of the Licensed Material. + . + g. License Elements means the license attributes listed in the name + of a Creative Commons Public License. The License Elements of this + Public License are Attribution and ShareAlike. + . + h. Licensed Material means the artistic or literary work, database, + or other material to which the Licensor applied this Public + License. + . + i. Licensed Rights means the rights granted to You subject to the + terms and conditions of this Public License, which are limited to + all Copyright and Similar Rights that apply to Your use of the + Licensed Material and that the Licensor has authority to license. + . + j. Licensor means the individual(s) or entity(ies) granting rights + under this Public License. + . + k. Share means to provide material to the public by any means or + process that requires permission under the Licensed Rights, such + as reproduction, public display, public performance, distribution, + dissemination, communication, or importation, and to make material + available to the public including in ways that members of the + public may access the material from a place and at a time + individually chosen by them. + . + l. Sui Generis Database Rights means rights other than copyright + resulting from Directive 96/9/EC of the European Parliament and of + the Council of 11 March 1996 on the legal protection of databases, + as amended and/or succeeded, as well as other essentially + equivalent rights anywhere in the world. + . + m. You means the individual or entity exercising the Licensed Rights + under this Public License. Your has a corresponding meaning. + . + . + Section 2 -- Scope. + . + a. License grant. + . + 1. Subject to the terms and conditions of this Public License, + the Licensor hereby grants You a worldwide, royalty-free, + non-sublicensable, non-exclusive, irrevocable license to + exercise the Licensed Rights in the Licensed Material to: + . + a. reproduce and Share the Licensed Material, in whole or + in part; and + . + b. produce, reproduce, and Share Adapted Material. + . + 2. Exceptions and Limitations. For the avoidance of doubt, where + Exceptions and Limitations apply to Your use, this Public + License does not apply, and You do not need to comply with + its terms and conditions. + . + 3. Term. The term of this Public License is specified in Section + 6(a). + . + 4. Media and formats; technical modifications allowed. The + Licensor authorizes You to exercise the Licensed Rights in + all media and formats whether now known or hereafter created, + and to make technical modifications necessary to do so. The + Licensor waives and/or agrees not to assert any right or + authority to forbid You from making technical modifications + necessary to exercise the Licensed Rights, including + technical modifications necessary to circumvent Effective + Technological Measures. For purposes of this Public License, + simply making modifications authorized by this Section 2(a) + (4) never produces Adapted Material. + . + 5. Downstream recipients. + . + a. Offer from the Licensor -- Licensed Material. Every + recipient of the Licensed Material automatically + receives an offer from the Licensor to exercise the + Licensed Rights under the terms and conditions of this + Public License. + . + b. Additional offer from the Licensor -- Adapted Material. + Every recipient of Adapted Material from You + automatically receives an offer from the Licensor to + exercise the Licensed Rights in the Adapted Material + under the conditions of the Adapter's License You apply. + . + c. No downstream restrictions. You may not offer or impose + any additional or different terms or conditions on, or + apply any Effective Technological Measures to, the + Licensed Material if doing so restricts exercise of the + Licensed Rights by any recipient of the Licensed + Material. + . + 6. No endorsement. Nothing in this Public License constitutes or + may be construed as permission to assert or imply that You + are, or that Your use of the Licensed Material is, connected + with, or sponsored, endorsed, or granted official status by, + the Licensor or others designated to receive attribution as + provided in Section 3(a)(1)(A)(i). + . + b. Other rights. + . + 1. Moral rights, such as the right of integrity, are not + licensed under this Public License, nor are publicity, + privacy, and/or other similar personality rights; however, to + the extent possible, the Licensor waives and/or agrees not to + assert any such rights held by the Licensor to the limited + extent necessary to allow You to exercise the Licensed + Rights, but not otherwise. + . + 2. Patent and trademark rights are not licensed under this + Public License. + . + 3. To the extent possible, the Licensor waives any right to + collect royalties from You for the exercise of the Licensed + Rights, whether directly or through a collecting society + under any voluntary or waivable statutory or compulsory + licensing scheme. In all other cases the Licensor expressly + reserves any right to collect such royalties. + . + . + Section 3 -- License Conditions. + . + Your exercise of the Licensed Rights is expressly made subject to the + following conditions. + . + a. Attribution. + . + 1. If You Share the Licensed Material (including in modified + form), You must: + . + a. retain the following if it is supplied by the Licensor + with the Licensed Material: + . + i. identification of the creator(s) of the Licensed + Material and any others designated to receive + attribution, in any reasonable manner requested by + the Licensor (including by pseudonym if + designated); + . + ii. a copyright notice; + . + iii. a notice that refers to this Public License; + . + iv. a notice that refers to the disclaimer of + warranties; + . + v. a URI or hyperlink to the Licensed Material to the + extent reasonably practicable; + . + b. indicate if You modified the Licensed Material and + retain an indication of any previous modifications; and + . + c. indicate the Licensed Material is licensed under this + Public License, and include the text of, or the URI or + hyperlink to, this Public License. + . + 2. You may satisfy the conditions in Section 3(a)(1) in any + reasonable manner based on the medium, means, and context in + which You Share the Licensed Material. For example, it may be + reasonable to satisfy the conditions by providing a URI or + hyperlink to a resource that includes the required + information. + . + 3. If requested by the Licensor, You must remove any of the + information required by Section 3(a)(1)(A) to the extent + reasonably practicable. + . + b. ShareAlike. + . + In addition to the conditions in Section 3(a), if You Share + Adapted Material You produce, the following conditions also apply. + . + 1. The Adapter's License You apply must be a Creative Commons + license with the same License Elements, this version or + later, or a BY-SA Compatible License. + . + 2. You must include the text of, or the URI or hyperlink to, the + Adapter's License You apply. You may satisfy this condition + in any reasonable manner based on the medium, means, and + context in which You Share Adapted Material. + . + 3. You may not offer or impose any additional or different terms + or conditions on, or apply any Effective Technological + Measures to, Adapted Material that restrict exercise of the + rights granted under the Adapter's License You apply. + . + . + Section 4 -- Sui Generis Database Rights. + . + Where the Licensed Rights include Sui Generis Database Rights that + apply to Your use of the Licensed Material: + . + a. for the avoidance of doubt, Section 2(a)(1) grants You the right + to extract, reuse, reproduce, and Share all or a substantial + portion of the contents of the database; + . + b. if You include all or a substantial portion of the database + contents in a database in which You have Sui Generis Database + Rights, then the database in which You have Sui Generis Database + Rights (but not its individual contents) is Adapted Material, + . + including for purposes of Section 3(b); and + c. You must comply with the conditions in Section 3(a) if You Share + all or a substantial portion of the contents of the database. + . + For the avoidance of doubt, this Section 4 supplements and does not + replace Your obligations under this Public License where the Licensed + Rights include other Copyright and Similar Rights. + . + . + Section 5 -- Disclaimer of Warranties and Limitation of Liability. + . + a. UNLESS OTHERWISE SEPARATELY UNDERTAKEN BY THE LICENSOR, TO THE + EXTENT POSSIBLE, THE LICENSOR OFFERS THE LICENSED MATERIAL AS-IS + AND AS-AVAILABLE, AND MAKES NO REPRESENTATIONS OR WARRANTIES OF + ANY KIND CONCERNING THE LICENSED MATERIAL, WHETHER EXPRESS, + IMPLIED, STATUTORY, OR OTHER. THIS INCLUDES, WITHOUT LIMITATION, + WARRANTIES OF TITLE, MERCHANTABILITY, FITNESS FOR A PARTICULAR + PURPOSE, NON-INFRINGEMENT, ABSENCE OF LATENT OR OTHER DEFECTS, + ACCURACY, OR THE PRESENCE OR ABSENCE OF ERRORS, WHETHER OR NOT + KNOWN OR DISCOVERABLE. WHERE DISCLAIMERS OF WARRANTIES ARE NOT + ALLOWED IN FULL OR IN PART, THIS DISCLAIMER MAY NOT APPLY TO YOU. + . + b. TO THE EXTENT POSSIBLE, IN NO EVENT WILL THE LICENSOR BE LIABLE + TO YOU ON ANY LEGAL THEORY (INCLUDING, WITHOUT LIMITATION, + NEGLIGENCE) OR OTHERWISE FOR ANY DIRECT, SPECIAL, INDIRECT, + INCIDENTAL, CONSEQUENTIAL, PUNITIVE, EXEMPLARY, OR OTHER LOSSES, + COSTS, EXPENSES, OR DAMAGES ARISING OUT OF THIS PUBLIC LICENSE OR + USE OF THE LICENSED MATERIAL, EVEN IF THE LICENSOR HAS BEEN + ADVISED OF THE POSSIBILITY OF SUCH LOSSES, COSTS, EXPENSES, OR + DAMAGES. WHERE A LIMITATION OF LIABILITY IS NOT ALLOWED IN FULL OR + IN PART, THIS LIMITATION MAY NOT APPLY TO YOU. + . + c. The disclaimer of warranties and limitation of liability provided + above shall be interpreted in a manner that, to the extent + possible, most closely approximates an absolute disclaimer and + waiver of all liability. + . + . + Section 6 -- Term and Termination. + . + a. This Public License applies for the term of the Copyright and + Similar Rights licensed here. However, if You fail to comply with + this Public License, then Your rights under this Public License + terminate automatically. + . + b. Where Your right to use the Licensed Material has terminated under + Section 6(a), it reinstates: + . + 1. automatically as of the date the violation is cured, provided + it is cured within 30 days of Your discovery of the + violation; or + . + 2. upon express reinstatement by the Licensor. + . + For the avoidance of doubt, this Section 6(b) does not affect any + right the Licensor may have to seek remedies for Your violations + of this Public License. + . + c. For the avoidance of doubt, the Licensor may also offer the + Licensed Material under separate terms or conditions or stop + distributing the Licensed Material at any time; however, doing so + will not terminate this Public License. + . + d. Sections 1, 5, 6, 7, and 8 survive termination of this Public + License. + . + . + Section 7 -- Other Terms and Conditions. + . + a. The Licensor shall not be bound by any additional or different + terms or conditions communicated by You unless expressly agreed. + . + b. Any arrangements, understandings, or agreements regarding the + Licensed Material not stated herein are separate from and + independent of the terms and conditions of this Public License. + . + . + Section 8 -- Interpretation. + . + a. For the avoidance of doubt, this Public License does not, and + shall not be interpreted to, reduce, limit, restrict, or impose + conditions on any use of the Licensed Material that could lawfully + be made without permission under this Public License. + . + b. To the extent possible, if any provision of this Public License is + deemed unenforceable, it shall be automatically reformed to the + minimum extent necessary to make it enforceable. If the provision + cannot be reformed, it shall be severed from this Public License + without affecting the enforceability of the remaining terms and + conditions. + . + c. No term or condition of this Public License will be waived and no + failure to comply consented to unless expressly agreed to by the + Licensor. + . + d. Nothing in this Public License constitutes or may be interpreted + as a limitation upon, or waiver of, any privileges and immunities + that apply to the Licensor or You, including from the legal + processes of any jurisdiction or authority. + . + . + ======================================================================= + . + Creative Commons is not a party to its public + licenses. Notwithstanding, Creative Commons may elect to apply one of + its public licenses to material it publishes and in those instances + will be considered the “Licensor.” The text of the Creative Commons + public licenses is dedicated to the public domain under the CC0 Public + Domain Dedication. Except for the limited purpose of indicating that + material is shared under a Creative Commons public license or as + otherwise permitted by the Creative Commons policies published at + creativecommons.org/policies, Creative Commons does not authorize the + use of the trademark "Creative Commons" or any other trademark or logo + of Creative Commons without its prior written consent including, + without limitation, in connection with any unauthorized modifications + to any of its public licenses or any other arrangements, + understandings, or agreements concerning use of licensed material. For + the avoidance of doubt, this paragraph does not form part of the + public licenses. + . + Creative Commons may be contacted at creativecommons.org. + +License: FSFAP + Copying and distribution of this file, with or without modification, are + permitted in any medium without royalty provided the copyright notice + and this notice are preserved. This file is offered as-is, without any + warranty. + +License: FSFULLR + This file is free software; the Free Software Foundation gives + unlimited permission to copy and/or distribute it, with or without + modifications, as long as this notice is preserved. + +License: GPL-2+ + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 2 of the License, or + (at your option) any later version. + . + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + . + You should have received a copy of the GNU General Public License along + with this program; if not, write to the Free Software Foundation, Inc., + 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. + . + On Debian systems, the complete text of the GNU General Public + License version 2 can be found in `/usr/share/common-licenses/GPL-2'. + +License: LGPL-2.1+ This program is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; version 2.1 of the License, or (at @@ -23,4 +525,3 @@ License: LGPL-2.1 . The complete text of the GNU General Public License can be found in /usr/share/common-licenses/LGPL-2.1 file. - . diff --git a/debian/libloc-dev.install b/debian/libloc-dev.install index d93d217..04e85fa 100644 --- a/debian/libloc-dev.install +++ b/debian/libloc-dev.install @@ -1,3 +1,4 @@ usr/include/libloc usr/lib/*/libloc.so usr/lib/*/pkgconfig +usr/share/man/man3 diff --git a/debian/libloc1.install b/debian/libloc1.install index 0f8eec4..e6cb2ac 100644 --- a/debian/libloc1.install +++ b/debian/libloc1.install @@ -1 +1,2 @@ usr/lib/*/libloc.so.* +usr/share/locale/*/LC_MESSAGES/libloc.mo diff --git a/debian/libloc1.symbols b/debian/libloc1.symbols index abdc32a..3770535 100644 --- a/debian/libloc1.symbols +++ b/debian/libloc1.symbols @@ -13,6 +13,7 @@ libloc.so.1 libloc1 #MINVER# loc_as_list_new@LIBLOC_1 0.9.5 loc_as_list_ref@LIBLOC_1 0.9.5 loc_as_list_size@LIBLOC_1 0.9.5 + loc_as_list_sort@LIBLOC_1 0.9.12 loc_as_list_unref@LIBLOC_1 0.9.5 loc_as_new@LIBLOC_1 0.9.4 loc_as_ref@LIBLOC_1 0.9.4 @@ -32,6 +33,7 @@ libloc.so.1 libloc1 #MINVER# loc_country_list_new@LIBLOC_1 0.9.5 loc_country_list_ref@LIBLOC_1 0.9.5 loc_country_list_size@LIBLOC_1 0.9.5 + loc_country_list_sort@LIBLOC_1 0.9.12 loc_country_list_unref@LIBLOC_1 0.9.5 loc_country_new@LIBLOC_1 0.9.4 loc_country_ref@LIBLOC_1 0.9.4 diff --git a/debian/location-perl.install b/debian/location-perl.install deleted file mode 100644 index 08e8cc4..0000000 --- a/debian/location-perl.install +++ /dev/null @@ -1 +0,0 @@ -usr/lib/*/perl/ diff --git a/debian/location.install b/debian/location.install index 716f0de..f9cb894 100644 --- a/debian/location.install +++ b/debian/location.install @@ -1,5 +1,4 @@ -usr/bin/location -usr/bin/location-importer +usr/bin var/lib/location/signing-key.pem -src/systemd/*.service /lib/systemd/system/ -src/systemd/*.timer /lib/systemd/system/ +lib/systemd/system +usr/share/man/man8 diff --git a/debian/location.manpages b/debian/location.manpages deleted file mode 100644 index 3e662bb..0000000 --- a/debian/location.manpages +++ /dev/null @@ -1 +0,0 @@ -man/location.8 diff --git a/debian/location.postinst b/debian/location.postinst new file mode 100644 index 0000000..913f39c --- /dev/null +++ b/debian/location.postinst @@ -0,0 +1,14 @@ +#!/bin/sh + +set -e + +case "$1" in + configure) + mkdir -p /var/lib/location || true + ln -s /usr/share/libloc-location/location.db /var/lib/location/database.db 2>/dev/null || true + ;; +esac + +#DEBHELPER# + +exit 0 diff --git a/debian/location.postrm b/debian/location.postrm new file mode 100644 index 0000000..df1b03e --- /dev/null +++ b/debian/location.postrm @@ -0,0 +1,15 @@ +#!/bin/sh + +set -e + +case "$1" in + purge) + rm -f /var/lib/location/database.db 2>/dev/null + rm -f /var/lib/location/signing-key.pem 2>/dev/null + rmdir /var/lib/location || true + ;; +esac + +#DEBHELPER# + +exit 0 diff --git a/debian/python3-location.install b/debian/python3-location.install index a6004ca..4606faa 100644 --- a/debian/python3-location.install +++ b/debian/python3-location.install @@ -1 +1 @@ -usr/lib/python3*/site-packages +usr/lib/python3* diff --git a/debian/rules b/debian/rules index 6ec8d8a..e5e3f18 100755 --- a/debian/rules +++ b/debian/rules @@ -1,25 +1,17 @@ #!/usr/bin/make -f -# enable verbose mode -#export DH_VERBOSE=1 - -# enable all hardening build flags export DEB_BUILD_MAINT_OPTIONS=hardening=+all +export PYBUILD_SYSTEM=custom +export PYBUILD_CLEAN_ARGS=dh_auto_clean +export PYBUILD_CONFIGURE_ARGS=intltoolize --force --automake; \ + PYTHON={interpreter} dh_auto_configure -- \ + --disable-perl +export PYBUILD_BUILD_ARGS=dh_auto_build +export PYBUILD_INSTALL_ARGS=dh_auto_install --destdir={destdir}; \ + mkdir -p {destdir}/usr/lib/python{version}/dist-packages; \ + mv {destdir}/usr/lib/python3/dist-packages/_location.so {destdir}/usr/lib/python{version}/dist-packages/_location.so; \ + rm -f {destdir}/usr/lib/python3/dist-packages/_location.la {destdir}/usr/lib/*/libloc.la +export PYBUILD_TEST_ARGS=dh_auto_test %: - dh $@ --with python3 --with-systemd - -override_dh_auto_configure: - intltoolize --force --automake - dh_auto_configure -- --disable-perl - -override_dh_perl: - dh_perl -d - -override_dh_systemd_enable: - dh_systemd_enable location-update.timer - -override_dh_install: - dh_install - # lintian: unknown-file-in-python-module-directory - rm debian/python3-location/usr/lib/python3*/site-packages/_location.la + dh $@ --buildsystem=pybuild diff --git a/debian/watch b/debian/watch index 19ace6d..f466401 100644 --- a/debian/watch +++ b/debian/watch @@ -1,3 +1,3 @@ version=4 https://source.ipfire.org/releases/libloc/ \ - @PACKAGE@@ANY_VERSION@@ARCHIVE_EXT@ debian uupdate + @PACKAGE@@ANY_VERSION@@ARCHIVE_EXT@ -- 2.36.1 [-- Attachment #4: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Upload libloc to Debian 2022-07-08 12:56 ` Jochen Sprickerhof @ 2022-07-13 12:12 ` Michael Tremer 2022-07-22 21:06 ` Jochen Sprickerhof 0 siblings, 1 reply; 27+ messages in thread From: Michael Tremer @ 2022-07-13 12:12 UTC (permalink / raw) To: location [-- Attachment #1: Type: text/plain, Size: 1818 bytes --] Hello Jochen, > On 8 Jul 2022, at 14:56, Jochen Sprickerhof <libloc(a)jochen.sprickerhof.de> wrote: > > * Michael Tremer <michael.tremer(a)ipfire.org> [2022-07-08 13:02]: >>> What do you mean by "absolutely compatible"? >> >> Have the same set of packages with the same dependencies. So basically provide what is in unstable, just compiled for buster and bullseye. > > Ah, makes sense. I am a simple kind of guy sometimes :) >>> Currently you provide packages for buster and bullseye, I guess you want to keep those. >> >> Yes, I was just hoping that the tooling will build on those as well and I just have to run the build :) > > I've just tried that. For bullseye it just works, for buster you need these extra sbuild arguments: > > sbuild --extra-repository="deb http://deb.debian.org/debian buster-backports main" --build-dep-resolver=aspcud > > So yes, you could merge the salsa changes but please keep the location-python and location-importer packages in debian/control to ease transition (I don't plan to upload those to Debian). > > I've attached a patches for both. Perfect. I merged them straight into master. >> Since I don’t know enough - barely anything really - about the Debian packaging system, maybe I am asking stupid questions. I will poke around a little bit more. Potentially Stefan already has a plan :) > > No worries, I'm happy to explain Debian :). Thanks. I am a happy user, but the build system is a little bit hard to get into for the occasion. We have, however, some more projects which we should package and make available in Debian over time. Any pointers for that? Would you be able to help? Best, -Michael > Cheers Jochen > <0002-Use-buster_backport-for-new-debhelper.patch><0001-Improvements-from-Debian-packaging.patch> ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Upload libloc to Debian 2022-07-13 12:12 ` Michael Tremer @ 2022-07-22 21:06 ` Jochen Sprickerhof 2022-08-16 9:00 ` Michael Tremer 0 siblings, 1 reply; 27+ messages in thread From: Jochen Sprickerhof @ 2022-07-22 21:06 UTC (permalink / raw) To: location [-- Attachment #1: Type: text/plain, Size: 458 bytes --] Hi, libloc and libloc-database are now in Debian unstable should transition to Debian testing in the next 5 days. One nitpick is that it does not build an all platforms: https://buildd.debian.org/status/package.php?p=libloc Not really important but maybe worth to look into for bugs in the code. You can try to reproduce the failing tests with these images: https://people.debian.org/~gio/dqib/ Otherwise I could test on real hardware. Cheers Jochen [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Upload libloc to Debian 2022-07-22 21:06 ` Jochen Sprickerhof @ 2022-08-16 9:00 ` Michael Tremer 2022-08-17 13:17 ` Jochen Sprickerhof 0 siblings, 1 reply; 27+ messages in thread From: Michael Tremer @ 2022-08-16 9:00 UTC (permalink / raw) To: location [-- Attachment #1: Type: text/plain, Size: 1774 bytes --] Hello Jochen, > On 22 Jul 2022, at 22:06, Jochen Sprickerhof <libloc(a)jochen.sprickerhof.de> wrote: > > Hi, > > libloc and libloc-database are now in Debian unstable should transition to Debian testing in the next 5 days. One nitpick is that it does not build an all platforms: > > https://buildd.debian.org/status/package.php?p=libloc I installed a virtual machine with mips64el and the testsuite weirdly runs through. I need to double-check what changes in the build environment on the affected systems. From what I can see, the error looks very similar across all the architectures this does not build for. make --no-print-directory check-TESTS check-local PASS: src/test-libloc PASS: src/test-stringpool PASS: src/test-database PASS: src/test-as PASS: src/test-network PASS: src/test-network-list PASS: src/test-country PASS: src/test-signature PASS: src/test-address PASS: tests/python/test-export.py ============================================================================ Testsuite summary for libloc 0.9.14 ============================================================================ # TOTAL: 10 # PASS: 10 # SKIP: 0 # XFAIL: 0 # FAIL: 0 # XPASS: 0 # ERROR: 0 ============================================================================ > Not really important but maybe worth to look into for bugs in the code. > You can try to reproduce the failing tests with these images: > > https://people.debian.org/~gio/dqib/ > > Otherwise I could test on real hardware. > > Cheers Jochen Additionally, the packages don’t build for Debian any more using my script. I opened a bug ticket with the error here: https://bugzilla.ipfire.org/show_bug.cgi?id=12912 If you like you can grab it :) -Michael ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Upload libloc to Debian 2022-08-16 9:00 ` Michael Tremer @ 2022-08-17 13:17 ` Jochen Sprickerhof [not found] ` <048f09d9-9985-a356-fed1-4cd8e286b87e@guardianproject.info> 0 siblings, 1 reply; 27+ messages in thread From: Jochen Sprickerhof @ 2022-08-17 13:17 UTC (permalink / raw) To: location [-- Attachment #1: Type: text/plain, Size: 1358 bytes --] Hi Michael, * Michael Tremer <michael.tremer(a)ipfire.org> [2022-08-16 10:00]: >> https://buildd.debian.org/status/package.php?p=libloc > >I installed a virtual machine with mips64el and the testsuite weirdly runs through. I was able to reproduce it using ppc64el: # echo "deb-src http://deb.debian.org/debian unstable main" >> /etc/apt/sources.list # apt update # apt build-dep libloc # apt source --compile libloc Interestingly the new version now also fails on mipsel, so maybe it is a flaky test? https://buildd.debian.org/status/logs.php?pkg=libloc&arch=mipsel Given that it compiled before this means we should try to fix the bug as it is blocks testing migration, otherwise: https://tracker.debian.org/pkg/libloc (The other option would be to request removal of the old mipsel version.) >Additionally, the packages don’t build for Debian any more using my script. > >I opened a bug ticket with the error here: https://bugzilla.ipfire.org/show_bug.cgi?id=12912 Looks like you try to cross build (installing crossbuild-essential-arm64:amd64), maybe that's currently broken. You can try installing qemu-user-static and replace --host with --arch in debian/build.sh. Btw. sbuild updates the chroot before building so there should be no need to throw it away (for a stable release). Cheers Jochen [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
[parent not found: <048f09d9-9985-a356-fed1-4cd8e286b87e@guardianproject.info>]
* Re: Upload libloc to Debian [not found] ` <048f09d9-9985-a356-fed1-4cd8e286b87e@guardianproject.info> @ 2023-03-02 16:19 ` Stefan Schantl 2023-03-02 17:26 ` Michael Tremer 0 siblings, 1 reply; 27+ messages in thread From: Stefan Schantl @ 2023-03-02 16:19 UTC (permalink / raw) To: location [-- Attachment #1: Type: text/plain, Size: 2431 bytes --] Hello Hans-Christoph, a big thanks for writing and sharing your script. I've added it to the official libloc source code by the following commit: ttps://git.ipfire.org/?p=location/libloc.git;a=commit;h=02a7d6ec0bb79f9 62ffe0746d311b3454b11a3db Best regards, -Stefan > > Hey all, > > I just uploaded a new version of the libloc Debian package that > includes bash > completion for the 'location' command. I would like to see this file > included > upstream in your git, so it is also attached to the email. > > If you want to try it, either install location 0.9.16-2 from Debian, > or stick > the attached file in /etc/bash_completion.d/location and open a new > bash shell. > > .hc > > Jochen Sprickerhof: > > Hi Michael, > > > > * Michael Tremer <michael.tremer(a)ipfire.org> [2022-08-16 10:00]: > > > > https://buildd.debian.org/status/package.php?p=libloc > > > > > > I installed a virtual machine with mips64el and the testsuite > > > weirdly runs > > > through. > > > > I was able to reproduce it using ppc64el: > > > > # echo "deb-src http://deb.debian.org/debian unstable main" >> > > /etc/apt/sources.list > > # apt update > > # apt build-dep libloc > > # apt source --compile libloc > > > > Interestingly the new version now also fails on mipsel, so maybe it > > is a flaky > > test? > > > > https://buildd.debian.org/status/logs.php?pkg=libloc&arch=mipsel > > > > Given that it compiled before this means we should try to fix the > > bug as it is > > blocks testing migration, otherwise: > > > > https://tracker.debian.org/pkg/libloc > > > > (The other option would be to request removal of the old mipsel > > version.) > > > > > Additionally, the packages don’t build for Debian any more using > > > my script. > > > > > > I opened a bug ticket with the error here: > > > https://bugzilla.ipfire.org/show_bug.cgi?id=12912 > > > > Looks like you try to cross build (installing crossbuild-essential- > > arm64:amd64), > > maybe that's currently broken. You can try installing qemu-user- > > static and > > replace --host with --arch in debian/build.sh. > > Btw. sbuild updates the chroot before building so there should be > > no need to > > throw it away (for a stable release). > > > > Cheers Jochen > > -- > Signal: +13478504872 > PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 > https://keys.openpgp.org/search?q=EE6620C7136B0D2C456C0A4DE9E28DEA00AA5556 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Upload libloc to Debian 2023-03-02 16:19 ` Stefan Schantl @ 2023-03-02 17:26 ` Michael Tremer [not found] ` <9c740e42-cd03-428c-814a-fa8bdee99db9@guardianproject.info> 0 siblings, 1 reply; 27+ messages in thread From: Michael Tremer @ 2023-03-02 17:26 UTC (permalink / raw) To: location [-- Attachment #1: Type: text/plain, Size: 2857 bytes --] Hello everyone, HC, thank you for your contribution to our little project. If you find anything else, please feel free to send patches. And thank you Stefan for getting this into the repository. Best, -Michael > On 2 Mar 2023, at 16:19, Stefan Schantl <stefan.schantl(a)ipfire.org> wrote: > > Hello Hans-Christoph, > > a big thanks for writing and sharing your script. I've added it to the > official libloc source code by the following commit: > > ttps://git.ipfire.org/?p=location/libloc.git;a=commit;h=02a7d6ec0bb79f9 > 62ffe0746d311b3454b11a3db > > Best regards, > > -Stefan >> >> Hey all, >> >> I just uploaded a new version of the libloc Debian package that >> includes bash >> completion for the 'location' command. I would like to see this file >> included >> upstream in your git, so it is also attached to the email. >> >> If you want to try it, either install location 0.9.16-2 from Debian, >> or stick >> the attached file in /etc/bash_completion.d/location and open a new >> bash shell. >> >> .hc >> >> Jochen Sprickerhof: >>> Hi Michael, >>> >>> * Michael Tremer <michael.tremer(a)ipfire.org> [2022-08-16 10:00]: >>>>> https://buildd.debian.org/status/package.php?p=libloc >>>> >>>> I installed a virtual machine with mips64el and the testsuite >>>> weirdly runs >>>> through. >>> >>> I was able to reproduce it using ppc64el: >>> >>> # echo "deb-src http://deb.debian.org/debian unstable main" >> >>> /etc/apt/sources.list >>> # apt update >>> # apt build-dep libloc >>> # apt source --compile libloc >>> >>> Interestingly the new version now also fails on mipsel, so maybe it >>> is a flaky >>> test? >>> >>> https://buildd.debian.org/status/logs.php?pkg=libloc&arch=mipsel >>> >>> Given that it compiled before this means we should try to fix the >>> bug as it is >>> blocks testing migration, otherwise: >>> >>> https://tracker.debian.org/pkg/libloc >>> >>> (The other option would be to request removal of the old mipsel >>> version.) >>> >>>> Additionally, the packages don’t build for Debian any more using >>>> my script. >>>> >>>> I opened a bug ticket with the error here: >>>> https://bugzilla.ipfire.org/show_bug.cgi?id=12912 >>> >>> Looks like you try to cross build (installing crossbuild-essential- >>> arm64:amd64), >>> maybe that's currently broken. You can try installing qemu-user- >>> static and >>> replace --host with --arch in debian/build.sh. >>> Btw. sbuild updates the chroot before building so there should be >>> no need to >>> throw it away (for a stable release). >>> >>> Cheers Jochen >> >> -- >> Signal: +13478504872 >> PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 >> https://keys.openpgp.org/search?q=EE6620C7136B0D2C456C0A4DE9E28DEA00AA5556 > > ^ permalink raw reply [flat|nested] 27+ messages in thread
[parent not found: <9c740e42-cd03-428c-814a-fa8bdee99db9@guardianproject.info>]
* Re: Upload libloc to Debian [not found] ` <9c740e42-cd03-428c-814a-fa8bdee99db9@guardianproject.info> @ 2025-03-06 10:48 ` Michael Tremer 2025-03-10 14:32 ` Michael Tremer 0 siblings, 1 reply; 27+ messages in thread From: Michael Tremer @ 2025-03-06 10:48 UTC (permalink / raw) To: Hans-Christoph Steiner; +Cc: Stefan Schantl, Peter Müller, location Hello Hans, Thanks for your email. Yes, there has been a lot of work being going into the library in the past year. We have made huge improvements to the importer which now several orders of magnitude faster, we have added Lua bindings and generally improved stability and performance. However, I don’t remember where I have left off. Time has been running out. It would be great to have the latest changes in Debian, because Trixie is coming up fast. We should definitely have the latest version in the release whenever it will come out. Is there a deadline for all of this? I would have to squeeze a release into my schedule and first of all making sure that we are releasing good software without introducing any new problems. -Michael > On 5 Mar 2025, at 18:25, Hans-Christoph Steiner <hans@guardianproject.info> wrote: > > > Hey IPFire crew! > > I'm just looking at updating libloc in Debian. It looks like there are a lot of commits in git that are not part of a release. Do you have plans to make a release soon? > > All the best, > Hans > > Michael Tremer: >> Hello everyone, >> HC, thank you for your contribution to our little project. If you find anything else, please feel free to send patches. >> And thank you Stefan for getting this into the repository. >> Best, >> -Michael >>> On 2 Mar 2023, at 16:19, Stefan Schantl <stefan.schantl@ipfire.org> wrote: >>> >>> Hello Hans-Christoph, >>> >>> a big thanks for writing and sharing your script. I've added it to the >>> official libloc source code by the following commit: >>> >>> ttps://git.ipfire.org/?p=location/libloc.git;a=commit;h=02a7d6ec0bb79f9 >>> 62ffe0746d311b3454b11a3db >>> >>> Best regards, >>> >>> -Stefan >>>> >>>> Hey all, >>>> >>>> I just uploaded a new version of the libloc Debian package that >>>> includes bash >>>> completion for the 'location' command. I would like to see this file >>>> included >>>> upstream in your git, so it is also attached to the email. >>>> >>>> If you want to try it, either install location 0.9.16-2 from Debian, >>>> or stick >>>> the attached file in /etc/bash_completion.d/location and open a new >>>> bash shell. >>>> >>>> .hc >>>> >>>> Jochen Sprickerhof: >>>>> Hi Michael, >>>>> >>>>> * Michael Tremer <michael.tremer@ipfire.org> [2022-08-16 10:00]: >>>>>>> https://buildd.debian.org/status/package.php?p=libloc >>>>>> >>>>>> I installed a virtual machine with mips64el and the testsuite >>>>>> weirdly runs >>>>>> through. >>>>> >>>>> I was able to reproduce it using ppc64el: >>>>> >>>>> # echo "deb-src http://deb.debian.org/debian unstable main" >> >>>>> /etc/apt/sources.list >>>>> # apt update >>>>> # apt build-dep libloc >>>>> # apt source --compile libloc >>>>> >>>>> Interestingly the new version now also fails on mipsel, so maybe it >>>>> is a flaky >>>>> test? >>>>> >>>>> https://buildd.debian.org/status/logs.php?pkg=libloc&arch=mipsel >>>>> >>>>> Given that it compiled before this means we should try to fix the >>>>> bug as it is >>>>> blocks testing migration, otherwise: >>>>> >>>>> https://tracker.debian.org/pkg/libloc >>>>> >>>>> (The other option would be to request removal of the old mipsel >>>>> version.) >>>>> >>>>>> Additionally, the packages don’t build for Debian any more using >>>>>> my script. >>>>>> >>>>>> I opened a bug ticket with the error here: >>>>>> https://bugzilla.ipfire.org/show_bug.cgi?id=12912 >>>>> >>>>> Looks like you try to cross build (installing crossbuild-essential- >>>>> arm64:amd64), >>>>> maybe that's currently broken. You can try installing qemu-user- >>>>> static and >>>>> replace --host with --arch in debian/build.sh. >>>>> Btw. sbuild updates the chroot before building so there should be >>>>> no need to >>>>> throw it away (for a stable release). >>>>> >>>>> Cheers Jochen >>>> >>>> -- >>>> Signal: +13478504872 >>>> PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 >>>> https://keys.openpgp.org/search?q=EE6620C7136B0D2C456C0A4DE9E28DEA00AA5556 >>> >>> > > -- > Signal: +13478504872 > PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Upload libloc to Debian 2025-03-06 10:48 ` Michael Tremer @ 2025-03-10 14:32 ` Michael Tremer [not found] ` <6e7a9c4e-63c1-4896-bdb0-e621542ca3a7@guardianproject.info> 0 siblings, 1 reply; 27+ messages in thread From: Michael Tremer @ 2025-03-10 14:32 UTC (permalink / raw) To: Hans-Christoph Steiner; +Cc: Stefan Schantl, Peter Müller, location Hello everyone, I have a release tagged here: https://source.ipfire.org/releases/libloc/libloc-0.9.18.tar.gz https://git.ipfire.org/?p=location/libloc.git;a=shortlog;h=8cbdc19cda26d37dca354135c2825fa6a4d94ff4 Please let me know if you find any regressions. Best, -Michael > On 6 Mar 2025, at 10:48, Michael Tremer <michael.tremer@ipfire.org> wrote: > > Hello Hans, > > Thanks for your email. > > Yes, there has been a lot of work being going into the library in the past year. We have made huge improvements to the importer which now several orders of magnitude faster, we have added Lua bindings and generally improved stability and performance. However, I don’t remember where I have left off. Time has been running out. > > It would be great to have the latest changes in Debian, because Trixie is coming up fast. We should definitely have the latest version in the release whenever it will come out. > > Is there a deadline for all of this? I would have to squeeze a release into my schedule and first of all making sure that we are releasing good software without introducing any new problems. > > -Michael > >> On 5 Mar 2025, at 18:25, Hans-Christoph Steiner <hans@guardianproject.info> wrote: >> >> >> Hey IPFire crew! >> >> I'm just looking at updating libloc in Debian. It looks like there are a lot of commits in git that are not part of a release. Do you have plans to make a release soon? >> >> All the best, >> Hans >> >> Michael Tremer: >>> Hello everyone, >>> HC, thank you for your contribution to our little project. If you find anything else, please feel free to send patches. >>> And thank you Stefan for getting this into the repository. >>> Best, >>> -Michael >>>> On 2 Mar 2023, at 16:19, Stefan Schantl <stefan.schantl@ipfire.org> wrote: >>>> >>>> Hello Hans-Christoph, >>>> >>>> a big thanks for writing and sharing your script. I've added it to the >>>> official libloc source code by the following commit: >>>> >>>> ttps://git.ipfire.org/?p=location/libloc.git;a=commit;h=02a7d6ec0bb79f9 >>>> 62ffe0746d311b3454b11a3db >>>> >>>> Best regards, >>>> >>>> -Stefan >>>>> >>>>> Hey all, >>>>> >>>>> I just uploaded a new version of the libloc Debian package that >>>>> includes bash >>>>> completion for the 'location' command. I would like to see this file >>>>> included >>>>> upstream in your git, so it is also attached to the email. >>>>> >>>>> If you want to try it, either install location 0.9.16-2 from Debian, >>>>> or stick >>>>> the attached file in /etc/bash_completion.d/location and open a new >>>>> bash shell. >>>>> >>>>> .hc >>>>> >>>>> Jochen Sprickerhof: >>>>>> Hi Michael, >>>>>> >>>>>> * Michael Tremer <michael.tremer@ipfire.org> [2022-08-16 10:00]: >>>>>>>> https://buildd.debian.org/status/package.php?p=libloc >>>>>>> >>>>>>> I installed a virtual machine with mips64el and the testsuite >>>>>>> weirdly runs >>>>>>> through. >>>>>> >>>>>> I was able to reproduce it using ppc64el: >>>>>> >>>>>> # echo "deb-src http://deb.debian.org/debian unstable main" >> >>>>>> /etc/apt/sources.list >>>>>> # apt update >>>>>> # apt build-dep libloc >>>>>> # apt source --compile libloc >>>>>> >>>>>> Interestingly the new version now also fails on mipsel, so maybe it >>>>>> is a flaky >>>>>> test? >>>>>> >>>>>> https://buildd.debian.org/status/logs.php?pkg=libloc&arch=mipsel >>>>>> >>>>>> Given that it compiled before this means we should try to fix the >>>>>> bug as it is >>>>>> blocks testing migration, otherwise: >>>>>> >>>>>> https://tracker.debian.org/pkg/libloc >>>>>> >>>>>> (The other option would be to request removal of the old mipsel >>>>>> version.) >>>>>> >>>>>>> Additionally, the packages don’t build for Debian any more using >>>>>>> my script. >>>>>>> >>>>>>> I opened a bug ticket with the error here: >>>>>>> https://bugzilla.ipfire.org/show_bug.cgi?id=12912 >>>>>> >>>>>> Looks like you try to cross build (installing crossbuild-essential- >>>>>> arm64:amd64), >>>>>> maybe that's currently broken. You can try installing qemu-user- >>>>>> static and >>>>>> replace --host with --arch in debian/build.sh. >>>>>> Btw. sbuild updates the chroot before building so there should be >>>>>> no need to >>>>>> throw it away (for a stable release). >>>>>> >>>>>> Cheers Jochen >>>>> >>>>> -- >>>>> Signal: +13478504872 >>>>> PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 >>>>> https://keys.openpgp.org/search?q=EE6620C7136B0D2C456C0A4DE9E28DEA00AA5556 >>>> >>>> >> >> -- >> Signal: +13478504872 >> PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 > ^ permalink raw reply [flat|nested] 27+ messages in thread
[parent not found: <6e7a9c4e-63c1-4896-bdb0-e621542ca3a7@guardianproject.info>]
* Re: Upload libloc to Debian [not found] ` <6e7a9c4e-63c1-4896-bdb0-e621542ca3a7@guardianproject.info> @ 2025-03-19 10:41 ` Michael Tremer [not found] ` <633f6312-7914-45db-882b-cb890a6f770c@guardianproject.info> 0 siblings, 1 reply; 27+ messages in thread From: Michael Tremer @ 2025-03-19 10:41 UTC (permalink / raw) To: Hans-Christoph Steiner; +Cc: Stefan Schantl, Peter Müller, location Hello, Great! Let me know whenever I can help testing or whether you need any changes. In the meantime I have been setting up a little Jenkins pipeline which should help us to provide better releases. There could be done much more here, but for that I would require some more time i.e. funding… The current status is here: https://jenkins.ipfire.org/job/libloc/ But so far we are building for Debian, Ubuntu, Fedora and Archlinux. We are also building Debian packages for pretty much all supported architectures which are amd64, arm64, armel, armhf, i386, ppc64el, s390x. This has already helped me finding a big-endian issue which is fixed here: https://git.ipfire.org/?p=location/libloc.git;a=commitdiff;h=afc5330f56d74b4a9142b800d994d623d7cd29e8 The pipeline outputs some Debian packages. These are not supported to be used by regular users, because I would rather have the latest version of our package in the official distribution. They are however useful for testing because I can install them really quick wherever I need them. Therefore it would be great if these packages would be as close to upstream as possible so that we are actually testing the same thing. I would be happy to receive patches if you are up for that. Best, -Michael > On 19 Mar 2025, at 09:10, Hans-Christoph Steiner <hans@guardianproject.info> wrote: > > > I uploaded 0.9.17 to Debian already, and will upload 0.9.18 once 0.9.17 is in testing. After 0.9.18 makes it to testing, I'll try enabling the lua-location binary package, it looks easy. It'll have to go through the NEW queue, so it might not make it into trixie/testing. > > Michael Tremer: >> Hello everyone, >> I have a release tagged here: https://source.ipfire.org/releases/libloc/libloc-0.9.18.tar.gz >> https://git.ipfire.org/?p=location/libloc.git;a=shortlog;h=8cbdc19cda26d37dca354135c2825fa6a4d94ff4 >> Please let me know if you find any regressions. >> Best, >> -Michael >>> On 6 Mar 2025, at 10:48, Michael Tremer <michael.tremer@ipfire.org> wrote: >>> >>> Hello Hans, >>> >>> Thanks for your email. >>> >>> Yes, there has been a lot of work being going into the library in the past year. We have made huge improvements to the importer which now several orders of magnitude faster, we have added Lua bindings and generally improved stability and performance. However, I don’t remember where I have left off. Time has been running out. >>> >>> It would be great to have the latest changes in Debian, because Trixie is coming up fast. We should definitely have the latest version in the release whenever it will come out. >>> >>> Is there a deadline for all of this? I would have to squeeze a release into my schedule and first of all making sure that we are releasing good software without introducing any new problems. >>> >>> -Michael >>> >>>> On 5 Mar 2025, at 18:25, Hans-Christoph Steiner <hans@guardianproject.info> wrote: >>>> >>>> >>>> Hey IPFire crew! >>>> >>>> I'm just looking at updating libloc in Debian. It looks like there are a lot of commits in git that are not part of a release. Do you have plans to make a release soon? >>>> >>>> All the best, >>>> Hans >>>> >>>> Michael Tremer: >>>>> Hello everyone, >>>>> HC, thank you for your contribution to our little project. If you find anything else, please feel free to send patches. >>>>> And thank you Stefan for getting this into the repository. >>>>> Best, >>>>> -Michael >>>>>> On 2 Mar 2023, at 16:19, Stefan Schantl <stefan.schantl@ipfire.org> wrote: >>>>>> >>>>>> Hello Hans-Christoph, >>>>>> >>>>>> a big thanks for writing and sharing your script. I've added it to the >>>>>> official libloc source code by the following commit: >>>>>> >>>>>> ttps://git.ipfire.org/?p=location/libloc.git;a=commit;h=02a7d6ec0bb79f9 >>>>>> 62ffe0746d311b3454b11a3db >>>>>> >>>>>> Best regards, >>>>>> >>>>>> -Stefan >>>>>>> >>>>>>> Hey all, >>>>>>> >>>>>>> I just uploaded a new version of the libloc Debian package that >>>>>>> includes bash >>>>>>> completion for the 'location' command. I would like to see this file >>>>>>> included >>>>>>> upstream in your git, so it is also attached to the email. >>>>>>> >>>>>>> If you want to try it, either install location 0.9.16-2 from Debian, >>>>>>> or stick >>>>>>> the attached file in /etc/bash_completion.d/location and open a new >>>>>>> bash shell. >>>>>>> >>>>>>> .hc >>>>>>> >>>>>>> Jochen Sprickerhof: >>>>>>>> Hi Michael, >>>>>>>> >>>>>>>> * Michael Tremer <michael.tremer@ipfire.org> [2022-08-16 10:00]: >>>>>>>>>> https://buildd.debian.org/status/package.php?p=libloc >>>>>>>>> >>>>>>>>> I installed a virtual machine with mips64el and the testsuite >>>>>>>>> weirdly runs >>>>>>>>> through. >>>>>>>> >>>>>>>> I was able to reproduce it using ppc64el: >>>>>>>> >>>>>>>> # echo "deb-src http://deb.debian.org/debian unstable main" >> >>>>>>>> /etc/apt/sources.list >>>>>>>> # apt update >>>>>>>> # apt build-dep libloc >>>>>>>> # apt source --compile libloc >>>>>>>> >>>>>>>> Interestingly the new version now also fails on mipsel, so maybe it >>>>>>>> is a flaky >>>>>>>> test? >>>>>>>> >>>>>>>> https://buildd.debian.org/status/logs.php?pkg=libloc&arch=mipsel >>>>>>>> >>>>>>>> Given that it compiled before this means we should try to fix the >>>>>>>> bug as it is >>>>>>>> blocks testing migration, otherwise: >>>>>>>> >>>>>>>> https://tracker.debian.org/pkg/libloc >>>>>>>> >>>>>>>> (The other option would be to request removal of the old mipsel >>>>>>>> version.) >>>>>>>> >>>>>>>>> Additionally, the packages don’t build for Debian any more using >>>>>>>>> my script. >>>>>>>>> >>>>>>>>> I opened a bug ticket with the error here: >>>>>>>>> https://bugzilla.ipfire.org/show_bug.cgi?id=12912 >>>>>>>> >>>>>>>> Looks like you try to cross build (installing crossbuild-essential- >>>>>>>> arm64:amd64), >>>>>>>> maybe that's currently broken. You can try installing qemu-user- >>>>>>>> static and >>>>>>>> replace --host with --arch in debian/build.sh. >>>>>>>> Btw. sbuild updates the chroot before building so there should be >>>>>>>> no need to >>>>>>>> throw it away (for a stable release). >>>>>>>> >>>>>>>> Cheers Jochen >>>>>>> >>>>>>> -- >>>>>>> Signal: +13478504872 >>>>>>> PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 >>>>>>> https://keys.openpgp.org/search?q=EE6620C7136B0D2C456C0A4DE9E28DEA00AA5556 >>>>>> >>>>>> >>>> >>>> -- >>>> Signal: +13478504872 >>>> PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 >>> > > -- > Signal: +13478504872 > PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 ^ permalink raw reply [flat|nested] 27+ messages in thread
[parent not found: <633f6312-7914-45db-882b-cb890a6f770c@guardianproject.info>]
* Re: Upload libloc to Debian [not found] ` <633f6312-7914-45db-882b-cb890a6f770c@guardianproject.info> @ 2025-03-23 12:18 ` Michael Tremer 2025-03-25 18:56 ` Valters Jansons 0 siblings, 1 reply; 27+ messages in thread From: Michael Tremer @ 2025-03-23 12:18 UTC (permalink / raw) To: Hans-Christoph Steiner Cc: Stefan Schantl, Peter Müller, location, Jochen Sprickerhof Hello, > On 23 Mar 2025, at 08:31, Hans-Christoph Steiner <hans@guardianproject.info> wrote: > > Hey Michael, > > Great to hear about all your work on libloc, it is really a key package. One possibility that might streamline things is if you maintained your Debian packaging in https://salsa.debian.org/debian/libloc/ or as a fork of it. That already includes a lot of tests around the Debian package and integration: > https://salsa.debian.org/debian/libloc/-/pipelines/836918 I agree that it would be nice to get these things closer together. I however remember that there were some problems that I discussed with Jochen some long time ago and which I cannot remember any more :) Those were a mix of me having very little experience with the Debian build system, different requirements for the different releases (trixie seems to have a different package naming system for libraries) and therefore massive confusion on my part. I also have no interest in publishing any packages outside for the purpose of development, so I didn’t think it was worth to spend any time on this. Any pointers on how we can make this all go together? I believe the closer the two repositories are to each other, the less work for all of us. > Then for your CI, you could make the CI job copy the debian/ dir from that repo. And then there would be no need to maintain the debian/ dir in the libloc git repo. But how do I build my test packages then? I need to be able to make changes as well. > I uploaded 0.9.18, it is in unstable awaiting the autopkgtest run. 0.9.17 made it into trixie already. Thank you very much! Let me know if there are any problems. Looking through the files I noticed a security contact here: https://salsa.debian.org/debian/libloc/-/blob/master/debian/upstream/metadata?ref_type=heads; Could you please add security@ipfire.org <mailto:security@ipfire.org> or a note that people can check a box on Bugzilla to submit a non-public ticket? The Git repository should also be https://git.ipfire.org/?p=location/libloc.git;a=summary as I don’t think we will continue using GitHub that much longer. It only serves as a mirror with no other benefit for us. Best, -Michael > > All the best, > Hans > > Michael Tremer: >> Hello, >> Great! Let me know whenever I can help testing or whether you need any changes. >> In the meantime I have been setting up a little Jenkins pipeline which should help us to provide better releases. There could be done much more here, but for that I would require some more time i.e. funding… >> The current status is here: https://jenkins.ipfire.org/job/libloc/ >> But so far we are building for Debian, Ubuntu, Fedora and Archlinux. We are also building Debian packages for pretty much all supported architectures which are amd64, arm64, armel, armhf, i386, ppc64el, s390x. This has already helped me finding a big-endian issue which is fixed here: >> https://git.ipfire.org/?p=location/libloc.git;a=commitdiff;h=afc5330f56d74b4a9142b800d994d623d7cd29e8 >> The pipeline outputs some Debian packages. These are not supported to be used by regular users, because I would rather have the latest version of our package in the official distribution. They are however useful for testing because I can install them really quick wherever I need them. Therefore it would be great if these packages would be as close to upstream as possible so that we are actually testing the same thing. I would be happy to receive patches if you are up for that. >> Best, >> -Michael >>> On 19 Mar 2025, at 09:10, Hans-Christoph Steiner <hans@guardianproject.info> wrote: >>> >>> >>> I uploaded 0.9.17 to Debian already, and will upload 0.9.18 once 0.9.17 is in testing. After 0.9.18 makes it to testing, I'll try enabling the lua-location binary package, it looks easy. It'll have to go through the NEW queue, so it might not make it into trixie/testing. >>> >>> Michael Tremer: >>>> Hello everyone, >>>> I have a release tagged here: https://source.ipfire.org/releases/libloc/libloc-0.9.18.tar.gz >>>> https://git.ipfire.org/?p=location/libloc.git;a=shortlog;h=8cbdc19cda26d37dca354135c2825fa6a4d94ff4 >>>> Please let me know if you find any regressions. >>>> Best, >>>> -Michael >>>>> On 6 Mar 2025, at 10:48, Michael Tremer <michael.tremer@ipfire.org> wrote: >>>>> >>>>> Hello Hans, >>>>> >>>>> Thanks for your email. >>>>> >>>>> Yes, there has been a lot of work being going into the library in the past year. We have made huge improvements to the importer which now several orders of magnitude faster, we have added Lua bindings and generally improved stability and performance. However, I don’t remember where I have left off. Time has been running out. >>>>> >>>>> It would be great to have the latest changes in Debian, because Trixie is coming up fast. We should definitely have the latest version in the release whenever it will come out. >>>>> >>>>> Is there a deadline for all of this? I would have to squeeze a release into my schedule and first of all making sure that we are releasing good software without introducing any new problems. >>>>> >>>>> -Michael >>>>> >>>>>> On 5 Mar 2025, at 18:25, Hans-Christoph Steiner <hans@guardianproject.info> wrote: >>>>>> >>>>>> >>>>>> Hey IPFire crew! >>>>>> >>>>>> I'm just looking at updating libloc in Debian. It looks like there are a lot of commits in git that are not part of a release. Do you have plans to make a release soon? >>>>>> >>>>>> All the best, >>>>>> Hans >>>>>> >>>>>> Michael Tremer: >>>>>>> Hello everyone, >>>>>>> HC, thank you for your contribution to our little project. If you find anything else, please feel free to send patches. >>>>>>> And thank you Stefan for getting this into the repository. >>>>>>> Best, >>>>>>> -Michael >>>>>>>> On 2 Mar 2023, at 16:19, Stefan Schantl <stefan.schantl@ipfire.org> wrote: >>>>>>>> >>>>>>>> Hello Hans-Christoph, >>>>>>>> >>>>>>>> a big thanks for writing and sharing your script. I've added it to the >>>>>>>> official libloc source code by the following commit: >>>>>>>> >>>>>>>> ttps://git.ipfire.org/?p=location/libloc.git;a=commit;h=02a7d6ec0bb79f9 >>>>>>>> 62ffe0746d311b3454b11a3db >>>>>>>> >>>>>>>> Best regards, >>>>>>>> >>>>>>>> -Stefan >>>>>>>>> >>>>>>>>> Hey all, >>>>>>>>> >>>>>>>>> I just uploaded a new version of the libloc Debian package that >>>>>>>>> includes bash >>>>>>>>> completion for the 'location' command. I would like to see this file >>>>>>>>> included >>>>>>>>> upstream in your git, so it is also attached to the email. >>>>>>>>> >>>>>>>>> If you want to try it, either install location 0.9.16-2 from Debian, >>>>>>>>> or stick >>>>>>>>> the attached file in /etc/bash_completion.d/location and open a new >>>>>>>>> bash shell. >>>>>>>>> >>>>>>>>> .hc >>>>>>>>> >>>>>>>>> Jochen Sprickerhof: >>>>>>>>>> Hi Michael, >>>>>>>>>> >>>>>>>>>> * Michael Tremer <michael.tremer@ipfire.org> [2022-08-16 10:00]: >>>>>>>>>>>> https://buildd.debian.org/status/package.php?p=libloc >>>>>>>>>>> >>>>>>>>>>> I installed a virtual machine with mips64el and the testsuite >>>>>>>>>>> weirdly runs >>>>>>>>>>> through. >>>>>>>>>> >>>>>>>>>> I was able to reproduce it using ppc64el: >>>>>>>>>> >>>>>>>>>> # echo "deb-src http://deb.debian.org/debian unstable main" >> >>>>>>>>>> /etc/apt/sources.list >>>>>>>>>> # apt update >>>>>>>>>> # apt build-dep libloc >>>>>>>>>> # apt source --compile libloc >>>>>>>>>> >>>>>>>>>> Interestingly the new version now also fails on mipsel, so maybe it >>>>>>>>>> is a flaky >>>>>>>>>> test? >>>>>>>>>> >>>>>>>>>> https://buildd.debian.org/status/logs.php?pkg=libloc&arch=mipsel >>>>>>>>>> >>>>>>>>>> Given that it compiled before this means we should try to fix the >>>>>>>>>> bug as it is >>>>>>>>>> blocks testing migration, otherwise: >>>>>>>>>> >>>>>>>>>> https://tracker.debian.org/pkg/libloc >>>>>>>>>> >>>>>>>>>> (The other option would be to request removal of the old mipsel >>>>>>>>>> version.) >>>>>>>>>> >>>>>>>>>>> Additionally, the packages don’t build for Debian any more using >>>>>>>>>>> my script. >>>>>>>>>>> >>>>>>>>>>> I opened a bug ticket with the error here: >>>>>>>>>>> https://bugzilla.ipfire.org/show_bug.cgi?id=12912 >>>>>>>>>> >>>>>>>>>> Looks like you try to cross build (installing crossbuild-essential- >>>>>>>>>> arm64:amd64), >>>>>>>>>> maybe that's currently broken. You can try installing qemu-user- >>>>>>>>>> static and >>>>>>>>>> replace --host with --arch in debian/build.sh. >>>>>>>>>> Btw. sbuild updates the chroot before building so there should be >>>>>>>>>> no need to >>>>>>>>>> throw it away (for a stable release). >>>>>>>>>> >>>>>>>>>> Cheers Jochen >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Signal: +13478504872 >>>>>>>>> PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 >>>>>>>>> https://keys.openpgp.org/search?q=EE6620C7136B0D2C456C0A4DE9E28DEA00AA5556 >>>>>>>> >>>>>>>> >>>>>> >>>>>> -- >>>>>> Signal: +13478504872 >>>>>> PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 >>>>> >>> >>> -- >>> Signal: +13478504872 >>> PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 > > -- > Signal: +13478504872 > PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Upload libloc to Debian 2025-03-23 12:18 ` Michael Tremer @ 2025-03-25 18:56 ` Valters Jansons 2025-03-26 10:17 ` Michael Tremer 0 siblings, 1 reply; 27+ messages in thread From: Valters Jansons @ 2025-03-25 18:56 UTC (permalink / raw) To: Michael Tremer, Hans-Christoph Steiner Cc: Stefan Schantl, Peter Müller, Jochen Sprickerhof, location On Sun, Mar 23, 2025 at 2:18 PM Michael Tremer <michael.tremer@ipfire.org> wrote: > > > On 23 Mar 2025, at 08:31, Hans-Christoph Steiner <hans@guardianproject.info> wrote: > > > > I uploaded 0.9.18, it is in unstable awaiting the autopkgtest run. 0.9.17 made it into trixie already. > > Thank you very much! Let me know if there are any problems. Hans-Christoph, I opened https://salsa.debian.org/debian/libloc/-/merge_requests/3 for address endianess to be fixed (s390x failure: 10.0.0.0.in-addr.arpa. versus 0.0.0.10.in-addr.arpa.) I also opened https://salsa.debian.org/debian/libloc/-/merge_requests/2 for symbols to be fixed, resolving lintian's error. I further noticed the libloc-database watch file is not configured for filename format changes, so I opened https://salsa.debian.org/debian/libloc-database/-/merge_requests/2 for that. Let me know if you have any thoughts either in email or on the pull requests. Michael, I haven't looked further into it, but mips64el architecture failed to build due to undefined _ABIO32 and _ABIN32. If you have any proposals, they would presumably be good to include in the "upstream" project directly. The build log is visible at https://buildd.debian.org/status/fetch.php?pkg=libloc&arch=mips64el&ver=0.9.18-1&stamp=1742656796&raw=0 --Valters Jansons ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Upload libloc to Debian 2025-03-25 18:56 ` Valters Jansons @ 2025-03-26 10:17 ` Michael Tremer 2025-03-27 0:25 ` Valters Jansons 0 siblings, 1 reply; 27+ messages in thread From: Michael Tremer @ 2025-03-26 10:17 UTC (permalink / raw) To: Valters Jansons Cc: Hans-Christoph Steiner, Stefan Schantl, Peter Müller, Jochen Sprickerhof, location Hello Valters, > On 25 Mar 2025, at 18:56, Valters Jansons <valter.jansons@gmail.com> wrote: > > On Sun, Mar 23, 2025 at 2:18 PM Michael Tremer > <michael.tremer@ipfire.org> wrote: >> >>> On 23 Mar 2025, at 08:31, Hans-Christoph Steiner <hans@guardianproject.info> wrote: >>> >>> I uploaded 0.9.18, it is in unstable awaiting the autopkgtest run. 0.9.17 made it into trixie already. >> >> Thank you very much! Let me know if there are any problems. > > Hans-Christoph, I opened > https://salsa.debian.org/debian/libloc/-/merge_requests/3 for address > endianess to be fixed (s390x failure: 10.0.0.0.in-addr.arpa. versus > 0.0.0.10.in-addr.arpa.) I also opened > https://salsa.debian.org/debian/libloc/-/merge_requests/2 for symbols > to be fixed, resolving lintian's error. I further noticed the > libloc-database watch file is not configured for filename format > changes, so I opened > https://salsa.debian.org/debian/libloc-database/-/merge_requests/2 for > that. Let me know if you have any thoughts either in email or on the > pull requests. Thank you for helping to get the upstream version nice and shiny. > Michael, I haven't looked further into it, but mips64el architecture > failed to build due to undefined _ABIO32 and _ABIN32. If you have any > proposals, they would presumably be good to include in the "upstream" > project directly. The build log is visible at > https://buildd.debian.org/status/fetch.php?pkg=libloc&arch=mips64el&ver=0.9.18-1&stamp=1742656796&raw=0 Yes, this is the error that I got. I did not look further into it because I am not aware of any users of MIPS for libloc, or even as a whole. I assumed this was a problem in Python. Looking for the two constants, I am not sure which one to set, because hardcoding this would break the build for other MIPS architectures. What would you suggest to fix this? -Michael > --Valters Jansons ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Upload libloc to Debian 2025-03-26 10:17 ` Michael Tremer @ 2025-03-27 0:25 ` Valters Jansons 2025-03-27 16:39 ` Michael Tremer 0 siblings, 1 reply; 27+ messages in thread From: Valters Jansons @ 2025-03-27 0:25 UTC (permalink / raw) To: Michael Tremer, Hans-Christoph Steiner Cc: Stefan Schantl, Peter Müller, Jochen Sprickerhof, location On Wed, Mar 26, 2025 at 10:30 AM Hans-Christoph Steiner <hans@guardianproject.info> wrote: > > Valters Jansons: > > This is great! One workflow we could use is adding you to the libloc and > libloc-location projects on salsa, then you could review and merge changes > there. Then you'd just need Jochen and/or I for reviewing and uploading > releases to Debian. How does that sound? Hi Hans-Christoph, I'm not a part of the IPFire/libloc team, however I would be happy to join as a maintainer for the Debian package. I have historically maintained an Ubuntu PPA for use in my old company, and in other projects afterwards on Ubuntu 22.04 and older (before the Debian Universe package). I may have gaps in how packaging is expected, but overall I feel comfortable in moving the process forward. > Towards that end, I made a merge request to review: > https://salsa.debian.org/debian/libloc-database/-/merge_requests/3 I am wondering if the d/watch mangle rule should be changed to follow the same sed logic as in d/rules. Left a comment on the PR and can be discussed there too. Overall, it looks like a good, helpful change. On Wed, Mar 26, 2025 at 12:17 PM Michael Tremer <michael.tremer@ipfire.org> wrote: > > Hello Valters, > > Thank you for helping to get the upstream version nice and shiny. > > > Michael, I haven't looked further into it, but mips64el architecture > > failed to build due to undefined _ABIO32 and _ABIN32. If you have any > > proposals, they would presumably be good to include in the "upstream" > > project directly. The build log is visible at > > https://buildd.debian.org/status/fetch.php?pkg=libloc&arch=mips64el&ver=0.9.18-1&stamp=1742656796&raw=0 > > Yes, this is the error that I got. I did not look further into it because I am not aware of any users of MIPS for libloc, or even as a whole. > > I assumed this was a problem in Python. Looking for the two constants, I am not sure which one to set, because hardcoding this would break the build for other MIPS architectures. > > What would you suggest to fix this? Hi Michael, Debian doesn't support MIPS 32-bit variants (mips or mipsel), but it supports mips64el (64-bit little-endian). Even more so, for packages to automatically transition out of unstable, mips64el is one of the architectures expected to successfully build. I haven't seen MIPS in real life myself, but Debian tooling having this automation check is a strong argument for patching the issue. And you are correct about this being unexpected behavior in CPython. The reason it bubbled up now is the addition of -Werror=undef as a compiler flag. Previously the undefined identifiers were silently converted to zero, and _MIPS_SIM would never be zero so it was "working as expected". I am not yet 100% sure how the CPython internals get prepared, and need to investigate a bit more before contributing upstream there. What I have found is that the logic matches what is defined twice in [Misc/platform_triplet.c] as "if _MIPS_SIM == _ABIO32, elif _MIPS_SIM == _ABIN32, elif _MIPS_SIM == _ABI64". Debian's [ArchitectureSpecificsMemo] recommends using _MIPS_SIM for evaluating what the architecture is. _MIPS_SIM naming seems to be sourced from a legacy constant from decades ago, and overall seems reasonable.The _ABIO32 name however specifically seems to stem in gcc codebase from year 2003. There were libffi changes happening, and people were trying to avoid pulling in legacy headers, so gcc had a patch ["Consistently use _ABIO32 for _MIPS_SIM"] which defined _ABIO32=1 and switched to _MIPS_SIM=_ABIO32 (from some other inherited magic constant) for ABI_32. Over time as other MIPS architectures were added, it transformed into a switch/case in [config/mips/mips.h] also defining _ABIN32 for ABI_N32 (as 2), _ABI64 for ABI_64 (as 3) and _ABIO64 for ABI_O64 (as 4). The current issue comes from the fact that these are defined as compiler `builtin_define`. That means, mips64el knows about _ABI64 but doesn't know about _ABIO32 and _ABIN32. When CPython tries to use all three, two of them are undefined, so CPython should be checking whether the values are defined before trying to use them. Two solutions I can suggest now: Either downgrading -Werror=undef to -Wundef so that it raises a warning (visibility) but doesn't fail the build, or adding the magic numbers based on gcc to libloc headers, #ifndef _ABIO32 # define _ABIO32 1 #endif #ifndef _ABIN32 # define _ABIN32 2 #endif #ifndef _ABI64 # define _ABI64 3 #endif #ifndef _ABIO64 # define _ABIO64 4 #endif Both options have pros and cons, and I haven't been able to convince myself which direction I believe to be more preferable as it stands. [Misc/platform_triplet.c]: https://github.com/python/cpython/blob/v3.13.2/Misc/platform_triplet.c#L60 [ArchitectureSpecificsMemo]: https://wiki.debian.org/ArchitectureSpecificsMemo ["Consistently use _ABIO32 for _MIPS_SIM"]: https://gcc.gnu.org/legacy-ml/gcc-patches/2003-10/msg00607.html [config/mips/mips.h]: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/mips/mips.h;h=616a275b918c34caf87f333f40e00866504156d7;hb=04696df09633baf97cdbbdd6e9929b9d472161d3#l560 --Valters Jansons ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Upload libloc to Debian 2025-03-27 0:25 ` Valters Jansons @ 2025-03-27 16:39 ` Michael Tremer 2025-03-27 16:55 ` Jochen Sprickerhof [not found] ` <9068f306-8558-4913-8c4e-dad8dc0ee42d@guardianproject.info> 0 siblings, 2 replies; 27+ messages in thread From: Michael Tremer @ 2025-03-27 16:39 UTC (permalink / raw) To: Valters Jansons Cc: Hans-Christoph Steiner, Stefan Schantl, Peter Müller, Jochen Sprickerhof, location Hello Valters, > On 27 Mar 2025, at 00:25, Valters Jansons <valter.jansons@gmail.com> wrote: > > On Wed, Mar 26, 2025 at 10:30 AM Hans-Christoph Steiner > <hans@guardianproject.info> wrote: >> >> Valters Jansons: >> >> This is great! One workflow we could use is adding you to the libloc and >> libloc-location projects on salsa, then you could review and merge changes >> there. Then you'd just need Jochen and/or I for reviewing and uploading >> releases to Debian. How does that sound? > > Hi Hans-Christoph, > > I'm not a part of the IPFire/libloc team, however I would be happy to > join as a maintainer for the Debian package. > > I have historically maintained an Ubuntu PPA for use in my old > company, and in other projects afterwards on Ubuntu 22.04 and older > (before the Debian Universe package). I may have gaps in how packaging > is expected, but overall I feel comfortable in moving the process > forward. > >> Towards that end, I made a merge request to review: >> https://salsa.debian.org/debian/libloc-database/-/merge_requests/3 > > I am wondering if the d/watch mangle rule should be changed to follow > the same sed logic as in d/rules. Left a comment on the PR and can be > discussed there too. Overall, it looks like a good, helpful change. > > On Wed, Mar 26, 2025 at 12:17 PM Michael Tremer > <michael.tremer@ipfire.org> wrote: >> >> Hello Valters, >> >> Thank you for helping to get the upstream version nice and shiny. >> >>> Michael, I haven't looked further into it, but mips64el architecture >>> failed to build due to undefined _ABIO32 and _ABIN32. If you have any >>> proposals, they would presumably be good to include in the "upstream" >>> project directly. The build log is visible at >>> https://buildd.debian.org/status/fetch.php?pkg=libloc&arch=mips64el&ver=0.9.18-1&stamp=1742656796&raw=0 >> >> Yes, this is the error that I got. I did not look further into it because I am not aware of any users of MIPS for libloc, or even as a whole. >> >> I assumed this was a problem in Python. Looking for the two constants, I am not sure which one to set, because hardcoding this would break the build for other MIPS architectures. >> >> What would you suggest to fix this? > > Hi Michael, > > Debian doesn't support MIPS 32-bit variants (mips or mipsel), but it > supports mips64el (64-bit little-endian). Even more so, for packages > to automatically transition out of unstable, mips64el is one of the > architectures expected to successfully build. I haven't seen MIPS in > real life myself, but Debian tooling having this automation check is a > strong argument for patching the issue. Generally I am all in favour of having the library build for as many things as possible. Usually any problems (e.g. like the recent endianness issue) propagate across multiple architectures. Sometimes however, some niche problem exists in some niche architecture. I am currently incredibly stretched with my own time, and therefore there is not a very good idea to spend it all on some niche problem where we probably won’t have any users anyways. I am trying to find a happy balance here. > And you are correct about this being unexpected behavior in CPython. > The reason it bubbled up now is the addition of -Werror=undef as a > compiler flag. Previously the undefined identifiers were silently > converted to zero, and _MIPS_SIM would never be zero so it was > "working as expected". I agree that this would abort the build. However, the problem is not exactly in my code :) I would have expected the compiler to define those values depending on the output architecture. > I am not yet 100% sure how the CPython internals get prepared, and > need to investigate a bit more before contributing upstream there. > What I have found is that the logic matches what is defined twice in > [Misc/platform_triplet.c] as "if _MIPS_SIM == _ABIO32, elif _MIPS_SIM > == _ABIN32, elif _MIPS_SIM == _ABI64". Debian's > [ArchitectureSpecificsMemo] recommends using _MIPS_SIM for evaluating > what the architecture is. > > _MIPS_SIM naming seems to be sourced from a legacy constant from > decades ago, and overall seems reasonable.The _ABIO32 name however > specifically seems to stem in gcc codebase from year 2003. There were > libffi changes happening, and people were trying to avoid pulling in > legacy headers, so gcc had a patch ["Consistently use _ABIO32 for > _MIPS_SIM"] which defined _ABIO32=1 and switched to _MIPS_SIM=_ABIO32 > (from some other inherited magic constant) for ABI_32. Over time as > other MIPS architectures were added, it transformed into a switch/case > in [config/mips/mips.h] also defining _ABIN32 for ABI_N32 (as 2), > _ABI64 for ABI_64 (as 3) and _ABIO64 for ABI_O64 (as 4). > > The current issue comes from the fact that these are defined as > compiler `builtin_define`. That means, mips64el knows about _ABI64 but > doesn't know about _ABIO32 and _ABIN32. When CPython tries to use all > three, two of them are undefined, so CPython should be checking > whether the values are defined before trying to use them. > > Two solutions I can suggest now: Either downgrading -Werror=undef to > -Wundef so that it raises a warning (visibility) but doesn't fail the > build, or adding the magic numbers based on gcc to libloc headers, > > #ifndef _ABIO32 > # define _ABIO32 1 > #endif > #ifndef _ABIN32 > # define _ABIN32 2 > #endif > #ifndef _ABI64 > # define _ABI64 3 > #endif > #ifndef _ABIO64 > # define _ABIO64 4 > #endif So it seems that all those values are somewhat defined, because if I add it to the compiler command line, I am getting this: In file included from <command-line>: ././config.h:224: warning: "_ABI64" redefined 224 | #define _ABI64 1 > Both options have pros and cons, and I haven't been able to convince > myself which direction I believe to be more preferable as it stands. > > [Misc/platform_triplet.c]: > https://github.com/python/cpython/blob/v3.13.2/Misc/platform_triplet.c#L60 > [ArchitectureSpecificsMemo]: https://wiki.debian.org/ArchitectureSpecificsMemo > ["Consistently use _ABIO32 for _MIPS_SIM"]: > https://gcc.gnu.org/legacy-ml/gcc-patches/2003-10/msg00607.html > [config/mips/mips.h]: > https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/mips/mips.h;h=616a275b918c34caf87f333f40e00866504156d7;hb=04696df09633baf97cdbbdd6e9929b9d472161d3#l560 On trixie, there is an additional problem where the build dependencies cannot be installed: Setting up python3.13-minimal:mips64el (3.13.2-2) ... /var/lib/dpkg/info/python3.13-minimal.postinst: 51: /usr/bin/python3.13: Exec format error dpkg: error processing package python3.13-minimal:mips64el (--configure): installed python3.13-minimal:mips64el package post-installation script subprocess returned error exit status 126 Errors were encountered while processing: python3.13-minimal:mips64el E: Sub-process /usr/bin/dpkg returned an error code (1) E: Failed to process build dependencies script returned exit code 100 Obviously this is emulated, but qemu-user-static is generally available for mips64el. Given all these problems, I would be happy to receive patches, but I don’t think I have enough experience and time to poke around here. I am happy to assist though. Best, -Michael > --Valters Jansons ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Upload libloc to Debian 2025-03-27 16:39 ` Michael Tremer @ 2025-03-27 16:55 ` Jochen Sprickerhof 2025-03-28 12:39 ` Michael Tremer [not found] ` <9068f306-8558-4913-8c4e-dad8dc0ee42d@guardianproject.info> 1 sibling, 1 reply; 27+ messages in thread From: Jochen Sprickerhof @ 2025-03-27 16:55 UTC (permalink / raw) To: location [-- Attachment #1: Type: text/plain, Size: 840 bytes --] Hi Michael, * Michael Tremer <michael.tremer@ipfire.org> [2025-03-27 16:39]: >On trixie, there is an additional problem where the build dependencies cannot be installed: > >Setting up python3.13-minimal:mips64el (3.13.2-2) ... >/var/lib/dpkg/info/python3.13-minimal.postinst: 51: /usr/bin/python3.13: Exec format error >dpkg: error processing package python3.13-minimal:mips64el (--configure): >installed python3.13-minimal:mips64el package post-installation script subprocess returned error exit status 126 >Errors were encountered while processing: >python3.13-minimal:mips64el >E: Sub-process /usr/bin/dpkg returned an error code (1) >E: Failed to process build dependencies >script returned exit code 100 On trixie try: sbuild --chroot-mode=unshare --anything-failed-commands=%s --arch=mips64el --dist=unstable libloc Cheers Jochen [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Upload libloc to Debian 2025-03-27 16:55 ` Jochen Sprickerhof @ 2025-03-28 12:39 ` Michael Tremer 0 siblings, 0 replies; 27+ messages in thread From: Michael Tremer @ 2025-03-28 12:39 UTC (permalink / raw) To: Jochen Sprickerhof; +Cc: location Thank you. My build system is currently running bookworm :( > On 27 Mar 2025, at 16:55, Jochen Sprickerhof <libloc@jochen.sprickerhof.de> wrote: > > Hi Michael, > > * Michael Tremer <michael.tremer@ipfire.org> [2025-03-27 16:39]: >> On trixie, there is an additional problem where the build dependencies cannot be installed: >> >> Setting up python3.13-minimal:mips64el (3.13.2-2) ... >> /var/lib/dpkg/info/python3.13-minimal.postinst: 51: /usr/bin/python3.13: Exec format error >> dpkg: error processing package python3.13-minimal:mips64el (--configure): >> installed python3.13-minimal:mips64el package post-installation script subprocess returned error exit status 126 >> Errors were encountered while processing: >> python3.13-minimal:mips64el >> E: Sub-process /usr/bin/dpkg returned an error code (1) >> E: Failed to process build dependencies >> script returned exit code 100 > > On trixie try: > > sbuild --chroot-mode=unshare --anything-failed-commands=%s --arch=mips64el --dist=unstable libloc > > Cheers Jochen ^ permalink raw reply [flat|nested] 27+ messages in thread
[parent not found: <9068f306-8558-4913-8c4e-dad8dc0ee42d@guardianproject.info>]
* Re: Upload libloc to Debian [not found] ` <9068f306-8558-4913-8c4e-dad8dc0ee42d@guardianproject.info> @ 2025-03-28 13:02 ` Michael Tremer [not found] ` <3209250b-4bb9-42f1-89d2-63ac86085148@guardianproject.info> 1 sibling, 0 replies; 27+ messages in thread From: Michael Tremer @ 2025-03-28 13:02 UTC (permalink / raw) To: Hans-Christoph Steiner Cc: Valters Jansons, Stefan Schantl, Peter Müller, Jochen Sprickerhof, location Hello HC, > On 27 Mar 2025, at 17:22, Hans-Christoph Steiner <hans@guardianproject.info> wrote: > > Michael, if you think libloc on mips64el has no real userbase, then we can update the package to have looser requirements there. I have done this on other packages, its kosher to do in this kind of situation. I think I was talking bollocks here. I assumed that in bookworm, we did not have a package for mips64el, but we do. If we didn’t I would have expected that sooner or later someone would come and ask for it. Preferably we support all architectures that Debian supports. As a user of non-amd64, it was always super annoying if some package was missing. So I don’t want to be *that guy*. However, as stated before, sometimes those problems are not the easiest to solve... > Valters, if everyone is OK with it, I'd add you as a "Developer" on the projects on Salsa. Then you can review and merge things to the packages. > > >>> Towards that end, I made a merge request to review: >>> https://salsa.debian.org/debian/libloc-database/-/merge_requests/3 >> I am wondering if the d/watch mangle rule should be changed to follow >> the same sed logic as in d/rules. Left a comment on the PR and can be >> discussed there too. Overall, it looks like a good, helpful change. > > I had the same thought, if that works for you, I think that would be a better approach. > > .hc > > Michael Tremer: >> Hello Valters, >>> On 27 Mar 2025, at 00:25, Valters Jansons <valter.jansons@gmail.com> wrote: >>> >>> On Wed, Mar 26, 2025 at 10:30 AM Hans-Christoph Steiner >>> <hans@guardianproject.info> wrote: >>>> >>>> Valters Jansons: >>>> >>>> This is great! One workflow we could use is adding you to the libloc and >>>> libloc-location projects on salsa, then you could review and merge changes >>>> there. Then you'd just need Jochen and/or I for reviewing and uploading >>>> releases to Debian. How does that sound? >>> >>> Hi Hans-Christoph, >>> >>> I'm not a part of the IPFire/libloc team, however I would be happy to >>> join as a maintainer for the Debian package. >>> >>> I have historically maintained an Ubuntu PPA for use in my old >>> company, and in other projects afterwards on Ubuntu 22.04 and older >>> (before the Debian Universe package). I may have gaps in how packaging >>> is expected, but overall I feel comfortable in moving the process >>> forward. >>> >>>> Towards that end, I made a merge request to review: >>>> https://salsa.debian.org/debian/libloc-database/-/merge_requests/3 >>> >>> I am wondering if the d/watch mangle rule should be changed to follow >>> the same sed logic as in d/rules. Left a comment on the PR and can be >>> discussed there too. Overall, it looks like a good, helpful change. >>> >>> On Wed, Mar 26, 2025 at 12:17 PM Michael Tremer >>> <michael.tremer@ipfire.org> wrote: >>>> >>>> Hello Valters, >>>> >>>> Thank you for helping to get the upstream version nice and shiny. >>>> >>>>> Michael, I haven't looked further into it, but mips64el architecture >>>>> failed to build due to undefined _ABIO32 and _ABIN32. If you have any >>>>> proposals, they would presumably be good to include in the "upstream" >>>>> project directly. The build log is visible at >>>>> https://buildd.debian.org/status/fetch.php?pkg=libloc&arch=mips64el&ver=0.9.18-1&stamp=1742656796&raw=0 >>>> >>>> Yes, this is the error that I got. I did not look further into it because I am not aware of any users of MIPS for libloc, or even as a whole. >>>> >>>> I assumed this was a problem in Python. Looking for the two constants, I am not sure which one to set, because hardcoding this would break the build for other MIPS architectures. >>>> >>>> What would you suggest to fix this? >>> >>> Hi Michael, >>> >>> Debian doesn't support MIPS 32-bit variants (mips or mipsel), but it >>> supports mips64el (64-bit little-endian). Even more so, for packages >>> to automatically transition out of unstable, mips64el is one of the >>> architectures expected to successfully build. I haven't seen MIPS in >>> real life myself, but Debian tooling having this automation check is a >>> strong argument for patching the issue. >> Generally I am all in favour of having the library build for as many things as possible. Usually any problems (e.g. like the recent endianness issue) propagate across multiple architectures. >> Sometimes however, some niche problem exists in some niche architecture. I am currently incredibly stretched with my own time, and therefore there is not a very good idea to spend it all on some niche problem where we probably won’t have any users anyways. I am trying to find a happy balance here. >>> And you are correct about this being unexpected behavior in CPython. >>> The reason it bubbled up now is the addition of -Werror=undef as a >>> compiler flag. Previously the undefined identifiers were silently >>> converted to zero, and _MIPS_SIM would never be zero so it was >>> "working as expected". >> I agree that this would abort the build. However, the problem is not exactly in my code :) >> I would have expected the compiler to define those values depending on the output architecture. >>> I am not yet 100% sure how the CPython internals get prepared, and >>> need to investigate a bit more before contributing upstream there. >>> What I have found is that the logic matches what is defined twice in >>> [Misc/platform_triplet.c] as "if _MIPS_SIM == _ABIO32, elif _MIPS_SIM >>> == _ABIN32, elif _MIPS_SIM == _ABI64". Debian's >>> [ArchitectureSpecificsMemo] recommends using _MIPS_SIM for evaluating >>> what the architecture is. >>> >>> _MIPS_SIM naming seems to be sourced from a legacy constant from >>> decades ago, and overall seems reasonable.The _ABIO32 name however >>> specifically seems to stem in gcc codebase from year 2003. There were >>> libffi changes happening, and people were trying to avoid pulling in >>> legacy headers, so gcc had a patch ["Consistently use _ABIO32 for >>> _MIPS_SIM"] which defined _ABIO32=1 and switched to _MIPS_SIM=_ABIO32 >>> (from some other inherited magic constant) for ABI_32. Over time as >>> other MIPS architectures were added, it transformed into a switch/case >>> in [config/mips/mips.h] also defining _ABIN32 for ABI_N32 (as 2), >>> _ABI64 for ABI_64 (as 3) and _ABIO64 for ABI_O64 (as 4). >>> >>> The current issue comes from the fact that these are defined as >>> compiler `builtin_define`. That means, mips64el knows about _ABI64 but >>> doesn't know about _ABIO32 and _ABIN32. When CPython tries to use all >>> three, two of them are undefined, so CPython should be checking >>> whether the values are defined before trying to use them. >>> >>> Two solutions I can suggest now: Either downgrading -Werror=undef to >>> -Wundef so that it raises a warning (visibility) but doesn't fail the >>> build, or adding the magic numbers based on gcc to libloc headers, >>> >>> #ifndef _ABIO32 >>> # define _ABIO32 1 >>> #endif >>> #ifndef _ABIN32 >>> # define _ABIN32 2 >>> #endif >>> #ifndef _ABI64 >>> # define _ABI64 3 >>> #endif >>> #ifndef _ABIO64 >>> # define _ABIO64 4 >>> #endif >> So it seems that all those values are somewhat defined, because if I add it to the compiler command line, I am getting this: >> In file included from <command-line>: >> ././config.h:224: warning: "_ABI64" redefined >> 224 | #define _ABI64 1 >>> Both options have pros and cons, and I haven't been able to convince >>> myself which direction I believe to be more preferable as it stands. >>> >>> [Misc/platform_triplet.c]: >>> https://github.com/python/cpython/blob/v3.13.2/Misc/platform_triplet.c#L60 >>> [ArchitectureSpecificsMemo]: https://wiki.debian.org/ArchitectureSpecificsMemo >>> ["Consistently use _ABIO32 for _MIPS_SIM"]: >>> https://gcc.gnu.org/legacy-ml/gcc-patches/2003-10/msg00607.html >>> [config/mips/mips.h]: >>> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/mips/mips.h;h=616a275b918c34caf87f333f40e00866504156d7;hb=04696df09633baf97cdbbdd6e9929b9d472161d3#l560 >> On trixie, there is an additional problem where the build dependencies cannot be installed: >> Setting up python3.13-minimal:mips64el (3.13.2-2) ... >> /var/lib/dpkg/info/python3.13-minimal.postinst: 51: /usr/bin/python3.13: Exec format error >> dpkg: error processing package python3.13-minimal:mips64el (--configure): >> installed python3.13-minimal:mips64el package post-installation script subprocess returned error exit status 126 >> Errors were encountered while processing: >> python3.13-minimal:mips64el >> E: Sub-process /usr/bin/dpkg returned an error code (1) >> E: Failed to process build dependencies >> script returned exit code 100 >> Obviously this is emulated, but qemu-user-static is generally available for mips64el. >> Given all these problems, I would be happy to receive patches, but I don’t think I have enough experience and time to poke around here. I am happy to assist though. >> Best, >> -Michael >>> --Valters Jansons > > -- > Signal: +13478504872 > PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 ^ permalink raw reply [flat|nested] 27+ messages in thread
[parent not found: <3209250b-4bb9-42f1-89d2-63ac86085148@guardianproject.info>]
* Re: Upload libloc to Debian [not found] ` <3209250b-4bb9-42f1-89d2-63ac86085148@guardianproject.info> @ 2025-03-28 13:05 ` Michael Tremer 0 siblings, 0 replies; 27+ messages in thread From: Michael Tremer @ 2025-03-28 13:05 UTC (permalink / raw) To: Hans-Christoph Steiner Cc: Valters Jansons, Stefan Schantl, Peter Müller, Jochen Sprickerhof, location Hello, I would once again need help with this. In our configure script we are asking the system where it would like its Lua stuff: https://git.ipfire.org/?p=location/libloc.git;a=blob;f=configure.ac;h=1fae3a336f7a4e9165f9cca56e60c8c25476bab3;hb=HEAD#l231 I have been searching for documentation on how to handle this on Debian as most packages are actually built for multiple versions of Lua. I could not find out whether that is legacy stuff or actual policy and what would be the best in our case. On my system the Lua interpreter finds the module, so it cannot be that wrong :) Is there anyone from the Lua team we could contact? -Michael > On 28 Mar 2025, at 11:01, Hans-Christoph Steiner <hans@guardianproject.info> wrote: > > > There seems to be some issues with the lua-location library, my autotools is very rusty these days: > https://salsa.debian.org/debian/libloc/-/jobs/7328277 > > E: lua-location: non-empty-dependency_libs-in-la-file /usr/lib/x86_64-linux-gnu/libloc.la -lssl -lcrypto -llua5.4 -lresolv [usr/lib/x86_64-linux-gnu/lua/5.4/location.la:20] > W: libloc source: autotools-pkg-config-macro-not-cross-compilation-safe AC_PATH_PROG [configure.ac:217] > > Hans-Christoph Steiner: >> Michael, if you think libloc on mips64el has no real userbase, then we can update the package to have looser requirements there. I have done this on other packages, its kosher to do in this kind of situation. >> Valters, if everyone is OK with it, I'd add you as a "Developer" on the projects on Salsa. Then you can review and merge things to the packages. >>>> Towards that end, I made a merge request to review: >>>> https://salsa.debian.org/debian/libloc-database/-/merge_requests/3 >>> >>> I am wondering if the d/watch mangle rule should be changed to follow >>> the same sed logic as in d/rules. Left a comment on the PR and can be >>> discussed there too. Overall, it looks like a good, helpful change. >> I had the same thought, if that works for you, I think that would be a better approach. >> .hc >> Michael Tremer: >>> Hello Valters, >>> >>>> On 27 Mar 2025, at 00:25, Valters Jansons <valter.jansons@gmail.com> wrote: >>>> >>>> On Wed, Mar 26, 2025 at 10:30 AM Hans-Christoph Steiner >>>> <hans@guardianproject.info> wrote: >>>>> >>>>> Valters Jansons: >>>>> >>>>> This is great! One workflow we could use is adding you to the libloc and >>>>> libloc-location projects on salsa, then you could review and merge changes >>>>> there. Then you'd just need Jochen and/or I for reviewing and uploading >>>>> releases to Debian. How does that sound? >>>> >>>> Hi Hans-Christoph, >>>> >>>> I'm not a part of the IPFire/libloc team, however I would be happy to >>>> join as a maintainer for the Debian package. >>>> >>>> I have historically maintained an Ubuntu PPA for use in my old >>>> company, and in other projects afterwards on Ubuntu 22.04 and older >>>> (before the Debian Universe package). I may have gaps in how packaging >>>> is expected, but overall I feel comfortable in moving the process >>>> forward. >>>> >>>>> Towards that end, I made a merge request to review: >>>>> https://salsa.debian.org/debian/libloc-database/-/merge_requests/3 >>>> >>>> I am wondering if the d/watch mangle rule should be changed to follow >>>> the same sed logic as in d/rules. Left a comment on the PR and can be >>>> discussed there too. Overall, it looks like a good, helpful change. >>>> >>>> On Wed, Mar 26, 2025 at 12:17 PM Michael Tremer >>>> <michael.tremer@ipfire.org> wrote: >>>>> >>>>> Hello Valters, >>>>> >>>>> Thank you for helping to get the upstream version nice and shiny. >>>>> >>>>>> Michael, I haven't looked further into it, but mips64el architecture >>>>>> failed to build due to undefined _ABIO32 and _ABIN32. If you have any >>>>>> proposals, they would presumably be good to include in the "upstream" >>>>>> project directly. The build log is visible at >>>>>> https://buildd.debian.org/status/fetch.php? pkg=libloc&arch=mips64el&ver=0.9.18-1&stamp=1742656796&raw=0 >>>>> >>>>> Yes, this is the error that I got. I did not look further into it because I am not aware of any users of MIPS for libloc, or even as a whole. >>>>> >>>>> I assumed this was a problem in Python. Looking for the two constants, I am not sure which one to set, because hardcoding this would break the build for other MIPS architectures. >>>>> >>>>> What would you suggest to fix this? >>>> >>>> Hi Michael, >>>> >>>> Debian doesn't support MIPS 32-bit variants (mips or mipsel), but it >>>> supports mips64el (64-bit little-endian). Even more so, for packages >>>> to automatically transition out of unstable, mips64el is one of the >>>> architectures expected to successfully build. I haven't seen MIPS in >>>> real life myself, but Debian tooling having this automation check is a >>>> strong argument for patching the issue. >>> >>> Generally I am all in favour of having the library build for as many things as possible. Usually any problems (e.g. like the recent endianness issue) propagate across multiple architectures. >>> >>> Sometimes however, some niche problem exists in some niche architecture. I am currently incredibly stretched with my own time, and therefore there is not a very good idea to spend it all on some niche problem where we probably won’t have any users anyways. I am trying to find a happy balance here. >>> >>>> And you are correct about this being unexpected behavior in CPython. >>>> The reason it bubbled up now is the addition of -Werror=undef as a >>>> compiler flag. Previously the undefined identifiers were silently >>>> converted to zero, and _MIPS_SIM would never be zero so it was >>>> "working as expected". >>> >>> I agree that this would abort the build. However, the problem is not exactly in my code :) >>> >>> I would have expected the compiler to define those values depending on the output architecture. >>> >>>> I am not yet 100% sure how the CPython internals get prepared, and >>>> need to investigate a bit more before contributing upstream there. >>>> What I have found is that the logic matches what is defined twice in >>>> [Misc/platform_triplet.c] as "if _MIPS_SIM == _ABIO32, elif _MIPS_SIM >>>> == _ABIN32, elif _MIPS_SIM == _ABI64". Debian's >>>> [ArchitectureSpecificsMemo] recommends using _MIPS_SIM for evaluating >>>> what the architecture is. >>>> >>>> _MIPS_SIM naming seems to be sourced from a legacy constant from >>>> decades ago, and overall seems reasonable.The _ABIO32 name however >>>> specifically seems to stem in gcc codebase from year 2003. There were >>>> libffi changes happening, and people were trying to avoid pulling in >>>> legacy headers, so gcc had a patch ["Consistently use _ABIO32 for >>>> _MIPS_SIM"] which defined _ABIO32=1 and switched to _MIPS_SIM=_ABIO32 >>>> (from some other inherited magic constant) for ABI_32. Over time as >>>> other MIPS architectures were added, it transformed into a switch/case >>>> in [config/mips/mips.h] also defining _ABIN32 for ABI_N32 (as 2), >>>> _ABI64 for ABI_64 (as 3) and _ABIO64 for ABI_O64 (as 4). >>>> >>>> The current issue comes from the fact that these are defined as >>>> compiler `builtin_define`. That means, mips64el knows about _ABI64 but >>>> doesn't know about _ABIO32 and _ABIN32. When CPython tries to use all >>>> three, two of them are undefined, so CPython should be checking >>>> whether the values are defined before trying to use them. >>>> >>>> Two solutions I can suggest now: Either downgrading -Werror=undef to >>>> -Wundef so that it raises a warning (visibility) but doesn't fail the >>>> build, or adding the magic numbers based on gcc to libloc headers, >>>> >>>> #ifndef _ABIO32 >>>> # define _ABIO32 1 >>>> #endif >>>> #ifndef _ABIN32 >>>> # define _ABIN32 2 >>>> #endif >>>> #ifndef _ABI64 >>>> # define _ABI64 3 >>>> #endif >>>> #ifndef _ABIO64 >>>> # define _ABIO64 4 >>>> #endif >>> >>> So it seems that all those values are somewhat defined, because if I add it to the compiler command line, I am getting this: >>> >>> In file included from <command-line>: >>> ././config.h:224: warning: "_ABI64" redefined >>> 224 | #define _ABI64 1 >>> >>>> Both options have pros and cons, and I haven't been able to convince >>>> myself which direction I believe to be more preferable as it stands. >>>> >>>> [Misc/platform_triplet.c]: >>>> https://github.com/python/cpython/blob/v3.13.2/Misc/platform_triplet.c#L60 >>>> [ArchitectureSpecificsMemo]: https://wiki.debian.org/ArchitectureSpecificsMemo >>>> ["Consistently use _ABIO32 for _MIPS_SIM"]: >>>> https://gcc.gnu.org/legacy-ml/gcc-patches/2003-10/msg00607.html >>>> [config/mips/mips.h]: >>>> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/mips/ mips.h;h=616a275b918c34caf87f333f40e00866504156d7;hb=04696df09633baf97cdbbdd6e9929b9d472161d3#l560 >>> >>> On trixie, there is an additional problem where the build dependencies cannot be installed: >>> >>> Setting up python3.13-minimal:mips64el (3.13.2-2) ... >>> /var/lib/dpkg/info/python3.13-minimal.postinst: 51: /usr/bin/python3.13: Exec format error >>> dpkg: error processing package python3.13-minimal:mips64el (--configure): >>> installed python3.13-minimal:mips64el package post-installation script subprocess returned error exit status 126 >>> Errors were encountered while processing: >>> python3.13-minimal:mips64el >>> E: Sub-process /usr/bin/dpkg returned an error code (1) >>> E: Failed to process build dependencies >>> script returned exit code 100 >>> >>> Obviously this is emulated, but qemu-user-static is generally available for mips64el. >>> >>> Given all these problems, I would be happy to receive patches, but I don’t think I have enough experience and time to poke around here. I am happy to assist though. >>> >>> Best, >>> -Michael >>> >>>> --Valters Jansons > > -- > Signal: +13478504872 > PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2025-03-28 13:05 UTC | newest]
Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <82DB10C8-A848-42EF-B395-3E27205E81D8@ipfire.org>
2022-07-02 6:57 ` Upload libloc to Debian Jochen Sprickerhof
2022-07-05 14:28 ` Michael Tremer
2022-07-06 7:41 ` Jochen Sprickerhof
2022-07-06 8:29 ` Michael Tremer
2022-07-07 5:46 ` Jochen Sprickerhof
2022-07-08 9:13 ` Michael Tremer
2022-07-08 9:58 ` Jochen Sprickerhof
2022-07-08 11:02 ` Michael Tremer
2022-07-08 12:56 ` Jochen Sprickerhof
2022-07-13 12:12 ` Michael Tremer
2022-07-22 21:06 ` Jochen Sprickerhof
2022-08-16 9:00 ` Michael Tremer
2022-08-17 13:17 ` Jochen Sprickerhof
[not found] ` <048f09d9-9985-a356-fed1-4cd8e286b87e@guardianproject.info>
2023-03-02 16:19 ` Stefan Schantl
2023-03-02 17:26 ` Michael Tremer
[not found] ` <9c740e42-cd03-428c-814a-fa8bdee99db9@guardianproject.info>
2025-03-06 10:48 ` Michael Tremer
2025-03-10 14:32 ` Michael Tremer
[not found] ` <6e7a9c4e-63c1-4896-bdb0-e621542ca3a7@guardianproject.info>
2025-03-19 10:41 ` Michael Tremer
[not found] ` <633f6312-7914-45db-882b-cb890a6f770c@guardianproject.info>
2025-03-23 12:18 ` Michael Tremer
2025-03-25 18:56 ` Valters Jansons
2025-03-26 10:17 ` Michael Tremer
2025-03-27 0:25 ` Valters Jansons
2025-03-27 16:39 ` Michael Tremer
2025-03-27 16:55 ` Jochen Sprickerhof
2025-03-28 12:39 ` Michael Tremer
[not found] ` <9068f306-8558-4913-8c4e-dad8dc0ee42d@guardianproject.info>
2025-03-28 13:02 ` Michael Tremer
[not found] ` <3209250b-4bb9-42f1-89d2-63ac86085148@guardianproject.info>
2025-03-28 13:05 ` Michael Tremer
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox