I would like to put together an alternative desktop sig which will build, qa, and support desktops which are not the Enterprise Linux primary or secondary desktops (GNOME and KDE).
There are a couple of ground rules I would like to propose:
1) Any desktop system needs to have 3 sponsors who are people willing to do the work of building RPMS, coordinating user bugs with upstream, and fixing packages. The reason for 3 is a) that this SIG isn't a dumping ground for here is ABC-DE compiled, goodbye. b) that disagreements between sponsors should be deadlock free. c) that when people take vacations, etc there is continuity of operation. 2) Desktops do not keep to Enterprise lifetimes, but major version changes to the desktop need to be announced, tested and released to a schedule. Desktops which don't want to do that will not be part of the SIG. [A schedule does not need to be super detailed, but just alleviate surprise.] 3) Desktops can and will be removed from the SIG if there isn't an interest in keeping them up. This is mainly to cover that if ABC-DE desktop no longer has sponsors, other members of the SIG aren't obliged to support ABC-DE if they don't want to. 4) Some level of governance needs to be established so that there is a committee that can make sure that a desktop has 'sponsors', that it is not just code thrown over a wall and left, and that users are not left surprised when updates to the desktop occur. They may also make up packaging rules and guidelines as needed to alleviate problems that come up.
As this is an RFC, these are just proposed rules to be solidified when the CentOS board considers the SIG.
On 03/14/2014 12:26 PM, Stephen John Smoogen wrote:
I would like to put together an alternative desktop sig which will build, qa, and support desktops which are not the Enterprise Linux primary or secondary desktops (GNOME and KDE).
Fantastic!
There are a couple of ground rules I would like to propose:
- Any desktop system needs to have 3 sponsors who are people willing to do
the work of building RPMS, coordinating user bugs with upstream, and fixing packages. The reason for 3 is a) that this SIG isn't a dumping ground for here is ABC-DE compiled, goodbye. b) that disagreements between sponsors should be deadlock free. c) that when people take vacations, etc there is continuity of operation.
How would this apply to something like EPEL, which in el6 has XFCE packaged. Would it be acceptable to pull that in, or would that simply count as 1 of the 3?
- Desktops do not keep to Enterprise lifetimes, but major version changes
to the desktop need to be announced, tested and released to a schedule. Desktops which don't want to do that will not be part of the SIG. [A schedule does not need to be super detailed, but just alleviate surprise.] 3) Desktops can and will be removed from the SIG if there isn't an interest in keeping them up. This is mainly to cover that if ABC-DE desktop no longer has sponsors, other members of the SIG aren't obliged to support ABC-DE if they don't want to.
I would propose that anything being removed be treated as a major version change, with an announcement and warning for users.
- Some level of governance needs to be established so that there is a
committee that can make sure that a desktop has 'sponsors', that it is not just code thrown over a wall and left, and that users are not left surprised when updates to the desktop occur. They may also make up packaging rules and guidelines as needed to alleviate problems that come up.
As this is an RFC, these are just proposed rules to be solidified when the CentOS board considers the SIG.
On 14 March 2014 14:49, Jim Perrin jperrin@centos.org wrote:
On 03/14/2014 12:26 PM, Stephen John Smoogen wrote:
I would like to put together an alternative desktop sig which will build, qa, and support desktops which are not the Enterprise Linux primary or secondary desktops (GNOME and KDE).
Fantastic!
There are a couple of ground rules I would like to propose:
- Any desktop system needs to have 3 sponsors who are people willing to
do
the work of building RPMS, coordinating user bugs with upstream, and
fixing
packages. The reason for 3 is a) that this SIG isn't a dumping ground for here is ABC-DE compiled, goodbye. b) that disagreements between sponsors should be deadlock free. c) that when people take vacations, etc there is continuity of
operation.
How would this apply to something like EPEL, which in el6 has XFCE packaged. Would it be acceptable to pull that in, or would that simply count as 1 of the 3?
That was something that I figured would also need to be planned for. Where do these packages live? Who is caring for them? My initial viewpoint is that it would be nice if the people on a desktop were co-maintainers on the package set if it were in EPEL. The main thing is to try and make sure that stuff gets accidentally abandoned.
- Desktops do not keep to Enterprise lifetimes, but major version
changes
to the desktop need to be announced, tested and released to a schedule. Desktops which don't want to do that will not be part of the SIG. [A schedule does not need to be super detailed, but just alleviate
surprise.]
- Desktops can and will be removed from the SIG if there isn't an
interest
in keeping them up. This is mainly to cover that if ABC-DE desktop no longer has sponsors, other members of the SIG aren't obliged to support ABC-DE if they don't want to.
I would propose that anything being removed be treated as a major version change, with an announcement and warning for users.
Yes I agree on that. It is a major change and would need an announcement and warning to users.
- Some level of governance needs to be established so that there is a
committee that can make sure that a desktop has 'sponsors', that it is
not
just code thrown over a wall and left, and that users are not left surprised when updates to the desktop occur. They may also make up packaging rules and guidelines as needed to alleviate problems that come
up.
As this is an RFC, these are just proposed rules to be solidified when
the
CentOS board considers the SIG.
-- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 15 martie 2014 00:44:29 EET, Stephen John Smoogen smooge@gmail.com wrote:
How would this apply to something like EPEL, which in el6 has XFCE packaged. Would it be acceptable to pull that in, or would that
simply
count as 1 of the 3?
That was something that I figured would also need to be planned for. Where do these packages live? Who is caring for them? My initial viewpoint is that it would be nice if the people on a desktop were co-maintainers on the package set if it were in EPEL.
Beware that - leaving sponsorship aside - becoming an EPEL maintainer implies accepting the Fedora EULA. I know of people who refused to /could not become Fedora contributors because they could/would not accept that license.
The main thing is to try and make sure that stuff gets accidentally abandoned
"gets" or "does not get" ? :)
- Some level of governance needs to be established so that there
is a
committee that can make sure that a desktop has 'sponsors', that it
is
not
just code thrown over a wall and left, and that users are not left surprised when updates to the desktop occur. They may also make up packaging rules and guidelines as needed to alleviate problems that
come
up.
I'd say it makes sense to follow the Fedora packaging rules, updated for use in our SIGs env. For instance one Fedora rule which needs to be excluded is the recently adopted one which drops packaging of SystemV initscripts.
On 14 March 2014 17:32, Manuel Wolfshant wolfy@nobugconsulting.ro wrote:
On 15 martie 2014 00:44:29 EET, Stephen John Smoogen smooge@gmail.com wrote:
How would this apply to something like EPEL, which in el6 has XFCE packaged. Would it be acceptable to pull that in, or would that
simply
count as 1 of the 3?
That was something that I figured would also need to be planned for. Where do these packages live? Who is caring for them? My initial viewpoint is that it would be nice if the people on a desktop were co-maintainers on the package set if it were in EPEL.
Beware that - leaving sponsorship aside - becoming an EPEL maintainer implies accepting the Fedora EULA. I know of people who refused to /could not become Fedora contributors because they could/would not accept that license.
I don't know of a Fedora EULA (which would be an End User License Agreement). There is a Fedora Contributor Agreement which replaced a different one (Fedora ICLA) which did have the stigma you listed above .
https://fedoraproject.org/wiki/Legal:Fedora_Project_Contributor_Agreement
Most of these rules seem to be common sense ones..
On 15 martie 2014 01:44:53 EET, Stephen John Smoogen smooge@gmail.com wrote:
On 14 March 2014 17:32, Manuel Wolfshant wolfy@nobugconsulting.ro wrote:
On 15 martie 2014 00:44:29 EET, Stephen John Smoogen
wrote:
How would this apply to something like EPEL, which in el6 has XFCE packaged. Would it be acceptable to pull that in, or would that
simply
count as 1 of the 3?
That was something that I figured would also need to be planned for. Where do these packages live? Who is caring for them? My initial viewpoint
is
that it would be nice if the people on a desktop were co-maintainers
on
the package set if it were in EPEL.
Beware that - leaving sponsorship aside - becoming an EPEL maintainer implies accepting the Fedora EULA. I know of people who refused to
/could
not become Fedora contributors because they could/would not accept
that
license.
I don't know of a Fedora EULA (which would be an End User License Agreement). There is a Fedora Contributor Agreement
Right, my bad. That's what I meant.
which replaced a different one (Fedora ICLA) which did have the stigma you listed above .
https://fedoraproject.org/wiki/Legal:Fedora_Project_Contributor_Agreement
Most of these rules seem to be common sense ones..
I agree with you, but common sense has different meanings for different people, though.
On 03/14/2014 05:44 PM, Stephen John Smoogen wrote:
On 14 March 2014 14:49, Jim Perrin jperrin@centos.org wrote:
On 03/14/2014 12:26 PM, Stephen John Smoogen wrote:
I would like to put together an alternative desktop sig which will build, qa, and support desktops which are not the Enterprise Linux primary or secondary desktops (GNOME and KDE).
Fantastic!
There are a couple of ground rules I would like to propose:
- Any desktop system needs to have 3 sponsors who are people willing to
do
the work of building RPMS, coordinating user bugs with upstream, and
fixing
packages. The reason for 3 is a) that this SIG isn't a dumping ground for here is ABC-DE compiled, goodbye. b) that disagreements between sponsors should be deadlock free. c) that when people take vacations, etc there is continuity of
operation.
How would this apply to something like EPEL, which in el6 has XFCE packaged. Would it be acceptable to pull that in, or would that simply count as 1 of the 3?
That was something that I figured would also need to be planned for. Where do these packages live? Who is caring for them? My initial viewpoint is that it would be nice if the people on a desktop were co-maintainers on the package set if it were in EPEL.
I proposed exactly this with the fedora maintainer of MATE. He's agreed and tagged it appropriately. It's working its way through the EPEL build system now.
The main thing is to try and make sure that
stuff gets accidentally abandoned.
It should only ever be INTENTIONALLY abandoned as the SIG deems appropriate ;-)
- Desktops do not keep to Enterprise lifetimes, but major version
changes
to the desktop need to be announced, tested and released to a schedule. Desktops which don't want to do that will not be part of the SIG. [A schedule does not need to be super detailed, but just alleviate
surprise.]
- Desktops can and will be removed from the SIG if there isn't an
interest
in keeping them up. This is mainly to cover that if ABC-DE desktop no longer has sponsors, other members of the SIG aren't obliged to support ABC-DE if they don't want to.
I would propose that anything being removed be treated as a major version change, with an announcement and warning for users.
Yes I agree on that. It is a major change and would need an announcement and warning to users.
- Some level of governance needs to be established so that there is a
committee that can make sure that a desktop has 'sponsors', that it is
not
just code thrown over a wall and left, and that users are not left surprised when updates to the desktop occur. They may also make up packaging rules and guidelines as needed to alleviate problems that come
up.
As this is an RFC, these are just proposed rules to be solidified when
the
CentOS board considers the SIG.
So lets do a bit of the groundwork so that we can take this SIG to the board for vote/approval. Who else has the time and desire to contribute to this SIG?
On 19 March 2014 17:09, Jim Perrin jperrin@centos.org wrote:
On 03/14/2014 05:44 PM, Stephen John Smoogen wrote:
On 14 March 2014 14:49, Jim Perrin jperrin@centos.org wrote:
<much trim>
That was something that I figured would also need to be planned for.
Where
do these packages live? Who is caring for them? My initial viewpoint is that it would be nice if the people on a desktop were co-maintainers on
the
package set if it were in EPEL.
I proposed exactly this with the fedora maintainer of MATE. He's agreed and tagged it appropriately. It's working its way through the EPEL build system now.
<so snipped>
So lets do a bit of the groundwork so that we can take this SIG to the board for vote/approval. Who else has the time and desire to contribute to this SIG?
I do. What else needs to be done to make a formal SIG?
On 03/19/2014 07:18 PM, Stephen John Smoogen wrote:
On 19 March 2014 17:09, Jim Perrin jperrin@centos.org wrote:
On 03/14/2014 05:44 PM, Stephen John Smoogen wrote:
On 14 March 2014 14:49, Jim Perrin jperrin@centos.org wrote:
<much trim>
That was something that I figured would also need to be planned for.
Where
do these packages live? Who is caring for them? My initial viewpoint is that it would be nice if the people on a desktop were co-maintainers on
the
package set if it were in EPEL.
I proposed exactly this with the fedora maintainer of MATE. He's agreed and tagged it appropriately. It's working its way through the EPEL build system now.
<so snipped>
So lets do a bit of the groundwork so that we can take this SIG to the board for vote/approval. Who else has the time and desire to contribute to this SIG?
I do. What else needs to be done to make a formal SIG?
At this point, people who will take ownership of it. 2-3 people with the time it takes to pull this off. Board members can act as mentors to provide guidance or help, but not 'own' it.
Given there were several folks responding to this thread, I don't think that would be an issue.
On 19.03.2014 23:09, Jim Perrin wrote:
That was something that I figured would also need to be planned for. Where do these packages live? Who is caring for them? My initial viewpoint is that it would be nice if the people on a desktop were co-maintainers on the package set if it were in EPEL.
I proposed exactly this with the fedora maintainer of MATE. He's agreed and tagged it appropriately. It's working its way through the EPEL build system now.
Wow, this is excellent news! Thanks for the effort! Looking forward to usable MATE builds for EL7.
Lucian
On Wed, Mar 19, 2014 at 06:09:51PM -0500, Jim Perrin wrote:
On 03/14/2014 05:44 PM, Stephen John Smoogen wrote:
On 14 March 2014 14:49, Jim Perrin jperrin@centos.org wrote:
On 03/14/2014 12:26 PM, Stephen John Smoogen wrote:
I would like to put together an alternative desktop sig which will build, qa, and support desktops which are not the Enterprise Linux primary or secondary desktops (GNOME and KDE).
Fantastic!
There are a couple of ground rules I would like to propose:
- Any desktop system needs to have 3 sponsors who are people willing to
do
the work of building RPMS, coordinating user bugs with upstream, and
fixing
packages. The reason for 3 is a) that this SIG isn't a dumping ground for here is ABC-DE compiled, goodbye. b) that disagreements between sponsors should be deadlock free. c) that when people take vacations, etc there is continuity of
operation.
How would this apply to something like EPEL, which in el6 has XFCE packaged. Would it be acceptable to pull that in, or would that simply count as 1 of the 3?
That was something that I figured would also need to be planned for. Where do these packages live? Who is caring for them? My initial viewpoint is that it would be nice if the people on a desktop were co-maintainers on the package set if it were in EPEL.
I proposed exactly this with the fedora maintainer of MATE. He's agreed and tagged it appropriately. It's working its way through the EPEL build system now.
The main thing is to try and make sure that
stuff gets accidentally abandoned.
It should only ever be INTENTIONALLY abandoned as the SIG deems appropriate ;-)
- Desktops do not keep to Enterprise lifetimes, but major version
changes
to the desktop need to be announced, tested and released to a schedule. Desktops which don't want to do that will not be part of the SIG. [A schedule does not need to be super detailed, but just alleviate
surprise.]
- Desktops can and will be removed from the SIG if there isn't an
interest
in keeping them up. This is mainly to cover that if ABC-DE desktop no longer has sponsors, other members of the SIG aren't obliged to support ABC-DE if they don't want to.
I would propose that anything being removed be treated as a major version change, with an announcement and warning for users.
Yes I agree on that. It is a major change and would need an announcement and warning to users.
- Some level of governance needs to be established so that there is a
committee that can make sure that a desktop has 'sponsors', that it is
not
just code thrown over a wall and left, and that users are not left surprised when updates to the desktop occur. They may also make up packaging rules and guidelines as needed to alleviate problems that come
up.
As this is an RFC, these are just proposed rules to be solidified when
the
CentOS board considers the SIG.
So lets do a bit of the groundwork so that we can take this SIG to the board for vote/approval. Who else has the time and desire to contribute to this SIG?
I've previously expressed interest.
I haven't the foggiest idea what kind or amount of work is required, but if it's something I can do I will join up.
On 03/19/2014 09:22 PM, Fred Smith wrote:
I haven't the foggiest idea what kind or amount of work is required, but if it's something I can do I will join up.
Are you familiar with rpm packaging, spec file creation and/or editing?
On Thu, Mar 20, 2014 at 12:39:31PM -0500, Jim Perrin wrote:
On 03/19/2014 09:22 PM, Fred Smith wrote:
I haven't the foggiest idea what kind or amount of work is required, but if it's something I can do I will join up.
Are you familiar with rpm packaging, spec file creation and/or editing?
unfortunately, not. Could learn it if need be.
On Wed, 19 Mar 2014 18:09:51 -0500, Jim Perrin wrote:
So lets do a bit of the groundwork so that we can take this SIG to the board for vote/approval. Who else has the time and desire to contribute to this SIG?
I am in too! No idea how much work this needs, but I will help as much as I can.
Just to bump this along a bit. (yes, I'm top-posting)
I'd like to flesh out http://wiki.centos.org/SpecialInterestGroup/AlternativeDesktop a bit more. I'd still like to see one or two more folks with some decent rpm/yum building experience volunteer, and some idea of deliverables.
examples/thoughts - enabling epel/elrepo by default. - import epel's cinnamon / mate packages for install media - distributable install media. - xxx - yyy
I'd like to get this hammered out in time to discuss in this week's board meeting.
On 03/14/2014 12:26 PM, Stephen John Smoogen wrote:
I would like to put together an alternative desktop sig which will build, qa, and support desktops which are not the Enterprise Linux primary or secondary desktops (GNOME and KDE).
There are a couple of ground rules I would like to propose:
- Any desktop system needs to have 3 sponsors who are people willing to do
the work of building RPMS, coordinating user bugs with upstream, and fixing packages. The reason for 3 is a) that this SIG isn't a dumping ground for here is ABC-DE compiled, goodbye. b) that disagreements between sponsors should be deadlock free. c) that when people take vacations, etc there is continuity of operation. 2) Desktops do not keep to Enterprise lifetimes, but major version changes to the desktop need to be announced, tested and released to a schedule. Desktops which don't want to do that will not be part of the SIG. [A schedule does not need to be super detailed, but just alleviate surprise.] 3) Desktops can and will be removed from the SIG if there isn't an interest in keeping them up. This is mainly to cover that if ABC-DE desktop no longer has sponsors, other members of the SIG aren't obliged to support ABC-DE if they don't want to. 4) Some level of governance needs to be established so that there is a committee that can make sure that a desktop has 'sponsors', that it is not just code thrown over a wall and left, and that users are not left surprised when updates to the desktop occur. They may also make up packaging rules and guidelines as needed to alleviate problems that come up.
As this is an RFC, these are just proposed rules to be solidified when the CentOS board considers the SIG.
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On Mon, Mar 31, 2014 at 11:59:37AM -0500, Jim Perrin wrote:
Just to bump this along a bit. (yes, I'm top-posting)
I'd like to flesh out http://wiki.centos.org/SpecialInterestGroup/AlternativeDesktop a bit more. I'd still like to see one or two more folks with some decent rpm/yum building experience volunteer, and some idea of deliverables.
examples/thoughts
- enabling epel/elrepo by default.
- import epel's cinnamon / mate packages for install media
- distributable install media.
- xxx
- yyy
I'd like to get this hammered out in time to discuss in this week's board meeting.
Is there anything happening for this SIG?
On 05/23/2014 12:26 PM, Fred Smith wrote:
On Mon, Mar 31, 2014 at 11:59:37AM -0500, Jim Perrin wrote:
Just to bump this along a bit. (yes, I'm top-posting)
I'd like to flesh out http://wiki.centos.org/SpecialInterestGroup/AlternativeDesktop a bit more. I'd still like to see one or two more folks with some decent rpm/yum building experience volunteer, and some idea of deliverables.
examples/thoughts
- enabling epel/elrepo by default.
- import epel's cinnamon / mate packages for install media
- distributable install media.
- xxx
- yyy
I'd like to get this hammered out in time to discuss in this week's board meeting.
Is there anything happening for this SIG?
Right now we've been reasonably 'heads-down' on building the seven rc and getting prepared for when 7 lands, but I haven't heard anything more from the folks who proposed the sig. We have been in contact with the EPEL folks to stuff in there. Currently epel has both mate and cinnamon, and may pick up more once 7 goes gold.
On 24 May 2014 07:44, Jim Perrin jperrin@centos.org wrote:
Right now we've been reasonably 'heads-down' on building the seven rc and getting prepared for when 7 lands, but I haven't heard anything more from the folks who proposed the sig. We have been in contact with the EPEL folks to stuff in there. Currently epel has both mate and cinnamon, and may pick up more once 7 goes gold.
My apologies. I have been head down in my own work and let this get away. What do people want to hear on this and want to see? My starting issue was to get a conversation started and see who was interested in what desktops and such without it being a one guy SIG.
On Wed, May 28, 2014 at 04:29:11PM -0600, Stephen John Smoogen wrote:
On 24 May 2014 07:44, Jim Perrin <[1]jperrin@centos.org> wrote:
Right now we've been reasonably 'heads-down' on building the seven rc and getting prepared for when 7 lands, but I haven't heard anything more from the folks who proposed the sig. We have been in contact with the EPEL folks to stuff in there. Currently epel has both mate and cinnamon, and may pick up more once 7 goes gold.My apologies. I have been head down in my own work and let this get away. What do people want to hear on this and want to see? My starting issue was to get a conversation started and see who was interested in what desktops and such without it being a one guy SIG. Â -- Stephen J Smoogen.
I'm interested in having a Mate desktop (in the absence of Gnome 2). I figured if I volunteered to help in some way it would be more likely than if I just whined. :)
So, I've been writing C for many years, usually in a Unix/Linux environment, but I've never done any GUI programming, and not much low-level stuff. I don't have any experience creating RPMs from scratch, for example. there's a long list of things I don't know. But if all else fails, I can assist with documentation, or bug triage, or such stuff.
29 maj 2014 kl. 00.29 skrev Stephen John Smoogen:
On 24 May 2014 07:44, Jim Perrin jperrin@centos.org wrote:
Right now we've been reasonably 'heads-down' on building the seven rc and getting prepared for when 7 lands, but I haven't heard anything more from the folks who proposed the sig. We have been in contact with the EPEL folks to stuff in there. Currently epel has both mate and cinnamon, and may pick up more once 7 goes gold.
My apologies. I have been head down in my own work and let this get away. What do people want to hear on this and want to see? My starting issue was to get a conversation started and see who was interested in what desktops and such without it being a one guy SIG.
Hi, I am interested in getting the Xfce desktop "supported" for CentOS.
Including working with upstream (Xfce and Fedora/EPEL), filing bugs and improving the packaging - seems like they were mostly dumped... The 4.6 Xfce in EPEL 5 was less polished than 4.4 in CentOS 5 Extras. For instance, the whole group (Xfce) is missing from the EPEL comps ?
I can do rpm packaging, spec file creation/editing and mock building. I don't use any of the other minority or retro desktop environments, like LXDE or MATE/Trinity, so "just" the GTK+-based desktop of Xfce. Think it's around 50-100 packages (mandatory-optional) for CentOS 5-7.
With EPEL 7 still in beta, and no (or not many) Xfce packages being built so far - I decided to see how far off it was, by using Fedora. Not very, it turned out... It already runs (!), with some minor things like ConsoleKit/systemd and udisks/udisks2, with the .fc18 packages.
The first step would be to rebuild "@xfce-desktop" properly for .el7, next step is apps (midori/claws-mail/etc) and office (abiword/gnumeric). Or possibly just ignore those for now and use Mozilla and LibreOffice ? I also had some ideas about the default theme for icons and background.
Details at: http://afb.users.sourceforge.net/xfce/xfce-desktop.html
--anders
On 9 July 2014 13:00, Anders F Björklund afb@users.sourceforge.net wrote:
29 maj 2014 kl. 00.29 skrev Stephen John Smoogen:
On 24 May 2014 07:44, Jim Perrin jperrin@centos.org wrote:
Right now we've been reasonably 'heads-down' on building the seven rc and getting prepared for when 7 lands, but I haven't heard anything more from the folks who proposed the sig. We have been in contact with the EPEL folks to stuff in there. Currently epel has both mate and cinnamon, and may pick up more once 7 goes gold.
My apologies. I have been head down in my own work and let this get away. What do people want to hear on this and want to see? My starting issue was to get a conversation started and see who was interested in what desktops and such without it being a one guy SIG.
Hi, I am interested in getting the Xfce desktop "supported" for CentOS.
Including working with upstream (Xfce and Fedora/EPEL), filing bugs and improving the packaging - seems like they were mostly dumped... The 4.6 Xfce in EPEL 5 was less polished than 4.4 in CentOS 5 Extras. For instance, the whole group (Xfce) is missing from the EPEL comps ?
I can do rpm packaging, spec file creation/editing and mock building. I don't use any of the other minority or retro desktop environments, like LXDE or MATE/Trinity, so "just" the GTK+-based desktop of Xfce. Think it's around 50-100 packages (mandatory-optional) for CentOS 5-7.
With EPEL 7 still in beta, and no (or not many) Xfce packages being built so far - I decided to see how far off it was, by using Fedora. Not very, it turned out... It already runs (!), with some minor things like ConsoleKit/systemd and udisks/udisks2, with the .fc18 packages.
The first step would be to rebuild "@xfce-desktop" properly for .el7, next step is apps (midori/claws-mail/etc) and office (abiword/gnumeric). Or possibly just ignore those for now and use Mozilla and LibreOffice ? I also had some ideas about the default theme for icons and background.
Details at: http://afb.users.sourceforge.net/xfce/xfce-desktop.html
Cool and thank you. I had this listed as my weekend project this week because someone wanted a working XFCE spin. If there is anyway I can help on this let me know.
Stephen J Smoogen.
Stephen John Smoogen wrote:
With EPEL 7 still in beta, and no (or not many) Xfce packages being built so far - I decided to see how far off it was, by using Fedora. Not very, it turned out... It already runs (!), with some minor things like ConsoleKit/systemd and udisks/udisks2, with the .fc18 packages.
The first step would be to rebuild "@xfce-desktop" properly for .el7, next step is apps (midori/claws-mail/etc) and office (abiword/gnumeric). Or possibly just ignore those for now and use Mozilla and LibreOffice ? I also had some ideas about the default theme for icons and background.
Details at: http://afb.users.sourceforge.net/xfce/xfce-desktop.html
Cool and thank you. I had this listed as my weekend project this week because someone wanted a working XFCE spin. If there is anyway I can help on this let me know.
Basically "we" need to rebuild all the packages in the "xfce-desktop" comps, including their build requirements. Some are in CentOS, some from Fedora. I don't know of the maintainer status or the build status in EPEL, but someone made a "epel7" branch (no idea why it wasn't called "el7", like "el5" and "el6")
Think I "only" have 60 .fc18 packages now, including Leafpad and Ristretto.
And add some packages for "gnome-colors-icon-theme" and make a new "arc-colors-background-theme". I included a dark theme too, for reference. The original GNOME theme works for the login screen / display manager, but I don't think it works for the background (it's "too bright", or "too dark") ?
Packaging Thunderbird needs to be done, but that's hardly for Xfce only...
--anders
On Wed, 9 Jul 2014 21:00:45 +0200 Anders F Björklund afb@users.sourceforge.net wrote:
Hi, I am interested in getting the Xfce desktop "supported" for CentOS.
Great.
Including working with upstream (Xfce and Fedora/EPEL), filing bugs and improving the packaging - seems like they were mostly dumped...
dumped? I've not really seen many if any bugs on epel5 xfce packages...
The 4.6 Xfce in EPEL 5 was less polished than 4.4 in CentOS 5 Extras. For instance, the whole group (Xfce) is missing from the EPEL comps ?
Odd. I thought i had updated that.
I can do rpm packaging, spec file creation/editing and mock building. I don't use any of the other minority or retro desktop environments, like LXDE or MATE/Trinity, so "just" the GTK+-based desktop of Xfce. Think it's around 50-100 packages (mandatory-optional) for CentOS 5-7.
With EPEL 7 still in beta, and no (or not many) Xfce packages being built so far - I decided to see how far off it was, by using Fedora. Not very, it turned out... It already runs (!), with some minor things like ConsoleKit/systemd and udisks/udisks2, with the .fc18 packages.
nonamedotc@fedoraproject.org has been heading this effort on the epel7 side. He's been building things in copr first and testing them before building in epel. We have the base/core packages aready branched.
The first step would be to rebuild "@xfce-desktop" properly for .el7,
Please coordinate with nonamedotc? Or do you intend to just copy this into a seperate repo?
next step is apps (midori/claws-mail/etc) and office (abiword/gnumeric). Or possibly just ignore those for now and use Mozilla and LibreOffice ? I also had some ideas about the default theme for icons and background.
Details at: http://afb.users.sourceforge.net/xfce/xfce-desktop.html
great. ;)
More help the better...
kevin
Kevin Fenzi wrote:
Including working with upstream (Xfce and Fedora/EPEL), filing bugs and improving the packaging - seems like they were mostly dumped...
dumped? I've not really seen many if any bugs on epel5 xfce packages...
Well, last time I looked it was still trying to use the "Fedora" icons from the epel6 package so it seemed like it was built and left there ?
The 4.6 Xfce in EPEL 5 was less polished than 4.4 in CentOS 5 Extras. For instance, the whole group (Xfce) is missing from the EPEL comps ?
Odd. I thought i had updated that.
Maybe I'm doing it wrong... I thought it was a "feature", like the "@buildsys-build" group being missing (replaced that with packages).
With EPEL 7 still in beta, and no (or not many) Xfce packages being built so far - I decided to see how far off it was, by using Fedora. Not very, it turned out... It already runs (!), with some minor things like ConsoleKit/systemd and udisks/udisks2, with the .fc18 packages.
nonamedotc@fedoraproject.org has been heading this effort on the epel7 side. He's been building things in copr first and testing them before building in epel. We have the base/core packages aready branched.
Nice! Will make contact with him/her then, and file some new Xfce bugs. There's some really obscure ones, like the "tab" key not working (!).
The first step would be to rebuild "@xfce-desktop" properly for .el7,
Please coordinate with nonamedotc? Or do you intend to just copy this into a seperate repo?
I don't think there's any need at this point, it should work right off EPEL. Basically the user can do: yum --enablerepo=epel groupinstall xfce-desktop
Not sure what the deal is here if you *only* want to include the Desktops SIG, but not the rest of EPEL ? Sounds like it would involve rebuilding/resigning.
And I have no idea why it is called "epel7" and not "el7" now, if that signals some further isolation ? I will be running EL, with EPEL disabled by default.
--anders
On Wed, 9 Jul 2014 21:46:28 +0200 Anders F Björklund afb@users.sourceforge.net wrote:
Kevin Fenzi wrote:
Including working with upstream (Xfce and Fedora/EPEL), filing bugs and improving the packaging - seems like they were mostly dumped...
dumped? I've not really seen many if any bugs on epel5 xfce packages...
Well, last time I looked it was still trying to use the "Fedora" icons from the epel6 package so it seemed like it was built and left there ?
I maintain/use Xfce in Fedora. Another interested party worked on Xfce for epel5/6. I'd be happy to look at specific bugs, but I don't use it day to day there, so I wouldn't have noticed this.
The 4.6 Xfce in EPEL 5 was less polished than 4.4 in CentOS 5 Extras. For instance, the whole group (Xfce) is missing from the EPEL comps ?
Odd. I thought i had updated that.
Maybe I'm doing it wrong... I thought it was a "feature", like the "@buildsys-build" group being missing (replaced that with packages).
Nope. it should be there... I can add it, although not sure how many people care about epel5 at this point. ;) epel6 does have the groups...
With EPEL 7 still in beta, and no (or not many) Xfce packages being built so far - I decided to see how far off it was, by using Fedora. Not very, it turned out... It already runs (!), with some minor things like ConsoleKit/systemd and udisks/udisks2, with the .fc18 packages.
nonamedotc@fedoraproject.org has been heading this effort on the epel7 side. He's been building things in copr first and testing them before building in epel. We have the base/core packages aready branched.
Nice! Will make contact with him/her then, and file some new Xfce bugs. There's some really obscure ones, like the "tab" key not working (!).
Fun. ;) Thanks!
The first step would be to rebuild "@xfce-desktop" properly for .el7,
Please coordinate with nonamedotc? Or do you intend to just copy this into a seperate repo?
I don't think there's any need at this point, it should work right off EPEL. Basically the user can do: yum --enablerepo=epel groupinstall xfce-desktop
Great. Thats my idea as well.
Not sure what the deal is here if you *only* want to include the Desktops SIG, but not the rest of EPEL ? Sounds like it would involve rebuilding/resigning.
And I have no idea why it is called "epel7" and not "el7" now, if that signals some further isolation ? I will be running EL, with EPEL disabled by default.
It's to avoid confusion. Some people in the past saw that epel5/6 had 'el5' and 'el6' branches and started saying things like "thats in rhel5, see the el5 branch!". We made the epel7 branch 'epel7' to make it clear that the packages we not RHEL, but epel.
kevin
Kevin Fenzi wrote:
dumped? I've not really seen many if any bugs on epel5 xfce packages...
Well, last time I looked it was still trying to use the "Fedora" icons from the epel6 package so it seemed like it was built and left there ?
I maintain/use Xfce in Fedora. Another interested party worked on Xfce for epel5/6. I'd be happy to look at specific bugs, but I don't use it day to day there, so I wouldn't have noticed this.
This would be an articulated goal of the new Special Interest Group, to make sure that such bugs and wishlists are forwarded upstream...
The 4.6 Xfce in EPEL 5 was less polished than 4.4 in CentOS 5 Extras. For instance, the whole group (Xfce) is missing from the EPEL comps ?
Odd. I thought i had updated that.
Maybe I'm doing it wrong... I thought it was a "feature", like the "@buildsys-build" group being missing (replaced that with packages).
Nope. it should be there... I can add it, although not sure how many people care about epel5 at this point. ;) epel6 does have the groups...
I think we are currently seeing a 50-50 split, where EL6 just passed. So I think that EL5 will probably be here 3 more years. "Red Hat XP" :-)
With EPEL 7 still in beta, and no (or not many) Xfce packages being built so far - I decided to see how far off it was, by using Fedora. Not very, it turned out... It already runs (!), with some minor things like ConsoleKit/systemd and udisks/udisks2, with the .fc18 packages.
nonamedotc@fedoraproject.org has been heading this effort on the epel7 side. He's been building things in copr first and testing them before building in epel. We have the base/core packages aready branched.
Nice! Will make contact with him/her then, and file some new Xfce bugs. There's some really obscure ones, like the "tab" key not working (!).
Fun. ;) Thanks!
Contact established, will test the new packages once they arrive. I added the packagelists from fc18, as "centos-el7-xfce-fc18.txt"
The first step would be to rebuild "@xfce-desktop" properly for .el7,
Please coordinate with nonamedotc? Or do you intend to just copy this into a seperate repo?
I don't think there's any need at this point, it should work right off EPEL. Basically the user can do: yum --enablerepo=epel groupinstall xfce-desktop
Great. Thats my idea as well.
Possibly we will do the whole "xfce-desktop-environment" group later. Not sure if the "xfce-media" is applicable at all, but we will see...
Not sure what the deal is here if you *only* want to include the Desktops SIG, but not the rest of EPEL ? Sounds like it would involve rebuilding/resigning.
And I have no idea why it is called "epel7" and not "el7" now, if that signals some further isolation ? I will be running EL, with EPEL disabled by default.
It's to avoid confusion. Some people in the past saw that epel5/6 had 'el5' and 'el6' branches and started saying things like "thats in rhel5, see the el5 branch!". We made the epel7 branch 'epel7' to make it clear that the packages we not RHEL, but epel.
Well, there's confusion between the git branch name and the rpm dist macro ? And the tags in git.centos.org are called "c7", so there's lots of standards.
--anders
On Thu, Jul 10, 2014 at 10:54 AM, Anders F Björklund afb@users.sourceforge.net wrote:
Kevin Fenzi wrote:
dumped? I've not really seen many if any bugs on epel5 xfce packages...
Well, last time I looked it was still trying to use the "Fedora" icons from the epel6 package so it seemed like it was built and left there ?
I maintain/use Xfce in Fedora. Another interested party worked on Xfce for epel5/6. I'd be happy to look at specific bugs, but I don't use it day to day there, so I wouldn't have noticed this.
This would be an articulated goal of the new Special Interest Group, to make sure that such bugs and wishlists are forwarded upstream...
I actually use vtwm quite effectively, and will test it on CentOS 7 when I have a chance. Much, much lighter weight than most modern managers, and thus much more robust on thin clients and overwhelmed VM's. Will I need to try to get that into Fedora first, or is there a reasonable way to get it into the 'extras' for CentOS?
The RPM building tools are at https://github.com/nkadel/vtwm-5.5.x-srpm
Nico Kadel-Garcia
Nico Kadel-Garcia wrote:
On Thu, Jul 10, 2014 at 10:54 AM, Anders F Björklund afb@users.sourceforge.net wrote:
Kevin Fenzi wrote:
dumped? I've not really seen many if any bugs on epel5 xfce packages...
Well, last time I looked it was still trying to use the "Fedora" icons from the epel6 package so it seemed like it was built and left there ?
I maintain/use Xfce in Fedora. Another interested party worked on Xfce for epel5/6. I'd be happy to look at specific bugs, but I don't use it day to day there, so I wouldn't have noticed this.
This would be an articulated goal of the new Special Interest Group, to make sure that such bugs and wishlists are forwarded upstream...
I actually use vtwm quite effectively, and will test it on CentOS 7 when I have a chance. Much, much lighter weight than most modern managers, and thus much more robust on thin clients and overwhelmed VM's. Will I need to try to get that into Fedora first, or is there a reasonable way to get it into the 'extras' for CentOS?
The overlap between Extras and EPEL needs to be sorted out, as well as the difference between a "desktop environment" and a "window manager"*...
I don't think you need a group for just installing vtwm/i3wm/etc, but maybe it could be part of a documentation effort or a wiki web page ?
* EL7 SAG http://tinyurl.com/oouywut
For myself, in addition to the ones from Xfce comps (e.g. @xfce-desktop), NX3 (nx/freenx/opennx/x2go) is also a required component of the desktop...
The desktops should provide both local workstation and server installations. Xfce also included yumex, as "alternative" (non-GNOME/KDE) software manager.
http://wiki.centos.org/HowTos/FreeNX https://fedoraproject.org/wiki/Changes/X2Go
I think it would be nice to define the scope of the Desktop SIG further: http://wiki.centos.org/SpecialInterestGroup/AlternativeDesktop
The short list seems to be: Xfce, LXDE(?), MATE, Trinity(?) Maybe something lighter still is required, as well.
--anders
-
Alexander Bisogiannis -
Anders F Björklund -
Fred Smith -
Jim Perrin -
Kevin Fenzi -
Manuel Wolfshant -
Nico Kadel-Garcia -
Nux! -
Stephen John Smoogen