Spec URL: http://blog.fedora-fr.org/public/smootherfrogz/SPECS/xenman.spec SRPM URL: http://blog.fedora-fr.org/public/smootherfrogz/RPMs/xenman-0.6-2.fc6.src.rpm Description: XenMan is an intuitive, graphical management tool aimed at operational lifecycle management for the Xen virtualization platform. With XenMan's secure, multi-node administration, performance management and provisioning capabilities, administrators can safely manage their entire environment from a single, centralized console. Most common administrative tasks like starting, stopping, monitoring and provisioning virtual machines (Guest OS's) typically involve just a few mouse clicks with XenMan; as do server management operations like scanning OS configurations or acquiescing individual servers for maintainance. Hi, I packaged this program and i would appreciate a review so that i can get it into fedora extras.
I'll have a look at it.
According to http://xenman.sourceforge.net/ XenMan was renamed to ConVirt. Is Xenman really the right name for the RPM?
Although I don't believe this is part of the formal packaging guidelines, the PAM config file that is included for the console-helper magic does not follow the standard used by other console-helper enabled apps. eg, xenman RPM installs a file containing # cat /etc/pam.d/xenman #%PAM-1.0 auth sufficient pam_rootok.so auth sufficient pam_timestamp.so auth include system-auth session required pam_permit.so session optional pam_xauth.so session optional pam_timestamp.so account required pam_permit.so While other apps typically delegate the config: # cat /etc/pam.d/system-config-network #%PAM-1.0 auth include config-util account include config-util session include config-util The latter config makes it easy to manage all the apps' PAM configs in one place. The app appears configured in /etc/xenman.conf to write to /var/log/xenman, but the RPM does not create this directory. I don't know if the application takes care of rotatings log files itself, but if not it installing a config into /etc/logrotate.d would be desirable.
(In reply to comment #2) > According to http://xenman.sourceforge.net/ XenMan was renamed to ConVirt. Is > Xenman really the right name for the RPM? Convirt is the project name. (In reply to comment #3) >While other apps typically delegate the config: it'll be change to follow the same way of all PAM config. >The app appears configured in /etc/xenman.conf to write to /var/log/xenman, but >the RPM does not create this directory. I don't know if the application takes >care of rotatings log files itself, but if not it installing a config into >/etc/logrotate.d would be desirable. Don't really need it in spec file, the apps is in charge for log file.
(In reply to comment #4) > (In reply to comment #2) > > According to http://xenman.sourceforge.net/ XenMan was renamed to ConVirt. Is > > Xenman really the right name for the RPM? > > Convirt is the project name. > > (In reply to comment #3) > >While other apps typically delegate the config: > > it'll be change to follow the same way of all PAM config. > > >The app appears configured in /etc/xenman.conf to write to /var/log/xenman, but > >the RPM does not create this directory. I don't know if the application takes > >care of rotatings log files itself, but if not it installing a config into > >/etc/logrotate.d would be desirable. > > Don't really need it in spec file, the apps is in charge for log file. and rpm is in charge to own the dirs and be able to remove it aswell. maybe it would make sense to also touch an empty logfile and get it owned by the package? ;)
That's right... i'll add it ;-) and post the updated spec file and srpm. thanks
>maybe it would make sense to also touch an empty logfile and get it owned by the >package? Add it in %post ands as %ghost file, what do you think about it ?
(In reply to comment #7) > >maybe it would make sense to also touch an empty logfile and get it owned by > the >package? > > Add it in %post ands as %ghost file, what do you think about it ? Doesn't sound good. Just create it in %install and simply add %{_sysconfdir}/log/%{name} to %files.
Spec URL: http://blog.fedora-fr.org/public/smootherfrogz/SPECS/xenman.spec SRPM URL: http://blog.fedora-fr.org/public/smootherfrogz/RPMs/xenman-0.6-3.fc6.src.rpm Added Logfile as mentioned in xenman.conf file in /etc/ (in reply to comment #8) >Just create it in %install and simply add >%{_sysconfdir}/log/%{name} to %files. better place in, %{_localstatedir}/log/%{name}
(Removing NEEDSPONSOR: bug 225075)
fixed some minor stuff. New updated files: http://blog.fedora-fr.org/public/smootherfrogz/SPECS/xenman.spec http://blog.fedora-fr.org/public/smootherfrogz/RPMs/xenman-0.6-4.fc6.src.rpm
Just built (sucessfully) in mock and I have noticed that the docs are packaged twice: in /usr/share/xenman/doc and in /usr/share/doc/xenman-0.6 Also, I do not think that the content of /usr/share/xenman/patches is worth shipping, because FC5, FC6 and devel all have python-paramiko>=1.6.4
Unassigning this bug due to my lack of time...
Still need to be reviewed (just a lil' up)
This isn't showing up in the list of tickets to be reviewed because the status is set to "POST". I only saw it because I'm cleaning up the old FE-NEW tracker. Let me see if I can get it to show up properly.
OK, this is showing up in the new package list now. However, I don't see any indication that the issues raised in comment 12 have been addressed, and I view this as unapprovable until they are.
ho yeah, Will fix this
I am somewhat confused by this package. The screenshots show it is for administrating xen servers. It depends on python-paramaibo, which is the python-ssh client. Yet it requires xen on the local machine? People tend to have more then 1 xen server (if only to be able to migrate). It would be great if this GUI would support adding remote xen servers.
Feature requests like this should really go upstream, shouldn't they?
> I am somewhat confused by this package. The screenshots show it is for > administrating xen servers. It depends on python-paramaibo, which is the > python-ssh client. Yet it requires xen on the local machine? only for local administration (i.e local managing domain) > People tend to have more then 1 xen server (if only to be able to migrate). > It would be great if this GUI would support adding remote xen servers. actually it able to do so (through ssh).
well, here is the fix SPEC: http://laxathom.fedorapeople.org/RPMS/xenman/xenman.spec SRPM: http://laxathom.fedorapeople.org/RPMS/xenman/xenman-0.6-5.fc8.src.rpm
Fedora apologizes that these issues have not been resolved yet. We're sorry it's taken so long for your bug to be properly triaged and acted on. We appreciate the time you took to report this issue and want to make sure no important bugs slip through the cracks. If you're currently running a version of Fedora Core between 1 and 6, please note that Fedora no longer maintains these releases. We strongly encourage you to upgrade to a current Fedora release. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained and closing them. http://fedoraproject.org/wiki/LifeCycle/EOL If this bug is still open against Fedora Core 1 through 6, thirty days from now, it will be closed 'WONTFIX'. If you can reporduce this bug in the latest Fedora version, please change to the respective version. If you are unable to do this, please add a comment to this bug requesting the change. Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we are following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again. And if you'd like to join the bug triage team to help make things better, check out http://fedoraproject.org/wiki/BugZappers
We must not close review requests automatically :( By the way, will you still want to have this package reviewed, Xavier? (I have no knowledge about Xen...)
Hmm, no response to Mamoru's question in seven months. I don't even know if there's any point to this package in the new KVM and libvirt world, but if there's no response soon then I guess I'll just close this.
thanks for the heads up Jason. No mail report received from previous update of this bug. Well, upstream has moved its software to Convirt (with KVM and libvirt support) since few months already. I'll just make it available in a new Review request. So I think this bug can be easily close.
Okay, thank you for update.