[opensuse-factory] Leap packagelist
Hi, I'm a bit concerned about the status of Leap 42.1. Every now and then I come across some missing package. Just now it was freeradius-server. Why is it not in Leap? I always understood that we'll have (almost) everything in Leap which is in SLE12 because that makes sense and given that freeradius-server is in Factory and SLE12 it's not like this is just some special SLE thing. Is there a current comparison list of packages which are in SLE12 but not in Leap? I'm wondering what I'll miss at some point when it comes to practical usage of Leap :-( Thanks, Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, Am Samstag, 26. September 2015 schrieb Wolfgang Rosenauer:
I'm a bit concerned about the status of Leap 42.1.
Every now and then I come across some missing package. Just now it was freeradius-server. Why is it not in Leap? I always understood that we'll have (almost) everything in Leap which is in SLE12 because that makes sense and given that freeradius-server is in Factory and SLE12 it's not like this is just some special SLE thing.
Is there a current comparison list of packages which are in SLE12 but not in Leap? I'm wondering what I'll miss at some point when it comes to practical usage of Leap :-(
Marguerite made lists comparing to SLE and Factory [1], but both seem to be outdated (I found packages that are in Leap already in both lists). Marguerite, can you please update your lists? It would also be a good idea to hide updates ("$packagename.123" in SLE SP1). Also, please make sure that you get all SLE packages - it seems osc ls -e SUSE:SLE-12- SP1:GA misses quite some packages, see below. That said - creating that list yourself is quite easy: osc ls -e openSUSE:Leap:42.1 | sort > leap ( osc ls -e SUSE:SLE-12-SP1:GA ; osc ls -e SUSE:SLE-12:GA ) | \ sort -u | grep -v '\.[0-9][0-9]*$' > sle12 # [2] diff -U0 leap sle12 |sort |grep -v ^@ > diff-leap-sle grep ^+ diff-leap-sle # gives you 426 SLE-only packages Note that renamed packages might cause false positives, therefore better check the full diff instead of just ^+. Also, some packages probably hide in non-oss. For those who don't want to run the commands above themself, here's the result as clickable links: www.cboltz.de/tmp/diff-leap-sle.txt - the whole diff www.cboltz.de/tmp/sle-only-packages.txt - packages only in SLE Those files are a snapshot taken some minutes ago, won't get updated and will be deleted in a week or two. Regards, Christian Boltz [1] https://forum.suse.org.cn/sle.html - SLE vs. Leap https://forum.suse.org.cn/leap.html - Factory vs. Leap [2] I tried with osc ls -e SUSE:SLE-12-SP1:GA | sort | grep -v '\.[0-9][0-9]*$'>sle12 first, but this doesn't give me all the 4815 inherited packages I see on https://build.opensuse.org/project/show/SUSE:SLE-12-SP1:GA --
I'm running SUPER. I've a USB mouse attached. The mouse is too sensitive, the cursor is moving too fast which is out of my control. Even the mouse is performance enhanced, wow! [> Qingjia Zhu and Peter Flodin in opensuse]
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 26.09.2015 um 18:46 schrieb Christian Boltz:
That said - creating that list yourself is quite easy: osc ls -e openSUSE:Leap:42.1 | sort > leap ( osc ls -e SUSE:SLE-12-SP1:GA ; osc ls -e SUSE:SLE-12:GA ) | \ sort -u | grep -v '\.[0-9][0-9]*$' > sle12 # [2] diff -U0 leap sle12 |sort |grep -v ^@ > diff-leap-sle grep ^+ diff-leap-sle # gives you 426 SLE-only packages
426 packages. This is what scares me. I really wonder if there was some misconception pulling in packages. I fear that we'll find a lot missing in real usage later on. Actually I don't think single persons can just look through the list and recognize what is important or not. Some examples which I can see immediately and really wonder why they are missing: - freeradius-server - squid - squidGuard - apache2-mod_python - icinga - kvm (wtf?) - nrpe - puppet - stunnel - tomcat - tsclient - ypserv I'm sure there are more. Yes, I checked early milestones for missing stuff and probably others did so as well but one cannot test everything. I SRed and reported some before but it seems to me we missed important ones in the process. I'm really wondering why we are at this stage at the moment because the topic was discussed in this thread before: http://lists.opensuse.org/opensuse-factory/2015-08/msg00415.html Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 26 September 2015 at 20:28, Wolfgang Rosenauer <wolfgang@rosenauer.org> wrote:
Am 26.09.2015 um 18:46 schrieb Christian Boltz:
That said - creating that list yourself is quite easy: osc ls -e openSUSE:Leap:42.1 | sort > leap ( osc ls -e SUSE:SLE-12-SP1:GA ; osc ls -e SUSE:SLE-12:GA ) | \ sort -u | grep -v '\.[0-9][0-9]*$' > sle12 # [2] diff -U0 leap sle12 |sort |grep -v ^@ > diff-leap-sle grep ^+ diff-leap-sle # gives you 426 SLE-only packages
426 packages. This is what scares me.
I really wonder if there was some misconception pulling in packages. I fear that we'll find a lot missing in real usage later on. Actually I don't think single persons can just look through the list and recognize what is important or not.
Some examples which I can see immediately and really wonder why they are missing:
- freeradius-server - squid - squidGuard - apache2-mod_python - icinga - kvm (wtf?) - nrpe - puppet - stunnel - tomcat - tsclient - ypserv
I'm sure there are more.
Yes, I checked early milestones for missing stuff and probably others did so as well but one cannot test everything. I SRed and reported some before but it seems to me we missed important ones in the process.
I'm really wondering why we are at this stage at the moment because the topic was discussed in this thread before: http://lists.opensuse.org/opensuse-factory/2015-08/msg00415.html
Wolfgang, for each package in the list that YOU think is important we get in Leap, you can make sure it'll go in leap osc submitrequest -m "Submitting $package from SLE 12 to Leap' SUSE:SLE-12-SP1:GA/$package openSUSE:Leap:42.1 Please do so :) Thanks :) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 26.09.2015 um 21:11 schrieb Richard Brown:
426 packages. This is what scares me.
I really wonder if there was some misconception pulling in packages. I fear that we'll find a lot missing in real usage later on. Actually I don't think single persons can just look through the list and recognize what is important or not.
Some examples which I can see immediately and really wonder why they are missing:
- freeradius-server - squid - squidGuard - apache2-mod_python - icinga - kvm (wtf?) - nrpe - puppet - stunnel - tomcat - tsclient - ypserv
I'm sure there are more.
Yes, I checked early milestones for missing stuff and probably others did so as well but one cannot test everything. I SRed and reported some before but it seems to me we missed important ones in the process.
I'm really wondering why we are at this stage at the moment because the topic was discussed in this thread before: http://lists.opensuse.org/opensuse-factory/2015-08/msg00415.html
Wolfgang, for each package in the list that YOU think is important we get in Leap, you can make sure it'll go in leap
osc submitrequest -m "Submitting $package from SLE 12 to Leap' SUSE:SLE-12-SP1:GA/$package openSUSE:Leap:42.1
Please do so :)
I can do so. Even besides the fact that I thought the package list is more or less frozen already. But more importantly: This still does not seem to look like a solution to me since I still _will_ miss things I need at some later stage. One simple question: Why are not all packages from SLE12 in Leap except the ones which are obviously solely SLE related or introduced? Thanks, Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, Sep 26, 2015 at 3:11 PM, Richard Brown <RBrownCCB@opensuse.org> wrote:
On 26 September 2015 at 20:28, Wolfgang Rosenauer <wolfgang@rosenauer.org> wrote:
Am 26.09.2015 um 18:46 schrieb Christian Boltz:
That said - creating that list yourself is quite easy: osc ls -e openSUSE:Leap:42.1 | sort > leap ( osc ls -e SUSE:SLE-12-SP1:GA ; osc ls -e SUSE:SLE-12:GA ) | \ sort -u | grep -v '\.[0-9][0-9]*$' > sle12 # [2] diff -U0 leap sle12 |sort |grep -v ^@ > diff-leap-sle grep ^+ diff-leap-sle # gives you 426 SLE-only packages
426 packages. This is what scares me.
I really wonder if there was some misconception pulling in packages. I fear that we'll find a lot missing in real usage later on. Actually I don't think single persons can just look through the list and recognize what is important or not.
Some examples which I can see immediately and really wonder why they are missing:
- freeradius-server - squid - squidGuard - apache2-mod_python - icinga - kvm (wtf?) - nrpe - puppet - stunnel - tomcat - tsclient - ypserv
I'm sure there are more.
Yes, I checked early milestones for missing stuff and probably others did so as well but one cannot test everything. I SRed and reported some before but it seems to me we missed important ones in the process.
I'm really wondering why we are at this stage at the moment because the topic was discussed in this thread before: http://lists.opensuse.org/opensuse-factory/2015-08/msg00415.html
Wolfgang, for each package in the list that YOU think is important we get in Leap, you can make sure it'll go in leap
osc submitrequest -m "Submitting $package from SLE 12 to Leap' SUSE:SLE-12-SP1:GA/$package openSUSE:Leap:42.1
Please do so :)
Thanks :)
Richard, I believe historically, as a matter of policy new packages were not introduced via the updates repo. Given that Leap was built from the ground up with a new collection of packages, it seems likely some important ones won't be in the distro on release day. I don't know who the decision makers are, but it is feasible the rules for the update repo be bent to allow missing packages to be added via it post release? Is that a board level policy? Thanks Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 26.09.2015 um 21:11 schrieb Richard Brown:
osc submitrequest -m "Submitting $package from SLE 12 to Leap' SUSE:SLE-12-SP1:GA/$package openSUSE:Leap:42.1
What will happen to these SRs? Looks like each pkg goes into its own staging, which may or may not result in unresolved dependencies. Will each succeeded pkg get automatically into 42.1, so that pkgs which currently have unresolved dependency can start to build? Olaf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 09/28/2015 04:51 PM, Olaf Hering wrote:
Am 26.09.2015 um 21:11 schrieb Richard Brown:
osc submitrequest -m "Submitting $package from SLE 12 to Leap' SUSE:SLE-12-SP1:GA/$package openSUSE:Leap:42.1 What will happen to these SRs? Looks like each pkg goes into its own staging, which may or may not result in unresolved dependencies. Will each succeeded pkg get automatically into 42.1, so that pkgs which currently have unresolved dependency can start to build?
Olaf
When i make a SR that requires other recent SR's to build i mention it in the message (after the -m) when the skillful team pick where to put the package for staging they then but it in staging together with its deps and the world is a happy place. Cheers Simon -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 28.09.2015 um 09:35 schrieb Simon Lees:
On 09/28/2015 04:51 PM, Olaf Hering wrote:
Am 26.09.2015 um 21:11 schrieb Richard Brown:
osc submitrequest -m "Submitting $package from SLE 12 to Leap' SUSE:SLE-12-SP1:GA/$package openSUSE:Leap:42.1 What will happen to these SRs? Looks like each pkg goes into its own staging, which may or may not result in unresolved dependencies. Will each succeeded pkg get automatically into 42.1, so that pkgs which currently have unresolved dependency can start to build?
Olaf
When i make a SR that requires other recent SR's to build i mention it in the message (after the -m) when the skillful team pick where to put the package for staging they then but it in staging together with its deps and the world is a happy place.
but real life problem here: I'm probably no expert in all these packages. I'm not involved into them. I don't know which build and runtime requirements they have. If I just submit them who is expected to care about the probable long tail of actions which need to follow? We've seen this process failing in other examples (like exactly freeradius-server). I think this is what Olaf basically asked? Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Sep 28, 2015 at 3:51 AM, Wolfgang Rosenauer <wolfgang@rosenauer.org> wrote:
Am 28.09.2015 um 09:35 schrieb Simon Lees:
On 09/28/2015 04:51 PM, Olaf Hering wrote:
Am 26.09.2015 um 21:11 schrieb Richard Brown:
osc submitrequest -m "Submitting $package from SLE 12 to Leap' SUSE:SLE-12-SP1:GA/$package openSUSE:Leap:42.1 What will happen to these SRs? Looks like each pkg goes into its own staging, which may or may not result in unresolved dependencies. Will each succeeded pkg get automatically into 42.1, so that pkgs which currently have unresolved dependency can start to build?
Olaf
When i make a SR that requires other recent SR's to build i mention it in the message (after the -m) when the skillful team pick where to put the package for staging they then but it in staging together with its deps and the world is a happy place.
but real life problem here: I'm probably no expert in all these packages. I'm not involved into them. I don't know which build and runtime requirements they have. If I just submit them who is expected to care about the probable long tail of actions which need to follow? We've seen this process failing in other examples (like exactly freeradius-server). I think this is what Olaf basically asked?
Can the Candidates Repo be updated to build against Leap:42.1 It still builds against "pure_42" and thus is out of date. Once that is done, it is fairly easy to see what dependencies are missing by looking at the packages in the Candidates repo: https://build.opensuse.org/project/show/openSUSE:42:Factory-Candidates-Check Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 28.09.2015 um 22:57 schrieb Greg Freemyer:
It still builds against "pure_42" and thus is out of date.
Once that is done, it is fairly easy to see what dependencies are missing by looking at the packages in the Candidates repo:
https://build.opensuse.org/project/show/openSUSE:42:Factory-Candidates-Check
We don't maintain this project any longer. Add openSUSE_Leap_42.1 to your own devel project. Greetings, Stephan -- Ma muaß weiterkämpfen, kämpfen bis zum Umfalln, a wenn die ganze Welt an Arsch offen hat, oder grad deswegn. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, Sep 26, 2015 at 9:28 PM, Wolfgang Rosenauer <wolfgang@rosenauer.org> wrote:
- icinga
https://build.opensuse.org/project/show/openSUSE:Leap:42.1:Staging:adi:32 . Not sure what's missing to accept the submission though.
- puppet
It's rubygem-puppet now ( https://build.opensuse.org/package/show/openSUSE:Leap:42.1/rubygem-puppet )
- tomcat
https://build.opensuse.org/project/show/openSUSE:Leap:42.1:Staging:adi:12 Unresolvable, although jakarta-commons-dbcp-src was submitted to Leap. Robert -- http://robert.muntea.nu/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, 2015-09-26 at 22:54 +0300, Robert Munteanu wrote:
On Sat, Sep 26, 2015 at 9:28 PM, Wolfgang Rosenauer <wolfgang@rosenauer.org> wrote:
- icinga
https://build.opensuse.org/project/show/openSUSE:Leap:42.1:Staging:ad i:32 . Not sure what's missing to accept the submission though.
https://build.opensuse.org/project/staging_projects/openSUSE:Leap:42.1/ adi:32 Gives some interesting idea here: Missing reviews: nagios-plugins-mysql_health by server:monitoring, nagios-plugins- mysql_health by nagios-plugins-mysql_health, logwatch by server:monitoring, logwatch by logwatch, monitoring-plugins-smart by server:monitoring, monitoring-plugins-smart by monitoring-plugins- smart, monitoring-plugins-diskio by server:monitoring, monitoring- plugins-diskio by monitoring-plugins-diskio, nagstamon by server:monitoring, nagstamon by nagstamon, collectd by server:monitoring, collectd by collectd, monitoring-plugins-clamav by server:monitoring, and monitoring-plugins-clamav by monitoring-plugins- clamav. so in fact: the current package maintainers are asked to commit maintaining this package for the life-time of Leap 42.1... there is no reason to add a package that won't have an active maintainer, right? Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 27.09.2015 um 13:30 schrieb Dominique Leuenberger / DimStar:
On Sat, 2015-09-26 at 22:54 +0300, Robert Munteanu wrote:
On Sat, Sep 26, 2015 at 9:28 PM, Wolfgang Rosenauer <wolfgang@rosenauer.org> wrote:
- icinga
https://build.opensuse.org/project/show/openSUSE:Leap:42.1:Staging:ad i:32 . Not sure what's missing to accept the submission though.
https://build.opensuse.org/project/staging_projects/openSUSE:Leap:42.1/ adi:32
Gives some interesting idea here: Missing reviews: nagios-plugins-mysql_health by server:monitoring, nagios-plugins- mysql_health by nagios-plugins-mysql_health, logwatch by server:monitoring, logwatch by logwatch, monitoring-plugins-smart by server:monitoring, monitoring-plugins-smart by monitoring-plugins- smart, monitoring-plugins-diskio by server:monitoring, monitoring- plugins-diskio by monitoring-plugins-diskio, nagstamon by server:monitoring, nagstamon by nagstamon, collectd by server:monitoring, collectd by collectd, monitoring-plugins-clamav by server:monitoring, and monitoring-plugins-clamav by monitoring-plugins- clamav.
so in fact: the current package maintainers are asked to commit maintaining this package for the life-time of Leap 42.1... there is no reason to add a package that won't have an active maintainer, right?
Actually I don't get this argument but probably just don't understand. icinga is in SLE12 logwatch is in SLE12 (probably not the others) So was the point that icinga does not make sense w/o every single plugin from above? Because I understood that SLE12 packages are implicitely maintained anyway w/o any commitment from the Factory maintainer? Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 27 September 2015 at 19:06, Wolfgang Rosenauer <wolfgang@rosenauer.org> wrote:
Am 27.09.2015 um 13:30 schrieb Dominique Leuenberger / DimStar:
On Sat, 2015-09-26 at 22:54 +0300, Robert Munteanu wrote:
On Sat, Sep 26, 2015 at 9:28 PM, Wolfgang Rosenauer <wolfgang@rosenauer.org> wrote:
- icinga
https://build.opensuse.org/project/show/openSUSE:Leap:42.1:Staging:ad i:32 . Not sure what's missing to accept the submission though.
https://build.opensuse.org/project/staging_projects/openSUSE:Leap:42.1/ adi:32
Gives some interesting idea here: Missing reviews: nagios-plugins-mysql_health by server:monitoring, nagios-plugins- mysql_health by nagios-plugins-mysql_health, logwatch by server:monitoring, logwatch by logwatch, monitoring-plugins-smart by server:monitoring, monitoring-plugins-smart by monitoring-plugins- smart, monitoring-plugins-diskio by server:monitoring, monitoring- plugins-diskio by monitoring-plugins-diskio, nagstamon by server:monitoring, nagstamon by nagstamon, collectd by server:monitoring, collectd by collectd, monitoring-plugins-clamav by server:monitoring, and monitoring-plugins-clamav by monitoring-plugins- clamav.
so in fact: the current package maintainers are asked to commit maintaining this package for the life-time of Leap 42.1... there is no reason to add a package that won't have an active maintainer, right?
Actually I don't get this argument but probably just don't understand. icinga is in SLE12 logwatch is in SLE12 (probably not the others)
So was the point that icinga does not make sense w/o every single plugin from above? Because I understood that SLE12 packages are implicitely maintained anyway w/o any commitment from the Factory maintainer?
From what I understand (and I admit, I'm struggling too also) it sounds like a number of maintainers haven't accepted the reviews for
those packages Therefore, they could be in Leap, but they need a maintainer to give permission to do so..without that permission, they're kind of stuck in limbo To everyone who feels packages are missing in Leap - please either poke the existing maintainers for the packages you want, or step up to help :) Thanks -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 26.09.2015 um 20:28 schrieb Wolfgang Rosenauer:
I'm really wondering why we are at this stage at the moment because the topic was discussed in this thread before: http://lists.opensuse.org/opensuse-factory/2015-08/msg00415.html
And freeradius-server is a prime example why it failed: https://build.opensuse.org/request/show/324970 Greetings, Stephan -- Ma muaß weiterkämpfen, kämpfen bis zum Umfalln, a wenn die ganze Welt an Arsch offen hat, oder grad deswegn. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Stephan Kulow wrote:
Am 26.09.2015 um 20:28 schrieb Wolfgang Rosenauer:
I'm really wondering why we are at this stage at the moment because the topic was discussed in this thread before: http://lists.opensuse.org/opensuse-factory/2015-08/msg00415.html
And freeradius-server is a prime example why it failed:
I don't really see a strong reason why FreeRADIUS from SLE12 was chosen. If this makes package freeradius-server stuck to upstream source 3.0.3 (or anything prior 3.0.9) it's plain wrong. IMO the build dependencies should be simply fixed. Frankly I'm totally confused by the approach taken for Leaf. Most times I'm just lurking on this list. But there are many examples discussed which show that this mix-stream approach for Leaf isn't going to be successful. As for freeradius-server packages: For my personal use I'm updating these packages to get upstream source fixes into a package. Also because I'm convinced that staying closely to upstream source results in good upstream support and saves time for everybody. But I'm not willing to maintain totally different streams. Ciao, Michael.
Am 27.09.2015 um 14:43 schrieb Michael Ströder:
As for freeradius-server packages: For my personal use I'm updating these packages to get upstream source fixes into a package. Also because I'm convinced that staying closely to upstream source results in good upstream support and saves time for everybody. But I'm not willing to maintain totally different streams.
That's totally up to you, but bugowner of the package is Jochen and he decided to prefer SLE12 - and then didn't submit it ;( Greetings, Stephan -- Ma muaß weiterkämpfen, kämpfen bis zum Umfalln, a wenn die ganze Welt an Arsch offen hat, oder grad deswegn. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Stephan Kulow wrote:
Am 27.09.2015 um 14:43 schrieb Michael Ströder:
As for freeradius-server packages: For my personal use I'm updating these packages to get upstream source fixes into a package. Also because I'm convinced that staying closely to upstream source results in good upstream support and saves time for everybody. But I'm not willing to maintain totally different streams.
That's totally up to you, but bugowner of the package is Jochen and he decided to prefer SLE12 - and then didn't submit it ;(
Yes, he's free to choose whatever option for the freeradius packages. And in general openSUSE is free to choose any kafkaesque process and build up myriads of ways to bring packages into openSUSE. But the openSUSE project should not whine later that 1. the distribution does not meet users' needs and 2. the contributions of community members really _using_ the packages they use will decrease. I don't have to say anything more for now but still I'm watching with interest what the outcome will be... Ciao, Michael.
Hi Michael, On Sun, Sep 27, 2015 at 04:33:21PM +0200, Michael Ströder wrote:
Stephan Kulow wrote:
Am 27.09.2015 um 14:43 schrieb Michael Ströder:
As for freeradius-server packages: For my personal use I'm updating these packages to get upstream source fixes into a package. Also because I'm convinced that staying closely to upstream source results in good upstream support and saves time for everybody. But I'm not willing to maintain totally different streams.
That's totally up to you, but bugowner of the package is Jochen and he decided to prefer SLE12 - and then didn't submit it ;(
Yes, he's free to choose whatever option for the freeradius packages. And in general openSUSE is free to choose any kafkaesque process and build up myriads of ways to bring packages into openSUSE.
Hey, please calm down.
But the openSUSE project should not whine later that
1. the distribution does not meet users' needs and
If you see a reason why version 3.0.9 doesn't meet openSUSE Lead 42.1 user needs please raise them here or via bugzilla. But please avoid to be this vague and negative. That's not driving the potential seen issue forward. :-)
2. the contributions of community members really _using_ the packages they use will decrease.
You're willing to help Jochen? I'm sure he's happy about any contribution. And if the issue is simple to fix I'm sure he's willing to push a newer version into Lead 42.1 too. Cheers, Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team + SUSE Labs SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
Lars Müller wrote:
1. the distribution does not meet users' needs and
If you see a reason why version 3.0.9 doesn't meet openSUSE Lead 42.1 user needs please raise them here or via bugzilla.
AFAICS SLE12 contains freeradius-server 3.0.3. If this is taken for Leap I'm concerned that users won't get support by FreeRADIUS developers because the standard response will be "upgrade to x because it's fixed there".
2. the contributions of community members really _using_ the packages they use will decrease.
You're willing to help Jochen? I'm sure he's happy about any contribution.
I'm willing to contribute updating to upstream sources (see [1]) which includes testing my local installation before submitting. Due to time constraints I'm not willing to do backport patching mess. Ciao, Michael. [1] https://build.opensuse.org/package/view_file/network/freeradius-server/freer...
Lars Müller wrote:
1. the distribution does not meet users' needs and
If you see a reason why version 3.0.9 doesn't meet openSUSE Lead 42.1 user needs please raise them here or via bugzilla.
AFAICS SLE12 contains freeradius-server 3.0.3. If this is taken for Leap I'm concerned that users won't get support by FreeRADIUS developers because the standard response will be "upgrade to x because it's fixed there". Why should users contact FreeRADIUS developers directly when Leap has
Dne 27.09.2015 v 17:48 Michael Ströder napsal(a): maintainer/bugowner?
2. the contributions of community members really _using_ the packages they use will decrease.
You're willing to help Jochen? I'm sure he's happy about any contribution.
I'm willing to contribute updating to upstream sources (see [1]) which includes testing my local installation before submitting.
Due to time constraints I'm not willing to do backport patching mess.
Well this will be done by Jochen in same manner as for SLES. Regards Martin Pluskal
Martin Pluskal wrote:
Dne 27.09.2015 v 17:48 Michael Ströder napsal(a):
Lars Müller wrote:
1. the distribution does not meet users' needs and
If you see a reason why version 3.0.9 doesn't meet openSUSE Lead 42.1 user needs please raise them here or via bugzilla.
AFAICS SLE12 contains freeradius-server 3.0.3. If this is taken for Leap I'm concerned that users won't get support by FreeRADIUS developers because the standard response will be "upgrade to x because it's fixed there".
Why should users contact FreeRADIUS developers directly when Leap has maintainer/bugowner?
That's what they usually do because they experience problems or at least have questions. Ciao, Michael
Dne 27.09.2015 v 18:18 Michael Ströder napsal(a):
Martin Pluskal wrote:
Dne 27.09.2015 v 17:48 Michael Ströder napsal(a):
Lars Müller wrote:
1. the distribution does not meet users' needs and
If you see a reason why version 3.0.9 doesn't meet openSUSE Lead 42.1 user needs please raise them here or via bugzilla.
AFAICS SLE12 contains freeradius-server 3.0.3. If this is taken for Leap I'm concerned that users won't get support by FreeRADIUS developers because the standard response will be "upgrade to x because it's fixed there".
Why should users contact FreeRADIUS developers directly when Leap has maintainer/bugowner?
That's what they usually do because they experience problems or at least have questions.
I am not sure if you or those hypothetical users are not missing the point of Leap, that is long term supported, stable release, where stability usually does not go well along having latest packages. For users seeking latest versions, there is Tumbleweed. Also notice that same kind of argumentation which you are using for freeradius-server could be applied to almost any package in distribution. Anyway, even with latest freeradius-server in Leap it is still possible that somebody (bugowner) would have to backport fix from upstream master - and as you already said, you are willing to do only version bumps. Regards Martin Pluskal
Martin Pluskal wrote:
Dne 27.09.2015 v 18:18 Michael Ströder napsal(a):
That's what they usually do because they experience problems or at least have questions.
I am not sure if you or those hypothetical users are not missing the point of Leap, that is long term supported, stable release,
For whatever definition of "stable"...
where stability usually does not go well along having latest packages.
In this particular case: If 3.0.3 contains bugs making certain deployments impossible and upstream developers answer "use 3.0.9" it's pretty stupid to ship 3.0.3 in a long-term release now and start back-porting all the fixes to that package for years. Personally I can live with custom packages for my own deployment and will simply stop contributing then.
For users seeking latest versions, there is Tumbleweed.
Note that I'm not advocating upgrading to latest beta releases here (which would be unreleased 3.1-branch in case of FreeRADIUS).
Also notice that same kind of argumentation which you are using for freeradius-server could be applied to almost any package in distribution.
Yes, I know. :-/
Anyway, even with latest freeradius-server in Leap it is still possible that somebody (bugowner) would have to backport fix from upstream master - and as you already said, you are willing to do only version bumps.
This unnecessarily eats up SuSE developer resources without actually gaining "stability". Ciao, Michael.
Am 27.09.2015 um 21:13 schrieb Michael Ströder:
Martin Pluskal wrote: In this particular case: If 3.0.3 contains bugs making certain deployments impossible and upstream developers answer "use 3.0.9" it's pretty stupid to ship 3.0.3 in a long-term release now and start back-porting all the fixes to that package for years.
Personally I can live with custom packages for my own deployment and will simply stop contributing then.
I don't get your argument. Even if we ship 3.0.9 now in a few months upstream will say "it's pretty stupid to use 3.0.9". How is that different to every normal openSUSE release? If it really is "stupid" in the end, then SLE and also Leap needs to act anyway. And for those who want to be always up to date there is Tumbleweed and OBS. Also why do you want to stop contributing? There is still Tumbleweed exactly matching your expectations AFAICS.
Anyway, even with latest freeradius-server in Leap it is still possible that somebody (bugowner) would have to backport fix from upstream master - and as you already said, you are willing to do only version bumps.
This unnecessarily eats up SuSE developer resources without actually gaining "stability".
So now you are actually questioning the whole of SLE? I have no real idea about SUSE's success with SLE but apparently they are fine with that approach to invest developer time to maintain 3.0.3 at this moment. Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Wolfgang Rosenauer wrote:
Am 27.09.2015 um 21:13 schrieb Michael Ströder:
Martin Pluskal wrote: In this particular case: If 3.0.3 contains bugs making certain deployments impossible and upstream developers answer "use 3.0.9" it's pretty stupid to ship 3.0.3 in a long-term release now and start back-porting all the fixes to that package for years.
Personally I can live with custom packages for my own deployment and will simply stop contributing then.
I don't get your argument. Even if we ship 3.0.9 now in a few months upstream will say "it's pretty stupid to use 3.0.9".
We can only see the past but cannot predict the future. IMO it's waste of resources (for upstream and distribution developers and deployers) to ship an older release at a certain point of time while a newer release already has the fixes known at that time. IMO packagers should try to keep the amount of patches at a minimum. Otherwise work piles up and it gets more and more tedious to make the next upstream update. Ciao, Michael.
On 27 September 2015 at 22:17, Michael Ströder <michael@stroeder.com> wrote:
Wolfgang Rosenauer wrote:
Am 27.09.2015 um 21:13 schrieb Michael Ströder:
Martin Pluskal wrote: In this particular case: If 3.0.3 contains bugs making certain deployments impossible and upstream developers answer "use 3.0.9" it's pretty stupid to ship 3.0.3 in a long-term release now and start back-porting all the fixes to that package for years.
Personally I can live with custom packages for my own deployment and will simply stop contributing then.
I don't get your argument. Even if we ship 3.0.9 now in a few months upstream will say "it's pretty stupid to use 3.0.9".
We can only see the past but cannot predict the future.
IMO it's waste of resources (for upstream and distribution developers and deployers) to ship an older release at a certain point of time while a newer release already has the fixes known at that time.
IMO packagers should try to keep the amount of patches at a minimum. Otherwise work piles up and it gets more and more tedious to make the next upstream update.
You sound very much like the typical Tumbleweed user and contributor And that's fine, please, continue your contributions to Tumbleweed then But the reality is that the 'constantly moving target' is _not_ what _some_ of our _users_ want A distribution that changes all the time requires an element of regular adaptation, learning, and (unless they have a very limited use case) alteration in order to continue being productive with whatever implications of the latest version of $Package brings with it And for Tumbleweeders that's fine And for people who want to use, and maintain Leap, the mindset is different It involves picking a stable, sensible version of $Package, maintaining it with care, attention, and backports, for at least a year, then revisiting whether or not upgrading to the latest and greatest (or something close to it) makes sense a year from now in the next Leap minor release (In the case of the next Leap major release, there's much less of a choice involved, the assumption is that it will start based on a Tumbleweed snapshot in a few years from now) So Michael, please don't be dismissive, and use terms like 'stupid', to describe other people who have an opinion different from your own With FreeRadius, if we end up with the SLE 3.0.3 version in it, there will be someone, from SUSE, maintaining the package. That means writing, backporting, and providing, patches for issues. If people have issues to raise, they can raise them in *our* openSUSE Bugzilla. Sound good? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, On Sep 27 22:17 Michael Ströder wrote (excerpt):
IMO it's waste of resources (for upstream and distribution developers and deployers) to ship an older release at a certain point of time while a newer release already has the fixes known at that time.
Your opinion contradicts what is requested by enterprise customers and enterprise requirements are the base of Leap (provided I understand correctly how Leap is meant).
IMO packagers should try to keep the amount of patches at a minimum. Otherwise work piles up and it gets more and more tedious to make the next upstream update.
Yes, and it shows the reason why enterprise customers must pay money to get older releases kept running. An example: CUPS 1.3.9 in SLE11 has meanwhile almost 50 patches. CUPS 1.7.5 in SLE12 has 9 patches. CUPS 2.1.0 in Factory has 8 patches. Usually it is no real fun to do the work that is needed to keep older releases running which is the reason why people who do such work want to get money which is the reason why customers who want that must pay money which is finally the reason why I can feed my children ;-) Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg)
-- Greg Freemyer www.IntelligentAvatar.net On Mon, Sep 28, 2015 at 5:46 AM, Johannes Meixner <jsmeix@suse.de> wrote:
Hello,
On Sep 27 22:17 Michael Ströder wrote (excerpt):
IMO it's waste of resources (for upstream and distribution developers and deployers) to ship an older release at a certain point of time while a newer release already has the fixes known at that time.
Your opinion contradicts what is requested by enterprise customers and enterprise requirements are the base of Leap (provided I understand correctly how Leap is meant).
Johannes, I slightly disagree and it may just be a language / nuance issue. SLE is definitely the core of Leap, but are "enterprise requirements" the base of Leap. I think not. I would say Leap is a novel (not Novell) mix of traditional enterprise requirements and more aggressive openSUSE end-user requirements. The core of SLE is used and is meant to provide a level of stability in the core typically reserved for enterprise users. The majority (at least 75%) of the Leap packages will come from factory and meet the traditional openSUSE end-user use case. Given the novelness of this approach, I don't think it can be summarized in 2 or 3 words. Thus Michael Ströder's desire that packages be "current" will be true of at least 75% of Leap. Hopefully he will find that 75% satisfying. OTOH, for the core packages, the more stable SLE packages will be used and SLE will fund the maintenance of those stable packages. If a user has a need to be on a newer version and is willing to take on the maintenance role, then he should volunteer to do so. CUPS would be an example ofa package I would not want to maintain as a volunteer enthusiast, so having paid SLE staff take care of that is perfect from my perspective. In the case of FreeRadius, if the version in SLE is thought not to be current enough and someone is willing to step up and maintain a current version, then they should submit a SR to update it to a current version and state their willingness to be the maintainer / bugowner. I don't know if SRs like that are still being accepted. After all Leap is set to "ship" in 5 or 6 weeks. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 27.09.2015 um 15:54 schrieb Stephan Kulow:
Am 27.09.2015 um 14:43 schrieb Michael Ströder:
As for freeradius-server packages: For my personal use I'm updating these packages to get upstream source fixes into a package. Also because I'm convinced that staying closely to upstream source results in good upstream support and saves time for everybody. But I'm not willing to maintain totally different streams.
That's totally up to you, but bugowner of the package is Jochen and he decided to prefer SLE12 - and then didn't submit it ;(
ok, this shows another example why the process was probably a bit too optimistic. If Leap would have got just all packages from SLE and afterwards manual and intentioned updates to the Factory variant we wouldn't be in that situation. Now because examples like this we might are a bit in trouble when it comes to completeness of Leap. It just doesn't work to rely on every single maintainer. This can break because of so many reasons. Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 27.09.2015 19:01, Wolfgang Rosenauer wrote:
If Leap would have got just all packages from SLE and afterwards manual
It was never my intention to have all of SLE - I wanted to create an openSUSE release with the core system of SLE.
and intentioned updates to the Factory variant we wouldn't be in that situation. Now because examples like this we might are a bit in trouble when it comes to completeness of Leap. It just doesn't work to rely on every single maintainer. This can break because of so many reasons.
I don't think we rely on every single maintainer - but some more helping hands reviewing the reviews we asked for would have been great. I closed yesterday several SRs to Leap because for several weeks no one of the maintainers cared to accept the package for Leap. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, Am 28.09.2015 um 10:41 schrieb Stephan Kulow:
On 27.09.2015 19:01, Wolfgang Rosenauer wrote:
If Leap would have got just all packages from SLE and afterwards manual
It was never my intention to have all of SLE - I wanted to create an openSUSE release with the core system of SLE.
That's what I implicitely understood meanwhile. It wasn't actually my own understanding and actually I still struggle to understand why. My expectation was that everything we have (or had) in the regular openSUSE release from a feature set perspective would or should be in Leap as well. I haven't heard the requirement or expectation to strip a good amount of packages out of Leap. (Or I missed or ignored it mentally.) So I expected that every package from openSUSE which is also in SLE12 will be in Leap as well and that the starting point would be to use SLE packages if available and keep it if there is no reason to use the Factory version. It's also probably safe to say that packages from openSUSE which are also in SLE are probably important enough to have also available in Leap. So if we are looking for packages which are probably rarely used or not important I wouldn't start to search for them in the SLE base set.
and intentioned updates to the Factory variant we wouldn't be in that situation. Now because examples like this we might are a bit in trouble when it comes to completeness of Leap. It just doesn't work to rely on every single maintainer. This can break because of so many reasons.
I don't think we rely on every single maintainer - but some more helping hands reviewing the reviews we asked for would have been great.
I closed yesterday several SRs to Leap because for several weeks no one of the maintainers cared to accept the package for Leap.
Yes, but somehow this was not really unexpected. I have several SRs in my view because I'm a OBS project maintainer for some affected packages. Still I'm not the maintainer of those certain packages and I cannot easily commit myself to take over maintenance for them in Leap. So I really expected the final decision from the real maintainers. That those SRs are not touched at all (even not declined) is very unfortunate though. Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
As for freeradius-server packages: For my personal use I'm updating these packages to get upstream source fixes into a package. Also because I'm convinced that staying closely to upstream source results in good upstream support and saves time for everybody. But I'm not willing to maintain totally different streams. Hi I am not exactly sure what you are talking about, there are two changelog entries with your name in freeradius-server and none in freeradius-client, you are neither maintainer of bugowner of any of
Dne 27.09.2015 v 14:43 Michael Ströder napsal(a): those packages - what exactly are you not willing to do? Regards Martin Pluskal
On 26.09.2015 17:18, Wolfgang Rosenauer wrote:
Hi,
I'm a bit concerned about the status of Leap 42.1.
Every now and then I come across some missing package. Just now it was freeradius-server. Why is it not in Leap? I always understood that we'll have (almost) everything in Leap which is in SLE12 because that makes sense and given that freeradius-server is in Factory and SLE12 it's not like this is just some special SLE thing.
BTW: freeradius-server is still not in Leap - 3 different people submitted the SLE12 version and I declined 3 requests as that version does not build on leap (gpg refusing the signature) and 3 different people ignored that fact and went on with life. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 21 Oct 2015 12:06:56 +0200, Stephan Kulow wrote:
On 26.09.2015 17:18, Wolfgang Rosenauer wrote:
Hi,
I'm a bit concerned about the status of Leap 42.1.
Every now and then I come across some missing package. Just now it was freeradius-server. Why is it not in Leap? I always understood that we'll have (almost) everything in Leap which is in SLE12 because that makes sense and given that freeradius-server is in Factory and SLE12 it's not like this is just some special SLE thing.
BTW: freeradius-server is still not in Leap - 3 different people submitted the SLE12 version and I declined 3 requests as that version does not build on leap (gpg refusing the signature) and 3 different people ignored that fact and went on with life.
Did you open a bug report on bugzilla.suse.com regarding this? thanks, Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 21.10.2015 12:16, Takashi Iwai wrote:
On Wed, 21 Oct 2015 12:06:56 +0200, Stephan Kulow wrote:
On 26.09.2015 17:18, Wolfgang Rosenauer wrote:
Hi,
I'm a bit concerned about the status of Leap 42.1.
Every now and then I come across some missing package. Just now it was freeradius-server. Why is it not in Leap? I always understood that we'll have (almost) everything in Leap which is in SLE12 because that makes sense and given that freeradius-server is in Factory and SLE12 it's not like this is just some special SLE thing.
BTW: freeradius-server is still not in Leap - 3 different people submitted the SLE12 version and I declined 3 requests as that version does not build on leap (gpg refusing the signature) and 3 different people ignored that fact and went on with life.
Did you open a bug report on bugzilla.suse.com regarding this?
No Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Stephan Kulow wrote:
On 26.09.2015 17:18, Wolfgang Rosenauer wrote:
Hi,
I'm a bit concerned about the status of Leap 42.1.
Every now and then I come across some missing package. Just now it was freeradius-server. Why is it not in Leap? I always understood that we'll have (almost) everything in Leap which is in SLE12 because that makes sense and given that freeradius-server is in Factory and SLE12 it's not like this is just some special SLE thing.
BTW: freeradius-server is still not in Leap - 3 different people submitted the SLE12 version and I declined 3 requests as that version does not build on leap (gpg refusing the signature) and 3 different people ignored that fact and went on with life.
Do yourself and Leap a favour and take 3.0.10 from Factory: https://build.opensuse.org/package/show/home:stroeder:branches:network/freer... Note that 3.0.10 is the first version with working EAP-MSCHAPv2 and you definitely don't want to back-port all important fixes from 3.0.10. Ciao, Michael.
Michael Ströder wrote:
Stephan Kulow wrote:
On 26.09.2015 17:18, Wolfgang Rosenauer wrote:
Hi,
I'm a bit concerned about the status of Leap 42.1.
Every now and then I come across some missing package. Just now it was freeradius-server. Why is it not in Leap? I always understood that we'll have (almost) everything in Leap which is in SLE12 because that makes sense and given that freeradius-server is in Factory and SLE12 it's not like this is just some special SLE thing.
BTW: freeradius-server is still not in Leap - 3 different people submitted the SLE12 version and I declined 3 requests as that version does not build on leap (gpg refusing the signature) and 3 different people ignored that fact and went on with life.
Do yourself and Leap a favour and take 3.0.10 from Factory:
https://build.opensuse.org/package/show/home:stroeder:branches:network/freer...
Note that 3.0.10 is the first version with working EAP-MSCHAPv2 and you definitely don't want to back-port all important fixes from 3.0.10.
BTW: I've pointed to my own branch because I've enabled building for Leap there. Of course you should take https://build.opensuse.org/package/show/network/freeradius-server Ciao, Michael. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (14)
-
Christian Boltz -
Dominique Leuenberger / DimStar -
Greg Freemyer -
Johannes Meixner -
Lars Müller -
Martin Pluskal -
Michael Ströder -
Olaf Hering -
Richard Brown -
Robert Munteanu -
Simon Lees -
Stephan Kulow -
Takashi Iwai -
Wolfgang Rosenauer