[opensuse-factory] URGENT: ACTION NEEDED: LAST CHANCE - Make sure the packages you need are in openSUSE Leap
Hi all, Got your attention? :) This is hopefully the last email I'll send on this topic openSUSE Leap 42.1 is now in Beta 1, and from an engineering perspective things are going quite well (ie. It works!) But the distribution is 'missing' quite a few packages compared to openSUSE 13.2 (-1130) and Tumbleweed (-1480) The reason for this is simple - no one has submitted those packages and/or maintainers have not accepted the outstanding reviews for those packages While having a tidier distribution isn't a bad thing, it's a bit of a concern that so many packages might be either unwanted, or unloved by their maintainers = What can I do about it? = Well, obviously, I'd hope you've been downloading the openSUSE Leap 42.1 beta and testing it, and finding that the stuff you want is missing that way. But assuming that you haven't... Review the following two package list diffs http://paste.opensuse.org/77513865 ;- packages that are in Tumbleweed but not in Leap http://paste.opensuse.org/28259518 ;- packages that are in 13.2 but not in Leap If there are packages you desire, then double check they're not already on the way to Leap - https://build.opensuse.org/project/requests/openSUSE:Leap:42.1 If not, then submit them! To submit a package from Tumbleweed to Leap run osc submitrequest -m 'Submitting $package for Leap' openSUSE:Factory/$package openSUSE:Leap:42.1 If it makes sense to use the SLE-12 version instead (shouldn't be many of these left, but just in case), then submit a package from SLE-12-SP1 to Leap: osc submitrequest -m 'Submitting $package for Leap' SLE-12 -SP1:GA/$package openSUSE:Leap:42.1 If you're not the maintainer of the package, don't worry, the maintainer will be involved in the review process to ensure they're happy with their package ending up in Leap. But we need YOU to tell us it should be in our new Distribution. If you ARE the maintainer of the package, please review and accept/deny the request in a very prompt manner When Leap is released in November, if anyone on this list complains that a package they wanted in the distribution is missing, expect my sympathy levels to be dramatically lower than usual, you have been warned :) -- 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 10:01 AM, Richard Brown <RBrownCCB@opensuse.org> wrote:
http://paste.opensuse.org/77513865 ;- packages that are in Tumbleweed but not in Leap http://paste.opensuse.org/28259518 ;- packages that are in 13.2 but not in Leap
Any reason not to include lsb (and lsb-release)? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 2015-09-28 at 19:06 -0300, Claudio Freire wrote:
On Mon, Sep 28, 2015 at 10:01 AM, Richard Brown <RBrownCCB@opensuse.o rg> wrote:
http://paste.opensuse.org/77513865 ;- packages that are in Tumbleweed but not in Leap http://paste.opensuse.org/28259518 ;- packages that are in 13.2 but not in Leap
Any reason not to include lsb (and lsb-release)?
We have lsb5 in Leap... so yes, a good reason not to include lsb. Cheers, Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Sep 30, 2015 at 5:42 AM, Dominique Leuenberger / DimStar <dimstar@opensuse.org> wrote:
On Mon, 2015-09-28 at 19:06 -0300, Claudio Freire wrote:
On Mon, Sep 28, 2015 at 10:01 AM, Richard Brown <RBrownCCB@opensuse.o rg> wrote:
http://paste.opensuse.org/77513865 ;- packages that are in Tumbleweed but not in Leap http://paste.opensuse.org/28259518 ;- packages that are in 13.2 but not in Leap
Any reason not to include lsb (and lsb-release)?
We have lsb5 in Leap... so yes, a good reason not to include lsb.
Cheers, Dominique
Ah... serves me right for searching the list of "not in leap" instead of Leap itself. Thanks. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 28 Sep 2015 15:01:08 +0200, Richard Brown wrote:
Hi all,
Got your attention? :) This is hopefully the last email I'll send on this topic
openSUSE Leap 42.1 is now in Beta 1, and from an engineering perspective things are going quite well (ie. It works!)
But the distribution is 'missing' quite a few packages compared to openSUSE 13.2 (-1130) and Tumbleweed (-1480)
The reason for this is simple - no one has submitted those packages and/or maintainers have not accepted the outstanding reviews for those packages
While having a tidier distribution isn't a bad thing, it's a bit of a concern that so many packages might be either unwanted, or unloved by their maintainers
= What can I do about it? =
Well, obviously, I'd hope you've been downloading the openSUSE Leap 42.1 beta and testing it, and finding that the stuff you want is missing that way. But assuming that you haven't...
Review the following two package list diffs
http://paste.opensuse.org/77513865 ;- packages that are in Tumbleweed but not in Leap http://paste.opensuse.org/28259518 ;- packages that are in 13.2 but not in Leap
Some listed packages seem not existing (e.g. ZynAddSubFX, which was renamed as zynaddsubfx and already merged to Leap, or xfce4-plugins-* that are deprecated on FACTORY). Could you refresh it?
If there are packages you desire, then double check they're not already on the way to Leap - https://build.opensuse.org/project/requests/openSUSE:Leap:42.1
Wouldn't it be better to put some mark (or SRID) to each list item? It would save lots of time to look through. I already hit a few times.
If not, then submit them!
To submit a package from Tumbleweed to Leap run
osc submitrequest -m 'Submitting $package for Leap' openSUSE:Factory/$package openSUSE:Leap:42.1
If it makes sense to use the SLE-12 version instead (shouldn't be many of these left, but just in case), then submit a package from SLE-12-SP1 to Leap:
osc submitrequest -m 'Submitting $package for Leap' SLE-12 -SP1:GA/$package openSUSE:Leap:42.1
If you're not the maintainer of the package, don't worry, the maintainer will be involved in the review process to ensure they're happy with their package ending up in Leap. But we need YOU to tell us it should be in our new Distribution.
If you ARE the maintainer of the package, please review and accept/deny the request in a very prompt manner
When Leap is released in November, if anyone on this list complains that a package they wanted in the distribution is missing, expect my sympathy levels to be dramatically lower than usual, you have been warned :)
I'm struck by the amount of list, especially about languages packages like perl-*. Maybe most of such packages are leaf packages and needed rarely. But the amount is... Interestingly, it seems that Coolo is the one who updated many of such perl packages. Coolo, are these packages left intentionally? If so, can we put some marks in the list for avoiding confusion? thanks, Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 29.09.2015 um 08:06 schrieb Takashi Iwai:
Interestingly, it seems that Coolo is the one who updated many of such perl packages. Coolo, are these packages left intentionally? If so, can we put some marks in the list for avoiding confusion?
I can't offer any marks, no. 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 Tue, 29 Sep 2015 08:13:47 +0200, Stephan Kulow wrote:
Am 29.09.2015 um 08:06 schrieb Takashi Iwai:
Interestingly, it seems that Coolo is the one who updated many of such perl packages. Coolo, are these packages left intentionally? If so, can we put some marks in the list for avoiding confusion?
I can't offer any marks, no.
Well, you answered only a half of questions. Are these perl-* packages left intentionally excluded from Leap? The marking is rather a question to Richard. thanks, Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 29.09.2015 10:05, Takashi Iwai wrote:
On Tue, 29 Sep 2015 08:13:47 +0200, Stephan Kulow wrote:
Am 29.09.2015 um 08:06 schrieb Takashi Iwai:
Interestingly, it seems that Coolo is the one who updated many of such perl packages. Coolo, are these packages left intentionally? If so, can we put some marks in the list for avoiding confusion?
I can't offer any marks, no.
Well, you answered only a half of questions. Are these perl-* packages left intentionally excluded from Leap?
Ah, you mean if I actively did nothing about perl packages in Leap? No, I only did passively nothing about perl packages - as everyone else ;( Max submitted every package in Factory that built against Leap and from what I remember every perl package in there was approved. That means to me, the rest of the packages just didn't build for Leap. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 29 Sep 2015 10:44:13 +0200, Stephan Kulow wrote:
On 29.09.2015 10:05, Takashi Iwai wrote:
On Tue, 29 Sep 2015 08:13:47 +0200, Stephan Kulow wrote:
Am 29.09.2015 um 08:06 schrieb Takashi Iwai:
Interestingly, it seems that Coolo is the one who updated many of such perl packages. Coolo, are these packages left intentionally? If so, can we put some marks in the list for avoiding confusion?
I can't offer any marks, no.
Well, you answered only a half of questions. Are these perl-* packages left intentionally excluded from Leap?
Ah, you mean if I actively did nothing about perl packages in Leap? No, I only did passively nothing about perl packages - as everyone else ;(
Max submitted every package in Factory that built against Leap and from what I remember every perl package in there was approved. That means to me, the rest of the packages just didn't build for Leap.
Thanks for clarification. So what's the next step for fixing these? Ping maintainers more aggressively? Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 29.09.2015 11:12, Takashi Iwai wrote:
On Tue, 29 Sep 2015 10:44:13 +0200, Stephan Kulow wrote:
On 29.09.2015 10:05, Takashi Iwai wrote:
On Tue, 29 Sep 2015 08:13:47 +0200, Stephan Kulow wrote:
Am 29.09.2015 um 08:06 schrieb Takashi Iwai:
Interestingly, it seems that Coolo is the one who updated many of such perl packages. Coolo, are these packages left intentionally? If so, can we put some marks in the list for avoiding confusion?
I can't offer any marks, no.
Well, you answered only a half of questions. Are these perl-* packages left intentionally excluded from Leap?
Ah, you mean if I actively did nothing about perl packages in Leap? No, I only did passively nothing about perl packages - as everyone else ;(
Max submitted every package in Factory that built against Leap and from what I remember every perl package in there was approved. That means to me, the rest of the packages just didn't build for Leap.
Thanks for clarification. So what's the next step for fixing these? Ping maintainers more aggressively?
Our perl modules are maintained by a bot and I'm really not interested in having all of this cpan stuff in Leap. But if you have a specific perl package at hands you need, submit it and make sure you also submit its dependencies. But be warned: perl modules are a mess - e.g. devel:openQA:42 contains all the perl modules Ludwig needed to get openQA installed on Leap. Those might be actually good candidates to submit Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 29 Sep 2015 11:16:11 +0200, Stephan Kulow wrote:
On 29.09.2015 11:12, Takashi Iwai wrote:
On Tue, 29 Sep 2015 10:44:13 +0200, Stephan Kulow wrote:
On 29.09.2015 10:05, Takashi Iwai wrote:
On Tue, 29 Sep 2015 08:13:47 +0200, Stephan Kulow wrote:
Am 29.09.2015 um 08:06 schrieb Takashi Iwai:
Interestingly, it seems that Coolo is the one who updated many of such perl packages. Coolo, are these packages left intentionally? If so, can we put some marks in the list for avoiding confusion?
I can't offer any marks, no.
Well, you answered only a half of questions. Are these perl-* packages left intentionally excluded from Leap?
Ah, you mean if I actively did nothing about perl packages in Leap? No, I only did passively nothing about perl packages - as everyone else ;(
Max submitted every package in Factory that built against Leap and from what I remember every perl package in there was approved. That means to me, the rest of the packages just didn't build for Leap.
Thanks for clarification. So what's the next step for fixing these? Ping maintainers more aggressively?
Our perl modules are maintained by a bot and I'm really not interested in having all of this cpan stuff in Leap. But if you have a specific perl package at hands you need, submit it and make sure you also submit its dependencies.
But be warned: perl modules are a mess - e.g. devel:openQA:42 contains all the perl modules Ludwig needed to get openQA installed on Leap. Those might be actually good candidates to submit
So this sounds more like an answer to the first question: these missing perl packages are more or less intentionally left without picking up to Leap. The list should be really updated to reflect the current status... thanks, Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday 28 of September 2015 15:01:08 Richard Brown wrote: ...
But the distribution is 'missing' quite a few packages compared to openSUSE 13.2 (-1130) and Tumbleweed (-1480)
The reason for this is simple - no one has submitted those packages and/or maintainers have not accepted the outstanding reviews for those packages ... If not, then submit them!
To submit a package from Tumbleweed to Leap run
osc submitrequest -m 'Submitting $package for Leap' openSUSE:Factory/$package openSUSE:Leap:42.1
How much time do we have? I would like to get twinkle into Leap 42.1 but I had to wait for libzrtpcpp and now I realized that while Leap presents itself as "1315", it already has ilbc-devel split out (unlike 13.2) so that another specfile hack will be needed and it may take some time before it propagates through network:telephony and staging project into openSUSE:Factory. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 28.09.2015 15:01, Richard Brown wrote:
Well, obviously, I'd hope you've been downloading the openSUSE Leap 42.1 beta and testing it,
If the installer would be working at all, I would have installed it on a few machines. bsc#947730
and finding that the stuff you want is missing that way. But assuming that you haven't...
Review the following two package list diffs
http://paste.opensuse.org/77513865 ;- packages that are in Tumbleweed but not in Leap http://paste.opensuse.org/28259518 ;- packages that are in 13.2 but not in Leap
If there are packages you desire, then double check they're not already on the way to Leap - https://build.opensuse.org/project/requests/openSUSE:Leap:42.1
If not, then submit them!
That's not possible. One example: dtv-scan-tables. Does not build on Leap, because the v4l-utils / dvb-utils stack is too old. I tried to fix it, but just gave up.
To submit a package from Tumbleweed to Leap run
osc submitrequest -m 'Submitting $package for Leap' openSUSE:Factory/$package openSUSE:Leap:42.1
As I wrote, it will not build in Leap because of missing dependencies.
If it makes sense to use the SLE-12 version instead (shouldn't be many of these left, but just in case), then submit a package from SLE-12-SP1 to Leap:
osc submitrequest -m 'Submitting $package for Leap' SLE-12 -SP1:GA/$package openSUSE:Leap:42.1
The package is not in SLE-12-SP1.
When Leap is released in November, if anyone on this list complains that a package they wanted in the distribution is missing, expect my sympathy levels to be dramatically lower than usual, you have been warned :)
Well, *you* have been warned that combining old crap (SLE12) with tumbleweed will not work out in practice and that it might be hard to motivate packager and developers to fix this. Expect my sympathy level to be dramatically lower than usual if Leap turns out to be a marketing disaster, because users cannot find the software they have been using for decades in it :-) Best regards, Stefan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, just my few comments below and please excuse my ignorance and missing knowledge about v4l and all that. Am 30.09.2015 um 09:52 schrieb Stefan Seyfried:
That's not possible.
One example: dtv-scan-tables.
Does not build on Leap, because the v4l-utils / dvb-utils stack is too old. I tried to fix it, but just gave up.
v4l-utils and dvb-utils does not at all sound like packages which are useful to use from SLE. Wasn't it possible to update them with the Factory versions? I guess nobody said it'll be easy to create Leap and we try it the first time. Actually I think we do not have enough time in the roadmap to make it perfect in the first phase. I hope we'll be able to come closer with 42.1. Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 30.09.2015 10:06, Wolfgang Rosenauer wrote:
Hi,
just my few comments below and please excuse my ignorance and missing knowledge about v4l and all that.
That's not ignorance. Almost nobody shold have to know abut v4l :-)
Am 30.09.2015 um 09:52 schrieb Stefan Seyfried:
That's not possible.
One example: dtv-scan-tables.
Does not build on Leap, because the v4l-utils / dvb-utils stack is too old. I tried to fix it, but just gave up.
v4l-utils and dvb-utils does not at all sound like packages which are useful to use from SLE. Wasn't it possible to update them with the Factory versions?
I am not the maintainer of v4l/dvb-utils, and I do not want to be. So I'm not going to submit it to Leap (committing to support it for basically forever). Additionally they do not build for Leap at all, because the specfile checks for version > 1320 and Leap only has 1315, but is often newer than 1320. And the benefit of Leap (as it was sold) is, that we'll get the stability of SLES12 for free. If we are going to update everything to Factory, then it's just the same as Tumbelweed.
I guess nobody said it'll be easy to create Leap and we try it the first time. Actually I think we do not have enough time in the roadmap to make it perfect in the first phase. I hope we'll be able to come closer with 42.1.
This *is* 42.1 already :-) maybe for 44... Best regards, Stefan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 30 Sep 2015 10:29:49 +0200, Stefan Seyfried wrote:
Am 30.09.2015 um 09:52 schrieb Stefan Seyfried:
That's not possible.
One example: dtv-scan-tables.
Does not build on Leap, because the v4l-utils / dvb-utils stack is too old. I tried to fix it, but just gave up.
v4l-utils and dvb-utils does not at all sound like packages which are useful to use from SLE. Wasn't it possible to update them with the Factory versions?
I am not the maintainer of v4l/dvb-utils, and I do not want to be. So I'm not going to submit it to Leap (committing to support it for basically forever).
Additionally they do not build for Leap at all, because the specfile checks for version > 1320 and Leap only has 1315, but is often newer than 1320.
Yeah, the version number is one of the biggest pains...
And the benefit of Leap (as it was sold) is, that we'll get the stability of SLES12 for free. If we are going to update everything to Factory, then it's just the same as Tumbelweed.
The advantage of Leap is the shared "core" stuff with SLE12. (The kernel is an exception, but here a kernel team takes care of it, so it's more or less well maintained.) v4l or dvb-utils isn't no core but rather a leaf package, I'd say. They are *often* better to follow the newer one from FACTORY. BTW, exactly which packages meant as dvb-utils? Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Takashi, On 30.09.2015 10:39, Takashi Iwai wrote:
On Wed, 30 Sep 2015 10:29:49 +0200, Stefan Seyfried wrote:
I am not the maintainer of v4l/dvb-utils, and I do not want to be. So I'm not going to submit it to Leap (committing to support it for basically forever).
Additionally they do not build for Leap at all, because the specfile checks for version > 1320 and Leap only has 1315, but is often newer than 1320.
Yeah, the version number is one of the biggest pains...
Agreed. And the "parts of it are older than 13.2 and parts of it are almost newer than Factory", combined with the apparent inability to conditionalize on *features* instead of *versions* in OBS.
And the benefit of Leap (as it was sold) is, that we'll get the stability of SLES12 for free. If we are going to update everything to Factory, then it's just the same as Tumbelweed.
The advantage of Leap is the shared "core" stuff with SLE12. (The kernel is an exception, but here a kernel team takes care of it, so it's more or less well maintained.)
Ok, I thought that X11 and stuff (which I would consider "core" for the audience) was also newer to be able to display something on machines newer than 5 years :-)
v4l or dvb-utils isn't no core but rather a leaf package, I'd say. They are *often* better to follow the newer one from FACTORY.
But then I don't get the benefits of a stable system :-)
BTW, exactly which packages meant as dvb-utils?
It's a sub-package of v4l-utils (split off after 13.2). Basicalls the userspace tools and libs to handle DVB stuff (which has exactly nothing to do technically with V4L :-), and thus splitting off the package makes perfect sense). susi:~ # rpm -qi dvb-utils|grep Source Source RPM : v4l-utils-1.6.3-1.1.src.rpm you can see the build-problem of dtv-scan-tables in the vdr repository, dvb-format-convert just segfaults when trying to convert the (new format) dtv-scan-tables. I fixed the segfaults locally, but it still cannot convert the new-format files. Anyway, dtv-scan-tables and dvb-utils are probably mostly irrelevant for most of the Leap customers. And for those who need it, I can still add all dependencies to the vdr repo so they can get a working, but totally unsupported(!) version. I just stumbled over it, when I enabled Leap42.1 build for vdr and subprojects and wondered about the build failures. But the same thing will happen to Software packages, people are actually caring about, and where "use unofficial repositories" is not an answer we would give to our users. Best regards, Stefan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 30 Sep 2015 11:14:58 +0200, Stefan Seyfried wrote:
Hi Takashi,
On 30.09.2015 10:39, Takashi Iwai wrote:
On Wed, 30 Sep 2015 10:29:49 +0200, Stefan Seyfried wrote:
I am not the maintainer of v4l/dvb-utils, and I do not want to be. So I'm not going to submit it to Leap (committing to support it for basically forever).
Additionally they do not build for Leap at all, because the specfile checks for version > 1320 and Leap only has 1315, but is often newer than 1320.
Yeah, the version number is one of the biggest pains...
Agreed. And the "parts of it are older than 13.2 and parts of it are almost newer than Factory", combined with the apparent inability to conditionalize on *features* instead of *versions* in OBS.
And the benefit of Leap (as it was sold) is, that we'll get the stability of SLES12 for free. If we are going to update everything to Factory, then it's just the same as Tumbelweed.
The advantage of Leap is the shared "core" stuff with SLE12. (The kernel is an exception, but here a kernel team takes care of it, so it's more or less well maintained.)
Ok, I thought that X11 and stuff (which I would consider "core" for the audience) was also newer to be able to display something on machines newer than 5 years :-)
Who said X11 is the core stuff? ;) Maybe it's better to interpret: Leap takes the SLE12 core stuff whenever it makes more sense, but not always when it doesn't.
v4l or dvb-utils isn't no core but rather a leaf package, I'd say. They are *often* better to follow the newer one from FACTORY.
But then I don't get the benefits of a stable system :-)
It'd be stable -- in the sense of update frequency ;)
BTW, exactly which packages meant as dvb-utils?
It's a sub-package of v4l-utils (split off after 13.2). Basicalls the userspace tools and libs to handle DVB stuff (which has exactly nothing to do technically with V4L :-), and thus splitting off the package makes perfect sense).
susi:~ # rpm -qi dvb-utils|grep Source Source RPM : v4l-utils-1.6.3-1.1.src.rpm
Ah, I see, thanks.
you can see the build-problem of dtv-scan-tables in the vdr repository, dvb-format-convert just segfaults when trying to convert the (new format) dtv-scan-tables. I fixed the segfaults locally, but it still cannot convert the new-format files.
Anyway, dtv-scan-tables and dvb-utils are probably mostly irrelevant for most of the Leap customers. And for those who need it, I can still add all dependencies to the vdr repo so they can get a working, but totally unsupported(!) version. I just stumbled over it, when I enabled Leap42.1 build for vdr and subprojects and wondered about the build failures.
But the same thing will happen to Software packages, people are actually caring about, and where "use unofficial repositories" is not an answer we would give to our users.
Right, this is the case we really need to care better in the official package. So, the right step here is to ask *openSUSE* v4l-utils package maintainers whether they are OK to use the latest package for Leap. After all, it's maintainer's responsibility. Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Takashi Iwai <tiwai@suse.de> writes:
Maybe it's better to interpret: Leap takes the SLE12 core stuff whenever it makes more sense, but not always when it doesn't.
Leap takes the SLE12 core stuff except when it doesn't. :-) 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." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 30.09.2015 um 10:29 schrieb Stefan Seyfried:
On 30.09.2015 10:06, Wolfgang Rosenauer wrote:
I am not the maintainer of v4l/dvb-utils, and I do not want to be. So I'm not going to submit it to Leap (committing to support it for basically forever).
those should be no problem to update with later .X versions (but again I'm not an expert). Also have you talked to the maintainer?
Additionally they do not build for Leap at all, because the specfile checks for version > 1320 and Leap only has 1315, but is often newer than 1320.
Yes, for some packages we had to fix this. It's allowed to create a new "branch" for a package if required for Leap. There should be a plan to streamline again asap though. We did that for other packages.
And the benefit of Leap (as it was sold) is, that we'll get the stability of SLES12 for free. If we are going to update everything to Factory, then it's just the same as Tumbelweed.
Nobody said we should update everything. We need to apply human intelligence and find the best solution on a case by case base. And yes, that is what I meant that this is not an easy thing.
I guess nobody said it'll be easy to create Leap and we try it the first time. Actually I think we do not have enough time in the roadmap to make it perfect in the first phase. I hope we'll be able to come closer with 42.1.
This *is* 42.1 already :-)
I obviously meant 42.2 and later because we can obviously be more progressive with package version updates and stuff with those releases. Please don't get me wrong. I'm a big exponent of using SLE packages as much as possible and changing that should have a good reason. But in your case it sounds like a good reason. And yes Leap also means that SLE and openSUSE maintainers need to work closer together and this needs "social" overhead. But in the end we hopefully end up with something useful (and we still have Tumbleweed). I'm really optimistic we can make that work. Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Wolfgang, On 30.09.2015 10:50, Wolfgang Rosenauer wrote:
Am 30.09.2015 um 10:29 schrieb Stefan Seyfried:
On 30.09.2015 10:06, Wolfgang Rosenauer wrote:
I am not the maintainer of v4l/dvb-utils, and I do not want to be. So I'm not going to submit it to Leap (committing to support it for basically forever).
those should be no problem to update with later .X versions (but again I'm not an expert). Also have you talked to the maintainer?
Not yet. As explained to Takashi, I just stumbled over that package because its devel project is "my" vdr project and it failed to build when I enabled Leap 42.1 builds there.
Additionally they do not build for Leap at all, because the specfile checks for version > 1320 and Leap only has 1315, but is often newer than 1320.
Yes, for some packages we had to fix this. It's allowed to create a new "branch" for a package if required for Leap. There should be a plan to streamline again asap though. We did that for other packages.
Personally I would try to avoid branches, as working with them is a real PITA IMHO.
And the benefit of Leap (as it was sold) is, that we'll get the stability of SLES12 for free. If we are going to update everything to Factory, then it's just the same as Tumbelweed.
Nobody said we should update everything. We need to apply human intelligence and find the best solution on a case by case base. And yes, that is what I meant that this is not an easy thing.
Unfortunately, v4l-utils is not exactly a leaf package: ~> osc whatdependson openSUSE:Factory v4l-utils standard x86_64|wc 164 165 2879 ~> osc whatdependson openSUSE:Leap:42.1 v4l-utils standard x86_64|wc 97 98 1527 Stuff like DirectFB, gnome-control-center, compiz and digikam depends on it. So just submitting the newer Version might not even work. And doing this with a later online-update is IMO almost impossible.
This *is* 42.1 already :-)
I obviously meant 42.2 and later because we can obviously be more progressive with package version updates and stuff with those releases.
Please don't get me wrong. I'm a big exponent of using SLE packages as much as possible and changing that should have a good reason. But in your case it sounds like a good reason. And yes Leap also means that SLE and openSUSE maintainers need to work closer together and this needs "social" overhead. But in the end we hopefully end up with something useful (and we still have Tumbleweed). I'm really optimistic we can make that work.
We'll see :-) A first step would be that Leap bugreports are not RESOLVE DUPLICATE'ed to SLES12-SP1 bugreports, where the original reporter and the community can no longer see them :-) Best regards, Stefan (And yes, of course I am trying to help with Leap, even if my comments sound sceptical sometimes. If not I would not have even started building "my" devel projects against it) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 30.09.2015 11:29, Stefan Seyfried wrote:
We'll see :-) A first step would be that Leap bugreports are not RESOLVE DUPLICATE'ed to SLES12-SP1 bugreports, where the original reporter and the community can no longer see them :-)
Please yell at the developers doing that - some need to get reminded daily ;( Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 30.09.2015 um 11:33 schrieb Stephan Kulow:
On 30.09.2015 11:29, Stefan Seyfried wrote:
We'll see :-) A first step would be that Leap bugreports are not RESOLVE DUPLICATE'ed to SLES12-SP1 bugreports, where the original reporter and the community can no longer see them :-)
Please yell at the developers doing that - some need to get reminded daily ;(
Believe me, I'm trying. But they are really learning-resistant. See boo#947704 :-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 30.09.2015 21:23, Stefan Seyfried wrote:
Am 30.09.2015 um 11:33 schrieb Stephan Kulow:
On 30.09.2015 11:29, Stefan Seyfried wrote:
We'll see :-) A first step would be that Leap bugreports are not RESOLVE DUPLICATE'ed to SLES12-SP1 bugreports, where the original reporter and the community can no longer see them :-)
Please yell at the developers doing that - some need to get reminded daily ;(
Believe me, I'm trying. But they are really learning-resistant. See boo#947704 :-)
So I sent yet another reminder ;( Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 30.09.2015 09:52, Stefan Seyfried wrote:
On 28.09.2015 15:01, Richard Brown wrote:
Well, obviously, I'd hope you've been downloading the openSUSE Leap 42.1 beta and testing it,
If the installer would be working at all, I would have installed it on a few machines. bsc#947730
All your machines are affected by this problem? It's pretty hardware specific, so I wonder. But thanks for testing the Beta. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 30.09.2015 10:08, Stephan Kulow wrote:
On 30.09.2015 09:52, Stefan Seyfried wrote:
If the installer would be working at all, I would have installed it on a few machines. bsc#947730
All your machines are affected by this problem? It's pretty hardware specific, so I wonder. But thanks for testing the Beta.
The ones I can use for testing, yes (a few X200s with "ölwanne"-dock). My armada of i686 laptops is no longer suitable for tests, I suppose :-P I have dup'ed one of the x200s to Leap and installed a VM for debugging the dtv-scan-tables build segfault, so I'm actually beta-testing a little bit. Best regards, Stefan -- 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 03:01:08PM +0200, Richard Brown wrote:
Hi all,
Got your attention? :) This is hopefully the last email I'll send on this topic
Hmmm ... I'm maintaining several packages and many of them are very common in SLES12 as well as in openSUSE 13.2 and Tumbleweed. Nevertheless I do not have the time to take a look at all my packages and make a decision for all of those. Sorry, but this does not work. Werner -- --------------------------------------------------------------------------- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr
participants (10)
-
Andreas Schwab -
Claudio Freire -
Dominique Leuenberger / DimStar -
Dr. Werner Fink -
Michal Kubecek -
Richard Brown -
Stefan Seyfried -
Stephan Kulow -
Takashi Iwai -
Wolfgang Rosenauer