Hi Ismail, Am Mittwoch, 19. April 2017, 13:54:17 CEST schrieb İsmail Dönmez:

Hi,

On 19 Apr 13:46, Marc Dietrich wrote:

...

Am Dienstag, 18. April 2017, 14:07:09 CEST schrieb İsmail Dönmez:

...

Hi!

Since llvm4 hit the Factory, I'd like to remove llvm3_8 and llvm3_9 (along with lldb3_8 and lldb3_9) from Factory to lower the maintenance burden. Is there anyone who needs these packages for some reason please speak up now.

I don't need older versions, but maybe you could keep at least llvm3_9 (or the previous version) in order to make the transition easier. I often compile mesa from trunk, and pulling llvm3_9 under its feet makes me feel uncomfortable. Sure, we can keep it there for some more time, until 4.1 and such.

great! This also facilitates testing of llvm bugs. Thanks! Marc

On 19 Apr 14:17, Ondřej Súkup wrote:

for future LTS version of ghc we need on aarch64 llvm-3.9 :(

That's ok, we'll just need to fix the build with gcc7 and it should be fine. Thanks for the heads up. Regards, ismail -- SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)

On 19 Apr 16:05, Andreas Färber wrote:

Hi İsmail,

Am 19.04.2017 um 13:54 schrieb İsmail Dönmez:

...

On 19 Apr 13:46, Marc Dietrich wrote:

...

Am Dienstag, 18. April 2017, 14:07:09 CEST schrieb İsmail Dönmez:

...

Hi!

Since llvm4 hit the Factory, I'd like to remove llvm3_8 and llvm3_9 (along with lldb3_8 and lldb3_9) from Factory to lower the maintenance burden. Is there anyone who needs these packages for some reason please speak up now.

I don't need older versions, but maybe you could keep at least llvm3_9 (or the previous version) in order to make the transition easier. I often compile mesa from trunk, and pulling llvm3_9 under its feet makes me feel uncomfortable.

Sure, we can keep it there for some more time, until 4.1 and such.

Another concern is that llvm4 failed to build on armv7l and armv6l. armv6l is a known QEMU/glibc problem, whereas armv7l hopefully just needs to be retriggered. (Dirk? Andreas?)

https://build.opensuse.org/package/show/openSUSE:Factory:ARM/llvm4

I know about the qemu problem, and locally armv7l gave the same problem hence there is no way for me to debug it.

llvm3_9 is showing build errors for aarch64 and armv6l, but at least there's binaries available that other packages can build against.

In general the non-x86 archs may be slower at building sometimes, so please check :PowerPC and :zSystems too before making removal decisions for such a key package as llvm.

https://build.opensuse.org/package/show/openSUSE:Factory:PowerPC/llvm4 https://build.opensuse.org/package/show/openSUSE:Factory:zSystems/llvm4

I always keep an eye on SystemZ and PPC64{LE} and unlike ARM they are 99% of the time is stable. Regards, ismail -- SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)

Hi Dirk, Am 19.04.2017 um 17:12 schrieb Dirk Müller:

On 19.04.2017 16:08, İsmail Dönmez wrote:

...

...

Another concern is that llvm4 failed to build on armv7l and armv6l. armv6l is a known QEMU/glibc problem, whereas armv7l hopefully just needs to be retriggered. (Dirk? Andreas?)

I don't think this is a retrigger issue.

...

...

In general the non-x86 archs may be slower at building sometimes, so please check :PowerPC and :zSystems too before making removal decisions for such a key package as llvm.

Ismail did actually reach out to the various folks on the ARM team to get help have llvm building again for the ARM platforms.

Note that I'm not blaming Ismail for build failures here. My point was in response to "hit the Factory" and "until 4.1" that you stripped from the quote above: The decision to drop llvm3_9 from Factory should not be based on the pure _submission_ of llvm4 (or future llvm4_1) - the decision should also incorporate actual _build status_ please. As long as llvm4 hasn't built once, the new llvm remains unresolvable, and thus old llvm binaries continue to point at llvm3_9. Thus removal of llvm3_9 would break e.g. Mesa and everything that depends on it for the specific architecture. Having the old llvm still around may break the build of new packages that expect certain new llvm4 features for suse_version > 1320, like my pending Mesa submission, but it will still allow installation of dependent packages. (I figured it made the most sense to add new stuff to the new version, but I could backport my changes to llvm3_9 if needed for build sanity.) Since we do have llvm3_9 built, I have no objections to dropping llvm3_8. None of this really matters for lldb as presumed leaf package, but I understood it is against Factory policy/scripts to drop links for spec files still contained in another Factory package.

I believe the issue with llvm4 is arm_suse_support.diff which got dropped on the 3.9/4 update. I'm going to readd that and submit it if it works.

Thanks for looking into the armv7l breakage! Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, Apr 19, 2017 at 7:54 AM, İsmail Dönmez wrote:

Hi,

On 19 Apr 13:46, Marc Dietrich wrote:

...

Am Dienstag, 18. April 2017, 14:07:09 CEST schrieb İsmail Dönmez:

...

Hi!

Since llvm4 hit the Factory, I'd like to remove llvm3_8 and llvm3_9 (along with lldb3_8 and lldb3_9) from Factory to lower the maintenance burden. Is there anyone who needs these packages for some reason please speak up now.

I don't need older versions, but maybe you could keep at least llvm3_9 (or the previous version) in order to make the transition easier. I often compile mesa from trunk, and pulling llvm3_9 under its feet makes me feel uncomfortable.

Sure, we can keep it there for some more time, until 4.1 and such.

Maybe have as a general rule that Factory keeps the current LLVM version and the immediate previous LLVM version. So now that 4 is out 3.8 will be dropped, 3.9 will be dropped when 4.1 is out, and so on. Of course if there is a specific need for specific versions those can be kept on a case-by-case basis. And I assume the old versions will not be deleted from devel:tools:compiler as long as they still build, right? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org