search

pmarguinaud / glgrib

Display GRIB2 fields with OpenGL
GNU General Public License v3.0
22 stars 3 forks source link

Towards packaging for Debian #1

Closed pgrt closed 1 year ago

pgrt commented 1 year ago

Hello,

This is a follow-up to https://lists.debian.org/debian-science/2022/12/msg00017.html

I looked at the packages you provided me with via FTP, and it turns out one should rather have one single source directory (made from yours and a debian/ directory) from which one would build all the binary packages. By the way, it would certainly be better if you removed or renamed the debian/ directory currently at the root of the source directory, as this would cause a name collision with the debian/ directory one adds when packaging for Debian.

I pushed the packaging effort forward, starting from the version you tagged v0.5. You can see and get my work at https://salsa.debian.org/pgt/glgrib I tried to put the same files as yours in the binary packages, except that I added dedicated binary packages for the libraries (following Debian Policy) and added some SOVERSION information, see debian/patches/build.patch and debian/rules. For the moment I only pushed the debian/ directory as the rest (i.e. your source) is a bit heavy.

It would be great if you would inspect the work I did, possibly build it and compare the resulting binaries to yours (missing files? suggestions? questions?).

Can you tell me whether you want to take over and feel like you can or not?

I have a few questions/remarks:

Looking forward to hearing from you,

Pierre

pmarguinaud commented 1 year ago

Hello Pierre,

And thank you very much for looking into this.

First some answers to your questions :

glgrib-data contains coastlines and landscape images, which are big files. I can split this into several smaller packages, and even remove some (not so needed) files. I will make a proposal.

I invoke scripts/debian.pl --install when I create the package. This script copies required data to debian/glgrib-bin/usr

This package contains the files used for creating the samples provided in the doc package. This would allow the user to run the examples described in doc.

I admit the names are very confusing, I will try to change that.

I will remove this file.

Thank you I will take this file from now. It was a bit unclear for me how to fill the copyright information.

I also a agree to create a dev package with the .so files + *.h. And maybe split glgrib-bin into one with the executable only, and the other with the libraries.

What I do not understand is how you managed to create different binary packages from a single source package (which tool do you use, with which options), and how you built the libraries and the executable (again which tool?). Could you shed some light on this ?

A few things you need to know about how I created these packages : I do not have access to a machine running Debian, so I create two Debian containers : one for building the packages, the other one for testing them. I do not use cmake, but instead a very simple makefile.

Regards,

Philippe

pgrt commented 1 year ago

Hello Philippe,

Thanks for your comments, things are much clearer now. As I understand it, I will now wait for changes from you in the repository layout?

Concerning the big files: in any case it is simpler (although not mandatory) if all the needed files are in the same repository then the code itself. If you are willing to keep all files in the repo but only some of them should be packaged into Debian, then this can be handled in the Debian package without requiring changes from your side.

About the glgrib-test package : OK I understand its purpose! Maybe it would be more standard if we changed its name to glgrib-examples.

Your comment reminds me I have not shipped the *h files in the -dev package right now; this should be done.

Finally, about how I built the packages: I am using sbuild, which is a wrapper of schroot https://wiki.debian.org/sbuild to maintain a minimal Debian unstable system. You should be able to follow the setup instructions in the page indicated above on a Debian-based distribution if you have one. After sbuild is set up, follow the instructions on slide 15 of https://www.debian.org/doc/manuals/packaging-tutorial/packaging-tutorial.fr.pdf where the orig tarball is the one of version 0.5 got from your repo, named glgrib_0.5.orig.tar.gz. Then cd to glgrib-0.5, where the debian/ folder of my salsa.debian.org:pgt/glGrib repo should lie, and type sbuild. This will handle the installation of the build-dependencies in the Debian unstable chroot and perform the build. If you are not willing to fiddle with sbuild, don't install it, just do everything as above, install build-dependencies on your system (in this case, your first Debian container) and type debuild (from the devscripts package) instead of sbuild to build.

To create multiple binary packages from a single source, one only needs to mention them all in debian/control (see the one in my repo), then the debhelper sequencer will put all the CMake-generated files in debian/tmp and then the debian/glgrib.install, debian/glgrib-test.install, ... files are used to put all these files in the desired binary packages.

I hope this is clearer now, else don't hesitate. That's arguably a lot of information.

Best regards,

Pierre

pmarguinaud commented 1 year ago

Thank you Pierre, I will look into this and let you know.

pmarguinaud commented 1 year ago

Just a simple question : I would like to avoid using cmake (which I do not like at all) and instead use a simple makefile. Would this be a problem or not ?

pgrt commented 1 year ago

Oh I see :) no problem, we can do it! It is just that I like the way the Debian sequence debhelper handles CMake builds, but we can also use a simple Makefile. Let's just remove the "--buildsystem=cmake" in debian/rules if we do so.

pmarguinaud commented 1 year ago

Another question : you have set the contents of libglgrib0.install to 

usr/lib/libLFI.so.*
usr/lib/libglGrib.so.*

But on my Debian systems, most shared libraries are installed in /usr/lib/x86_64-linux-gnu.

What should I do here ? Target /usr/lib or /usr/lib/$ARCH ?

Philippe

but

pgrt commented 1 year ago

Oh you're right, it should definitely be in the architecture-dependent subdirectory of /usr/lib: we could simply change the two lines into usr/lib/libLFI.so. usr/lib/$(DEB_HOST_MULTIARCH) usr/lib/libglGrib.so. usr/lib/$(DEB_HOST_MULTIARCH) in order to provide origin / destination pairs. Maybe we should need to include /usr/share/dpkg/architecture.mk in debian/rules so that the shorthand $(DEB_HOST_MULTIARCH) is correctly set!

Bye,

Pierre

pmarguinaud commented 1 year ago

I tried what you suggest (include /usr/share/dpkg/architecture.mk in rules + $(DEB_HOST_MULTIARCH) in libglgrib.install), but unfortunately the libraries get copied as : 

debian/libglgrib/usr/lib/$(DEB_HOST_MULTIARCH)/libglGrib.so.0
debian/libglgrib/usr/lib/$(DEB_HOST_MULTIARCH)/libLFI.so.0

Which implies that the evaluation of DEB_HOST_MULTIARCH is not performed. Note that this variable is defined in rules (I have echoed its value), and is also defined as an environment variable.

pmarguinaud commented 1 year ago

Maybe I should have a liblglgrib.install such as : 

usr/lib/*/libglGrib.so.*
usr/lib/*/libLFI.so.*

and install in debian/tmp using DEB_HOST_MULTIARCH : 


debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/libglGrib.so.0
debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/libLFI.so.0

?

pgrt commented 1 year ago

Hello Philippe,

Sorry, I should have tested my ideas before launching them ;)

You can grab the repo salsa.debian.org:pgt/glgrib and especially commit eed891121c98c656078a4185495ab92c58ab77cc which installs the libs in the right folder using dh-exec (which allows one to properly use variables defined in debian/rules in the debian/*.install files).

By the way: I have not considered installing the header files up to now, we should do it through debian/libglgrib-dev.install. I am wondering whether we should install them in /usr/include/glgrib instead of just /usr/include, in order to avoid possible name collisions in the /usr/include dir... Are the src/shaders/.../*.h headers needed in the developement library? Else, all headers would start with "glGrib" and so I am not afraid of any possible name collision. It is just that installing a shaders directory in /usr/include could seem strange.

Best,

Pierre

pmarguinaud commented 1 year ago

Hello Pierre,

I have made some progress and managed to create a bunch of deb files. You can see the result here on my home ftp server : 86.250.249.136 (l/p as usual), directory '2'. Please note that I have now two different builds for the application : glfw (interactive use) and egl (batch for system without x11).

Please look at it and tell me how to improve it if necessary.

Regards,

Philippe

pgrt commented 1 year ago

Hello Philippe,

Thanks for sharing this new work!

I suggest you run lintian -i -I from the root of the source directory after building the .deb files. lintian is the Debian linter, available in the lintian package, and its output is very useful to detect enhancement possibilities.

Here is the output I got with your work (on the very left one can see a letter for the severity: error, warning, information). lintian2.log

I made some changes to silence some of the tags, see the zip with the contents of my debian/ folder. debian2new.zip Here is the diff: changes.diff.txt

You will see my changes are:

So what's next? We should silence as many Lintian tags as possible, see this output I got with my changes: lintian2new.log

The steps would be (ignoring the 60 first lines for the moment, they are not related to packaging issues):

Also for my understanding: is there any relationship between the glfw and egl packages you propose to build? Are they co-installable? Or absolutely not?

If anything is unclear, please do write to me :)

Best, Pierre

pmarguinaud commented 1 year ago

Hello Pierre,

Following your advice, I managed to suppress all warnings except this one : "initial-upload-closes-no-bugs", which appears for all packages. I also have used the flags for "hardening" executable code. I still have a question regarding the debian directory; how should I manage this directory ? You said I need to move it to another sub-directory, but debuild expects this directory to be at the top level. Should I move it at top level just for building packages ?

Regards,

Philippe

pgrt commented 1 year ago

Hello Philippe,

Great :) About closing a bug: we should fill a bug stating our intent to package glgrib -- if this evokes nothing to you, I will do so.

About the debian/ directory: usually upstream developers develop their software and it typically does not include a debian/ drectory. For instance, the bash original tarball: https://ftp.gnu.org/gnu/bash/bash-5.2.tar.gz Then the Debian packager gets the upstream original tarball, unpacks it, add a debian/ directory (but does /not/ include it in the orig tarball) with the necessary files and then calls debuild. This generates the .deb files, the .dsc and a .debian.tar.xz file with the contents of the debian/ directory only. For instance in the Debian pools, one finds the orig tarball of bash (identical to the one on the GNU website) http://ftp.fr.debian.org/debian/pool/main/b/bash/bash_5.2.orig.tar.xz, the .dsc http://ftp.fr.debian.org/debian/pool/main/b/bash/bash_5.2-2.dsc and the .debian.tar.xz file http://ftp.fr.debian.org/debian/pool/main/b/bash/bash_5.2-2.debian.tar.xz . In the cas of glgrib, the upstream maintainer and the Debian maintainer are the same person :) which causes the confusion. If you maintained your original software and the Debian packaging in different repositories, you would not see this problem I guess :)

Having read this, you can re-read https://www.debian.org/doc/manuals/packaging-tutorial/packaging-tutorial.fr.pdf, slide 15, having in mind that dh_make is one tool that handles automatically the creation of the debian/ directory. But I never used it :) It's just to recap on the usual steps to Debian packaging.

Is it clearer now?

Best regards, Pierre

pgrt commented 1 year ago

Hello again,

To keep things simpler, I have declared the Intent-to-Package bug myself, it is here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027277

So you only have to change the line in debian/changelog to

and we are done. This will silence the remaining Lintian item!

Bye,

Pierre

pmarguinaud commented 1 year ago

Hello Pierre,

I still have a few warnings from lintian, which I do not know how to solve (I assume I should ignore those related to the bug number you gave me): 

W: liblfi0: improbable-bug-number-in-closes 1027277
W: python3-glgrib-glfw: improbable-bug-number-in-closes 1027277
W: glgrib source: newer-standards-version 4.6.1 (current is 4.5.1)
W: glgrib source: no-debian-changes

Regarding the debian/ directory, I have moved it in packaging/debian, and I copy its contents into debian before issuing the debuild command. Is that correct ?

Regards,

Philippe

pgrt commented 1 year ago

Hello Philippe,

Yes, you see these warnings because (I guess) the version of Debian in the docker is Debian 11 which did not know of bug numbers > 999999 and for which the reference Standards version was 4.5.1. Everything is normal thus :)

About the debian/ directory: yes, I trust this is the right thing to do!

Do you think there remains to polish some parts of the packaging or would you like me to look at the current version?

Best, Pierre

pmarguinaud commented 1 year ago

Hello Pierre,

I think it is ready now. You can look at it.

Philippe

pgrt commented 1 year ago

Hello Philippe,

Thanks, but I trust there are only versions 1 and 2 on your server (2 being the last one I saw, on mid-December), is this right?

Best, Pierre

pmarguinaud commented 1 year ago

Hello Pierre,

I thought you wanted to generate the packages yourself, to test that the whole process is valid.

I have generated the deb packages for debian:latest; directory number 3 is now online.

Regards,

Philippe

pmarguinaud commented 1 year ago

There is also a question I forgot to answer : you once asked the difference between glgrib-egl and glgrib-glfw. The GLFW build is for interactive use, with a X11 display. The EGL build can use a graphic card without X11, which is useful on batch systems.

pgrt commented 1 year ago

Hello Philippe,

Yes that's right, but I only fetched the contents of your ftp server and forgot to look at the Github repository itself for the source... sorry about that! I will be having a look soon.

Thanks for the further explanation on GLFW/EGL! From this I guess they are perfectly co-installable, fine for me then :)

Best, Pierre

pgrt commented 1 year ago

Hello Philippe,

I looked at your last packaging, I think we are quite close to the end and only some technical issues remain.

First, I made some changes which you can see by inspecting the last commits in https://salsa.debian.org/pgt/glgrib I hope the commit texts are enough to understand them, else please let me know.

I installed the built packages and typed $ glgrib /usr/share/glgrib/testdata/diff/ICMSHFCST+0001 (as suggested in the manpage), however I only get Error: 65543 | GLX: Failed to create context: GLXBadFBConfig Same with glgrib-glfw. With $ glgrib-egl /usr/share/glgrib/testdata/diff/ICMSHFCST+0001 I have Arguments are inconsistent (for example, a valid context requires buffers not supplied by a valid surface).

With $ glgrib-tk I get Can't locate DBI.pm in @INC so the glgrib-tk package should depend on libdbi-perl (I have not made the change in the packaging at the moment). After installing it manually, I get the error message about GLXBadFBConfig.

Finally: I guess the python3- package should allow me to type some import command in a python console? I tried import glfw, import glgrb_glfw but got errors like ModuleNotFoundError: No module named 'glfw' in any case.

Thanks for your help on this,

Best, Pierre

pmarguinaud commented 1 year ago

Hello Pierre,

I have started looking into this. Until now, I have made some tests in a docker container, always on the same laptop, but I tried another laptop (both are running ubuntu 22.04) and managed to reproduce your problem (also in docker).

Do you also test in a container ?

Philippe

pgrt commented 1 year ago

Hello Philippe,

Thanks for looking at it :) I made the test in ``true conditions'', by installing the built packages on my computer running Debian 12 Bookworm, so not in a container. Please let me know if I can provide you with more details!

All the best, Pierre

pmarguinaud commented 1 year ago

Hello Pierre,

This is interesting, because I have tried glgrib on several computers, and never encountered this problem. Could you describe the hardware you use, in particular the graphic card ?

Philippe

pgrt commented 1 year ago

Hello Philippe,

I am using a Dell Latitude E6420 from 2012, here is the output of my lspci command:

00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09) 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200/2nd Generation Core Processor Family PCI Express Root Port (rev 09) 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) 00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 (rev 04) 00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (Lewisville) (rev 04) 00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 04) 00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller (rev 04) 00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 (rev b4) 00:1c.1 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 2 (rev b4) 00:1c.2 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 3 (rev b4) 00:1c.3 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 4 (rev b4) 00:1c.5 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 6 (rev b4) 00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 04) 00:1f.0 ISA bridge: Intel Corporation QM67 Express Chipset LPC Controller (rev 04) 00:1f.2 RAID bus controller: Intel Corporation 82801 Mobile SATA Controller [RAID mode] (rev 04) 00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller (rev 04) 01:00.0 VGA compatible controller: NVIDIA Corporation GF119M [NVS 4200M] (rev a1) 01:00.1 Audio device: NVIDIA Corporation GF119 HDMI Audio Controller (rev a1) 03:00.0 Network controller: Broadcom Inc. and subsidiaries BCM4313 802.11bgn Wireless Network Adapter (rev 01) 0b:00.0 SD Host controller: O2 Micro, Inc. OZ600FJ0/OZ900FJ0/OZ600FJS SD/MMC Card Reader Controller (rev 05) 0b:00.1 Mass storage controller: O2 Micro, Inc. Device 8231 (rev 03)

So, as you see, my graphics card is NVIDIA Corporation GF119M [NVS 4200M].

Also here are the first lines of my glxinfo output:

name of display: :0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.4

I hope this helps...!

All the best, Pierre

pmarguinaud commented 1 year ago

Hello Pierre,

I am afraid your graphic card is too old. glgrib requires OpenGL 4.3 minimum to run (this is a hardware feature, not a library version). Here is the output of glxinfo on my laptop (4 or 5 years old) :+1: 

$ glxinfo | grep -i version
server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
    Version: 22.0.5
    Max core profile version: 4.6
    Max compat profile version: 4.6
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.2
OpenGL core profile version string: 4.6 (Core Profile) Mesa 22.0.5
OpenGL core profile shading language version string: 4.60
OpenGL version string: 4.6 (Compatibility Profile) Mesa 22.0.5
OpenGL shading language version string: 4.60
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 22.0.5
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
    GL_EXT_shader_group_vote, GL_EXT_shader_implicit_conversions,

You can also try this test program : 

#include <GL/glew.h>
#include <GLFW/glfw3.h>
#include <stdlib.h>
#include <stdio.h>

int main ()
{
  if (! glfwInit ())
    return 1;

  glfwWindowHint (GLFW_CONTEXT_VERSION_MAJOR, 4);
  glfwWindowHint (GLFW_CONTEXT_VERSION_MINOR, 3);
  glfwWindowHint (GLFW_OPENGL_FORWARD_COMPAT, GL_FALSE);
  glfwWindowHint (GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);
  glfwWindowHint (GLFW_RESIZABLE, GL_FALSE);
  glfwWindowHint (GLFW_OPENGL_DEBUG_CONTEXT, GL_TRUE);

  GLFWwindow * window = glfwCreateWindow (400, 400, "", NULL, NULL);

  if (! window)
    {
      fprintf (stderr, "Failed to open GLFW window.\n");
      glfwTerminate();
      return 1;
    }

  return 0;
}

It compiles as follows : 

cc -g -o glfw.x glfw.c -lglfw

Philippe

pgrt commented 1 year ago

Hello Philippe,

Thanks for pointing this out; it is indeed likely my card is old :D

I built your test program and ran it, and got Failed to open GLFW window.

Does this fit your expectations?

I guess we could let the library packages as they are, (only adding the libdbi-perl depencency for the -perl package), maybe there remains something to do with the python3- package (see one of my most recent messages above), afterwards I guess we can upload the package?

Bye, Pierre

pmarguinaud commented 1 year ago

Hello Pierre

Yes, it was expected that this test program would fail on your PC.

I have taken all your changes, except this one : 

diff -r packaging/debian/python3-glgrib-glfw.install ../pgrt/debian/python3-glgrib-glfw.install
1c1
< usr/lib/python3.*/site-packages/* usr/lib/python3/dist-packages/
---
> usr/local/lib/python3.*/dist-packages/* usr/lib/python3/dist-packages/

I force python to install in /usr/lib, and it works. Have you encountered some issues while creating the packages ?

And the python library should be used like that : import glGrib.glfw.

Philippe

pgrt commented 1 year ago

Hello Philippe,

Fine then!

Yes, I met an issue with the version of python3-glgrib-glfw.install that you wrote, as it seems setuptools (from python3-setuptools 65.6.3-1) is putting things in usr/local/lib. Here is an excerpt of my build log:

cd src/python3/glfw && make install
make[2]: Entering directory '/<<PKGBUILDDIR>>/src/python3/glfw'
python3 setup.py install 
running install
/usr/lib/python3/dist-packages/setuptools/command/install.py:34: SetuptoolsDeprecationWarning: setup.py install is deprecated. Use build and pip and other standards-     based tools.
  warnings.warn( 
running build
running build_ext
running install_lib
creating ../../../debian/tmp/usr/local
creating ../../../debian/tmp/usr/local/lib
creating ../../../debian/tmp/usr/local/lib/python3.11
creating ../../../debian/tmp/usr/local/lib/python3.11/dist-packages
creating ../../../debian/tmp/usr/local/lib/python3.11/dist-packages/glGrib
copying build/lib.linux-x86_64-cpython-311/glGrib/glfw.cpython-311-x86_64-linux-gnu.so -> ../../../debian/tmp/usr/local/lib/python3.11/dist-packages/glGrib
running install_egg_info
running egg_info 
creating glGrib.glfw.egg-info
writing glGrib.glfw.egg-info/PKG-INFO
writing dependency_links to glGrib.glfw.egg-info/dependency_links.txt
writing top-level names to glGrib.glfw.egg-info/top_level.txt
writing manifest file 'glGrib.glfw.egg-info/SOURCES.txt'
reading manifest file 'glGrib.glfw.egg-info/SOURCES.txt'
writing manifest file 'glGrib.glfw.egg-info/SOURCES.txt'
Copying glGrib.glfw.egg-info to ../../../debian/tmp/usr/local/lib/python3.11/dist-packages/glGrib.glfw-0.1-py3.11.egg-info

Maybe this is just a discrepancy due to our build environments which would not include the same setuptools; I am building packages in a chroot with Debian/unstable.

Thanks for your answer regarding the Python part; I can import glGrib but trying import glGrib.glfw returns No module named 'glGrib.glfw', which is a bit surprising as it seems we have the same files list in the packages we build :( I think there only remains to understand what is going on here... right now I have no idea :-/

Bye,

Pierre

pmarguinaud commented 1 year ago

Hello Pierre,

I have changed the installation of the python3 module (I use pip3 now), and things look much better (everything builds without a single warning). I also used a debian:unstable docker image to generate the packages. I am currently copying the data to my ftp server; the address is now 86.250.249.136.

Regards,

Philippe

pgrt commented 1 year ago

Hello Philippe,

Thanks! Yes, with pip3 this indeed looks better!

Were you able to install the built packages and run import glGrib.glfw in an interactive python3 session? Unfortunately I could not. But honestly this is the last thing that prevents me to upload the whole source package to the archive. Please tell me if you meet the same issue or not...

Best, Pierre

pmarguinaud commented 1 year ago

Hello Pierre,

Yes the python module was installed and I was able to load it in my container :


phi001@glgrib_install:~$ ls /usr/lib/python3/dist-packages/glGrib
glGrib/                    glGrib.glfw-0.1.dist-info/ 
phi001@glgrib_install:~$ ls /usr/lib/python3/dist-packages/glGrib/glfw.cpython-311-x86_64-linux-gnu.so 
/usr/lib/python3/dist-packages/glGrib/glfw.cpython-311-x86_64-linux-gnu.so

phi001@glgrib_install:~$ python3 
Python 3.11.1 (main, Dec 31 2022, 10:23:59) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import glGrib.glfw
>>>

What kind of error message do you get ?

pgrt commented 1 year ago

Hello Philippe,

It is so fortunate you copied the contents of your Python session! I was getting a "Module not found" error. But I was running python3, and in Debian/testing right now, this is Python 3.10 by default, whereas in Debian/unstable this is Python 3.11 (there will be a discrepancy during some days as some Python packages seem to encounter difficulties due to the change of default version). Both you and I build on unstable and thus for Python 3.11, which is why my Python 3.10 session would not be able to load the module. I ran python3.11 and then was able to load it.

I uploaded glgrib to the Debian archive. You can monitor it in the NEW queue https://ftp-master.debian.org/new.html: it needs a manual review as it is a new package. This can take days to months... we shall see. But it is only for the first upload, next versions won't need such review.

I changed the repository of the package to https://salsa.debian.org/science-team/glgrib.

If you want to co-maintain it with me (as you obviously have some experience in Debian packaging now), you may create an account on salsa.debian.org, the Debian gitlab instance, then ask for access to science team (https://salsa.debian.org/science-team/) with it, and next you will be able to write to the repo of glgrib. Don't hesitate to ask your name next to mine in the Uploaders field in debian/control if you want!

Now we shall wait for the result of the manual review. In case it would fail (main possible causes are errors in debian/copyright), I would tell you so that we can react.

You may see if you prefer closing the present issue now or waiting until the manual review step is finished :)

Best, Pierre

pmarguinaud commented 1 year ago

Thank you very much Pierre. This trip through Debian packaging was very interesting.

I will probably move the contents of packaging/debian to your git repository, as you suggest.

Philippe

pmarguinaud commented 1 year ago

I still have another question; I have another project which I would like to be part of Debian/Ubuntu distribution. Its name is fxtran :

https://github.com/pmarguinaud/fxtran/tree/debian

The purpose of this tool is to parse FORTRAN source code into a XML document, which can be displayed in a web browser, searched for specific patterns or modified using regular XML libraries.

In which Debian section/group should such a tool be integrated ?

Regards,

Philippe

pmarguinaud commented 1 year ago

Another question : you suggested me to push the code to salsa.debian.org. Do you mean the whole glgrib repository, or just the debian folder ?

pgrt commented 1 year ago

Hello Philippe,

You are welcome!

You will see that in the https://salsa.debian.org/science-team/glgrib repo, I put the debian/ directory only. I think I will add the whole glgrib source when it exits the NEW package queue, so that we can easily ensure the Salsa repo is synced with the version in the Debian archive. I suggest you touch this repository if you see some changes to bring.

About fwtran: I understand it is a code parser. Looking at the list of authorized sections (https://www.debian.org/doc/debian-policy/ch-archive.html#sections), I think the one that would best suit is "editors", maybe "devel"... I don't see a team that would be an obvious match, perhaps it would be better to maintain it without a team (there is nothing wrong about it, it is rather common e.g. for Emacs https://tracker.debian.org/pkg/emacs). From a practical point of view, this would mean creating a repo in the salsa.debian.org/debian namespace (which I can do for you), and when you think your packaging is ready you can either ask for sponsorship on https://mentors.debian.net/ or tell me if you want I do it, like we did for glgrib!

Bye,

Pierre

pgrt commented 1 year ago

Hello,

The Debian package for glgrib is now in testing, so a candidate for inclusion in the next stable release. Could you please try to get it and maybe do some tests in order to check if everything is working right now?

Best, Pierre

pmarguinaud commented 1 year ago

Hello Pierre,

I have installed and tested the core features of glgrib in a debian:unstable docker container.

It works !

Best regards,

Philippe

pgrt commented 1 year ago

Hi Philippe,

Very happy to read this!

Let's stay in touch if something wrong show up one day, or if you tag a new version!

Best,

Pierre