Re: [Spacewalk-devel] spacecmd - Added new scap features
Hello, your patch has been committed into Spacewalk as 58dc4b990d6e94a73935c318d6fd8d39f25de1c6. Thanks for contribution! On 08/05/2013 08:12 PM, Gregor Gruener wrote: Hi Spacewalkers, I have added a few completely new openscap functions to spacecmd. The new file scap.py contains the new functions: scap_getxccdfscandetails scap_getxccdfscanruleresults scap_listxccdfscans scap_schedulexccdfscan Can you review and add this patch upstream. Cheers, Gregor Gr�ner ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel -- Tomáš Kašpárek Red Hat Satellite 5, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] upstreaming some of our .spec file changes
% 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?
The %defattr is not necessary since rpm 4.4 which is included even in RHEL 5.
So we don't need to care about it.
% 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}
So if you have
Provides: %{name}-sql-virtual = %{version}
you'll get
spacewalk-backend-sql-virtual = 2.0.3-3.1
?
And what will gou get for Provides: %{name}-sql-virtual = %{version}-%{release}?
% 1.1.3) epochs
%
% -BuildRequires: antlr = 0:2.7.6
% +BuildRequires: antlr = 2.7.6
% (ton like these)
Does it causes errors during build time or is just using epoch uncommon in SUSE
packages?
% 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
So wouldn't be easier to change it to %{_localstatedir}/lib/spacewalk/systemlogs
in upstream?
% 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
No problem adding different user/group defs into spec (until it's still working
in Fedora/RHEL).
% 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
This should be definitely done in more elegant way than modifying
makefile in build time.
% 1.4.1) apache paths
%
% +%define wwwdocroot %{_var}/www/html
%
% -install -d -m 755 %{buildroot}%{_var}/www/html
%
[Spacewalk-devel] [PATCH] fix python gettext_test
The following patch fixes the execution of the gettext_test. Cheers Flavio -- Flavio Castelli SUSE LINUX Products GmbH Maxfeldstraße 5, 90409 Nürnberg Germany From 98924fbd477e5071c5bfc3ea609df517f0099fe3 Mon Sep 17 00:00:00 2001 From: Flavio Castelli fcaste...@suse.com Date: Tue, 23 Jul 2013 16:40:48 +0200 Subject: [PATCH] Backend: fix broken gettext test The gettext test was trying to load translation files from the wrong directory. Signed-off-by: Flavio Castelli fcaste...@suse.com --- backend/common/test/unit-test/test_gettext.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/backend/common/test/unit-test/test_gettext.py b/backend/common/test/unit-test/test_gettext.py index 83b6afa..87d5bda 100644 --- a/backend/common/test/unit-test/test_gettext.py +++ b/backend/common/test/unit-test/test_gettext.py @@ -24,8 +24,8 @@ import unittest if sys.argv[0] == /: topdir = sys.argv[0] else: -topdir = %s/%s % (os.getcwd(), sys.argv[0]) -topdir = os.path.abspath(os.path.dirname(topdir + /../../../../..)) +topdir = os.path.dirname(os.path.abspath(__file__)) +topdir = os.path.abspath(os.path.dirname(topdir + /../../../..)) if topdir not in sys.path: sys.path.append(topdir) -- 1.8.1.4 ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] Fix html not being escaped in package information
Hello Johannes, I committed you patch as: https://git.fedorahosted.org/cgit/spacewalk.git/commit/?id=55405e0c57e34c35cd13a482cf95e867661c0829 Thank you! -- Tomas Lestach Red Hat Satellite Engineering, Red Hat - Original Message - From: Johannes Renner jren...@suse.de To: spacewalk-devel@redhat.com Sent: Monday, August 5, 2013 4:13:21 PM Subject: [Spacewalk-devel] [PATCH] Fix html not being escaped in package information Hello, here is another small bugfix patch fixing HTML not being properly escaped in package description on this page: https://hostname/rhn/software/packages/Details.do?pid=pid Found that with a package where there was an email address in ... notation that didn't show up. Thanks and regards, Johannes -- SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Twitter Bootstrap: Standardizing the CSS framework?
% - 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. Well they are closely tied to Fedora and EL clones because majority of our users and contributors runs these distros. On the other hand we are open to make changes which simplify building Spacewalk on other distributions (on assumption they won't hurt current users). % 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. Well in fact they are very different e.g. tomcat 7 vs tomcat 5 and tomcat 6, systemd vs. SysV init, python 2.7 vs 2.4 and 2.6, etc. And all these differences are IMHO nicely handled in specs. % 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. Definitely, I can see a lot of people trying to build Spacewalk packages in build.opensuse.org they will appreciate for sure. % - 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
[Spacewalk-devel] patch to allow pgp signed rpms to be displayed in webui
Attaching a patch for review to allow pgp signed rpms to be displayed in the webui. In looking at the java Package queries xml we are specifically filtering out any rpm that does not have a key type of 'gpg' or not signed. I am seeing a case were some rpms are being imported successfully from puppet that are signed by pgp keys into custom channels but the webui will not display them due to this filter in the query. I talked with Justin Sherrill who was the original author of adding the filter to the query and we both could not determine why this constraint was added. So I wanted to check with spacewalk team if there is a historical reason otherwise I propose to allow pgp signed rpms. Regards, Shannon Hughes Senior SEG/GSS Red Hat From 5e9ed31bd1fc4c32f91585ed2ca95a1ff4dc838f Mon Sep 17 00:00:00 2001 From: Shannon Hughes shug...@redhat.com Date: Tue, 6 Aug 2013 14:50:24 -0400 Subject: [PATCH] allow pgp signed rpms to be displayed in webui channel listing --- .../common/db/datasource/xml/Package_queries.xml |2 +- web/html/Makefile |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/java/code/src/com/redhat/rhn/common/db/datasource/xml/Package_queries.xml b/java/code/src/com/redhat/rhn/common/db/datasource/xml/Package_queries.xml index 1971ce6..2a2f557 100644 --- a/java/code/src/com/redhat/rhn/common/db/datasource/xml/Package_queries.xml +++ b/java/code/src/com/redhat/rhn/common/db/datasource/xml/Package_queries.xml @@ -371,7 +371,7 @@ SELECT P.id AS ID, rhnPackageProvider PP on key.provider_id = PP.id left join rhnPackageKeyType KEYT on KEY.key_type_id = KEYT.id WHERE CP.channel_id = :cid and - ( KEYT.label = 'gpg' or KEYT.label is NULL) + ( KEYT.label = 'gpg' or KEYT.label = 'pgp' or KEYT.label is NULL) /query /mode diff --git a/web/html/Makefile b/web/html/Makefile index ccf016f..77c463a 100644 --- a/web/html/Makefile +++ b/web/html/Makefile @@ -1,5 +1,5 @@ # Makefile for installing the html files for RHN -# +# shughes # $Id$ TOP = .. -- 1.7.7.6 ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] upstreaming some of our .spec file changes
[snip] Well, discussions about renaming all tools and packages to spacewalk- something pop up from time to time for many years ;). Althought we mostly agree with renaming comandline tools (assuming that old names will remain at least as symlinks for compatibility reasons) we've decided not to rename rpm packages because it will make upgrades much complicated. How so? You simply Obsoletes: the old package name with the new one. You can even drop the Obsoletes: from the SPEC file after a time. [snip] -- Lamont Peterson lamont.peter...@imail.org Senior Systems Administrator Intermountain Healthcare ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
