On Dienstag, 3. Januar 2017, 09:26:17 CET wrote Olaf Hering:

On Tue, Jan 03, Adrian Schröter wrote:

...

On Dienstag, 3. Januar 2017, 08:39:07 CET wrote Olaf Hering:

...

How is this supposed to be fixed? [ 86s] build-compare.noarch: E: SUSE-Backports-policy-SLE-conflict (Badness: 10000) Package with name build-compare already in SLE well, short answer is that you are not allowed to modify build-compare when you build for SLE backports.

build-compare is infrastructure, at the same level as OBS itself.

build-compare is a package. It is content and not OBS infrastructure. It comes from the SLE code stream, so you can modify it only there via a maintenance update atm. I don't think that we want to make an exception here and to allow to have a fork in Backports project. But I am not the Backports maintainer ;) I suppose you plan to submit your packages to Backports, right? If you just want to build them you could disable the check of course... -- Adrian Schroeter email: adrian@suse.de SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Dienstag, 3. Januar 2017, 09:41:20 CET wrote Olaf Hering:

On Tue, Jan 03, Adrian Schröter wrote:

...

...

build-compare is infrastructure, at the same level as OBS itself. build-compare is a package. It is content and not OBS infrastructure.

Even if its a package within the buildroot it remains essential build infrastructure.

just like gcc, make, rpm, ... ? It may for you, but for an OBS developer it is just content ;)

...

I suppose you plan to submit your packages to Backports, right?

I dont, other projects just use Backports as a base. I will see how to deal with this and other breakage caused by the check.

well, you can just disable the check then. -- Adrian Schroeter email: adrian@suse.de SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Dienstag, 3. Januar 2017, 10:04:57 CET wrote Olaf Hering:

On Tue, Jan 03, Adrian Schröter wrote:

...

On Dienstag, 3. Januar 2017, 09:41:20 CET wrote Olaf Hering:

...

Even if its a package within the buildroot it remains essential build infrastructure. just like gcc, make, rpm, ... ?

unlike these packages build-compare is supposed to work with all released versions, starting from SLE11.

No, they are part of the distro. And they are maintained together with the distro. SLE11 had no build-compare IIRC, so you wouldn't get one. So there is no difference to rpm or rpmlint or ... -- Adrian Schroeter email: adrian@suse.de SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Dienstag, 3. Januar 2017, 10:19:51 CET wrote Olaf Hering:

On Tue, Jan 03, Adrian Schröter wrote:

...

No, they are part of the distro. And they are maintained together with the distro. SLE11 had no build-compare IIRC, so you wouldn't get one.

If build-compare is available it will be used at the end of the build.

yes, sure, you can do whatever you want in your project. But plain SUSE:SLE-11 project has no build-compare, nor it is configured to install one by default. And if it would, it would come out of the SLE 11 project and not from somewhere else ;) -- Adrian Schroeter email: adrian@suse.de SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Tue, Jan 03, Marcus Meissner wrote:

Olaf, just open a bug describing the change you do in build-compare and submit an updated build-compare for SLE12.

In case of build-compare just _link to openSUSE:Factory/build-compare. It is always safe to use the latest version of that package. If not, give me a call. But it turned out the whole check is flawed because its not easy to use the Backports project as a base for other projects. I was hoping for a repo stack like this: myprj openSUSE:Backports:SLE-12-SP2 SUSE:SLE-12-SP2:Update If myprj needs 'X-devel' its not possible to rebuild X in myprj because the checks inherited from Backports cause a build failure, even if X is _linked from SUSE:SLE-12-SP2:GA/X (or wherever X was initially provided). So either all the missing devel packages get published, or Backports rebuilds all of the packages with missing devel packages, or each myprj has to continue to duplicate these packages. In the meantime I will stop using the Backports project as base. Olaf

[excuse the late reply - catching up after returning from holidays] Hi Olaf, On Tue, 2017-01-03 at 13:40 +0100, Olaf Hering wrote:

On Tue, Jan 03, Marcus Meissner wrote:

...

Olaf, just open a bug describing the change you do in build-compare and submit an updated build-compare for SLE12.

In case of build-compare just _link to openSUSE:Factory/build-compare. It is always safe to use the latest version of that package. If not, give me a call.

I believe this has been worked out with the maintenance team in the meantime?

But it turned out the whole check is flawed because its not easy to use the Backports project as a base for other projects.

I was hoping for a repo stack like this:   myprj  openSUSE:Backports:SLE-12-SP2 SUSE:SLE-12-SP2:Update

If myprj needs 'X-devel' its not possible to rebuild X in myprj because the checks inherited from Backports cause a build failure, even if X is _linked from SUSE:SLE-12-SP2:GA/X (or wherever X was initially provided).

So either all the missing devel packages get published, or Backports rebuilds all of the packages with missing devel packages, or each myprj has to continue to duplicate these packages.

In the meantime I will stop using the Backports project as base.

You are right about the missing -devel package, and that is something we need to look into fixing. We do want you and others to be able to use Backports as a base wherever possible. It might not work perfectly in all cases, but we are interested in fixing issues where we can. A new product in Bugzilla has been created and if you think something is broken or are in general having issues using the Backports project you can open a bug against the "openSUSE Backports" product in bugzilla.opensuse.org and the team will take a look. (the missing glew-devel package is now being looked into) Thanks and happy packaging! -Scott

On Tue, Jan 17, Marcus Meissner wrote:

On Tue, Jan 17, 2017 at 11:04:07AM +0100, Scott Bahling wrote:

...

I believe this has been worked out with the maintenance team in the meantime? No.

There is no further action required. One has to override rpmlint-backports-data anyway to build packages which have have subpackages missing. Olaf

On Tue, 2017-01-17 at 10:59 +0000, Richard Brown wrote:

On 17 January 2017 at 10:23, Olaf Hering wrote:

...

On Tue, Jan 17, Marcus Meissner wrote:

...

On Tue, Jan 17, 2017 at 11:04:07AM +0100, Scott Bahling wrote:

...

I believe this has been worked out with the maintenance team in the meantime?

No.

There is no further action required. One has to override rpmlint-backports-data anyway to build packages which have have subpackages missing.

Olaf

Isn't the whole point of building against Backports to prepare submissions for Packagehub? Doesn't disabling mandatory checks for Backports undermine that purpose?

When you look at something like devel:languages:python, there a lot of packages that can be submitted to Backports and at the same time contains packages that fail the checks because of policies. Just because those other packages are not suitable for Backports doesn't mean they shouldn't be built in the devel project. One options is to override the checks, the other option is to have both SUSE:SLE and openSUSE:Backports build targets in parallel in such projects. Not sure which is better or what the project maintainers would prefer. I'm open to both. In the end the best way to submit any packages from such large projects is to branch the packages first in an isolated project just to determine build and runtime dependencies. In the branched project the mandatory checks would kick in by default. -Scott

On Tue, 2017-01-17 at 11:23 +0100, Olaf Hering wrote:

On Tue, Jan 17, Marcus Meissner wrote:

...

On Tue, Jan 17, 2017 at 11:04:07AM +0100, Scott Bahling wrote:

...

I believe this has been worked out with the maintenance team in the meantime?

No.

There is no further action required. One has to override rpmlint-backports-data anyway to build packages which have have subpackages missing.

One idea I have had is to create an optional rpmlint with a much lower badness to just warn when building packages that replace official SLE packages for those project that want to build both packages eligible and not eligible for submission to Backports in one project (think devel:languages:*. The repo in the project would need to be configured to pull in the alternate rpmlint by adding another path to the repo definition. Of course anyone wanting to submit packages from such a configured project to the Backports project will need to take extra care that 1) they aren't getting the rpmlint warning for the package(s) in question and 2) the packages aren't dependent on others in the project that fail the rpmlint checks. That can be done by simply branching the packages in question from the devel project into a isolated project and testing the buid there (with the strict rpmlint) before submitting to openSUSE:Backports. If you think this would be helpful, we can continue to look into such an option. -Scott

On Tue, Jan 17, Scott Bahling wrote:

We do want you and others to be able to use Backports as a base wherever possible. It might not work perfectly in all cases, but we are interested in fixing issues where we can.

Is the actualy usage of Backports documented? It turned out one needs to add Backports_SP0 and Backports_SP1 and Backports_SP2 to the repo list to get all dependencies. Olaf

Hi Olaf, On 01/17/2017 11:20 AM, Olaf Hering wrote:

On Tue, Jan 17, Scott Bahling wrote:

Is the actualy usage of Backports documented? It turned out one needs to add Backports_SP0 and Backports_SP1 and Backports_SP2 to the repo list to get all dependencies.

Since Backports is slightly different than other projects it might not be obvious that the repo is layered and so you need all repos up to your service pack level in order to use Backports correctly. You can find more information at https://en.opensuse.org/openSUSE:Backports_Package_Submission_Process or at https://packagehub.suse.com and don't hesitate to contact us if you need more information. Thanks, Wolfgang -- - - - SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Dienstag, 3. Januar 2017, 10:47:23 CET wrote Olaf Hering:

Where is the public glew-devel?

there is none. Sorry, but SLE release managers decided not to publish it.

[ 140s] glew-devel.x86_64: E: SUSE-Backports-policy-SLE-conflict (Badness: 10000) Package with name glew-devel already in SLE

Olaf

-- Adrian Schroeter email: adrian@suse.de SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org