Re: [Spacewalk-devel] Spacewalk got forked?! WTF is going on?!
Neal Gompa writes: > Something is seriously wrong here. > > Today, I woke up to the news that SUSE forked Spacewalk[0] into Uyuni[1] > (which frankly, is a hard name to say...). The explicit reason they gave > for this was that despite requests to the community to step up to take over > the Spacewalk project, the current Spacewalk leadership refused SUSE's > offer to lead the community. > > To me, something sounds fishy about this, because I've historically known > Red Hat folks to be very much community-first, so if Red Hat as a company > was no longer interested in Satellite 5/Spacewalk, transitioning it to > someone else who was interested in it should have been easy. However, the > evidence they gave was pretty compelling[2]. At the same time, I have no > means of verifying whether or not what SUSE is saying is true. > > As a Spacewalk user, I'm incredibly disappointed that the leadership > managed to successfully drive away an interested party. At my scale (tens > of servers), Spacewalk serves my needs perfectly. > > However, for those who think that Uyuni will be any better, my past > experience with most SUSE teams has not been pleasant. They're usually not > the most responsive group with their open source projects (KIWI[3] > excepted). It's not a good sign that the SUSE Manager project development > didn't already exist as an open branch to begin with. Hi Neal, SUSE Manager branch was not public because it was supposed to be, just like the Satellite branches (which I understand are also not public), a product branch used for releases. The collaboration point was always intended to be Spacewalk. We never planned for our branch to start diverging. It just happened, and at this point we think SUSE Manager code-base makes up for a better "master" branch. > A splinter in the small development community around Spacewalk sucks, and > the cursory glance at Uyuni seems to indicate that things are pretty broken > for non-SUSE distributions. I would kindly ask you to give the people working on this some compassion and benefit of the doubt. Things are not there yet. Since we realized we had to fork, we decided to use the openSUSE Conference as a deadline to make things happen from our side. I think our FAQ [1] covers some expectations about when things will be in place. Uyuni server-side targets openSUSE Leap 42.3 for now. On the client side, things should work on Redhat-like and SUSE-like systems, however, mind that we haven't yet setup things to properly test that we support anything outside what SUSE Manager officially supports. Once things are in place, we hope to take advantage of OBS, Salt and collaborators to reach as many platforms as possible. Best regards, [1] https://www.uyuni-project.org/faq.html -- Duncan Mac-Vicar P. - Director, Data Center Management; R SUSE Linux GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Stabilization of Spacewalk 2.6
Gennadii Altukhov writes: > Hello guys, > > I am starting to work on stabilization of Spacewalk 2.6 before release, > please postpone pushing your changes that might destabilize Spacewalk 2.6 or > break a build. > Please, remember that we still build spacewalk-backend-* on RHEL 5(!), that > means all python code should be compatible with Python 2.4. Hi Gennadii, Is there a good reasoning about this? Is this because spacewalk-backend is used on the client? -- Duncan Mac-Vicar P. - Director, Data Center Management; R SUSE Linux GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Python 2/3 compatibility
On 04/07/2016 06:41 PM, Gennadii Altukhov wrote: > PS Yes, I know about 'six' module, but I'm not sure we will use it. Can you explain why? -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Getting rid of Repository Checksum Type None
Hi
While fixing our testsuite to run with PhantomJS, we hit a clunky part:
- One is that when adding a channel, default checksum is sha1, parent
channel None. But:
- Changing the parent channel, triggers changing the checksum / arch
to the parent channel one
- Except if you select Parent: None again, Checksum will be None (and
not sha1) - BUG (and we can fix it and make a PR)
So to fix that bug, we found out that a None checksum makes taskomatic
silently skip that channel for metadata generation which could be very
confusing for users:
if (checksumtype == null) {
generateBadRepo(channel, prefix);
return;
}
So I was thinking to add a better log entry and may be a warning in the
channel details page, but...
If we don't generate metadata for None, and this option is not part of
checksumtype table, but manually added in the form:
ListMapString, String checksums = new ArrayListMapString, String();
addOption(checksums, ls.getMessage(generic.jsp.none), );
for (ChecksumType chType :
ChannelFactory.listYumSupportedChecksums()) {
addOption(checksums, chType.getLabel(), chType.getLabel());
}
Why not removing the None option alltogether? Does anyone see a reason
to keep it?
Regards,
--
Duncan Mac-Vicar P. - http://www.suse.com/
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu,
Graham Norton, HRB 21284 (AG Nürnberg)
Maxfeldstraße 5, 90409 Nürnberg, Germany
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] length of vip6 in SatCluster
Hi The SatCluster class has an attribute vip6 restricted to len 45 which is supposed to get filled with an ipv6 address (therefore the length, 39 or 45 for ipv4 address mapped to ipv6). However, the Java API used to get the value (getHostAddress) in my system returns the address with a zone identifier, in this case the interface: :xxx::::::%enp0s25 This does not fit. While we could extend the column to be 45 + 1 (%) + linux/if.h IFNAMSIZE (16), I wonder if we really need the zone, in that case I could just remove it in the setter setVip6. Anyone familiar with this attribute? -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ 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 07:13 PM, Matej Kollar wrote: It is a pity that this one can't be merged automatically anymore because of 8c31e63 / 3daaad01 Matej, did you replace everything with 8 spaces? It was standard retab procedure with tabstop=8. So it would be simpler to describe it as fill with spaces to the next closest multiple of 8. There might be differences for files that had explicitly set tabstop to different value. I have rebased it fixing conflicts by hand and added some commits that were added later in our internal branch. -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ 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 05:59 PM, Silvio Moioli wrote: https://github.com/spacewalkproject/spacewalk/pull/216 Among others, JSP fixes are particularly welcome to minimize downstream conflicts so I would also recommend this: https://github.com/spacewalkproject/spacewalk/pull/200 It is a pity that this one can't be merged automatically anymore because of 8c31e63 / 3daaad01 Matej, did you replace everything with 8 spaces? -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ 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 04:41 PM, Stephen Herr wrote: 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. 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. -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Java 6 required?
On 20/05/14 14:56, Stephen Herr wrote: Hi Duncan, Spacewalk has to support Java 6 for older operating systems like RHEL 5 and 6, so a backport would be appreciated. -Stephen Done, https://github.com/spacewalkproject/spacewalk/pull/74 (used a different solution, as I realized then that we need the workaround for formatting and not for parsing) -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Java 6 required?
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.
--
Duncan Mac-Vicar P. - http://www.suse.com/
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB
16746 (AG Nürnberg)
Maxfeldstraße 5, 90409 Nürnberg, Germany
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Java Script on Repositories/Sync page.
On 07/03/14 16:27, Dimitar Yordanov wrote:
Hi all,
I was working on adding several check-boxes on the Repositories/Sync page
when it turned out that the check-boxes were somehow disabled.
Channels - Manage Software channels - Some Custom Channael -
Repositories - Sync
https://sw.redhat.com/rhn/channels/manage/Sync.do?cid=102
/WEB-INF/pages/channel/manage/syncrepos.jsp
It seems it is related to the following Java Script:
script type=text/javascript
$(function() {
function toggleStatus() {
var status = $('fieldset#recurring-picker-${picker.name}
input[type=radio]:checked').val();
$('fieldset#recurring-picker-${picker.name}
.recurring-options[data-status!=' + status +
'][data-picker-name=${picker.name}]').find('select,
input').prop('disabled', true);
$('fieldset#recurring-picker-${picker.name}
.recurring-options[data-status=' + status +
'][data-picker-name=${picker.name}]').find('select,
input').prop('disabled', false);
}
$('fieldset#recurring-picker-${picker.name}
input[type=radio]').click(function() {
toggleStatus();
});
toggleStatus();
});
/script
That javascript controls that you can only edit the schedule for the
selected type only.
Where did you try to add a checkbox? May be the selector is too wide and
matches a checkbox inside the recurring picker.
Duncan
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] On picking a standard on HTML5 void tags
On 18/02/14 14:10, Michael Mraka wrote: Using self-closed tags for void elements as well as using end tags even in situations where they can be omitted in HTML5 is common agreement among whole team. They improve readability - you immediately know what was intentional and what a mistake. As for patch rejection - no, most likely the other way round :). I am fine with using self-closing tags as long as everyone is aware that using it in a non-void tag will create bad markup and understand that the browser will just remove the /'s. It happened with i class=iconclass/ already, which is wrong and invalid) In HTML5 foo/ is expanded to foo. Not to foo/foo as in XHTML. -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] Date/Time picker
Thanks for the review and fixes!. Most of it looks good except for the self-closing tag as Silvio explained. There are other changes that I would like to understand: - The css part where you override some styles (and use !important, which basically means SUSE Manager can't override it again in its css) - setting of the input size to 15 -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] editarea and apache 2.4
On 13/02/14 10:10, Michael Mraka wrote: Duncan Mac-Vicar P. wrote: Hello Duncan, Thanks for the patch. Currently we focus on Spacewalk 2.1 release so we will take a look on it after the release. Makes sense. I plan to push it for our release. If you see something totally wrong with it, it would be nice to know now, even if it is not applied for 2.1. I am fine with doing more corrections after the release but I would like to avoid something completely different. Duncan ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] On quality of patches
On 30/01/14 11:57, Matej Kollar wrote: Hi all. We welcome community contributions and we want to maintain some level of quality. Natural expectation is that every proposed patch is tested for the functionality. 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. We care about quality and you can see that we not only contributed our own testsuite in early 2011 with the first release of our own product, but then focused lot of contributions in having the testsuites enabled and working again. But all this is pointless if the process has holes. Right now it depends on a lot of luck to be useful. We suggested not long time ago in the mailing list to move to a github approach where code could be submitted only with pull-requests that need to be reviewed. Policies could be created that at least 2-3 acks is needed to merge a feature. People can study those reviews and learn in the process. Continuous integration could be setup on top of this process, to have up to date results. But what you are seeing, the process is kind of designed to produce those results, which is a process where code has different ways to arrive to master, which different quality outcomes. -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [RFC] showing timestamps in Spacewalk
On 27/01/14 15:00, Michael Mraka wrote: I've commited this part of timestamp changes with an exception of moment-with-langs.min.js file. It isn't referenced from pages (moment.min.js is), moreover it should not be in spacewalk-web but a separate package. It is referenced from the JSP tag. The tag includes the script once if the tag is used. If you don't use the JSP tag but the HTML tag manually then you have to include it yourself. Should there be already some dates translated to human readable string on pxt pages? Even if I download moment.min.js to my spacewalk I can't see any. I see date wrapped with time/time but no translation (e.g. on /network/systems/details/history/pending.pxt). No, I did some examples but did not include them in the patch. I think case by case we should define if for a displayed date it makes more sense the calendar or ago style. -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] less.js development mode broken
On 14/01/14 10:36, Silvio Moioli wrote: On 01/13/2014 03:18 PM, Michael Mraka wrote: Ok, I've changed the path back for you. JFI: I pushed a further small fix in 27076678423180d1226f407bdd342e127cc5e017, namely using the absolute path instead of the relative one, otherwise the URL https://HOST_NAME/css/bootstrap/less/bootstrap.less would be used resulting in a 404 error. Regards, I know I gave you the tip of the absolute path to you but there is something I did not see: our lesscss-engine does not support search paths, therefore in now looks in /. and spacewalk-branding does not build. May be the combination that works for both is: Upstream: spacewalk.less import relative bootstrap/less... apache alias: /css/bootstrap /usr/share/bootstrap branding package: search path, /usr/share Manager: spacewalk.less same apache alias: /css/bootstrap /usr/share/susemanager-frontend-libs/bootstrap branding package: symlink bootstrap to /usr/share/susemanager-frontend-libs/bootstrap -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] perl List port to new css/markup
On 09/01/14 15:40, Duncan Mac-Vicar P. wrote:
Attached patch with all mentioned issues corrected.
Now attached for real.
diff --git a/branding/templates/header.pxt b/branding/templates/header.pxt
index d90e605..c567b3a 100644
--- a/branding/templates/header.pxt
+++ b/branding/templates/header.pxt
@@ -21,6 +21,10 @@
script src=/javascript/bootstrap.js/script
script src=/javascript/spacewalk-essentials.js/script
script src=/javascript/spacewalk-checkall.js/script
+
+script src=/rhn/dwr/engine.js/script
+script src=/rhn/dwr/util.js/script
+script src=/rhn/dwr/interface/DWRItemSelector.js/script
/head
/pxt-passthrough
diff --git a/web/modules/pxt/PXT/HTML.pm b/web/modules/pxt/PXT/HTML.pm
index 7064042..dde1c7a 100644
--- a/web/modules/pxt/PXT/HTML.pm
+++ b/web/modules/pxt/PXT/HTML.pm
@@ -119,6 +119,7 @@ sub hidden {
#text(
# -name = foo,
# -value = foo,
+# -placeholder = foo,
# -maxlength = 30,
# -size = 15);
sub text{
@@ -129,7 +130,7 @@ sub text{
$class-_spew(-text no name given, defaulting to . $e{-name});
}
- return $class-_format(\%e,input type=\text\);
+ return $class-_format(\%e,input class=\form-control\ type=\text\);
}
#file(
@@ -451,6 +452,26 @@ sub link {
return sprintf qq{a href=%s$css_class$target%s/a}, $url, $label;
}
+sub button {
+ my $class = shift;
+ my $text = shift;
+ my %params = @_;
+
+ if (not exists $params{-name}) {
+die nameless button;
+ }
+
+ my @inner;
+ for my $attr (qw/value type name class/) {
+next unless exists $params{-$attr};
+push @inner, sprintf(qq{$attr=$params{-$attr}});
+ }
+
+ my $inner_str = join( , @inner);
+
+ return qq{button $inner_str$text/button};
+}
+
sub link2 {
my $class = shift;
my %params = validate(@_, { url = 1, text = 0, css = 0, target = 0, params = 0 });
@@ -527,6 +548,7 @@ my %rhn_icons = (
header-errata-set = fa spacewalk-icon-patch-set,
header-errata-set-add = fa pacewalk-icon-patchset-install,
header-event-history = fa fa-suitcase,
+header-filter = fa fa-eye,
header-help = fa fa-question-circle,
header-info = fa fa-info-circle text-primary,
header-package= fa spacewalk-icon-packages,
diff --git a/web/modules/sniglets/Sniglets/ListView/List.pm b/web/modules/sniglets/Sniglets/ListView/List.pm
index 47030ce..f5cada4 100644
--- a/web/modules/sniglets/Sniglets/ListView/List.pm
+++ b/web/modules/sniglets/Sniglets/ListView/List.pm
@@ -492,6 +492,17 @@ sub render_formvars {
sub render_alphabar {
my $self = shift;
+ my $pxt = shift;
+ my $content = shift;
+
+ # if there is no alphabar we still need the div there
+ my $template = $self-style-alphabar();
+ $template =~ s/\{alphabar_content\}/$content/;
+ return $template;
+}
+
+sub render_alphabar_content {
+ my $self = shift;
my $alphabar = shift;
my $pagesize = shift;
my $url = shift;
@@ -511,19 +522,15 @@ sub render_alphabar {
my $varstring = join('amp;', map { $_= . PXT::Utils-escapeURI($vars-{$_}) } keys %{$vars});
- push @ret, qq{A HREF=$url?$varstring class=list-alphabar-enabled$alpha/A};
+ push @ret, qq{lia href=$url?$varstring$alpha/a/li\n};
}
else {
- push @ret, qq {span class=list-alphabar-disabled$alpha/span};
+ push @ret, qq {li class=disableda href=#$alpha/a/li\n};
}
}
- my $bar = qq(div align=centerstrong\n) . join(, @ret) . qq(\n/strong/div\nbr /\n);
-
- my $html = $self-style-alphabar;
- $html =~ s/\{alphabar\}/$bar/;
-
- return $html;
+ my $bar = qq(ul class=spacewalk-alphabar pagination pagination-sm\n) . join(, @ret) . qq(\n/ul\n);
+ return $bar;
}
sub render_filterbox {
@@ -536,10 +543,12 @@ sub render_filterbox {
throw No 'sort_by' column for mode ' . $self-mode-{__name__} . '\n unless defined $filter_by;
- $ret .= q{div class=filter-input};
- $ret .= sprintf('Filter by %s: ', $filter_by-name);
+ $ret .= q{div class=spacewalk-list-filter};
+ $ret .= q{div class=input-group input-group-sm};
+
if ($self-filter_type eq 'text') {
-$ret .= PXT::HTML-text(-name = 'filter_value', -value = PXT::Utils-escapeHTML($self-filter_string || ''), -size = 12);
+$ret .= PXT::HTML-text(-name = 'filter_value', -value = PXT::Utils-escapeHTML($self-filter_string || ''),
+-placeholder = sprintf('Filter by %s: ', $filter_by-name));
$ret .= PXT::HTML-hidden(-name = 'prev_filter_value', -value = PXT::Utils-escapeHTML($self-filter_string || ''));
}
elsif ($self-filter_type eq 'select') {
@@ -554,8 +563,12 @@ sub render_filterbox {
throw Unknown filter type: ' . $self-filter_type . ';
}
- $ret .= ;
- $ret .= PXT::HTML-submit_image(-src = '/img/button-go.gif', -alt = Filter, -name = filter_list);
+ $ret .= q{div class=input-group-btn};
+ $ret .= PXT::HTML-button(PXT::HTML-icon(-type = 'header-filter') , -type = 'submit', -name = filter_list,
+-class = btn btn-default spacewalk-button
Re: [Spacewalk-devel] Things that needs to be dobne before next release.
On 09/01/14 13:26, Matej Kollar wrote: Major things that we currently consider release blockers for 2.1 from UI point of view are: * Things from [1] * Date picker * Human readable dates For this one, I was blocked by the perl list, for which I just sent a second patch. If anyone has cycles, it would be good to check that the list is styled correctly for the other list sub-types. * Confirm pages * Bare-metal systems management -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] perl List port to new css/markup
On 06/01/14 17:13, Michael Mraka wrote: I've reviewed your patch and found couple of issues: Attached patch with all mentioned issues corrected. It's a legacy code and I'm afraid no current spacewalk developer knows correct answer. Ok, I will need to check if this causes some list to be incorrectly styled. -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] RFC: manage bare-metal systems from Spacewalk
On 20/12/13 10:57, Silvio Moioli wrote: I guess so, even though I do not understand why you would want to do that. Idea is that the boot image is used by default before any kickstart. We want any new bare-metal system to automatically appear in Spacewalk as soon as it is connected to the network and powered on, to have it inventoried and ease a subsequent kickstart. The only purpose of the boot image is to add the necessary intelligence to a bare-metal system to get out of its state of bare-metal plus some inventory capabilities. However, from the user perspective, the machine is empty. It has no OS yet. -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] [PATCH] perl List port to new css/markup
Attached is a first port of the list view to the new CSS markup. I still
have a question though.
https://git.fedorahosted.org/cgit/spacewalk.git/tree/web/modules/sniglets/Sniglets/ListView/Style.pm
The way the styles work is by defining Style:standard with the default
methods and then other styles override this default.
When I look at Sniglets::ListView::Style::standard sub header
I see that package Sniglets::ListView::Style::channel_tree redefines it
exactly in the same way (overrides without changing it). Is it because
of the use of Style::blank below?
package Sniglets::ListView::Style::channel_tree;
use base qw/Sniglets::ListView::Style::blank/;
What is the reason for this?
--
Duncan Mac-Vicar P. - http://www.suse.com/
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix
Imendörffer, HRB 16746 (AG Nürnberg)
Maxfeldstraße 5, 90409 Nürnberg, Germany
diff --git a/branding/templates/header.pxt b/branding/templates/header.pxt
index d90e605..c567b3a 100644
--- a/branding/templates/header.pxt
+++ b/branding/templates/header.pxt
@@ -21,6 +21,10 @@
script src=/javascript/bootstrap.js/script
script src=/javascript/spacewalk-essentials.js/script
script src=/javascript/spacewalk-checkall.js/script
+
+script src=/rhn/dwr/engine.js/script
+script src=/rhn/dwr/util.js/script
+script src=/rhn/dwr/interface/DWRItemSelector.js/script
/head
/pxt-passthrough
diff --git a/web/modules/pxt/PXT/HTML.pm b/web/modules/pxt/PXT/HTML.pm
index 7064042..dbde608 100644
--- a/web/modules/pxt/PXT/HTML.pm
+++ b/web/modules/pxt/PXT/HTML.pm
@@ -119,6 +119,7 @@ sub hidden {
#text(
# -name = foo,
# -value = foo,
+# -placeholder = foo,
# -maxlength = 30,
# -size = 15);
sub text{
@@ -129,7 +130,7 @@ sub text{
$class-_spew(-text no name given, defaulting to . $e{-name});
}
- return $class-_format(\%e,input type=\text\);
+ return $class-_format(\%e,input class=\form-control\ type=\text\);
}
#file(
@@ -451,6 +452,26 @@ sub link {
return sprintf qq{a href=%s$css_class$target%s/a}, $url, $label;
}
+sub button {
+ my $class = shift;
+ my $text = shift;
+ my %params = @_;
+
+ if (not exists $params{-name}) {
+die nameless button;
+ }
+
+ my @inner;
+ for my $attr (qw/value type name class/) {
+next unless exists $params{-$attr};
+push @inner, sprintf(qq{$attr=$params{-$attr}});
+ }
+
+ my $inner_str = join( , @inner);
+
+ return qq{button $inner_str$text/button};
+}
+
sub link2 {
my $class = shift;
my %params = validate(@_, { url = 1, text = 0, css = 0, target = 0, params = 0 });
diff --git a/web/modules/sniglets/Sniglets/ListView/List.pm b/web/modules/sniglets/Sniglets/ListView/List.pm
index 47030ce..9732c20 100644
--- a/web/modules/sniglets/Sniglets/ListView/List.pm
+++ b/web/modules/sniglets/Sniglets/ListView/List.pm
@@ -492,6 +492,17 @@ sub render_formvars {
sub render_alphabar {
my $self = shift;
+ my $pxt = shift;
+ my $content = shift;
+
+ # if there is no alphabar we still need the div there
+ my $template = $self-style-alphabar();
+ $template =~ s/\{alphabar_content\}/$content/;
+ return $template;
+}
+
+sub render_alphabar_content {
+ my $self = shift;
my $alphabar = shift;
my $pagesize = shift;
my $url = shift;
@@ -536,10 +547,12 @@ sub render_filterbox {
throw No 'sort_by' column for mode ' . $self-mode-{__name__} . '\n unless defined $filter_by;
- $ret .= q{div class=filter-input};
- $ret .= sprintf('Filter by %s: ', $filter_by-name);
+ $ret .= q{div class=spacewalk-list-filter};
+ $ret .= q{div class=input-group input-group-sm};
+
if ($self-filter_type eq 'text') {
-$ret .= PXT::HTML-text(-name = 'filter_value', -value = PXT::Utils-escapeHTML($self-filter_string || ''), -size = 12);
+$ret .= PXT::HTML-text(-name = 'filter_value', -value = PXT::Utils-escapeHTML($self-filter_string || ''),
+-placeholder = sprintf('Filter by %s: ', $filter_by-name));
$ret .= PXT::HTML-hidden(-name = 'prev_filter_value', -value = PXT::Utils-escapeHTML($self-filter_string || ''));
}
elsif ($self-filter_type eq 'select') {
@@ -554,8 +567,12 @@ sub render_filterbox {
throw Unknown filter type: ' . $self-filter_type . ';
}
- $ret .= ;
- $ret .= PXT::HTML-submit_image(-src = '/img/button-go.gif', -alt = Filter, -name = filter_list);
+ $ret .= q{div class=input-group-btn};
+ $ret .= PXT::HTML-button(PXT::HTML-icon(-class = 'fa fa-eye') , -type = 'submit', -name = filter_list,
+-class = btn btn-default spacewalk-button-filter);
+ $ret .= q{/div};
+
+ $ret .= q{/div};
$ret .= q{/div};
return $ret;
@@ -598,26 +615,6 @@ sub render_select_buttons {
return $block;
}
-sub render_set_info {
- my $self = shift;
- my $pxt = shift;
- my $block = shift;
- my $pos = shift;
-
- my $subst = { };
-
- if ($self-allow_selections($pxt) and $self-{__set__}) {
-my $num_contents = scalar $self-{__set__}-contents;
-$subst
Re: [Spacewalk-devel] Asking for date/time in Spacewalk
On 18/12/13 10:55, Michael Mraka wrote: That's true but it was a legacy. Maybe at least put those external javascripts into a different directory next to spacewalk ones so we can easily pack them independently. I would really like to solve this for all resource assets. The packaging part is easy. If we move them out, we need to answer too many questions: - Do we package the minified version, full, both? - Do we take upstream minification? do we minify as part of the build (welcome grunt and the full javascript toolchain yeah!) - How do we handle versioning? - How do we handle the Apache configuration? How many webservers do we support? Until all of that is clear, worrying about Javascripts in web/html/javascript is shooting ourselves on the foot. They were already there since ages (spacewalk-search even has .jars). Duncan ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Asking for date/time in Spacewalk
On 17/12/13 08:53, Tomas Lestach wrote: Hey Duncan, the date picker is closely related with the displaying of timestamps as you among other things also display the proposed/chosen timestamp. I'd probably finish the displaying of timestamps and then concentrate on date picker. I think they are independent patches because we already have a date/time picker in spacewalk. It is worth noting that this implementation is backward compatible, even if it has 2 fields instead of 5 (?), it generates hidden compatibility form inputs for the old actions. I am posting them at the same time to start a discussion. I basically like the possibility to pick a date from the calendar and be able to enter it form the keyboard at the same time. Btw. I saw your patch requires jQuery. As I am not aware of any jquery packages available in Fedora koji http://koji.fedoraproject.org/koji/ the eventual patch would need to contain also packaging for all Fedora and RHEL versions for those Spacewalk will be built. jQuery is already on master. It was committed together with the UI refactoring as a replacement to prototype.js, which btw, was not packaged either. I know you would prefer to have jquery packaged, but the web-assets specification is pretty new (Fedora 20, http://fedoraproject.org/wiki/Changes/Web_Assets ), and you would had the same problem with the old prototype.js. Cheers -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [RFC] showing timestamps in Spacewalk
On 12/12/13 16:01, Cliff Perry wrote: Of course, how much perl code is to remain, soon? - So, that maybe is something that can be mitigated with plan to continue converting perl pages to java. That is a good question. We will also contribute more porting but we have no immediate plan of a massive porting yet (not because we dont want but because the pipeline is quite full with other stuff :-) ). Client side rendering via js is reasonable - dumb question - where/what does the locales? :) - I do like the screen shots and idea of making date/time stuff easier to read - I've also seen people wanting date formatting displayed changed. Just because their language is English, doesn't mean that 11/12/13 is clear to them - since in America is is 12th November and in UK it is 11th December. The Java implementation I originally did (PrettyTime) included translations and one could add more. I hooked this into the configured locale in Spacewalk in the tag implementation itself. I have completed the js implementation. moments.js also supports localization and my implementation also hooks into Spacewalk configured locale so you see the text in your language. The precise date that is put into the tooltip should be shown also formatted to your locale. Also moment.js is loaded on demand if the tag is used and not in every page. IMHO APIs reports are the only place where the date has to be in a ISO format that makes life easy for machines. I will think how to hook the moment.js rhn:formatDateHuman tag into perl and post a patch. I still preferred the PrettyTime server-based one as one could test the tag easily with junit. -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Pushing to spacewalk.git
On 10/12/13 11:03, Michael Mraka wrote: Heya Spacewalk commiters, I've noticed recently that our git repo is a bit weird looking. I'm talking about commit sequences a291087ad5ef010074ad2d4b1679fcc2cdf667c5..0f49b04dc9c6062a2fd6f480449270123ff7f6b7 and 742472c23d67b6d62730c329d09e1bdac63bd22b..0bfcd3c4029fcf886e3ab5001a7dc75860457095. What's wrong with them? As for code changes they are OK. The way they've been forked / merged / re-merged and finally pushed made git repo pretty messy. As human brain is mostly used to think in linear timeline it's easy e.g. to look for bugs in linear sequence of code changes but you will very quickly get lost in the number of parallel branches. That's why our golden rule is - don't merge, rebase - it's an easy way to keep git repo as much linear as possible. We explicitly asked about this on irc. The issue is was how to work all the UI issues in a branch. Rebasing work if we only push, but not if others contribute to that branch. -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] New way for displaying icons
On 10/12/13 11:02, Tomáš Kašpárek wrote: Hello, Hello as new Spacewalk webUI brought new icons with itself and many of those icons are used at many places, scattered across entire webUI, some effort would be required if any of those icons would need to be changed for whatever reason (sure, nothing that grep and sed can't handle). For this reason I've implemented new rhn:icon tag, so icon definitions like fa fa-check-circle fa-1-5x text-success are all put at one place and only this would need to be changed if any changes are needed. I am not calling for using rhn:icon for every icon in Spacewalk (espetialy those that are used only in one place), but if you know that some icon is or will be used multiple times, please consider using the new tag. It will make future changes easier ;-) Syntax of the new tag is following: rhn:icon type=system-ok title=I am dangerous shark! / Type is mandatory and it must be one of the HashMap keys specified in IconTag.java. Title is optional and as it's name says it will place title for the icon. Any comments are welcome I think it is a good idea, but if this would be the standard way, then we should port all the i class= tags. I have a tool to do this in case you are interested. -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] New way for displaying icons
On 10/12/13 17:04, Tomáš Kašpárek wrote: That thing would be appreciated. It is available here: https://github.com/dmacvicar/spacewalk-ui-porting It uses jruby. I run latest jruby using rbenv: https://github.com/sstephenson/rbenv Once you rbenv shell jruby-1.7.x, you can do gem install bundler bundle install to get the ruby dependencies and then run it from the source tree as bin/spacewalk-html-clean. Refactorings are implemented by adding some hooks to a class. They register automatically with the CLI. You can look at https://github.com/dmacvicar/spacewalk-ui-porting/blob/master/lib/spacewalk_html_clean/commands/images_to_icons.rb as an starting point. The tool outputs a diff. So you can examine it before applying/commiting. I can help you implementing the transform but it will take me some days (still have some stuff on my plate). Duncan ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [RFC] showing timestamps in Spacewalk
On 09/12/13 05:32, Jan Pazdziora wrote: (and code attached) Nice idea. There is a problem with the general inconsistency of the date/time displays, and part of it stems from the fact that Java does it differently than Perl. What is the proposal for the Perl side of the code base? If there is going to be some mass deployment of the new tags, it would be good to make it a full audit of the time formatting usage and do it everywhere. ... Johannes was pushing for the moment.js option (client side) and I convinced him on the server-side solution, but I did not think about perl. Doing it client side would solve the problem. I will try a different implementation using moment.js. And of course -- there may be people who prefer the exact dates/times to be shown so this really should be configurable. For new deployment/users, I assume the new behaviour would be fine but for existing users, we might want to preserve the existing behaviour, and let the users change it manually. I disagree in making configurable (software complexity increases a lot adding little value), but if in order to get the patch upstream it is needed, with the client-side solution this should not be hard to achieve. Duncan ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] [RFC] showing timestamps in Spacewalk
Hi Astronauts
While fixing glitches after the big merge, I have been looking for other
details that could make the user interface easier to the eyes.
One thing that immediately caught my attention was the amount of
timestamps we show in the user interface. Stuff like 15/10/13 08:13:33
EDT.
In most cases you don't care for that level of detail, and IMHO such
level of detail makes you ignore parsing it with your eyes and ignoring
it completely. Most modern websites use a human relative time that
attracts the eyes. Is my server out of date since today, last week or a
month?... after you processed that you may need the details.
So I implemented this. Details, screen-shots are here.
https://fedorahosted.org/spacewalk/wiki/User/Dmacvicar/HumanDates
(and code attached)
About the implementation, you have to be aware that the original date is
still available in two places. Hover tooltip and also as a microformat
in the address tag (for javascript use for example).
Now, I wanted to reuse fmt:formatDate in the tooltip but JSP does not
make this possible if using a Java implementation of the tag.
This leads me to a second discussion: tag implementation.
I thought first of this when reimplementing the List tag. But now it is
more obvious.
As the formatDateHuman tag still shows the normal date in the tooltip, I
wanted to reuse fmt:formatDate, but this is not possible.
It would be more or less possible if I implement it in a .tag file
instead of a Java file. It is also easier to see the markup, and it can
be added to the taglib without problem. I assume even trivial tags in
Spacewalk are done in Java because at that time there was no support for
tag files. So implementing this tag in a .tag file would be easier and
would mean I can reuse fmt:formatDate.
The only issue is I am not sure how one can test a tag done with a tag
file (can't use the Tag Mock infrastructure).
Otherwise we should look into using tag-files for the simpler tags.
--
Duncan Mac-Vicar P. - http://www.suse.com/
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix
Imendörffer, HRB 16746 (AG Nürnberg)
Maxfeldstraße 5, 90409 Nürnberg, Germany
diff --git a/java/code/src/com/redhat/rhn/frontend/taglibs/FormatDateHumanTag.java b/java/code/src/com/redhat/rhn/frontend/taglibs/FormatDateHumanTag.java
new file mode 100644
index 000..aad176e
--- /dev/null
+++ b/java/code/src/com/redhat/rhn/frontend/taglibs/FormatDateHumanTag.java
@@ -0,0 +1,144 @@
+/**
+ * Copyright (c) 2013 SUSE
+ *
+ * This software is licensed to you under the GNU General Public License,
+ * version 2 (GPLv2). There is NO WARRANTY for this software, express or
+ * implied, including the implied warranties of MERCHANTABILITY or FITNESS
+ * FOR A PARTICULAR PURPOSE. You should have received a copy of GPLv2
+ * along with this software; if not, see
+ * http://www.gnu.org/licenses/old-licenses/gpl-2.0.txt.
+ *
+ * Red Hat trademarks are not licensed under GPLv2. No permission is
+ * granted to use or replicate Red Hat trademarks that are incorporated
+ * in this software or its documentation.
+ */
+package com.redhat.rhn.frontend.taglibs;
+
+import com.redhat.rhn.domain.user.User;
+import com.redhat.rhn.frontend.struts.RequestContext;
+import org.ocpsoft.prettytime.PrettyTime;
+import java.util.Date;
+
+import java.io.IOException;
+import java.util.Locale;
+import javax.servlet.ServletRequest;
+import javax.servlet.http.HttpServletRequest;
+
+import javax.servlet.jsp.JspException;
+import javax.servlet.jsp.JspWriter;
+import javax.servlet.jsp.tagext.TagSupport;
+
+/**
+ * strongHumanTimeTag/strong
+ Displays a value in a human format (eg. 3 minutes ago)
+ * pre
+ * lt;rhn:human-value value=${bean.value}gt;
+ * /pre
+ * Outputs a human readable text for the value relative to now.br
+ *
+ */
+public class FormatDateHumanTag extends TagSupport {
+
+private Date value;
+private Date reference;
+private Locale locale;
+
+private PrettyTime p;
+
+/**
+ * @return the reference Date for which other values
+ are calculated
+ */
+public Date getReference() {
+return reference;
+}
+
+/**
+ * Sets the reference value from where other
+ values are calculated
+ * @param reference the reference value
+ */
+public void setReference(Date reference) {
+this.reference = reference;
+}
+
+/**
+ * @return The locale for the formatting, defaults
+ * to the application settings
+ */
+public Locale getLocale() {
+return locale;
+}
+
+/**
+ * @param locale Locale to do the formatting, defaults
+ * to the application settings
+ */
+public void setLocale(Locale locale) {
+this.locale = locale;
+}
+
+/**
+ * @return value to be formatted
+ */
+public Date getValue() {
+return value;
+}
+
+/**
+ * @param value the value to be formatted
+ */
+public void setValue(Date value) {
+this.value = value
[Spacewalk-devel] Using fonts in /rhn/account/LocalePreferences.do
/rhn/account/LocalePreferences.do - in 21st century and utf8 fonts, do we need pictures with text in national alphabets (if you select hindi as webui language, we have to use some fonts supporting hindi anyway), therefore getting rid of images would be really nice? I looked briefly into this and I have a patch. However there is a problem. The normal fonts are not that complete so even if hindi shows correctly with their alphabet, korean and other do not. This can be fixed by adding another font that is complete (like gnu unifont) and generate a css style that would apply that font only in that section of the page. However unifont .ttf is 14M. I am pretty sure that one could generate a subset of the font but I haven't looked into that yet. It should be possible with the build system of those fonts. Options? - We look into generating a font with the symbols we need? - We keep using images but may be improve them? - ??? -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Using fonts in /rhn/account/LocalePreferences.do
On 28/11/13 14:55, Michael Mraka wrote: Duncan Mac-Vicar P. wrote: % /rhn/account/LocalePreferences.do - in 21st century and utf8 fonts, do % we need pictures with text in national alphabets (if you select hindi as % webui language, we have to use some fonts supporting hindi anyway), % therefore getting rid of images would be really nice? % % I looked briefly into this and I have a patch. However there is a % problem. The normal fonts are not that complete so even if hindi shows % correctly with their alphabet, korean and other do not. % % This can be fixed by adding another font that is complete (like gnu % unifont) and generate a css style that would apply that font only in % that section of the page. However unifont .ttf is 14M. I am pretty sure % that one could generate a subset of the font but I haven't looked into % that yet. It should be possible with the build system of those fonts. Hi Duncan, Is that 10KB of images really that ugly / big problem that we need to replace them with 14MB ttf font? I don't think so. It does not bother me, but someone wrote it on the wiki page :-) -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Using fonts in /rhn/account/LocalePreferences.do
On 28/11/13 15:06, Bo Maryniuk wrote: On Thu, Nov 28, 2013 at 02:55:59PM +0100, Michael Mraka wrote: Is that 10KB of images really that ugly / big problem that we need to replace them with 14MB ttf font? I don't think so. I am wondering what is the problem of once downloading 14MB in a datacenter, usually local network? It looks big vs gifs, but the benefit is incomparable. I think in this case, for one page, and 10 language names, the use of a font is overkill. There is no real benefit apart of the scaling. -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Merging the bootstrap-css branch
On 06/11/13 11:49, Tomáš Kašpárek wrote: Contact me when everything is ready for the merge. I have repushed the branch with the checkstyle fixes and the jsp syntax error fixed as well. https://github.com/dmacvicar/spacewalk.git master-bootstrap-merge -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Merging the bootstrap-css branch
On 06/11/13 13:59, Bo Maryniuk wrote: On Wed, Nov 06, 2013 at 11:15:31AM +0100, Duncan Mac-Vicar P. wrote: About the pxt, we will put the port in another sprint in a month for now, and we will have minimum 3 developers working on it for those two weeks. We can tackle the perl List widget there. I would like to add that porting from Perl is sort of another topic and contributing should go *after* the Bootstrap merge, as the new JSPs should follow the Bootstrap paradigm. The perl main part is done, which is the layout, nav widgets, etc. Missing is the data table and styling some stuff that has inline style or that for other reason don't pickup the default styles. Duncan ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Merging the bootstrap-css branch
Hi astronauts We would like to start discussing a merge of the bootstrap-css branch. As you may know, the name is very technology specific but the work has a wider goal in mind. In case you haven't followed it, we prepared a blog post: http://duncan.mac-vicar.com/2013/10/30/modernizing-spacewalks-user-interface/ So what is the state of the work? [x] Layout [x] Java widgets (Nav, Toolbar, List) [x] Perl layout [x] Forms [x] Prototype - jQuery port [x] Fontawesome icon infrastructure [x] Spacewalk black theme Right now there is stuff we would like to fix grouped in various areas: [ ] Perl data list [ ] Port all icons .gif - fonticon [ ] Hidden cosmetic details in pages we haven't seen yet. [ ] JSP tags testcases - The perl data list is in our TODO list. - For the port of all .gif icons we still need to draw some replacements and this may be an ongoing task. We are then building an equivalence map and will use the a tool we wrote to aid on the conversion to do a translation once the map is completed: https://github.com/dmacvicar/spacewalk-ui-porting (We also are using this tool to help us sanitize the html, port styles, etc). - Hidden cosmetic details is something that will popup as we find issues and get feedback - The testcases are WIP. You have seen with previous patches that we care about the Java test cases because we are running them, and therefore we will work on this. Right now having a branch is blocking another features where we want to make use of the new css infrastructure and components, therefore it is our wish to do a first merge as soon as possible. This does not mean that we will stop working on it, but that we want to do the merges in stages. Also, I would really love to have other people gving feedback, contributing, learning and improving the new lookfeel. I would like to discuss the previous open items. Which ones would be a requisite for a 1st stage merge, which ones could be delayed to a second merge in some weeks from now. Regards, -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Future of the development stack?
On 14/10/13 11:37, Cliff Perry wrote: Hi Duncan and guys, so the last I saw, 12 days ago, was this Spacewalk branch https://git.fedorahosted.org/cgit/spacewalk.git/log/?h=bootstrap-css Grant loaded it onto a test system and it was looking good, still some polish needed and fixes done in a few places, but great to see. Hey Cliff Thanks for the feedback, it is much appreciated. So, I had a couple of questions 1) Any further progress/merging into that branch? I spent the Hackweek at SUSE porting the list widgets. Grant Gainey supported me with useful information. Silvio just pushed the current branch to the spacewalk git. The current plan is to make a sprint this and next week and look into: - Perl pages (we upstreamed some Java ports, but as part of a different feature branch :-)) - Details everywhere - asset processing and CDNs (I will explain below) Then we would like to try to merge upstream, and work the next details (static html pages that require different classes, by-hand widgets and porting images to font icons that are not generated by jsp tags) in a second round when the first basic stuff is already merged. This would open the window for others to contribute, port, and to get some bug reports. We would continue then to do minor work as we find issues and in a ~6 weeks we will do another 2 week sprint focusing various developers on polishing specific reported problems. So our main focus now is to manage to get this week and next week everything in a state where a merge would be accepted. 2) There was at least two css scripts being pulled from 3rd party locations which were required. They need to be packaged/shipped - since a fully disconnected Spacewalk instance, would not have internet access to pull it down. Yes, this is the asset processing part I mention above. We did this for development convenience. We will remove this and use bundled versions. Also, right now LESS is preprocessed to CSS in the client using less.js. We want to introduce a developer/production mode that in the second case it uses the css (generated during build) and in the first it would preprocess at runtime for developer convenience. Also this processing could include minifying and bundling of various assets together. This could help eg. RHN by reducing bandwidth and number of requests. Rails has this feature, may be we can mimick it somehow with Struts. 3) More a reminder, to ensure all code/libraries/scripts used are GPL friendly. http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses Twitter Bootstrap: Apache License 2.0 jQuery: MIT Font-Awesome code: MIT (all compatible) Font-Awesome fontss: SIL Open Font License (OFL) Addressed here: http://www.gnu.org/licenses/license-list.html#SILOFL (not a problem) Really, this is good stuff and I look forward to seeing the finished and polished product. Thanks a lot for the feedback! -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] editarea and apache 2.4
Hi Colin, editarea is used on Spacewalk. When using Fedora 19 apache 2.4 getting /editarea/edit_area_full.js results in Forbidden. Apache auth is now done in a set of modules for 2.4. According to the documentation https://httpd.apache.org/docs/2.4/upgrading.html 2.2 configuration: Order deny,allow Deny from all 2.4 configuration: Require all denied I am not sure why the default changed, as httpd/conf.d/editarea.conf did not had a configuration before, but adding the corresponding 2.4 part fixes the problem. https://gist.github.com/dmacvicar/6684649 alias /editarea /usr/share/editarea IfVersion = 2.4 Directory /usr/share/editarea Require all granted /Directory /IfVersion Regards, Duncan ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] upstreaming some of our .spec file changes
specific. -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Twitter Bootstrap: Standardizing the CSS framework?
On 01/08/13 10:05, Jan Pazdziora wrote: On Fri, Jul 26, 2013 at 03:06:47PM +0200, Duncan Mac-Vicar P. wrote: Yes, we do all development on SUSE Manager and then rebase against master what we want to upstream. It makes total sense. It may make sense from SUSE's point of view. Not sure it makes sense from upstream project health point of view. It would not be very different. We could do a long feature against master, not having it accepted, and then still having to backport it. - Spacewalk code is very distro oriented. In what way? In the way that the team tries hard to release binary signed rpms with each release to allow the administrators just upgrade the software without having to compile it? No, that is fine. Just that it is assumed (and in its own right) that the administrator runs Fedora, and therefore .specs, some Makefiles and even some code is distro specific. Spacewalk is very tied to Fedora in this regard. Not really -- all recent Spacewalk releases were done both on Fedoras *and* on RHEL 5 and 6. Ok, I did not consider those different. Why didn't you send those %ifdefs for review? If this is the only thing which blocks you do do Spacewalk vanilla releases on SUSE, I'm sure the Spacewalk team will be happy to consider those patches for master. Agreed. I started a new thread about this. - If you do a feature in Spacewalk master, you just do it and commit it. We have to ask for review and then the feature may not be accepted. Therefore the inverse work-flow, cherry-picking in our tree what looks good to upstream, makes more sense. There are SUSE developers who have commit access to Spacewalk git, based on their history of providing sensible bug fixes and contributions. Trust is built over time. If you start with small fixes and features, if the patches are clean against master and they are correct and not disturbing the rest of the Spacewalk, you will build trust for future big changes that you may have planned. Fully agreed. I am not complaining about this. It makes total sense. What I want you to realize is that we don't have that level of control: eg. you can do features for several months and be sure it will land upstream). Our process right now just fits our resources and control. Making a more vanilla master build on plain SUSE may help us do at least the changes that _do_not_need_ to start the other way around upstream first. I think we will invest some time to improve this because I see some opportunities, and may be some value for openSUSE as well. - Stuff like porting pages, happened as the side-effect of features we will have anyway in our tree but we don't know yet if we will be accepted upstream, The longer you wait and the longer you hack in your tree, the bigger the patchset will be when you decide to show ti upstream, and the harder will be for upstream to easily accept the feature. We know this, we take this decisions in a pragmatic way. Sometimes we just decide consciously that we will take a fork-debt, and sometimes we decide to pay it back. Check that communication again. I raised some general questions about the overall client -- server mechanism, issues that we saw with it in the past, and how it could be improved. I did not see answer that would indicate willingness to work on existing issues to improve the situation and maybe get the ssh push feature in as a well aligned part of the future setup. It was presented as mostly additional code which increased the complexity of the code (duplication of the scheduling functionality), solution that you propose in one form without being prepared to contribute to improving the overall setup. Yes, one could see this as duplicate from the push side, but that was not the core of it. The core was when the clients could not reach the client. You stated the first scenario does not sound that interesting to me. This is fine. I gave an example of this scenario: Spacewalk in the internal network, clients in a public cloud. We totally agree with upstream disagreeing. The problem is that in this case we could not move forward. What is interesting or not as a problem is subjective, and in this case we did not have the power. Imagine somebody in the community did not find ABRT support interesting?. This situation is fine and makes sense due to the amount of contributions from the diverse stakeholders. But control is a fact, and we can't see master in the same way you do. We should really figure out a run from source here :-) In the Spacewalk team, some developers run Spacewalk in their developer's setup which I assume is equivalent to the run from source wish. It's not my preferred approach as it in the past lead to different setup being used than what we then released to users, leading to missed bugs. However, I can well understand the desire to do so for some reason, so if there are any patches to make it easier, just submit them for review. Do you
Re: [Spacewalk-devel] Twitter Bootstrap: Standardizing the CSS framework?
On 26/07/13 09:05, Tomas Lestach wrote: Hello Duncan, I wasn't able to apply your patch. Could you send your patch rebased on latest master? Or at least write me against what commit I shall apply it. It seems that java/code/webapp/WEB-INF/includes/header.jsp version against that the patch is done, was never in Spacewalk. Please create your patch using: git format-patch The patch is against SUSE Manager, as I mentioned it is a quick port of the basics. I sent it mostly so that you get an idea of what is touched. I will try to make a patch against master if you really want to see it. Btw. do you plan to apply the bootstrap framework to perl pages as they are? Well, if we apply it, we will need to fix everything otherwise we will not be able to release ourselves. What I am not sure is how clean the initial commit to master can be, as there will be always stuff that will need fixing and lot of eyes stabilizing it. We have a bunch of perl pages already ported to Java as part of a feature we are doing, but I guess there is still more Perl around. Another possible workaround would be to use LESS features to auto-fix incomplete ports. We can have a compat.css with the original styles defined using LESS mixins. -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Twitter Bootstrap: Standardizing the CSS framework?
On 26/07/13 14:05, Tomas Lestach wrote: How can we be sure, that you cover all the Spacewalk pages, if you focus on downstream, that has a different set of pages? If the sent patch was against Suse Manager, I suppose that you do not really work with Spacewalk itself. So, are you going to verify the upcoming work only on Suse Manager or on Spacewalk as well? Yes, we do all development on SUSE Manager and then rebase against master what we want to upstream. It makes total sense. - Spacewalk code is very distro oriented. It is not possible right now to run it from the source tree. It needs packaging and productizing in order to run it. Spacewalk is very tied to Fedora in this regard. Running vanilla Spacewalk on SUSE would be a big effort and %ifdefs in the spec files (like they are in our tree. /srv/www vs /var/www anyone) - If you do a feature in Spacewalk master, you just do it and commit it. We have to ask for review and then the feature may not be accepted. Therefore the inverse work-flow, cherry-picking in our tree what looks good to upstream, makes more sense. - Stuff like porting pages, happened as the side-effect of features we will have anyway in our tree but we don't know yet if we will be accepted upstream, so we can't start the other way around, and we can't decide whether we do or not a feature based on whether upstream will take it or not (like it happened with SSH push). Of course this may change in the future and at some point it may be more productive to develop on Spacewalk master. We should really figure out a run from source here :-) Now, going back to how we would do the Bootstrap work, I guess it would make more sense to do it in Spacewalk master, but I haven't really thought how to do it. May be just develop on a Fedora platform for this specific case. Now, SUSE Manager pages are not that different. We have additional pages, but the existing ones are more or less the same. Some features we are working on for first time touches fragments of pages everywhere, and that is the reason why we may not make much of a difference in terms of conflicts by merging the bootstrap stuff. -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Twitter Bootstrap: Standardizing the CSS framework?
Hey astronauts
Twitter bootstrap (http://twitter.github.io/bootstrap/) is a CSS
framework that in addition to provide a good looking default theme, it
also provides:
- A very simple and standardized way of building the UI, with provided
styles for common UI elements
- Grid, Javascript plugins/features, typography, forms
- Awesome documentation (see the website)
- Responsive design
- Font icons (with Glyph-icons or Font-Awesome)
- So popular that apart of good docs there is a big community around
- It works with LESS, which makes reusing and customizing CSS very easy
- It has explicit instructions on how to customize it.
We find Bootstrap a very attractive path to:
- Cleanup the markup and move it to the current state of the art
- Make it very defined an easier for RHN and SUSE Manager to be a
customized version of Spacewalk.
- Have a better toolkit at hand for doing new user interfaces and/or
optional modules.
We started to explore how it would look to change the CSS framework. At
the end it resulted not that complicated, as once you set the framework,
lot of the UI is generated in Java code and custom tags, which have the
styles hard-coded.
So I did an initial port (See patch attached). Mostly the base layout
and the tags. There are a lot of jsp pages with plain html that need
porting by hand, but hey, it is a good start.
Here is a gallery with Spacewalk being customized by just changing a
LESS [²] file with variables (similar to what
http://twitter.github.io/bootstrap/customize.html#variables offers):
http://postimg.org/gallery/7dwszo2g/35f216dc/
So of course this patch needs the 80% remaining work. The SUSE Manager
team would be willing to do this work if upstream is willing to merge it
[¹].
As 2.0 was just released, this may be a good timing to merge new stuff.
If this is accepted we could start working in a final patch in order to
merge it some months from now.
What do you think?
Other ideas?
Regards,
[¹] (we may still move forward with it at cost of a bigger fork, and we
really want to make a decision soon to base future work on this).
[²] http://lesscss.org, works precompiled (compiling to css at build
time) or at runtime with a javascript implementation (eg. for
development). There is a java
implementation as well: http://www.asual.com/lesscss
--
Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF:
Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
Maxfeldstraße 5, 90409 Nürnberg, Germany
commit e1d3c7d9a418944d1039705cc56fb199bd8a
Author: Duncan Mac-Vicar P dmacvi...@suse.de
Date: Tue Jun 11 13:41:07 2013 +0200
Port the layout to twitter bootstrap
diff --git a/java/code/src/com/redhat/rhn/frontend/nav/DialognavRenderer.java b/java/code/src/com/redhat/rhn/frontend/nav/DialognavRenderer.java
index a7b5345..f68a667 100644
--- a/java/code/src/com/redhat/rhn/frontend/nav/DialognavRenderer.java
+++ b/java/code/src/com/redhat/rhn/frontend/nav/DialognavRenderer.java
@@ -42,7 +42,7 @@ public class DialognavRenderer extends Renderable {
sb.append(div.renderOpenTag());
}
-/** {@inheritDoc} */
+/** {@inheritDoc} */
public void preNavLevel(StringBuffer sb, int depth) {
if (!canRender(null, depth)) {
return;
@@ -88,7 +88,7 @@ public class DialognavRenderer extends Renderable {
titleBuf.append( - + node.getName());
renderNode(sb, node, treeIndex, parameters,
- content-nav-selected, content-nav-selected-link);
+ selected, );
}
/** {@inheritDoc} */
@@ -196,10 +196,10 @@ public class DialognavRenderer extends Renderable {
private static String getRowClass(int depth) {
if (depth == 0) {
-return content-nav-rowone;
+return nav nav-tabs;
}
else if (depth == 1) {
-return content-nav-rowtwo;
+return nav nav-pills;
}
else {
return content-nav-rowthree;
diff --git a/java/code/src/com/redhat/rhn/frontend/nav/SidenavRenderer.java b/java/code/src/com/redhat/rhn/frontend/nav/SidenavRenderer.java
index bb0cd4f..96105f8 100644
--- a/java/code/src/com/redhat/rhn/frontend/nav/SidenavRenderer.java
+++ b/java/code/src/com/redhat/rhn/frontend/nav/SidenavRenderer.java
@@ -46,10 +46,11 @@ public class SidenavRenderer extends Renderable {
return;
}
-if (depth == 1) {
+//if (depth == 1) {
HtmlTag ul = new HtmlTag(ul);
+ul.setAttribute(class, nav nav-list);
sb.append(ul.renderOpenTag());
-}
+//}
}
@@ -67,12 +68,12 @@ public class SidenavRenderer extends Renderable {
return;
}
-if (depth 1) {
-renderNode(sb, node, sidenav-selected navchild);
-}
-else {
-renderNode(sb, node, sidenav-selected navparent);
-}
+//if (depth 1) {
+renderNode
[Spacewalk-devel] Future of the development stack?
Hey astronauts We have been planning features for SUSE Manager and we are asking ourselves if for some of them it makes sense to do it with the current stack. As part of the CSS re-factoring upstream we lost all our re-branding work, which is fine, because we had forked the CSS so we kind of deserve it :-). However even by doing it by cascading a .css file at the end, it is cumbersome to override the previous styles. The world outside keeps moving and people are nowadays solving these problems by standardizing the css framework a bit eg: twitter bootstrap, where you have a very nice standard theme to start with, and then you can customize it in a standard way, as all css rules are documented and standarized. We already are using bootstrap in other SUSE products, and other major opensource projects (eg: OpenStack, OpenShift, etc) are also using it. We could start using bootstrap for new features, but we would be afraid to have them rejected by upstream. But another possibility would be to contribute upstream a port of all the styling to bootstrap from the beginning, which would be a mega-patch, but we would not start working on something like this without having discussed whether this is wanted or not. This would mean basically replace all css rule names of all pages. Similar discussions go in other areas of the web stack. We are realizing for some features we could avoid struts and use a client side Javascript framework (AngularJS, batman.js, etc) and have the Java web framework provide the data. Would features using a client side framework be rejected? I wanted to ask what is upstream strategy on these topics. Which kinds of contributions would be welcome and desired by Redhat (that is the biggest contributor)? Which aren't?, so that we, SUSE, as a frequent contributor and community members could align ourselves to this. We are trying to keep SUSE Manager as close to Spacewalk as possible, but we also don't want to get stuck without good reasons. Regards, -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] SSH Push Feature Proposal
On 24/04/13 14:38, Johannes Renner wrote: Can the logic you propose to be put to taskomatic be put to osa-dispatcher, to throttle the number of clients which get invited to rhn_check? Doesn't osad work by having the clients connect via XMPP _to_ the server? -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] SSH Push Feature Proposal
On 24/04/13 14:38, Johannes Renner wrote: Frankly, the first scenario does not sound that interesting to me. Access to and from DMZ is typically closed from/to all other networks as well and only opened in a very targeted fashion. The IT of that organization would still need to allow access _to_ the DMZ to sshd ports on those machines. You can always have Spacewalk Proxy in If you put a system in a public cloud with ssh access and want to manage it from your internal Spacewalk server you are already in that scenario. -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] application-wide caching facility?
Hi guys. I gave it a second round to my patch that improves the channel status. Right now part of the status is calculated with queries to the job history, but the metadata generation leaves no traces on the queue. I could enhance the schema to insert a flag when an exception is thrown, but this is overkill, as I don't need this data to survive reboots. If the latest status is lost is harmless. In other stacks I would use something like redis for this. A key/value store that can be configured in-memory or with very basic persistence, and accessible from all the components (webapp, taskomatic, python, etc). Do we have something like this already? Any other way of achieving the same? Would adding something like redis to the infrastructure would be desired? Cheers -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] [PATCH] Do not use America/New_York as the default timezone
Do not use America/New_York as the default timezone for the first new
user (subsequent users take as default the one from the user creating
the new user), but take the one configured for the server using
java.util.TimeZone.getDefaultTimeZone(). As the rhnTimeZone table does
not contain all timezones, but one per offset, we take the first one
that matches the offset.
Duncan
From bc80a6ff58aa2926dc01b8a4d6aaf80fce837a56 Mon Sep 17 00:00:00 2001
From: Duncan Mac-Vicar P dmacvi...@suse.de
Date: Fri, 8 Mar 2013 16:06:01 +0100
Subject: [PATCH] Do not use America/New_York as the default timezone for the
first new user (subsequent users take as default the one from the user
creating the new user), but take the one configured for the server using
java.util.TimeZone.getDefaultTimeZone(). As the rhnTimeZone table does not
contain all timezones, but one per offset, we take the first one that matches
the offset.
Conflicts:
java/code/src/com/redhat/rhn/domain/user/UserFactory.java
---
.../code/src/com/redhat/rhn/domain/user/UserFactory.java | 16
.../com/redhat/rhn/domain/user/test/UserFactoryTest.java | 4 +++-
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/java/code/src/com/redhat/rhn/domain/user/UserFactory.java b/java/code/src/com/redhat/rhn/domain/user/UserFactory.java
index 36e5808..80ea266 100644
--- a/java/code/src/com/redhat/rhn/domain/user/UserFactory.java
+++ b/java/code/src/com/redhat/rhn/domain/user/UserFactory.java
@@ -44,6 +44,7 @@ import java.util.Iterator;
import java.util.LinkedList;
import java.util.List;
import java.util.Map;
+import java.util.TimeZone;
/**
* UserFactory - the singleton class used to fetch and store
@@ -501,6 +502,20 @@ public class UserFactory extends HibernateFactory {
* @return US Eastern Time Zone
*/
public static RhnTimeZone getDefaultTimeZone() {
+RhnTimeZone sysDefault = getTimeZone(TimeZone.getDefault().getID());
+if (sysDefault != null) {
+return sysDefault;
+}
+Session session = HibernateFactory.getSession();
+ListRhnTimeZone allTimeZones =
+session.getNamedQuery(RhnTimeZone.loadAll).list();
+for (RhnTimeZone tz : allTimeZones) {
+if (TimeZone.getDefault().getRawOffset() == TimeZone.getTimeZone(
+tz.getOlsonName()).getRawOffset()) {
+return tz;
+}
+}
+// This should not happen unless the timezone table is incomplete
return getTimeZone(America/New_York);
}
@@ -522,6 +537,7 @@ public class UserFactory extends HibernateFactory {
//All other timezones are sorted West to East based on raw off-set.
if (timeZones != null) {
Collections.sort(timeZones, new Comparator() {
+@Override
public int compare(Object o1, Object o2) {
int offSet1 = ((RhnTimeZone)o1).getTimeZone().getRawOffset();
int offSet2 = ((RhnTimeZone)o2).getTimeZone().getRawOffset();
diff --git a/java/code/src/com/redhat/rhn/domain/user/test/UserFactoryTest.java b/java/code/src/com/redhat/rhn/domain/user/test/UserFactoryTest.java
index 0117caf..e6f0bcf 100644
--- a/java/code/src/com/redhat/rhn/domain/user/test/UserFactoryTest.java
+++ b/java/code/src/com/redhat/rhn/domain/user/test/UserFactoryTest.java
@@ -42,6 +42,7 @@ import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.util.ArrayList;
import java.util.List;
+import java.util.TimeZone;
/** JUnit test case for the User
* class.
@@ -51,6 +52,7 @@ import java.util.List;
public class UserFactoryTest extends RhnBaseTestCase {
private UserFactory factory;
+@Override
public void setUp() {
factory = UserFactory.getInstance();
}
@@ -176,7 +178,7 @@ public class UserFactoryTest extends RhnBaseTestCase {
public void testGetTimeZoneDefault() {
RhnTimeZone tz = UserFactory.getDefaultTimeZone();
assertNotNull(tz);
-assertTrue(tz.getOlsonName().equals(America/New_York));
+assertTrue(tz.getTimeZone().getRawOffset() == TimeZone.getDefault().getRawOffset());
}
public void testTimeZoneLookupAll() {
--
1.8.1.4
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] 'es improve channel status display
While it is easy to calculate the status of the repo-sync, -- as every channel sync has _one_ taskomatic job which has a result --, the status of the metadata generation is in _one_ Taskomatic job which creates workers for every channel. However the status is lost one it runs. The items in the worker table are basically the scheduled and running. If we want to improve here, I see 2 alternatives: - Improve this table (workers) to keep the failed and successful workers for a channel metadata generation run. - Keep it like it is, but make some assumptions: - If the metadata directory does not exists, it has not run yet (so it is not completed, but unknown). - If the metadata dir is there, but there is a FAILED file (written when the worker throws) then it is failed - Michael also suggested looking for .new files to detect failed state. - If the metadata dir is there but not the above, then it is completed. What do you think? Duncan ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] 'es improve channel status display
On 02/14/2013 05:59 PM, Tomas Lestach wrote: Hi Duncan, thanks for your patches. I committed following: eb7beb3277fb8db48376e44c058bde8ad5d1be45 1db45d611fbc307b4eac1fa35d25ed3b30dc6fac 668f52d928590b4bc7e2d3c955f2b6a59e5d3fb8 I didn't commit following ones: *TaskoRun Log tail: Handle the case where more bytes are requested than the current size of the log. - I rather return the whole log file in case more bytes are requested, so I committed this code: 6012adfcc5d4ae182c164a3e64e442255f44751c - anyway thank you for pointing on that situation Makes sense * both ChannelStatus commits - generally I like the idea, implementation, spinning icons, but I mean they aren't complete - I didn't find a way the 'Repo Cache Status' would say 'Completed' or 'Failed'. For the reposync, the result of the task will determine those statuses. For the repodata generation, only in-progress and scheduled is supported. But you are right in this second case if there are no items in the queue, it may be seen as completed instead of unknown. - are you sure you sent everything? - even if my repo was regenerated, I saw just '(none)' on the page Probably because of the above. The repodata-generation should return Completed in the else case and not Unknown. - please check and I'd be happy to commit your patches Btw. would you run checkstyle before sending patches, please? I am working on a ant-task to do checkstyle from the command line. Currently it is done in the rpm and not very comfortable. Thanks for the review, I will improve the patches, merge the ones you committed and try again soon. Duncan ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] [PATCH] avoid negative payload sizes with older rpms
Older rpm versions have signed tag data, which results in negative numbers for sizes 2G. If your yum-metadata-parser does not have the 2d8499c and ffdcc0b fixes, then yum will read a repo, insert negative values into the sqlite3 db, and spacewalk-reposync will put those negative values into the database. The sizes being negative will prevent urlgrabber to get the rpm. Even if you apply those fixes, then the rpm headers are read directly to generate the metadata for the channel. Even if the size is positive (thanks to the previous fix) the payload size will be read negative from the rpm header and will appear negative in the user interface. The following patch to spacewalk-backend (headerSource.py) removes the sign to this value, resulting in a cosmetic fix in the UI. I have another workaround patch to yum yumRepo.py that removes the sign even if the value is coming from a sqlite3 db done without the yum-metadata-parser fix. I include it, but that is optional to apply and only a safeguard. Not sure yet if I should upstream it (including it here for review though) -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany diff --git a/backend/server/importlib/headerSource.py b/backend/server/importlib/headerSource.py index 6b016ec..9d5ff8a 100644 --- a/backend/server/importlib/headerSource.py +++ b/backend/server/importlib/headerSource.py @@ -57,6 +57,11 @@ class rpmPackage(IncompletePackage): if type(val) in (IntType, LongType): # A UNIX timestamp val = gmtime(val) + if f == 'payload_size': +# workaround for older rpms where signed +# attributes go negative for size 2G +if val 0: +val = long(val) + 2 ** 32 elif val: # Convert to strings if isinstance(val, unicode): --- yumRepo.py 2013-02-12 10:30:18.0 +0100 +++ yumRepo.py.fix 2013-02-08 17:03:57.0 +0100 @@ -857,13 +857,17 @@ return local misc.unlink_f(local) + fixed_size = long(package.size) +if fixed_size 0: +fixed_size = fixed_size + 2 ** 64 + return self._getFile(url=basepath, relative=remote, local=local, checkfunc=checkfunc, text=text, cache=cache, -size=package.size, +size=fixed_size, ) def getHeader(self, package, checkfunc = None, reget = 'simple', ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] [PATCH] 'es improve channel status display
The following patches improve the status of a channel by taking into
account both download/mirror _and_ repodata generation.
The download/sync status was a bit tricky to get, as the taskomatic
table is made polymorphic by serializing java objects which in turn
contain the channel_id, so you can't just SQL it.
Some bugs are fixed in order to get everything working, specially
failing when exit code of external programs is not successful, and
getting the tail log for logs smaller than the requested tail.
The status is exposed as a ChannelStatus class.
This could be displayed as icons (spinning wheel, exclamation) in the
overview lists, but as I don't have a concept for the UI I kept it in
the channel details page, as the half status was already there.
The patches are intended for review, but are not yet rebased against master.
commit c523b18667ace8acd5dd835378e87d0be45f9473
Author: Duncan Mac-Vicar P dmacvi...@suse.de
Date: Thu Jan 31 17:45:25 2013 +0100
Improve the Channel Details page by using the status generated
by ChannelStatus, which includes also repo-sync information.
commit 080232549c07e6c38caaebbaa640530efebcd614
Author: Duncan Mac-Vicar P dmacvi...@suse.de
Date: Thu Jan 31 11:31:36 2013 +0100
Introduce ChannelStatus as an agregate way to query both the repo-sync
and repodata generation status of a channel.
The class also carries a log to transport debug information to the
admin. In the future, more data or sub-statuses could be added to
this class.
The ChannelStatus is exposed in ChannelManager::statusForLabel(label)
and ChannelManager::isChannelLabelInProgress(label) gets deprecated
and reimplemented using ChannelManager::statusForLabel(label).
The Task queries get a new query to ask for candidate repodata
generation workers and the active ones gets renamed to keep the
names meanful and consistent.
commit caec97d8d2b88f008cb0e70391cb572207f6b1da
Author: Duncan Mac-Vicar P dmacvi...@suse.de
Date: Wed Jan 30 18:37:52 2013 +0100
RhnJavaJob: Do not ignore the exit code for external programs.
commit 630870f813d2deaf2b95d8a133fdfd78e110c05a
Author: Duncan Mac-Vicar P dmacvi...@suse.de
Date: Wed Jan 30 18:31:01 2013 +0100
TaskoRun Log tail: Handle the case where more bytes are requested
than the current size of the log.
commit 6f445ce3e1f85fecbe4010f3cfce1a5724dab286
Author: Duncan Mac-Vicar P dmacvi...@suse.de
Date: Wed Jan 30 18:30:09 2013 +0100
Do not silence catched exceptions. Debugging can be hard.
commit ce3c088b4890e40273aa846bad0501bd62367080
Author: Duncan Mac-Vicar P dmacvi...@suse.de
Date: Wed Jan 30 18:29:25 2013 +0100
FileNotFoundException inherits IOException so no need for a separate
catch block if the catch code is the same (none).
From ce3c088b4890e40273aa846bad0501bd62367080 Mon Sep 17 00:00:00 2001
From: Duncan Mac-Vicar P dmacvi...@suse.de
Date: Wed, 30 Jan 2013 18:29:25 +0100
Subject: [PATCH 1/6] FileNotFoundException inherits IOException so no need
for a separate catch block if the catch code is the
same (none).
---
java/code/src/com/redhat/rhn/taskomatic/TaskoRun.java |3 ---
1 file changed, 3 deletions(-)
diff --git a/java/code/src/com/redhat/rhn/taskomatic/TaskoRun.java b/java/code/src/com/redhat/rhn/taskomatic/TaskoRun.java
index c58a296..b521513 100644
--- a/java/code/src/com/redhat/rhn/taskomatic/TaskoRun.java
+++ b/java/code/src/com/redhat/rhn/taskomatic/TaskoRun.java
@@ -188,9 +188,6 @@ public class TaskoRun {
file.close();
return tail;
}
-catch (FileNotFoundException e) {
-// return ;
-}
catch (IOException e) {
// return ;
}
--
1.7.10.4
From 6f445ce3e1f85fecbe4010f3cfce1a5724dab286 Mon Sep 17 00:00:00 2001
From: Duncan Mac-Vicar P dmacvi...@suse.de
Date: Wed, 30 Jan 2013 18:30:09 +0100
Subject: [PATCH 2/6] Do not silence catched exceptions. Debugging can be
hard.
---
java/code/src/com/redhat/rhn/taskomatic/TaskoRun.java |1 +
1 file changed, 1 insertion(+)
diff --git a/java/code/src/com/redhat/rhn/taskomatic/TaskoRun.java b/java/code/src/com/redhat/rhn/taskomatic/TaskoRun.java
index b521513..3dfd595 100644
--- a/java/code/src/com/redhat/rhn/taskomatic/TaskoRun.java
+++ b/java/code/src/com/redhat/rhn/taskomatic/TaskoRun.java
@@ -189,6 +189,7 @@ public class TaskoRun {
return tail;
}
catch (IOException e) {
+log.error(Can't tail + fileName + : + e.toString());
// return ;
}
}
--
1.7.10.4
From 630870f813d2deaf2b95d8a133fdfd78e110c05a Mon Sep 17 00:00:00 2001
From: Duncan Mac-Vicar P dmacvi...@suse.de
Date: Wed, 30 Jan 2013 18:31:01 +0100
Subject: [PATCH 3/6] TaskoRun Log tail: Handle the case where more bytes are
requested than the current size of the log.
---
java/code/src/com/redhat
Re: [Spacewalk-devel] Deployment of images built with SUSE Studio
On 05/16/2012 01:33 PM, Johannes Renner wrote:
http://downloads.sourceforge.net/simple/%{name}-%{version}.zip
Thanks, I didn't know that. Changed it in our specfile as well.
Regards,
Johannes
We don't do it that way all the time, because sometimes we use bznew and
convert upstreams tar.gz to tar.bz2, and then the url does not make sense.
Duncan
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] [PATCH] fixes for system that needs reboot feature
- Move the notification to the last position, and make it appear even
when other notifications are shown.
- Missing icon
- Capitalize the text of the title to be consistent with other pages
From f20edd99cf6b4862e77378d9018161f12417aef7 Mon Sep 17 00:00:00 2001
From: Duncan Mac-Vicar P dmacvi...@suse.de
Date: Tue, 24 Apr 2012 16:18:00 +0200
Subject: [PATCH 1/3] Put the reboot notification at the end. Make it not
mutually exclusive with other notifications.
---
.../webapp/WEB-INF/pages/systems/sdc/overview.jsp | 16
1 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/java/code/webapp/WEB-INF/pages/systems/sdc/overview.jsp b/java/code/webapp/WEB-INF/pages/systems/sdc/overview.jsp
index d69645b..94eba0d 100644
--- a/java/code/webapp/WEB-INF/pages/systems/sdc/overview.jsp
+++ b/java/code/webapp/WEB-INF/pages/systems/sdc/overview.jsp
@@ -8,8 +8,10 @@
body
%@ include file=/WEB-INF/pages/common/fragments/systems/system-header.jspf %
h2bean:message key=sdc.details.overview.systemstatus//h2
+
div class=systeminfo
div class=systeminfo-full
+
c:choose
c:when test=${unentitled}
@@ -22,10 +24,6 @@
bean:message key=sdc.details.overview.inactive2 arg0=/rhn/help/reference/en-US/s1-sm-systems.jsp#s2-sm-system-list/
/c:if
/c:when
-c:when test=${rebootRequired}
- img src=/img/restart.png/bean:message key=sdc.details.overview.requires_reboot/
- bean:message key=sdc.details.overview.schedulereboot arg0=/network/systems/details/reboot_confirm.pxt?sid=${system.id}/
-/c:when
c:when test=${hasUpdates}
c:choose
c:when test=${criticalErrataCount 0}
@@ -54,6 +52,16 @@
/c:otherwise
/c:choose
/div
+
+ c:if test=${rebootRequired}
+div class=systeminfo
+ div class=systeminfo-full
+img src=/img/restart.png/bean:message key=sdc.details.overview.requires_reboot/
+bean:message key=sdc.details.overview.schedulereboot arg0=/network/systems/details/reboot_confirm.pxt?sid=${system.id}/
+ /div
+/div
+ /c:if
+
div class=systeminfo-clear /
/div
c:if test=${probeListEmpty != 'true'}
--
1.7.7
From c3d2235f90001c953d32db9074a941d43fe78963 Mon Sep 17 00:00:00 2001
From: Duncan Mac-Vicar P dmacvi...@suse.de
Date: Fri, 20 Apr 2012 13:39:16 +0200
Subject: [PATCH 2/3] Missing icon for the systems that need reboot list
---
branding/img/restart.png | Bin 0 - 912 bytes
1 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 branding/img/restart.png
diff --git a/branding/img/restart.png b/branding/img/restart.png
new file mode 100644
index ..3fd71d6e5929ba0c40db1960e36e9acba9d7e525
GIT binary patch
literal 912
zcmV;B18@9^P)h;3K|Lk000e1NJLTq000mG000mO1^@s6AM^iV4b3#c}2nYxW
zdbNSPbVXQnQ*UN;cVTj60C#tHE@^ISb7Ns}WiD@WXPfRk8UO$TB1uF+R5*=o
zQcY}BWfVR4d+(L`tut*0Td1}Qh7zWsqBD(u(U?Xz#9ycyhMzUf$+0o2OA7c3=wo;
zqTmCgF-#?xGyymK1R;{t!mDx7(2~^B#sNkvoWowDaEkzU!j%l38$)o7}}cCnx7z
zVrKYAWwOsS=-Lqw-t?qu)r6QQ!notg696vQmg~r9t3cLe1UW(yG7H)Ku^~yeO+g
z(bg0Jm{BNJFfw+(d}sQhCl9uE%R)8S2n|p?*PPznUTt5*BiPR+1l3~ipPS`iO?Jk
zARN#U4H*a;0yD)$9M29{3dMY4K?WE{g^G!Zl7)jelV^{i|AG#D_%tfB+t_MTc
zeJs7#lH0O;okMFqzQr$gkPrsJC8h7YDw+Nu`!(E)KfE(t5U!_KF)uRXGsl%@
z#;0eK6ZhtiUhin`+P8I6C=mc9EA6Ed~Oh1OP~!d1ufk}o{_gOutKfI-_b^R{JP
z`QzJUK*V?A?9r67D}NVS1(vsTcqQ01GUys_Cgne`6%@RcHIkZU9qtY3sTsc5Zto
z2^LHMWS9G(o-t)@yh1Uq9cxfG6X$C)H~ghbOC7?WrZ-yyL00QOs`0x)UuAAQg
z;LGL0Gpf^PVr@oj}%1`wDT7wv!4sq=s3q*OhWftpMhqGg=O68@F-$%x80Ep=T
zKm-sG?*3PXAs8nI|0Dok)RR-0Y?z4d_HJBzCOQm0-yn?3IGs91OOe05LUN@@#X%v
zsjVe)?3Fz~-%4e6*s6^5?o^0Noh2ra)My_p{u2^JcwBLDVQ7jykI}v|io-kJ
z2z}6(e7UtbaxJ}Uz%_L7jZ`u|_ho4jX~0c7z6Sk*NR2p{0r3+~lR$EA{P2of=
zi0-usdagYlDwbXRJ6nR|coYd5ICpup;z@M`0G1y~F-_#=PTxGaE%~6Z@JavoH|CEI
z+$;^LcltM%9%NL@3OchjeEiCkKZJAL;J5G-fbF(raxE|ezUjbwpTH4kW$4B
mU7I1oP}Px#Y|H%H5BGmARd#9Wz5C^MNUMnLSTZGTBDT!
literal 0
HcmV?d1
--
1.7.7
From 2022e7821091986983e959adbf0457372d6a19e4 Mon Sep 17 00:00:00 2001
From: Duncan Mac-Vicar P dmacvi...@suse.de
Date: Tue, 24 Apr 2012 15:43:30 +0200
Subject: [PATCH 3/3] Capitalize title to be consistent
---
.../frontend/strings/jsp/StringResource_en_US.xml |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/java/code/src/com/redhat/rhn/frontend/strings/jsp/StringResource_en_US.xml b/java/code/src/com/redhat/rhn/frontend/strings/jsp/StringResource_en_US.xml
index e82b561..72e9d24 100644
--- a/java/code/src/com/redhat/rhn/frontend/strings/jsp/StringResource_en_US.xml
+++ b/java/code/src/com/redhat/rhn/frontend/strings/jsp/StringResource_en_US.xml
@@ -5062,7 +5062,7 @@ value for this entitlement, excluding the default organization's consumption./s
/trans-unit
trans-unit id=requiringrebootlist.jsp.header
-sourceSystems requiring reboot/source
+sourceSystems Requiring Reboot/source
[Spacewalk-devel] [PATCH] Show systems that need reboot because of an errata
On 04/16/2012 11:25 AM, Tomas Lestach wrote:
On Friday 13 of April 2012 17:28:05 Duncan Mac-Vicar P. wrote:
On 04/13/2012 02:30 PM, Tomas Lestach wrote:
A separate query for a single system would definitelly be more efficient.
Looking at what you pointed out in IRC: what happens if the errata is
applied on the client side. So I modified them to look at the package
install time instead:
For the system list:
SELECT DISTINCT S.id, S.NAME,
(SELECT 1
FROM rhnServerFeaturesView SFV
WHERE SFV.server_id = S.id
AND SFV.label = 'ftr_system_grouping') AS selectable
FROM rhnServer S,
rhnErrata E,
rhnServerInfo SI,
rhnServerPackage SP,
rhnPackage P,
rhnActionErrataUpdate EA,
rhnServerAction SA,
rhnErrataPackage EP,
rhnPackageName PN
WHERE S.org_id = :org_id
AND EXISTS (SELECT 1 FROM rhnUserServerPerms USP WHERE
USP.user_id=:user_id AND USP.server_id = S.id)
AND SI.server_id = S.id
AND SP.server_id = S.id
AND P.evr_id = SP.evr_id
AND P.name_id = SP.name_id
AND EA.errata_id = E.id
AND SA.action_id = EA.action_id AND SA.server_id = S.id
AND EP.errata_id = E.id AND EP.package_id = P.id
AND (to_timestamp(S.last_boot) SP.installtime)
AND E.id IN (SELECT EK.errata_id FROM rhnErrataKeyword EK WHERE
EK.keyword = :keyword)
AND PN.id = P.name_id
Duncan,
if an erratum package is installed on the client side using yum, you
definitelly won't have any entry in the
rhnServerAction/rhnAction/rhnActionErrataUpdate tables. I would omit them from
the select.
Basicly you need only (user) servers having any errata packages installed
after the latest reboot, where the appropriate erratum has the need_reboot
flag. (no 'Actions' in the sentence)
I'm not sure, why you join also the rhnPackageName, if you do not really use
it.
Sorry for wasting your time. I pasted directly from the pgadmin3 console.
Attached patch, rebased against master. It contains all suggestions and
fixed some formatting issues not relevant to the patch. Additionally
changed to_timestamp() to something that works in both databases.
Duncan
From 34b8bea2ad8e64a4b9c5359d21ad6d0d480f054f Mon Sep 17 00:00:00 2001
From: Duncan Mac-Vicar P dmacvi...@suse.de
Date: Tue, 17 Apr 2012 15:31:06 +0200
Subject: [PATCH] Show systems that need reboot because of an errata.
---
.../common/db/datasource/xml/System_queries.xml| 55
.../action/systems/RequiringRebootSetupAction.java | 37 +
.../action/systems/sdc/SystemOverviewAction.java |5 ++
.../frontend/strings/jsp/StringResource_en_US.xml | 14 +
.../frontend/strings/nav/StringResource_en_US.xml |6 ++
.../redhat/rhn/manager/system/SystemManager.java | 40 ++
.../webapp/WEB-INF/nav/sitenav-authenticated.xml |1 +
.../WEB-INF/pages/systems/requiringrebootlist.jsp | 25 +
.../webapp/WEB-INF/pages/systems/sdc/overview.jsp |5 ++-
java/code/webapp/WEB-INF/struts-config.xml | 10
10 files changed, 197 insertions(+), 1 deletions(-)
create mode 100644 java/code/src/com/redhat/rhn/frontend/action/systems/RequiringRebootSetupAction.java
create mode 100644 java/code/webapp/WEB-INF/pages/systems/requiringrebootlist.jsp
diff --git a/java/code/src/com/redhat/rhn/common/db/datasource/xml/System_queries.xml b/java/code/src/com/redhat/rhn/common/db/datasource/xml/System_queries.xml
index cdb0cc5..64560e0 100644
--- a/java/code/src/com/redhat/rhn/common/db/datasource/xml/System_queries.xml
+++ b/java/code/src/com/redhat/rhn/common/db/datasource/xml/System_queries.xml
@@ -757,6 +757,61 @@ ORDER BY UPPER(COALESCE(S.NAME, '(none)')), S.ID
elaborator name=is_virtual_host /
/mode
+query name=having_errata_with_keyword_applied_since_last_reboot_list params=org_id, user_id, keyword
+SELECT DISTINCT S.id, S.NAME,
+ (SELECT 1
+ FROM rhnServerFeaturesView SFV
+ WHERE SFV.server_id = S.id
+ AND SFV.label = 'ftr_system_grouping') AS selectable
+ FROM rhnServer S,
+ rhnErrata E,
+ rhnServerInfo SI,
+ rhnServerPackage SP,
+ rhnPackage P,
+ rhnErrataPackage EP
+ WHERE S.org_id = :org_id
+ AND EXISTS (SELECT 1 FROM rhnUserServerPerms USP WHERE USP.user_id=:user_id AND USP.server_id = S.id)
+ AND SI.server_id = S.id
+ AND SP.server_id = S.id
+ AND P.evr_id = SP.evr_id
+ AND P.name_id = SP.name_id
+ AND EP.errata_id = E.id AND EP.package_id = P.id
+ AND (to_date('1970-01-01', '-MM-DD') + numtodsinterval(S.last_boot, 'second')) lt; SP.installtime
+ AND E.id IN (SELECT EK.errata_id FROM rhnErrataKeyword EK WHERE EK.keyword = :keyword)
+/query
+
+mode name=having_errata_with_keyword_applied_since_last_reboot class=com.redhat.rhn.frontend.dto.SystemOverview
+ query name=having_errata_with_keyword_applied_since_last_reboot_list/
+ elaborator name=system_overview
Re: [Spacewalk-devel] dto's from the database?
On 04/06/2012 10:54 AM, Tomas Lestach wrote: Hmm, this isn't suitable for one system (if I understood it correctly), because you make a query, where you get all the systems having the specific errata keyword and then you just elaborate a 1 for one single system (without setting it anywhere)? This doesn't seem to be correct at all. (Or I just didn't understand it.) I took the pattern from another method, that did the same query and the Java method in the Manager class returns !result.isEmpty() What query/elaborator do you mean here? For example Package_queries: package_available_to_user which is then used in rhn/manager/user/UserManager.java for verifyPackageAccess(org, packageId). It selects for 1. If there is access, it gets 1, if not, it gets an empty set. The function returns a bool by computing !result.isEmpty() -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] dto's from the database?
On 04/05/2012 12:14 PM, Tomas Lestach wrote: yes, this shall work. However, I'd much better see something like: query name=system_list_with_errata_keyword params=org_id, user_id, keyword ... (SELECT EK.errata_id FROM rhnErrataKeyword EK WHERE EK.keyword = :keyword) ... to have it more generic and prepared for possible reuse with other keywords Thanks, I will try to refactor it. Hmm, this isn't suitable for one system (if I understood it correctly), because you make a query, where you get all the systems having the specific errata keyword and then you just elaborate a 1 for one single system (without setting it anywhere)? This doesn't seem to be correct at all. (Or I just didn't understand it.) I took the pattern from another method, that did the same query and the Java method in the Manager class returns !result.isEmpty() If I implement this at the Java level, by fetching the keywords, I would not be able to reuse the queries Give me the systems who had this kind of errata applied, but still because limitations in the framework, I don't seem to be able to refactor requiring_reboot_list into a list of erratas plus a elaborator that fetches the systems with those erratas, because they would be in different files. What is still unclear to me, where you'd like to store the information the system has been rebooted, so you stop marking the system as needing reboot. The query compares against rhnSystem.last_boot (against the time of the errata action completed) :-) thanks a lot for your help. -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Policy for collections and generics?
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? -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ 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 02:37 PM, Stephen Herr wrote: 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 Great to hear. I think is equally hard in the developers end, as you don't sit to fix just generics, but fix them as you go over code, and that mixes changes in the same patch. But I will keep in mind :-) -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] dto's from the database?
On 04/02/2012 11:14 AM, Duncan Mac-Vicar P. wrote: Hi guys, I was trying to add a small icon in one errata page, showing if an errata requires a reboot later. Ok, I am getting more familiar with the DataSource and SelectMode stuff (what a framework you have in there :-) ) One possible solution is to do it at the SQL level: adding the column as a sub-query. This is not very portable across distros but seems to be a good solution: SELECT DISTINCT E.id, E.advisory_name AS advisory, E.update_date AS update_date, E.synopsis AS advisory_synopsis, E.advisory_type AS advisory_type, (SELECT CASE WHEN (SELECT TRUE FROM rhnErrataKeyword EK WHERE EK.keyword LIKE '%reboot_suggested%'AND EK.errata_id=E.id) IS NULL THEN FALSE ELSE TRUE END) AS reboot_suggested FROM rhnErrata E, rhnChannelErrata CE WHERE CE.channel_id = cid AND CE.errata_id = E.id Another solution, that is more consistent with the methods like ErrataOverview.isProductEnhancement() would be to have the SQL add a comma joined version of the keywords and then have the logic in ErrataOverview for isRebootSuggested() (I assume it is not possible to have them fetched as a collection into the dto) I still haven't figured out the Elaborators part of the framework, but I would like to hear what sounds a better approach to you. -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] spacewalk-dobby
On 03/21/2012 01:34 PM, Bo Maryniuk wrote: Hi! I was looking at Spacewalk Dobby wrapper around Oracle tools and I am wondering if there is any plans to work on it? We find it lack of some features that we would like to have, so we are looking to know what are community plans on this particular software. We are particularly interested to know if dobby needs to gain Postgres support, of if replacing it completely was the plan. -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Exceptions, i18n and error messages
I have been working on NewChannelHelper, CreateChannelCommand, ChannelSoftwareHandler and EditChannelAction. Right now NewChannelHelper does some verifying and implements cloning, while new channel creation is implemented in CreateChannelCommand. Basic validation is in two places, CreateChannelCommand validates and throws (translated) exceptions. NewChannelHelper implements the logic (but only answers true or false) and then the clone operation in the same class creates an untranslated InvalidChannelParameter exception. This makes sense, as NewChannelHelper::clone is used in ChannelSoftwareHandler (xmlrpc) for the clonning, so an untranslated error is ok (despite the duplication). When I refactored the validation in one place, I kept the ones from CreateChannelCommand, which are translated. I remember Tomas Lestach mentioning in irc that it is important that these xmlrpc exceptions are untranslated. Everything fine, however then I realized ChannelSoftwareHandler uses CreateChannelCommand for creating channels, and therefore it receives translated exceptions. EditChannelAction catches the exceptions and based on the reason constructs ActionMessages no matter if the exception was already translated or not. If I could use the translated ones, I could remove the switch per-reason and just construct an ActionMessage directly from the Exception. Any guidance here? -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] All relevant errata as All Errata
On 03/02/2012 04:06 PM, Tomas Lestach wrote: On Friday 02 of March 2012 15:41:49 Duncan Mac-Vicar P. wrote: Hi Astronauts, The errata hierarchy in the Errata tab is: Errata Relevant All Errata - Bugfix Errata - Enhancement Errata - Security Errata All All Errata - Bugfix Errata - Enhancement Errata - Security Errata When the user is in Relevant (Errata Relevant to Your System) having a subtab All Errata is confusing, because it really means Relevant Errata of all types, and not All Errata like the parent menu. I suggest to change it to All Types un both Errata-All and Errata-Relevant. Comments? I agree. Attached patch for english and spanish. In spanish I did not need to mention all TYPES as I can use the gender difference to make it very obvious if I am talking of erratas types or erratas. German, is still being discussed here in the office... Duncan From f6fcded8d4c718c1089d1aa31ee75196fd7a59db Mon Sep 17 00:00:00 2001 From: Duncan Mac-Vicar P dmacvi...@suse.de Date: Mon, 5 Mar 2012 13:27:53 +0100 Subject: [PATCH 1/2] Rename All Errata to All Types as we are refering to Erratas of all types (Bugfixes, Security) and it can be confused with the All Errata menu which refers to Relevant/All. See: https://www.redhat.com/archives/spacewalk-devel/2012-March/thread.html#2 --- .../frontend/strings/jsp/StringResource_en_US.xml |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/java/code/src/com/redhat/rhn/frontend/strings/jsp/StringResource_en_US.xml b/java/code/src/com/redhat/rhn/frontend/strings/jsp/StringResource_en_US.xml index 2cc91d6..becd5e4 100644 --- a/java/code/src/com/redhat/rhn/frontend/strings/jsp/StringResource_en_US.xml +++ b/java/code/src/com/redhat/rhn/frontend/strings/jsp/StringResource_en_US.xml @@ -3500,7 +3500,7 @@ button below, and lt;bgt;will be unable to log back inlt;/bgt;./source /context-group /trans-unit trans-unit id=erratalist.jsp.allerrata -sourceAll Errata/source +sourceAll Types/source context-group name=ctx context context-type=sourcefile/rhn/errata/AllErrata/context /context-group -- 1.7.7 From 27dae2a916f5aed5a59721492c38e625492db6c7 Mon Sep 17 00:00:00 2001 From: Duncan Mac-Vicar P dmacvi...@suse.de Date: Mon, 5 Mar 2012 13:32:49 +0100 Subject: [PATCH 2/2] Rename Toda la errata to Todos as we are refering to Erratas of all types (Bugfixes, Security) and it can be confused with the All Errata menu which refers to Relevant/All. See: https://www.redhat.com/archives/spacewalk-devel/2012-March/thread.html#2 (Spanish version) --- .../rhn/frontend/strings/jsp/StringResource_es.xml |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/java/code/src/com/redhat/rhn/frontend/strings/jsp/StringResource_es.xml b/java/code/src/com/redhat/rhn/frontend/strings/jsp/StringResource_es.xml index 813db7f..767f5b9 100644 --- a/java/code/src/com/redhat/rhn/frontend/strings/jsp/StringResource_es.xml +++ b/java/code/src/com/redhat/rhn/frontend/strings/jsp/StringResource_es.xml @@ -3491,7 +3491,7 @@ del rol de Administrador de la organización./target/trans-unit context-group name=ctx context context-type=sourcefile/rhn/errata/AllErrata/context /context-group - targetToda la errata/target/trans-unit + targetTodos/target/trans-unit !-- == AUDIT == -- trans-unit id=audit.overview.jsp.header -- 1.7.7 ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] rhn-prefix check when creating new channel
On 03/02/2012 04:20 PM, Miroslav Suchý wrote: On 03/02/2012 02:57 PM, Duncan Mac-Vicar P. wrote: As we replaced some errror messages Redhat with a configurable vendor string we now get the error message as Did I miss this patch? - Or its generic version: make it a vendor restriction and the regex configurable Hmm, this one sounds best to me. For channel validation there seems to be a bunch of duplicated code: NewChannelHelper and CreateChannelCommand both perform very similar validations. If I make the regexp rhn independent, configurable and switchable/optional it would be easier if the validations are refactored in one place. I think the right place for the validations is the helper, and the command class should consume the validations from the helper. Is that fine? Duncan ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] rhn-prefix check when creating new channel
Hi Astronauts The create channel page does a check for a prefix rhn-*. As we replaced some errror messages Redhat with a configurable vendor string we now get the error message as SUSE channels creation need admin privileges (or something like that) We are discussing how to remove that check in the best upstream-friendly way possible: - remove the restriction completely (btw, the regex is duplicated, I guess CreateChannelCommand could use the one in NewChannelHelper instead) - Allow to disable the check - Or its generic version: make it a vendor restriction and the regex configurable What do you think? In any case we need to get rid of the check, we are trying to avoid a patch in our tree that would live forever. cheers -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] All relevant errata as All Errata
On 03/02/2012 05:55 PM, Duncan Mac-Vicar P. wrote: On 03/02/2012 04:06 PM, Tomas Lestach wrote: There's one more thing confusing for me, when we're in the errata area. I mean following two pages https://spacewalk/rhn/errata/Overview.do https://spacewalk/rhn/errata/RelevantErrata.do display the same errata content. We might want to drop one of them. Ok, I have a patch that gets rid of errata/Overview.do. I need to rebase for master. attached. Is the removal of strings with this file as context needed? Duncan From 36ebcfc0f1be2cb7c193907f3a0f81716bb18771 Mon Sep 17 00:00:00 2001 From: Duncan Mac-Vicar P dmacvi...@suse.de Date: Fri, 2 Mar 2012 17:50:04 +0100 Subject: [PATCH] errata/Overview.do and errata/RelevantErrata.do provide the same list. Get rid of Overview and use RelevantErrata instead. See https://www.redhat.com/archives/spacewalk-devel/2012-March/msg3.html Conflicts: java/code/webapp/WEB-INF/nav/sitenav-authenticated.xml --- .../webapp/WEB-INF/nav/errata_overview_tabs.xml| 15 - .../webapp/WEB-INF/nav/sitenav-authenticated.xml |4 +- java/code/webapp/WEB-INF/pages/errata/overview.jsp | 27 --- java/code/webapp/WEB-INF/struts-config.xml | 34 +--- java/scripts/lwload.pl |2 +- 5 files changed, 4 insertions(+), 78 deletions(-) delete mode 100644 java/code/webapp/WEB-INF/nav/errata_overview_tabs.xml delete mode 100644 java/code/webapp/WEB-INF/pages/errata/overview.jsp diff --git a/java/code/webapp/WEB-INF/nav/errata_overview_tabs.xml b/java/code/webapp/WEB-INF/nav/errata_overview_tabs.xml deleted file mode 100644 index b259d08..000 --- a/java/code/webapp/WEB-INF/nav/errata_overview_tabs.xml +++ /dev/null @@ -1,15 +0,0 @@ -?xml version=1.0? -rhn-navi-tree label=errata_tabs invisible=1 formvar=prid title-depth=1 - rhn-tab name=erratalist.jsp.allerrata -rhn-tab-url/rhn/errata/Overview.do/rhn-tab-url - /rhn-tab - rhn-tab name=yourrhn.jsp.criticalsystems.bugfixerrata -rhn-tab-url/rhn/errata/OverviewBugErrata.do/rhn-tab-url - /rhn-tab - rhn-tab name=yourrhn.jsp.criticalsystems.enhancementerrata -rhn-tab-url/rhn/errata/OverviewEnhancementErrata.do/rhn-tab-url - /rhn-tab - rhn-tab name=yourrhn.jsp.criticalsystems.securityerrata -rhn-tab-url/rhn/errata/OverviewSecurityErrata.do/rhn-tab-url - /rhn-tab -/rhn-navi-tree diff --git a/java/code/webapp/WEB-INF/nav/sitenav-authenticated.xml b/java/code/webapp/WEB-INF/nav/sitenav-authenticated.xml index 49f9a2b..129cd55 100644 --- a/java/code/webapp/WEB-INF/nav/sitenav-authenticated.xml +++ b/java/code/webapp/WEB-INF/nav/sitenav-authenticated.xml @@ -109,8 +109,8 @@ /rhn-tab /rhn-tab /rhn-tab - rhn-tab name=Errata url=/rhn/errata/Overview.do active-image=tab-errata-selected.gif inactive-image=tab-errata.gif on-click=Sniglets::Lists-navi_empty_set node-id=target_systems_list -rhn-tab name=Errata url=/rhn/errata/Overview.do on-click=Sniglets::Lists-navi_empty_set node-id=target_systems_list + rhn-tab name=Errata url=/rhn/errata/RelevantErrata.do active-image=tab-errata-selected.gif inactive-image=tab-errata.gif on-click=Sniglets::Lists-navi_empty_set node-id=target_systems_list +rhn-tab name=Errata url=/rhn/errata/RelevantErrata.do on-click=Sniglets::Lists-navi_empty_set node-id=target_systems_list rhn-tab-directory/rhn/errata/rhn-tab-directory rhn-tab name=Relevant on-click=Sniglets::Lists-navi_empty_set node-id=target_systems_list rhn-tab-url/rhn/errata/RelevantErrata.do/rhn-tab-url diff --git a/java/code/webapp/WEB-INF/pages/errata/overview.jsp b/java/code/webapp/WEB-INF/pages/errata/overview.jsp deleted file mode 100644 index 6842a08..000 --- a/java/code/webapp/WEB-INF/pages/errata/overview.jsp +++ /dev/null @@ -1,27 +0,0 @@ -%@ taglib uri=http://rhn.redhat.com/rhn; prefix=rhn % -%@ taglib uri=http://rhn.redhat.com/tags/list; prefix=rl % -%@ taglib uri=http://java.sun.com/jsp/jstl/core; prefix=c % -%@ taglib uri=http://struts.apache.org/tags-html; prefix=html % -%@ taglib uri=http://struts.apache.org/tags-bean; prefix=bean % - -html:xhtml/ -html -head -meta name=page-decorator content=none / -/head -body -rhn:toolbar base=h1 img=/img/rhn-icon-errata.gif imgAlt=errata.overview.jsp.alt - helpUrl=/rhn/help/reference/en-US/s1-sm-errata.jsp - bean:message key=errata.overview.jsp.errataoverview/ -/rhn:toolbar - -rhn:dialogmenu mindepth=0 maxdepth=3 definition=/WEB-INF/nav/errata_overview_tabs.xml renderer=com.redhat.rhn.frontend.nav.DialognavRenderer / - -pbean:message key=errata.overview.jsp.summary//p - -h2bean:message key=errata.jsp.header//h2 - -%@ include file=/WEB-INF/pages/common/fragments/errata/relevant-errata-list.jspf % - -/body -/html diff --git a/java/code/webapp/WEB-INF/struts-config.xml b/java/code/webapp/WEB-INF/struts-config.xml index a6d7560..1d75f49 100644 --- a/java/code/webapp/WEB-INF/struts-config.xml +++ b/java/code/webapp/WEB-INF/struts-config.xml
Re: [Spacewalk-devel] moving zypp-plugin-spacewalk to spacewalk code base
On 10/31/2011 02:18 PM, Miroslav Suchy wrote: Dne 31.10.2011 11:41, Christian Berendt napsal(a): Why lives the zypp-plugin-spacewalk code in an external repository at the moment? We are aware of zypp-plugin-spacewalk, because it was announced here. But nobody sent us patch, which we can accept. Personally I would be happy if somebody from Suse would stand up and would create and maintain /client/suse. But nobody done it so far. I would even do it myself, but I'm unable to test zypp-plugin-spacewalk, because it require libzypp and that is not in Fedora. https://bugzilla.redhat.com/show_bug.cgi?id=729200#c5 So I could not test in on Fedora and I do not have time/energy to test it native on OpenSuse. I will discuss this with the team. I don't see the benefits yet as we need to keep branching very specific to ZYpp versions. Thanks for bringing this up. -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Bug #739009 to be taken over by SuSE ...
On 09/19/2011 06:01 PM, Milan Zazrivec wrote: Heya -- anybody from SuSE, please take a look at bug [1] and try to resolve the issue described. It's a SuSE client thing and I'd like you to take over the bug since I don't know squat about that platform :-) I am reassigning it to me :-) -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Bug #739009 to be taken over by SuSE ...
On 09/19/2011 06:01 PM, Milan Zazrivec wrote: Heya -- anybody from SuSE, please take a look at bug [1] and try to resolve the issue described. It's a SuSE client thing and I'd like you to take over the bug since I don't know squat about that platform :-) Can't reassign. Can you assign it to dmacvicar at suse.com? (not .de) -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Audit Logging
On 08/29/2011 04:32 PM, Ionuț Arțăriși wrote: So if the auditlogging server is down, then the XMLRPC API is down. The whole point of audit logging is to not let anything important pass through without having a record of it. You can of course turn the logging off from the server. And somehow the role Cliff mentions is done by the daemon itself, acting as a buffer/journal between the client and the outputs (syslog, database, etc). -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Audit Logging
On 08/30/2011 01:51 PM, Jan Pazdziora wrote: Sure. I'm just pointing out that you might save yourself some architecture and coding work if you consider the bigger picture and goals of the project and not just blindly focus on the narrow goal you have on your plate right now. The narrow goal that we have on our plate right now is basically the reason why we are implementing this feature. Of course we want this to be upstream, yes, and that is why Bo and Johannes started the discussion to get feedback of what could be improved. I have the impression the discussion is getting further from finding a common view as it progressed (the first replies where very valid suggestions). But now we are already on the topic of porting perl pages to Java. While we sure want to help with this in the future (monitoring anyone), it is not in the scope of what we need to deliver and we can't get out of our schedule in order to find the ultimate solution. If there is no agreement or the visions are too different, may be it would make sense to keep this in our tree for now and we would need to make the right decisions so that merging does not become too hard in the future. I don't find this ideal, because some of the proposals+feedback are not that intrusive, so they could be in the spacewalk tree and would be mostly optional for the user. Even the daemon is a XML-RPC interface so it can easily be replaced. Adding a logging setup to two stacks surely is less work than adding it to three, and if there still is the common goal of finishing the migration, I consider it a valid option to consider, whether to switch the order in which work is done and make things easier in total. I think Bo gave very a good explanation why this is not Logging but Auditing: more contextual/semantic data, security, tamper-proof, use cases, etc. -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Audit Logging
On 08/29/2011 03:14 PM, Cliff Perry wrote: In short, my personal preference is not to become a toaster if audit logging has crashed (including out of space to write). An alternative implementation we may consider for a second iteration is to have Spacewalk send the messages via AMPQ to a broker (apache QPid seems to have a reasonable footprint), and the current daemon could fetch from there to the outputs, turning itself into a simple agent. -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] quartz and slf4j
On 07/28/2011 04:18 PM, Jan Pazdziora wrote: On Tue, Jul 26, 2011 at 06:34:28PM +0200, Tomas Lestach wrote: I noticed quartz depends on spacewalk-slf4j. Why is there a custom version of slf4j (spacewalk-slf4j)? It's because slf4j isn't distributed in RHEL. And I believe we did not want to rebuild the whole slf4j because it requires maven or something and dependencies got ugly. So spacewalk-slf4j is just a minimal subset needed. I built slfj without maven. I can make sure it builds on Fedora/RHEL as well if you need it. We actually build lot of Java packages un-mavenizing them first using the maven ant:ant plugin, and then adding this tarball of build.xml to the source list. Maven is nothing you want in your build toolchain. -- Duncan Mac-Vicar P. - Novell® Making IT Work As One™ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] quartz and slf4j
Hi I noticed quartz depends on spacewalk-slf4j. Why is there a custom version of slf4j (spacewalk-slf4j)? Regards, -- Duncan Mac-Vicar P. - SUSE SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] plans to upgrade ivy version?
Hi I have in my workspace changes like this. +++ b/java/buildconf/build-taskdefs.xml @@ -1,16 +1,16 @@ project name=build-taskdefs target name=init-ivy depends=boot-deps unless=installbuild taskdef name=ivy-retrieve + classname=org.apache.ivy.ant.IvyRetrieve - classname=fr.jayasoft.ivy.ant.IvyRetrieve Is there a plan to upgrade the required ivy version? -- Duncan Mac-Vicar P. - SUSE SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] XML-RPC API for Erratas/Systems
Hi Is there a way to get system needing erratas from xml-rpc? I see only one to get affected systems for an _specific_ errata, which would mean to loop over all erratas, or loop over all systems and find needed erratas... Regards, -- Duncan Mac-Vicar P. - Novell® Making IT Work As One™ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] dojo - javascript framework
On 06/20/2011 07:51 PM, Shannon Hughes wrote: - it is not in Fedora :) don't see the downside of jquery not being in Fedora. This is javascript you have to set in your public web area anyway. jQuery does not need to be packaged. For public websites you can Advantages of jQuery? 1) It defines more a way to use javascript than a library itself. This means there is a full ecosystem built on top. For example, something equivalent to dojo: http://jqueryui.com The best part is that all jQuery based libraries feel the same, and it is easy to create your own extensions. 2) It is Unobtrusive JavaScript * http://en.wikipedia.org/wiki/Unobtrusive_JavaScript You don't have much javascript in the page itself, but you just give the elements the correct ids or classes and then enhance them, eg: input class=date... and then in some include you do: $(.date).datepicker() And all those inputs get a widget with a datepicker. But if not, the fallback is the input field it was there from the beginning. Same with tabs, you just make some divs with the right ids, and then you tab-ify them by appliying some method on a selector (ids, classes or more complex). 3) It is far more popular than any competition: 41% of the 1 most visited websites. That speaks for its community too. I like jQuery a lot. I would however use it as a resort to Ajaxify current webpages. As it is unobtrusive, it can be done without touching the templates too much, except for adding classes and ids. For more complex user interfaces, I would go for the combination of GWT/Vaadin. Javascript is cool, but is like the assembler of the browser machine. Assembler was cool back then, but today most people use higher level models. -- Duncan Mac-Vicar P. - Novell® Making IT Work As One™ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] dojo - javascript framework
On 06/22/2011 09:56 AM, Duncan Mac-Vicar P. wrote: jQuery does not need to be packaged. For public websites you can ... link it directly from google's CDN. http://code.google.com/apis/libraries/ -- Duncan Mac-Vicar P. - Novell® Making IT Work As One™ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] dojo - javascript framework
On 06/22/2011 11:55 AM, Miroslav Suchý wrote: Which unfortunately does not apply for Spacewalk, as it can be disconnected. I know. Also another cool extension of jquery is jquery mobile. If you follow some conventions you can unobtrusively adapt an user interface for mobile usage: http://jquerymobile.com -- Duncan Mac-Vicar P. - Novell® Making IT Work As One™ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ 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 05/18/2011 02:38 PM, Ionuț Arțăriși wrote: On 05/18/2011 01:14 PM, Jan Pazdziora wrote: ... Nack. This is SQL-injection-prone. You have to use bind parameters or sanitize the input properly. Thanks, I have fixed the SQL issue. Besides, if you allow the list of errata id's to be passed in, which would lead to multiple erratas to be returned, shouldn't you return the id as well to make it clear which advisory name belongs to which id? We don't exactly need the errata ids, but I can see how this might be useful, so I have changed the method to return a list of (id, advisory_name) tuples. This is tricky. What happens if the clients update their package, but the server is not updated yet (and therefore the API is not there)? We could catch the error and fallback to the packages-way, but it looks like a common scenario: the client requiring something from the server. Or we could look with getApiNamespaceCallList if the API is there. The question is what to do if it is not. -- Duncan Mac-Vicar P. - Novell® Making IT Work As One™ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ 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 05/13/2011 10:02 AM, Miroslav Suchý wrote:
If you go through SDC - software - errata - and you choose one.
It should result in:
errata.update
actions.
Which is picked up by:
client/rhel/rhn-client-tools/src/actions/errata.py
The transformation from errata to package list is there:
for errataid in errataidlist:
tmpList = __getErrataInfo(errataid)
packagelist = packagelist + tmpList
Thanks, I completely oversaw this errata action as I saw all installs
ending in packages.py (which we reimplemented), but now I see errata.py
actually uses packages.py.
Would it make more sense for errata.py to be in the yum-rhn-plugin?
For *SUSE I think we will have to override errata.py as zypper should
install the patch directly and not let the plugin resolve the package list.
Would it be acceptable upstream that we don't install errata.py from the
.spec file %if 0%{?suse_version} and supply it with
zypp-plugin-spacewalk (which contains package.py)?
Thanks for the hint.
--
Duncan Mac-Vicar P. - Novell® Making IT Work As One™
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix
Imendörffer, HRB 16746 (AG Nürnberg)
Maxfeldstraße 5, 90409 Nürnberg, Germany
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] (contribution) Novell testsuite for Spacewalk
On 01/27/2011 04:11 PM, Duncan Mac-Vicar P. wrote: Right now it will probably not work out of the box with Spacewalk (because some text links), but we would like to make the branding configurable so that it can be used with both Spacewalk and Satellite. btw, this is the output of the testsuite in html mode: http://www.suse.de/~dmacvicar/spacewalk/test-results.html -- Duncan Mac-Vicar P. - Novell® Making IT Work As One™ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] (contribution) ZYpp-based Spacewalk client for SUSE systems
Hi guys, The following code allows a openSUSE/SUSE system (= 11.4/Factory) to talk to a Spacewalk-compatible server. We pushed the source code to this repository: http://gitorious.org/opensuse/spacewalk-testsuite-base This is SUSE specific. We could keep it in gitorious.org/opensuse, but if you think spacewalk's git /client/suse is a better place, please let us know! Other patches will follow. Regards, -- Duncan Mac-Vicar P. - Novell® Making IT Work As One™ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] (contribution) ZYpp-based Spacewalk client for SUSE systems
On 01/27/2011 04:14 PM, Duncan Mac-Vicar P. wrote: We pushed the source code to this repository: http://gitorious.org/opensuse/spacewalk-testsuite-base Sorry, the repo for this one is http://gitorious.org/opensuse/zypp-plugin-spacewalk -- Duncan Mac-Vicar P. - Novell® Making IT Work As One™ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] XML-RPC testsuite proposal
On 01/20/2011 04:07 PM, Jan Vlček wrote: Hi, I have started working on XML-RPC testsuite for Spacewalk as a part of my bachelor thesis. Few ideas are concentrated in following Google Docs document. https://docs.google.com/Doc?docid=0AfRvg1ST7uS2ZGMzOG5ycm5fMjZjZ3YzMzhmcwhl=csauthkey=CIWYod8F https://docs.google.com/Doc?docid=0AfRvg1ST7uS2ZGMzOG5ycm5fMjZjZ3YzMzhmcwhl=csauthkey=CIWYod8F Hi Jan, we just pushed our testsuite to the open and we already test some stuff over XML-RPC there. It is based on cucumber, so tests can be human readable steps, and the steps itself can be implemented with various strategies: we control a browser to test the user interface, or ssh to the target machine to test that processes are running, and use a XML-RPC client to test the API. It would make a lot of sense if you could help us improve it. A pending feature is to make the branding configurable so that it works with all flavors of Spacewalk (ie, Satellite, or our SUSE port), but that is not much work. -- Duncan Mac-Vicar P. - Novell® Making IT Work As One™ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
