[opensuse-factory] mono in Factory

Dinar Valeev

21 Mar 2015 21 Mar '15

20:34

Hi, many packages are built with bcond without mono. which means project config should say that explicit to build without it. Factory prjconf don't say either. Do we want to have gnome and kde4 desktops really depend on Mono? I'm not proposing to drop mono completely, just build without mono by default. affected packages are: libcaca libgpod gmime libproxy libkolabxml While this blocks gnome and kde for ppc64le at the moment (mono is broken there) I believe x86 will benefit as well. Stagings and Rongs will not depend on mono build anymore -> faster checkins to the Factory. Thanks, Dinar -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Show replies by date

Raymond Wooninck

21 Mar 21 Mar

21:07

On Saturday, March 21, 2015 09:34:06 PM Dinar Valeev wrote:

...

Factory prjconf don't say either. Do we want to have gnome and kde4 desktops really depend on Mono? I'm not proposing to drop mono completely, just build without mono by default.

I assume that we want to offer the full functionality of the packages to our users. For KDE this means that libkolabxml offers mono bindings if it is build with mono. At this moment there are no packages within openSUSE:Factory that are using these mono bindings, but that doesn't say anything about the world outside of Factory. Our users might as well have all kind of applications that are utilizing these mono bindings.

...

While this blocks gnome and kde for ppc64le at the moment (mono is broken there) I believe x86 will benefit as well. Stagings and Rongs will not depend on mono build anymore -> faster checkins to the Factory.

If mono is broken for ppc64le, then I suggest two alternative approaches for this issue: The first option would be to unbreak mono for ppc64le. I don't know how much work this could be, nor what exactly the issue would be. The other option would be to enhance the indicated packages by excluding mono for ppc64le builds. You could create submit requests to the development repo's. In my opinion this would be a much better way, than just to remove the functionality completely. It would be strange to say that we deliver mono, but not the bindings for it. Regards Raymond -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Dinar Valeev

21:23

...

On Saturday, March 21, 2015 09:34:06 PM Dinar Valeev wrote:

...
Factory prjconf don't say either. Do we want to have gnome and kde4 desktops really depend on Mono? I'm not proposing to drop mono completely, just build without mono by default.

I assume that we want to offer the full functionality of the packages to our users. For KDE this means that libkolabxml offers mono bindings if it is build with mono. At this moment there are no packages within openSUSE:Factory that are using these mono bindings, but that doesn't say anything about the world outside of Factory. Our users might as well have all kind of applications that are utilizing these mono bindings. Then devel projects can define with mono builds. In case use would need it Factory package can be replaced with the one from devel

On Sat, Mar 21, 2015 at 10:07 PM, Raymond Wooninck wrote: project.

...

...
While this blocks gnome and kde for ppc64le at the moment (mono is broken there) I believe x86 will benefit as well. Stagings and Rongs will not depend on mono build anymore -> faster checkins to the Factory.

If mono is broken for ppc64le, then I suggest two alternative approaches for this issue:

The first option would be to unbreak mono for ppc64le. I don't know how much work this could be, nor what exactly the issue would be.

The other option would be to enhance the indicated packages by excluding mono for ppc64le builds. You could create submit requests to the development repo's. In my opinion this would be a much better way, than just to remove the functionality completely. It would be strange to say that we deliver mono, but not the bindings for it.

Yes, I considered those options. Can even do bcond without Mono for ppc64le (I'm doing that in openSUSE:Factory:PowerPC atm) But I'm integrating now in Stagings and Rings and those are using Factory prconf. Depending to mono in Stagings looks weird to me. We can be faster without it. less scheduled jobs (couple of build slots will be freedup). Faster Factory submitions :) Don't take me wrong. I'm not pushing this initiative only because of Power, but interested in optimizing x86 stuff as well.

...

Regards

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

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

Raymond Wooninck

21:33

On Saturday, March 21, 2015 10:23:36 PM Dinar Valeev wrote:

...

...
I assume that we want to offer the full functionality of the packages to our users. For KDE this means that libkolabxml offers mono bindings if it is build with mono. At this moment there are no packages within openSUSE:Factory that are using these mono bindings, but that doesn't say anything about the world outside of Factory. Our users might as well have all kind of applications that are utilizing these mono bindings.

Then devel projects can define with mono builds. In case use would need it Factory package can be replaced with the one from devel project.

So in your vision, for what do we have Factory ?? It seems that if people want some additional functionality, they have to start searching and activating devel projects where they might encouter errors and breakages. I don't think that is the right way.

...

Depending to mono in Stagings looks weird to me. We can be faster without it. less scheduled jobs (couple of build slots will be freedup). Faster Factory submitions :)

Don't take me wrong. I'm not pushing this initiative only because of Power, but interested in optimizing x86 stuff as well.

I don't understand why you think this is so strange. If we want to really optimize, then I guess we could drop at least 40 % of all buildrequires as that those are mostly optional requirements to provide non-core functionality. Is this really what openSUSE wants to distribute ? Packages that only offer core functionality and nothing extra just to speed up the Staging ?? I know that you are only proposing to drop mono, but as long as openSUSE builds and supports mono we should also build the bindings for it. The target has always been to deliver the best and most functionlity to our users and this unfortunately means that we have to cover every single optional requirement for each and every package. (At least if the maintainer of that package wants that). For the KDE desktop this is the case and I am sure that the same is valid for GNOME. So the only alternatives are either to fix mono for ppc64le or to drop the mono requirement for just the ppc64le builds. Regards Raymond -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Martin Pluskal

22 Mar 22 Mar

08:37

Dne 21.3.2015 v 22:33 Raymond Wooninck napsal(a):

...

...
Then devel projects can define with mono builds. In case use would need it Factory package can be replaced with the one from devel project.

So in your vision, for what do we have Factory ?? It seems that if people want some additional functionality, they have to start searching and activating devel projects where they might encouter errors and breakages. I don't think that is the right way. +1

...
Depending to mono in Stagings looks weird to me. We can be faster without it. less scheduled jobs (couple of build slots will be freedup). Faster Factory submitions :)

Don't take me wrong. I'm not pushing this initiative only because of Power, but interested in optimizing x86 stuff as well.

I don't understand why you think this is so strange. If we want to really optimize, then I guess we could drop at least 40 % of all buildrequires as that those are mostly optional requirements to provide non-core functionality. Is this really what openSUSE wants to distribute ? Packages that only offer core functionality and nothing extra just to speed up the Staging ?? I know that you are only proposing to drop mono, but as long as openSUSE builds and supports mono we should also build the bindings for it.

The target has always been to deliver the best and most functionlity to our users and this unfortunately means that we have to cover every single optional requirement for each and every package. (At least if the maintainer of that package wants that). For the KDE desktop this is the case and I am sure that the same is valid for GNOME. So the only alternatives are either to fix mono for ppc64le or to drop the mono requirement for just the ppc64le builds. +1

Kind regards Martin Pluskal

André Verwijs

11:28

New subject: [opensuse-factory] RE: mono in Factory

mono for amd64 is also broken, but please don't remove mono all together, mono is VERY important for .NET (Windows) development. Many devopers (i think) would be set back if mono should disappear André ______________________________________________________________________________________ My Twitter Page: http://twitter.com/OpenSimFan My Facebook page (be my friend, please ) http://www.facebook.com/andre.verwijs My Google+ page (follow me please ) André Verwijs - Google+ https://plus.google.com/111310545842863442992 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Stephan Kulow

23 Mar 23 Mar

08:30

New subject: [opensuse-factory] RE: mono in Factory

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 22.03.2015 12:28, André Verwijs wrote:

...

mono for amd64 is also broken, but please don't remove mono all together, mono is VERY important for .NET (Windows) development.

Many devopers (i think) would be set back if mono should disappear

And they are fine with a broken one? Doesn't sound plausible to me. Actually noone so far spoke up to say he needs mono or uses mono - it's all hearsay so far ;( Greetings, Stephan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlUPzyUACgkQwFSBhlBjoJYvVACfQPiE+4x9zNhIlKqCaA+gsJaU or0AoMOGSRgkLCGVoicbBNisYxldpbZz =MmqO -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Dimstar / Dominique Leuenberger

08:46

New subject: [opensuse-factory] RE: mono in Factory

On Mon, 2015-03-23 at 09:30 +0100, Stephan Kulow wrote:

...

On 22.03.2015 12:28, André Verwijs wrote:

...
mono for amd64 is also broken, but please don't remove mono all together, mono is VERY important for .NET (Windows) development.

Many devopers (i think) would be set back if mono should disappear

And they are fine with a broken one? Doesn't sound plausible to me. Actually noone so far spoke up to say he needs mono or uses mono - it's all hearsay so far ;(

Maybe 'broken' is a bit a bold statement; it doesn't build on ppc64le as far as I understand. Maybe we should be clear which apps this means would be dropped with a removal of mono; most users will care less about the language something is written in as compared to which app they would lose: The list is not that long IIRC, but the ones I know off of head are: * banshee * bareftp * docker * flickrnet * gbrainy (at least parts of it) * giver * gnome-do * mono develop * pdfmod * Sparkleshare * Tasque * tomboy Some have good replacements, some would probably be missed more than others. Cheers, Dominique -- Dimstar / Dominique Leuenberger

Andreas Schwab

09:06

New subject: [opensuse-factory] Re: mono in Factory

Dimstar / Dominique Leuenberger writes:

...

Maybe 'broken' is a bit a bold statement; it doesn't build on ppc64le as far as I understand.

Then you should set _without_mono in the prjconf for ppc64le, just like aarch64 does, which doesn't have mono support either. 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

Dinar Valeev

09:17

New subject: [opensuse-factory] RE: mono in Factory

On Mon, Mar 23, 2015 at 9:46 AM, Dimstar / Dominique Leuenberger wrote:

...

On Mon, 2015-03-23 at 09:30 +0100, Stephan Kulow wrote:

...
On 22.03.2015 12:28, André Verwijs wrote:

...
mono for amd64 is also broken, but please don't remove mono all together, mono is VERY important for .NET (Windows) development.

Many devopers (i think) would be set back if mono should disappear

And they are fine with a broken one? Doesn't sound plausible to me. Actually noone so far spoke up to say he needs mono or uses mono - it's all hearsay so far ;(

Maybe 'broken' is a bit a bold statement; it doesn't build on ppc64le as far as I understand.

Maybe we should be clear which apps this means would be dropped with a removal of mono; most users will care less about the language something is written in as compared to which app they would lose:

The list is not that long IIRC, but the ones I know off of head are: * banshee * bareftp * docker huh, docker? * flickrnet * gbrainy (at least parts of it) * giver * gnome-do * mono develop * pdfmod * Sparkleshare * Tasque * tomboy

Some have good replacements, some would probably be missed more than others. I'm not asking to drop mono completely. Just don't build with it by default.

Cheers, Dominique -- Dimstar / Dominique Leuenberger -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Dimstar / Dominique Leuenberger

09:20

New subject: [opensuse-factory] RE: mono in Factory

On Mon, 2015-03-23 at 10:17 +0100, Dinar Valeev wrote:

...

On Mon, Mar 23, 2015 at 9:46 AM, Dimstar / Dominique Leuenberger wrote:

...
On Mon, 2015-03-23 at 09:30 +0100, Stephan Kulow wrote:

...
On 22.03.2015 12:28, André Verwijs wrote:

...
mono for amd64 is also broken, but please don't remove mono all together, mono is VERY important for .NET (Windows) development.

Many devopers (i think) would be set back if mono should disappear

And they are fine with a broken one? Doesn't sound plausible to me. Actually noone so far spoke up to say he needs mono or uses mono - it's all hearsay so far ;(

Maybe 'broken' is a bit a bold statement; it doesn't build on ppc64le as far as I understand.

Maybe we should be clear which apps this means would be dropped with a removal of mono; most users will care less about the language something is written in as compared to which app they would lose:

The list is not that long IIRC, but the ones I know off of head are: * banshee * bareftp * docker huh, docker? * flickrnet * gbrainy (at least parts of it) * giver * gnome-do * mono develop * pdfmod * Sparkleshare * Tasque * tomboy

Some have good replacements, some would probably be missed more than others. I'm not asking to drop mono completely. Just don't build with it by default.

Results in the same: we are providing one distribution in one repository. If we don't build bindings for mono, then all above packages cannot run... So switching the 'default off' equates in the end to dropping all those packages. Dominique -- Dimstar / Dominique Leuenberger

Dimstar / Dominique Leuenberger

10:22

New subject: [opensuse-factory] RE: mono in Factory

On Mon, 2015-03-23 at 10:17 +0100, Dinar Valeev wrote:

...

...
Maybe 'broken' is a bit a bold statement; it doesn't build on ppc64le as far as I understand.

Maybe we should be clear which apps this means would be dropped with a removal of mono; most users will care less about the language something is written in as compared to which app they would lose:

The list is not that long IIRC, but the ones I know off of head are: * banshee * bareftp * docker huh, docker?

Ups, my bad.. that's meant to be 'docky' Those apps all have the same name nowadays :) Cheers, Dominique -- Dimstar / Dominique Leuenberger

Dinar Valeev

10:26

New subject: [opensuse-factory] RE: mono in Factory

On Mon, Mar 23, 2015 at 11:22 AM, Dimstar / Dominique Leuenberger wrote:

...

On Mon, 2015-03-23 at 10:17 +0100, Dinar Valeev wrote:

...
...
Maybe 'broken' is a bit a bold statement; it doesn't build on ppc64le as far as I understand.

Maybe we should be clear which apps this means would be dropped with a removal of mono; most users will care less about the language something is written in as compared to which app they would lose:

The list is not that long IIRC, but the ones I know off of head are: * banshee * bareftp * docker huh, docker?

Ups, my bad.. that's meant to be 'docky'

Those apps all have the same name nowadays :) Making a whole gnome depend on mono is it worth for just couple of packages? Cheers, Dominique

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

Dimstar / Dominique Leuenberger

10:37

New subject: [opensuse-factory] RE: mono in Factory

On Mon, 2015-03-23 at 11:26 +0100, Dinar Valeev wrote:

...

...
Ups, my bad.. that's meant to be 'docky'

Those apps all have the same name nowadays :)

Making a whole gnome depend on mono is it worth for just couple of packages?

...
Cheers, Dominique

GNOME does not depend on mono.. but a couple of libraries do offer bindings and, yes, it IS worthy to provide this stuff. if you really want to split this out, then the way would be to build the same library twice: once with mono and then a 2nd .spec file which only builds the mono bindings.. but you will waste much more build cycle, so not worth it at all (especially as most libs will not allow to 'only build the bindings' - the core component always need to be built and in case of the 2nd .spec file be ignored. This is done for example in libproxy/libproxy-plugins

...

...
Dimstar / Dominique Leuenberger

-- Dimstar / Dominique Leuenberger

Dinar Valeev

15:21

New subject: [opensuse-factory] RE: mono in Factory

On Mon, Mar 23, 2015 at 11:37 AM, Dimstar / Dominique Leuenberger wrote:

...

On Mon, 2015-03-23 at 11:26 +0100, Dinar Valeev wrote:

...
...
Ups, my bad.. that's meant to be 'docky'

Those apps all have the same name nowadays :)

Making a whole gnome depend on mono is it worth for just couple of packages?

...
Cheers, Dominique

GNOME does not depend on mono.. but a couple of libraries do offer bindings and, yes, it IS worthy to provide this stuff.

if you really want to split this out, then the way would be to build the same library twice: once with mono and then a 2nd .spec file which only builds the mono bindings.. but you will waste much more build cycle, so not worth it at all (especially as most libs will not allow to 'only build the bindings' - the core component always need to be built and in case of the 2nd .spec file be ignored. This is done for example in libproxy/libproxy-plugins So, IIUC

We want to build bindings with Mono by default for KDE to be prepared to the fact some user will come and build 'third party' against libkolabxml. And we want to be prepared for that. for GNOME we want this for banshee and tomboy? btw. There is another pacakge.. graphviz-plugins which is a dependency for libzypp. But SR for it was accepted before I started this discussion.

...

...
...
Dimstar / Dominique Leuenberger

-- Dimstar / Dominique Leuenberger

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

Raymond Wooninck

15:34

New subject: [opensuse-factory] RE: mono in Factory

On Monday, March 23, 2015 04:21:31 PM Dinar Valeev wrote:

...

So, IIUC

We want to build bindings with Mono by default for KDE to be prepared to the fact some user will come and build 'third party' against libkolabxml. And we want to be prepared for that.

No, it is not if we want to prepared for this or that. The main discussion point is if we accept to drop certain functionality or not. If we want to deliver a complete KDE experience, then we need to deliver the mono bindings as well. It is not only libkolabxml, but also packages likes mono-kde4 and mono-qt4, which delivers mono bindings for KDE and Qt.

...

for GNOME we want this for banshee and tomboy?

I believe that Dominique clearly indicated that both Banshee and Tomboy would require mono in order to be build at all. So this would mean that if we drop mono, we would also drop banshee and tomboy. And I wonder what is the reasoning behind this ? Does it really take so much work in order to maintain mono for openSUSE ?? Or is the fact that it doesn't build for other arch's, the reason to loose functionality on the main i586/ x86_64 architectures ? Don't tell me that this is to save buildcycles or something like this, because packages needs to be build anyway. Whether with or without mono. Regards Raymond -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Yamaban

15:53

New subject: [opensuse-factory] Re: RE: mono in Factory

On Mon, 23 Mar 2015 16:34, Raymond Wooninck wrote:

...

On Monday, March 23, 2015 04:21:31 PM Dinar Valeev wrote:

...
So, IIUC

We want to build bindings with Mono by default for KDE to be prepared to the fact some user will come and build 'third party' against libkolabxml. And we want to be prepared for that.

No, it is not if we want to prepared for this or that. The main discussion point is if we accept to drop certain functionality or not. If we want to deliver a complete KDE experience, then we need to deliver the mono bindings as well. It is not only libkolabxml, but also packages likes mono-kde4 and mono-qt4, which delivers mono bindings for KDE and Qt.

...
for GNOME we want this for banshee and tomboy?

I believe that Dominique clearly indicated that both Banshee and Tomboy would require mono in order to be build at all. So this would mean that if we drop mono, we would also drop banshee and tomboy.

And I wonder what is the reasoning behind this ? Does it really take so much work in order to maintain mono for openSUSE ?? Or is the fact that it doesn't build for other arch's, the reason to loose functionality on the main i586/ x86_64 architectures ?

Don't tell me that this is to save buildcycles or something like this, because packages needs to be build anyway. Whether with or without mono.

Can some one give some englightment, please? For my understanding, a 'bindings'-package for a lib, should not build WITHIN the build for the lib, but as a seperate cycle, with a 'BuildRequire: libname-devel'. That way the libs (and the build-cycle for it) yould be completely independent from the package that the 'bindings' is build in. Pro: - small cycles for the base libs / apps that the 'bindings' are build for. - Build of mono-core stays small. - seperate small cycles for 'bindings'-packages Contra: - You have to keep libs/bindings/mono in sync at abi changes. The idea to pack the 'bindings' for a, b, c, blubber into the the same spec as the lib itself and the same rpm build cycle, looks nice at the first glance, but is hell in reality -- just look at bootstrap, no-one wants a second issue of that. - Yamaban. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Dimstar / Dominique Leuenberger

16:04

New subject: [opensuse-factory] Re: RE: mono in Factory

On Mon, 2015-03-23 at 16:53 +0100, Yamaban wrote:

...

Can some one give some englightment, please?

For my understanding, a 'bindings'-package for a lib, should not build WITHIN the build for the lib, but as a seperate cycle, with a 'BuildRequire: libname-devel'.

That way the libs (and the build-cycle for it) yould be completely independent from the package that the 'bindings' is build in.

It depends. In many cases, the bindings are shipped as 'extra' packages (e.g glibmm, gtkmm, gstreamermm) and in this case, of course, the bindings are built in a sep. cycle Other packages ship a set of bindings as part of the main source tree (libproxy for example ships python, perl and mono bindings all intree). In this specific case, it was split out, as libproxy turned out to go 'deep' in any stack and cycles turned out to be large. gmime also provides the bindings 'intree'. Average build time for the package is ~ 4 minutes (of which ~ 140s are setting up the buildroot)

...

Pro: - small cycles for the base libs / apps that the 'bindings' are build for. - Build of mono-core stays small.

build of mono-core does not change: mono-core is needed TO build those packages, not the other way around.

...

- seperate small cycles for 'bindings'-packages

'cycles' as in package a requires package b requires package a? Those are generally disallowed in openSUSE:Factory already and are always a reason to split. If no cycle is introduced, the overhead of maintaining two packages of one source is often too excessive.

...

Contra: - You have to keep libs/bindings/mono in sync at abi changes. The idea to pack the 'bindings' for a, b, c, blubber into the the same spec as the lib itself and the same rpm build cycle, looks nice at the first glance, but is hell in reality -- just look at bootstrap, no-one wants a second issue of that.

As said above: the strategy differs between upstream projects: if upstream has it in one source tree, it's overhead to split it in the distro. As a rule of thumb: one .tar.xz file from upstream == one package in openSUSE. Dominique -- Dimstar / Dominique Leuenberger

Dimstar / Dominique Leuenberger

15:36

New subject: [opensuse-factory] RE: mono in Factory

On Mon, 2015-03-23 at 16:21 +0100, Dinar Valeev wrote:

...

...
GNOME does not depend on mono.. but a couple of libraries do offer bindings and, yes, it IS worthy to provide this stuff.

if you really want to split this out, then the way would be to build the same library twice: once with mono and then a 2nd .spec file which only builds the mono bindings.. but you will waste much more build cycle, so not worth it at all (especially as most libs will not allow to 'only build the bindings' - the core component always need to be built and in case of the 2nd .spec file be ignored. This is done for example in libproxy/libproxy-plugins So, IIUC

We want to build bindings with Mono by default for KDE to be prepared to the fact some user will come and build 'third party' against libkolabxml. And we want to be prepared for that.

for GNOME we want this for banshee and tomboy?

for GNOME is not exactly correct, but I know what you mean. Various GNOME libraries must provide bindings for tomboy, gnome-do banshee and certainly others (gmime's mono bindings for example are needed by tomboy - and possibly stuff outside our distribution). For graphviz: what harm does it cause, that a dependency for libzypp might provide mono bindings (ok, it means libzypp will be ordered a bit further down the chain, as mono must be before graphviz). THIS could be addressed with a 2nd .spec file, as I outlined earlier (1st spec file doing graphviz-mini doing only the 'bare minimum' and graphviz.spec doing the 'full set') For ppcle64, which essentially your goal, I'd rather have the prjconf set for this project to not do mono bindings, if fixing mono is really not in reach (anybody talked with mono upstream here?) But disabling for all archs 'just because of ppcle64' is rude :) Cheers, Dominique -- Dimstar / Dominique Leuenberger

Dinar Valeev

15:48

New subject: [opensuse-factory] RE: mono in Factory

On Mon, Mar 23, 2015 at 4:36 PM, Dimstar / Dominique Leuenberger wrote:

...

On Mon, 2015-03-23 at 16:21 +0100, Dinar Valeev wrote:

...
...
GNOME does not depend on mono.. but a couple of libraries do offer bindings and, yes, it IS worthy to provide this stuff.

if you really want to split this out, then the way would be to build the same library twice: once with mono and then a 2nd .spec file which only builds the mono bindings.. but you will waste much more build cycle, so not worth it at all (especially as most libs will not allow to 'only build the bindings' - the core component always need to be built and in case of the 2nd .spec file be ignored. This is done for example in libproxy/libproxy-plugins So, IIUC

We want to build bindings with Mono by default for KDE to be prepared to the fact some user will come and build 'third party' against libkolabxml. And we want to be prepared for that.

for GNOME we want this for banshee and tomboy?

for GNOME is not exactly correct, but I know what you mean.

Various GNOME libraries must provide bindings for tomboy, gnome-do banshee and certainly others (gmime's mono bindings for example are needed by tomboy - and possibly stuff outside our distribution).

For graphviz: what harm does it cause, that a dependency for libzypp might provide mono bindings (ok, it means libzypp will be ordered a bit further down the chain, as mono must be before graphviz). THIS could be addressed with a 2nd .spec file, as I outlined earlier (1st spec file doing graphviz-mini doing only the 'bare minimum' and graphviz.spec doing the 'full set')

For ppcle64, which essentially your goal, I'd rather have the prjconf set for this project to not do mono bindings, if fixing mono is really not in reach (anybody talked with mono upstream here?) But disabling for all archs 'just because of ppcle64' is rude :) I already have in place prjconf and I'm on the way of fixing mono for LE.

Again.. This is not about it is broken for ppc64le. It is about we have to rebuild this again and again in stagings. I took it as general Factory optimization. To have fixes going though faster. Yes. My main working area is Power. But this doesn't mean I'll ask to drop any stuff doesn't build for me yet.

...

Cheers, Dominique

-- Dimstar / Dominique Leuenberger

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

Dimstar / Dominique Leuenberger

15:57

New subject: [opensuse-factory] RE: mono in Factory

On Mon, 2015-03-23 at 16:48 +0100, Dinar Valeev wrote:

...

Again.. This is not about it is broken for ppc64le. It is about we have to rebuild this again and again in stagings. I took it as general Factory optimization. To have fixes going though faster.

We also build KDE in a GNOME Staging and run all KDE tests... and vice versa. I don't think this should be considered a problem at all, but rather be seen as an opportunity, showing that integration does not break other stuff. Cheers, Dominique -- Dimstar / Dominique Leuenberger

Stefan Seyfried

16:43

New subject: [opensuse-factory] RE: mono in Factory

Am 23.03.2015 um 09:46 schrieb Dimstar / Dominique Leuenberger:

...

On Mon, 2015-03-23 at 09:30 +0100, Stephan Kulow wrote:

...
And they are fine with a broken one? Doesn't sound plausible to me. Actually noone so far spoke up to say he needs mono or uses mono - it's all hearsay so far ;(

Maybe 'broken' is a bit a bold statement; it doesn't build on ppc64le as far as I understand.

Can I even buy a useful ppc64le hardware? And will it be able to run mono or is it some embedded calculator style stuff? I mean -- "build the whole factory for all the fringe architectures always" is most likely not going to fly. -- 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

Stephan Kulow

16:50

New subject: [opensuse-factory] RE: mono in Factory

Am 23.03.2015 um 17:43 schrieb Stefan Seyfried:

...

Am 23.03.2015 um 09:46 schrieb Dimstar / Dominique Leuenberger:

...
On Mon, 2015-03-23 at 09:30 +0100, Stephan Kulow wrote:

...
And they are fine with a broken one? Doesn't sound plausible to me. Actually noone so far spoke up to say he needs mono or uses mono - it's all hearsay so far ;(

Maybe 'broken' is a bit a bold statement; it doesn't build on ppc64le as far as I understand.

Can I even buy a useful ppc64le hardware?

That depends on your budget, but: http://www.tyan.com/campaign/openpower/index.html 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

Stefan Seyfried

18:47

New subject: [opensuse-factory] RE: mono in Factory

Am 23.03.2015 um 17:50 schrieb Stephan Kulow:

...

Am 23.03.2015 um 17:43 schrieb Stefan Seyfried:

...
Can I even buy a useful ppc64le hardware?

That depends on your budget, but: http://www.tyan.com/campaign/openpower/index.html

Ok, so it needs neither gnome, nor mono and it is as relevant as the ARM moonshot(?) servers. -- 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

Martin Pluskal

08:46

New subject: [opensuse-factory] RE: mono in Factory

On Monday 23 of March 2015 09:30:33 Stephan Kulow wrote:

...

On 22.03.2015 12:28, André Verwijs wrote:

...
mono for amd64 is also broken, but please don't remove mono all together, mono is VERY important for .NET (Windows) development.

Many devopers (i think) would be set back if mono should disappear

And they are fine with a broken one? Doesn't sound plausible to me. Actually noone so far spoke up to say he needs mono or uses mono - it's all hearsay so far ;(

Greetings, Stephan Well at least some people are using mono (or at least trying) on openSUSE-13.2: https://bugzilla.opensuse.org/show_bug.cgi?id=906714

Martin

Stephan Kulow

22 Mar 22 Mar

09:37

Am 21.03.2015 um 22:33 schrieb Raymond Wooninck:

...

I don't understand why you think this is so strange. If we want to really optimize, then I guess we could drop at least 40 % of all buildrequires as that those are mostly optional requirements to provide non-core functionality. Is this really what openSUSE wants to distribute ? Packages that only offer core functionality and nothing extra just to speed up the Staging ?? I know that you are only proposing to drop mono, but as long as openSUSE builds and supports mono we should also build the bindings for it.

The target has always been to deliver the best and most functionlity to our users and this unfortunately means that we have to cover every single optional requirement for each and every package. (At least if the maintainer of that package wants that). For the KDE desktop this is the case and I am sure that the same is valid for GNOME. So the only alternatives are either to fix mono for ppc64le or to drop the mono requirement for just the ppc64le builds.

I'm in total agreement here. While I have no love for mono myself I don't see removing it as "optimization". 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

Stephan Kulow

09:34

Am 21.03.2015 um 22:23 schrieb Dinar Valeev:

...

...
On Saturday, March 21, 2015 09:34:06 PM Dinar Valeev wrote:

...
Factory prjconf don't say either. Do we want to have gnome and kde4 desktops really depend on Mono? I'm not proposing to drop mono completely, just build without mono by default.

I assume that we want to offer the full functionality of the packages to our users. For KDE this means that libkolabxml offers mono bindings if it is build with mono. At this moment there are no packages within openSUSE:Factory that are using these mono bindings, but that doesn't say anything about the world outside of Factory. Our users might as well have all kind of applications that are utilizing these mono bindings. Then devel projects can define with mono builds. In case use would need it Factory package can be replaced with the one from devel

On Sat, Mar 21, 2015 at 10:07 PM, Raymond Wooninck wrote: project.

No! Devel projects should build as factory - or their build results are worthless 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

Yamaban

21 Mar 21 Mar

22:14

New subject: [opensuse-factory] Re: mono in Factory

On Sat, 21 Mar 2015 21:34, Dinar Valeev wrote:

...

Hi, many packages are built with bcond without mono. which means project config should say that explicit to build without it.

Factory prjconf don't say either. Do we want to have gnome and kde4 desktops really depend on Mono? I'm not proposing to drop mono completely, just build without mono by default.

affected packages are: libcaca libgpod gmime libproxy libkolabxml

While this blocks gnome and kde for ppc64le at the moment (mono is broken there) I believe x86 will benefit as well. Stagings and Rongs will not depend on mono build anymore -> faster checkins to the Factory.

I can only speak for one package: * libproxy * after the last "non-happy-endings" with libproxy, I'd vote for removing any and all depencies on Mono for this package. IOW: any "Require:", or "Recomment:" line in libproxy.spec that pulls in Mono is bad, "Suggest:" is mostly ignored. libproxy has enough other problems. Personally by gut-feeling: WHY should "libcaca" use Mono ???? fail to compute! libcaca is for "ascii art" - Yamaban. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

3326

Age (days ago)

3328

Last active (days ago)

List overview

Download

27 comments

9 participants

participants (9)

Andreas Schwab
André Verwijs
Dimstar / Dominique Leuenberger
Dinar Valeev
Martin Pluskal
Raymond Wooninck
Stefan Seyfried
Stephan Kulow
Yamaban