Re: [Spacewalk-devel] [PATCH] - 982673 - rhnsd minimum interval should fit within 1 minute
On 07/09/2013 04:38 PM, Marcelo Moreira de Mello wrote: Hello team, Following attached a patch to address the issue reported on bug #982673. Thanks. mmello ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel I believe you want to turn it the other around. See bug 563173. -- Simon Lukasik Security Technologies ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] a question about the Audit feature
On 02/22/2013 09:42 PM, Brian Millett wrote: (sorry, this might be a resend, but used the wrong email to send the original) I've got a spacewalk server running and it is really nice. Good job on the system. One question about the Audit. I've been doing a lot of work with openSCAP and generating a custom XCCDF.xml file that also incorporates 400 fixes. I've been able to schedule an Audit for a system, providing the correct profile and the location of my XCCDF file. I can get a nice result of the Audit, which rules pass, which fails. One of the features of openscap is the ability to generate a remediation script based on the results of the audit, so my question is where do I start looking, to add the ability to supply the remediation script for the server to download? I can get a CSV of the results, look at the result of the Audit, but I also would like to down load the remediation script for that server. Thanks. Brian, these are very good questions! Thank You! Just a few days ago, I have implemented remediation script processing in the OpenSCAP project. So, with the upcomming release of oscap, you are able to remediate your machine at the very same time as the scan proceeds. # oscap xccdf eval --remediate (...) In the resulting XCCDF file, You will find the output of remediation scripts, return values and info messages about the xccdf:fix processing. I am thinking about allowing this procedure also through Spacewalk, but we cannot easily allow this arbitrary script execution. Perhaps, the --remediate option can be allowed only for client machines which has the 'rhn-actions-control --enable-run'. And regarding your question about remediation *after* the scan, using the results from Spacewalk: This might be also possible, just not right now. We still need to figure out, how to allow remediation of existing xccdf:TestResult files. That will be probably possible through # oscap xccdf remediate (...) module. Maybe some intermediate (XCCDF:TestResult-based) format will be needed to allow user to select rule-results which shall be remediated and select rule-resuts which shall not. Do You think, that You can use online remediation (without user interactions) in your organization? As usual, we welcome any ideas and comments! Best regards, -- Simon Lukasik Security Technologies ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] ***UNCHECKED*** Re: ***UNCHECKED*** Re: ubuntu dependancy python-hwdata and support for 3.x kernels for memory information
On 08/31/2012 04:26 PM, william wrote: On 08/31/2012 12:06 PM, Simon Lukasik wrote: On 07/06/2012 03:47 PM, william wrote: On 07/06/2012 12:29 PM, william wrote: inititial debian package for python-hwdata. I have put my name in it but please feel free to change that. updated: Fixed some lintian errors There is only one left: W: python-hwdata: new-package-should-close-itp-bug Hello William, Thanks for contribution. I would really like to apply Your contribution needs to be reworked to the form of patch. Unfortunately, due to other constraints I am unable to find time for doing it myself. It would be much appreciated if You could check-out spacewalk sources: $ git clone git://git.fedorahosted.org/git/spacewalk.git/ and go to the directory where debian clients lays: cd spacewalk.git/client/debian/ create there directory structure for python-hwdata (similar to others there). And then send it in form of git patch. Should i also make the client depending on python-hwdata? Yes. git add python-hwdata git commit git format-patch i will try when i have time, probably monday. Great news! An information on how-to-contribute can be found at https://fedorahosted.org/spacewalk/wiki/PatchProcess Thank You! -- Simon Lukasik ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Ubuntu 12.04 typeError when getting installtime
On 08/31/2012 10:27 AM, william wrote: Hello Ubuntu 12.04 has some difference with upstream debian with multiarch packages. When you try to add a system to spacewalk it will raise a typeError. After investigating the issue it seems that the package name as listed with dpkg -l has packages without the packagename.list file in /var/lib/dpkg/info/ e.g. e2fslibs. The file debUtils.py from rhn-client looks for this file to determine the installtime (dpkg does not have this info in its package database), but on Ubuntu 12.04 you can have the package e2fslibs bot not the file e2fslibs.list file but the filename is e2fslibs:amd64.list. https://bugs.launchpad.net/bugs/1020833 #dpkg -l|grep e2fslibs ii e2fslibs 1.42-1ubuntu2 ext2/ext3/ext4 file system libraries #ls /var/lib/dpkg/info/e2fslibs* /var/lib/dpkg/info/e2fslibs:amd64.list /var/lib/dpkg/info/e2fslibs:amd64.postinst /var/lib/dpkg/info/e2fslibs:amd64.shlibs /var/lib/dpkg/info/e2fslibs:amd64.md5sums /var/lib/dpkg/info/e2fslibs:amd64.postrm /var/lib/dpkg/info/e2fslibs:amd64.symbols The filenames for packages with e.g. the name gcc-4.6-base:i386 does have the correct list file in /var/lib/dpkg/info/, but packages without this arch extension is mostly packagename:amd64.list An easy solution would be to check for the packagename.list then packagename:amd64.list and so on. e.g. file: /usr/share/rhn/up2date_client/debUtils.py def installTime(pkg_name): path = '/var/lib/dpkg/info/%s.list' % pkg_name if os.path.isfile(path): return os.path.getmtime(path) path = '/var/lib/dpkg/info/%s:amd64.list' % pkg_name if os.path.isfile(path): return os.path.getmtime(path) path = '/var/lib/dpkg/info/%s:i386.list' % pkg_name if os.path.isfile(path): return os.path.getmtime(path) else: print pkg_name return None So, after this change Spacewalk community would maintain a mapping between possible architectures and their names in Debian world? I really don't feel this is the right way to go. Why we actually need that file? Yes, we need it because dpkg does not provide package installation time. Wouldn't be the world much better place to live in if dpkg could provide package installation time? (it can also be to return 0 if the list file has not been found). After this change Ubuntu 12.04 works as expected without a typeError ps: a while back i also posted the package python-hwdata which adds the system info to the spacewalk database, without this you wil not have hw info. https://www.redhat.com/archives/spacewalk-devel/2012-July/msg00018.html Regards William -- Simon Lukasik ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] ***UNCHECKED*** Re: ***UNCHECKED*** Re: ubuntu dependancy python-hwdata and support for 3.x kernels for memory information
On 07/06/2012 03:47 PM, william wrote: On 07/06/2012 12:29 PM, william wrote: inititial debian package for python-hwdata. I have put my name in it but please feel free to change that. updated: Fixed some lintian errors There is only one left: W: python-hwdata: new-package-should-close-itp-bug Hello William, Thanks for contribution. I would really like to apply Your contribution needs to be reworked to the form of patch. Unfortunately, due to other constraints I am unable to find time for doing it myself. It would be much appreciated if You could check-out spacewalk sources: $ git clone git://git.fedorahosted.org/git/spacewalk.git/ and go to the directory where debian clients lays: cd spacewalk.git/client/debian/ create there directory structure for python-hwdata (similar to others there). And then send it in form of git patch. git add python-hwdata git commit git format-patch An information on how-to-contribute can be found at https://fedorahosted.org/spacewalk/wiki/PatchProcess Thank You! -- Simon Lukasik ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] cobbler 2.2 version
On 07/19/2012 03:39 PM, Franky Van Liedekerke wrote: Hi all, in this thread: https://www.redhat.com/archives/spacewalk-devel/2012-July/msg00045.html I saw people saying that cobbler version 2.2 has issues working together with spacewalk 1.7 However: I had the EPEL activated when I upgraded from 1.6 to 1.7, and cobbler updated as well, so now I'm currently running cobbler 2.2.1 together with Spacewalk 1.7, and no issues so far By any change you forgot to switch your SELinux Enforcing mode? (apart from the fact that I needed to regenerate the kickstart profiles, but a small script resolved that just fine). Is this something that I now should be worried about when upgrading to 1.8 in the future? Since cobbler 2.2.3 is also out, but I'm now holding back on updating that part ... Franky ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel -- Simon Lukasik ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Advanced Yum Repo Question
On 03/31/2012 06:28 AM, Steven Crothers wrote:
Hello everyone,
I'm working on building a yum repo generator from Spacewalk sources.
It will function like this:
Jump into the Spacewalk API, snag all the packages. Build them into a list.
Insert all the data into a sqlite database (easiest way to power this
type of project I think, no I don't want to hook into the life DB
either, it should be DB free imo).
Download metadata for each package, insert into the sqlite database.
Build various files {other,primary,filelists}.xml
Just wondering, wouldn't it be easier to register machines, create
appropriate channel, and let Spacewalk to create the repodata for you?
Now here's my question. Before I get to involved in something that may
or may not work, from my understanding location href=something.rpm
can point to a full URL correct? As in
http://spacewalk/bla/bla/bla/something.rpm;?
There is one, but it serves only to authenticated authorized requests.
https://example.com/XMLRPC/GET-REQ/channel/rpm
If not, the only other solution I can think of is writing an apache
mod_rewrite rule for each package. This repo is ideally going to sit
on the Spacewalk server, so doing some rewrites isn't that big of a
deal. Considering the goal is to simply create yum repos from
Satellite packages and channels I think these are logically my best
two options without entering the database.
My reasons for not entering the database are the following:
1. Security policies in the office.
2. My Oracle-fu sucks.
So if someone says that I should be pulling the DB directly and can
give me a few good reasons, and possibly be willing to let me bounce
some queries off them, I would be more than happy to do it that way.
It would be quicker after all.
--
Simon Lukasik
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Status of Debian support in Spacewalk
I'm also interested, we have some Debian 5 machines here in our environment and a healthy Debian following. Where can I sign up? Where is your existing work at, and notes if you have them? Steven, I'll try to summarize where the available readings about Debian support lies. Page about registering Debian clients to the Spacewalk. - https://fedorahosted.org/spacewalk/wiki/RegisteringClients#Debian Overall status and a few outdated examples. - https://fedorahosted.org/spacewalk/wiki/Deb_support_in_spacewalk Current deb packaging repository, including apt-spacewalk sources - http://git.fedorahosted.org/git/?p=spacewalk.git;a=tree;f=client/debian Currently opened bugs: - https://bugzilla.redhat.com/show_bug.cgi?id=703834 - https://bugzilla.redhat.com/show_bug.cgi?id=703838 A few threads on Spacewalk mailinglist (keywords: debian, apt) Additionally, there are two whitepapers about Debian support: - http://www.fit.vutbr.cz/study/DP/DP.php?id=8013y=2009 - http://www.fit.vutbr.cz/study/DP/BP.php?id=12397y=2010 If I can I would suggest 'Chapter 5 - Conclusion' of the latter. Finally, I and Mirek will be happy to answer any questions. Best regards, -- Simon Lukasik ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] erratas and the client plugin package action
On 10/18/2011 08:43 PM, Miroslav Suchy wrote: Dne 18.10.2011 17:56, Ionuț Arțăriși napsal(a): Cool. So can you apply the patch that I attached to my previous email? Ahh, I did not notice it first time - sorry. Applied. Thanks. Mirek This is going to break Debian client. When something is moved from the rhn-client-tools to yum-rhn-plugin, it should be moved to apt-spacewalk as well. -- Simon LukasikSystems Management QA sluka...@redhat.com #satellite-qa ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] parallelism in satellite-sync
On 05/31/2011 10:41 PM, Miroslav Suchy wrote: Dne 31.5.2011 09:45, Simon Lukasik napsal(a): I have synced RHEL6 channel (more than 6 GiB of rpms) in about 48 minutes. And what was your previous average time? Mirek I haven't specify that, because I don't have a numbers for that particular machine. On another machine without applying a patch I was able to sync that channel in about 1h 40m. Both machines are in the same location, but the time of day was different. Also note, that I have clocked only the download of rpms. ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel -- Simon LukasikSystems Management QA sluka...@redhat.com #satellite-qa ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] The struggle with rhn-client-tools on Debian
On 04/06/2011 03:39 PM, Miroslav Suchý wrote: On 04/02/2011 01:46 PM, Simon Lukasik wrote: I have finished a minimal work needed for rhn-client-tools on Debian. Changes are in rhn-client-tools-debian branch. Would You mind to take a review? I just read the code and have no problem. Merged to master. My comment: - in debUtils I would use python-dpkg. I know that it is long time dead, but dpkg does not change either. So you may not depend on it directly, but copy'n'paste it from that library. I will look at it. Thanks much. -- Simon LukasikSystems Management QA sluka...@redhat.com #satellite-qa ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] The struggle with rhn-client-tools on Debian
On 03/29/2011 05:36 PM, Simon Lukasik wrote: On 03/29/2011 08:41 AM, Miroslav Suchý wrote: On 03/29/2011 08:19 AM, Simon Lukasik wrote: (A) A big part of the code depends directly on python-rpm. We don't want 'import rpm' on Debian nor 'import apt' on Fedora. (B) /etc/sysconfig does not exist on Debian I would suggest to use /etc/default/rhn. /etc/default is Debian equivalent for /etc/sysconfig. More or less. The problem is not, that I cannot find an equivalent, the problem is, how to separate the code. (C) redhat-release does not exist on Debian /etc/debian_version or lsb_release -r or lsb_release -c So You suggest to require lsb from rhn-client-tools? It's not necessarily needed, but it would make things easier, yes. (D) Architecture names are slightly different Yeah, but we already have Debian architecture in DB and rhnpush count with it, right? Not exactly, but yes. Now we treat i686 as an i386. Which might not be ultimate solution for an Ubuntus. Potential solutions: Hello Mirek, I have finished a minimal work needed for rhn-client-tools on Debian. Changes are in rhn-client-tools-debian branch. Would You mind to take a review? I have introduced up2date_client.platform.getPlatfrom() which returns either 'rpm' or 'deb'. And other modules look up the value and decide what to do in a runtime. The 'rpm' is always default and I aimed not to change the behavior for rpm. So far I didn't touch /etc/sysconfig/rhn path. Nor the strings. It could be the next step. For testing on Debian you will need to install at least: python-ethtool, python-newt, python-dmidecode, python-apt, python-libxml2, lsb-release. And then install rhn-client-tools by: make PLATFORM=deb -f Makefile.rhn-client-tools install At least you should be able to register with Spacewalk-1.3+. Seeing the hardware profile, distribution information and package profile together with installation dates. Please make use of activation keys. So far we have no mechanism to associate channel to Debian/Ubuntu/Mint/Whatever. It could be tricky to parse that distribution information provided by lsb-release. I will follow up with *.deb packages, once these changes are merged upstream. Regards, My priorities: (1) Create a Debian patch, and apply it only when building the .deb package. It is easier for start, but the patch needs to be maintained. +1 (2) Modify upstream rhn-client-tools, to include bits for both: Debian Fedora and choose one during a build-time. +3 (3) Same as (2) but in run-time. (polymorphism). +2 (4) interleave with if-else: if getPlatform() == 'deb': import apt else: import rpm +2 (5) Still there is an option to write rhn-client-tools from scratch. (Design new interface). I doubt anybody likes that. -10 I see, build-time (2) has scored. I will look at this option focusing on Python's distutils. Assuming that sed (see current Makefile) and Python's preprocesor are not preferred ways. Will see, -- Simon Lukasik ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] The struggle with rhn-client-tools on Debian
Hello list, I am trying to build the rhn-client-tools package for a Debian client. In this mail I try to collect my thoughts and facts. Problems: (A) A big part of the code depends directly on python-rpm. We don't want 'import rpm' on Debian nor 'import apt' on Fedora. (B) /etc/sysconfig does not exist on Debian (C) redhat-release does not exist on Debian (D) Architecture names are slightly different Potential solutions: (1) Create a Debian patch, and apply it only when building the .deb package. It is easier for start, but the patch needs to be maintained. (2) Modify upstream rhn-client-tools, to include bits for both: Debian Fedora and choose one during a build-time. (3) Same as (2) but in run-time. (polymorphism). (4) interleave with if-else: if getPlatform() == 'deb': import apt else: import rpm (5) Still there is an option to write rhn-client-tools from scratch. (Design new interface). I doubt anybody likes that. --- I have already started with the (3) option. The reason I am writing this mail is that my result does not seem much promising. The third option assumes a lot of refactoring and it's not elementary. For instance each module containing 'import rpm', could be extracted to 3 or 4 submodules: - one top level - to preserve current interface - containing platform independent functions - doing the magic to import either deb or rpm variant - one for rpm dependent functions - one for deb dependent functions As you can see, it's not acceptable. Application logic will be lost in the pile of modules. In the opposite way, creating a single module for Debian and another for Fedora, would result in a big inconsistent modules. Unless you have better idea, I'll start with (1) option. -- Simon Lukasik ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] The struggle with rhn-client-tools on Debian
On 03/29/2011 08:41 AM, Miroslav Suchý wrote: On 03/29/2011 08:19 AM, Simon Lukasik wrote: (A) A big part of the code depends directly on python-rpm. We don't want 'import rpm' on Debian nor 'import apt' on Fedora. (B) /etc/sysconfig does not exist on Debian I would suggest to use /etc/default/rhn. /etc/default is Debian equivalent for /etc/sysconfig. More or less. The problem is not, that I cannot find an equivalent, the problem is, how to separate the code. (C) redhat-release does not exist on Debian /etc/debian_version or lsb_release -r or lsb_release -c So You suggest to require lsb from rhn-client-tools? It's not necessarily needed, but it would make things easier, yes. (D) Architecture names are slightly different Yeah, but we already have Debian architecture in DB and rhnpush count with it, right? Not exactly, but yes. Now we treat i686 as an i386. Which might not be ultimate solution for an Ubuntus. Potential solutions: My priorities: (1) Create a Debian patch, and apply it only when building the .deb package. It is easier for start, but the patch needs to be maintained. +1 (2) Modify upstream rhn-client-tools, to include bits for both: Debian Fedora and choose one during a build-time. +3 (3) Same as (2) but in run-time. (polymorphism). +2 (4) interleave with if-else: if getPlatform() == 'deb': import apt else: import rpm +2 (5) Still there is an option to write rhn-client-tools from scratch. (Design new interface). I doubt anybody likes that. -10 I see, build-time (2) has scored. I will look at this option focusing on Python's distutils. Assuming that sed (see current Makefile) and Python's preprocesor are not preferred ways. Will see, -- Simon Lukasik ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] PATCH: Repogeneration for debian channels is broken
Hello list,
There are few issues with repo generation for Debian channels:
* Process will not complete for most of the cases, because
FileNotFoundException is thrown, but rhn_taskomatic_daemon.log is silent.
* When Debian channel is deleted, Taskomatic attempts to delete yum metadata
which pollutes log, while Debian specific metadata are left on disk.
* RepositoryWriter class contains private methods for both Deb and Rpm
* Progress of 'Repo Cache Status' for Debian channel is reported on webui as
'(none)'
I didn't address the last issue.
Please, could somebody review my patches?
Best regards,
Šimon Lukašík
From e17edada0933c90f6fd9762ac90f297c74c039c9 Mon Sep 17 00:00:00 2001
From: Simon Lukasik sluka...@redhat.com
Date: Thu, 30 Sep 2010 19:38:14 +0200
Subject: [PATCH 1/4] Create cache directory for both rpm and deb channels.
Otherwise metadata creation for deb channel fails
with FileNotFoundException.
---
.../taskomatic/task/repomd/RepositoryWriter.java |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/java/code/src/com/redhat/rhn/taskomatic/task/repomd/RepositoryWriter.java b/java/code/src/com/redhat/rhn/taskomatic/task/repomd/RepositoryWriter.java
index 820407c..12fcf03 100644
--- a/java/code/src/com/redhat/rhn/taskomatic/task/repomd/RepositoryWriter.java
+++ b/java/code/src/com/redhat/rhn/taskomatic/task/repomd/RepositoryWriter.java
@@ -104,15 +104,15 @@ public class RepositoryWriter {
// we closed the session, so we need to reload the object
channel = (Channel) HibernateFactory.getSession().get(channel.getClass(),
channel.getId());
+if (!new File(prefix).mkdirs() !new File(prefix).exists()) {
+throw new RepomdRuntimeException(Unable to create directory: +
+prefix);
+}
if (channel.getChannelArch().getArchType().getLabel().equalsIgnoreCase(deb)) {
log.info(Generating new DEB repository for channel + channel.getLabel());
generateDebRepository(channel, prefix);
}
else {
-if (!new File(prefix).mkdirs() !new File(prefix).exists()) {
-throw new RepomdRuntimeException(Unable to create directory: +
-prefix);
-}
// Get compatible checksumType
this.checksumtype = channel.getChecksumTypeLabel();
if (checksumtype == null) {
--
1.7.2.3
From 4a14079634c37e1dc3eee766cf86522b5a26e938 Mon Sep 17 00:00:00 2001
From: Simon Lukasik sluka...@redhat.com
Date: Fri, 1 Oct 2010 13:34:24 +0200
Subject: [PATCH 2/4] Rpm and Deb metadata creation differs, moving to separate classes.
---
.../task/repomd/ChannelRepodataWorker.java | 19 +-
.../task/repomd/DebRepositoryWriter.java | 79 +++
.../taskomatic/task/repomd/RepositoryWriter.java | 551 +++-
.../task/repomd/RpmRepositoryWriter.java | 472 +
4 files changed, 625 insertions(+), 496 deletions(-)
create mode 100644 java/code/src/com/redhat/rhn/taskomatic/task/repomd/DebRepositoryWriter.java
create mode 100644 java/code/src/com/redhat/rhn/taskomatic/task/repomd/RpmRepositoryWriter.java
diff --git a/java/code/src/com/redhat/rhn/taskomatic/task/repomd/ChannelRepodataWorker.java b/java/code/src/com/redhat/rhn/taskomatic/task/repomd/ChannelRepodataWorker.java
index 5c021b5..c5162ea 100644
--- a/java/code/src/com/redhat/rhn/taskomatic/task/repomd/ChannelRepodataWorker.java
+++ b/java/code/src/com/redhat/rhn/taskomatic/task/repomd/ChannelRepodataWorker.java
@@ -27,6 +27,7 @@ import com.redhat.rhn.taskomatic.task.threaded.QueueWorker;
import com.redhat.rhn.taskomatic.task.threaded.TaskQueue;
import org.apache.log4j.Logger;
+import org.jfree.util.Log;
import java.util.HashMap;
import java.util.List;
@@ -58,10 +59,20 @@ public class ChannelRepodataWorker implements QueueWorker {
String mountPoint =
Config.get().getString(ConfigDefaults.REPOMD_CACHE_MOUNT_POINT, /pub);
channelLabelToProcess = (String) workItem.get(channel_label);
-repoWriter = new RepositoryWriter(prefixPath, mountPoint);
-logger.info(Creating ChannelRepodataWorker with prefixPath( + prefixPath +
-), mountPoint( + mountPoint + ) + for channel_label ( +
-channelLabelToProcess + ));
+
+// We need to find out whether to use Rpm or Debian repository
+Channel channelToProcess = ChannelFactory.lookupByLabel(channelLabelToProcess);
+// if the channelExists in the db still
+if (channelToProcess != null channelToProcess.getChannelArch()
+.getArchType().getLabel().equalsIgnoreCase(deb)) {
+repoWriter = new DebRepositoryWriter(prefixPath, mountPoint);
+}
+else {
+repoWriter = new RpmRepositoryWriter(prefixPath, mountPoint);
+}
+logger.info(Creating ChannelRepodataWorker with prefixPath
[Spacewalk-devel] spacewalk plug-in for apt-get
Hi Spacewalkers, I would like to announce, that I've started work on $subj. Deadline is 1 year ahead, but I would really like to finish it till October. Will keep You informed. best regards Simon Lukasik ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
