Package for Debian/Ubuntu

pantierra commented

2021-05-09 10:35:28 +00:00

(Migrated from github.com)

There is no good FOSS offline map app for the Linux desktop. Organic Maps contains instructions on how to build this app for the desktop. Wondering if it would make sense to package Organic Apps for Debian and make it available for this Operating System and its derivates such as Ubuntu, etc? It seems this would fill a gap and it also makes sense the more hardware like Pinephones are around that build on more regular Linux systems.

Dear maintainers, do you think this would be desirable and feasible?

Thanks for the great work on providing a truly free and respectful OpenStreetMap based vector map app!

There is no good FOSS offline map app for the Linux desktop. Organic Maps contains instructions on how to build this app for the desktop. Wondering if it would make sense to package Organic Apps for Debian and make it available for this Operating System and its derivates such as Ubuntu, etc? It seems this would fill a gap and it also makes sense the more hardware like Pinephones are around that build on more regular Linux systems. Dear maintainers, do you think this would be desirable and feasible? Thanks for the great work on providing a truly free and respectful OpenStreetMap based vector map app!

👍 2 ❤️ 22

rtsisyk commented

2021-05-09 10:54:07 +00:00

Owner

Hi @xamanu, thank you for your interest to this project!

We are not focusing on the desktop version, but if somebody can contribute and maintain the Debian package it would be great. There was another request for a desktop version, please collaborate with @KAMiKAZOW.

Hi @xamanu, thank you for your interest to this project! We are not focusing on the desktop version, but if somebody can contribute and maintain the Debian package it would be great. There was [another request](https://github.com/organicmaps/organicmaps/discussions/375) for a desktop version, please collaborate with @KAMiKAZOW.

pantierra commented

2021-05-09 11:59:31 +00:00

(Migrated from github.com)

I'm going to build and have a look on it on the desktop. If it runs nicely on a Linux system, I will consider supporting the packaging (related Debian "bug"). Just to be clear, I don't have commits right on Debian, I've just lately been loosely contributing with the Debian GIS Team. In any case, I'm very excited about the effort you are doing with Organic Maps!

I'm going to build and have a look on it on the desktop. If it runs nicely on a Linux system, I will consider supporting the packaging (related [Debian "bug"](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986232)). Just to be clear, I don't have commits right on Debian, I've just lately been loosely contributing with the [Debian GIS Team](https://debian-gis-team.pages.debian.net/). In any case, I'm very excited about the effort you are doing with Organic Maps!

❤️ 1

KAMiKAZOW commented

2021-05-09 15:38:26 +00:00

(Migrated from github.com)

please collaborate with @KAMiKAZOW.

Huh? Where did you get the impression that I have any interest in Ubuntu?

> please collaborate with @KAMiKAZOW. Huh? Where did you get the impression that I have any interest in Ubuntu?

pantierra commented

2021-05-10 12:59:57 +00:00

(Migrated from github.com)

Currently, the software is not working perfectly on a Linux desktop, yet. And data download is being done via a private URL.

For me the two big questions would be:

are maintainers interested (at some time - no rush; no pressure!) to actively support a desktop build, in terms of fixing bugs, etc.? or is this out of scope?
how do maintainers envision data consumption of the desktop program (currently, the route to the data download, is not part of the source code and hold private)?

Currently, the software is not working perfectly on a Linux desktop, yet. And data download is being done via a private URL. For me the two big questions would be: * are maintainers interested (at some time - no rush; no pressure!) to actively support a desktop build, in terms of fixing bugs, etc.? or is this out of scope? * how do maintainers envision data consumption of the desktop program (currently, the route to the data download, is not part of the source code and hold private)?

rtsisyk commented

2021-05-11 10:04:56 +00:00

Owner

are maintainers interested (at some time - no rush; no pressure!) to actively support a desktop build, in terms of fixing bugs, etc.? or is this out of scope?

We are mostly focused on improving the mobile app, but you are welcome to send bug fixes for the desktop part.

how do maintainers envision data consumption of the desktop program (currently, the route to the data download, is not part of the source code and hold private)?

We will publish the server address soon.

>are maintainers interested (at some time - no rush; no pressure!) to actively support a desktop build, in terms of fixing bugs, etc.? or is this out of scope? We are mostly focused on improving the mobile app, but you are welcome to send bug fixes for the desktop part. >how do maintainers envision data consumption of the desktop program (currently, the route to the data download, is not part of the source code and hold private)? We will publish the server address soon.

👍 3

rtsisyk commented

2021-05-13 07:41:40 +00:00

Owner

See organicmaps/organicmaps#398

See https://git.omaps.dev/organicmaps/organicmaps/pulls/398

❤️ 2

fgaz commented

2021-05-16 16:43:30 +00:00

(Migrated from github.com)

Thanks for the great work on providing a truly free and respectful OpenStreetMap based vector map app!

seconding this!

I just packaged this software for NixOS, so here's some more info for other packagers & feedback for the project:

I had to disable tools/unix/check_cert.sh since it's dependent on time and affects reproducible builds
I applied #418
I see that lots of dependencies are vendored. It'd be nice to be able to link to the system ones, even just because of the build times (icu in particular takes a lot)
I had to manually install the OMaps binary, the data directory, and the icon and desktop files, in addition to running the normal ninja/make install.
- it'd be nice if install statements for those items were added in the cmake files. I'd make a patch myself, but I'm not very familiar with cmake.
I removed the xmlfw executable that was automatically installed, since it looks like OMaps does not need it (it only uses the library) and it may conflict with the system's one
I wrapped the OMaps executable with a script that adds these flags:
- -resources_path $PREFIX/share/organicmaps/data (where I installed data)
- -data_path "${XDG_DATA_HOME:-${HOME}/.local/share}/OMaps" this has to be separate, since resources_path is not writable
the script also creates the data_path if not existing before starting the program, since it's not automatically created

The package is pending review, you can see its source at https://github.com/NixOS/nixpkgs/pull/123259

> Thanks for the great work on providing a truly free and respectful OpenStreetMap based vector map app! seconding this! I just packaged this software for [NixOS](https://nixos.org), so here's some more info for other packagers & feedback for the project: * I had to disable `tools/unix/check_cert.sh` since it's dependent on time and affects reproducible builds * I applied #418 * I see that lots of dependencies are vendored. It'd be nice to be able to link to the system ones, even just because of the build times (icu in particular takes a lot) * I had to manually install the OMaps binary, the data directory, and the icon and desktop files, in addition to running the normal ninja/make install. * it'd be nice if install statements for those items were added in the cmake files. I'd make a patch myself, but I'm not very familiar with cmake. * I removed the xmlfw executable that was automatically installed, since it looks like OMaps does not need it (it only uses the library) and it may conflict with the system's one * I wrapped the OMaps executable with a script that adds these flags: * `-resources_path $PREFIX/share/organicmaps/data` (where I installed `data`) * `-data_path "${XDG_DATA_HOME:-${HOME}/.local/share}/OMaps"` this has to be separate, since resources_path is not writable * the script also creates the data_path if not existing before starting the program, since it's not automatically created The package is pending review, you can see its source at https://github.com/NixOS/nixpkgs/pull/123259

👍 1

rtsisyk commented

2021-05-17 09:12:33 +00:00

Owner

I had to disable tools/unix/check_cert.sh since it's dependent on time and affects reproducible builds

I have no idea about this script.
CC: @biodranik

I applied #418

Merged. Thanks for PR!

I see that lots of dependencies are vendored. It'd be nice to be able to link to the system ones, even just because of the build times (icu in particular takes a lot)

Please feel free to send a patch to our CMake scripts to allow system dependencies.

I had to manually install the OMaps binary, the data directory, and the icon and desktop files, in addition to running the normal ninja/make install.

CMake can be used to install all required files, please make a patch.

I removed the xmlfw executable that was automatically installed, since it looks like OMaps does not need it (it only uses the library) and it may conflict with the system's one

Make sense.

wrapped the OMaps executable with a script that adds these flags:
the script also creates the data_path if not existing before starting the program, since it's not automatically created

I think that we can try to patch default paths in the executable.

The package is pending review, you can see its source at NixOS/nixpkgs#123259

Thanks for your work on Nix package. We appreciate that. You are welcome to send all required patches directly to our upstream instead of applying them in packages.

>I had to disable tools/unix/check_cert.sh since it's dependent on time and affects reproducible builds I have no idea about this script. CC: @biodranik >I applied #418 Merged. Thanks for PR! >I see that lots of dependencies are vendored. It'd be nice to be able to link to the system ones, even just because of the build times (icu in particular takes a lot) Please feel free to send a patch to our CMake scripts to allow system dependencies. > I had to manually install the OMaps binary, the data directory, and the icon and desktop files, in addition to running the normal ninja/make install. CMake can be used to install all required files, please make a patch. >I removed the xmlfw executable that was automatically installed, since it looks like OMaps does not need it (it only uses the library) and it may conflict with the system's one Make sense. > wrapped the OMaps executable with a script that adds these flags: >the script also creates the data_path if not existing before starting the program, since it's not automatically created I think that we can try to patch default paths in the executable. > The package is pending review, you can see its source at NixOS/nixpkgs#123259 Thanks for your work on Nix package. We appreciate that. You are welcome to send all required patches directly to our upstream instead of applying them in packages.

biodranik commented

2021-05-17 10:48:56 +00:00

(Migrated from github.com)

I had to disable tools/unix/check_cert.sh since it's dependent on time and affects reproducible builds

It looks like embedding some client certificates to avoid malicious connections to rogue servers. Maps.me used it for user passport auth. We don't use these certs at the moment but may enable them in the future if cloud backups will be introduced.

> I had to disable tools/unix/check_cert.sh since it's dependent on time and affects reproducible builds It looks like embedding some client certificates to avoid malicious connections to rogue servers. Maps.me used it for user passport auth. We don't use these certs at the moment but may enable them in the future if cloud backups will be introduced.

andrewshadura commented

2021-06-09 16:08:45 +00:00

(Migrated from github.com)

I was going to work on a package, but it’s going to be a long road because of a lot of vendored libraries.

Probably a Flatpak package might get usable results quicker.

I was going to work on a package, but it’s going to be a long road because of a lot of vendored libraries. Probably a Flatpak package might get usable results quicker.

👍 2 👎 1

fgaz commented

2021-07-14 13:29:27 +00:00

(Migrated from github.com)

Same for the NixOS package :-/

The package is working and the PR is there, but we're waiting to merge until we can use system libraries, the biggest and most security sensitive ones at least.

I'd do this myself, but as I wrote above I'm not knowledgeable about cmake, so if anyone could help with this that'd be great! 🙏

Same for the NixOS package :-/ The package is working and the PR is there, but we're waiting to merge until we can use system libraries, the biggest and most security sensitive ones at least. I'd do this myself, but as I wrote above I'm not knowledgeable about cmake, so if anyone could help with this that'd be great! :pray:

suoko commented

2021-07-23 21:26:35 +00:00

(Migrated from github.com)

Did anybody try to build a package for xenial? That way Ubuntu touch users can test it using the libertine container.

fgaz commented

2022-01-23 13:11:56 +00:00

(Migrated from github.com)

I was going to work on a package, but it’s going to be a long road because of a lot of vendored libraries.

Linking with system libraries was just enabled for freetype/icu!

#1724 #1877 #1870

Maybe I could use that PR as a base to try to do the same with other libraries

> I was going to work on a package, but it’s going to be a long road because of a lot of vendored libraries. Linking with system libraries was just enabled for freetype/icu! #1724 #1877 #1870 Maybe I could use that PR as a base to try to do the same with other libraries

👍 1

fgaz commented

2022-03-27 16:47:58 +00:00

(Migrated from github.com)

https://github.com/NixOS/nixpkgs/pull/123259 is in, we have the first distro package!

🎉 5

andrewshadura commented

2022-03-27 20:49:10 +00:00

(Migrated from github.com)

@fgaz, thanks for your work on ~~devendoring~~ unbundling 🙂

@fgaz, thanks for your work on ~~devendoring~~ unbundling 🙂

fgaz commented