On Fri, Mar 13, 2015 at 11:20 PM, Kevin Fenzi <kevin at scrye.com> wrote: > On Fri, 13 Mar 2015 21:25:08 +0200 > Toni Spets <toni.spets at iki.fi> wrote: > > > - comp group @xfce-desktop doesn't depend on @X Window System so it > > doesn't really work and has some wrong packages and some missing > > ok. Lets fix that. Is it base-x and fonts thats needed? > On 6 and 7 ? > I think these issues span both, regardless they should be read through carefully and checked that the packages exist and that the comp contains all of Xfce and not only part of it. Some missing packages that makes up full Xfce would include (from EPEL 7): - mousepad (there's leafpad but I'm thinking Xfce not "let's pick random packages together that seem like a good fit") - ristretto There are probably others but I haven't looked at the big picture yet, just worked with Anders to fix the first visible things. I think it's important the Xfce experience is as complete as it can be. That will require some new packaging unfortunately. Though, I believe these packages will build just fine and doesn't really require any new deps to be pulled in. I've also requested whisker menu from nonamedotc since it's a lot better compared to the stock menu and apparently is more supported now after the 4.12 release. > > Do you have a list of the wrong packages or missing ones? > I'd need some help figuring out what the Xfce experience *should* be before calling everything myself. This is where I'd like the SIG to chime in. Those two, however, would clearly need to be in. > > > - @xfce-desktop depends on gdm instead of lightdm, we think it > > should do that instead > > lightdm wasn't available when the comps were setup. > I assume this is only epel7? (I don't see it for 5/6). > > Happy to make that change. > It is only in EPEL 7 for now. I'm not sure if EPEL 6 needs to be touched that much, except look at the branding issues there as well to make sure the desktop is consistent the very least. I'd say focus on EPEL 7 first anyway and see what EPEL 6 would need based on that work as I'm guessing it has a lot of similiarities. > > > - dejavu sans fonts are not a dependency and fonts are broken > > because of that > > I am pretty sure I fixed that? > Was this: https://bugzilla.redhat.com/show_bug.cgi?id=718121 > ? > It only pulls the mono one, the default sans font isn't which is used everywhere else on the UI and the UI starts using the mono font as its fallback. I'm not sure what package should depend on it or if it should be the comps since technically that font isn't *exactly* needed as any sans font would probably do. > > If so, we added the dep to the terminal, as thats what used it. > > > - gtk-xfce-engine package is missing (EPEL7) > > Yeah. Nonamedotc was going to work on those this weekend... > Excellent! > > Right. Thanks! As noted nonamedotc was going to work on these this > weekend. I've not had time to dig into them, but if he can't fix things > up I am happy to look further. > > Filing specific bugs like this is excellent. > I'm happy to file specific bugs for generic problems and provide a patch if I can. I believe the EPEL approach is the right thing to do. > > 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. > > 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. > > 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. > > > 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. > > 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. 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. Thanks for chiming in! > > kevin > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > > -- Toni Spets -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20150314/0947dbad/attachment-0008.html>