Re: [Spacewalk-devel] fork/merge coprs
Stefan Bluhm: > Hello Michael, > > can you please merge my Java and Python copr repos to the spacewalkproject > once again? > > I have added all required packages to build all Spacewalk packages for RHEL8 > with Python 2 (plus a lot more to build the requirements of the requirements). > > https://copr.fedorainfracloud.org/coprs/sbluhm/python-packages/ > https://copr.fedorainfracloud.org/coprs/sbluhm/java-packages/ > > There are still a few packages missing to build the whole tree from scratch > (like Eclipse) but these are not required for the normal build. > > Again, these modules should be enabled for the EPEL8 build to make the Java > Spacewalk packages, sitemesh and simple-xml build: javapackages-tools:201801, > ant:1.10, python27:2.7, perl:5.26 (would be great if you could trigger the > rebuild a few times afterwards). Hello Stefan, I've merged packages back to spacewalkproject java/python packages. Java stack looks good, I've been able to rebuild everything up to spacewalk-search and spacewalk-java. Python stack still fails due to missing python2-dnf. A quick attempt to rebuild dnf with python2 enabled failed because of snowball of missing python2 dependencies. Regards, -- Michael Mráka Smart Management Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Repository data under /var/cache/rhn
Stefan Bluhm: > Hello, > > what creates the repository data under /var/cache/rhn/repodata ? Hello Stefan, It's taskomatic job channel-repodata. > The repomd.xml contains references to the files including their checksums. > repodata/comps.xml > repodata/modules.yaml > > These files do not exist though. > > yum seems to be OK with the missing files. dnf exits with files not found, > when reading the repo. I have tested it using spacewalk-clone-by-date. > > Are these files expected to exist (a checksum is in repomd.xml)? If yes, then > I guess I have a different issue than I expect. They should exist, you can find them in /var/satellite/rhn/comps and /var/satellite/rhn/modules/. The path from repomd.xml is translated to a proper file on the disk by backend (see rhnchannelcomps table in the datatabase for the mapping). > Best wishes, > > Stefan Regards, -- Michael Mráka System Management Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] spacewalk-utils functions depsolver and cloneByDate
Stefan Bluhm: > Hello, > > can you please explain me the purpose and the functionality of the > spacewalk-utils files depsolver.py and cloneByDate.py? Are they being called > by anything? I could not find any references to these files. They are used by spacewalk-clone-by-date: $ git grep depsolver utils ... utils/cloneByDate.py:from depsolver import DepSolver ... $ git grep cloneByDate utils ... utils/spacewalk-clone-by-date:from utils import cloneByDate utils/spacewalk-clone-by-date:from utils.cloneByDate import UserError utils/spacewalk-clone-by-date:return cloneByDate.main(args) ... > If these are just human readable CLI tools, it would make a re-implementation > with similar output easier. (or even drop the function as dnf can do the same > by itself?) > > Thank you and best wishes, > > Stefan Regards, -- Michael Mráka System Management Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [Spacewalk-list] Spacewalk 2.10 Released!
TOMAŠKOVIČ Marcel: > Hi Michael, > Thank you and development team for this project. I think, this project is > very sucessful. > I have question - is there another solution / product for system mangment in > linux (RHEL)? Somethng like Spacewalk.. Hello Marcel, New version of Red Hat Satellite (aka Satellite 6) is based on https://theforeman.org project with Katello plugin (https://theforeman.org/plugins/katello/). There's also https://www.uyuni-project.org which is a fork of Spacewalk made by SUSE. > Thank you, > Best regards > Marcel Regards, -- Michael Mráka System Management Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Spacewalk 2.10 Released!
> Hello everyone, > > We are proudly announcing release of Spacewalk 2.10, a systems management > solution. Hello Spacewalkers, I'd like to set properly expectations about future of this project. As you most likely know this project is an upstream for Red Hat Satellite 5 product. And Satellite 5 is going to be End Of Life on May 31 2020. This also means Red Hat will discontinue an active support of this project. The most important message is Spacewalk 2.10 was the last official release of Spacewalk. Git repo, project pages, documentation and wiki will still be available (we plan to switch them to readonly). COPR repos (which means packages) will also remain available. Regards, -- Michael Mráka System Management Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Spacewalk Client - Python 2
Neal Gompa: > On Fri, Mar 20, 2020 at 6:23 AM Stefan Bluhm wrote: > > > > Thank you, > > > > valid point that RHEL7 != RHEL7. > > What would be the expectation of the server? To also run on 7.6? > > > > Server would be expected to run on latest RHEL 7 with updates applied. > So we can expect Python 3 there. Yes, it's ok to expect latest updates on server, i.e. RHEL 7.7 with python3. The problem with client is that there's often a valid reason for installing older clients, e.g. if you need to run a third party software certified only for RHEL 7.3 on it. Regards, -- Michael Mráka System Management Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Spacewalk 2.10 Released!
Hello everyone, We are proudly announcing release of Spacewalk 2.10, a systems management solution. Spacewalk 2.10 could be installed on * RHEL 6 * RHEL 7 * Fedora 30 * Fedora 31 The download location is * https://copr.fedorainfracloud.org/coprs/g/spacewalkproject/spacewalk-2.10/ with client repositories under * https://copr.fedorainfracloud.org/coprs/g/spacewalkproject/spacewalk-2.10-client/ For fresh installations, please use steps from * https://github.com/spacewalkproject/spacewalk/wiki/HowToInstall If you plan to upgrade from older release, search no more -- the following page will guide you: * https://github.com/spacewalkproject/spacewalk/wiki/HowToUpgrade Features & Enhancements in Spacewalk 2.10 * Spacewalk now installable on Fedora 30 and 31 * Spacewalk supports Fedora 30 and 31, Red Hat Enterprise Linux and CentOS 8 clients * Number of bugfixes and security fixes The up-to-date API documentation can be found at http://spacewalkproject.github.io/documentation/api/2.10/ Contributors Our thanks go to the community members who contributed to this release: * Christian Hailer * Eduardo Suarez-Santana * Elena Zaharia * Jay McCanta * Josef Hak * Kenny Tordeurs * Kim Sondrup * Laurence Rochfort * Michael Mraka * Robert Paschedag * Rostislav Medvěd * Stefan Bluhm * Tomas Kasparek * Vladislav Belogrudov * Yuriy Kashirin Some statistics In Spacewalk 2.10, we've seen * 46 major bugs fixed * 230 changesets committed * 429 commits done User community, reporting issues To reach the user community with questions and ideas, please use mailing list spacewalk-l...@redhat.com. On this list, you can of course also discuss issues you might find when installing or using Spacewalk, but please do not be surprised if we ask you to file a bug at https://bugzilla.redhat.com/enter_bug.cgi?product=Spacewalk with more details or full logs. Thank you for using Spacewalk. -- Michael Mráka System Management Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Spacewalk Client - Python 2
Stefan Bluhm: > > Python 2 version is needed for RHEL/CentOS 6 and 7 because python 3 is not > > installed by default. > > Regarding RHEL7, having the Python 3 installation as a prerequisite for the > client is not preferred? Well, from the community project point of view (like Spacewalk) it could be more or less ok. From enterprise product POV (like Satellite 5) it is not. And the reason is that python3 has been introduced lately in RHEL 7.7 so any RHEL <7.6 client wont work. Regards, -- Michael Mráka System Management Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Spacewalk Client - Python 2
Stefan Bluhm: > Hello again, > > Can you please give me some strategic guidance regarding Python 2 on the > clients. Python 2 is end of life. Should Python 2 clients still be included? > I am not really sure, which clients that would be impacted across the Linux > distributions. Python 2 version is needed for RHEL/CentOS 6 and 7 because python 3 is not installed by default. > My opinion is to also remove all Python 2 from the clients (SUSE, Debian, > RHEL6). If they still need to be managed, the 2.9/2.10 clients could still be > used. > > Best wishes, Regards, -- Michael Mráka System Management Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Spacewalk on RHEL8 - Step 2 (of many) completed
Stefan Bluhm: > Hello all, > > just to give you an update: I now have Spacewalk 8 installing and running on > CentOS 8. > > I have created pull requests for all my modifications. Hello Stefan, I've reviewed them and some of them needs a small fixes. > Couple of issues I noticed straight away: > - When installing the setup packages, some dependencies seem to be not > automatically installing (spacewalk-selinux, taskomatic,...) Both spacewalk-selinux and spacewalk-taskomatic should be installed as they are required by spacewalk-common. > - the password field at the first registration. It does not show a green tick > when the password is OK. (optical issue) > - The overview page is pretty empty. Not sure if this is just due to an empty > system or of this is an issue. > - When creating a repo, CSRF token issues/403 show up. I expect these things > to show up at some places then. > > Clicking through the rest, I do not see any issues on the pages at first > glance. > > > To try this yourself, get started with a minimal CentOS 8 in 12 lines: > > systemctl disable firewalld; systemctl stop firewalld # no need to > play with individual ports > dnf config-manager --add-repo https://raw.githubusercontent.com/sbluhm > # packages that still need to be put to COPR > echo "gpgcheck=0" >> /etc/yum.repos.d/raw.githubusercontent.com_sbluhm.repo > dnf -y copr enable sbluhm/python-packages; dnf -y copr enable > sbluhm/java-packages # stuff to move to spacewalkproject > dnf -y copr enable sbluhm/nightly # as soon as the official > nightly builds with my pull requests, I will update this section > dnf -y config-manager --enable PowerTools > dnf -y module enable javapackages-tools:201801/common > dnf -y install epel-release langpacks-en langpacks-de glibc-all-langpacks > # without the langpacks, Postgresql will not run. > dnf -y update python3-dmidecode # own version required > to install python2-dmicode > rpm -e yum # remove yum 4 to > install yum 3 > dnf -y install spacewalk-setup spacewalk-setup-postgresql tomcat > osa-dispatcher spacewalk-search spacewalk-backend-sql-postgresql > spacewalk-taskomatic spacewalk-java spacewalk-java-postgresql > spacewalk-selinux # not all dependencies are strangely installed so doing it > all here. This should be better dnf -y install spacewalk-setup-postgresql dnf -y install spacewalk-postgresql > spacewalk-setup > > You can visit my personal project note to get the latest working installation > instructions (currently same as above): > https://www.bluhm-de.com/content/os-tools/en/applications/spacewalk/installing-spacewalk-nightly-on-centos8-rhel8.html > > Open topics: > - How will the Spacewalk Project continue? > - Remove Python 2 scripts. > - Update to latest/newer required packages if possible. > - Test for non-working items > - Update package requirements/dependencies in the spec files. > - Add official RH Java packages to copr/java-packages. How would we go about > that?. > - Add official RH Python packages to copr/python. How would we go about that?. I've forked copr sbluhm/java-packages into @spacewalkproject/java-packages and similarly sbluhm/python-packages into @spacewalkproject/python-packages. > - Add spec files of modified packages to spacewalkproject/spec-tree. > > Best wishes, > > Stefan Regards, -- Michael Mráka System Management Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Update COPR nightly settings
Stefan Bluhm: > Hello, > > can you please update the following settings in the nightly COPR epel8-x64-86 > chroot: > > Repos (add): http://mirror.centos.org/centos/8/PowerTools/x86_64/os/ > modules: javapackages-tools:201801, ant:1.10, python27:2.7, perl:5.26 > > This will allow more modules to compile (for ant) Hello Stefan, I've updated epel8 settings and will try to resubmit failed packages. > Thanks, > > Stefan -- Michael Mráka System Management Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Please accept pull requests
Stefan Bluhm: > Hello Michael, > > can you please accept these pull requests to Spacewalk Master (all minor/low > risk changes in spec files): > > PR704 - Added info for clarity (for future work) > PR705 - Updated Source URLs in SPEC Files to allow COPR builds > PR706 - Adapted spec for RHEL8 package name. > PR707 - Changed to versioned Python2 for RHEL8(only) > PR708 - Modified cglib.jar naming for RHEL8 > > There should not be any breaking changes or impact on other OS versions. Hello Stefan, I will. Just a note: there's no need to increase version/release and add changelog into spec manually. It's done automatically by a script. > Thank you, > > Stefan Regards, -- Michael Mráka System Management Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Spacewalk on RHEL8 - Step 1 (of many) completed
Stefan Bluhm:
> Hello all,
>
> TLDR: Spacewalk packages build and can be installed on CentOS 8.
>
> as I am working on getting Spacewalk to run on CentOS8/RHEL8, I would like to
> share my progress here with you, in the hopes that you can contribute or
> share your experience/knowledge. I am not company sponsored, not a developer
> nor do I have much other knowledge of Linux.
>
> Around three weeks ago, I forked the GIT repo and the COPR repositories. So
> that is the basis of my current work:
> https://github.com/sbluhm/spacewalk
> https://copr.fedorainfracloud.org/coprs/sbluhm/nightly/ # Contains
> the packages from the original spacewalk nightly
> https://copr.fedorainfracloud.org/coprs/sbluhm/java-packages/ # Contains
> 421 Java related and other random packages
> https://copr.fedorainfracloud.org/coprs/sbluhm/python-packages/ # Contains
> 115 Python, Perl and other random packages
> http://dev2.bluhm-de.com/packages # Custom
> repo for locally compiled or added packages that I was not yet able to build.
>
> Primary objective was to hack everything together to get everything to build.
>
> I have added and built all required dependencies (mainly Python 2 and Java)
> and modified the RPM spec files so that it is possible to successfully build
> all Spacewalk packages. It is also possible to install all Spacewalk packages
> apart from spacewalk-proxy* and spacewalk-oracle* which I have no idea (or
> currently care) how to set up.
Hello Stefan,
That sounds like a huge amount of great work.
> Unfortunately, spacewalk-setup fails due to a postgresql configuration error
> (unrecognized configuration parameter "checkpoint_segments"), otherwise this
> would have been an additional great achievement.
See commit fe265a597de3f043c22bf7910d2119e9c9b967cd.
IMHO you just need to change condition in spec to
%if 0%{?fedora} || 0%{?rhel} >= 8
> Next few steps I see (in no real particular order):
> - Clean up and verify the git changes and push them to the Spacewalk master.
> Michael, you will see quite a few SHORT pull requests coming from me in the
> future. It would be great, if you could sanity check them (as mentioned
> above, I am not a developer nor do I know what I am doing).
I'll take a look.
> - Fix the compile issues from my local repository and add them to the COPR
> repos.
> - Clean up the repos. I probably have more packages built than required.
> Including already existing RHEL8 packages and/or module conflicts.
> - Start moving code to Python 3 to get rid of the many custom built Python 2
> packages.
>
> Open questions from my side:
> - What do I do with those build packages in my repos? How/where do I add them
> to hand my work over? Please give some assistance where to put what (git,
> nightly, python-packages, java-packages) and how.
What are these packages? Fedora packages simply rebuilt for RHEL8? Or
are there any tweaks in their spec?
Clean rebuilds can go to python-packages / java-packages, packages with changed
specs
we keep in git and build them into nightly.
> - Is there a reason to keep Python 2 or can everything be moved to Python 3?
Server side can be moved to python3 without problem. For RHEL 6 and 7
(and clones like CentOS, OL, etc.) clients we still need python2.
> - What are the supported OS? I would say RHEL>=7 (remove 6 code), Fedora >=
> 29 (28 is EOL in May and I doubt we will be ready for a release by then).
> What about SLES? I have seen SLES specific code in there.
So far RHEL6+ and Fedora 30+ (29 has been EOLed and removed from COPR).
For Spacewalk 2.9 we had also had SLES and Debian clients built but I
don't know the current status.
> - Probably create a wiki page/edit for instructions how to install the
> nightly on RHEL8
>
> Do you see the next steps in the same way? Do you have any other suggestions,
> recommendations, guidelines?
> How can you assist?
>
> I will shift my focus for time being to a different project (evdi) to get my
> second screen working again. Then I will probably be back here.
>
> Best wishes,
>
> Stefan
Regards,
--
Michael Mráka
System Management Engineering, Red Hat
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] rhnpush with Python2 and Python 3
Stefan Bluhm: > Hello Michael, > > > You need the same version of python3-dmidecode and python2-dmidecode (built > > from the same srpm) so the /usr/share/python-dmidecode/pymap.xml file is > > identical in both and do not conflict. > > That might be. But the package building still conflicts as dnf does not know > this (see error message below). Is it still possible to build rhnpush > (without manual interaction) or is this a bug in the spec file? Dnf does know. Quick test on F30: [root@d3119aed1f35 /]# dnf install python3-dmidecode python2-dmidecode -y Last metadata expiration check: 0:01:50 ago on Mon Mar 9 10:42:44 2020. Dependencies resolved. == Package Architecture Version Repository Size == Installing: python2-dmidecodex86_64 3.12.2-14.fc30 fedora 87 k python3-dmidecodex86_64 3.12.2-14.fc30 fedora 86 k Installing dependencies: python2 x86_64 2.7.17-1.fc30 updates45 k ... Complete! [root@d3119aed1f35 /]# rpm -qf /usr/share/python-dmidecode/pymap.xml python2-dmidecode-3.12.2-14.fc30.x86_64 python3-dmidecode-3.12.2-14.fc30.x86_64 In your case: "file /usr/share/python-dmidecode/pymap.xml from install of python3-dmidecode-3.12.2-15.el8.x86_64 conflicts with file from package python2-dmidecode-3.12.2-11.el8.x86_64" 3.12.2-15 != 3.12.2-11 Regards, -- Michael Mráka System Management Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] rhnpush with Python2 and Python 3
Stefan Bluhm: > Hello, > > can you tell me how to build the RPM for python2-rhnpush for the server or > any other system that has Python 2 and Python 3 installed (Fedora and > RHEL7+)? As far as I understand from the source, it is actually not possible > to build the package on Fedora/later RHEL versions (Python 2 is always built, > Python 3 is always built on Fedora/latest RHEL). > > Python 2 requires "python2-rhn-client-tools" and Python 3 requires > "python3-rhn-client-tools". Both packages require their own version of > mutually exclusive "python?-dmidecode" versions. So an "dnf install" for > these packages will fail with the message: > > "file /usr/share/python-dmidecode/pymap.xml from install of > python3-dmidecode-3.12.2-15.el8.x86_64 conflicts with file from package > python2-dmidecode-3.12.2-11.el8.x86_64" Hello Stefan, You need the same version of python3-dmidecode and python2-dmidecode (built from the same srpm) so the /usr/share/python-dmidecode/pymap.xml file is identical in both and do not conflict. > How did you manage to build python2-rhnpush on the latest Fedora? On my > branch, I now added a "--with server" option to only build Python2 for that. > > Best wishes, > Stefan Regards, -- Michael Mráka System Management Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Fwd: Spacewalk 2.10 branched
Stefan Bluhm: > Hello Michael > > >> PR702 Changed backend/satellite_tools/reposync.py to also download the > >> .treeinfo file from a repo. The missing treeinfo file stops provisioning > >> of KVMs. > >> Downside is, that the now added treeinfo file causes issues when > >> provisioning CentOS 8 as it includes the Appstream repo, which does not > >> get synced down with reposync. > > >What problem solves it? Is currently provisioning of all distributins > >(Fedora, CentOS 6,7) or CentoOS 8 only broken? > > The current design: > .treeinfo is not downloaded from the repo. This file seems to be required for > kickstart provisionings. CentOS 7 shows a 404 before starting Anaconda. Then > the kickstart continues without any further issues. > > On CentOS 8, it sometimes worked, sometimes doesn't. I think it depends on > the channel setup. Sometimes even resaving of the channel helps. > > This month, I started looking at virtualising via kvm instead of VMWare but I > was not able to provision CentOS 7 or CentOS 8 at all. I don't remember > exactly but I think the installation process failed before anaconda. I traced > it down to the missing .treeinfo file. Now with my fix, I can always deploy > C7 and C8 reliably. Even on non kvm kickstart. Ok, I see. > As I mentioned, one drawback of the existing treeinfo file is that a default > C8 definitely won't provision as the treeinfo file contains a link to the > AppStream FOLDER, which one would usually not clone down for Spacewalk usage > as all packages are in one/different Spacewalk Channels. So at the moment, > one has to manually update the treeinfo file and remove linked channels. The > way I see it though is, that this would be the expected design/flaw and > should be improved upstream. Kopano has the same issue. > I am happy to eventually work an a C8 specific/general Spacewalk improvement > to filter all linked channels out if that is asked for. Either way, this > limitation should be documented in the Spacewalk manual. RHEL 8 provisioning works, I'll try to take a look how is it different from CentOS. > Best wishes, > > Stefan -- Michael Mráka System Management Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [Spacewalk-list] Spacewalk 2.10 branched
Brian Long: > Michael, this is great news. Is it expected Spacewalk 2.10 will fully > support RHEL 8 clients including modules and appstreams? I imagine > due to previous threads you are not ready to support Spacewalk 2.10 > server on RHEL 8, but I hope clients will be fully supported. Thank > you for any additional details you can provide. Hello Brian, This release will not contain Spacewalk server on RHEL8 because we are unable to build all necessary dependencies (yet). As for RHEL 8 client there are no new features over Spacewalk 2.9. So the current status both for Spacewalk 2.9 and 2.10 is - able to sync RHEL 8 repos - both BaseOS and AppStream - able to create kickstart distribution and profile for RHEL 8 - which also means able to provision RHEL 8 hosts (physical and virtual) - if repo contains module information it's downloaded and passed on to client - does not support creation of own modules - does not properly show updates for modular repos (maybe something else I can't remember off the top of my head). > /Brian/ Regards, -- Michael Mráka System Management Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Spacewalk 2.10 branched
Stefan Bluhm: > Hello Michael, Hello Stefan, > any chance to get my two pull requests into it? > > PR703 Is low risk (updating http to https in a SPEC file.) No problem with that one. Merged. > PR702 Changed backend/satellite_tools/reposync.py to also download the > .treeinfo file from a repo. The missing treeinfo file stops provisioning of > KVMs. > Downside is, that the now added treeinfo file causes issues when provisioning > CentOS 8 as it includes the Appstream repo, which does not get synced down > with reposync. What problem solves it? Is currently provisioning of all distributins (Fedora, CentOS 6,7) or CentoOS 8 only broken? > So eventually, there has to be a code change to automatically strip out > linked repositories and addition to the documentation to provide the stripped > out repositories as a channel during provisioning. Or auto-creation of the > treeinfo file. Apart from that, I would say that the above behaviour would be > as designed and should be expected in that way. > > Best wishes, > > Stefan Regards, -- Michael Mráka System Management Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Spacewalk 2.10 branched
Hello Spacewalkers, We moved on and we are woking towards Spacewalk 2.10 release. A new git branch SPACEWALK-2.10 has been created for it. Now it's a release candidate and we are working on stabilization. You can help with a testing/verification bugs in the nightly repo https://copr.fedorainfracloud.org/coprs/g/spacewalkproject/nightly/ https://copr.fedorainfracloud.org/coprs/g/spacewalkproject/nightly-client/ and if we find and fix some blocker bugs, we will cherry-pick fixes into Spacewalk 2.10. Updated instruction how to install nightly version https://github.com/spacewalkproject/spacewalk/wiki/HowToInstallNightly Thanks, -- Michael Mráka System Management Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Spacewalk Server for RHEL 8
Stefan Bluhm: > Thank you Neal, > > > Another thing needed will be to port the code using YUM to DNF. > > Is this mandatory for RHEL8? As far as I understand, yum is still working on > RHEL8. Not really, you can build and use old yum on RHEL8 (as we still do on Fedora). > Or is this a nice to have to drop Pyhton 2 support? Yes, move to python3 and dnf would be nice but not necessary. > Best wishes, > > Stefan Regards, -- Michael Mráka System Management Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Some 2.8.x version RPMs list in 2.9 COPR project
Laurence Rochfort: > > Hello Laurence, > > > > these versions are ok. There has been no change during Spacewalk 2.9 > > development in these packages. If you look into .spec you can see > > Version: 2.9.0 here but it is just a result of an automatic version > > bump so the first real change in the package would increased version to > > 2.9.1. > > > > Let's check latest tagged versions: > > $ cd spacewalk.git > > $ git checksout SPACEWALK-2.9 > > $ for t in spacewalk-proxy-installer spacewalk-config > > spacewalk-setup-postgresql spacewalk-proxy-selinux perl-Satcon spacewalk-2 > > spacewalk-proxy-docs spacewalk-proxy-html ; do git tag | grep $t | tail -1 > > ; done > > spacewalk-proxy-installer-2.8.6-1 > > spacewalk-config-2.8.5-1 > > spacewalk-setup-postgresql-2.8.4-1 > > spacewalk-proxy-selinux-2.8.3-1 > > perl-Satcon-2.8.2-1 > > spacewalk-2.8.2-1 > > spacewalk-proxy-docs-2.8.2-1 > > spacewalk-proxy-html-2.8.2-1 > > Thanks for the explanation, Michael. > > I do wonder if having the main Spacewalk 2.9 package have a version of > 2.8 is a little confusing for a sys admin who's not so familiar with > Spacewalk? > > If I were to ask yum which version of Spacewalk I have installed and it > says 2.8, or the main package version didn't match all the others, then > it might be confusing and cause me to try to upgrade? Hello Laurence, Well, that's actually a good point. I've rebuilt spacewalk package both in 2.9 branch and master to reflect the repository version.> > Just a thought. > > -- > Cheers, > Laurence. Regards, -- Michael Mráka System Management Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Some 2.8.x version RPMs list in 2.9 COPR project
Laurence Rochfort: > Hi all, > > I was looking at the COPR project for Spacewalk 2.9 and noticed that > some of the spacewalk-* packages have a 2.8.x version, whereas in the > SPACEWALK-2.9 git tag they have a 2.9.x version. > > The main spacewalk package stands out in particular. > > https://copr.fedorainfracloud.org/coprs/g/spacewalkproject/spacewalk-2.9/ > > I noticed the following packages have different version numbers from > git: > > spacewalk-proxy-installer 2.8.6-1.fc2814 days ago succeeded > Disabled- > spacewalk-config 2.8.5-1.fc2814 days ago succeeded > Disabled- > spacewalk-setup-postgresql2.8.4-1.fc2814 days ago succeeded > Disabled- > spacewalk-proxy-selinux 2.8.3-1.fc2814 days ago succeeded > Disabled- > perl-Satcon 2.8.2-1.fc2814 days ago succeeded Disabled > - > spacewalk 2.8.2-1.fc2814 days ago succeeded Disabled > - > spacewalk-proxy-docs 2.8.2-1.fc2814 days ago succeeded > Disabled- > spacewalk-proxy-html 2.8.2-1.fc2814 days ago succeeded > Disabled- > > Could somebody please confirm if the correct versions have been built on > COPR? Hello Laurence, these versions are ok. There has been no change during Spacewalk 2.9 development in these packages. If you look into .spec you can see Version: 2.9.0 here but it is just a result of an automatic version bump so the first real change in the package would increased version to 2.9.1. Let's check latest tagged versions: $ cd spacewalk.git $ git checksout SPACEWALK-2.9 $ for t in spacewalk-proxy-installer spacewalk-config spacewalk-setup-postgresql spacewalk-proxy-selinux perl-Satcon spacewalk-2 spacewalk-proxy-docs spacewalk-proxy-html ; do git tag | grep $t | tail -1 ; done spacewalk-proxy-installer-2.8.6-1 spacewalk-config-2.8.5-1 spacewalk-setup-postgresql-2.8.4-1 spacewalk-proxy-selinux-2.8.3-1 perl-Satcon-2.8.2-1 spacewalk-2.8.2-1 spacewalk-proxy-docs-2.8.2-1 spacewalk-proxy-html-2.8.2-1 Which matches with what you observe. > Many thanks. > > > > Oh, I noticed that the repo link on the following page is wrong: > > https://spacewalkproject.github.io/howtoinstall.html > > States: > https://copr.fedorainfracloud.org/groups/g/spacewalkproject/spacewalk-2.9/ > Should be: > https://copr.fedorainfracloud.org/coprs/g/spacewalkproject/spacewalk-2.9/ Fixed, Thanks for the report. > -- > Cheers, > Laurence. Regards, -- Michael Mráka System Management Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Struts 1.x v1.3 (Apache Software Foundation, The)
Rajput, Jawad (CONTR): > Good Afternoon. > > I have a question about Struts 1.x v1.3 (Apache Software Foundation, The). We > are running Spacewalk 2.9 and during software audit we found Spacewalk 2.9 is > running struts-1.3.10-18.sw.noarch which has already been EOL. I am wondering > if it possible to confirm if the Struts is backported or can it be updated to > supported version? Please advise. Hello Jawad, Spacewalk uses struts v1.x. We know it's been EOLed and we follow and fix possible CVEs. It isn't possible to upgrade to struts v2 because of different API. > - Jawad Regards, -- Michael Mráka System Management Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Replacing YUM with DNF in Spacewalk server (and Python 3 for the server?)
Neal Gompa: > Hey all, > > In light of the Fedora 30 change to retire YUM[1] and the fact that > DNF is now present in RHEL/CentOS 7 (as well as Fedora, openSUSE Leap > 15, Mageia, etc.), I think we should port the last remaining things > server side that have hard dependencies on YUM to use DNF. Hello, > I did a quick grep through the codebase, and I only identified two > files that trigger a hard dependency on YUM: > * utils/depsolver.py > * backend/satellite_tools/repo_plugins/yum_src.py also * utils/cloneByDate.py but it isn't a big deal. > Porting these to DNF should completely eliminate the hard dependency > on YUM as well as the remaining blockers to keeping the Spacewalk > server Python 2 only, which is important since Python 2 stuff is being > removed in Fedora 30, too[2]. > > Now, I've done a few ports of things from YUM to DNF before, so I'm > willing to help with this porting effort. I just want to make sure > that this is something you'd be willing to accept. Yes, we will gladly accept patches for dnf and python3 support. I'm just afraid there's way more than that - all the subtle differences with print, exceptions, lists vs. iterators, bytes vs. strings vs. unicode, etc. > I don't know if you guys are still supporting RHEL/CentOS 6 based > Spacewalk servers, but EL6's EOL is next year anyway, and push comes > to shove, we can keep a copy of the old file and have the package > install the YUM version of the code only on EL6 builds. We still need to support RHEL6 - this is what makes difference between an OSS project and an enterprise product ;). > So, what do you all think? > > Best regards, > Neal > > [1]: https://fedoraproject.org/wiki/Changes/Retire_YUM_3 > [2]: https://fedoraproject.org/wiki/Changes/Mass_Python_2_Package_Removal > > -- > 真実はいつも一つ！/ Always, there's only one truth! Unless there is more than one... Regards, -- Michael Mráka System Management Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Spacewalk 2.9 Released!
Hello everyone, We are proudly announcing release of Spacewalk 2.9, a systems management solution. Spacewalk 2.9 could be installed on * RHEL 6 * RHEL 7 * Fedora 27 * Fedora 28 * Fedora 29 The download location is https://copr.fedorainfracloud.org/coprs/g/spacewalkproject/spacewalk-2.9/ with client repositories under https://copr.fedorainfracloud.org/coprs/g/spacewalkproject/spacewalk-2.9-client/ SUSE Linux client packages can be found here http://download.opensuse.org/repositories/systemsmanagement:/spacewalk:/2.9/ For fresh installations, please use steps from https://github.com/spacewalkproject/spacewalk/wiki/HowToInstall If you plan to upgrade from older release, search no more -- the following page will guide you: https://github.com/spacewalkproject/spacewalk/wiki/HowToUpgrade Features & Enhancements in Spacewalk 2.9 * Spacewalk now installable on Fedora 29 * Spacewalk supports Fedora 29 and Fedora rawhide clients * All packages and repositories are exclusively in https://copr.fedorainfracloud.org/ * Spacewalk server is now capable of syncing and distributing of Red Hat Enterprise Linux 8 Beta content * Number of bugfixes Updated API calls: * errata.create/setDetails - add possibility to manage severities Contributors Our thanks go to the community members who contributed to this release: Chris Bajumpaa Neal Gompa Robert Paschedag Angelo Lisco see https://github.com/spacewalkproject/spacewalk/wiki/ContributorList for all contributors list Some statistics In Spacewalk 2.9, we've seen * 41 major bugs fixed * 318 changesets committed * 555 commits done User community, reporting issues To reach the user community with questions and ideas, please use mailing list spacewalk-list redhat com On this list, you can of course also discuss issues you might find when installing or using Spacewalk, but please do not be surprised if we ask you to file a bug at https://bugzilla.redhat.com/enter_bug.cgi?product=Spacewalk with more details or full logs. Thank you for using Spacewalk. ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Branching of Spacewalk 2.9
Hello Spacewalkers, I have made a branch for a new release of Spacewalk 2.9. Now it's a release candidate and we are working on stabilization. You can help with a testing/verification bugs in the nightly repo and if we find and fix some blocker bugs, I will cherry-pick fixes into Spacewalk 2.9. Thanks, -- Michael Mráka System Management Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Spacewalkproject archive has moved
Hello Spacewalkers, Yesterday we moved archive of old spacewalk releases (<= 2.7) from old infrastructure to Fedora COPR servers. The new path is https://copr-be.cloud.fedoraproject.org/archive/spacewalk/ (instead of old http://yum.spacewalkproject.org/). If you still need access to archived releases please update url in your repo files. E.g. using sed -i 's,yum.spacewalkproject.org,copr-be.cloud.fedoraproject.org/archive/spacewalk,' /etc/yum.repos.d/spacewalk*.repo Urls for current release and nightly snapshots have not changed because they are already in COPS for quite some time. Regards, -- Michael Mráka System Management Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Improving Spacewalk Debian/Ubuntu client packaging with debbuild + spec files
Neal Gompa: > Hey all, > > I'm working with a colleague of mine to package the Spacewalk > Debian/Ubuntu client packages for internal use. In our environment, we > use an internal instance of OBS[1] combined with debbuild[2] to build > native Debian packages with RPM spec files to drastically simplify the > effort we have to go through to build and maintain Debian packages. > > We're also willing to contribute the work we're doing upstream, if > this interests the Spacewalk and Uyuni developers. Note that debbuild > can be used completely independently of OBS, so it can be used on a > plain Linux system, as long as dpkg and dpkg-dev are installed. Hello Neal, Your effort is definitelly welcome. Once you have your changes together please create a pull request so we can include it and improve Spacewalk upstream packaging. Thank your for the contribution, > Best regards, > Neal > > [1]: https://openbuildservice.org/ > [2]: https://github.com/ascherer/debbuild > > -- > 真実はいつも一つ！/ Always, there's only one truth! -- Michael Mráka System Management Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] EOL Jakarta Packages in Spacewalk
Danis, Andrew (CONTR): > Good Afternoon Spacewalk Team, > > Regarding these packages: > > jakarta-oro-2.0.8-16.el7.noarch > jakarta-commons-httpclient-3.1-16.el7_0.noarch > > Are these being supported with security patches by red hat? I see fixes as of > 2013/2014 for CVE-2014-3577 and 2013-1571 but according to the Jakarta > project page it has been EOL since 2010. Hi Andrew, These packages are provided by Red Hat (as a part of Red Hat Enterprise Linux 7 repos) and we take responsibility for security fixes of all packages we ship (even EOLed by upstream). That's the value of your RHEL subscription. > Andrew Danis > System Administrator Regards, -- Michael Mráka System Management Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [Spacewalk-list] spacewalk info needed
Afify, Sherif S (IBS): > Hi , after joining the spacewalk , I got the below error message while > running the yum command , did any faced that before ? > AttributeError: 'RhnRepo' object has no attribute '_retry_no_cache' This issue has been fixed in Spacewalk 2.7. Please update yum-rhn-plugin package. -- Michael Mráka System Management Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] FW: Spacewalk 2.6 install issue
Lewis Bower: > Hi, > > I am following this > guide;https://github.com/spacewalkproject/spacewalk/wiki/HowToInstall#installing-spacewalk > > I am getting SELinux errors when installing spacewalk. > > I am having two issues when installing spacewalk-selinux-2.3.2-1.el7.noarch > and osa-dispatcher-selinux-5.11.74-1.el7.noarch > > I get the errors: > > Installing : spacewalk-selinux-2.3.2-1.el7.noarch Failed to resolve roletype > statement at > /etc/selinux/mls/tmp/modules/400/spacewalk/cil:2 > /usr/sbin/semodule: Failed! > Failed to resolve roletype statement at > /etc/selinux/strict/tmp/modules/400/spacewalk/cil:2 > /usr/sbin/semodule: Failed! Verifying : spacewalk-selinux-2.3.2-1.el7.noarch > and also; > > Installing : osa-dispatcher-selinux-5.11.74-1.el7.noarch > Failed to resolve roletype statement at > /etc/selinux/mls/tmp/modules/400/osa-dispatcher/cil:2 > /usr/sbin/semodule: Failed! > Failed to resolve roletype statement at > /etc/selinux/strict/tmp/modules/400/osa-dispatcher/cil:2 > /usr/sbin/semodule: Failed! > Verifying : osa-dispatcher-selinux-5.11.74-1.el7.noarch > In /etc/selinux/config it is SELINUX=enforcing and SELINUXTYPE=targeted. > result of rpm -qa | grep selinux-policy is > selinux-policy-3.13.1-102.el7_3.16.noarch and > selinux-policy-targeted-3.13.1-102.el7_3.16.noarch > > I have enabled the CentOS-CR repo to resolve an earlier error when installing > about not having http-parser dependencies. > > I have also tried setting SeLinux to permissive but this didn't help. These errors messages are harmless. They are cause by recent change in semodule error code handeling. It's been already fixed for Spacewalk 2.7/nightly. Despite the errors spacewalk selinux policy is installed correctly. Regards, > Cheers, > > Lewis. -- Michael Mráka System Management Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Failed builds of spacewalk-backend on RHEL7
FYI An (silly) automatic package orphaning process removed python-astroid from EPEL which broke pylint which broke spacewalk-backend builds. Rel-eng ticket already here https://pagure.io/releng/issue/6941 -- Michael Mráka System Management Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Spacewalk Development setup - not working
Bhavesh Bharadiya: > Hello, > > I have installed spacewalk on Fedrora 24 ( > https://github.com/spacewalkproject/spacewalk/wiki/HowToInstall ) and it is > working fine. I am trying to setup development environment ( > https://github.com/spacewalkproject/spacewalk/wiki/DevelopmentWorkstationSetup) > on top of this. I am following steps under Poor Man’s Dev workstation. > > • sudo /usr/sbin/rhn-satellite stop > • sudo yum install ant-contrib yum-plugin-versionlock > • sudo yum install jmock --disablerepo=* --enablerepo=jpackage-generic > > • cd $SPACEWALK_GIT/java > • sudo ant install-web > • sudo ant install-tomcat Hello, is there new rhn.jar build and installed in /var/lib/tomcat/webapps/rhn/WEB-INF/lib/rhn.jar after this? > • sudo service tomcat restart > > I am able to execute above steps successfully, it is not giving me any > errors. But after doing change in source code I do not see those changes on > web page. It seems my changes are not reflecting. Can you please help me to > resolve this issue. Are there any error in /var/log/tomcat/catalina*.log? > Thanks > Bhavesh Regards, -- Michael Mráka System Management Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] spacewalk nightly 2.6 ist postgresql is not installable
Pavel Studeník: > Hi. > Can anybody help me with this issue? > > I try to install spacewalk 2.6 with postgresql and I received error > during installation of packages: > > Transaction check error: > file /usr/share/java/commons-fileupload.jar conflicts between > attempted installs of jakarta-commons-fileupload-1:1.2.1-1.jpp5.noarch > and apache-commons-fileupload-1.3.2-3.el7.noarch > > I found advice in mailing list and I enabled epel-testing. Now packages > are installable, but spacewalk doesn't work. Late but better than never... > > FO: Deploying configuration descriptor > /etc/tomcat/Catalina/localhost/rhn.xml > Apr 11, 2017 3:03:29 PM org.apache.catalina.loader.WebappLoader > startInternal > SEVERE: LifecycleException > java.io.IOException: Failed to access resource /WEB-INF/lib/c3p0.jar > at There's an update of c3p0 in EPEL which puts c3p0.jar into a different path than older c3p0 (from jpackage). So workaround/fix is a) downgrade to older (jpackage) version yum downgrade c3p0 or b) create a symlink ln -s c3p0/c3p0.jar /usr/share/java/c3p0.jar > org.apache.catalina.loader.WebappLoader.setRepositories(WebappLoader.java:981) > at ... -- Michael Mráka System Management Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] First version of spacewalk plugin for dnf
Hi Spacewalk developers, I've committed and built first version of dnf-plugin-spacewalk a.k.a. spacewalk plugin for dnf package manager. So far it has couple of limitations: - it's python 2 only (because of up2date libs which are python 2 only), - it can list attached spacewalk channels and install / update packages from spacewalk - but it can't pick up actions scheduled on spacewalk server (i.e. it can't be invoked from rhn_check). Package is available in koji/nightly repos. Testing, comments and contributions are welcome. Regards, -- Michael Mráka Software Management Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] virtual machines hosted by oVirt are not recognized as virtualized
Patrick Hurrelmann wrote: % Hi all, % % registering a virtual machine that is hosted by oVirt in Spacewalk, does % not mark it as virtualized. The registered system will present itself as % physical machine. This worked some time ago, but that was when oVirt % presented itself as RHEV via smbios. Now oVirt uses its onw name in % smbios. Attached is a simple patch, that addresses this issue and makes % virtual machines hosted on oVirt register as virtualized again. Hi Patrick, Thank you for your patch. It's been reviewed and commited to master as 0480fc04d1e1b9bca0beb1ecb9aaa42797fa408f. If you decide to send another patch in future take an advantage of github pull requests described also on https://fedorahosted.org/spacewalk/wiki/PatchProcess. Thanks. -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] editarea and apache 2.4
Duncan Mac-Vicar P. wrote: % On 13/02/14 10:10, Michael Mraka wrote: % > Duncan Mac-Vicar P. wrote: % > Hello Duncan, % > % > Thanks for the patch. Currently we focus on Spacewalk 2.1 release so we will % > take a look on it after the release. % % Makes sense. % % I plan to push it for our release. If you see something totally wrong % with it, it would be nice to know now, even if it is not applied for % 2.1. I am fine with doing more corrections after the release but I would % like to avoid something completely different. Hello Duncan, I've commited ace editor changes to master. Regards, -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] Proxy should not make bogus fqdn:port DNS queries
Michele Baldessari wrote: % In proxy 5.6 in order to fix 1000586, we've added the following commit: % commit 4273986e4c1996c6c575a4cc4ca9d2c5587acf1c % Author: Stephen Herr % Date: Fri Aug 23 14:46:32 2013 -0400 % % 1000586 - /etc/hosts doesn't work with proxies % % It does a "socket.gethostbyname(req.headers_in['Host'])", but since RHEL 5 % clients over https send 'server.domain:443' host headers, we end up % doing lots of odd queries to the DNS servers (note the :443 at the end): % 22:12:00.733856 IP 172.16.11.11.49785 > 172.16.11.254.53: 60115+ A? satproxy.int.rhx:443.int.rhx. (46) % 22:12:00.734481 IP 172.16.11.254.53 > 172.16.11.11.49785: 60115 NXDomain* 0/1/0 (93) ... Hi Michele, I've committed your patch, thank you for your contribution. Since we have moved our git repo to github.com I'd like to ask you to make your future patches pull requests on github. Details are described in updated https://fedorahosted.org/spacewalk/wiki/PatchProcess. Thank you, -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH v2] Show server modified time with "rhncfg-client diff"
Michele Baldessari wrote:
% Currently when launching "rhncfg-client diff" it is not possible
% to figure out if the difference is due to a change on the server or
% on the client. This could be done via the /XMLRPC API (for example via
% configchannel.lookupFileInfo and looking at the 'modified' field) or
% via "rhncfg-manager diff", but both require adequate satellite credentials
% which in certain environments are not always available to the people
% needing this information.
...
Hello Michele,
Thanks for your contribution. I've reviewed the patch and here are my comments:
% +# try to set mtime and ctime of the file to
% +# the last modified time on the server
% +if file_struct.has_key('modified'):
% +xmlrpc_time = file_struct['modified']
% +modified = None
% +try:
% +# oracle backend: 20130304T23:19:17
% +modified = time.strptime(xmlrpc_time, '%Y%m%dT%H:%M:%S')
% +except:
% +pass
Try-except without a specified exception isn't good. It very easily
hides different errors than was originally intended.
% +try:
% +# postresql backend format: 2014-02-28 18:47:31.506953+01:00
% +modified = time.strptime(xmlrpc_time.split('.')[0],
'%Y-%m-%d %H:%M:%S')
% +except:
% +pass
If the first time.strptime() succeed it should not try to parse the value again.
% +
% +if not modified is None:
% +try:
% +epoch_time = time.mktime(modified)
% +os.utime(fullpath, (epoch_time, epoch_time))
% +except:
% +pass
What this try-except block tries to prevent? Is it really ok to silently skip
these errors?
% return fullpath, dirs_created
Well, I agree with the idea of the patch so I've fixed the issues above
and committed it.
Thanks.
--
Michael Mráka
Satellite Engineering, Red Hat
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] - 1072872 - spacewalk-repo-sync includepkgs/exclude directive from conf file
Neha Rawat wrote: % Hello Folks, % % Proposed patch to fix issue described in BZ 1072872. % Please share your feedback. % % Rgeards, % Neha Hi Neha, I've already commited your change. Thanks. -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] 1070866 - spacewalk-repo-sync fails in case both options --sync-kickstart and --url are specified.
% From b3be4347594e20a6833896057118b3e349eec1d9 Mon Sep 17 00:00:00 2001 % From: Dimitar Yordanov % Date: Thu, 27 Feb 2014 16:45:55 +0100 % Subject: [PATCH] 1070866 - sw-repo-sync fails to sync kickstart. % % --- % backend/satellite_tools/reposync.py | 4 +++- % backend/satellite_tools/spacewalk-repo-sync.sgml | 2 +- % 2 files changed, 4 insertions(+), 2 deletions(-) % % diff --git a/backend/satellite_tools/reposync.py b/backend/satellite_tools/reposync.py % index d336a88..983612e 100644 % --- a/backend/satellite_tools/reposync.py % +++ b/backend/satellite_tools/reposync.py % @@ -119,7 +119,9 @@ class RepoSync(object): % % if not self.no_errata: % self.import_updates(plugin, url) % -if self.sync_kickstart: % + % +# only for repos obtained from the DB % +if self.sync_kickstart and repo_label: Hi Dimi, I think ignoring --sync-kickstart when --url is used is not a good solution (even if it's stated in man page). Better solution would be to require repo_label to be set on command line in such case. ... % % -Attempt to create kickstartable tree (distribution) if there is subdirectory images/pxeboot/ under repo's URL. % +Attempt to create kickstartable tree (distribution) if there is subdirectory images/pxeboot/ under repo's URL. The option is ignored for repositories set from CLI via option [-u|--url]. % % % Regards, -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] 484950 - clear-db flag does'nt do whats it says it does in the --help
Dimitar Yordanov wrote:
% From fd33801c43e02396a6f9937d83fe5a1db801accf Mon Sep 17 00:00:00 2001
% From: Dimitar Yordanov
% Date: Tue, 4 Feb 2014 23:12:15 +0100
% Subject: [PATCH] 484950 - clear-db flag does not do what in --help
%
% ---
% spacewalk/setup/bin/spacewalk-setup | 2 ++
% 1 file changed, 2 insertions(+)
%
% diff --git a/spacewalk/setup/bin/spacewalk-setup
b/spacewalk/setup/bin/spacewalk-setup
% index 38a001b..61303d2 100755
% --- a/spacewalk/setup/bin/spacewalk-setup
% +++ b/spacewalk/setup/bin/spacewalk-setup
% @@ -50,6 +50,8 @@ my $product_name = $answers{'product_name'} || 'Spacewalk';
%
% $answers{hostname} ||= Sys::Hostname::hostname;
%
% +$opts{"skip-db-install"} = 1 if $opts{"clear-db"};
% +
% # Skip the logfile init, normally just used when called from install.pl,
% # which already did this.
% if (not $opts{"skip-logfile-init"}) {
% --
% 1.8.3.1
Applied. Thanks.
--
Michael Mráka
Satellite Engineering, Red Hat
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH]: 460556 - option clear-db missing in answer file
Dimitar Yordanov wrote:
% Hi all,
%
% I belief I have just come up with better patch.
%
% Dimi
% From d5726f1bd733f545ff9136b51f191572e3e371a6 Mon Sep 17 00:00:00 2001
% From: Dimitar Yordanov
% Date: Tue, 4 Feb 2014 22:44:22 +0100
% Subject: [PATCH] 460556 - option clear-db missing in answer file
%
% ---
% spacewalk/setup/bin/spacewalk-setup | 4
% 1 file changed, 4 insertions(+)
%
% diff --git a/spacewalk/setup/bin/spacewalk-setup
b/spacewalk/setup/bin/spacewalk-setup
% index 38a001b..0a7c09c 100755
% --- a/spacewalk/setup/bin/spacewalk-setup
% +++ b/spacewalk/setup/bin/spacewalk-setup
% @@ -50,6 +50,10 @@ my $product_name = $answers{'product_name'} || 'Spacewalk';
%
% $answers{hostname} ||= Sys::Hostname::hostname;
%
% +if ( not defined $opts{"clear-db"} and $answers{"clear-db"} =~ /Y/i ){
% +$opts{'clear-db'} = 1;
% +}
% +
% # Skip the logfile init, normally just used when called from install.pl,
% # which already did this.
% if (not $opts{"skip-logfile-init"}) {
% --
% 1.8.3.1
%
Hi Dimi,
Yes, this is better one :). Commited, Thanks.
--
Michael Mráka
Satellite Engineering, Red Hat
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Clean up embedded Oracle related code.
Hello Dimi,
Although your fix is correct I'm not going to apply this patch because
20 lines of 21 changed are just whitespace removal. Please make a clean
patch with only relevant change.
% From 53403e7eb5b1dbe158a39e32e6d7b360f66c19a0 Mon Sep 17 00:00:00 2001
% From: Dimitar Yordanov
% Date: Tue, 4 Feb 2014 15:25:49 +0100
% Subject: [PATCH] Clean up - embedded Oracle related code
%
% ---
% spacewalk/setup/lib/Spacewalk/Setup.pm | 41
+-
% 1 file changed, 20 insertions(+), 21 deletions(-)
%
% diff --git a/spacewalk/setup/lib/Spacewalk/Setup.pm
b/spacewalk/setup/lib/Spacewalk/Setup.pm
% index 32d3e74..62d3612 100644
% --- a/spacewalk/setup/lib/Spacewalk/Setup.pm
% +++ b/spacewalk/setup/lib/Spacewalk/Setup.pm
% @@ -36,7 +36,7 @@ our $VERSION = '1.1';
%
% use constant SHARED_DIR => "/usr/share/spacewalk/setup";
%
% -use constant POSTGRESQL_SCHEMA_FILE => File::Spec->catfile("/etc",
"sysconfig",
% +use constant POSTGRESQL_SCHEMA_FILE => File::Spec->catfile("/etc",
"sysconfig",
% 'rhn', 'postgres', 'main.sql');
%
% use constant POSTGRESQL_DEPLOY_FILE => File::Spec->catfile("/etc",
"sysconfig",
% @@ -376,23 +376,23 @@ sub upgrade_stop_services {
%
% my $spinning_callback_count;
% my @spinning_pattern = split /\n/,
Re: [Spacewalk-devel] [PATCH] fixing other python tests
Flavio Castelli wrote: % On 13/02/14 15:42, Flavio Castelli wrote: % >I just realized I forgot to push this small patch upstream. % % Here we go again, I forgot another patch :) % % Flavio Hello Flavio, Patches commited. Thanks. -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Query question regarding system.listLatestUpgradeablePackages
Jeremy D Davis wrote: % Any updates as to if we can get my latest patch that removes duplicate packages from the output into 2.1? Or should I submit a pull request in the new github? Hi Jeremy, I've applied you fix both to master and SPACEWALK-2.1. It took a bit long because we are busy with the release. % Kind regards, % Jeremy Davis % % -Original Message- % % Michael, % % I have two child channels that have the same package but different % checksum. Meaning we have cloudlinux rpms which use the same package % name, version, release and arch but a different checksum. So for % example % % bind-libs-9.8.2-0.23.rc1.el6_5.1.x86_64.rpm - Is in the updates % channel. This is a child channel from the base channel. % % bind-libs-9.8.2-0.23.rc1.el6_5.1.x86_64.rpm - Is in the cloudlinux % repo but different checksum than the one in updates channel. This is a % child channel of the CentOS base channel. % % So adding those two lines like I provided in the patch will resolve % this issue of displaying both packages as it restricts the search to % only the channels assigned to the server. Regards, -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Query question regarding system.listLatestUpgradeablePackages
Jeremy D Davis wrote: % Michael, % % I was able to get it working by manually changing the % rhnServerOutdatedPackages.sql to include the arch in the select and % then remove the table from Spacewalk and run the query. Once I got % that fixed I was able to test the queries you updated. It seem in my % environment system_upgradable_packages_list_no_errata_info pulled % duplicate packages due to a child channel contains these packages but % is not assigned to the server being checked. So I have created a % couple patches attached to this email that should resolve the issues % for me. I am still looking for a way that I can deploy this without % having to remove a table. Hello Jeremy, I've commited rhnServerOutdatedPackages.sql fix, thanks for correcting my mistake. As for duplicated package - I can't reproduce it. What's your setup? I have: server 389-ds-base-1.2.10.2-15.el6.x86_64 base channel389-ds-base-1.2.11.15-31.el6_5.x86_64 child channel 389-ds-base-1.2.11.15-31.el6_5.x86_64 server is subscribed to base channel and not to child channel and it gives me just one row. Even if I subscribe server to the child channel there still just one row. Regards, -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] Refeactored cookie parsing code to better handle malformed cookies
Michael Dorman wrote: % We recently discovered an issue where requests for any pxt page would % generate 500 errors. Traced it back to this submitted bug: % https://bugzilla.redhat.com/show_bug.cgi?id=723372 % % Apache2::Cookie->fetch dies if there is a malformed cookie sent by the % browser. In our case, it was a wildcard cookie, set by a different % site with the same domain name as our Spacewalk installation. So this % is not due to a bad cookie that Spacewalk itself is setting, but % rather the inability to deal with a malformed cookie set elsewhere. Hello Michael, I've actually already commited your patch but I have to revert it because it causes internal server error e.g. on /help/about.pxt. Regards, -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Query question regarding system.listLatestUpgradeablePackages
Jeremy D Davis wrote: % Attached you will find the patch as per the documentation % https://fedorahosted.org/spacewalk/wiki/GitGuide . Sorry about all the % emails and not following documentation. ... % Hello Spacewalk Developers, % % After asking the last question I decided to go ahead and make a change % of my own to see if I can improve performance. I was able to improve % the query by at least 6 seconds faster. The old query was taking about % 6101 ms to finish where I my query takes about 161 ms. Much % improvement. Please let me know if there is anything I need to change. % If everything looks good please let me know how I can get this added % for the next release of Spacewalk (Prefer 2.1). Hello Jeremy, Thank you for your patch. I've reviewed it and completely agree with you. Moreover looking into this query I found out some more places which can be optimized so I did even more complex rewrite of it. And there was also very similar query for list on UpgradableList.do page. Both changes are in 2a11191e20de5d0fa751f61fd59e82d903242238 so you can check it. Regards, -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] Date/Time picker
Duncan Mac-Vicar P. wrote: % Thanks for the review and fixes!. Most of it looks good except for the % self-closing tag as Silvio explained. % % There are other changes that I would like to understand: % % - The css part where you override some styles (and use !important, which % basically means SUSE Manager can't override it again in its css) They override stuff from datepicker/timepicker css. Because css files order they have to be forced with !important. % - setting of the input size to 15 To set length ratio of date and time input boxes. Otherwise they are equally long. Is there a better way to enforce it? Regards, -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] On picking a standard on HTML5 void tags
Silvio Moioli wrote: % > Is this your own personal opinion or the whole Spacewalk team official % > position? In particular, will future patches be rejected if they have % > those trailing slashes? % % Oops, typo there. I really meant: % % In particular, will future patches be rejected unless they have those % trailing slashes? Ahh, this version makes better sense ;). I'd say not rejected but you'll be most likely asked to make it consistent with the others. Regards, -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] On picking a standard on HTML5 void tags (was: Date/Time picker)
Silvio Moioli wrote: % On 02/17/2014 04:43 PM, Matej Kollar wrote: % > * standard allows closing of tags, % % Let me rephrase this: standard allows adding an optional trailing slash % to void elements, that by definition do not have end tags, as syntax % sugar[0]. % % Non-void elements must have a start and end tag - "closing" and % "self-closing" are not defined by the standard. % % So standard allows both adding and not adding, and IMO it's a matter of % choosing a coding convention. ... % Thread renamed to keep the two discussions separated. % % On the other hand, I would argue that: % % * those slashes are really superfluous; % * a good portion of Web projects outside Spacewalk are following the % same convention, among others Bootstrap itself[1] and HTML5 % Boilerplate[2], which is also used in Initializr[3] which in turn are % used in lots of projects. % % I do acknowledge that debate is ongoing[4] and there is no ultimate % agreement in the wider Web development community, so I do not want to % start and endless discussion here trying to solve that. % % So all I have is one last question: % % Is this your own personal opinion or the whole Spacewalk team official % position? In particular, will future patches be rejected if they have % those trailing slashes? Hi Silvio, Using self-closed tags for void elements as well as using end tags even in situations where they can be omitted in HTML5 is common agreement among whole team. They improve readability - you immediately know what was intentional and what a mistake. As for patch rejection - no, most likely the other way round :). Regards, -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Proper Twitter Bootstrap class
Bo Maryniuk wrote: % Hi! % % There is a little fix for this commit, which keeps the full form layout on % smaller screens: % https://git.fedorahosted.org/cgit/spacewalk.git/commit/?id=b7f023ff07b9944f9c34022a98768cafb317df70 Pushed to master. Thanks. -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] Date/Time picker
Duncan Mac-Vicar P. wrote:
% See attached patches.
%
% They fix
%
% - time localization
% - first day of the week
% - clicking on time picker
% - autoclose
% - move the libraries to separate package
Hello Duncan,
I've reviewed and committed date picker patches. Although I have some
objections I've decided to fix it rather then send it back and forth.
...
% +private String toPhpTimeFormat(String format) {
% +String ret = format.replaceAll("(a)+", "a");
% +ret = ret.replaceAll("(H)\\1+", "H");
% +ret = ret.replaceAll("(H)", "G");
This is wrong. It will replace HH with H and immediately H with G which
is most likely not what you meant.
% +// k (0-24) not supported, convert to the 0-23 format
% +ret = ret.replaceAll("(k)\\1+", "H");
% +ret = ret.replaceAll("(k)", "G");
% +// K (0-11) not supported, convert to the 1-12 format
% +ret = ret.replaceAll("(k)\\1+", "h");
% +ret = ret.replaceAll("(k)", "g");
This should likely be (K) not (k).
% +ret = ret.replaceAll("(h)\\1+", "h");
% +ret = ret.replaceAll("(h)", "g");
Again hh is replaced with h and immediately h with g.
% +ret = ret.replaceAll("(m)+", "i");
% +ret = ret.replaceAll("(s)+", "s");
...
% @@ -159,15 +192,18 @@ public class DateTimePickerTag extends TagSupport {
%
% HtmlTag dateAddon = createInputAddonTag("date", "fa fa-calendar");
For icons there's IconTag which ensures consistent usage of icons.
(So that one won't use fa-calendar while others use fa-calendar-o.)
...
% +/**
% + * Convert day java.util.Calendar constants
% + * (for which we can't assume a fixed value)
% + * to an index usable by the javascript picker.
% + *
% + * @return the equivalent index for the javascript
% + * picker
% + */
% +private int getJavascriptPickerDayIndex(int calIndex) throws
IllegalArgumentException {
% +switch (calIndex) {
% +case Calendar.SUNDAY:return 0;
% +case Calendar.MONDAY:return 1;
% +case Calendar.TUESDAY: return 2;
% +case Calendar.WEDNESDAY: return 3;
% +case Calendar.THURSDAY: return 4;
% +case Calendar.FRIDAY:return 5;
% +case Calendar.SATURDAY: return 6;
% +default: throw new IllegalArgumentException("Invalid day " +
calIndex);
% +}
% +}
I think such switch statement is really overkill. Yes, in theory
calendar constant values may change in the future but in fact they are pretty
solid for couple of years now.
...
% +private String toWeirdDateFormat(String format) {
% +String ret = format.replaceAll("(M)\\1\\1\\1+", "MM");
% +ret = ret.replaceAll("MMM", "M");
% +ret = ret.replaceAll("MM", "mm");
% +ret = ret.replaceAll("M", "m");
Exactly the same problem I described in toPhpTimeFormat().
is replaced by MM which is then replaced by mm.
MMM is replaced by M which is then replaced by m.
% +ret = ret.replaceAll("(E)\\1\\1\\1+", "DD");
% +ret = ret.replaceAll("E+", "D");
% +ret = ret.replaceAll("(D)\\1+", "dd");
% +ret = ret.replaceAll("D", "d");
And again to DD to dd.
% +ret = ret.replaceAll("(y)\\1\\1\\1+", "");
% +ret = ret.replaceAll("y+", "yy");
% +return ret;
% +}
And again.
% +private void writePickerHtml(Writer out) throws IOException {
...
% +HtmlTag timeAddon = createInputAddonTag("time", "fa fa-clock-o");
% +
% +HtmlTag timeInput = new HtmlTag("input");
% +//dateInput.setAttribute("value", data.getDate().toString());
% +timeInput.setAttribute("type", "text");
% +timeInput.setAttribute("class", "form-control");
% +timeInput.setAttribute("id", data.getName() +
"_timepicker_widget_input");
% +
% +HtmlTag tzAddon = new HtmlTag("span");
% +tzAddon.setAttribute("id", data.getName() + "_tz_input_addon");
% +tzAddon.setAttribute("class", "input-group-addon");
% +tzAddon.addBody(
% +data.getCalendar().getTimeZone().getDisplayName(
% +false, TimeZone.SHORT, data.getLocale()));
% +
% +HtmlTag col2 = new HtmlTag("div");
% +col2.setAttribute("class", "col-md-5");
% +
% +group.addBody(dateAddon);
% +group.addBody(dateInput);
% +if (!data.getDisableTime()) {
% +group.addBody(timeAddon);
% +group.addBody(timeInput);
% +group.addBody(tzAddon);
% +}
Whole timeAddon and timeInput should be better placed inside the if block.
So they aren't even generated when they aren't used later.
...
% +private void writeI18NMap(Writer out) throws IOException {
% +// generate i18n for the picker here
% +DateFormatSymbols syms = data.getDateFormatSymbols();
% +out.append("
Re: [Spacewalk-devel] Things that needs to be dobne before next release.
Silvio Moioli wrote: % On 01/09/2014 01:26 PM, Matej Kollar wrote: % > Major things that we currently consider release blockers for 2.1 % > from UI point of view are: % > [...] % > * Bare-metal systems management % Hello Silvio, % May I ask what's the status of that? Is it still planned for 2.1? Unfortunately no, we hadn't enough time to go through it. So it's been postponed after 2.1. % More importantly, is there something that prevents merging? We can help % in that case. % % >From our side, we just added custom icons and I am planning to display % some more relevant data in the Bare-metal System List page in the next % weeks. Regards, -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] editarea and apache 2.4
Duncan Mac-Vicar P. wrote: % > Sorry guys, I did see this but then promptly forgot about it. % > % > We may need to replace EditArea anyway as the project appears to have % > been abandoned. My emails to the dev have not been returned and there % > is virtually no activity on the EditArea SF site. % > % % Attached is a patch that changes the editor to the ACE editor. Hello Duncan, Thanks for the patch. Currently we focus on Spacewalk 2.1 release so we will take a look on it after the release. Regards, -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] Date/Time picker
Duncan Mac-Vicar P. wrote: % > Usability glitches: % > - date changes correctly accroding to localization but time is always % > 12 hour a.m./p.m. in any localization % I left this because it was like that in the current date picker. I will % improve this, but I have to first make sure the date picker object (Java % part) support this (if needed at all). Well, either don't bother with localization at all or make it complete. Half done things are annoying. % > - week starts on Sunday in all localizations % Fixed, I will include it in an updated patch. Thanks. % > - clicking on calendar icon pops-up date picker but clicking on clock % > icon doesn't pop-up time picker % Fixed by updating the library Thanks. % > - calendar pops above picker, time pulls down % We could enforce this, but in general the direction is calculated on % available space, I guess this happens because the picker is at the end % of the page. Enforcing may have some nasty side-effects Nope, there's plenty of space both above and bellow the picker. IMHO "auto-bottom" option opens it bellow the picker by default. % > - if I click for the first time to date calendar doesn't highlight % > currently selected date (it highlights always today) % The start date is today, and the calendar highlights today and the % selected date in different colors. % So I am not sure I understand what is the problem here. E.g in monitoring probe there's picker which is set some time in the future (or in the past). When I click it shows calendar with highlighted "today" not the date from the picker. % > - calendar should close when I click chosen date (or at least at % > doubleclick) % Fixed, will go in next patch. Thanks. % > Implementation: % > - What are fn.datepicker.dates arrays needed for? It looks like a kind % > of localization but AFAIK bootstrap datepicker cares about % > localization itself (language option). % That way instead of using the built-in locale files from javascript I % generate % the localization from the Java strings (Calendar). That way we don't % have to include the localization .js files and to track them for % translation. Well, I'd prefer including static javascript to generating it over and over with every picker. Even those static localization js can be generated automatically in rpm build time (from the same sources you generate it now). Anyway I'm not pushing for it. % > - bootstrap-datepicker / jquery.timepicker css and js should not be in % > branding or web but in a separate package which is required by branding. % > - What's the benefit of combining bootstrap datepicker with jquery % > timepicker over some bootstrap datetimepicker ([1], [2]) which does % > both? % % We tried different combinations of pickers. We all kind of agreed that % the combination of these two give you something very similar to the % Facebook picker which is a very good balance between easy and convenient % with the keyboard (you can still use it) from all the ones we tried. % Cynthia, our UX developer also agreed. So I would say we optimized more % the user experience than the packaging or the code. I agree with user experience on the other hand this combination, for me, isn't good experience. They are two different libs / different styles. There's visible difference between date picker - pop up window - and time picker - "classic" pull down menu. % bootstrap-datetimepicker is also an external library, combining two % pickers in one, but the date picker is not very nice. You can try it % yourself and you will see what I am talking about :-), also I suspect % Facebook also experimented a lot with their picker already. The second % one you linked is a bit better, though it forces you to go through the 3 % steps. I've tried [1]. I didn't liked it at the beginning but after some time I found it in fact quite good. You can set the time with a precision of seconds in just 3 clicks (try clicking on second number). Yes, it's a bit uglier on the other hand both date and time part has consistent look and feel. The [2] is also more consistent, looks IMHO a bit better then [1], and allows to set time with 5 min precision. % Duncan Regards, -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] 870990 - "spacewalk-remove-channel -l" can not be used when satellite-sync is running.
Dimitar Yordanov wrote: % -- % Dimitar Yordanov % Systems Management QA % #satellite-qa % From d4290838141676727db093499230e5b642c25c80 Mon Sep 17 00:00:00 2001 % From: Dimitar Yordanov % Date: Wed, 5 Feb 2014 15:48:56 +0100 % Subject: [PATCH] 870990 - sw-rm-ch -l when satellite-sync runs. Hi Dimitar, Looks good, applied. Thanks. -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] SUSE Studio API will stop working via unencrypted HTTP
Johannes Renner wrote: % On 01/22/2014 12:18 PM, Johannes Renner wrote: % >Hello, % > % >The SUSE Studio API will no longer process requests via unencrypted HTTP after % >Jan 2014, see here: % > % >http://blog.susestudio.com/2013/12/coming-soon-https-only-on-suse-studio.html % > % >Therefore attached is a patch to change the default endpoint to use SSL. % % Following up on this issue, here is two more related patches: One is to update % the specfile in spec-tree in order to build a more recent version of the client % library and another one to make the spacewalk code compile against that version. % % Note that the integration part will work with the old lib as well since we don't % use the default endpoint that comes with the library, but we rather set it from % within spacewalk. I would still recommend to update the library anyways. Hello Johannes, I've applied your patches. Thanks. % Thanks and regards, % Johannes -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] Adding a password placeholder check when editing a user.
Maximilian Meister wrote: % Hi Michael, % % i changed the patch. So no additional javascript. % % * I replaced the struts tag with the standard html input tag to use % the placeholder attribute % * Some changes to the logic in % spacewalk-pwstrength-handler.js:updateTickIcon() % * Johannes Renner helped me with the Java code changes. Hi Maximilian, thanks for the patch update. I've applied to master. % The question is now in UserEditActionHelper:62 we use more or less % the same code for validation as in UpdateUserCommand:132 % As this is a small redundancy in code, I wanted to ask if it would % make sense to put that code into % a public function accessible by both classes, and where this % function should reside. % Do you think it is worth the extra work, or is the solution in the % patch acceptable? I see. Yes, in a perfect world we should, of course :), somehow reuse the validation code from UpdateUserCommand in UserEditActionHelper but I'm not sure whether it's worth the effort. % Maximilian Regards, -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Action Chain XML-RPC API
Bo Maryniuk wrote: % On Tue, Feb 04, 2014 at 01:22:40PM +0100, Michael Mraka wrote: % > That's correct. But then you have to use NEVRA+checksum which is more % > complicated than simple id. % % Do you actually need the checksum, as long as you know the channel name? NEVRA+channel name is still more complicated than simple id. Moreover it's volatile (someone can remove package from the channel) while id is immutable. Regards, -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Action Chain XML-RPC API
Bo Maryniuk wrote: % > It's not uncommon to have the same machine registered with Spacewalk multiple % > times and use the same profile name / hostname / IP address for all these % > registrations. "myfantasticserver" simply won't be enough to uniquely identify % > the desired server -- only server id will be. % > % > Similarly, it's perfectly OK to have two packages with the same NEVRA pushed % > into one organization (for example RHEL + CentOS). In these situations, your % > concept would not be able to realiably identify desired packages -- only % > package id would be. % % But I would expect two packages would either have different checksum and/or in % different channels? That's correct. But then you have to use NEVRA+checksum which is more complicated than simple id. % > While I understand that the thought of operating with human-compatible data % > seems appealing, I'm afraid it won't work with API, where we need to model % > functions in an orthogonal manner -- i.e. one function will give you system % > id(s), another one will give you package id(s) and a third one will take these % > two ids and instruct a specific chain to remove packages from a specific % > system. % % This are three calls. Fine with the software, like we've built for Android % for example, but quite bad if this is your admin script. Why is it quite bad? What's the vital difference? % Leaving the "by ID" still available, isn't it better to have a convenience % layer by name? It isn't unique. You may extend names with _something_ to make it unique but then you've just created more complicated id. Regards, -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] Date/Time picker
Duncan Mac-Vicar P. wrote: % On 04/02/14 00:04, Duncan Mac-Vicar P. wrote: % > Here is the latest patch for the date picker. Feedback welcome! % > % % I just realized the patch above contains a javascript file that is not % used (a picker implementation used in the first experiments). Here are % the patches with that file removed. Hello Duncan, New date picker looks much better than current one nevertheless I have couple of comments. Usability glitches: - date changes correctly accroding to localization but time is always 12 hour a.m./p.m. in any localization - week starts on Sunday in all localizations - clicking on calendar icon pops-up date picker but clicking on clock icon doesn't pop-up time picker - calendar pops above picker, time pulls down - if I click for the first time to date calendar doesn't highlight currently selected date (it highlights always today) - calendar should close when I click choosen date (or at least at doubleclick) Implementation: - What are fn.datepicker.dates arrays needed for? It looks like a kind of localization but AFAIK bootstrap datepicker cares about localization itself (language option). - bootstrap-datepicker / jquery.timepicker css and js should not be in branding or web but in a separate package which is required by branding. - What's the benefit of combining bootstrap datepicker with jquery timepicker over some bootstrap datetimepicker ([1], [2]) which does both? Regards, -- Michael Mráka Satellite Engineering, Red Hat [1] http://tarruda.github.io/bootstrap-datetimepicker/ [2] http://www.malot.fr/bootstrap-datetimepicker/ ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Patch: 1058431-sw-remove-channel-does-not-rm-ks-trees
Tomas Lestach wrote: % What if I created a custom distribution that reuses the kickstart trees of rhel-i386-server-5 (according to the BZ)? % % Does my kickstart distribution stays unusable after deleting the channel? Hi Tomas, Thanks for pointing it out. I've modified code so files are deleted only if no other kickstart tree points to them. % > % Hi all, % > % % > %I tried to fix the problem described in bz1058431 - % > Spacewalk-remove-channel does not remove the kickstart trees. % > %You can find my patch enclosed. % > % > Hi Dimi, % > % > Thanks for your patch. I've reviewed and commited it. Actually I've % > splitted the change into two commits - trailing whitespace removal % > and % > the change itself - so it's clear which code really changed. Regards, -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Patch: 1058431-sw-remove-channel-does-not-rm-ks-trees
Dimitar Yordanov wrote: % Hi all, % %I tried to fix the problem described in bz1058431 - Spacewalk-remove-channel does not remove the kickstart trees. %You can find my patch enclosed. Hi Dimi, Thanks for your patch. I've reviewed and commited it. Actually I've splitted the change into two commits - trailing whitespace removal and the change itself - so it's clear which code really changed. Regards, -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] Adding a password placeholder check when editing a user.
Maximilian Meister wrote: % On 01/29/2014 01:19 PM, Maximilian Meister wrote: % > % >Hi Michael, % > % >I have tried this in my first attempt, but the html:password % >struts tag doesn't accept the attribute "placeholder="**". % % to reformulate my statement a bit, the html:password struts tag % doesn't know any placeholder attribute. ... I see :(, I was not aware of it. Anyway I'd still prefer not to use javascript if not necessary. So in this particular case I'd replace html:password with direct html input tag: Regards, -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] Adding a password placeholder check when editing a user.
Maximilian Meister wrote:
% Hi,
%
% after the password strength meter went through, I have another enhancement
% related to the password field.
% On the edit user page, there are placeholders in the password fields.
% The placeholders are plain *'s, so if I add some characters after
% the placeholder
% like [**] my new password will contain the placeholder
% instead
% of my expectation [].
% That could lead to locking out of a user.
%
% This patch makes sure that you can't lock yourself out accidentally
% like this.
Hello Maximilian,
I think there's an easier way to do it in a plain html without new
javascript file. If you replace
with
(similar to e.g. search field on the page) there will be greyed out dots
and user have to type whole password and can't submit placeholder string
anymore. ('•' is unicode BULLET char U+2022.) Well, there's one more
step needed - UserEditActionHelper class have to be updated to accept empty
password as no change in password.
What do you think about this?
Regards,
--
Michael Mráka
Satellite Engineering, Red Hat
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [RFC] showing timestamps in Spacewalk
Duncan Mac-Vicar P. wrote: % % Attached is the first iteration of this patch. % % It includes: % % - Transformation logic moved to js so that it can be shared with perl % or easily disabled (disabled not implemented yet) % - A rhn:formatDate % -> allows to format in both moment.js fromXX/fromNow/calendar styles % -> automatic locale configuration if used from jsp % -> usage of time HTML5 tag % -> uses the standard user format for the date in the popup, or in case the % humanizing does not occur. % - A perl rhn-date tag: % -> allows to format in both moment.js fromXX/fromNow/calendar styles % -> usage of time HTML5 tag % -> uses the standard user format for the date in the popup, or in case the % humanizing does not occur. % - An improved is_date option for List columns in perl that allow to set % the human style % % Additionally, a momentjs package is required, which I made available here: % https://build.opensuse.org/package/show/home:dmacvicar:spacewalk/momentjs % % In the next iteration I would like to improve: % - in the Java code, may be split the momentjs locales in different files % - Implement disable % % But I think this iteration is good enough to be committed. Hi Duncan, I've commited this part of timestamp changes with an exception of moment-with-langs.min.js file. It isn't referenced from pages (moment.min.js is), moreover it should not be in spacewalk-web but a separate package. Should there be already some dates translated to "human readable" string on pxt pages? Even if I download moment.min.js to my spacewalk I can't see any. I see date wrapped with but no translation (e.g. on /network/systems/details/history/pending.pxt). Regards, -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Action chaining - new js files
Hello Silvio, I noticed there are new javascript files in master-action-chaining branch. Last week I've finaly cleaned up branding and web packages from third party stuff (bootstrap, font-awesome, roboto) and put it into separate packages. I'd like to ask you also put it into independent packages. It helps us to keep our code sparated from others work, track where it comes from, what's its license etc. Thanks, -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Action chaining - table names
Hi Silvio, I've come across commit 8844fcb10460d7d9838e89e376e09e7b1539b3fe which adds new tables for action chaining feature. I noticed all table/trigger/constraint names have 'suse' prefix. I guess I understand why you named it that way :). Anyway majority of tables have rhn prefix but it isn't because they were created by Red Hat engineers rather then just a legacy prefix from old days when Satellite was born as Red Hat Network (and many years later opensourced as Spacewalk project). So we continue to use rhn prefix even if the project is called differently nowadays because renaming of all tables is just not worth of it. To sum it up - I'd like new tables to continue with old rhn prefix naming. Thanks, -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] Adding a password strength meter to spacewalk
Maximilian Meister wrote: % >Is it possible to keep original pwstrength-bootstrap*.js unmodified and % >put modification to the separate .js (call modified functions from the % >page and call original functions from them)? % % Hi Michael, % % I end up with 2 separate .js files now. % First one is the original sources, packaged and patched through the % spec file in spec-tree. % Second one is a caller .js with the document.ready handler and some % custom functions. Hi Maximilian, that sounds great. % Question is now do I need to package the second .js as well? Or can % i simply add it to the git tree % in web/html/javascript? If it's spacewalk specific (I think so) then just put it to web/html/javascript next to other spacewalk-*.js. Regards, -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH]es ISE fix and UI unification, phase 1
Bo Maryniuk wrote: % Hi! % % While doing UI unification (attached here one more time again, since I didn't % see it went to the mailing list archives for some odd reasons), I also % accidentally step on the ISE, which happens if Cobbler is not installed (at % least properly). % % Here are those two patches, please review. :) Hello Bo, I've commited cobbler issue fix. As for UI unification I've already reviewed it and answered in the previous email. Thanks. Regards, -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Action scheduling on ported pages
Bo Maryniuk wrote:
% On Wed, Jan 08, 2014 at 01:12:06PM +0100, Michael Mraka wrote:
% > % > Could be. But it doesn't answer my questions. I'm asking for timeframe
% > % > because this is one of the blockers for Spacewalk 2.1 release and we
% > % > have to decide whether wait for it or not.
% > %
% > % OK, that sounds reasonable. Then I will make some more patches that will
% > % synchronize the rest of the pages with the current Date picker. Then we
will
% > % introduce the new Date picker (as a tag, so it will instantly replace
% > % everything). Fair enough?
% >
% > Yes, that will solve it.
%
% Michael,
% what is the status here reviewing it, please?
Hello Bo,
I'm sorry it took me very long to review it. It looks good, just two notes:
- SSM/Configuration/Enable: The message 'You may schedule rhncfg* package...'
should stay above the date picker as it was originally.
- The original text before the date picker ('You may schedule the package
installations to take place as soon as possible, or no sooner than a
specified time') suggests that the action might not take place immediately
while with new wording 'Schedule at' users would expect the action is going
to happen right after confirmation. I'd prefer something with
similar meaning to the original.
Regards,
--
Michael Mráka
Satellite Engineering, Red Hat
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] Added extra log folder to spacewalk-debug
Flavio Castelli wrote: % Add extra log folder /var/log/rhn/tasko/sat/ in spacewalk-debug. Hi Flavio, patch commited into master as 8793925a10d2e482669c0e6104197737fad0cad8. Thanks. -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCHES] More work on the python tests
Flavio Castelli wrote: % These commits bring back to life 39 python tests which have been left % unmaintained for quite a long time. % % While fixing and improving the tests I also took the chance to move some of them % to better locations. I tried to be consistent with what has been done in other % parts of the code base. % % All the tests are passing except for the `test_server_registration` which has % 2 errors and 2 failures. I tried hard to fix these issues but I didn't succeed % and now I feel a bit stuck. % % I hope you like these changes and I also hope you will find a solution for the % 3 remaining broken tests. Hello Flavio, Great job. Thank you for fixing the tests. I've reviewed and committed them to master. % Cheers % Flavio Regards, -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Fwd: [Bug 1033062] New: License of spacewalk-branding needs to be changed
Milan Zázrivec wrote: % > Tomas and others, % > Any concerns? % > % > Thanks, % > Cliff % > Original Message % > Subject: [Bug 1033062] New: License of spacewalk-branding needs to be % > changed % > % > https://bugzilla.redhat.com/show_bug.cgi?id=1033062 % > % > Description of problem: % > % > The license of the spacewalk-branding package needs to be changed since from % > now on the following css frameworks, fonts and icons will be included with % > the % > package: % > % > - Twitter Bootstrap (Apache-2.0) % > - Font Awesome (MIT and OFL-1.1) % > - Roboto Font (Apache-2.0) % > % > Given our own GPL-2.0 sources we would probably end up with an aggregate: % > % > "Apache-2.0 and GPL-2.0 and MIT and OFL-1.1" ... % % Is this report still valid? Does it need to be addressed? I've moved all Twitter Bootstrap, Font Awesome and Roboto Font to separate packages so this is no more valid problem ;). I've updated bugzilla accordingly. -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCHES] CVE-ID changing syntax in 2014
Michael Calmer wrote: % Hi, % % I think you already heard from the fact, that mitre.org change the syntax of % CVE IDs with the beginning of 2014. % % https://cve.mitre.org/cve/identifiers/syntaxchange.html % % Currently there are 4 digits at the end which can be in future more. % % In spacewalk DB, the name column in rhnCVE is limited to 13 characters which % is not enough in the future. % % I have attached 3 patches which increase the size to 20 which will hopefully % enough for a long time. % % I hope I catched all places where the old format is expected. Hello Michael, Thanks for the patch. It's been reviewed and applied to master. Regards, -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Patch fixing paths in Perl code
Paul Robert Marino wrote: % I found the fix for https://bugzilla.redhat.com/show_bug.cgi?id=1053787 % its in the same file % patch attached which stacks on top of my previous patch to fix the % links in the pages effected. Thanks. Commited as 333515fb46ee77ea6f25acc994904e01b0b4e78d. -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Patch fixing paths in Perl code
Paul Robert Marino wrote:
% I found a bug in some of the perl pages where there was a link to
%
% /network/systems/details/probes/index.pxt?sid=${sid} instad of the new path to
%
% /rhn/systems/details/probes/ProbesList.do?sid=${sid}
%
% I tracked it down to one of the modules and corrected the path this is
% related to but not the actual fix for
% https://bugzilla.redhat.com/show_bug.cgi?id=1053787
Thanks for the fix. Commited as ae9eb7e9ee2ad196248df250d02109901c579cb4.
--
Michael Mráka
Satellite Engineering, Red Hat
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] less.js "development mode" broken
Duncan Mac-Vicar P. wrote: % Hi % % As the .less files where moved to /usr/share/bootstrap/less and used % only to compile spacewalk.less, in development mode the bootstrap.less % files are not accessible from the web. % % One could alias only bootstrap.less but this one include more files. I % suggest: % - Reverting 4fa8df9431dedbe4ada0c072697a5bd1a4ef5427 % +@import url(bootstrap/less/bootstrap.less); % -@import url(bootstrap.less); Ok, I've changed the path back for you. % Adding to bootstrap a /etc/httpd/conf.d/bootstrap.conf % % alias /bootstrap /usr/share/bootstrap % = 2.4> % % Require all granted % % % % or just to bootstrap-less /etc/httpd/conf.d/bootstrap-less.conf % % alias /bootstrap/less /usr/share/bootstrap/less % = 2.4> % % Require all granted % % % % Changing the branding package so that lessc is called with the right % include path, I think in this case it would be just /usr/share. I've added bootstrap-less.conf to bootstrap-less and also updated koji configuration so bootstrap-less will be in spacewalk-nightly repo. Regards, -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] perl List port to new css/markup
Duncan Mac-Vicar P. wrote: % > Attached patch with all mentioned issues corrected. % % Now attached for real. This one works fine, I've commited it as 02a0a6549b97a7851a52e4a262f1704548545a83. Thanks, -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Ubuntu Sync Script
Hello Martin, % I have created a bash script for syncing Ubuntu Channels to SpaceWalk.. % % The script has been written to resemble the "satellite-sync" and "mgr-ncc-sync" on Red Hat Satellite and SuSE Manager.. % % The script is definitely NOT perfect, and could do with a rewrite in python/perl.. But it works, and thats the main reason I'm releasing it... Your sync script looks good. If you really think about rewriting it into python I'd point you to spacewalk-repo-sync command. It is currently able to download packages only from yum repos but you can extend it with new repo plugin (see ./backend/satellite_tools/repo_plugins in spacewalk.git). So you have to write code only for fetching package list and packages itself and rest of the infrastructure is already there. Regards, -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] Adding a password strength meter to spacewalk
Maximilian Meister wrote: % >I see. Then it should keep the original name so we can easily figure out % >where it came from and replace it with newer version in the future. % % Hi Michael, % % the original name would be pwstrength.js (in 0.5.0). We decided to % use the spacewalk- prefix to distinguish it for all JavaScript % related to the password strength meter in one single file. % % >Which version of jquery.pwstrength.bootstrap was it? It doesn't match to % >any pwstrength-bootstrap-1.0.X.js. % % 0.5.0 As it's new feature in spacewalk I'd vote for using current latest version of pwstrength-bootstrap. % >Is it possible to keep original pwstrength-bootstrap*.js unmodified and % >put modification to the separate .js (call modified functions from the % >page and call original functions from them)? % % To keep the pwstrength.js library itself separate for easier update % on a new version makes sense but has a few issues. % I needed to change the library itself to make it work and look good % for spacewalk. % I had to change/add some generated html output (html tags, add css % classes), some logic and css selectors. % These are changes only make sense for spacewalk specific look and % functionality. I understand it. In such cases where we need to modify upstream sources we put upstream package spec to spec-tree/ and create patches to it. This let's us easily keep our modifications and re-apply it on new upstream versions whenever wee need. See e.g. spec-tree/stringtree-json in spacewalk.git. % Furthermore in 1.0.2 the pwstrength.js is now separated into 4 % different js files. Isn't https://github.com/ablanco/jquery.pwstrength.bootstrap/blob/master/dist/pwstrength-bootstrap-1.0.2.js all we need to distribute? Regards, -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Action scheduling on ported pages
% > Could be. But it doesn't answer my questions. I'm asking for timeframe % > because this is one of the blockers for Spacewalk 2.1 release and we % > have to decide whether wait for it or not. % % OK, that sounds reasonable. Then I will make some more patches that will % synchronize the rest of the pages with the current Date picker. Then we will % introduce the new Date picker (as a tag, so it will instantly replace % everything). Fair enough? Yes, that will solve it. Regards, -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Action scheduling on ported pages
Hello Bo, % > but until it's done % > (consistently across all the pages) you should keep the old style. % % Then why to make the efforts tripple times? Let's sync it with the rest of the % pages instead? You already agreed that the current way is not simple and, in % fact, duplicates the functionality. There should be always only one date % input, set to now by default. How you can possibly get confused with this? As you wrote previously you postponed finishing the changes. Are you working on it again or not? If yes go ahead, if not please make it compatible with other pages. % Otherwise it is the same as you would say "It is possible to port Perl to % Java, but until it is done, let's continue invest in Perl code". :-/ I strongly disagree. It is the same as I'd say "Port Perl to Java but always keep interface compatible regardless which technology it's based on". % > This is also possible and again until it's done you should keep % > consistency with old pages. % % Please see above. This is why you call them "old". :) % % > % The feature was a bit postponed since we had first to get TB3 working. :-) Now % > % it is there, so new UI is coming, of course. % > % % > % > Could please take a look and update the pages so they follow original % > % > workflow? % > % > By 'the feature' you mean new date picker or pop-up confirmation stuff? % > Do you have a timeframe for their implementation? % % Of course. And we already did that here, BTW. Looks super-awesome and you will % *love* it. :) Could be. But it doesn't answer my questions. I'm asking for timeframe because this is one of the blockers for Spacewalk 2.1 release and we have to decide whether wait for it or not. % And this is also why we kept the old way JSPs in "under-done" state in % previous code only because we yet had no Twitter Bootstrap there. Adding 3rd % party JavaScript libraries would be also a big mistake. The "old things" are % anyway will die. And this is also why we had started Twitter Bootstrap in % general: to have simpler, better, more responsive UI, yet standardized. So % again, I honestly see no reasons to continue the old way duplicating the % efforts, especially if we already have modern way. Regards, -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] Adding a password strength meter to spacewalk
Johannes Renner wrote: % On 01/07/2014 10:54 AM, Michael Mraka wrote: % > Maximilian Meister wrote: % > % Hi everybody, % > % ... % > % > Hello Maximilian, % > % > Is the spacewalk-pwstrength.js a copy of jquery.pwstrength.bootstrap % > (i.e. third party stuff) or your own implementation of it? % % Currently it's basically a copy of third party code (with AFAIK some custom % modifications he made) plus a "$(document).ready()" handler so that there is % eventually only one single javascript file being referenced from the markup. I see. Then it should keep the original name so we can easily figure out where it came from and replace it with newer version in the future. Which version of jquery.pwstrength.bootstrap was it? It doesn't match to any pwstrength-bootstrap-1.0.X.js. Is it possible to keep original pwstrength-bootstrap*.js unmodified and put modification to the separate .js (call modified functions from the page and call original functions from them)? Regards, -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Action scheduling on ported pages
% > First of them: the original schedule date picker on contains two choices % > - Schedule action as soon as possible % > - Schedule action for no sooner than: % > while new contains only % > - Schedule action for no sooner than % % Because it is the same thing: "as soon as possible" is basically now, which is % already defined in the date picker. There is no need to duplicate the same % thing twice. % % > Although we may discuss which one is better and whether it's worth of % > changing it, for now I'd primarily prefer to keep it consistent across % > all the pages. % % Actually, we were discussing to removing the option "as soon as possible" from % other pages to keep it consistent. :-) Yes, it's possible to simplify date picker on other pages but until it's done (consistently across all the pages) you should keep the old style. % > The second and IMHO major issue is - the original page (and all other pages) % > implement "two phase" confirmation. % % The confirmation won't be any longer a bulky separate JSP page with all the % hassle involved, but a little neat Twitter Bootstrap-based modal pop-up % instead. This is also possible and again until it's done you should keep consistency with old pages. % The feature was a bit postponed since we had first to get TB3 working. :-) Now % it is there, so new UI is coming, of course. % % > Could please take a look and update the pages so they follow original % > workflow? By 'the feature' you mean new date picker or pop-up confirmation stuff? Do you have a timeframe for their implementation? Regards, -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] Adding a password strength meter to spacewalk
Maximilian Meister wrote: % Hi everybody, % % this patch would add a bootstrapified password strength meter to all % pages where % user details are being created or edited (create the initial admin user, % create/edit normal users and create organization). % There is also a tick icon on the side of the password input fields, % which checks if % the value in the desired password field will be accepted by the % server and if the % value in the confirm password field matches the value in the desired % password field. % % We had this implemented in SUSE Manager before, and now completely % reworked it. % It would be useful due to spacewalk being a systems administrations % tool and % due to the security implications that come with it. % % It is based on https://github.com/ablanco/jquery.pwstrength.bootstrap % where I also contributed to during the process. Hello Maximilian, Is the spacewalk-pwstrength.js a copy of jquery.pwstrength.bootstrap (i.e. third party stuff) or your own implementation of it? As for visual appearance - the strength meter box has sharp corners while other boxes on the page have rounded corners. Also vertical space between Password and Confirm Password is much larger than other spaces. BTW would it be possible to put the strength meter to the background of Password input box (similar to the http://www.jqueryscript.net/demo/Simple-jQuery-Password-Strength-Indicator-Plugin-passMeter/)? The current strength box looks a bit misaligned with the rest of the page... or at least I'd prefer to prepend a label (e.g. Password strength) to the box (similar to http://cdn1.freshdesignweb.com/wp-content/uploads/2011/09/jquery-password-strength-meter-005.jpg) so it aligns well with the other inputs. Regards, -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] RFC: manage bare-metal systems from Spacewalk
Michael Calmer wrote: % Hi, % ... % > how does registration from this bootstrap image differs from the % > situation when I create standard kickstart with minimal set of packages % > to register the system to my org and boot the system from this kickstart? % % Not too much. % % * we use now also rhnreg_ks with a special activation key which give you a % bootstrap entitlementen and no base channel is assigned. % * bootstrap entitlements are "free" (2 per org) % this is not so important for spacewalk, but for SUSE Manager and Satellite % where you have to pay for management entitlements So do we need entitle such system at all? Nowadays there can be unetitled system in spacewalk. Does bootstrap entitlement brings us something more than current unetitled system? % * directly after registration it does a shutdown That's a feature of the boot image, right? So I could achieve the same with 'poweroff' in post install kickstart script. % * nothing is installed on the harddisk, the image exists only in RAM % - this give you the possibility to see the host in spacewalk and assign % the final kickstart profile to this host. If you turn this host on again % it boots again via PXE and install the correct profile. % If you use a re-registration key, the history will stay. Yes, we can't create such boot image in satellite right now. So I'd have to create external distribution with memory only image and import it to satellite. Then I'd have to create an activation key which asigns no base channel and no entitlements to systems. And I'd also have to manage kickstart based on this distribution + activation key to be the default pxe image. Is it all I need? Just trying to figure out whether we can't achieve the same goal somehow easier with the current code... Regards, -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Action scheduling on ported pages
Hello Bo, recently come across two pages - SSM > Errata (/rhn/systems/ssm/ListPatches.do) and SSM > Misc > Reboot (/rhn/systems/ssm/misc/RebootSystem.do) - which you've converted from pxt to java. Both pages works fine but there're small yet important differences between them and the other action scheduling pages. First of them: the original schedule date picker on contains two choices - Schedule action as soon as possible - Schedule action for no sooner than: while new contains only - Schedule action for no sooner than Although we may discuss which one is better and whether it's worth of changing it, for now I'd primarily prefer to keep it consistent across all the pages. The second and IMHO major issue is - the original page (and all other pages) implement "two phase" confirmation. I mean e.g. on > Software > Packages > List / Remove (/rhn/systems/details/packages/PackageList.do) you can select packages and click "Remove" which gets you to a confirmation page (/rhn/systems/details/packages/RemoveConfirm.do) where you can pick the date and click "Confirm". The new pages have date picker and "Apply" right on them and there's no "Confirm" page. Which is, again, inconsistent with the other pages and it removes the _emergency cord_ which is dangerous especially for actions that can't be undone (like reboot systems). Could please take a look and update the pages so they follow original workflow? Thanks a lot, -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] Fix the Java package of DeleteGroupAction class
Johannes Renner wrote: % Hello, % % here is another micropatch fixing up a recent commit in master. The Java % package needs to correspond with the filesystem path in any case. Oops :). Good catch. Tomas fixed it moment ago in 267da66a286824299ae8cf61dda7c6793660339a. Thanks, -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] RFC: manage bare-metal systems from Spacewalk
Silvio Moioli wrote: % Dear Spacewalk Team, % % as announced, this is the second part of the contribution we wanted to % share with you. Actually it is again split in two sub-parts which are % largely independent from one another and from the power management % feature I wrote about yesterday - git commits are stacked over previous % ones mostly for convenience reasons. ... % Second is support to list bare-metal systems in Spacewalk and provision % them. This is the basic workflow: % - admin enables this feature from Spacewalk Configuration -> Bare-metal % systems. This results in a new default Cobbler profile being created; % - bare-metal system is powered on, and gets the default (hereinafter % "bootstrap") image from Cobbler. This is a special, minimal OS that will % boot, register the system with a special "bootstrap" activation key and % shut the system down; % - admin will happily see its system in the Systems list with a special % icon and slightly different pages (basically, to hide a lot of actions % which would not make sense). Bare-metal systems have a special % entitlement which gets assigned with the bootstrap activation key only; % - provisioning works as usual with Kickstart by creating Cobbler % records (obviously scheduled provisioning is not supported). Admin can % also use the new feature above to provision multiple bare-metal systems; % - admin can also use the power management feature to power on his % system and begin the kickstart process. Hi Silvio, how does registration from this bootstrap image differs from the situation when I create standard kickstart with minimal set of packages to register the system to my org and boot the system from this kickstart? -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Asking for date/time in Spacewalk
Duncan Mac-Vicar P. wrote: % On 17/12/13 08:53, Tomas Lestach wrote: % > Hey Duncan, % > % > the date picker is closely related with the displaying of timestamps % > as you among other things also display the proposed/chosen % > timestamp. I'd probably finish the displaying of timestamps and then % > concentrate on date picker. % % I think they are independent patches because we already have a date/time % picker in spacewalk. It is worth noting that this implementation is % backward compatible, even if it has 2 fields instead of 5 (?), it % generates hidden compatibility form inputs for the old actions. % % I am posting them at the same time to start a discussion. Hi, I like this feature. This calendar style picker is way better than what's there today. % > I basically like the possibility to pick a date from the calendar % > and be able to enter it form the keyboard at the same time. % > % > Btw. I saw your patch requires jQuery. As I am not aware of any % > jquery packages available in Fedora koji % > http://koji.fedoraproject.org/koji/ the eventual patch would need to % > contain also packaging for all Fedora and RHEL versions for those % > Spacewalk will be built. % % jQuery is already on master. It was committed together with the UI % refactoring as a replacement to prototype.js, which btw, was not % packaged either. That's true but it was a legacy. Maybe at least put those external javascripts into a different directory next to spacewalk ones so we can easily pack them independently. % I know you would prefer to have jquery packaged, but the web-assets % specification is pretty new (Fedora 20, % http://fedoraproject.org/wiki/Changes/Web_Assets ), and you would had % the same problem with the old prototype.js. Regards, -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Pushing to spacewalk.git
Silvio Moioli wrote: ... % So we prefer merging master into master-bootstrap-css-fixes from time to % time, because this does not require force pushing, that is talking % to/stopping 6 people every time master changes significantly (and it % does, see for example 559ab061). % % I asked Tomáš Kašpárek if this was acceptable: % % tkasparek: since various people work on % master-bootstrap-css-fixes here, we do not really like force pushing. At % the moment we are merging master back to the branch from time to time - % I hope that you don't mind some extra merge commits % moio: sure, just do whatever suits you the best % tkasparek thanks % np % % I hope this is not really a difficult issue, as I am happy with the % current upstream patch flow that, being quite fast, allows lots of bugs % to be solved efficiently. % % Final note for a future discussion: we would also be very happy if you % had an official GitHub account and could accept pull requests, as we % already do internally. That would also address this problem cleanly in % my opinion! Hi Silvio, Pushing changes to master-bootstrap-css-fixes is perfectly sane. I was complaining about those one-commit sub-branches which immediatelly merge back to the master-bootstrap-css-fixes branch. Regards, -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Pushing to spacewalk.git
Duncan Mac-Vicar P. wrote: % On 10/12/13 11:03, Michael Mraka wrote: % > Heya Spacewalk commiters, % > % > I've noticed recently that our git repo is a bit weird looking. % > I'm talking about commit sequences % > a291087ad5ef010074ad2d4b1679fcc2cdf667c5..0f49b04dc9c6062a2fd6f480449270123ff7f6b7 % > and % > 742472c23d67b6d62730c329d09e1bdac63bd22b..0bfcd3c4029fcf886e3ab5001a7dc75860457095. % > % > What's wrong with them? As for code changes they are OK. The way they've % > been forked / merged / re-merged and finally pushed made git repo pretty messy. % > As human brain is mostly used to think in linear timeline it's easy e.g. % > to look for bugs in linear sequence of code changes but you will very % > quickly get lost in the number of parallel branches. % > % > That's why our golden rule is - don't merge, rebase - it's an easy way % > to keep git repo as much linear as possible. % % We explicitly asked about this on irc. % % The issue is was how to work all the UI issues in a branch. Rebasing % work if we only push, but not if others contribute to that branch. Maybe I didn't explain it clearly for the first time. There's no problem working on branch, just please don't explode it to couple of sub-branches which - after one or two commits - merge back to it. Use rebase on top of the topic branch for this. Similarly merging master to the topic branch from time to time is not a problem. I hope it's more clear now. Regards, -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Path for rhn-custom-info.py
Ulf wrote: % Hello, % % I' d like to provide a small patch for rhn-custom-info.py. % It adds the option -d to delete custom values from systems. % % Cheers, % Ulf Hello Ulf, I've reviewed and committed your patch. Thanks for your contributions. Regards, -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Using fonts in /rhn/account/LocalePreferences.do
Duncan Mac-Vicar P. wrote: % > /rhn/account/LocalePreferences.do - in 21st century and utf8 fonts, do % we need pictures with text in national alphabets (if you select hindi as % webui language, we have to use some fonts supporting hindi anyway), % therefore getting rid of images would be really nice? % % I looked briefly into this and I have a patch. However there is a % problem. The "normal" fonts are not that complete so even if hindi shows % correctly with their alphabet, korean and other do not. % % This can be fixed by adding another font that is complete (like gnu % unifont) and generate a css style that would apply that font only in % that section of the page. However unifont .ttf is 14M. I am pretty sure % that one could generate a subset of the font but I haven't looked into % that yet. It should be possible with the build system of those fonts. Hi Duncan, Is that 10KB of images really that ugly / big problem that we need to replace them with 14MB ttf font? I don't think so. % Options? % - We look into generating a font with the symbols we need? Even when the font will include only necessary characters will it be smaller than current images? % - We keep using images but may be improve them? If it's just about good-looking labels I'd vote for new images based on font which looks nice with the rest of the page. % - ??? Regards, -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] Added Oracle Linux channels for UEKR3, as well as Spacewalk 2.0 Server/Client for OL6 and Client for OL5
Avi Miller wrote: % Oracle has shipped UEK Release 3 as well as Oracle built and signed versions of Spacewalk 2.0 Server (for Oracle Linux 6-x86_64) and Spacewalk 2.0 Client for (OL5/OL6). This patch adds those channels to spacewalk-common-channels.ini. % % I specified the Spacewalk channels as children of the parent OL5/OL6 channels as they inherit the GPG keys from the parent. They also use an alternative naming so as not to conflict with anyone who wants to use the upstream server/client channels. Hi Avi, Thanks for your patch. Commited to Spacewalk master as c1079bc659d892322b70dd63d85d9dcefa935693. Regards, -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] Add support for enhances weak dependency
Michael Calmer wrote: % Hi, % % just found out that we forgot one rpm weak dependency. % "Enhances" is a waek version of "Supplements" and is heavyly used at SUSE. % % 4 patches add the support for it to % % 001: spacewalk-backend % 002: java (taskomatic) % 003: web % 004: schema % % Patch 005 remove all cached metadata and trigger a regeneration for all % channels. % Feel free to skip this patch if you think that this is not needed. Hello Michael, I've reviewed your changes and commited patches. There was a small issue in table alias which I've fixed in e8650f095af2d37e106fdde4d14cb2d78540112b. Regards, -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Update spacewalk-repo-sync man page
Flavio Castelli wrote: % We recently got a bug because a cli option of spacewalk-repo-sync was not % mentioned by its man page. Later I realized there was also another one which was % missing. % % These commits bring the man page up to date. Hello Flavio, I can't see neither --non-interactive nor --deep-verify options in upstream version of spacewalk-repo-sync. Do they implement something very SUSE specific or would they be useful also for upstrem? Regards, -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
