On 25 July 2015 at 15:48, Wolfgang Rosenauer wrote:

Hi,

Am 24.07.2015 um 22:59 schrieb Richard Brown:

...

Hi All,

As we have Milestone 1 of Leap 42.1 out now and I'm sure both bugs requests for packages are going to start cropping up, I've added to the wiki some instructions on how to Contribute to Leap so it should be really easy for people to start helping fix things

https://en.opensuse.org/openSUSE:How_to_contribute_to_Leap

I've also updated the https://en.opensuse.org/Portal:Leap and https://en.opensuse.org/openSUSE:Leap with some more up to date information

Just installed milestone 1 to replace a 12.3 server instance in a vSphere environment.

I still have questions left:

Yes, I understood I can submit packages from Factory to Leap. But for example what to do when I miss packages which are in openSUSE Factory but not in Leap and are not maintained by myself?

Ask the maintainer of the factory package to do the Submit request?

Interestingly all I found so far are actually in SLES12. So why are they missing in Leap then? What to do to get them from SLES12 to Leap?

I'm talking about the following examples I found quickly:

amavisd-new clamav rsyslog open-vm-tools

I would imagine osc sr SUSE:SLE-12:GA/$packagename openSUSE:42 or osc sr SUSE:SLE-12:Update/$packagename openSUSE:42 would be the way to go -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 25 July 2015 at 16:35, Wolfgang Rosenauer wrote:

Am 25.07.2015 um 16:14 schrieb Richard Brown:

...

...

Interestingly all I found so far are actually in SLES12. So why are they missing in Leap then? What to do to get them from SLES12 to Leap?

I'm talking about the following examples I found quickly:

amavisd-new clamav rsyslog open-vm-tools

I would imagine

osc sr SUSE:SLE-12:GA/$packagename openSUSE:42

or

osc sr SUSE:SLE-12:Update/$packagename openSUSE:42

would be the way to go

Given that SLES12 is quite small in the first place, why are not all packages from there in Leap already? I thought there must be a reason and therefore a simple SR sounds too easy.

Wolfgang

My guess? In order to build a Milestone 1 with the greatest chance of working as well as the current one is, we started with a very tightly defined SLE core, similar to openSUSE's Rings 0 and 1 Enough to get the OS started and running, but not with all of the tools and other stuff you need Then, we've thrown ontop a significant amount of openSUSE Tumbleweed and built it ontop of this core, but primarily things which we know will get peoples attention and interest in testing.. KDE, GNOME, and the like We know the package list in Milestone 1 needs work, from both the 'stuff from Tumbleweed' and the 'stuff from SLE' direction, but we have a good starting point for that now We know we have an OS that boots and is usable for something, which is exactly the state we need it in so we can add new stuff while continuously testing it and making sure the new stuff doesn't break anything :) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 26.07.2015 um 07:39 schrieb Stephan Kulow:

Just do it - I only picked from SLE12 the rings, not the full set and I ignored products completely.

BTW: We maintain openSUSE:42:Factory-Candidates-Check building Factory packages against 42 - everything that succeeds can possibly be submitted. But of course submitting from SLE-12:Update should be fine too 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

Am 26.07.2015 um 11:48 schrieb Wolfgang Rosenauer:

Am 26.07.2015 um 07:42 schrieb Stephan Kulow:

...

Am 26.07.2015 um 07:39 schrieb Stephan Kulow:

...

Just do it - I only picked from SLE12 the rings, not the full set and I ignored products completely.

BTW: We maintain openSUSE:42:Factory-Candidates-Check building Factory packages against 42 - everything that succeeds can possibly be submitted. But of course submitting from SLE-12:Update should be fine too

Just wanted to check for pcsc-lite which is rather old (and I think buggy) in 42 as inherited from SLE12 and because it's a candidate for improved/up-to-date hardware support together with other pcsc-* updates in Factory.

So I see the package as "inherited" in Factory-Candidates-Check but I cannot find any build result.

https://build.opensuse.org/project/monitor?utf8=%E2%9C%93&commit=Filter%3A&succeeded=1&failed=1&unresolvable=1&broken=1&blocked=1&dispatching=1&scheduled=1&building=1&finished=1&signing=1&disabled=1&excluded=1&locked=1&deleting=1&unknown=1&pkgname=pcsc-lite&repo_pure_42=1&arch_x86_64=1&project=openSUSE%3A42%3AFactory-Candidates-Check&defaults=0

What did I miss?

The f-c-c project only builds packages not yet in 42 - so it's not for your use case. Sorry - for this we would need to setup another. 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 Sun, Jul 26, 2015 at 4:35 AM, Stephan Kulow wrote:

Am 26.07.2015 um 11:48 schrieb Wolfgang Rosenauer:

...

Am 26.07.2015 um 07:42 schrieb Stephan Kulow:

...

Am 26.07.2015 um 07:39 schrieb Stephan Kulow:

...

Just do it - I only picked from SLE12 the rings, not the full set and I ignored products completely.

BTW: We maintain openSUSE:42:Factory-Candidates-Check building Factory packages against 42 - everything that succeeds can possibly be submitted. But of course submitting from SLE-12:Update should be fine too

Just wanted to check for pcsc-lite which is rather old (and I think buggy) in 42 as inherited from SLE12 and because it's a candidate for improved/up-to-date hardware support together with other pcsc-* updates in Factory.

So I see the package as "inherited" in Factory-Candidates-Check but I cannot find any build result.

https://build.opensuse.org/project/monitor?utf8=%E2%9C%93&commit=Filter%3A&succeeded=1&failed=1&unresolvable=1&broken=1&blocked=1&dispatching=1&scheduled=1&building=1&finished=1&signing=1&disabled=1&excluded=1&locked=1&deleting=1&unknown=1&pkgname=pcsc-lite&repo_pure_42=1&arch_x86_64=1&project=openSUSE%3A42%3AFactory-Candidates-Check&defaults=0

What did I miss?

The f-c-c project only builds packages not yet in 42 - so it's not for your use case. Sorry - for this we would need to setup another.

Greetings Stephan

I can see from https://build.opensuse.org/project/list_public when I search for openSUSE:42 there are 18 Projects that begin with the string openSUSE:42: How does one decide where to add to the effort to create the next regular release in a non-duplicating, non-interfering manner? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi, On 07/25/2015 04:33 PM, Wolfgang Rosenauer wrote:

Am 25.07.2015 um 16:26 schrieb Peter Czanik:

...

Hi,

...

Hi All,

As we have Milestone 1 of Leap 42.1 out now and I'm sure both bugs requests for packages are going to start cropping up, I've added to the wiki some instructions on how to Contribute to Leap so it should be really easy for people to start helping fix things

https://en.opensuse.org/openSUSE:How_to_contribute_to_Leap But how do I test builds for Leap? I tried "add repo", but Leap is not

On 07/24/2015 10:59 PM, Richard Brown wrote: listed there. My package, syslog-ng, has different dependencies for different SLES and openSUSE releases, so I'd like to test that everything works correctly, before submitting to Leap. I have no answer to your question but given that syslog-ng is also in SLES AFAIK, do you actually want to overwrite it?

It was the default in SLES11. With SLES12 it's not in SLES core any more, but available only through a "legacy" repo. That version is quite old (3.4), already EoL upstream. My plan is to get the current "factory" version into Leap now, and update both Factory and Leap to syslog-ng 3.7 once released by the end of Summer. This is a version, which syslog-ng upstream can support much longer than anything earlier than syslog-ng 3.6. Bye, CzP (from syslog-ng upstream) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi, On 07/25/2015 06:31 PM, Richard Brown wrote:

Hi Peter,

On 25 July 2015 at 16:51, Peter Czanik wrote:

...

It was the default in SLES11. With SLES12 it's not in SLES core any more, but available only through a "legacy" repo. That version is quite old (3.4), already EoL upstream.

My plan is to get the current "factory" version into Leap now, and update both Factory and Leap to syslog-ng 3.7 once released by the end of Summer. This is a version, which syslog-ng upstream can support much longer than anything earlier than syslog-ng 3.6.

From the sound of things, I don't think I need to ask _you_ this question, but for the sake of illustration for anyone else in a similar position to you, I'm still going to ask these 3 questions so everyone knows the sort of things that I think should cross package maintainers minds as they submit things to Leap.

1. Will users get any practical benefit from the new package compared to the version available from SLES?

Yes, there are many. Journal source support, JSON parsing and formatting just to name the most popular from a long list of new features. https://czanik.blogs.balabit.com/2014/10/syslog-ng-3-6-1-is-released/ https://asylum.madhouse-project.org/blog/2013/11/06/syslog-ng-3.5.1/

I think the SLES one, with it's SUSE provided maintenance should still be considered unless there is a compelling reason to upgrade it I personally don't think 'it's old', on it's own, is a valid compelling reason (NOTE: in the case of syslog-ng I realise it's presence in the legacy module means the SUSE provided maintenance may not match what we want for Leap, to me that is a valid compelling reason, but I'm still leaving this question here for everyone else)

Yeah, I already helped out SUSE with a syslog-ng 3.4 bug, that's how I learned about the 'legacy' repo :)

2. Assuming the answer to #1 is Yes, are you comfortable supporting your chosen newer package in Leap for at least a year, preferably with backported patches and not version updates?

Yes.

3. Assuming the answer to #2 is Yes, would you plan to increase the version of the package for Leap 42.2 a year from now?

This is a rather tough question. On one hand I also prefer stability, on the other hand if I learn from feedback, that syslog-ng version 3.X is problematic but 3.Y is all right, I'd rather do the version upgrade. Bye, CzP

Where possible I'd like to see package version choices for Leap favour versions that we can ideally keep around for a while for the sake of long term stability, after all we have Tumbleweed for the 'follow upstream at the pace of upstream' scenario

Regards,

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sat, Jul 25, 2015 at 10:26 AM, Peter Czanik wrote:

Hi,

On 07/24/2015 10:59 PM, Richard Brown wrote:

...

Hi All,

As we have Milestone 1 of Leap 42.1 out now and I'm sure both bugs requests for packages are going to start cropping up, I've added to the wiki some instructions on how to Contribute to Leap so it should be really easy for people to start helping fix things

https://en.opensuse.org/openSUSE:How_to_contribute_to_Leap

But how do I test builds for Leap? I tried "add repo", but Leap is not listed there. My package, syslog-ng, has different dependencies for different SLES and openSUSE releases, so I'd like to test that everything works correctly, before submitting to Leap.

In the WebUI after you click "Add Repositories" at the top of the list is "Or pick one via advanced interface. " Form the advanced interface put "openSUSE:42" as the project. Be sure to check x86_64 (or some other arch) I just did it for the security:forensics project and builds are commencing. https://build.opensuse.org/project/show/security:forensics Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org