On Wed, Sep 30, 2015 at 5:42 AM, Dominique Leuenberger / DimStar wrote:

On Mon, 2015-09-28 at 19:06 -0300, Claudio Freire wrote:

...

On Mon, Sep 28, 2015 at 10:01 AM, Richard Brown 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

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 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 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

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 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

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

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

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

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 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