Andrea,
I've read all the responses and there are merits to both 1 and 2 as well
as Bernard Li's response.
- My vote goes for 2.
- should not have binaries availble which are broken and this will
fix the current problem without introducing any
other issues.
- option 1 should be released a 4.0.1( ie pre release of 4.0.2) and
tested.
Thanks
David K Livingstone
CN Signals and Communications
10229 127 Avenue floor 2
Edmonton, AB, T5E 0B9
Ph : 780 472-3959 Fax : 780 472-3050
Email: [EMAIL PROTECTED]
Andrea Righi <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
2007/11/07 16:29
Please respond to
[EMAIL PROTECTED]; Please respond to
sisuite-users@lists.sourceforge.net
To
Brian Elliott Finley <[EMAIL PROTECTED]>, Erich Focht <[EMAIL PROTECTED]>,
Bernard Li <[EMAIL PROTECTED]>
cc
sisuite-dev s <[EMAIL PROTECTED]>, sisuite-users
<sisuite-users@lists.sourceforge.net>
Subject
[sisuite-users] [ RFC ] SystemImager 4.0.2 or not? (was: client netboot
fails (rsync: failed to set times))
Hi all,
it seems that someone is agree with me and someone is not about the
solution to
add the pre-release of rsync (3.0.0pre4) into the stable branch of
SystemImager
and tag the new 4.0.2 stable ASAP (4.0.1, since ".1" is odd, is reserved
for
development pre-releases).
So, probably this is the first polling in these lists :-), don't know, but
I
would really like to know opinion of the community about this issue.
The fact is that the current stable release of SystemImager 4.0.0 is not
"stable" enough: there is a bug that occurs with rsync when it's built on
a
machine with a kernel >= 2.6.22 (that's actually my build server) and the
installing client uses a kernel < 2.6.22:
See http://www.systemimager.org:8000/trac.systemimager.org/ticket/6 for
details,
many thanks to Rochus Schmid for reporting this bug.
The proposed solutions for now are:
1) use the pre-release of rsync that seems to fix the problem and tag
SystemImager 4.0.2, leaving the 4.0.0 packages as they are, let me say
that I
would just proceed like the kernel guys do if there's a bug in the kernel
(just
leave all the previous released kernels "forzen" and available for
download in
any case, and always release new versions in case of errors/bugs)
2) remove the old 4.0.0 packages from SF.net (let me say "close" them to
the
users), rebuild all the packages in a build server with a kernel < 2.6.22
and
then release the new packages using the same version number: 4.0.0
3) rebuild the packages in a build server with a kernel < 2.6.22 and
changing
the version number to 4.0.2, leaving 4.0.0 packages as they are on SF.net
4) other ideas are welcome...
I vote for 1).
-Andrea
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
sisuite-users mailing list
sisuite-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sisuite-users
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
sisuite-users mailing list
sisuite-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sisuite-users
