Overview
Request 1082916 accepted
- disable MemoryDenyWriteExecute as it is incompatible with
libpcre2 in openSUSE and SLE
- restore access to git in apparmor profile. this is a git
service after all
- Created by dirkmueller
- In state accepted
-
Package maintainer:
ecsos
- Supersedes 1080183
And please stop your request. I don't like it. I want docs, I want my service. And I use this as is since many years. Please accept it.
you can continue to use your service, it works the same way like before. the only difference is that the origin of the documentation tarball is listed in the spec file.
And you don't answer my questions. And after your last changes the package could not build for many times. And you does not read and correct my comments. So I can not trust your changes.
which questions did you have? where did you submit your questions? I don't see any question from you anywhere.
Request History
dirkmueller created request
- disable MemoryDenyWriteExecute as it is incompatible with
libpcre2 in openSUSE and SLE
- restore access to git in apparmor profile. this is a git
service after all
ecsos declined request
You does not answer my questions again and again and you does not use the correct code.
dirkmueller reopened request
I cannot parse "you does not use the correct code.", sorry. which code is incorrect where? the change works and is tested.
ecsos accepted request
Question again. Do you have install and test the package again? Your last changes are broken gitea to start.
of course I've tested it. Here's how
$ cat Dockerfile FROM bci/bci-init:15.4 RUN zypper -n ar -f -G https://download.opensuse.org/repositories/home:/dirkmueller:/Factory/15.4/ repo-dirkmueller RUN zypper -n in --no-recommends gitea RUN systemctl enable gitea.service $ podman build . --gitea-test $ podman run -t gitea-test ... [ OK ] Started D-Bus System Message Bus. [ OK ] Started Gitea (Git with a cup of tea). Starting User Login Management... Starting Permit User Sessions... [ OK ] Finished Permit User Sessions. [ OK ] Started Console Getty. [ OK ] Reached target Login Prompts. [ OK ] Started User Login Management. [ OK ] Reached target Multi-User System. [ OK ] Reached target Graphical Interface. Starting Record Runlevel Change in UTMP... [ OK ] Finished Record Runlevel Change in UTMP. 9dd47292af6a login:Also, the code is deployed on https://gitea.opensuse.org/ for about a month already and is working fine there.
As a devel project maintainer I have to say that I am not happy with what is going here - request is declined for reasons that are understandable only to declining party, current maintainer states that questions are not answered where there are no questions raised
@ecsos either communicate technical reasons you see for not accepting request or accept request. Pleas refrain from statements such as "And please stop your request. I don't like it." - thats not respectful and collaborative way to do stuff in openSUSE
Consider this final warning before I remove you as maintainer of this package.
I think I make it quite clear why I do not accept. Also I did not reject immediately. But only after a few days no reaction from him came.
My reasons were:
1) The code which Dirk uses as a basis for his changes does not correspond to the code which is in devel:tools:scm. You can see it very well online . He only has to make an osc co devel:tools:scm. And in it his changes. But he should know that?
2) Then I ask him if he has installed gitea from scratch, for example in a VM and he can start gitea there. So in a clean system. But there is no answer from him. I ask not without reason. Because in the past a change from him led to the fact that one could not start gitea any more.
So how can I present my reason for refusal even better?
PS: Why I am so meticulous is also due to the fact that there are many packages that simply do not run, especially when it comes to server software. And I have for the server packages that I maintain, the claim that these really run.
And I don't let myself be threatened at all. I had started the package. And I am, at least still, the maintainer. And I attach importance to the fact that the packages also run. If that is not desired, then they just deprive me of the rights if it is fun.
This is now a cronyism here that is unbelievable.
How exactly are the changes submitted here an issue? How could making hardening rules for apparmor and systemd more relaxed cause gitea to stop working?
Obviously Dirk has tested them and even shows sort of evidence of running gitea in fresh environment as well on production system which is used.
"And I don't let myself be threatened at all." - thats good as noone is threatening you here
"I had started the package" - noone is taking credit for this from you
"And I am, at least still, the maintainer." - sure, maintainer is however not owner of package
"And I attach importance to the fact that the packages also run. If that is not desired, then they just deprive me of the rights if it is fun." - I dont think that Dirk has intentions to make gitea into something that is not working, I also dont see why any of this should be fun for anyone involved
"This is now a cronyism here that is unbelievable." - I am not going to dignify this statement with response
Once again. The error at that time, errors can always happen, prevented the application from starting. I had also been able to recreate this in a clean VM. Only after I took an older systemd service file, gitea could be started again. The problem had not only myself, but also others.
Therefore the request to test the whole thing in a new, clean VM. And to get the code from devel:tools:scm. If both are positive, nothing stands in the way of accepting.
Hi @ecsos, appreciate the more verbose reply. here's my response
on 1) the changes were tested on top of devel:tools:scm at the time I submitted them. the fact that the changes file evolves further should not stop the submission from being accepted. it is perfectly okay to merge. accepting the SR will do the right thing.
2) I accept full blame for breaking the start of gitea on a single change on a single occasion. the issue did not occur on my system because I have ACME enabled. it only happened on ACME disabled systems and was quickly remediated by somebody else already. I am testing on "clean" systems as well as "in-place upgrade of prod systems" before submitting my changes to be sure. plus these changes are actually making things less restrictive, hence have less changes of breaking something.
we're both aiming for this to be and stay a high quality package. in fact many of my submissions are aiming to make the package ready for maintenance in openSUSE Tumbleweed. I'd appreciate your support in making that a reality (where openqa tests could test many things including starting the service on fresh installed systems automaticaly).