Closed Fantu closed 8 months ago
From a fast look now seems ok, try to ask again in mentors chat for a sponsor, maybe now with several things fixed/improved there will be more chance of finding a DD that want to check and sponsor
Probably is useful to close the old RFS (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057076) that is wrong and open a new one taking the template autogenerated from latest mentors upload, if you are not sure to do right try to send a mail to me instead submit@bugs.debian.org before
Fabio, please see this messages:
1057386-done@bugs.debian.org Subject: bug#1057386 The request has been moved to RFS.
submit@bugs.debian.org Subject: RFS: imsprog/1.1.4-1 [put in ITP, ITA, RC, NMU if applicable] -- friendly greeter
Package: sponsorship-requests Severity: normal [important for RC bugs, wishlist for new packages]
Dear mentors,
I am looking for a sponsor for my package "imsprog":
Package name : imsprog
Version : 1.1.4-1
Upstream contact : Mikhail Medvedev e-ink-reader@yandex.ru
URL : https://github.com/bigbigmdm/IMSProg/archive/refs/tags/v1.1.4.tar.gz
License : GPL-2+, GPL-3+, LGPL-2.1
Homepage : https://github.com/bigbigmdm/IMSProg
Vcs-Git : https://github.com/bigbigmdm/IMSProg.git -b debian/latest
Vcs-Browser : https://github.com/bigbigmdm/IMSProg/
Section : devel
The source builds the following binary packages:
IMSProg - i2c,SPI,MW chips programmer for CH341a devices
IMSProg_editor - chip database editor for the IMSProg
IMSProg_database_update - online chip database update from the external web-server.
To access further information about this package, please visit the following URL:
https://github.com/bigbigmdm/IMSProg
https://launchpad.net/imsprog
Alternatively, you can download the package with 'dget' and wget using this commands:
dget https://mentors.debian.net/debian/pool/main/i/imsprog/imsprog_1.1.4-1.dsc
wget https://github.com/bigbigmdm/IMSProg/archive/refs/tags/v1.1.4.tar.gz
Changes since the last upload:
imsprog (1.1.4-1) unstable; urgency=medium .
Regards, -- M. Medvedev
The ITP must remain open, will be automatically closed only when upload to official repository will be accepted by ftp-master.
message1: Is the wrong RFS to close (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057076)
message2: About the new one to open is correct, only some small things to change:
Subject: RFS: imsprog/1.1.4-1 [ITP] -- friendly greeter
on severity line remove the part [important for RC bugs, wishlist for new packages]
and change normal
to wishlist
(as explained in the text)
and below "To access further information about this package, please visit the following URL:" must be the mentors page and not upstream repository and unofficial build on launchpad what is being done is for builds in the official debian repositories (and thanks to the auto sync from debian also in ubuntu and derivatives)
https://mentors.debian.net/package/imsprog/
in theory, it should already be right in the template
Fabio, I'm duplicating here before posting just in case:
submit@bugs.debian.org Subject: RFS: imsprog/1.1.4-1 [ITP] -- friendly greeter
Package: sponsorship-requests Severity: wishlist
Dear mentors,
I am looking for a sponsor for my package "imsprog":
Package name : imsprog
Version : 1.1.4-1
Upstream contact : Mikhail Medvedev e-ink-reader@yandex.ru
URL : https://github.com/bigbigmdm/IMSProg/archive/refs/tags/v1.1.4.tar.gz
License : GPL-2+, GPL-3+, LGPL-2.1
Homepage : https://github.com/bigbigmdm/IMSProg
Vcs-Git : https://github.com/bigbigmdm/IMSProg.git -b debian/latest
Vcs-Browser : https://github.com/bigbigmdm/IMSProg/
Section : devel
The source builds the following binary packages:
IMSProg - i2c,SPI,MW chips programmer for CH341a devices
IMSProg_editor - chip database editor for the IMSProg
IMSProg_database_update - online chip database update from the external web-server.
To access further information about this package, please visit the following URL:
https://mentors.debian.net/package/imsprog/
Alternatively, you can download the package with 'dget' and wget using this commands:
dget https://mentors.debian.net/debian/pool/main/i/imsprog/imsprog_1.1.4-1.dsc
wget https://github.com/bigbigmdm/IMSProg/archive/refs/tags/v1.1.4.tar.gz
Changes since the last upload:
imsprog (1.1.4-1) unstable; urgency=medium .
Regards, -- M. Medvedev
Is everything correct now?
I hadn't noticed before, but I suppose you replaced the part too The source builds the following binary packages:
the generated binary package is only one, so this seems you change the right autogenerated content of template with this wrong.
I don't have to upload to mentors at the moment as these days I'm working on packages for which I have upload permissions, but if I remember correctly the template autogenerated by mentors is correct and with only 1-2 small things to change normally.
Okay. I mixed up binary packages - it's a DEB package, it's one. But there are three executable files in it. I'll fix it in mail and send it to Debian.
binary packages != binary executable (there can also be multiple executables in a package)
I also still saw old wrong RFS (1057076) open, better close before open the new one
One DD replies on mentors page, /lib/udev/rules.d should be moved for next debian and ubuntu.
I was thinking about the best way to do it, I don't know if better in upstream (on cmake build) or in packaging to build.
For detecting the path to use I suppose can be used pkg-config --variable=udevdir udev
on Debian unstable/testing and Ubuntu 24.04 it should return /usr/lib/udev
, on older instead /lib/udev
Fabio, you wrote: "I also still saw old wrong RFS (1057076) open, better close before open the new one". In order to close bug#105076 I need to send an email like this:
[1057386-done@bugs.debian.org](mailto:1057386-done@bugs.debian.org)
Subject: bug#1057386
The request has been moved to RFS.
Am I understanding this correctly?
For close bug#1057076 must be 1057076-done@bugs.debian.org https://www.debian.org/Bugs/Developer#closing
I have the file arrangement into folders in IMSProg_programmer/CMakeLists.txt: String 111:
install(FILES "${CMAKE_CURRENT_SOURCE_DIR}/other/99-CH341.rules" DESTINATION "/lib/udev/rules.d")
I don't have much experience with cmake however currently it has a fixed path, right? pkg-config probably can be used in upstream and should works on other distro different from Debian and derivates, but I'm not sure
Fabio, when i closing bug#1057076, what do need specify in the message body? (What's the reason for the closure?)
I suppose the cause can be "old and wrong", about open the new instead wait, need to fix udev rules and do new upload
CMake can use prefixes such as:
# Set the CMAKE_INSTALL_PREFIX to /usr if not specified
if (CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
set(CMAKE_INSTALL_PREFIX "/usr" CACHE PATH "The default install prefix" FORCE)
endif()
But for the rule files, I haven't found the examples.
Actually the path /lib/udev/rules.d prompted me lintian. True, I have the penultimate version of Ubuntu.
Should don't change the default path, need to set new cmake variable for udev destination like UDEV_CMAKE_INSTALL_DIR and set in it pkg-config --variable=udevdir udev
+/rules.d and use this variable like
install(FILES "${CMAKE_CURRENT_SOURCE_DIR}/other/99-CH341.rules" DESTINATION ${UDEV_CMAKE_INSTALL_DIR})
but I don't have time to try to do it
for example mdadm (don't use cmake) have Makefile with:
UDEVDIR := $(shell $(PKG_CONFIG) --variable=udevdir udev 2>/dev/null)
ifndef UDEVDIR
UDEVDIR = /lib/udev
endif
Good afternoon, Fabio! The more I learn about CMake, the more questions I have. Here are my variables that CMake gets from the Linux environment:
-- CMAKE_INSTALL_BINDIR=bin
-- CMAKE_INSTALL_DATADIR=share
-- CMAKE_INSTALL_DATADIR=share
-- CMAKE_INSTALL_DATAROOTDIR=share
-- CMAKE_INSTALL_DEFAULT_COMPONENT_NAME=Unspecified
-- CMAKE_INSTALL_DOCDIR=share/doc/IMSProg
-- CMAKE_INSTALL_DOCDIR=share/doc/IMSProg
-- CMAKE_INSTALL_FULL_BINDIR=/usr/local/bin
-- CMAKE_INSTALL_FULL_DATADIR=/usr/local/share
-- CMAKE_INSTALL_FULL_DATAROOTDIR=/usr/local/share
-- CMAKE_INSTALL_FULL_DOCDIR=/usr/local/share/doc/IMSProg
-- CMAKE_INSTALL_FULL_INCLUDEDIR=/usr/local/include
-- CMAKE_INSTALL_FULL_INFODIR=/usr/local/share/info
-- CMAKE_INSTALL_FULL_LIBDIR=/usr/local/lib
-- CMAKE_INSTALL_FULL_LIBEXECDIR=/usr/local/libexec
-- CMAKE_INSTALL_FULL_LOCALEDIR=/usr/local/share/locale
-- CMAKE_INSTALL_FULL_LOCALSTATEDIR=/usr/local/var
-- CMAKE_INSTALL_FULL_MANDIR=/usr/local/share/man
-- CMAKE_INSTALL_FULL_OLDINCLUDEDIR=/usr/include
-- CMAKE_INSTALL_FULL_RUNSTATEDIR=/usr/local/var/run
-- CMAKE_INSTALL_FULL_SBINDIR=/usr/local/sbin
-- CMAKE_INSTALL_FULL_SHAREDSTATEDIR=/usr/local/com
-- CMAKE_INSTALL_FULL_SYSCONFDIR=/usr/local/etc
-- CMAKE_INSTALL_INCLUDEDIR=include
-- CMAKE_INSTALL_INFODIR=share/info
-- CMAKE_INSTALL_INFODIR=share/info
-- CMAKE_INSTALL_LIBDIR=lib
-- CMAKE_INSTALL_LIBEXECDIR=libexec
-- CMAKE_INSTALL_LOCALEDIR=share/locale
-- CMAKE_INSTALL_LOCALEDIR=share/locale
-- CMAKE_INSTALL_LOCALSTATEDIR=var
-- CMAKE_INSTALL_MANDIR=share/man
-- CMAKE_INSTALL_MANDIR=share/man
-- CMAKE_INSTALL_OLDINCLUDEDIR=/usr/include
-- CMAKE_INSTALL_PREFIX=/usr
-- CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT=1
-- CMAKE_INSTALL_RUNSTATEDIR=var/run
-- CMAKE_INSTALL_RUNSTATEDIR=var/run
-- CMAKE_INSTALL_SBINDIR=sbin
-- CMAKE_INSTALL_SHAREDSTATEDIR=com
-- CMAKE_INSTALL_SO_NO_EXE=1
-- CMAKE_INSTALL_SYSCONFDIR=etc
If you look at CMAKE_INSTALL_FULL_...
, it appears that the system is asking for executables to be located in /usr/local/bin
instead of /usr/bin
. Is this correct?
Fabio, can you compile /debian/latest in the latest version of Ubuntu and let me know the path to the rules file? (I corrected the /IMSProg_programmer/CMakeLists.txt)
These should be the default values (for users that do custom build without specify them), Debian packaging set them to the needed. In debian/latest (and other packaging branches) MUST don't have changes out of Debian folder, any packaging specific changes to upstream source must use quilt (or gbp pq) and patches will be in debian/patches. Probably in this case with one binary package and without specific things dh_auto_install should take all files as installed by the build system and no packaging changes are need when fixed upstream. This change should be done upstream as also other distro are doing usr merge. From a fast look the change seems to me wrong because udev change may differ from the global lib one, so any software I saw are managing udev dir instead for doing the correct thing (I don't found one using cmake to see the correct setting to do)
I used GNUInstallDirs to read the correct linux patches.
I mean that udev path changes may be moved differently from general lib one so should be considered itself. All softwares I saw use 2 method, automatically set it like mdadm (I suppose the best) or make it settable by parameter (which would possibly be set via debian/rules)
Fabio, I'm sorry! What is mdadm?
mdadm is for manage software raid, but don't use cmake, in its makefile I saw a good and minimal way to make udevdir:
UDEVDIR := $(shell $(PKG_CONFIG) --variable=udevdir udev 2>/dev/null)
ifndef UDEVDIR
UDEVDIR = /lib/udev
endif
about cmake with udev rules I found only this: https://github.com/mixxxdj/mixxx/blob/main/CMakeLists.txt probably you can make a minimal and optimal thing looking it In it the full procedure is long, I don't know if it is done due to cmake shortcomings
Fabio, thanks for the cmake example. I will definitely have a look at it.
About commit message in latest main commit I saw for example:
Add files via upload
Fixed invalid path
I think should be only "Fixed invalid path" and "Add files via upload" is useless.
For make commit in easier/fast way you can use a gui tool, for example I use git-cola, while for most other things I continue to use the git commands from the cli (git fetch/pull/push/rebase/reset etc...)
Ok, thank you!
Hello Fabio!
I put the tag 1.1.6, but gbp import-ref -u1.1.6
returned the error: Import of upstream/1.1.6 failed: Error while executing git tag: fatal: Failed to resolve "upstream/1.1.6^0" as a link.
.
The 1.1.6 tag seems ok, I suppose you have issue on your local git, I suggest cloning the repository in a new folder to have a clean and correct local copy
@bigbigmdm In https://mentors.debian.net/package/imsprog/ you missed enabling "sponsor need" flag
Thank you, Fabio, for helping me! I'm very grateful to you!
@bigbigmdm Some other small fixes d/copyright I hope is now ok, ftp-master will do deep check before accept new package in Debian repository
I think you can try to do a new upload to mentors after merge this, but without do a new release (with only packaging fixes and improvement can be done only when all finished and ok)