Closed Fantu closed 7 months ago
Thank you, Fabio! Everything works well!
If sure is ok, you can for example release 1.1.5, if you want.
For Debian packaging, if there will be to wait for new version, but there are important fixes need patches must be imported in debian/patches, latest commit in debian/latest are wrong and must be removed.
With unofficial builds (for example on ppa) you can also do bad things, against policies (https://www.debian.org/doc/debian-policy/) or even packages that update correctly or cause conflicts with others that there are not enough checks and blocks while those that will go to the official repositories must follow the policies and pass several checks.
You will learn over time, as I have learned in these 10 years of contributing to various Debian packages, and I never stop learning.
For now, explaining easy, on debian/latest need git reset --hard fb224c27f9972c450ad888983329ceac0145d04d
(to remove wrong commits), use git push with "-f" for override (for now that it has not yet been released and perhaps not used by others this branch can still be used, on used branches however forced pushes are to be avoided).
If you release 1.1.5, after the remove of wrong commit, on debian/latest to import the new version use gbp import-ref -u1.1.5
and change version in debian/changelog (like what I did in https://github.com/bigbigmdm/IMSProg/commit/4cceb700e3eaf853961a1d75710a817e2d799c16).
If you don't release, to apply patches to debian/patches use can do manually with quilt or easier/fast with gbp pq
$ gbp pq import
$ git cherry-pick any_upstream_commit
$ gbp pq export
(patches branch should not be push and when finished can be removed with gbp pq drop
)
In your case, probably d/patches I suppose can be used rarely, for example for applying bugfix only (if important fixes are needed for stable proposed updates) or for release fixes when there is freeze period near new debian/ubuntu release.
Fabio, please tell me:
Why can't the imsprog (1.1.4-2) UNRELEASED; urgency=medium
version be used?
Why is it necessary to release 1.1.5?
Can't be 1.1.4-2 because 1.1.4-1 was not released (on Debian), so version will be 1.1.4-1 in both case. About the case of not release 1.1.5 but apply the 2 fixes commits, I explained the correct way above. If you do changes out of debian folder without d/patches an orig tar of 1.1.4 will be generated that will be different from the real 1.1.4 and this is an RC (release critical) bug, if I remember good, if done in first upload probably sponsor don't do upload, and if sponsor don't spot it will be rejected by ftp-master when it will review the package in NEW queue. In case will be uploaded after, when spotted an RC bug is opened and if not resolved in a certain amount of time package will be removed from testing.
Fabio, is d/changelog for version 1.1.5 supposed to be like this?
imsprog (1.1.5) UNRELEASED; urgency=medium
* Initial release (Closes: #1057386)
-- Mikhail Medvedev <e-ink-reader@yandex.ru> Fri, 12 Jan 2024 13:01:00 +1000
Or should it be like this?
imsprog (1.1.5) UNRELEASED; urgency=medium
* Initial release (Closes: #1060385)
[ Fabio Fantoni ]
+ Detect udev path with pkg-config
-- Mikhail Medvedev <e-ink-reader@yandex.ru> Fri, 12 Jan 2024 13:01:00 +1000
* Initial release (Closes: #1060385)
or * Initial release (Closes: #1057386)
?
Is initial release, so list of changes (from previous version) is null, only "initial release" entry should be present. The close is of the ITP bug, so remain the same. The version should be 1.1.5-1, see https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-version
@bigbigmdm I saw the new upload but is wrong. And is wrong also 1.1.5 release :(
I already explained step to step what to do for debian/latest and about new upstream release I thinked was too easy that is not needed to explain. upstream tags should be on main branches commit, debian tags will be generated with gbp tag
and pushed only for upload accepted in official repository.
About debian/latest was explained in https://github.com/bigbigmdm/IMSProg/pull/45#issuecomment-1888695690:
For now, explaining easy, on debian/latest need git reset --hard fb224c27f9972c450ad888983329ceac0145d04d (to remove wrong commits), use git push with "-f" for override (for now that it has not yet been released and perhaps not used by others this branch can still be used, on used branches however forced pushes are to be avoided).
If you release 1.1.5, after the remove of wrong commit, on debian/latest to import the new version use gbp import-ref -u1.1.5 and change version in debian/changelog (like what I did in https://github.com/bigbigmdm/IMSProg/commit/4cceb700e3eaf853961a1d75710a817e2d799c16).
important note: before import upstream version, the tag 1.1.5 must be redone correctly about the tag was explained in the previous version https://github.com/bigbigmdm/IMSProg/pull/43#issuecomment-1879698629
Fabio, forgive me! Maybe I'm a very stupid and old man.
As you wrote, for the new release I did git reset --hard fb224c27f9972c450ad88898332329ceac0145d04d
.
Modified d/changelog
Did a commit
Added tag v1.1.5
Made commit, git push origin v1.1.5
.
And built the package.
I deleted wrong tag, delete it also locally and redone it on latest commit of "main" branch.
Before do something, check to be in the correct branch, main for upstream and debian/latest for Debian packaging, for switch use "git checkout
After the new tag fixed:
git checkout debian/latest
git reset --hard fb224c27f9972c450ad888983329ceac0145d04d
(to remove wrong commits)
gbp import-ref -u1.1.5
for import new upstream version
change version in debian/changelog (like what I did in https://github.com/bigbigmdm/IMSProg/commit/4cceb700e3eaf853961a1d75710a817e2d799c16).
use git push with "-f" for override actual debian/latest wrong on origin (for example can be git push -f origin debian/latest
)
Fabio, I think I did everything as you wrote.
Now on mentors.debian do I need to delete the latest release and upload it again?
Right tag 1.1.5 is missed, I suppose not pushed debian/latest branch is still wrong, I don't understand how is possible with step by step, push the right tag, after I'll fix debian/latest on mentors delete wrong 1.1.5-1, you'll upload the right later
edit: probably your local 1.1.5 tag is still wrong if you did git reset and after gbp import on wrong tag
for delete wrong tag git tag -d v1.1.5
after create the new right on latest commit of "main" branch and push it
Hello Fabio! I have created a v1.1.5 tag, please see if I have done everything correctly.
I also got the message "Bug#1057076 closed by Bastian Germann". Could you please tell me what this means?
Bastian Germann is a DD, sponsor many upload to mentors, have simply closed the old and wrong RFS I wrote to close. tag 1.1.5 is still wrong 😢 ... it point to debian/latest again
Thank you, Fabio! I'll try to fix that tomorrow.
Good afternoon, Fabio! I think I've done it...
1.1.5 is now at least based on main branch but is on wrong commit, is the same of 1.1.4, as you can see https://github.com/bigbigmdm/IMSProg/commit/1761b82e22dbe94c4985d94d130db922c07b5fd4:
Delete debian directory
main
v1.1.5 v1.1.4
v1.1.5 tag should point to https://github.com/bigbigmdm/IMSProg/commit/bee5b622d851e2dd671aa07580b14e3bbd56a103 instead. Or https://github.com/bigbigmdm/IMSProg/commit/21cc0424df987fe85c83556a259af5aacd7c9a4a if you want to keep 1.1.5 bugfix only and postpone the new feature for next upstream version.
About debian/latest the procedure is near correct, update of debian/changelog should be done after import of new upstream but as don't use uscan in this case (using import-ref) don't cause issue. Doing the correct procedure with the correct 1.1.5 tag it should be ok
Fabio, I'd like gag 1.1.5 to point to bee5b62
. Only I don't understand how to do it. Can you help me fix this so I can send the package to mentors.debian?
Override should be normally avoided checking what done before push to be sure to do the correct things and if needed to fix wrong thing not yet pushed can be for example using git amend on latest commit, git reset instead revert etc... Avoid to push the wrong thing and keep git history clean is the best thing.
When don't possible additional commit are used, additional tag etc...
In this case tag is and was completely wrong (before as point to wrong branch and now the same of previous version), so probably is better override it instead does a new one (1.1.6) and keep one duplicate.
If you use cli, to override the tag use -f, like when create new tag normally on latest commit,
Normally, the procedure is to switch to the correct branch (if not already selected):
git checkout main
and create the tag:
git tag <name of the tag>
optionally, you can also sign if not already setted global (-s), point to a specific commit adding its hash if not latest commit or of another branch (this can be used to be sure to do the correct point, and also you don't need to switch before)
in this case will be git tag -f v1.1.5
or git tag -f v1.1.5 bee5b622d851e2dd671aa07580b14e3bbd56a103
for push ovverring the tag you will use for example git push -f origin v1.1.5
before to be sure the tag is correct you can use git log and on the correct commit you should see something like:
commit bee5b622d851e2dd671aa07580b14e3bbd56a103 (HEAD -> main, tag: v1.1.5 ...)
or use can use also gui tools instead cli if you prefer, the most important tip is to always check before pushing
after creation of correct tag you can redone the procedure for fix debian/latest:
git checkout debian/latest
git reset --hard fb224c27f9972c450ad888983329ceac0145d04d
(to remove wrong commits)
gbp import-ref -u1.1.5
for import new upstream version
change version in debian/changelog (like what you did in https://github.com/bigbigmdm/IMSProg/commit/9757b1c8c52ecddbea9ced47621cd49b1dcc0f95).
Fabio, I did everything up to and including "git reset --hard fb224c27f9972c450ad888983323232329ceac0145d04d (to remove invalid commits)". But it turns out that the CMakeLists.txt files in /IMSProg_programmer and IMSProg_editor are lagging behind the versions in the main branch.
I have not yet executed gbp import-ref -u1.1.5
.
tag is now correct, I don't understand your issue
if you did git reset --hard fb224c27f9972c450ad888983323232329ceac0145d04d
now you should do gbp import-ref -u1.1.5
and after update of d/changelog
Ok, thank you!
Actually, I see debian/latest ok after your gbp import-ref -u1.1.5
and only d/changelog update is missed
some distro have default udev path /lib/udev up to "usr merge" where is changed to /usr/lib/udev, other distro use already /usr/lib/udev
@bigbigmdm I did this done fast, probably need improvements