Re: [Spacewalk-devel] Twitter Bootstrap: Standardizing the CSS framework?
On 01/08/13 10:05, Jan Pazdziora wrote: > On Fri, Jul 26, 2013 at 03:06:47PM +0200, Duncan Mac-Vicar P. wrote: >> >> Yes, we do all development on SUSE Manager and then rebase against >> master what we want to upstream. It makes total sense. > > It may make sense from SUSE's point of view. Not sure it makes sense > from upstream project health point of view. It would not be very different. We could do a long feature against master, not having it accepted, and then still having to backport it. > >> - Spacewalk code is very "distro" oriented. > > In what way? In the way that the team tries hard to release binary > signed rpms with each release to allow the administrators just upgrade > the software without having to compile it? No, that is fine. Just that it is assumed (and in its own right) that the administrator runs Fedora, and therefore .specs, some Makefiles and even some code is distro specific. >> Spacewalk is very tied to Fedora in this regard. > > Not really -- all recent Spacewalk releases were done both on Fedoras > *and* on RHEL 5 and 6. Ok, I did not consider those different. > Why didn't you send those %ifdefs for review? If this is the only > thing which blocks you do do Spacewalk vanilla releases on SUSE, I'm > sure the Spacewalk team will be happy to consider those patches for > master. Agreed. I started a new thread about this. >> - If you do a feature in Spacewalk master, you just do it and commit it. >> We have to ask for review and then the feature may not be accepted. >> Therefore the inverse work-flow, cherry-picking in our tree what looks >> good to upstream, makes more sense. > > There are SUSE developers who have commit access to Spacewalk git, > based on their history of providing sensible bug fixes and > contributions. Trust is built over time. If you start with small fixes > and features, if the patches are clean against master and they are > correct and not disturbing the rest of the Spacewalk, you will build > trust for future big changes that you may have planned. Fully agreed. I am not complaining about this. It makes total sense. What I want you to realize is that we don't have that level of control: eg. you can do features for several months and be sure it will land upstream). Our process right now just fits our resources and control. Making a more vanilla master build on plain SUSE may help us do at least the changes that _do_not_need_ to start the other way around upstream first. I think we will invest some time to improve this because I see some opportunities, and may be some value for openSUSE as well. >> - Stuff like porting pages, happened as the side-effect of features we >> will have anyway in our tree but we don't know yet if we will be >> accepted upstream, > > The longer you wait and the longer you hack in your tree, the bigger > the patchset will be when you decide to show ti upstream, and the > harder will be for upstream to easily accept the feature. We know this, we take this decisions in a pragmatic way. Sometimes we just decide consciously that we will take a fork-debt, and sometimes we decide to pay it back. > Check that communication again. I raised some general questions about > the overall client -- server mechanism, issues that we saw with it in > the past, and how it could be improved. I did not see answer that > would indicate willingness to work on existing issues to improve the > situation and maybe get the ssh push feature in as a well aligned > part of the future setup. It was presented as mostly additional code > which increased the complexity of the code (duplication of the > scheduling functionality), solution that you propose in one form > without being prepared to contribute to improving the overall setup. Yes, one could see this as duplicate from the "push" side, but that was not the core of it. The core was when the clients could not reach the client. You stated "the first scenario does not sound that interesting to me". This is fine. I gave an example of this scenario: Spacewalk in the internal network, clients in a public cloud. We totally agree with upstream disagreeing. The problem is that in this case we could not move forward. What is "interesting" or not as a problem is subjective, and in this case we did not have the power. Imagine somebody in the community did not find ABRT support interesting?. This situation is fine and makes sense due to the amount of contributions from the diverse stakeholders. But control is a fact, and we can't see "master" in the same way you do. >> We should really figure out a "run from source" here :-) > > In the Spacewalk team, some developers run Spacewalk in their > developer's setup which I assume is equivalent to the "run from > source" wish. It's not my preferred approach as it in the past > lead to different setup being used than what we then released to > users, leading to missed bugs. However, I can well understand the > desire to do so for some reason, so if
[Spacewalk-devel] upstreaming some of our .spec file changes
On 01/08/13 10:05, Jan Pazdziora wrote:
>> Running vanilla Spacewalk on SUSE would be a big effort and %ifdefs in
>> the spec files (like they are in our tree. /srv/www vs /var/www anyone)
>
> Why didn't you send those %ifdefs for review? If this is the only
> thing which blocks you do do Spacewalk vanilla releases on SUSE, I'm
> sure the Spacewalk team will be happy to consider those patches for
> master.
This is something we probably should do. I think the 80% of the patch
are SUSE/RH differences, and the minor part SUSE Manager/Spacewalk
specific. We should upstream at least the first part.
We would need to "split" the changes in those two. I can give you an
overview of the changes and we can discuss now if you would be willing
to have those upstream. I copy pasted some snippets, of course similar
changes are across all specs.
I am posting these examples so that we can discuss how to handle them
overall.
1) apache/FHS/paths/etc changes, redhat -> SUSE specifics:
1.1) Packaging differences
1.1.1) newer versions of fedora do not use defattr
+%defattr(-,root,root)
How do you handle those in RHEL?
1.1.2) Release in versions. SUSE releases are generated from the build,
so we don't use releases in dependencies, except for example a
subpackage requiring a parent package:
-Provides: %{name}-sql-virtual = %{version}-%{release}
+Provides: %{name}-sql-virtual = %{version}
1.1.3) epochs
-BuildRequires: antlr >= 0:2.7.6
+BuildRequires: antlr >= 2.7.6
(ton like these)
1.1.4) macros
This one is funny because %_localstatedir resolves to /var on Fedora :-)
+%if 0%{?suse_version}
+install -d -m 755
$RPM_BUILD_ROOT/%{_localstatedir}/lib/spacewalk/systemlogs
+%else
+install -d -m 755 $RPM_BUILD_ROOT/%{_var}/spacewalk/systemlogs
+%endif
1.2) Redhat does not require owning directories.
A SUSE package either has to own a directory with %dir explicitly, or
BuildRequire the owner.
+%if 0%{?suse_version}
+%dir %{rhnroot}/server
+%endif
1.3) python/apache specifics
+%if 0%{?suse_version}
+%global apacheconfd %{_sysconfdir}/apache2/conf.d
+%global apache_user wwwrun
+%global apache_group www
+%else
%global apacheconfd %{_sysconfdir}/httpd/conf.d
-%if 0%{?rhel} && 0%{?rhel} < 6
-%{!?python_sitelib: %global python_sitelib %(%{__python} -c "from
distutils.sysconfig import get_python_lib; print get_python_lib()")}
+%global apache_user apache
+%global apache_group apache
+%endif
+%if 0%{?rhel} || 0%{?suse_version}
+%{!?py_ver: %define py_ver %(python -c "import sys;
v=sys.version_info[:2]; print '%%d.%%d'%%v" 2>/dev/null || echo
PYTHON-NOT-FOUND)}
+%{!?py_prefix: %define py_prefix %(python -c "import sys; print
sys.prefix" 2>/dev/null || echo PYTHON-NOT-FOUND)}
+%{!?py_libdir: %define py_libdir %{py_prefix}/%{_lib}/python%{py_ver}}
+%{!?python_sitelib: %define python_sitelib %(%{__python} -c "from
distutils.sysconfig import get_python_lib; print get_python_lib()")}
+%if 0%{?suse_version}
+BuildRequires: spacewalk-config
+Requires(pre): apache2
+PreReq: %fillup_prereq
+%else
+Requires(pre): httpd
+%endif
+%if 0%{?suse_version}
+BuildRequires: python-devel
+%if 0%{?suse_version} >= 1110
+Requires: python-base
+%else
+Requires: python
+Requires: python-hashlib
+%endif
+%else
BuildRequires: python2-devel
Conflicts: %{name} < 1.7.0
Requires: python-hashlib
BuildRequires: python-hashlib
+%endif
1.4) apache user/groups
if [ -f $OLD_SECRET_FILE ]; then
-install -d -m 750 -o root -g apache %{rhnconf}
+install -d -m 750 -o root -g %{apache_group} %{rhnconf}
mv ${OLD_SECRET_FILE}* %{rhnconf}
fi
-%attr(755,root,apache) %dir %{rhnconfigdefaults}
-%attr(644,root,apache) %{rhnconfigdefaults}/rhn.conf
+%attr(755,root,%{apache_group}) %dir %{rhnconfigdefaults}
+%attr(644,root,%{apache_group}) %{rhnconfigdefaults}/rhn.conf
Some Fedora specifics are in the Makefiles, so we fix them in the spec:
+%if !0%{?suse_version}
+sed -i 's/^INSTALL_DEST.*/INSTALL_DEST = \/etc\/httpd\/conf.d/'
apache-conf/Makefile
+%endif
1.4.1) apache paths
+%define wwwdocroot %{_var}/www/html
-install -d -m 755 %{buildroot}%{_var}/www/html
+install -d -m 755 %{buildroot}/%{wwwdocroot}
1.5) SUSE specifics
+%post tools
+%{fillup_only -nd reposync rhn}
%files
+/var/adm/fillup-templates/sysconfig.reposync
+%if 0%{?suse_version} && 0%{?suse_version} < 1210
+Requires(preun): %fillup_prereq %insserv_prereq
+%endif
+%if 0%{?suse_version}
+%py_compile %{buildroot}/%{rhnroot}
+%py_compile -O %{buildroot}/%{rhnroot}
+%endif
2) Debranding: those should be straightforward, except for renamed packages
-Summary: Core functions providing SQL connectivity for the RHN backend
modules
+Summary: Core functions providing SQL connectivity for the Spacewalk
backend modules
Renamed specs:
rhnsd -> spacewalksd
rhn-client-tools spacewalk-client-tools
Some stuff due to renamed packages:
-Requires: rhn-check
+Requires: %{rhn_check}
If we can discuss those, I can prepare a patch with most of the changes
that are mostly distro
Re: [Spacewalk-devel] Twitter Bootstrap: Standardizing the CSS framework?
On Fri, Jul 26, 2013 at 03:06:47PM +0200, Duncan Mac-Vicar P. wrote: > > Yes, we do all development on SUSE Manager and then rebase against > master what we want to upstream. It makes total sense. It may make sense from SUSE's point of view. Not sure it makes sense from upstream project health point of view. > - Spacewalk code is very "distro" oriented. In what way? In the way that the team tries hard to release binary signed rpms with each release to allow the administrators just upgrade the software without having to compile it? > It is not possible right now > to "run" it from the source tree. What are the patches to make it possible? > It needs packaging and "productizing" > in order to run it. We figured that's exactly how our users would want to use it. > Spacewalk is very tied to Fedora in this regard. Not really -- all recent Spacewalk releases were done both on Fedoras *and* on RHEL 5 and 6. > Running vanilla Spacewalk on SUSE would be a big effort and %ifdefs in > the spec files (like they are in our tree. /srv/www vs /var/www anyone) Why didn't you send those %ifdefs for review? If this is the only thing which blocks you do do Spacewalk vanilla releases on SUSE, I'm sure the Spacewalk team will be happy to consider those patches for master. > - If you do a feature in Spacewalk master, you just do it and commit it. > We have to ask for review and then the feature may not be accepted. > Therefore the inverse work-flow, cherry-picking in our tree what looks > good to upstream, makes more sense. There are SUSE developers who have commit access to Spacewalk git, based on their history of providing sensible bug fixes and contributions. Trust is built over time. If you start with small fixes and features, if the patches are clean against master and they are correct and not disturbing the rest of the Spacewalk, you will build trust for future big changes that you may have planned. > - Stuff like porting pages, happened as the side-effect of features we > will have anyway in our tree but we don't know yet if we will be > accepted upstream, The longer you wait and the longer you hack in your tree, the bigger the patchset will be when you decide to show ti upstream, and the harder will be for upstream to easily accept the feature. > so we can't start the other way around, and we can't > decide whether we do or not a feature based on whether upstream will > take it or not (like it happened with SSH push). Check that communication again. I raised some general questions about the overall client -- server mechanism, issues that we saw with it in the past, and how it could be improved. I did not see answer that would indicate willingness to work on existing issues to improve the situation and maybe get the ssh push feature in as a well aligned part of the future setup. It was presented as mostly additional code which increased the complexity of the code (duplication of the scheduling functionality), solution that you propose in one form without being prepared to contribute to improving the overall setup. > We should really figure out a "run from source" here :-) In the Spacewalk team, some developers run Spacewalk in their developer's setup which I assume is equivalent to the "run from source" wish. It's not my preferred approach as it in the past lead to different setup being used than what we then released to users, leading to missed bugs. However, I can well understand the desire to do so for some reason, so if there are any patches to make it easier, just submit them for review. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] spacecmd - new functions patch
Hi spacewalkers,
I've updated the spacecmd "misc.py" file, to add new functions like
"is_monitoringenabled" and "list_proxies".
Can you review and add this patch upstream.
Cheers,
Gregor Grüner
>From f668db7aaf3a39053513280b98ddb20809c9f667 Mon Sep 17 00:00:00 2001
From: Gregor Gruener
Date: Thu, 1 Aug 2013 09:52:40 +0200
Subject: [PATCH] add new function is_monitoringenabled and list_proxies
---
rel-eng/packages/spacecmd | 2 +-
spacecmd/spacecmd.spec| 6 +-
spacecmd/src/lib/misc.py | 21 +
3 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/rel-eng/packages/spacecmd b/rel-eng/packages/spacecmd
index f9ca916..c88f653 100644
--- a/rel-eng/packages/spacecmd
+++ b/rel-eng/packages/spacecmd
@@ -1 +1 @@
-2.1.1-1 spacecmd/
+2.1.2-1 spacecmd/
diff --git a/spacecmd/spacecmd.spec b/spacecmd/spacecmd.spec
index f167795..0b79f58 100644
--- a/spacecmd/spacecmd.spec
+++ b/spacecmd/spacecmd.spec
@@ -4,7 +4,7 @@
%endif
Name:spacecmd
-Version: 2.1.1
+Version: 2.1.2
Release: 1%{?dist}
Summary: Command-line interface to Spacewalk and Satellite servers
@@ -64,6 +64,10 @@ touch %{buildroot}/%{python_sitelib}/spacecmd/__init__.py
%doc %{_mandir}/man1/spacecmd.1.gz
%changelog
+* Thu Aug 1 2013 Gregor Gruener 2.1.2-1
+- add new function is_monitoringenabled
+- add new function list_proxies
+
* Mon Jul 22 2013 Gregor Gruener 2.1.1-1
- add new function custominfo_updatekey
diff --git a/spacecmd/src/lib/misc.py b/spacecmd/src/lib/misc.py
index 6273eb4..21d2806 100644
--- a/spacecmd/src/lib/misc.py
+++ b/spacecmd/src/lib/misc.py
@@ -137,6 +137,27 @@ def do_get_certificateexpiration(self, args):
+def help_is_monitoringenabled(self):
+print 'is_monitoringenabled: Indicates if monitoring is enabled '
+print " on the satellite "
+print 'usage: is_monitoringenabled'
+
+def do_is_monitoringenabled(self, args):
+monitoring = self.client.satellite.isMonitoringEnabled(self.session)
+print monitoring
+
+
+
+def help_list_proxies(self):
+print 'list_proxies: List the proxies wihtin the user\'s organization '
+print 'usage: list_proxies'
+
+def do_list_proxies(self, args):
+proxies = self.client.satellite.listProxies(self.session)
+print proxies
+
+
+
def help_get_session(self):
print 'get_session: Show the current session string'
print 'usage: get_session'
--
1.8.3.1
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
