Re: [Spacewalk-devel] cobbler20 commits for 7.1
On 09/10/2015 03:09 AM, Avi Miller wrote: > Hi, > > In reference to https://bugzilla.redhat.com/show_bug.cgi?id=1184595 the fix > was listed in koan-2.0.7-54. However, I can't seem to find any corresponding > commits in the Spacewalk GitHub repo in spec-tree/cobbler20. > > Was this not patched/fixed in Spacewalk's build of Cobbler? If not, is there > any particular reason? Spacewalk does not ship koan packages, instead it relies on the koan packages that are in the OS's repositories. -Stephen ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Monitoring on Spacewak 2.2 and Upgrade to 2.3
Please note that if you're running Spacewalk Nightly you have to manually apply the database changes, spacewalk-schema-upgrade only works to go from one release to the next. This is almost certainly the cause of your errors, and one of the reasons that running nightly is not recommended. -Stephen On 02/04/2015 04:15 AM, Francisco Cardoso wrote: Morning, Following some mails up and down regarding the loss of the monitoring feature. With its removal, all the systems and kickstarts and everything where the monitoring feature was activated are now showing tracebacks on the catalina.out and internal server errors. Is it to be expected that when you upgrade to the final 2.3 that there will be some pruning to the database and to “fix” these issues ? I can provide the traces from the tomcat and any information deemed necessary. Regards, Francisco ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Outstanding pull requests
On 02/02/2015 09:56 AM, Patrick Hurrelmann wrote: On 02.02.2015 15:06, Cliff Perry wrote: Hi folks, the amount of outstanding pull requests has gone down a lot. We only have 8 remaining. Is there any remaining which would be good to get done before SW 2.3 was branched? - Any of high priority that are being advocated above the rest. https://github.com/spacewalkproject/spacewalk/pulls Thanks, Cliff Hi Cliff, there are still some outstanding issues concerning RHEL7/CentOS7 support. I will try to gather them. Is RHEL7 support still an aim for 2.3? Regards Patrick Yes. -Stephen ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Clone errata page migrating to Java
Hey everyone, I'm starting to work on migrating the clone errata page (/network/software/channels/manage/errata/clone.pxt?cid=) from Perl to Java. Instead of doing a straight port though I think I'm going to change it a bit, which is why I'm writing. The existing page generates a dropdown menu for each erratum in the original channel with the following options: Merge with existing org-owned erratum (default if it exists, repeated for each clone of the original erratum that this org owns (there are potentially many of them, not just one)), Clone as new clone (default if no clones already exist), Do Nothing. A dropdown menu is required if we are going to give the user the option to merge to any of the potentially many clones of that erratum that her org owns. However that also makes this page very awkward to use. There is currently no way to, for example, change all the errata to Do Nothing and then only clone the one or two that you care about, except by clicking through every erratum in the list and changing its default action. In many large channels that can be hundreds or thousands of errata. I can't imaging that many people would be using this page for that purpose. I also can't really see the point of having multiple clones of the same errata in the same org. It seems to me that you would only really need one, and then associate it with the channels in your org that you want it to be associated with. In other pages of this type (/rhn/channels/manage/errata/AddCustomErrata.do, /rhn/errata/manage/Channels.do) Spacewalk only gives you the option create a clone of the original erratum if your org does not already own one, or to associate your org's clone to the channel if it does. /rhn/errata/manage/CloneErrata.do gives you the option to clone an existing errata as unpublished errata, which is a little different. Tooling like spacewalk-clone-by-date always reuses existing clones if they exist. And of course the API allows you to do whatever you want, so you could still create additional clones if you really wanted to. What I'm planning on doing for the Java port of this page is to instead have a list of errata with two or three radio buttons each: Merge with oldest existing org-owned clone (if it exists), Clone as new clone, and Do Nothing. There will also be buttons at the top of the list to change the selection for all errata. I think that will make this page a lot more useful and usable, but it removes the ability to choose which of your potentially many org-owned clones you want to merge with. If anyone has a problem with that or can think of a use-case where we need to keep the old behavior I'd love to hear about it. -Stephen ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Large changes from dropping monitoring and solaris support
Hey everyone, In preparation for Spacewalk 2.3 I have merged the perl-removal branch into master, which (among other things) drops support for solaris and monitoring. This is a large change, involving the deletion of many database tables and obsoleting many packages. I will work to get master back into a stable state, but I fully expect that there will be things that are broken in the short-term. We need to work everything out now so that Spacewalk 2.3 is stable and functional. If you notice problems related to solaris or monitoring being mentioned in remaining pages, installers, tools, or problems related to upgrading schema or packages, please help fix them or point them out to me so that we can get everything stable for 2.3. Thanks! -Stephen ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Large changes from dropping monitoring and solaris support
On 12/17/2014 10:54 AM, Duncan Mac-Vicar P. wrote: Monitoring integrated somehow with the overview/alerts page. Will some infrastructure remain in place so that in the future some external monitoring system can be plugged in? We have a plugin that sends Spacewalk data - Nagios and it could make sense providing the reverse. Spacewalk would offer just a coord that can be plugged into some monitoring system with an adaptor and you would see some basic status of the systems registered in both inside Spacewalk. If there are ideas around it, it could enable our team to contribute to that. The infrastructure (tables, code) that was in place was pretty specific and tightly-coupled to Spacewalk's monitoring solution. I think that some form of integration with third-party monitoring is a great idea, but I think that support for that would have had to be written from scratch even if we were not removing Spacewalk's monitoring. But feel free to revert deletions of things that can be re-used with this new feature as you work on it. -Stephen ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Java 6 required?
On 05/20/2014 08:43 AM, Duncan Mac-Vicar P. wrote:
Hi,
We tested a build today and a testcase I added some days ago in our tree
(to be upstreamed) failed. It was because 2 scenarios:
- a SUSE Manager 1.7 build that was updated to 2.1 and therefore the old
jvm stayed on 1.6
- a Docker container with an outdated description, using 1.6 from the
beginning.
I realized that in FormatDateTag I used:
private static final String ISO_FORMAT = -MM-dd'T'HH:mm:ssXXX;
private final DateFormat isoFormatter = new SimpleDateFormat(ISO_FORMAT);
the X pattern is new in Java 7. To make it Java 6 compatible it would
need to be done something like (untested, but an elegant solution from a
SO user)
private static final String ISO_FORMAT = -MM-dd'T'HH:mm:ssZ;
private final DateFormat isoFormatter = new
SimpleDateFormat(ISO_FORMAT) {
public Date parse(String source, ParsePosition pos) {
return
super.parse(source.replaceFirst(:(?=[0-9]{2}$),),pos);
}
};
The question is wether we need to backport it. At least for us, we are
using Java 7 already, but I am not sure what Spacewalk wants to support.
I am not a fan of legacy code just in case someone runs it on an old
platform (openssl cough cough), then the backport belongs in that git
branch, but in the case there is no
need to support Java 6, spacewalk-java.spec needs to be updated.
Hi Duncan,
Spacewalk has to support Java 6 for older operating systems like RHEL 5
and 6, so a backport would be appreciated.
-Stephen
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] IMPORTANT - Please read - Migration to github
The Spacewalk git repository is migrating to github! This will enable better community submission interaction via the github pull request process, instead of emailing patches to a mailing list where they can be missed or forgotten. As a result, you MUST update your existing git repositories to use the github Spacewalk repository as upstream instead of the fedorahosted repository. The fedorahosted Spacewalk repository will no longer be updated! The github repository should currently be identical to the fedorahosted repository, so you should be able to simply update your origin url and proceed with whatever you were doing. To update your existing repository, please run one of the following commands: git remote set-url origin g...@github.com:spacewalkproject/spacewalk.git * Upside: If you have commit access you can upload your ssh public key to your github account and not have to log in to github every time you push something * Downside: Some proxies and firewalls block the ssh ports git remote set-url origin https://github.com/spacewalkproject/spacewalk.git * Upside: Works even behind proxies or firewalls * Downside: If you have commit access you will have to log in to your github account each time you push That's it, you are done and can continue with your life! FAQ: Q: Why is my github user not credited with my past commits? A: That's probably because your github user is using a different email address than the one that they were committed under. Simply add (and verify) the other email address and then when github gets around to it they'll recalculate things and attribute your commits to you. https://help.github.com/articles/why-are-my-commits-linked-to-the-wrong-user#the-past-is-history Q: What if my github user has write access to Spacewalk but I specifically want this clone to be read-only? A: You... can't. The closest you can come is to use the https url above so that you would be forced to manually type in your username / password to push back upstream. That will at least prevent accidents. And really that's not so different from a read-only url, because if you really wanted to you could always change the read-only url and then push from anywhere. Just use the https url and if it asks for your credentials you'll know you've done something wrong. Q: What if I had write access to the fedorahosted repository and now I don't to the github repository? A: Email me and I'll get you set up. -Stephen Herr ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] On quality of patches
On 01/30/2014 07:32 AM, Duncan Mac-Vicar P. wrote: I fully agree with you that this is not acceptable. Now, I think your diagnostic is IMHO neither fair or correct. This does not have to do with the community contributions but with the setup of the project itself. We sometimes have sent patches that are very strictly reviewed, sometimes needing change multiple times to get a reviewer happy. Then next day our internal testsuite fails only to realize that someone with direct commit access did a big refactoring and committed very broken code in a big patch that was not reviewed by anyone and which quality was also obviously not the best. We asked ourselves, what is the point of reviewing some of them?. Not only code but also design decisions and way of approaching solutions. Sometimes this happens with our own patches, depending on the reviewer, they may get committed faster. The setup of the review process is broken. - All code should be committed in similar units (features/branches) - All code should be able to be reviewed and vetoed by everyone OpenStack has this model working quite successfully. Every patch is reviewed with +1, and they need a certain amounts of ACKS to get committed. Everyone can review and people learn in the process, and it is a great source of inspiration for other projects. For what it's worth I agree with Duncan. I think that having a consistent process requiring multiple reviews for all changes could only improve code quality and make Spacewalk more accessible to community contributors. The process Duncan describes is very common among modern open source projects and seems to work well. -Stpehen ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] Fix NPE when uploading kickstart profile
Ah, yeah thanks for catching that. The patch makes perfect sense. Committing as: 4003937da4077c674d6b60b52a506da5728a37ef -Stephen On 12/18/2013 05:39 AM, Johannes Renner wrote: Hey, we found that one of your recent bugfixes (see 009fab0) causes a NPE when trying to upload a kickstart profile with Virtualization Type set to None. Consider to apply the attached patch after review to fix the problem. Thank you, Johannes ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [Patch] Client registration via proxy crashes
Hi Flavio, Unless I'm mistaken the patch attached to your second email is the same as the patch in your first. Want to send me the second one before I commit it? -Stephen On 12/17/2013 09:12 AM, Flavio Castelli wrote: On 17/12/13 10:17, Flavio Castelli wrote: Fixed an error raised during the client registration via proxy when 'X-RHN-IP-Path' header is not set. This regression has been introduced by commit 251005196b02b. I found another issue later in the same part of the code. If you want I can merge the two patches into a single one. Cheers Flavio ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [Patch] Client registration via proxy crashes
These changes all look reasonable, committed as 70e86d8d47cc87bf7e2335489f4735e01bd90341 Thanks! -Stephen On 12/17/2013 10:41 AM, Flavio Castelli wrote: On 17/12/13 15:47, Stephen Herr wrote: Unless I'm mistaken the patch attached to your second email is the same as the patch in your first. Want to send me the second one before I commit it? You are right. That's the right patch I indented to send. Cheers Flavio ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Contribution: Normalization Script
Hi Austin, I have reviewed you script. Generally we would ask for patch files that we could apply, but in this case since the entire change is just the addition of a file then simply providing the URL is fine. In the future when doing command-line scripts in python you may want to look into using the argparse (or optparse if it has to run on python 2.7, which spacewalk scripts generally should be able to do since it we build packages for RHEL 5) libraries for managing the command-line arguments. They enable you to create and use the arguments you need in a much more flexible, powerful, and user-friendly way. The decision of wheither or not to use an external library is always an ongoing one for a developer, a good developer will know when to use a library to solve the problem at hand and which one to use. Of course that requires knowing what is available, a task which is never complete. This is a suggestion only, if you chose not to bother with optparse that for this program that is fine. Usage examples never go amiss, especially when it is not clear what an particular argument is or what format it should be. For example the server argument, should that be just hostname of the Spacewalk server? In this particular case you were expecting the user to pass in something like https://$hostname/rpc/api; to connect to Spacewalk's public API. A Spacewalk developer might be expected to know that url, but a user of the tool should not have to. You should update it to expect only the hostname of the Spacewalk server (and if you had used a library like argparse we could have even specified a default of 'localhost'). It is generally good practice to follow the style of other code in whatever project you are contributing to. Python developers in particular care a lot about code format, probably because spacing matters in Python. When in doubt follow the python style guide. http://www.python.org/dev/peps/pep-0008/ In paricular I'm refering to the usual 4 spaces for indentation, where you use 8. It's not a huge deal, but having code that looks the same from file to file aids in the readability and ease of maintenance for the developers. Finally, code should handle known problem cases whenever possible. You mention in the comments, The systems in the group MUST be different from the target or else the sync will fail and the script exit. If that's a known issue then why not catch the error if it occures and continue syncing the rest of the systems? In this case the error occuring means literally that there is nothing to do for that server, so there is no harm in catching it and continuing on. If you would be willing to make the changes mentioned in the last three paragraphs I would be happy to commit it. Thanks! -Stephen On 12/02/2013 09:16 PM, Austin Lavinghouse wrote: I just finished writing testing a script that, given a group, will sync every system in that group with a target system. This script was written for my senior thesis. What's the proper way to contribute it such that it can be added to the spacewalk/scripts directory? You can view the script here: turing.cs.olemiss.edu/~aelaving/normalize.py Any comments or critiques would be most appreciated. Thanks, A. E. Lavinghouse ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Newbie trying to test my code changes
Oh, and upon re-reading I realized: You can't skip spacewalk-java-lib. That's the rpm that contains all the really important stuff. What client are you breaking by installing it? Another thing to consider is that if you installed the Spacewalk 2.0 rpms you probably want to be making your changes on top of the SPACEWALK-2.0 branch, not master. The code in master may have been updated to rely on changes made in other packages, for example the database schema, and may break if installed on a 2.0 system. Once you have your changes working on the SPACEWALK-2.0 branch it would probably be a clean merge over to master. -Stephen On 11/11/2013 02:10 PM, Stephen Herr wrote: Hi Austin, Assuming that you really are sucessfully building and installing the rpm, the only thing that occures to me is that you should restart the tomcat service (probably 'tomcat6' or 'tomcat' depending on your setup). This forces it to reload cached content. In general that's a fine approach to take. /var/log/httpd/error_log and /var/log/tomcat/catalina.out are some error logs it might be very useful for you to watch when you're testing your changes. In the former you'll generally see exceptions generated in the python and perl layers, in the latter you'll see exceptions generated in the java layer. -Stephen Herr On 11/11/2013 12:21 PM, Austin Lavinghouse wrote: Hello there, first time user. I'm trying to test my changes to the code by building from source, but I can't figure out how to do so. I've gotten as far as using 'tito build --test --rpm in spacewalk/java as per https://www.redhat.com/archives/spacewalk-list/2013-February/msg00052.html. My test to see if I am working from my updated code has been to git rm EnabledListSetupAction.java, and commit the change to git. Then I run tito build --test --rpm in spacewalk/java, and rpm -ivh --replacefiles the resulting packages (skipping the spacewalk-java-lib package, because that breaks the client even without my changes). After I start Spacewalk back up, navigating to /rhn/users/ActiveList.do still functions. It is my understanding that without EnabledListSetupAction (as per https://fedorahosted.org/spacewalk/wiki/TracingaPage) this should no longer work. Any help with this specific line of thinking would be greatly appreciated, but, more generally, how do I build the project to test my changes to the code? My senior thesis is to make a contribution to the project, but I'm having the hardest time just setting up an environment where I can make changes - see results, and I only have 3 weeks left. Thank you for your time, Austin E. Lavinghouse PS- If I'm doing anything wrong re: formatting, mailing list etiquette, please let me know! ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] Fix navigation for the default snippets page
On 11/05/2013 05:07 AM, Johannes Renner wrote: On 11/04/2013 05:52 PM, Stephen Herr wrote: Hi Johannes, On 11/04/2013 10:05 AM, Johannes Renner wrote: Further I wonder if we shouldn't go to the Default Snippets page per default once a user navigates to Systems - Kickstart? At least to me it appears odd to end up on the 2nd of three tabs there. You could consider to apply the second patch as well. I would vote against doing this actually. It may be unusual, but we do the same thing other places in the UI. Another example would be the 'Software' tab of a system's details. The default tab should be whichever tab people want to use the most. That may mean that we should move the default tab to be always the first tab, but I don't think we should determin which tab is default based on their current order. I'm not motivated enough to change this the other way right now either. :) I'm motivated enough while I'm at it already.. I surely agree that the default should be what people want to use the most. So assuming that you are right in the fact that in this case it is the custom snippets, here is a patch reordering those tabs. Thank you, Johannes ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel Heh, fair enough. Committed as fd207afe0ae8a9415d96fca52167f2302df8f466. Thanks! -Stephen ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] Make taskomatic max memory configurable via rhn.conf
On 09/13/2013 06:07 AM, Johannes Renner wrote: Hello, the attached patch is supposed to enable users to override the taskomatic config option 'wrapper.java.maxmemory' via the global rhn.conf file. As the key I chose 'taskomatic.maxmemory', but feel free to propose something else in case you don't like it. Some of our users had issues with the default value of 1024 and increasing the value fixes their problems. Further, since nobody is supposed to edit the default config files in /usr/share/rhn/config-defaults/, there is a necessity for such a patch. I hope you like the idea. Regards, Johannes ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel Hi Johannes, Yes, agreed that it's a common issue. Your patch works great, committing as c416a5942562849cc1f1122cfc003423772dfdd0. Thanks! -Stephen ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] pltcl question
On 09/11/2013 08:28 AM, Jan Pazdziora wrote: On Wed, Sep 04, 2013 at 09:41:15AM +0200, Silvio Moioli wrote: We recently stumbled in some failing tests downstream and we were wondering why it was chosen to use pltcl in the new logging schema I've decided it was the optimal solution for the task. Faster than temporary tables, less invasive than custom_variable_classes. Problems arise because: - pltcl global variables are used [1]; That's the goal. - Postgres allocates a new Tcl interpreter for each database connection [2]; - thus, each connection will have its independent set of Tcl global variables; That's the hope. We use it for the logging purpose and wouldn't want the sessions to influence each other. - Hibernate will by default release a database connection after a transaction has ended [3]; Which for typical web application request handling is what you want, isn't it? The whole request processing is one transaction and releasing it gives you nice cleanup. Of course, you could change the mode to ON_CLOSE if your really wanted. Normally the case yes, but there are at least a couple of instances where we commit a single request as multiple transactions to avoid overrunning Oracle's rollback buffer. One example that jumps to mind is generating yum repodata for channels. I'm not sure if that's relevant to this discussion or not, I just saw that comment and thought I'd chime in. -Stephen - thus, any database operation occurring after, for example, a call to ConnectionManager.commitTransaction(), could get a different connection from the one used before the COMMIT; Does it happen in our code base? We tried to catch and fix all such occurences. - possibly, this different connection could be completely new - in that case no global variables are set; - the above could also not happen if, in lucky cases, the same connection is reused but this is (at least) Hibernate, c3p0, context, JVM and load dependent. Actually, there is not a lot of places in the Spacewalk codebase where database operations are carried out after a COMMIT, nevertheless in those cases trouble can happen. For example we found out that DELETE queries on web_contact will fail on a new connection, because web_contact_log_trig will call logging.get_log_id() that will in turn call logging._get_log_id() which would raise an exception due to the global variable the_log_id not being initialized. In our case, this after-commit user deletion happens in BaseTestCaseWithUser.tearDown() - OrgFactory.deleteOrg() - rhn_org.delete_org() - rhn_org.delete_user() which is called because ChannelManagerTest.testListCompatibleBaseChannels() commits in the middle. This is in tests, right? They need to be fixed to properly initialize the auth info in the logging infrastructure. Questions: - is it really necessary to track variables per _database connection_ in the logging package? Is there any other way to get the id of the authenticated user or of the logging event in say an AFTER DELETE TRIGGER? Since connections should be handled in a completely transparent way by Hibernate sessions, I believe this should not happen; Our hope, supported by testing, is that even Hibernate is not so bold to run part of its session using one database session and the other part using other session. In other words, underneath Hibernate session, there is still a RDBMS with its own notion of sessions and Hibernate respects that. - is it really necessary to add the pltcl language and use globals? No to the first part (we could use some other way), I did not find a better way to the second part. Wouldn't a simple database sequence or even plain table suffice? The problem I faced with database sequences was, I did not find an easy way to invalidate the currval. With the existing logging infrastructure, we clear the log_id after we are done with it so if the database session gets reused, the application logic needs to reinitialize it or things will fail (basically, what you see in the failing tests). That is a feature -- we do not want the log_id from the previous HTTP request which happened to be handled by application that used our database sessions previously to leak to the subsequent operations. As for plain tables -- I don't think it would work. How would you know in that AFTER DELETE TRIGGER which record in the table is yours? And if you did not COMMIT and depended on there being only one record (the one that your session inserted), how would it work if the application decided to ROLLBACK? And if the application COMMITed by mistake, the assumption of there only being one record would immediately break. I see the following possible solutions: - adopting another way to keep the log counter, possibly at transaction or whole database level; It's not about the log counter. There is a sequence there alright. It's about being able to access in reliable way value which was instantiated in the same
Re: [Spacewalk-devel] [PATCH] Make CSV Separator Character Configurable
I don't necessarily have a problem with the idea, but I will comment that CSVs are by definition Comma Separated Value files. Excel and every other spreadsheet in the world should have an option to import from comma-separated lists. If we do want to change the delimiter then we should call it something other than *.csv. -Stephen On 08/19/2013 08:21 AM, Johannes Renner wrote: Hey, here is a small feature patch that allows users to choose semicolon (;) as an alternative to comma (,) for the delimiter in all downloadable CSV files that we generate from the webapp. This seems to be helpful for importing those files into MS Excel for example. Unfortunately we had to hack the schema source sanity check in order to not complain about a ; in the middle of a table definition. I hope you like the idea and the patch as well, let me know what you think. Thanks, Johannes ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] spacecmd do_ssm_intersect() returns a list instead of dict bug report and patch
Thanks for the patch! Reviewed and committed as e485f0a584886b8941b3ac652920541d2c5996bc. -Stephen Herr On 07/11/2013 03:33 AM, Bram Mertens wrote: Hi, Not sure if this post is necessary but I believe I found a bug in the ssm.py of spacecmd. I opened a bug report https://bugzilla.redhat.com/show_bug.cgi?id=983400 and added a patch. Note that there is likely a better solution possible, I'm not an experienced python developer, but the patch works for me. Regards Bram ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] Change spacecmd configchannel_create behavior to reflect webui.
Hi Baptiste, I reviewed and mostly accepted your patch. The only thing I changed was to keep the current behavior of spacecmd where name is a required option and label (if not provided) is the same as name. Your change would have made name optional and the new label required, and while that makes perfect sense it also breaks backwards-compatibility and would have annoyed users who use spacecmd in their scripts. Committed to Spacewalk master as d182cc2601ba20a9ad2e6913821d00402da6c513. Thanks for the patch! -Stephen On 04/16/2013 12:12 PM, Baptiste AGASSE wrote: Hi, Just a small patch to spacecmd to add -l/--label option to configchannel_create command. The current behavior of the command is to ask a name and set label and name to this value, but label is more restrictive than name (for labels, only alphanumeric characters, '-', '_', and '.' are allowed). With this patch, the label must be provided, and name is set to label value if name is not provided. Have a nice day. Regards. --- Baptiste AGASSE Lyra Network, Service Systèmes et Réseaux Rue Carmin, BP 87350, 31673 Labège Cedex - France Tél: (+33)5.67.22.31.87 Fax: (+33)5.67.22.31.61 Mail: baptiste.aga...@lyra-network.com Site: http://www.lyra-network.com ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] Add update_date option in spacewalk-clone-by-date
Hi Paresh, Patch accepted as Spacewalk master commit 3f8e200c4ee6aa1fab10bdfe4bdaf27b641c4f28. Thanks! -Stephen Herr On 04/03/2013 11:41 AM, Paresh Mutha wrote: Hello, Attached is the proposed patch to add update_date option in spacewalk-clone-by-date. (spacewalk bz#947942) Currently spacewalk-clone-by-date refers the issue_date of the errata. But web-ui displays update date. With the attached patch spacewalk-clone-by-date utility can now use update date of errata which will help bring uniformity between the channel cloned to specific date using cli and web-ui. Appreciate your feedback. Once this gets accepted will work on updating the man page of spacewalk-clone-by-date. Regards, Paresh ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Spacewalk 1.9 Released
Hello everyone, It is my pleasure to announce that Spacewalk 1.9 is now available. The release notes are available here: https://fedorahosted.org/spacewalk/wiki/ReleaseNotes19 -Stephen Herr ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Branch for Spacewalk 1.9 has been created
Hi everyone, We have a new branch, SPACEWALK-1.9, to track our next release of Spacewalk. Spacewalk nightly builds will now be for Spacewalk 1.10. -Stephen Herr ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Spacewalk 1.9 release candidate
Hello everyone, Tonight's build of Spacewalk nightly is a release candidate for Spacewalk 1.9. Any testing or verification of bugs that you can do would be greatly appreciated and help us turn Spacewalk 1.9 into a very high quality release. Thank you. -Stephen Herr ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Spacewalk 1.9 release candidate
Hi Edson, The packages have been built but we will have to wait for the yum repodata to rebuild before they are truly available. That should happen tonight, so the packages will be available tomorrow. -Stephen On 03/02/2013 12:28 AM, Edson Manners wrote: Great news Stephen. I was just looking around the spacewalk site for a changelog for 1.9. Is it available or not ready as yet? On 3/1/13 12:03 PM, Stephen Herr wrote: Hello everyone, Tonight's build of Spacewalk nightly is a release candidate for Spacewalk 1.9. Any testing or verification of bugs that you can do would be greatly appreciated and help us turn Spacewalk 1.9 into a very high quality release. Thank you. -Stephen Herr ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Spacewalk 1.9 release candidate
Oh, my mistake. I have not generated the changelogs yet, I will let you know when they are ready. -Stephen On 03/02/2013 01:06 AM, Edson Manners wrote: Thanks Stephen but I don't mind waiting for the packages. I was actually looking for the changelog showing expected differences between 1.8 and 1.9. Or am I misunderstanding your point that I'd have to get the changelogs at the individual RPM level for the complete list of changes? On 3/1/13 12:57 PM, Stephen Herr wrote: Hi Edson, The packages have been built but we will have to wait for the yum repodata to rebuild before they are truly available. That should happen tonight, so the packages will be available tomorrow. -Stephen On 03/02/2013 12:28 AM, Edson Manners wrote: Great news Stephen. I was just looking around the spacewalk site for a changelog for 1.9. Is it available or not ready as yet? On 3/1/13 12:03 PM, Stephen Herr wrote: Hello everyone, Tonight's build of Spacewalk nightly is a release candidate for Spacewalk 1.9. Any testing or verification of bugs that you can do would be greatly appreciated and help us turn Spacewalk 1.9 into a very high quality release. Thank you. -Stephen Herr ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Should spacewalk-clone-by-date be allowed to merge channels?
On 12/20/2012 03:53 PM, Stephen Herr wrote: Hey everyone, https://bugzilla.redhat.com/show_bug.cgi?id=838122 needs a wider audience / consideration. First there are problems with the bug itself, as it appears to be about two different issues (see comment 10). However one of the issues (and the one that is currently receiving attention) is that a customer would like to be able to use the tool to merge a parent channel and several of its children into a grand unified cloned channel. As far as I can tell we have never allowed merging multiple channels into a single clone, and it may be that we've only allowed transitioning from child to base as an accident (it currently works from the API, see comment 13). What are some problems / complications that can arise from merging a channel tree down into a single channel like this? Is this something that we should allow? -Stephen Now that everyone is back from the break I'm hoping to revive this conversation. This RFE is the last one in the list of spacewalk-clone-by-date issues. -Stephen ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Should spacewalk-clone-by-date be allowed to merge channels?
Hey everyone, https://bugzilla.redhat.com/show_bug.cgi?id=838122 needs a wider audience / consideration. First there are problems with the bug itself, as it appears to be about two different issues (see comment 10). However one of the issues (and the one that is currently receiving attention) is that a customer would like to be able to use the tool to merge a parent channel and several of its children into a grand unified cloned channel. As far as I can tell we have never allowed merging multiple channels into a single clone, and it may be that we've only allowed transitioning from child to base as an accident (it currently works from the API, see comment 13). What are some problems / complications that can arise from merging a channel tree down into a single channel like this? Is this something that we should allow? -Stephen ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] proposed for rhncfg in nightly repo to check stat of local file instead of temp file
Oops, sorry about the empty email. Yes, there will be a command line option. rhncfg-client diff will now have a -d or --diff-secure-files option that you can specify to get the old behavior. There will also be an option that you can set permanently in /etc/sysconfig/rhn/rhncfg-client.conf. This will be available in rhncfg-5.10.27-10-sat and up. -Stephen On 11/30/2012 01:29 AM, Mullis, Josh (CCI-Atlanta) wrote: Good day, While this is a good idea, we at least need the option to display a diff regardless. It's an important piece of config mgmt / file integrity mgmt in knowing what changes were made to a file that was replaced. Is there a command line flag that will allow this? Thanks! -josh -Original Message- From: spacewalk-devel-boun...@redhat.com [mailto:spacewalk-devel-boun...@redhat.com] On Behalf Of Michael Mraka Sent: Monday, October 29, 2012 9:47 AM To: spacewalk-devel@redhat.com Subject: Re: [Spacewalk-devel] [PATCH] proposed for rhncfg in nightly repo to check stat of local file instead of temp file Paresh Mutha wrote: % Hello, % % Commit 7a18b250b07ff4ed0c34fa48e69029c114ec3ab1 introduced the check % on ownership permission of the config file so that it doesn't % log/display the diff it the config file is not readable by all. % % Here it is checking the stat for source. But source is always the % temp file which is created based on the config file content received % from the Server and it is always under root ownership and not % readable by all. Thus for all config files which are not owned by % root or are readable by all, the diff result is not displayed. % Instead there is the message Differences exist in a file that is % not readable by all. Re-deployment of configuration file is % recommended % % Attached is the proposed patch to check the stat of dst i.e the file % present on the system. With this change, for the files which are % readable by all the actual diff result would be displayed. You're correct :). Reviewed and pushed patch. Thanks. % Regards, % Paresh -- 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 mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Rationale for rhncfg-actions should not log the diff of files that are not readable by all
On 11/08/2012 10:34 AM, Parsons, Aron wrote: Can anyone explain the rationale behind commit 7a18b250b07ff4ed0c34fa48e69029c114ec3ab1? I do not have access to the BZ that it references. I don't see the security implications of generating a diff for a non-world-readable file. Unauthorized users can't read the file on the system This did not used to be true. We were generating diffs of every file and placing them in a readable-by-anyone log file. In bug 824707 we fix this problem by 1) Not diffing files that are not readable by all in 7a18b250b07ff4ed0c34fa48e69029c114ec3ab1 and then we also 2) Made the log file only readable by root in 0cb9f801bfc073cd68111868014219407b73f9f9 Both are probably not necessary, but the feeling at the time was better safe than sorry. -Stephen and you need to have access to the system in Spacewalk to view the output. Is there another scenario that makes returning the diff insecure? /aron ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] Script contents not properly displayed
Hi Johannes, Can you please give me more information on the system where you are experiencing this problem? We had a bug with identical symptoms where the root cause was that the defaults on how a particular object was stored (as ascii or as hex) in Postgresql changed in newer versions of the database. If that is the root cause of your problem, then it would not be safe to simply assume that we will always get hex back and expand it out to ascii, because that would generate errors for people who are running older versions of Postgresql. My cursory search has not turned up the original bug, but I will keep looking. -Stephen On 08/14/2012 06:18 AM, Johannes Renner wrote: Hello, we found out that script contents are not properly displayed in the web UI in Systems - Events - History (it's a perl page ...). To reproduce: - choose a system and go to Remote Command - type in some script contents, e.g. a b c d e f g h - schedule the command - go to Events and click on the one just scheduled - in the Details you will see (for the example above): x23212f62696e2f73680a0a61206220632064206520662020672068 which is the ASCII code for #!/bin/sh a b c d e f g h The attached patch fixes the problem by converting the ASCII codes into a string using the pack() function. Regards, Johannes ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] Script contents not properly displayed
Johannes, Could you ensure in /usr/share/pgsql/postgresql.conf that bytea_output = 'escape', and if not see if that corrects your problem? -Stephen On 08/14/2012 08:57 AM, Stephen Herr wrote: Hi Johannes, Can you please give me more information on the system where you are experiencing this problem? We had a bug with identical symptoms where the root cause was that the defaults on how a particular object was stored (as ascii or as hex) in Postgresql changed in newer versions of the database. If that is the root cause of your problem, then it would not be safe to simply assume that we will always get hex back and expand it out to ascii, because that would generate errors for people who are running older versions of Postgresql. My cursory search has not turned up the original bug, but I will keep looking. -Stephen On 08/14/2012 06:18 AM, Johannes Renner wrote: Hello, we found out that script contents are not properly displayed in the web UI in Systems - Events - History (it's a perl page ...). To reproduce: - choose a system and go to Remote Command - type in some script contents, e.g. a b c d e f g h - schedule the command - go to Events and click on the one just scheduled - in the Details you will see (for the example above): x23212f62696e2f73680a0a61206220632064206520662020672068 which is the ASCII code for #!/bin/sh a b c d e f g h The attached patch fixes the problem by converting the ASCII codes into a string using the pack() function. Regards, Johannes ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] New column 'mac_address'
On 07/10/2012 04:31 AM, Johannes Renner wrote: Hey, I just saw in commit 8a0662e (Allow user to set MAC Address when provisioning a virtual guest), that there is a new database migration script (109-rhnactionkickstartguest...), but the initial creation of this table was not modified. Shouldn't the initial creation also add the 'mac_address' column? Thanks, Johannes Yes it should. Good catch. -Stephen ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] 798571 - Timezone definitions outdated for russian TZs
On 07/03/2012 10:15 AM, Marcelo Moreira de Mello wrote: On 07/03/2012 07:01 AM, Jan Pazdziora wrote: On Mon, Jul 02, 2012 at 05:12:58PM -0300, Marcelo Moreira de Mello wrote: Hello team, Here follow a patch which fixed the issue reported on BZ#798571. Marcelo, are we sure that it's just the description change that is needed? Do the timezones otherwise work as expected on both Perl and Java stacks, or is some logic change needed as well? Hello Jan, I thought the same when I was changing the code. Then, I checked the git changelog and saw some commits which only changed the description (0518d03935bdefa5cf0a1e5b76b7f44105eaf6f2 per example). Looking the commit b77210efc1f39fbb095f47b8c67580045b4b6165, it seems that the trick to the Perl and Java stacks seems to use the timezone description (such as America/Sao_Paulo). After changing the code, the webUI displayed the Russian time using GMT+4 as expected. Best Regards, mmello Hi guys, I can't speak for anything else, but 0518d039 was a special case. In that bug the time zones were operating properly and adding the correct number of hours to GMT to get the time, but the text in the string resource file was incorrect. You shouldn't use that as a model unless the same is true of the time zones you are looking at. -Stephen ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] YUM RHN Lock Plugin
On 06/14/2012 03:37 PM, Jan Hutař wrote: On Wed, 13 Jun 2012 08:49:46 -0400 Musayev, Ilya imusa...@webmd.net wrote: That is correct. You can also install via RPM. If I'm not mistaken, --noplugings will also cut off rhn-plugin and therefore there will be no rhn repos. Ideally, it would be nice to integrate RHN LOCK with rhn-yum-plugin. That way if system locked - it is truly locked from both aspects (GUI and CLI) and you would not be able to disable lock independently. Hello, of course, yum have --disableplugin=[plugin] as well. What I wanted to say is: that plugin might be creating some false feeling of something being disabled/secured. If it is meant more do not incidentally install packages on locked system, then it is OK. Regards, Jan I believe this is exactly why Ilya wants this integrated with rhn-yum-plugin, so that it could not be disabled separately. -Stephen ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] small license issues
On 05/31/2012 08:43 AM, Michael Calmer wrote: 1) rhnpush declared GPL v2 but no COPYING file Would you add a COPYING file please? 2) spacewalk-setup license mix The spec file states that the package is licensed under GPLv2. However, the README implies that the package is actually licensed under the same terms as Perl, means Artistic License. If this is true please say in specfile GPLv2 or Artistic-1.0 and provide the COPYING and the Artistic License files with the package. 3) spacewalk-reports declared GPLv2 but contains no COPYING file Would you add a COPYING file please? 4) spacewalk-utils declared GPLv2 but contains GPL-3.0+ licensed script Please verify and change the spec to GPLv2 and GPLv3+ and provide both COPYING files with the package. I've created a bug to track these problems, I'll work on getting them fixed today. https://bugzilla.redhat.com/show_bug.cgi?id=827022 -Stephen ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] small license issues
On 05/31/2012 09:03 AM, Stephen Herr wrote: On 05/31/2012 08:43 AM, Michael Calmer wrote: 1) rhnpush declared GPL v2 but no COPYING file Would you add a COPYING file please? 2) spacewalk-setup license mix The spec file states that the package is licensed under GPLv2. However, the README implies that the package is actually licensed under the same terms as Perl, means Artistic License. If this is true please say in specfile GPLv2 or Artistic-1.0 and provide the COPYING and the Artistic License files with the package. 3) spacewalk-reports declared GPLv2 but contains no COPYING file Would you add a COPYING file please? 4) spacewalk-utils declared GPLv2 but contains GPL-3.0+ licensed script Please verify and change the spec to GPLv2 and GPLv3+ and provide both COPYING files with the package. I've created a bug to track these problems, I'll work on getting them fixed today. https://bugzilla.redhat.com/show_bug.cgi?id=827022 -Stephen Or maybe not today, since this is not as urgent as I thought it was. -Stephen ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] spacewalk-search declared as GPL-2.0 but contains Apache licenses
On 05/31/2012 09:11 AM, Johannes Renner wrote: Hello, the 'spacewalk-search' package is (according to spacewalk-search.spec) licensed as GPLv2, but apparently it contains numerous Apache licenses throughout the files listed below. The GPL-2.0 and the Apache licenses are not compatible with each other, according to the Free Software Foundation:http://www.gnu.org/licenses/license-list.html#apache2. This does most likely not pose a problem for the package, as the files appear to be mostly content as opposed to code. Could you still please confirm that the Apache licensed files are not actually being linked with GPL files? I guess you would have to add both license texts to the package and it should be reflected in the specfile (spacewalk-search.spec) as well: License: GPLv2 -- License: GPL-2.0 and Apache-2.0 Thank you, Johannes Renner Please see the list of files here: spacewalk-search-git-0.fd73b43/buildconf/tempjars/hadoop-0.18.1-core/bin/hadoop spacewalk-search-git-0.fd73b43/buildconf/tempjars/hadoop-0.18.1-core/bin/hadoop-config.sh spacewalk-search-git-0.fd73b43/buildconf/tempjars/hadoop-0.18.1-core/bin/hadoop-daemon.sh spacewalk-search-git-0.fd73b43/buildconf/tempjars/hadoop-0.18.1-core/bin/hadoop-daemons.sh spacewalk-search-git-0.fd73b43/buildconf/tempjars/hadoop-0.18.1-core/bin/rcc spacewalk-search-git-0.fd73b43/buildconf/tempjars/hadoop-0.18.1-core/bin/slaves.sh spacewalk-search-git-0.fd73b43/buildconf/tempjars/hadoop-0.18.1-core/bin/start-all.sh spacewalk-search-git-0.fd73b43/buildconf/tempjars/hadoop-0.18.1-core/bin/start-balancer.sh spacewalk-search-git-0.fd73b43/buildconf/tempjars/hadoop-0.18.1-core/bin/start-dfs.sh spacewalk-search-git-0.fd73b43/buildconf/tempjars/hadoop-0.18.1-core/bin/start-mapred.sh spacewalk-search-git-0.fd73b43/buildconf/tempjars/hadoop-0.18.1-core/bin/stop-all.sh spacewalk-search-git-0.fd73b43/buildconf/tempjars/hadoop-0.18.1-core/bin/stop-balancer.sh spacewalk-search-git-0.fd73b43/buildconf/tempjars/hadoop-0.18.1-core/bin/stop-dfs.sh spacewalk-search-git-0.fd73b43/buildconf/tempjars/hadoop-0.18.1-core/bin/stop-mapred.sh spacewalk-search-git-0.fd73b43/buildconf/tempjars/ibatis-2.3.0.677/com/ibatis/sqlmap/engine/builder/xml/sql-map-2.dtd spacewalk-search-git-0.fd73b43/buildconf/tempjars/ibatis-2.3.0.677/com/ibatis/sqlmap/engine/builder/xml/sql-map-config-2.dtd spacewalk-search-git-0.fd73b43/buildconf/tempjars/ibatis-2.3.0.677/license.txt spacewalk-search-git-0.fd73b43/buildconf/tempjars/lucene-analyzers-2.3.2/META-INF/LICENSE.txt spacewalk-search-git-0.fd73b43/buildconf/tempjars/lucene-core-2.3.2/META-INF/LICENSE.txt spacewalk-search-git-0.fd73b43/buildconf/tempjars/nutch-2008-12-01_04-01-21/nutch-default.xml spacewalk-search-git-0.fd73b43/nutch/crawl_jsp/conf/automaton-urlfilter.txt spacewalk-search-git-0.fd73b43/nutch/crawl_jsp/conf/common-terms.utf8 spacewalk-search-git-0.fd73b43/nutch/crawl_jsp/conf/configuration.xsl spacewalk-search-git-0.fd73b43/nutch/crawl_jsp/conf/context.xsl spacewalk-search-git-0.fd73b43/nutch/crawl_jsp/conf/crawl-tool.xml spacewalk-search-git-0.fd73b43/nutch/crawl_jsp/conf/crawl-urlfilter.txt spacewalk-search-git-0.fd73b43/nutch/crawl_jsp/conf/domain-suffixes.xml spacewalk-search-git-0.fd73b43/nutch/crawl_jsp/conf/domain-suffixes.xsd spacewalk-search-git-0.fd73b43/nutch/crawl_jsp/conf/nutch-default.xml spacewalk-search-git-0.fd73b43/nutch/crawl_jsp/conf/parse-plugins.xml spacewalk-search-git-0.fd73b43/nutch/crawl_jsp/conf/prefix-urlfilter.txt spacewalk-search-git-0.fd73b43/nutch/crawl_jsp/conf/regex-normalize.xml spacewalk-search-git-0.fd73b43/nutch/crawl_jsp/conf/regex-urlfilter.txt spacewalk-search-git-0.fd73b43/nutch/crawl_jsp/conf/subcollections.xml spacewalk-search-git-0.fd73b43/nutch/crawl_jsp/conf/tika-mimetypes.xml spacewalk-search-git-0.fd73b43/scripts/lukeall-0.8.1/META-INF/LICENSE.txt spacewalk-search-git-0.fd73b43/scripts/lukeall-0.8.1/xml/about.xml spacewalk-search-git-0.fd73b43/task-lib/commons-beanutils-1.7.0/META-INF/LICENSE.txt spacewalk-search-git-0.fd73b43/task-lib/commons-logging-1.0.4/META-INF/LICENSE.txt spacewalk-search-git-0.fd73b43/task-lib/commons-logging-1.0.4/org/apache/commons/logging/impl/package.html spacewalk-search-git-0.fd73b43/task-lib/commons-logging-1.0.4/org/apache/commons/logging/package.html Hi Johannes, I have added your issue to an existing licensing issue bug for tracking: https://bugzilla.redhat.com/show_bug.cgi?id=827022 -Stephen ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] fixing dead links in list
Hi Michael, Patch looks great, thank you! Submitted to Spacwalk master as df622ac01f986a611d6ce26d00796d2eec7bc415. -Stephen Herr On 04/13/2012 10:25 AM, Michael Calmer wrote: Hi, I found a page with links to not existing pages. Overview = Subscription Management = Software Channel Entitlements = click on a number in Systems Subscribed column You see a page with a list of all Systems which uses this entitlement, but if you click on the Errata or Package Number you end up in a not existing page. The attached patch should bring you to the java pages. ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] enhancement for spacecmd
On 04/04/2012 01:56 PM, Miroslav Suchý wrote: Can somebody (Steven or Aron) review this patch please?: https://bugzilla.redhat.com/show_bug.cgi?id=809905#c0 Patch looked great, so I committed to Spacewalk master. -Stephen ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Policy for collections and generics?
On 04/02/2012 05:17 AM, Duncan Mac-Vicar P. wrote: Hi, I see that in lot of places collections are used without generics (1000+ warnings). What is the view on this? are patches in the direction of using generics for compile-time errors wanted? if yes, can this be a bit of a flood of patches for review? Hi Duncan, I personally would love to see patches for the generics warnings. I would be happy to review these patches, no matter how many of them there are. -Stephen ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
