Aw: [opensuse-packaging] Re: [opensuse-factory] Use of _service file
Gesendet: Montag, 15. August 2016 um 16:22 Uhr Von: "Bjoern Voigt" <bjoernv@arcor.de> An: opensuse-packaging@opensuse.org Betreff: [opensuse-packaging] Re: [opensuse-factory] Use of _service file
Axel Braun wrote:
_service file is a conveniant way to manage sources for a package automatically: Change the version number in the spec file, and it gets downloaded automatically. Unfortunately this is not allowed in many devel-repos or in Factory. That means additionally I have to provide the source-tarball OR run someting
Hi, like
osc service localrun download_files Personally I think, that _service files provide a slightly better security and I wonder, why the a bit more secure solution is forbidden in many devel-repos. It's easier to monitor small _service files than big tarballs for modifications.
Regardless of the tarball source (upload from a developer or download by OBS via _service file), I think, that the tarballs should be verified with GPG keys or SHA checksums. This verification is enabled in some Factory packages, but not in all.
That makes perfectly sense.
See the discussion here: [opensuse-factory] Build service and checksums for source code archive verification https://lists.opensuse.org/opensuse-factory/2016-08/msg00213.html
But coming back to the original scope of the mail - why automatic service runs are not allowed in Factory. I would have expected the whole community of package maintainers to step-up and grill me. Except Björn's comment I saw a mail from Oliver https://lists.opensuse.org/opensuse-factory/2016-08/msg00428.html complaining basically about the same fact. So, if we dont have hard reasons to give away this nice feature , why cant we enable it by default? Or at least, not complain about it in factory? Cheers Axel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 26 August 2016 21:54:02 Axel Braun wrote:
Hi,
Gesendet: Montag, 15. August 2016 um 16:22 Uhr […] But coming back to the original scope of the mail - why automatic service runs are not allowed in Factory. I would have expected the whole community of package maintainers to step-up and grill me. Except Björn's comment I saw a mail from Oliver https://lists.opensuse.org/opensuse-factory/2016-08/msg00428.html complaining basically about the same fact.
ah, ok. so maybe because of unsuitable mailing list I did not get many answers yet. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, 2016-08-26 at 21:54 +0200, Axel Braun wrote:
Regardless of the tarball source (upload from a developer or download by OBS via _service file), I think, that the tarballs should be verified with GPG keys or SHA checksums. This verification is enabled in some Factory packages, but not in all.
That makes perfectly sense.
Not all upstreams provide a signature - for the ones that do, I agree, we should use them. But it's at the maintainers to verify that there ARE signatures and use them. The infrastructure is ready - sigs are verified upon submission to Factory and as the package can't change there without a submission, it's gauranteed to stay valid (but can of cource be verified at any given point in time)
See the discussion here: [opensuse-factory] Build service and checksums for source code archive verification https://lists.opensuse.org/opensuse-factory/2016-08/msg00213.html
But coming back to the original scope of the mail - why automatic service runs are not allowed in Factory. I would have expected the whole community of package maintainers to step-up and grill me. Except Björn's comment I saw a mail from Oliver https://lists.opensuse.org/opensuse-factory/2016-08/msg00428.html complaining basically about the same fact.
So, if we dont have hard reasons to give away this nice feature , why cant we enable it by default? Or at least, not complain about it in factory?
For Factory it's a no-go: we have to guarantee that source will never change except by means of a submission from a devel project. With enabled services we risk that any given package might just 'updated to latest git master' (possibly involving user error, but still). You have to understand that any such thing would more than just invalidate the entire staging and pre-integration testing workflows we do. Services can be a great aid - but I don't see them fit in maintaining a project like Tumbleweed. Cheers, Dominique
Am 27. August 2016 11:52:25 MESZ, schrieb Dominique Leuenberger / DimStar <dimstar@opensuse.org>:
On Fri, 2016-08-26 at 21:54 +0200, Axel Braun wrote:
Regardless of the tarball source (upload from a developer or download by OBS via _service file), I think, that the tarballs should be verified with GPG keys or SHA checksums. This verification is enabled in some Factory packages, but not in all.
That makes perfectly sense.
Not all upstreams provide a signature - for the ones that do, I agree, we should use them. But it's at the maintainers to verify that there ARE signatures and use them.
Can you point me to a how-to or some documentation?
The infrastructure is ready - sigs are verified upon submission to Factory and as the package can't change there without a submission, it's gauranteed to stay valid (but can of cource be verified at any given point in time)
See the discussion here: [opensuse-factory] Build service and checksums for source code archive verification https://lists.opensuse.org/opensuse-factory/2016-08/msg00213.html
But coming back to the original scope of the mail - why automatic service runs are not allowed in Factory. I would have expected the whole community of package maintainers to step-up and grill me. Except Björn's comment I saw a mail from Oliver https://lists.opensuse.org/opensuse-factory/2016-08/msg00428.html complaining basically about the same fact.
So, if we dont have hard reasons to give away this nice feature , why cant we enable it by default? Or at least, not complain about it in factory?
For Factory it's a no-go: we have to guarantee that source will never change except by means of a submission from a devel project. With enabled services we risk that any given package might just 'updated to latest git master' (possibly involving user error, but still). You have to understand that any such thing would more than just invalidate the entire staging and pre-integration testing workflows we do.
For git, agree that may be an issue. For the packages I maintain there is a distinct version number, so it does not change 'by chance', only by purpose in the spec-file. I don't see that a service download would do harm
Services can be a great aid - but I don't see them fit in maintaining a project like Tumbleweed.
They can reduce workload dramatically: each supported version of Tryton (currently 6) has around 100 packages, where around 20% of them receive a monthly bugfix, resulting in a new minor version. Only 1 version should go to factory in the future, but the additional effort for local package handling does not really make me happy.... :-( Viele Grüße Axel Braun -- Diese Nachricht wurde von meinem Android-Tablet mit K-9 Mail gesendet. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, 2016-08-27 at 14:25 +0200, Axel Braun wrote:
Not all upstreams provide a signature - for the ones that do, I agree, we should use them. But it's at the maintainers to verify that there ARE signatures and use them.
Can you point me to a how-to or some documentation?
https://en.opensuse.org/openSUSE:Package_source_verification is the best I could find within 30s of searching :)
For Factory it's a no-go: we have to guarantee that source will never change except by means of a submission from a devel project. With enabled services we risk that any given package might just 'updated to latest git master' (possibly involving user error, but still). You have to understand that any such thing would more than just invalidate the entire staging and pre-integration testing workflows we do.
For git, agree that may be an issue. For the packages I maintain there is a distinct version number, so it does not change 'by chance', only by purpose in the spec-file. I don't see that a service download would do harm
I'm almost ready to guarantee that you will have move fun with a local script that happens to update all your 100 packages' spec files, .changes files and downloads the tarballs, ready to inject them into the package, than modifying all those files in the webui. What would happen if the tarball on the server changes in between service runs? They should not - but I have seen cases where it happens.
Services can be a great aid - but I don't see them fit in maintaining a project like Tumbleweed.
They can reduce workload dramatically: each supported version of Tryton (currently 6) has around 100 packages, where around 20% of them receive a monthly bugfix, resulting in a new minor version. Only 1 version should go to factory in the future, but the additional effort for local package handling does not really make me happy.... :-(
See above. With 100 packages linked together, the webui will prove the most inefficient of ways to handle the load. Cheers, Dominique
On 08/27/2016 09:55 PM, Axel Braun wrote:
Am 27. August 2016 11:52:25 MESZ, schrieb Dominique Leuenberger / DimStar <dimstar@opensuse.org>:
On Fri, 2016-08-26 at 21:54 +0200, Axel Braun wrote:
Regardless of the tarball source (upload from a developer or download by OBS via _service file), I think, that the tarballs should be verified with GPG keys or SHA checksums. This verification is enabled in some Factory packages, but not in all.
That makes perfectly sense.
Not all upstreams provide a signature - for the ones that do, I agree, we should use them. But it's at the maintainers to verify that there ARE signatures and use them.
Can you point me to a how-to or some documentation?
The infrastructure is ready - sigs are verified upon submission to Factory and as the package can't change there without a submission, it's gauranteed to stay valid (but can of cource be verified at any given point in time)
See the discussion here: [opensuse-factory] Build service and checksums for source code archive verification https://lists.opensuse.org/opensuse-factory/2016-08/msg00213.html
But coming back to the original scope of the mail - why automatic service runs are not allowed in Factory. I would have expected the whole community of package maintainers to step-up and grill me. Except Björn's comment I saw a mail from Oliver https://lists.opensuse.org/opensuse-factory/2016-08/msg00428.html complaining basically about the same fact.
So, if we dont have hard reasons to give away this nice feature , why cant we enable it by default? Or at least, not complain about it in factory?
For Factory it's a no-go: we have to guarantee that source will never change except by means of a submission from a devel project. With enabled services we risk that any given package might just 'updated to latest git master' (possibly involving user error, but still). You have to understand that any such thing would more than just invalidate the entire staging and pre-integration testing workflows we do.
For git, agree that may be an issue. For the packages I maintain there is a distinct version number, so it does not change 'by chance', only by purpose in the spec-file. I don't see that a service download would do harm
Services can be a great aid - but I don't see them fit in maintaining a project like Tumbleweed.
They can reduce workload dramatically: each supported version of Tryton (currently 6) has around 100 packages, where around 20% of them receive a monthly bugfix, resulting in a new minor version. Only 1 version should go to factory in the future, but the additional effort for local package handling does not really make me happy.... :-(
Viele Grüße Axel Braun
Well theoretically maintainers should test there new packages from the devel repo before submitting them to openSUSE:Factory so that an update that causes a crash on startup is caught and never sent to factory. As for the local handling if you changed your services to localonly you should be able to write a pretty simple bash script like below (not valid bash syntax because i'm lazy)to do the bulk of the work. for DIR in $Repo pushd $DIR osc vc -m "Scripted Version bump" osc commit -m "Scripted Version bump popd $DIR end Now someone can probably improve on that for example getting a sha256sum of the existing tarball running "osc build" to run the service then only updating the changelog and committing if there is a change would be much better, at that point some simple commandline magic might also be able to extract the version number to include in the commit message and changelog. That has the downside of needing to build everything locally though which may take time so "osc service" might be an answer I just didn't look at how to use it yet. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
participants (4)
-
Axel Braun -
Dominique Leuenberger / DimStar -
Oliver Kurz -
Simon Lees