Re: [Spacewalk-devel] commit c8317564eecd3839769971a39535ea3e189849ac
Jesus M. Rodriguez wrote:
John,
http://git.fedorahosted.org/git/?p=spacewalk.git;a=commitdiff;h=c8317564eecd3839769971a39535ea3e189849ac
One nitpick with the hardware_device_by_id query. Right justify the
SQL keywords for example, the T of SELECT
should line up with the M in FROM and the final E in WHERE. The rest
of the query looks ok.
Why are you doing the cast if the DataResult has a type?
+DataResult dr =
+SystemManager.getHardwareDeviceById(hwId);
+if ((dr != null) && (dr.size() > 0)) {
+sr.setHw((HardwareDeviceDto)dr.get(0));
Just my own ignorance, will fix.
Also, if you're expecting only ONE HardwareDevice, then I'd change
getHardwareDeviceById method
to retun the HardwareDeviceDto directly instead.
sr.setHw(SystemManager.getHardwareDeviceById(hwId));
Makes sense, will change.
Everything else looks ok. Good job.
jesus
Thanks for looking this over
-John
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] commit d30dfdb992c0a3f3da09dabc3f604947bb3efe18
Jesus M. Rodriguez wrote: John, Some comments on the recent commit: http://git.fedorahosted.org/git/?p=spacewalk.git;a=commitdiff;h=d30dfdb992c0a3f3da09dabc3f604947bb3efe18 How often are we running 'deleteRecordsNotInList' in IndexManager? Is this during every index run? or in between runs? This will be run at the end of every index task. I could create a separate task for handling this instead. That would allow us to schedule the delete task to run less frequent. What approach do you recommend? Thanks for the other tips, I've followed your advice and updated the files. -John ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Re: 70 MB tar.gz in git ...
Hi Jan, Jan Pazdziora wrote: Hello John, I generally wonder how correct it is to have the tarballs of this size there. Especially looking at its name, it looks like some kind of nightly build. So I assume it will get replaced eventually, and by having it as tar.gz in there, the next check-in will again bring in the whole 70 MB beast because git will not have a way of storing it as a diff or sharing content of common files from those tarballs. Maybe we shouldn't store such things in git at all and just change the make test-srpm / make srpm targets to download the Source0 thing from the remote URL? I understand your concern, I felt uncomfortable committing this file, yet wasn't aware of a better place to store it. I'm worried about the longevity of nightly builds from nutch's hudson, I would think they won't be available for long. That's my only argument against making a script fetch this when it's required. Do we have any place we can store a tarball, so I don't need to pollute git with this? Or maybe we'd want to unpack that tar.gz, so that subsequent changes can only store the diff? This is possible, but might create a little more work as nutch includes 3rd party jars in the tarball, the extra work required would be to ensure after upgrading to a new version, that any older jars hanging around get removed. The end goal is to get nutch into Fedora. This wiki page outlines the packaging needed: https://fedorahosted.org/spacewalk/wiki/GettingPackagesIntoFedora/Nutch ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Re: Automatic commit of package [spacewalk-search] release [0.4.4-1].
Michael Mraka wrote: % Automatic commit of package [spacewalk-search] release [0.4.4-1]. % % author John Matthews % Wed, 17 Dec 2008 20:34:28 + (15:34 -0500) % commit e7063088c7cf158f48f519237886b219ab10e6dd % % commit of package [spacewalk-search] release [0.4.4-1]. Heya John, I can't see tags associated with your 'Automatic commit...' commits. Probably forgotten 'git push --tags'. Hi Michael, I just double checked and did another "git push --tags", it said there were no changes. I see this "Tagging package [spacewalk-search] version [0.4.4-1] in directory [search-server/]." from this URL http://git.fedorahosted.org/git/?p=spacewalk.git;a=tag;h=5ea1b5662f951987f574a58c9d095ebf3b37d519 Am I missing another step, this is my first attempt at tagging/building? Thanks, John ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] #!/usr/bin/env python to #!/usr/bin/python
Devan Goodwin wrote:
On Wed, 14 Jan 2009 12:13:20 +0100
Jan Pazdziora wrote:
On Wed, Jan 14, 2009 at 10:36:37AM +0100, Jan Pazdziora wrote:
I propose to phase out
#!/usr/bin/env python
in favour of
#!/usr/bin/python
in our python scripts.
Speak now or forever hold your peace.
Note that we already use the second form 182 times in non-test
scripts, while we use env 63 times.
The current problem that I'm solving is that osa-dispatcher, when
started via /usr/bin/env, will search directories for python, which
generates SELinux AVC denials like
type=AVC msg=audit(1231924839.798:5971): avc: denied { search }
for pid=15336 comm="python" name="root" dev=dm-0 ino=784129
scontext=root:system_r:osa_dispatcher_t:s0
tcontext=root:object_r:user_home_dir_t:s0 tclass=dir
Actually, this AVC denial is about different problem. So it was not
a good example.
But nevertheless: shouldn't we decide for env or direct path in the
shebang line and be consistent about it?
+1. I'd go the other direction though and stick with "/usr/bin/env
python", iirc that's considered best practice to accommodate people
with Python installed in a weird location or using multiple versions.
Devan
I agree with Devan, and prefer the "env" usage.
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Spacewalk 0.6 code freeze: Thursday, Aug 6 @ noon EDT
It's that time again, time to get yet another release of Spacewalk out the door. Thursday, Aug 6 @ noon EDT will be code freeze. There are 30 bugs (lot's of tracking bugs) that still need punting or fixing. Please take a look at your bug lists: http://tinyurl.com/kspjsl We will start building the packages around 2pm EDT. The hope is to have the packages signed and put into the QA repo by 4pm on Thursday. Our target is to go LIVE on Friday August 7th, by 5pm EDT. ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] rhnpush error from latest 0.6 packages
I installed our latest 0.6 packages from koji and am seeing a problem with rhnpush. Exception RuntimeError: 'maximum recursion depth exceeded while calling a Python object' in ignored In addition to the rhnpush issue, the install displayed 2 warnings from Cheetah about md5 being deprecated. .. ... * Setting up Cobbler.. /usr/lib/python2.6/site-packages/Cheetah/CacheRegion.py:30: DeprecationWarning: the md5 module is deprecated; use hashlib instead import md5 Cobbler requires tftp and xinetd services be turned on for PXE provisioning functionality. Enable these services (y/n, default = 'y')? /usr/lib/python2.6/site-packages/Cheetah/CacheRegion.py:30: DeprecationWarning: the md5 module is deprecated; use hashlib instead import md5 * Restarting services. Installation complete. ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] rhnpush error from latest 0.6 packages
On 08/06/2009 09:48 PM, Dennis Gilmore wrote: On Thursday 06 August 2009 08:36:15 pm Jesus M. Rodriguez wrote: On Thu, Aug 6, 2009 at 8:46 PM, John Matthews wrote: I installed our latest 0.6 packages from koji and am seeing a problem with rhnpush. Exception RuntimeError: 'maximum recursion depth exceeded while calling a Python object' in ignored Hrm. That's not cool. Do we have the latest clients built? in my testing i got that message but could push just fine Dennis Thanks Dennis, you're right it's working. I saw the message and immediately thought the operation was busted, didn't even look in the webui. I'm checking now and I see it pushed the packages fine. ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] rhnpush error from latest 0.6 packages
In addition to the rhnpush issue, the install displayed 2 warnings from Cheetah about md5 being deprecated. Let's file a bug on the md5 issue. It will still work in F11, but display those warnings. Turns out this has already been filed as a bz, and there is a plan mentioned for this getting into Fedora-11 https://bugzilla.redhat.com/show_bug.cgi?id=480945#c8 Bug 480945 - [PATCH] Use hashlib instead of deprecated module 'md5' ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
