[CentOS-devel] Fixing up Xfce for CentOS 7

[Adam Miller]

On Sun, Mar 15, 2015 at 11:42 AM, Anders F Björklund
<afb at users.sourceforge.net> wrote:
> Toni Spets wrote:
>
> On Fri, Mar 13, 2015 at 11:20 PM, Kevin Fenzi <kevin at scrye.com> wrote:
>
>
>> If you all do decide to go this way, we should still coordinate a bit,
>>
>> as some people will undoutably get Xfce from epel and enable your sig
>> stuff and we want to make sure they don't mix poorly.
>
>
> From the looks of it, I've mostly got chiming in towards option A than B
> off-list so I really doubt we would go full SIG Xfce route since you seem to
> be accepting of our help getting EPEL fixed up and sticking with 4.10 has
> benefits of its own. We could always have a separate 4.12 COPR like
> nonamedotc does for F21 for those who want it but keep all default stuff to
> minimal branding packages + EPEL.
>
>
> This seems like a good idea (providing the COPR), but apparently this (Xfce
> in EPEL) handled by the Xfce SIG rather than the EPEL SIG. Or perhaps both
> of the Fedora SIGs at once, but at any rate it's not in CentOS Extras.
>
> Putting the packages in a COPR was how it was handled last year, and it
> seems that it didn't work out perfectly ? But perhaps with some more
> awareness and documentation, it could be a better and more stable option.
>
> http://nonamedotclinux.blogspot.com/2014/03/xfce-410-on-epel-7.html
>
> https://copr.fedoraproject.org/coprs/nonamedotc/xfce412/
>

nonamedotc and myself have been working on epel7-xfce412 packages over here:
    https://copr.fedoraproject.org/coprs/maxamillion/epel7-xfce412/

If anyone is interested in helping test or fix issues, please feel
free to join in. If you would like to help fix things and work on
package builds, please just request build permissions on the COPR and
either nonamedotc or myself will be happy to approve.

My apologies for not being more vocal about the work that's going on,
on my end this has been done in free time as I've been able to find it
but it's scarce right now for various personal life reasons. I'm
always open to more collaboration. :)

-AdamM

>
>>
>>
>> Right. Moving EPEL7 to 4.12 might still be possible, I've not fully
>> decided. There are definitely issues... changing user interface on
>> people is not usually good to do.
>
>
> The decision time would be around now since Xfce is in a bad shape and
> changing it later would then break existing experience that was fixed up
> first. I'm not saying it's all bad, you can get mostly everything working
> when you touch here and there after installing all the packages you need.
> Definitely going 4.12 later would not be in the best interest of the users.
> The amount of tears and grief at this point would be a lot less.
>
>
> Xfce got off to a slow start, since EPEL-7 was still in beta when CentOS-7
> came out. But I wouldn't say it's in a bad shape now, and it already had a
> pretty good Xfce 4.10 experience even with the Fedora 18 packages.
>
> Most of the remaining problems are the same for all of el5-el6-el7, and it's
> about the completeness of the packaging (the rpms and the comps). And
> possibly doing some branches and rebuilds, of the missing packages.
>
>
>
>>
>>
>> smooge said:
>> > 1) A lot of plugins that were in 4.10 and earlier are no longer in
>> > 4.12
>>
>> Yeah, it's about 4-7 plugins, but we could make them work if we decided
>> to upgrade to 4.12, it would just mean we are pulling along old dead
>> upstream stuff ourselves, which is no fun when things break. ;(
>
>
> This is why the change would need to be done now and all the dead plugins
> dropped if it was going to happen. I can already hear the screams in my head
> that will come from people who use them so it's an important decision which
> way EPEL 7 shall be.
>
>
> Doesn't sound like a very good approach for an enterprise release ?
>
>>
>> > 2) A lot of 4.12 was actually built around a gtk3 and tools
>> > which aren't in EL-7.
>>
>> Only a few things have gtk3 support... the panel for adding gtk3 panel
>> plugins, the libxfce4ui library for making gtk3 apps, etc. It's pretty
>> minor and you can actually build it without that support if desired.
>
>
> Probably boils down to if it doesn't require any new deps to EL7/EPEL. If
> the gtk3 support can be compiled in with only minor dependency additions
> then that would be forwards thinking as someone might want to compile a gtk3
> plugin.
>
>
> I don't think that rebuilding things with gtk3 is very necessary in itself.
>
>
>>
>> Personally, I am focused on Fedora. I'm happy to help people out, but I
>> don't run Xfce day to day in a CentOS desktop. Thats likely where there
>> are so many polish issues (well, with 5 and 6. I didn't do much at all
>> for 7).
>
>
> Unfortunately I don't run Xfce on CentOS either (I don't run CentOS on my
> primary desktop), but I'd love to use Xfce CentOS on my laptop where I don't
> need all the fancy new things I get from latest Fedora. That's also why my
> interest in this is to help us all organize and figure out this and get the
> grunt work done in one sprint so there wouldn't be too much maintaining
> ahead regarding the SIG, hence fixing EPEL is much more desirable for me
> than doing all custom.
>
>
> We have something like 90% on EL6, and 10% on EL5. But only 1% (testing)
> EL7. So it is more interesting to fix the existing releases, and that
> doesn't need any Xfce rebases.  New fancy stuff from Fedora isn't needed at
> all, more like rebuilds/branches of old stuff that is missing from EPEL. It
> would be better to use some mechanism like SCL for add-ons, and keep the
> mainline at the current Xfce releases. The EL "rebases" *always* seem to
> break stuff.
>
>
> The general consensus seems to be that we should help you guys with EPEL so
> that we shall do first regardless. At least it isn't duplicate work as
> smooge said we would be doing if we did anything else than helping out
> existing efforts. Doing the spins and SIG branding in the end would be great
> to have on top of EPEL. That would probably be only one or two packages
> depending if whatever theme (wm and gtk) we would want is going to be in
> EPEL or not plus the default panel settings etc.
>
>
> There was some talk about an "Alternative Desktops" SIG for CentOS last
> year, but there wasn't enough interest or volunteers to form a group. Then
> we tried to narrow it down to just a "Xfce Desktop" group, but in the end
> that came down to "so just use EPEL". But maybe a spin is a nice focal
> point, then the packaging can continue in EPEL and the CentOS Xfce SIG can
> just offer a special ISO with the epel-release and @xfce-desktop already
> added to it.
>
>
> Basically I just want a better Xfce user experience, not join a club. ;-)
>
> --anders
>
>
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> http://lists.centos.org/mailman/listinfo/centos-devel
>