Packages in OBS not configured for Factory
I have a newbie question about the decision about what targets a package in OBS are built for. I mean about the logic behind the choice of which to enable. I quite often find that packages are enabled for only 15.2, or only Tumblwweed. But it is quite common that the packages are not enabled for all current openSUSE/SUSE releases. For exampl (not a complaints against this ptroject! I just happen to be following the status of the tensorflow2 and it took me here as a unresolvable package): https://build.opensuse.org/package/show/devel%3Alanguages%3Apython/python-go... Why would a project in devel:languages:python not have Factory enabled? I know that in user's own builds, them might unfortunately do this. But in a place like devel:languages:python, I would have thought the all current openSUSE/SUSE targets would generally be enabled. If it is a 'I don't have time' thing, then I'm okay with that. No problem. I am curious if it is something else that I have just not cottoned on to. -- Roger Oberholtzer
On 8/24/22 17:43, Roger Oberholtzer wrote:
I have a newbie question about the decision about what targets a package in OBS are built for. I mean about the logic behind the choice of which to enable.
At the end of the day this is a manual decision by the maintainer of the packages / project.
I quite often find that packages are enabled for only 15.2, or only Tumblwweed. But it is quite common that the packages are not enabled for all current openSUSE/SUSE releases.
Adding new versions is a manual process so the maintainer needs to decide to do it, having 15.2 and nothing newer is probably a good sign no one is paying much attention to it.
For exampl (not a complaints against this ptroject! I just happen to be following the status of the tensorflow2 and it took me here as a unresolvable package):
https://build.opensuse.org/package/show/devel%3Alanguages%3Apython/python-go...
Why would a project in devel:languages:python not have Factory enabled? I know that in user's own builds, them might unfortunately do this. But in a place like devel:languages:python, I would have thought the all current openSUSE/SUSE targets would generally be enabled.
It has openSUSE_Tumbleweed enabled which these days is generally more useful because it only rebuilds against changes that have been accepted into snapshots as opposed to openSUSE_Factory which used to trigger rebuilds earlier in the process which occasionally causes issues for users. Most of the time using them interchangably doesn't break much. -- 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 8/24/22 03:24, Simon Lees wrote:
On 8/24/22 17:43, Roger Oberholtzer wrote:
I have a newbie question about the decision about what targets a package in OBS are built for. I mean about the logic behind the choice of which to enable.
At the end of the day this is a manual decision by the maintainer of the packages / project.
I quite often find that packages are enabled for only 15.2, or only Tumblwweed. But it is quite common that the packages are not enabled for all current openSUSE/SUSE releases.
Adding new versions is a manual process so the maintainer needs to decide to do it, having 15.2 and nothing newer is probably a good sign no one is paying much attention to it.
For exampl (not a complaints against this ptroject! I just happen to be following the status of the tensorflow2 and it took me here as a unresolvable package):
https://build.opensuse.org/package/show/devel%3Alanguages%3Apython/python-go...
Why would a project in devel:languages:python not have Factory enabled? I know that in user's own builds, them might unfortunately do this. But in a place like devel:languages:python, I would have thought the all current openSUSE/SUSE targets would generally be enabled.
It has openSUSE_Tumbleweed enabled which these days is generally more useful because it only rebuilds against changes that have been accepted into snapshots as opposed to openSUSE_Factory which used to trigger rebuilds earlier in the process which occasionally causes issues for users. Most of the time using them interchangably doesn't break much.
I think I can answer this question as the maintainer of VirtualBox, a project that is not derived from any version of SLE. Our development project is Virtualization/virtualbox. In it, all current versions of Leap as well as Tumbleweed are enabled. I branch that project and checkout that code whenever there is need to update the package. Once the code builds OK locally using osc, I check in the new code. That triggers a build for all enabled projects. Once it builds OK at OBS, I then use an 'osc sr' command to push it on to Tumbleweed/Factory. At that point, I branch and check out the code of all the Leap versions in maintenance from their updates project, and copy the new Virtualization/virtualbox code to that directory, then check in the new code to the appropriate updates project. Once a correct build there is confirmed, I then use an 'osc mr' command to push it on. For Leap versions not yet released such as Leap 15.5 at the moment, there is no updates project. For them, the project is submitted though the OBS web site. It would be a lot simpler if the Virtualization/birtualbox project could be used to push new code to the Leap updates project, but that step failed the last time I tried it, thus the differing treatment for released Leap versions. Larry
Hello, On Wed, Aug 24, 2022 at 10:19:11AM -0500, Larry Finger wrote:
On 8/24/22 03:24, Simon Lees wrote:
It would be a lot simpler if the Virtualization/birtualbox project could be used to push new code to the Leap updates project, but that step failed the last time I tried it, thus the differing treatment for released Leap versions.
If that failed that's probably a bug. I see no reason why that should not work. Leap updates are generally auto-submitted from develprojects before each new release. Thanks Michal
Hi, Am 24.08.22 um 10:13 schrieb Roger Oberholtzer:
For exampl (not a complaints against this ptroject! I just happen to be following the status of the tensorflow2 and it took me here as a unresolvable package):
https://build.opensuse.org/package/show/devel%3Alanguages%3Apython/python-go...
tensorflow is not a requirement of google-pasta, is it? Only the other way round. science:machinelearning/tensorflow2 has been removed from Factory, thus from the Tumbleweed snapshots. https://build.opensuse.org/package/show/science:machinelearning/tensorflow2#... https://build.opensuse.org/request/show/978958 https://bugzilla.opensuse.org/show_bug.cgi?id=1199814 It became impossible to maintain a successful build from source with the progression of Tumbleweed packages. The bazel build was pinned to very specific library versions. Upstream (Google) is not very cooperative in accepting patches to remain compatibility with other versions and really it is meant to be installed in containers or a virtual environment (pre-built wheels on PyPI exist) rather than as a system package. - Ben
Hello, On 24/08/2022 10:13, Roger Oberholtzer wrote:
I quite often find that packages are enabled for only 15.2, or only Tumblwweed. But it is quite common that the packages are not enabled for all current openSUSE/SUSE releases.
For packages that are inherited in SLE15-SP4 from SLE15-SP2, I normally don't enable other leap then 15.2, since they are supposed to work with newer versions as they are. So, why to waste resources. Cheers F.
I get this point. But when searching for packages for a version of leap like 15.4, these will not show up. If they are truly compatible, then perhaps this should be accounted for. Also, if they are compatible, why does OBS even bother with a 15.x target and instead simply define only, say, 15. Then the wasted builds and all would be avoided and the users of these packages would perhaps better understand what they are for. Maybe that's a goal already defined? It doesn't mean that the point release targets can't also exist. But a non-point-release-common target would perhaps make intentions more clear. One could choose the 15 target to make it clear that your package is not specific to a point release. JM2CW On Wed, Aug 24, 2022 at 10:43 AM Fridrich Strba <fstrba@suse.com> wrote:
Hello,
On 24/08/2022 10:13, Roger Oberholtzer wrote:
I quite often find that packages are enabled for only 15.2, or only Tumblwweed. But it is quite common that the packages are not enabled for all current openSUSE/SUSE releases.
For packages that are inherited in SLE15-SP4 from SLE15-SP2, I normally don't enable other leap then 15.2, since they are supposed to work with newer versions as they are. So, why to waste resources.
Cheers
F.
-- Roger Oberholtzer
Is there a table/description of which targets (15.2, 15.3, etc) are binary compatible? Something that would help one to select which things might work? And I guess one would need multiple point release versions of a repository defined so as to able able to pick up the packages that are scattered across the various target repos, So on a, say, 15.5 install, you would need to add the repos for 15.1, 15.2, 15.3, 15.4, and 15.5 so that you can find the one that actually got built. On Fri, Aug 25, 2023 at 9:17 AM Roger Oberholtzer < roger.oberholtzer@gmail.com> wrote:
I get this point. But when searching for packages for a version of leap like 15.4, these will not show up. If they are truly compatible, then perhaps this should be accounted for.
Also, if they are compatible, why does OBS even bother with a 15.x target and instead simply define only, say, 15. Then the wasted builds and all would be avoided and the users of these packages would perhaps better understand what they are for. Maybe that's a goal already defined? It doesn't mean that the point release targets can't also exist. But a non-point-release-common target would perhaps make intentions more clear. One could choose the 15 target to make it clear that your package is not specific to a point release.
JM2CW
On Wed, Aug 24, 2022 at 10:43 AM Fridrich Strba <fstrba@suse.com> wrote:
Hello,
On 24/08/2022 10:13, Roger Oberholtzer wrote:
I quite often find that packages are enabled for only 15.2, or only Tumblwweed. But it is quite common that the packages are not enabled for all current openSUSE/SUSE releases.
For packages that are inherited in SLE15-SP4 from SLE15-SP2, I normally don't enable other leap then 15.2, since they are supposed to work with newer versions as they are. So, why to waste resources.
Cheers
F.
-- Roger Oberholtzer
-- Roger Oberholtzer
Not intended to start a violent discussion with this as I am not decided on it, but I am guessing that it is hoped that flatpacks as an alternative might clear this up. At least for complete applications. In another thread I was wondering about how all that worked in a development environment where you need all the bits that will eventually go into your flatpack. On Fri, Aug 25, 2023 at 9:23 AM Roger Oberholtzer < roger.oberholtzer@gmail.com> wrote:
Is there a table/description of which targets (15.2, 15.3, etc) are binary compatible? Something that would help one to select which things might work?
And I guess one would need multiple point release versions of a repository defined so as to able able to pick up the packages that are scattered across the various target repos, So on a, say, 15.5 install, you would need to add the repos for 15.1, 15.2, 15.3, 15.4, and 15.5 so that you can find the one that actually got built.
On Fri, Aug 25, 2023 at 9:17 AM Roger Oberholtzer < roger.oberholtzer@gmail.com> wrote:
I get this point. But when searching for packages for a version of leap like 15.4, these will not show up. If they are truly compatible, then perhaps this should be accounted for.
Also, if they are compatible, why does OBS even bother with a 15.x target and instead simply define only, say, 15. Then the wasted builds and all would be avoided and the users of these packages would perhaps better understand what they are for. Maybe that's a goal already defined? It doesn't mean that the point release targets can't also exist. But a non-point-release-common target would perhaps make intentions more clear. One could choose the 15 target to make it clear that your package is not specific to a point release.
JM2CW
On Wed, Aug 24, 2022 at 10:43 AM Fridrich Strba <fstrba@suse.com> wrote:
Hello,
On 24/08/2022 10:13, Roger Oberholtzer wrote:
I quite often find that packages are enabled for only 15.2, or only Tumblwweed. But it is quite common that the packages are not enabled for all current openSUSE/SUSE releases.
For packages that are inherited in SLE15-SP4 from SLE15-SP2, I normally don't enable other leap then 15.2, since they are supposed to work with newer versions as they are. So, why to waste resources.
Cheers
F.
-- Roger Oberholtzer
-- Roger Oberholtzer
-- Roger Oberholtzer
On Fri, Aug 25, 2023 at 09:29:12AM +0200, Roger Oberholtzer wrote:
Not intended to start a violent discussion with this as I am not decided on it, but I am guessing that it is hoped that flatpacks as an alternative might clear this up. At least for complete applications. In another thread I was wondering about how all that worked in a development environment where you need all the bits that will eventually go into your flatpack.
Then instead of wasting resources on OBS you can waste resources on flathub and your machine. Your choice. Flatpaks tend to be _very_ wasteful when it comes to space, tend to integrate poorly with the OS, and security updates tend to be problematic because there would be many copies of each library. YMMV. Thanks Michal
On Fri, Aug 25, 2023 at 10:42 AM Michal Suchánek <msuchanek@suse.de> wrote:
Not intended to start a violent discussion with this as I am not decided on it, but I am guessing that it is hoped that flatpacks as an alternative might clear this up. At least for complete applications. In another
On Fri, Aug 25, 2023 at 09:29:12AM +0200, Roger Oberholtzer wrote: thread
I was wondering about how all that worked in a development environment where you need all the bits that will eventually go into your flatpack.
Then instead of wasting resources on OBS you can waste resources on flathub and your machine. Your choice. Flatpaks tend to be _very_ wasteful when it comes to space, tend to integrate poorly with the OS, and security updates tend to be problematic because there would be many copies of each library. YMMV.
I'm not a flatpack user. And as a developer I am curious how one gets all the various libs/components needed for an application in the flatpack world. They would, I would imagine, still need to be made the current way, and then packaged into flatpacks along with whatever bits are needed. So in a flatpack developer's world, all the work/hassle to get the needed components must still exist. Or do people think that the flatpack developer also builds and maintains all the 3rd party libs needed to make that flatpack? I can't think that's the way. But I think it would be great if there was some more organized way that the binary compatible things built in OBS were managed. Like a '15' target for all the things that can be used in 15 and all the point releases. If that would be difficult to manage (tracking compatibility), then my original point of things all being built for the current point releases would be good. To only have, say, 15.2 seems incomplete. -- Roger Oberholtzer
On Fri, Aug 25, 2023 at 02:24:30PM +0200, Roger Oberholtzer wrote:
On Fri, Aug 25, 2023 at 10:42 AM Michal Suchánek <msuchanek@suse.de> wrote:
Not intended to start a violent discussion with this as I am not decided on it, but I am guessing that it is hoped that flatpacks as an alternative might clear this up. At least for complete applications. In another
On Fri, Aug 25, 2023 at 09:29:12AM +0200, Roger Oberholtzer wrote: thread
I was wondering about how all that worked in a development environment where you need all the bits that will eventually go into your flatpack.
Then instead of wasting resources on OBS you can waste resources on flathub and your machine. Your choice. Flatpaks tend to be _very_ wasteful when it comes to space, tend to integrate poorly with the OS, and security updates tend to be problematic because there would be many copies of each library. YMMV.
I'm not a flatpack user. And as a developer I am curious how one gets all the various libs/components needed for an application in the flatpack world. They would, I would imagine, still need to be made the current way, and then packaged into flatpacks along with whatever bits are needed.
So in a flatpack developer's world, all the work/hassle to get the needed components must still exist. Or do people think that the flatpack developer also builds and maintains all the 3rd party libs needed to make that flatpack? I can't think that's the way.
There are basically two approaches to this. - bundle everything the application needs with it - use 'frameworks' which are sets of libraries People cannot agree on a set of frameworks so there is a number of different, incompatible frameworks with overlapping functionality. Slightly better than every application bunling everything but not by much.
But I think it would be great if there was some more organized way that the binary compatible things built in OBS were managed. Like a '15' target for all the things that can be used in 15 and all the point releases. If that would be difficult to manage (tracking compatibility), then my original point of things all being built for the current point releases would be good. To only have, say, 15.2 seems incomplete.
That's likely because the project is simply abandoned. 15.2 is EOL for quite a while by now. Nothing stops you from branching the package and building it for other releases. Thanks Michal
On Fri, Aug 25, 2023 at 2:52 PM Michal Suchánek <msuchanek@suse.de> wrote:
That's likely because the project is simply abandoned. 15.2 is EOL for quite a while by now. Nothing stops you from branching the package and building it for other releases.
Which is what I do. It's not a problem. Maybe OBS needs a target called "Current Leaps" which is all the Leap that are currently not EOL. It changes as the Leaps change. -- Roger Oberholtzer
On 8/25/23 16:53, Roger Oberholtzer wrote:
Is there a table/description of which targets (15.2, 15.3, etc) are binary compatible? Something that would help one to select which things might work?
In terms of packages that come from SLE they will be binary compatible for the whole of the 15.X series with select few exceptions, this is why we still have such an old version of gcc. For openSUSE packages its a bit more flexible so it may change from point release to point release but normally people try to avoid it.
On Fri, Aug 25, 2023 at 9:17 AM Roger Oberholtzer <roger.oberholtzer@gmail.com <mailto:roger.oberholtzer@gmail.com>> wrote:
I get this point. But when searching for packages for a version of leap like 15.4, these will not show up. If they are truly compatible, then perhaps this should be accounted for.
Also, if they are compatible, why does OBS even bother with a 15.x target and instead simply define only, say, 15. Then the wasted builds and all would be avoided and the users of these packages would perhaps better understand what they are for. Maybe that's a goal already defined? It doesn't mean that the point release targets can't also exist. But a non-point-release-common target would perhaps make intentions more clear. One could choose the 15 target to make it clear that your package is not specific to a point release.
JM2CW
On Wed, Aug 24, 2022 at 10:43 AM Fridrich Strba <fstrba@suse.com <mailto:fstrba@suse.com>> wrote:
Hello,
On 24/08/2022 10:13, Roger Oberholtzer wrote: > I quite often find that packages are enabled for only 15.2, or only > Tumblwweed. But it is quite common that the packages are not enabled > for all current openSUSE/SUSE releases.
For packages that are inherited in SLE15-SP4 from SLE15-SP2, I normally don't enable other leap then 15.2, since they are supposed to work with newer versions as they are. So, why to waste resources.
Cheers
F.
-- Roger Oberholtzer
-- Roger Oberholtzer
-- 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 Fri, Aug 25, 2023 at 05:45:35PM +0930, Simon Lees wrote:
On 8/25/23 16:53, Roger Oberholtzer wrote:
Is there a table/description of which targets (15.2, 15.3, etc) are binary compatible? Something that would help one to select which things might work?
In terms of packages that come from SLE they will be binary compatible for the whole of the 15.X series with select few exceptions, this is why we still have such an old version of gcc. For openSUSE packages its a bit more flexible so it may change from point release to point release but normally people try to avoid it.
They would be binary compatible if they built at all. However, many packages need dependencies from the newer releases to build at all or enable additional features on newer releases. Thanks Michal
participants (6)
-
Ben Greiner -
Fridrich Strba -
Larry Finger -
Michal Suchánek -
Roger Oberholtzer -
Simon Lees