Bugzilla – Bug 1218579
cargo_vendor source service does not work when run server-side
Last modified: 2024-05-15 06:38:41 UTC
Created attachment 871679 [details] local cargo_vendor cargo_vendor work in local `osc service ra`, but failed in OBS. error: > Files could not be expanded: service error: 400 remote error: cargo_vendor service parameter "srctar" is not defined (http://obs-gateway:5153/sourceupdate/home:Werwolf2517/Alfis?timeout=7200) less info > service daemon error: > 400 remote error: cargo_vendor service parameter "srctar" is not defined (http://obs-gateway:5153/sourceupdate/home:Werwolf2517/Alfis?timeout=7200) i try src, srctar, srcdir. in my local machine all works, but in OBS always i get this error For a long time I thought I was doing something wrong, but now I'm sure it's not me.
The project on which the error is being reproduced right now: https://build.opensuse.org/package/show/home:Werwolf2517/Alfis
The cargo-vendor developers don't support the OBS deployment. As a result, this is an OBS bug, reassigning.
To explain better: * I don't have visibility into why it's breaking on OBS * I don't have any way to *test* fixes on OBS * I don't know how it's configured as there is no documentation As a result, I'm powerless to actually help here. This is why it's up to the OBS team to investigate and PR for any issues they have with cargo_vendor on the server side. I can only test and fix things on a local check with osc.
(In reply to William Brown from comment #3) > To explain better: > > * I don't have visibility into why it's breaking on OBS > * I don't have any way to *test* fixes on OBS > * I don't know how it's configured as there is no documentation > > As a result, I'm powerless to actually help here. This is why it's up to the > OBS team to investigate and PR for any issues they have with cargo_vendor on > the server side. > > I can only test and fix things on a local check with osc. sorry, my english is not very good. I don’t understand: does this mean that there will be no correction?
(In reply to Dmitry Markov from comment #4) > (In reply to William Brown from comment #3) > > To explain better: > > > > * I don't have visibility into why it's breaking on OBS > > * I don't have any way to *test* fixes on OBS > > * I don't know how it's configured as there is no documentation > > > > As a result, I'm powerless to actually help here. This is why it's up to the > > OBS team to investigate and PR for any issues they have with cargo_vendor on > > the server side. > > > > I can only test and fix things on a local check with osc. > > sorry, my english is not very good. I don’t understand: does this mean that > there will be no correction? I have assigned it to the team that needs to fix it.
I apologize for having the impudence to remind you of the current problem, but it seems to me that this is a very important problem, I would like to know if there are any changes?
I would like to know if there will be any reaction to this bug report? The amount of software on rust is increasing every day and the lack of a working cargo_vendor service on the server side increases the amount of useless traffic.
This has been open for 6 months - you have a community member that wants a response. Please provide it.
is there any news on this report? Quite a lot of time has passed, I would like to know if a fix is planned or if this should not work..
Some random observations: * the "cargo_vendor" OBS source service comes from the binary RPM obs-service-cargo_vendor * the obs-service-cargo_vendor binary RPM is built from the obs-service-cargo_vendor source package in OBS/IBS * there is no obs-service-cargo_vendor source package in openSUSE:Factory * there is https://build.opensuse.org/package/show/devel:languages:rust/obs-service-cargo_vendor but the build is broken for all repos, probably because the package got dropped from Factory?
(In reply to Nathan Cutler from comment #10) > Some random observations: > > * the "cargo_vendor" OBS source service comes from the binary RPM > obs-service-cargo_vendor > > * the obs-service-cargo_vendor binary RPM is built from the > obs-service-cargo_vendor source package in OBS/IBS > > * there is no obs-service-cargo_vendor source package in openSUSE:Factory > > * there is > https://build.opensuse.org/package/show/devel:languages:rust/obs-service- > cargo_vendor but the build is broken for all repos, probably because the > package got dropped from Factory? As far as I understand, all `obs-service-cargo_*` have been replaced with `obs-service-cargo`. I had to make some changes to `_service`, and locally everything works. however, on OBS the problem remains relevant. Here is an example `_service` to reproduce: > <?xml version="1.0"?> > <services> > <service name="tar_scm" mode="trylocal"> > <param name="url">https://github.com/Revertron/Alfis</param> > <param name="scm">git</param> > <param name="exclude">.git</param> > <param name="revision">v0.8.4</param> > <param name="versionformat">@PARENT_TAG@</param> > <param name="changesgenerate">enable</param> > <param name="versionrewrite-pattern">v((\d+\.\d+\.\d+))</param> > <param name="filename">Alfis</param> > </service> > <service name="set_version" mode="trylocal"> > <param name="basename">Alfis</param> > </service> > <service name="recompress" mode="trylocal"> > <param name="file">*.tar</param> > <param name="compression">zst</param> > </service> > <service name="cargo_vendor" mode="trylocal"> > <param name="srctar">Alfis-*.tar.zst</param> > <param name="i-accept-the-risk">RUSTSEC-2022-0093</param> > <param name="compression">zst</param> > </service> > </services> > if you replace `trylocal` with `manual` then local vendoring will proceed normally, but in this case both vendor and source archives will be provided not by OBS who is trusted, but by me personally, and I am an outsider and should not inspire trust among people. This is why I consider this report critically important. Moreover, I would vote for ALL packages to be compiled from sources obtained by OBS itself through the `_service` and not by push maintainers.
OK, now I will correct what I wrote in the previous comment: * in Factory, the "cargo_vendor" OBS source service comes from the binary RPM "obs-service-cargo" * the obs-service-cargo binary RPM is built from the obs-service-cargo source package in: https://build.opensuse.org/package/show/openSUSE:Factory/obs-service-cargo https://build.opensuse.org/package/show/devel:languages:rust/obs-service-cargo * the current version is 1.3.2 * the source code of obs-service-cargo is maintained at https://github.com/openSUSE/obs-service-cargo_vendor
> if you replace `trylocal` with `manual` then local vendoring will > proceed normally There is also https://en.opensuse.org/openSUSE:Packaging_Rust_Software which instructs folks to use mode="disabled" in the _service file. Of course, mode="disabled" is the predecessor of mode="manual". So my understanding is: this bug is not about not being able to use the cargo_vendor source service in OBS, but rather that it doesn't work when you try to run it server-side, and you don't want to run it locally for your own reasons. The current bug title "cargo_vendor serice fail" is rather vague and doesn't really describe the bug you are actually reporting. Would it make sense to change it to something like "cargo_vendor source service does not work when run server-side"?
> I would like to know if a fix is planned or if this should not work.. As far as I can tell, there is no fix forthcoming for the server-side cargo_vendor. You should run it locally.
(In reply to Nathan Cutler from comment #14) > > I would like to know if a fix is planned or if this should not work.. > > As far as I can tell, there is no fix forthcoming for the server-side > cargo_vendor. You should run it locally. The problem is as I said before - we can't support it on the server side from the community, it's up to the OBS team to support running it server side as we have no visibility into OBS and no way to make effective changes. Since there is no response from OBS developers about this I think it has to be closed unless the OBS team themself are willing to step up to make this work.
(In reply to Nathan Cutler from comment #13) > The current bug title "cargo_vendor serice fail" is rather vague and doesn't > really describe the bug you are actually reporting. Would it make sense to > change it to something like "cargo_vendor source service does not work when > run server-side"? Sorry, my level of English is not high.
Don't worry Dmitri, it's okay :)
(In reply to William Brown from comment #15) > (In reply to Nathan Cutler from comment #14) > > > I would like to know if a fix is planned or if this should not work.. > > > > As far as I can tell, there is no fix forthcoming for the server-side > > cargo_vendor. You should run it locally. > > The problem is as I said before - we can't support it on the server side > from the community, it's up to the OBS team to support running it server > side as we have no visibility into OBS and no way to make effective changes. > Since there is no response from OBS developers about this I think it has to > be closed unless the OBS team themself are willing to step up to make this > work. please tell me where to write with this question. in my opinion, this is a big problem that affects both convenience and security issues of the code base.
> please tell me where to write with this question. in my opinion, this is a > big problem that affects both convenience and security issues of the code > base. Sadly, the answer is "this bugzilla". But given that there was no response from the OBS team in 6 months, and in other channels where I made it clear to them that they need to support it and there has been no action then I think this is where we have to leave it.
(In reply to William Brown from comment #19) > > please tell me where to write with this question. in my opinion, this is a > > big problem that affects both convenience and security issues of the code > > base. > > Sadly, the answer is "this bugzilla". But given that there was no response > from the OBS team in 6 months, and in other channels where I made it clear > to them that they need to support it and there has been no action then I > think this is where we have to leave it. Forgive me for my meticulousness, but in this case I see no reason to put the "RESOLVED WONTFIX" mark on the report. There is a problem, and it has not been solved. Perhaps later those responsible for this issue will have time to resolve it. but a solution will definitely not appear if this report is forgotten.
sorry, went under my radar after the long december vacation. However, right now, I can not enable it as there is no package in openSUSE:Tools anymore. feel free to submit a current package there again if you want to have it enabled again. However, we also need to think about how to manage rust sources when switching to git ...
(In reply to Adrian Schröter from comment #21) > sorry, went under my radar after the long december vacation. > > However, right now, I can not enable it as there is no package in > openSUSE:Tools anymore. > > feel free to submit a current package there again if you want to have it > enabled again. > > However, we also need to think about how to manage rust sources when > switching to git ... thanks for the answer, I'll give it a try right now: https://build.opensuse.org/request/show/1174122