[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Help packaging an octave toolbox



On 6/18/20 12:58 PM, Rafael Laboissière wrote:
It seems there is no way to do this in GitLab.  I just created the master branch in the octave-jsonlab repository.  I am afraid you will have to clone the repository, instead of working on your current local repository.

At any rate, I see two commits that you pushed onto the repository:

 https://salsa.debian.org/pkg-octave-team/octave-jsonlab/-/commit/ed79c04e8b4f2e3194b07d23f1f2b376c6536014
 https://salsa.debian.org/pkg-octave-team/octave-jsonlab/-/commit/06b39d94e299ab5ff45c0527d4e9eb9398c38463

These two commits are very strange, because they are floating (they are on no branch). Perhaps, you have them associate with your local master branch. Anyway, this looks quite strange to me.


yes, I saw your newly created master branch and was trying to upload again, it now shows the following error


fangq@invocation:~/space/git/Temp/pkg/octave-jsonlab$ git push
Counting objects: 87, done.
Delta compression using up to 16 threads.
Compressing objects: 100% (80/80), done.
Writing objects: 100% (87/87), 126.53 KiB | 5.75 MiB/s, done.
Total 87 (delta 26), reused 0 (delta 0)
remote: GitLab: You are not allowed to push code to protected branches on this project.
To https://salsa.debian.org/pkg-octave-team/octave-jsonlab.git
 ! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'https://salsa.debian.org/pkg-octave-team/octave-jsonlab.git'

the master branch is protected in gitlab by default, the repo owner must go to Settings to remove the protection before a developer can push to the master, see

https://stackoverflow.com/questions/42073357/remote-gitlab-you-are-not-allowed-to-push-code-to-protected-branches-on-this-p?noredirect=1&lq=1#:~:text=In%20GitLab%20some%20branches%20can,on%20%22Protected%20branches%22%20).


yes, the two tags were pushed accidentally when I tried various things I found on the website, particularly, by calling the below command

git push --set-upstream git@salsa.debian.org:pkg-octave-team/octave-jsonlab.git : --tags

I just deleted both tags and the repo is ok now.


Furthermore, these commits are tagged "upstream/2.0" and "debian/2.0-1", respectively. The former tag is suspicious, but the later is incorrect, because "debian/*" tags should point to commits that correspond to the versions of the package that have been uploaded to unstable .  Besides, the first line of the associated debian/changelog file should have "unstable" instead of "UNRELEASED".

I am afraid you will have to start from scratch with this repository.


done, as long as the master protection is lifted, I will push it to salsa.



Please, tell me which other repositories you have created under the DOG Salsa space. I will create master branches for them, before you start working on the associated packages.


there are two more:

https://salsa.debian.org/pkg-octave-team/octave-jnifti

https://salsa.debian.org/pkg-octave-team/zmat

if possible, please create master branch and set it unprotected, I should be able to upload my packaging files.


thanks a lot!



is this acceptable as the "upstream" branch in the gbp created repo? or "upstream" must store exactly the same files as in the upstream tarball (such as the released source code tarball on github)?
Your package falls perhaps in this case:
https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#repackaged-upstream-source

ok, I will try to use the *override_dh_auto_configure* section to do all pre-installation changes and keep the upstream tarball unaltered.

I would rather repack the tarball, but do whatever fits you better.

Best,

Rafael

Reply to: