Distro packaging

[kjkent]

Hey there, IMSProg is great; thank you for creating it. I thought it might help others access IMSProg if I packaged it for the AUR, which I've now done: https://aur.archlinux.org/packages/imsprog. You can read the PKGBUILD there, but essentially it just pulls the release tarball from this repo and automates the build/install process. Users get the added benefits of the transactional install & uninstall capabilities.

Perhaps it might help others if a note was added to the README to say Arch users can install with paru imsprog or yay imsprog, or whichever AUR helper they like! If you have any feedback or suggestions for the PKGBUILD please let me know. The only deviation from the build process in the README is that I've used

make -j`nproc`

instead of make -j4, which should give a quicker performance boost on systems with more cores. I haven't timed this, though.

Lastly, it's not mentioned in the README, but the database update script depends on wget and zenity (I've added these to the PKGBUILD depends array), and the .desktop file for the script has the same Name and GenericName (the latter, just the English text) properties as the main IMSProg entry, which leads to ambiguous listings in, e.g., rofi:

If it was something you'd be open to, I'd be happy to submit a couple of PRs for these minor fixes. In any case, thanks!

[Fantu]

I suggest removing the actual mentors upload that seems wrong (I don't understand why orig contain debian folder, I suppose something wrong in your local repository). Continuous incorrect uploads with error on basic things discourage possible revision and DD sponsors who don't have much time to teach everything including the basics to the possible new maintainers.

[bigbigmdm]

All right, Fabio. I'll remove it!

[axet]

Fabio намекает, что раз уж мы так много времени потратели на объеснение простых вещей, не плохо было бы взять на себя сопровождение еще нескольких пакетов ;)

[Fantu]

@axet I don't understand what you mean on latest message, I don't know if badly translated by google translator.

[bigbigmdm]

@axet is so joking...

[kjkent]

@bigbigmdm will do — I'll get to this later today, thanks for the reminder 👍🏻

[Fantu]

@axet if you meant if I also became maintainer of this package, in theory I would like to avoid it, I don't have much time and that's why I haven't started the procedure to become DD (I'm only a DM), otherwise I would start sponsoring packages. I give some rare help like this one which seemed like a quick and simple package and needed a little quick information, but unfortunately it seems to be @bigbigmdm having difficulties, or I'm not good enough at explaining :(

[bigbigmdm]

kjkent, thank you! I'll be looking forward to this one!

[axet]

@Fantu I was said: "Since we spend so much time teaching you basic things about maintaining, it would be reasonable to start maintain few more debian packages"

[Fantu]

@axet maintaining this might be enough, he is already having difficulty with even just a few basic things. About debian/latest for now result ok, I tried to generate source from it, adding only temp. commit for d/changelog and generated correctly so I suppose @bigbigmdm have local repository with wrong 1.1.5 tag, wrong old unofficial packages files or other. There is still no 1.1.6, so I have not updated debian/latest for it.

One small thing that can help:

nano ~/.gbp.conf # add the following line:
[DEFAULT]
export-dir = ../build-area/

for build to ../build-area/ and for example after uploaded to ftp-master, launchpad, mentors debomatic etc... and ok I delete them to avoid mistake for other build. @bigbigmdm This I suppose will help you to have both official and unofficial different build

another thing, for a clean build "source only" I use for example: gbp buildpackage --git-builder='debuild -d -S -sa' additional and different parameters of debuild may be needed based on what you need

[bigbigmdm]

Fabio, you're right! I sit at one computer in one place during the day, and at another computer in another place in the evening. Probably at some point I forgot to do git push....

I'll check tomorrow to see if I need to add anything else and make tag 1.1.6.

[bigbigmdm]

Hello, Fabio! I was maek the tag 1.1.6, but the gbp import-ref -u1.1.6 returned error: Import of upstream/1.1.6 failed: Error running git tag: fatal: Не удалось разрешить «upstream/1.1.6^0» как ссылку.

[Fantu]

The 1.1.6 tag seems ok, I suppose you have issues on your local git, I suggest cloning the repository in a new folder to have a clean and correct local copy. For the new tag I suppose only missed and can solve with a fetch but from a wrong latest upload to mentors I suppose there is only something else wrong, so since you have difficulty with the basic use of git, the simplest and fastest thing is to start from a clean situation by cloning it in a new folder.

[bigbigmdm]

Fabio, I cloned IMSProg to a new folder, checked git config, but the error didn't go away:

gbp import-ref -u1.1.6 gbp:warning: This script is experimental, it might change incompatibly between versions. gbp:info: Upstream tag 'upstream/1.1.6' not found. Creating it for you. gbp:error: Import of upstream/1.1.6 failed: Error running git tag: fatal: Не удалось разрешить «upstream/1.1.6^0» как ссылку.

[Fantu]

I did a test on a clean clone and worked, worked also on my old copy, I'm not sure how to help you learn :( For now I updated debian/latest for you. There is also the upstream changelog (in the readme) not corresponding to effective version changes and "v1.1.4-2" wrong tag, that I suppose can be confusing for package maintainers, users and developers. Is there anyone who wants to help with their opinions? And maybe someone better than me with english and explain who can help @bigbigmdm learn to use git?

Edit: thinking again of what can be your issue also on clean repository copy, I suppose you tried to execute the command in main branch Before do something, check to be in the correct branch, main for upstream work on the software and debian/latest for Debian packaging, for switch use "git checkout ". If you work on multiple device as you wrote, make sure to update your local copy with git fetch origin and git pull on the branch you need to work. I suppose this as possible cause of previous error if you added and pushed 1.1.6 tag on one device, and you tried to do gbp import-ref -u1.1.6 on the other without git fetch and git pull before.

At least for working on packaging (debian/latest should be selected before), probably can help gbp pull, if branch tracking is configured correctly, it helps as with one command it does git fetch and git pull of both branches.

I tried to check your latest builds on launchpad https://launchpad.net/~bigmdm/+archive/ubuntu/imsprog, and I saw orig with debian folder also with 1.1.6 that I don't understand how is possible as there wasn't wrong initial tag (FWIK) like there was with 1.1.5. So I did a fast test on my ppa:

• on debian/latest created temp. commit changing d/changelog with "fake" initial release and new entry for rebuild.
• built with gbp buildpackage --git-builder='debuild -d -S -sa' and orig generated was ok
• uploaded on launchpad with dput ppa:fantonifabio/tests and also after build result ok
• removed the latest temp. commit with git reset --hard HEAD~1

I also tried another build for other Ubuntu LTS and also orig from this upload seems ok. One thing I spotted that if I don't clean build-area between the builds don't regenerate the orig (if is of the same version), so if first was generated wrong remain wrong and keep using it on any debian revision (including only for rebuild)

[bigbigmdm]

Thank you, Fabio! It worked!

[Fantu]

orig of 1.1.6 you generated for latest mentors upload is still wrong :( I don't know how you make it, probably is the same you generated for yesterday, upload to launchpad. It also seems strange to me that you didn't notice this wrong way (I don't know exactly which one) you use for generating package sources. With the first upload, as in the case of mentors, there is no serious error that make reject, while launchpad with subsequent uploads, seeing origs of the same upstream version already uploaded but different, should reject the upload if I'm not mistaken. Unless you see the rejects and instead of understanding that you are doing something wrong you continue to empty the ppa every new upload as a workaround.

[bigbigmdm]

Fabio, could you please explain to me what is wrong with the download? What criteria do you use to determine that the download is bad? I only see the warning Package uploaded for the UNRELEASED distribution at https://mentors.debian.net/package/imsprog/.

To generate package sources I use:

cd imsprog-1.1.6
dpkg-buildpackage -T clean
dh_make --createorig
debuild -S -us -uc -sa
cd ..
debsign -k 65*******22 imsprog_1.1.6-1.dsc
debsign -k 65*******22 imsprog_1.1.6-1_source.changes
dput mentors imsprog_1.1.6-1_source.changes

[Fantu]

Instead of all this operations you can use gbp buildpackage --git-builder='debuild -d -S -sa', cd on .. or ../build-area (based on settings, and dput mentors (by default select the latest .changes)

gbp buildpackage --git-builder='debuild -d -S -sa' do many checks and operations like dh_clean, create of orig, source and signing if detected gpg of the mail (or you need to add -k to debuild inside gbp if it don't sign automatically)

remember to delete old and wrong orig, deb files etc... if in the same folder of output (mainly "..")

For example, I created a new git copy and correct source build ready to mentors upload in less than 1 minute:

gbp clone git@github.com:bigbigmdm/IMSProg.git --debian-branch=debian/latest
cd IMSProg/
gbp buildpackage --git-builder='debuild -d -S -sa'

Full gbp buildpackage output here: https://paste.debian.net/1304507 If is generated correctly, probably is ok to do a temp. commit for release to unstable (dch -r --distribution unstable) before gbp buildpackage ...

As you can see, it generate the orig from the tag: gbp:info: Creating imsprog_1.1.6.orig.tar.gz from 'v1.1.6' when content (and not the name that should be imsprog_1.1.6.orig.tar.gz) of the orig and the v1.1.6 tar.gz from github will be the same so the orig will be correct

[bigbigmdm]

Thank you, Fabio! Now I'm beginning to understand something. So all-all files that are in the debian/latest branch should be in imsprog_1.1.6.orig.tar.gz?

[bigbigmdm]

Fabio, give me a hint, please: Can I delete a release on mentors.debian, rebuild it on my computer and submit it again with the same tag V1.1.6-1 (imsprog (1.1.6-1) UNRELEASED; urgency=medium)?

[Fantu]

Thank you, Fabio! Now I'm beginning to understand something. So all-all files that are in the debian/latest branch should be in imsprog_1.1.6.orig.tar.gz?

😢 orig is the upstream tarball so is the same of "main" at specific tag and not the same of debian/latest. I mean relating on files. debian folder will be in debian.tar.xz instead however gbp makes it much easier and faster to generate packages in just a few commands, much more than what you were trying to do, which wasn't completely correct.

Fabio, give me a hint, please: Can I delete a release on mentors.debian, rebuild it on my computer and submit it again with the same tag V1.1.6-1 (imsprog (1.1.6-1) UNRELEASED; urgency=medium)?

yes delete wrong upload on mentors. What you mean tag "V1.1.6-1"? That tag should not exist the tag debian/1.1.6-1 will be generated with gbp tag and pushed only after package will be uploaded to official repository for now, try to do at least a correct upload generating with: gbp buildpackage --git-builder='debuild -d -S -sa'

[bigbigmdm]

Thank you. I'll try to do that tomorrow.

[bigbigmdm]

Thank you, Fabio!

[kjkent]

@bigbigmdm Apologies for my delay in getting back to you! So I've just built and installed the latest release (1.1.4-2), which installed without issue; however IMSProg is erroring due to the change of database file location from /etc to /usr/etc:

And within the IMSProg database updater, perhaps stemming from the same cause:

I searched my system for any configuration file that may still be pointing to the previous location but was unable to find one.

Any advice you can offer is greatly appreciated; I may have time to investigate this myself in the next day or so. In any case as soon as it's figured out I'll have an updated PKGBUILD pushed to the AUR and will make that PR regarding a potential addition to the readme.

Also, I noticed the readme has been updated to include zenity for the updater script, but not wget -- is wget no longer needed? If so, I'll remove it from the PKGBUILD dependencies array :)

Thanks!

[Fantu]

@kjkent From a fast search wget is used in https://github.com/bigbigmdm/IMSProg/blob/main/IMSProg_programmer/other/IMSProg_database_update about .dat path is not changed in Debian package, by default set CMAKE_INSTALL_SYSCONFDIR to /etc, I suppose your default is /usr/etc instead. First result on a fast search seems related: https://github.com/fish-shell/fish-shell/issues/6595

edit: if is changed in IMSprog instead, I suppose that can be related to add of include(GNUInstallDirs), but I don't have time to check now

[bigbigmdm]

@kjkent, temporarily (while I fix this problem) you can comment out or delete line number 12 in /IMSProg_programmer/CMakeLists.txt (include(GNUInstallDirs)). CMake cannot load linux environment variables and will set their default values. That should solve the problem.

[bigbigmdm]

Good afternoon, Fantu! Could you tell me if I should change the location of the IMSProg.Dat file from /etc/imsprog/ to /usr/share/imsprog and rename it to chips.Dat to make its purpose clear?

[Fantu]

@kjkent Instead add a patch in packaging that remove it I suppose is better add CMAKE_INSTALL_SYSCONFDIR="/etc" @bigbigmdm about .dat in /etc I also was thinking that is not very good, based on https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s07.html

No binaries may be located under /etc.

It only contains information about chips and not configuration, or I'm wrong? Thinking about /usr/share/imsprog probably is better, I try to ask for advice on mentors.

About possible improvements as wget and zenity only needed for IMSProg_database_update, I think is good to improve it to check if they are present, if not show a warning and exit. Improve also readme that are optional only for that. And after in Debian packages wget and zenity can be moved from dependencies to recommends.

[bigbigmdm]

@Fantu, then let's wait for advice from the mentors. Yes, this file only contains information about the chips.

[Fantu]

I saw that wget and zenity were not present in d/control of Debian packaging, I added them at least in suggests: https://github.com/bigbigmdm/IMSProg/commit/47190cc1f9bc34bceed90116b1979d49f06a2969

Reply from a DD:

Is that supposed to be modified by the user/administrator of a machine? I.e. could a new chip be supported by simply adding something there? The it could be considered a configuration file and could stay in /etc If not, moving it to /usr/share/ sounds reasonable

So I think is ok to keep in /etc, about include(GNUInstallDirs) as changed a default to a not standard path should be removed, the important is that all default folder are setted (if parameter is don't specified) and from a fast look to https://github.com/bigbigmdm/IMSProg/blob/main/IMSProg_programmer/CMakeLists.txt seem is done, and I suppose include(GNUInstallDirs) can be removed. Or someone have a better idea?

[bigbigmdm]

@Fantu, thanks for including Zenity in d/control.

[Fantu]

Actually build system don't seem very good, in particular for user that don't use packages, not optimal also for maintainer. Cmake don't seems very easy/fast for improve using it, or I'm wrong? Meson seems better to me, most of the packages I maintain have migrated to that in the last few years. I don't have excellent knowledge about it, but when I needed something specific, I found it easier and faster than with CMake.

[bigbigmdm]

@Fantu, thank you for including Zenity to d/control.

[bigbigmdm]

@Fantu, there is good documentation on CMake. That's why I chose it. And this is the first time I've heard about Meson.....

[Fantu]

Ok, I hope that someone expert in CMake help to improve the build of this project. About d/control I spotted something strange in build-deps: why both new (libusb-1.0-0-dev) and older (libusb-dev) usb library? Is the new not enough? I don't see include of old usb.h (0.1) but only the new libusb.h (1.0) And libusb-1.0-0 is not needed (is dep of libusb-1.0-0-dev)

[Fantu]

@bigbigmdm tried to fix deb packaging build-deps but needs tests, mainly for "systemd-dev | udev" alternative that may be not working with some cases

I started to prepare build tests workflow: https://github.com/Fantu/IMSProg/commit/0833b201dccc599c54268572f561a2e95285b1f1 Debian 10 build fails: https://github.com/Fantu/IMSProg/actions/runs/7609770964/job/20721683258 you consider it too older to support it, and I'll remove from tests (will end also LTS support in few months https://wiki.debian.org/LTS) or you want still support it, and you will fix the issue?

[bigbigmdm]

Good afternoon, @Fantu! I can't say about Debian 10. But UBUNTU 20.04 should be kept. There are still many people using it now.

I've put CMake on hold for a while now, as I'm doing INTEL HEX format support at the request of users of the program.

The error is most likely related to the version of the C compiler (not C++). Please see this and CMakeLists.txt, lines 3,4,10.

[Fantu]

So I'll remove Debian 10, as you can see from the list of tested system there are Ubuntu 20.04,22.04 and Debian 11,12,testing,experimental and all other build was successful. Anyway CMake build without parameters, for users that build it manually .dat default to /usr/etc can cause issue.

About line 3 is https://cmake.org/cmake/help/latest/prop_tgt/CXX_STANDARD.html "C++17 New in version 3.8", so seems ok. If there is something used that require CMake >3.10 cmake_minimum_required(VERSION 3.10.0) must be fixed. Out of that, I think is enough to specify in readme that support Debian >=11 and Ubuntu >= 20.04 (to inform users that older version are not supported)

[bigbigmdm]

Well done! Thank you, @Fantu! I agree with you completely!

[bigbigmdm]

Thanks, @Fantu! And how was the problem with the location of IMSProg.Dat solved? /etc/imsprog/IMSProg.Dat or /usr/share/imsprog/IMSProg.Dat? Or have the mentors not answered yet?

[axet]

/usr 👍

[Fantu]

I wrote in https://github.com/bigbigmdm/IMSProg/issues/19#issuecomment-1902623955

Reply from a DD:

Is that supposed to be modified by the user/administrator of a machine? I.e. could a new chip be supported by simply adding something there? The it could be considered a configuration file and could stay in /etc If not, moving it to /usr/share/ sounds reasonable

So seems ok /etc

[bigbigmdm]

Ok, thank you, @Fantu!

[bigbigmdm]

@kjkent, your problem has been resolved. Please rebuild the IMSProg packet for the AUR.

[Fantu]

@bigbigmdm I don't see new version release

[kjkent]

@bigbigmdm @Fantu thanks both for working to resolve the install dir for the database file; I'll re-package now!

[bigbigmdm]

@Fantu, ok, I'll do that tomorrow. I wanted to mix these changes and the new programmer features, but it's not working out yet.

[bigbigmdm]

@Fantu, what is the best way to write a comment on version 1.1.7 in README.md ?

[Fantu]

What you mean exactly? For extended changelog probably is better separate from readme and put it in a specific file to avoid have a too long readme.