Hello, I'm sending this email out to tell you about a new package I'm submitting to Factory from devel:tools:scm. I'm submitting gh, the official cli for GitHub. The application can interface with GitHub-specific features that git alone cannot. The package is comparable to hub, but has an entirely new codebase programmed in Go, has the official support of GitHub, and is marketed as an official interface to their platform, as opposed to a wrapper. Considering this, gh is a very worthwhile and important addition to the openSUSE distribution. The maintenance workload is minimal. So far in maintaining the package, an upgrade only requires running the service file to update the source archive and the go modules included in vendor.tar.gz. Aside from the switch from tar_scm to obs_scm for fetching the source from the official repo, there have been no significant issues. I would be happy to take on maintainership myself, as a newbie it will probably help me be able to maintain further packages in future. I will be submitting a SR for this package to Factory shortly after this message is sent. OBS: https://build.opensuse.org/package/show/devel:tools:scm/gh <https://build.opensuse.org/package/show/devel:tools:scm/gh> Upstream: https://cli.github.com/ <https://cli.github.com/> Git repo: https://github.com/cli/cli <https://github.com/cli/cli> - Emily (nopeinomicon)
After submitting the SR the auto review denied the package, so I've switched back to tar_scm to comply with it. Feel free to disregard anything about obs_scm in the previous message. - Emily (nopeinomicon)
On 07.12.20 06:51, Emily Roberts wrote:
After submitting the SR the auto review denied the package, so I've switched back to tar_scm to comply with it. Feel free to disregard anything about obs_scm in the previous message.
Haha, again a crazy bot running amok: Output of check script: Source validator failed. Try "osc service localrun source_validator" (E) gh-1.3.1.tar.gz mentioned in spec file does not exist. Of course it does not exist: <service name="tar" mode="buildtime"> <param name="filename">gh-1.3.1</param> </service> <service name="recompress" mode="buildtime"> <param name="compression">gz</param> <param name="file">*.tar</param> </service> Or the bot just has an old version of source_validator, because it does not complain on my factory box at all. So we have once again the case of the bot causing a good package being downgraded in quality, just to comply with the bot 🤦 -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
On 12/7/20 6:43 PM, Stefan Seyfried wrote:
On 07.12.20 06:51, Emily Roberts wrote:
After submitting the SR the auto review denied the package, so I've switched back to tar_scm to comply with it. Feel free to disregard anything about obs_scm in the previous message.
Haha, again a crazy bot running amok:
Output of check script: Source validator failed. Try "osc service localrun source_validator" (E) gh-1.3.1.tar.gz mentioned in spec file does not exist.
Of course it does not exist:
<service name="tar" mode="buildtime"> <param name="filename">gh-1.3.1</param> </service> <service name="recompress" mode="buildtime"> <param name="compression">gz</param> <param name="file">*.tar</param> </service>
Or the bot just has an old version of source_validator, because it does not complain on my factory box at all.
So we have once again the case of the bot causing a good package being downgraded in quality, just to comply with the bot
🤦
No this bot is enforcing our long standing policy that source tarballs must be present in packages submitted to factory. This way we can ensure that the only way package sources can change is by another submission to factory. So for today you can leave your crusade against the bots and I guess you could replace it with a crusade against our policies although I doubt you will convince people to change this policy. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On Mon, 2020-12-07 at 09:13 +0100, Stefan Seyfried wrote:
Or the bot just has an old version of source_validator, because it does not complain on my factory box at all.
So we have once again the case of the bot causing a good package being downgraded in quality, just to comply with the bot
🤦
Oh Stefan, Ifonly you can moan about the bots. The bot has been known to acceptd the .obscpio for a long time already. The problem there is that the spec file claimed to have a gh- 1.3.1.tar.gz, but then the package had a cli-1.3.1.obscpio. And in no book will you find gh == cli So, please, before you go an a crusade against the bot because they make you follow rules, learn what they are doing. Cheers, Dominique
Am 07.12.20 um 09:31 schrieb Dominique Leuenberger / DimStar:
On Mon, 2020-12-07 at 09:13 +0100, Stefan Seyfried wrote:
Or the bot just has an old version of source_validator, because it does not complain on my factory box at all.
So we have once again the case of the bot causing a good package being downgraded in quality, just to comply with the bot
🤦
Oh Stefan,
Ifonly you can moan about the bots. The bot has been known to acceptd the .obscpio for a long time already.
The problem there is that the spec file claimed to have a gh- 1.3.1.tar.gz, but then the package had a cli-1.3.1.obscpio.
And in no book will you find gh == cli
So, please, before you go an a crusade against the bot because they make you follow rules, learn what they are doing.
The magic is the parameter in the service that renames the tar during creation - which is not taking into account. But I wonder what's the point of this rename is. Greetings, Stephan -- Lighten up, just enjoy life, smile more, laugh more, and don't get so worked up about things. Kenneth Branagh
On 07.12.20 09:31, Dominique Leuenberger / DimStar wrote:
Ifonly you can moan about the bots. The bot has been known to acceptd the .obscpio for a long time already.
The problem there is that the spec file claimed to have a gh- 1.3.1.tar.gz, but then the package had a cli-1.3.1.obscpio.
And in no book will you find gh == cli
But the recommended solution to get more information, "osc service localrun source_validator" does find it and not complain. Or is source_validator doing something completely different and its suggestion is just a random hint on things to explore when trying to have fun with OBS? ;-)
So, please, before you go an a crusade against the bot because they make you follow rules, learn what they are doing. I try to, but obviously I'm lacking information.
I don't care anymore if they complain about "my" packages, but this is a new contributor that gets distracted by, at least, misleading error messages. My suggestion for a better message would be: (E) gh-1.3.1.tar.gz mentioned in spec file does not exist (looked for: [gh-1.3.1.tar.gz, gh-1.3.1.obscpio], found: [cli-1.3.1.obscpio]) I would not have complained with such a message, as I probably would have seen that the problem is in the (complicated) renaming in the _service file, which is questionable in this case in my opinion, too. I would try to patch source_validator with better messages, but since it does not fail for me, I don't really know where to start. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
On Mon, 2020-12-07 at 12:10 +0100, Stefan Seyfried wrote:
(E) gh-1.3.1.tar.gz mentioned in spec file does not exist (looked for: [gh-1.3.1.tar.gz, gh-1.3.1.obscpio], found: [cli-1.3.1.obscpio])
But it didn't look for 'gh-1.3.1.obscpio' It looked for gh-1.3.1.tar.gz because that's precisely what was written in the specfile. Why should the source validator grok files that may not have anything to do with the service being run? any other obscpio or tar.gz|xz file might be related to other spec files in the package for example.
Am 07.12.20 um 12:28 schrieb Richard Brown:
On Mon, 2020-12-07 at 12:10 +0100, Stefan Seyfried wrote:
(E) gh-1.3.1.tar.gz mentioned in spec file does not exist (looked for: [gh-1.3.1.tar.gz, gh-1.3.1.obscpio], found: [cli-1.3.1.obscpio])
But it didn't look for 'gh-1.3.1.obscpio' But it did: https://github.com/openSUSE/obs-service-source_validator/blob/master/20-file...
Greetings, Stephan -- Lighten up, just enjoy life, smile more, laugh more, and don't get so worked up about things. Kenneth Branagh
On 07.12.20 12:28, Richard Brown wrote:
On Mon, 2020-12-07 at 12:10 +0100, Stefan Seyfried wrote:
(E) gh-1.3.1.tar.gz mentioned in spec file does not exist (looked for: [gh-1.3.1.tar.gz, gh-1.3.1.obscpio], found: [cli-1.3.1.obscpio])
But it didn't look for 'gh-1.3.1.obscpio'
It looked for gh-1.3.1.tar.gz because that's precisely what was written in the specfile.
But obs_scm providing gh-1.3.1.obscpio and buildtime tar / recompress creating gh-1.3.1.tar.gz. AFAIK from an OBS POV it is even the preferred way of doing it, because the obscpio archives are (or can be) stored in an "incremental", more storage efficient fashion. Of course you can say that we do not want that in openSUSE:Factory, but then the bot should actually complain about the _service entry not being allowed.
Why should the source validator grok files that may not have anything to do with the service being run? any other obscpio or tar.gz|xz file might be related to other spec files in the package for example.
It might help the source validator generate a useful error message. Even gcc or perl nowadays try to give meaningful messages if you "just" forgot a semicolon, instead of giving relatively useless messages for 100 lines down in the code as they did 10 years ago. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
Am 07.12.20 um 13:49 schrieb Stefan Seyfried:
On 07.12.20 12:28, Richard Brown wrote:
On Mon, 2020-12-07 at 12:10 +0100, Stefan Seyfried wrote:
(E) gh-1.3.1.tar.gz mentioned in spec file does not exist (looked for: [gh-1.3.1.tar.gz, gh-1.3.1.obscpio], found: [cli-1.3.1.obscpio])
But it didn't look for 'gh-1.3.1.obscpio'
It looked for gh-1.3.1.tar.gz because that's precisely what was written in the specfile.
But obs_scm providing gh-1.3.1.obscpio and buildtime tar / recompress creating gh-1.3.1.tar.gz.
AFAIK from an OBS POV it is even the preferred way of doing it, because the obscpio archives are (or can be) stored in an "incremental", more storage efficient fashion.
Of course you can say that we do not want that in openSUSE:Factory, but then the bot should actually complain about the _service entry not being allowed.
We have tons of packages in openSUSE:Factory using obscpio archives - just none that rename the tar on build time Greetings, Stephan -- Lighten up, just enjoy life, smile more, laugh more, and don't get so worked up about things. Kenneth Branagh
On 07.12.20 14:20, Stephan Kulow wrote:
Am 07.12.20 um 13:49 schrieb Stefan Seyfried:
On 07.12.20 12:28, Richard Brown wrote:
Of course you can say that we do not want that in openSUSE:Factory, but then the bot should actually complain about the _service entry not being allowed.
We have tons of packages in openSUSE:Factory using obscpio archives -
I know. I just answered Richard's observations that the bot or service cannot possibly know why there is no tar.gz
just none that rename the tar on build time
Yes, and I'd actually consider this not the best idea, too. But the bot or source_validator could still try to provide a better message. Even if it might seem otherwise, I'm not generally against automatic QA checks, but I'd like them to be helpful. The error message given this time has, IMHO lead to a inferior "fix" to get around the bot. The -- IMHO -- better fix would have been to not rename the file but keep obs_scm. The -- again, IMHO -- less good solution was to revert to tar_scm. (And Emily, if you are still reading ;-) You did nothing reallly wrong here, and even tar_scm is good enough to get the package flying. I am discussing with coolo and Dominique on how to improve the user experience, so the next new contributor can get a more helpful message if the bot declines the submission for this reason) Have fun! -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
Ah, yeah, just read back on the rest of the thread. I mean, what I was doing was a bit of a hamfisted workaround to compensate for the services and build process not getting the correct name for the source archive, so it's unsurprising that it would fail the QA. I'd like to transition back to obs_scm if there's a good, clean way to do so, but for now tar_scm will do. Thanks, I'll keep peeping on the thread and put a word in if need be. - Emily (nopeinomicon) On 12/7/20 6:29 AM, Stefan Seyfried wrote:
On 07.12.20 14:20, Stephan Kulow wrote:
Am 07.12.20 um 13:49 schrieb Stefan Seyfried:
On 07.12.20 12:28, Richard Brown wrote:
Of course you can say that we do not want that in openSUSE:Factory, but then the bot should actually complain about the _service entry not being allowed.
We have tons of packages in openSUSE:Factory using obscpio archives -
I know. I just answered Richard's observations that the bot or service cannot possibly know why there is no tar.gz
just none that rename the tar on build time
Yes, and I'd actually consider this not the best idea, too. But the bot or source_validator could still try to provide a better message.
Even if it might seem otherwise, I'm not generally against automatic QA checks, but I'd like them to be helpful.
The error message given this time has, IMHO lead to a inferior "fix" to get around the bot. The -- IMHO -- better fix would have been to not rename the file but keep obs_scm. The -- again, IMHO -- less good solution was to revert to tar_scm.
(And Emily, if you are still reading ;-) You did nothing reallly wrong here, and even tar_scm is good enough to get the package flying. I am discussing with coolo and Dominique on how to improve the user experience, so the next new contributor can get a more helpful message if the bot declines the submission for this reason)
Have fun!
On 12/7/20 11:43 AM, Emily Roberts wrote:
Ah, yeah, just read back on the rest of the thread. I mean, what I was doing was a bit of a hamfisted workaround to compensate for the services and build process not getting the correct name for the source archive, so it's unsurprising that it would fail the QA. I'd like to transition back to obs_scm if there's a good, clean way to do so, but for now tar_scm will do. Thanks, I'll keep peeping on the thread and put a word in if need be.
- Emily (nopeinomicon)
On 12/7/20 6:29 AM, Stefan Seyfried wrote:
On 07.12.20 14:20, Stephan Kulow wrote:
Am 07.12.20 um 13:49 schrieb Stefan Seyfried:
On 07.12.20 12:28, Richard Brown wrote:
Of course you can say that we do not want that in openSUSE:Factory, but then the bot should actually complain about the _service entry not being allowed.
We have tons of packages in openSUSE:Factory using obscpio archives -
I know. I just answered Richard's observations that the bot or service cannot possibly know why there is no tar.gz
just none that rename the tar on build time
Yes, and I'd actually consider this not the best idea, too. But the bot or source_validator could still try to provide a better message.
Even if it might seem otherwise, I'm not generally against automatic QA checks, but I'd like them to be helpful.
The error message given this time has, IMHO lead to a inferior "fix" to get around the bot. The -- IMHO -- better fix would have been to not rename the file but keep obs_scm. The -- again, IMHO -- less good solution was to revert to tar_scm.
(And Emily, if you are still reading ;-) You did nothing reallly wrong here, and even tar_scm is good enough to get the package flying. I am discussing with coolo and Dominique on how to improve the user experience, so the next new contributor can get a more helpful message if the bot declines the submission for this reason)
Have fun!
openSUSE Factory mailing list -- factory@lists.opensuse.org To unsubscribe, email factory-leave@lists.opensuse.org List Netiquette: https://en.opensuse.org/openSUSE:Mailing_list_netiquette List Archives: https://lists.opensuse.org/archives/list/factory@lists.opensuse.org
Oh, and just for more specificity to help out here, now that my memory is a bit clearer because it's the morning, I'll tell you the specific breakage I had and why I couldn't just change the filename param for obs_scm. Whenever I attempted to change that filename param, the tar service failed to find the archive, and thus I couldn't build the package that way. So that lead to me using the default repo name in obs_scm, and doing the filename switch in the tar service instead. Hope that gives some good context to help out here. Let me know if you need anything else in that department.
Am 07.12.2020 um 09:13 schrieb Stefan Seyfried:
On 07.12.20 06:51, Emily Roberts wrote:
After submitting the SR the auto review denied the package, so I've switched back to tar_scm to comply with it. Feel free to disregard anything about obs_scm in the previous message.
Haha, again a crazy bot running amok:
Output of check script: Source validator failed. Try "osc service localrun source_validator" (E) gh-1.3.1.tar.gz mentioned in spec file does not exist.
Of course it does not exist:
<service name="tar" mode="buildtime"> <param name="filename">gh-1.3.1</param> </service> <service name="recompress" mode="buildtime"> <param name="compression">gz</param> <param name="file">*.tar</param> </service>
Or the bot just has an old version of source_validator, because it does not complain on my factory box at all.
So we have once again the case of the bot causing a good package being downgraded in quality, just to comply with the bot
🤦
Just use: Source0: https://github.com/cli/cli/archive/v%{version}.tar.gz#/gh-%{version}.tar.gz This allows you to throw out all the unneccessary _service* files. Best regards, -- Johannes Weberhofer Weberhofer GmbH, Austria, Vienna
Ah, thanks everyone for the comments. I'm new to this so stuff like this is still confusing. I had the service file rename from cli to gh as gh has been the name standard for it across other package managers, and the git repo is named cli. I really have no clue the proper way to go about this, so for simplicity's sake I switched back to tar_scm as that doesn't produce the bot error, and also avoided an ongoing issue I've been having with obs_scm making the package require some python packages which are not in the repo for some odd reason. Regardless if you have any advice on how best to proceed please shoot that over to me. And Joannes, how would I be able to do that and ditch the services? Are you just suggesting a manual download of the tarball form that url, or something else? Anyway, I'm going to get some shuteye. I'll check back here in the morning. Thanks for the discussion and such. - Emily (nopeinomicon) On 12/7/20 2:24 AM, Johannes Weberhofer wrote:
Am 07.12.2020 um 09:13 schrieb Stefan Seyfried:
On 07.12.20 06:51, Emily Roberts wrote:
After submitting the SR the auto review denied the package, so I've switched back to tar_scm to comply with it. Feel free to disregard anything about obs_scm in the previous message.
Haha, again a crazy bot running amok:
Output of check script: Source validator failed. Try "osc service localrun source_validator" (E) gh-1.3.1.tar.gz mentioned in spec file does not exist.
Of course it does not exist:
<service name="tar" mode="buildtime"> <param name="filename">gh-1.3.1</param> </service> <service name="recompress" mode="buildtime"> <param name="compression">gz</param> <param name="file">*.tar</param> </service>
Or the bot just has an old version of source_validator, because it does not complain on my factory box at all.
So we have once again the case of the bot causing a good package being downgraded in quality, just to comply with the bot
🤦
Just use: Source0: https://github.com/cli/cli/archive/v%{version}.tar.gz#/gh-%{version}.tar.gz
This allows you to throw out all the unneccessary _service* files.
Best regards,
Hi, Am 07.12.20 um 11:05 schrieb Emily Roberts:
And Joannes, how would I be able to do that and ditch the services? Are you just suggesting a manual download of the tarball form that url, or something else?
Anyway, I'm going to get some shuteye. I'll check back here in the morning. Thanks for the discussion and such.
- Emily (nopeinomicon)
On 12/7/20 2:24 AM, Johannes Weberhofer wrote:
Just use: Source0: https://github.com/cli/cli/archive/v%{version}.tar.gz#/gh-%{version}.tar.gz
Until recently you could just do `osc service localrun download_files` and it would download from all Source: and Patch URLs with the right expansion of %{version} and other macros. Now you need a minimal _service file for that to work (which you don't even have to add and commit): <services><service name="download_files"></services> Or use the not very intuitive "disabledrun": https://github.com/openSUSE/osc/issues/874 Cheers, Ben
... of course the _service should be a valid XML file. Sorry. <services><service name="download_files" /></services>
On Monday 2020-12-07 10:24, Johannes Weberhofer wrote:
Just use: Source0: https://github.com/cli/cli/archive/v%{version}.tar.gz#/gh-%{version}.tar.gz
This allows you to throw out all the unneccessary _service* files.
You don't even need the # part. Just Source: https://github.com/cli/cli/archive/v%{version}.tar.gz %setup -n cli-%{version} Done deal.
Am 07.12.20 um 21:07 schrieb Jan Engelhardt:
On Monday 2020-12-07 10:24, Johannes Weberhofer wrote:
Just use: Source0: https://github.com/cli/cli/archive/v%{version}.tar.gz#/gh-%{version}.tar.gz
This allows you to throw out all the unneccessary _service* files. You don't even need the # part. Just
Source: https://github.com/cli/cli/archive/v%{version}.tar.gz %setup -n cli-%{version}
Done deal.
But it is nice to have a properly named source file. v1.0.0.tar.gz is not really a speaking name.
On Dez 07 2020, Jan Engelhardt wrote:
On Monday 2020-12-07 10:24, Johannes Weberhofer wrote:
Just use: Source0: https://github.com/cli/cli/archive/v%{version}.tar.gz#/gh-%{version}.tar.gz
This allows you to throw out all the unneccessary _service* files.
You don't even need the # part. Just
Source: https://github.com/cli/cli/archive/v%{version}.tar.gz %setup -n cli-%{version}
It is preferrable to name the tarfile after the package name. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
On 12/8/20 1:03 PM, Andreas Schwab wrote:
On Dez 07 2020, Jan Engelhardt wrote:
Source: https://github.com/cli/cli/archive/v%{version}.tar.gz %setup -n cli-%{version}
It is preferrable to name the tarfile after the package name.
This would also be my personal preference. But I see that many packages get changed to Source: v%{version}.tar.*. Is there a written package guide-line regarding Source:? Ciao, Michael.
On Tue, 2020-12-08 at 13:17 +0100, Michael Ströder wrote:
On 12/8/20 1:03 PM, Andreas Schwab wrote:
On Dez 07 2020, Jan Engelhardt wrote:
Source: https://github.com/cli/cli/archive/v%{version}.tar.gz %setup -n cli-%{version}
It is preferrable to name the tarfile after the package name.
This would also be my personal preference.
But I see that many packages get changed to Source: v%{version}.tar.*.
Is there a written package guide-line regarding Source:?
https://en.opensuse.org/openSUSE:Specfile_guidelines#Metadata_Tags The guideline only says that a full URL is preferred, no word about preference of renaming files. The 2nd best (which is not explicitly stated - should probably add it) is a _Service file, that still allows to verify the source of the code matches what is being submitted. Cheers, Dominique
On Tuesday 2020-12-08 13:03, Andreas Schwab wrote:
Just use: Source0: https://github.com/cli/cli/archive/v%{version}.tar.gz#/gh-%{version}.tar.gz
This allows you to throw out all the unneccessary _service* files.
You don't even need the # part. Just
Source: https://github.com/cli/cli/archive/v%{version}.tar.gz %setup -n cli-%{version}
It is preferrable to name the tarfile after the package name.
Your preference, my preference.
participants (11)
-
Andreas Schwab -
Ben Greiner -
Dominique Leuenberger / DimStar -
Emily Roberts -
Jan Engelhardt -
Johannes Weberhofer -
Michael Ströder -
Richard Brown -
Simon Lees -
Stefan Seyfried -
Stephan Kulow