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