Fedora 13 Final TC1 is now available [1]. Please refer to the following pages for download links and testing instructions.
Installation:
https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test
Desktop:
https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test
Ideally, all Alpha, Beta, and Final priority test cases for installation [2] and desktop [3] should pass in order to meet the Final Release Criteria [4]. Help is available on #fedora-qa on irc.freenode.net [5], or on the test list [6].
[1] http://poelstra.fedorapeople.org/schedules/f-13/f-13-quality-tasks.html [2] https://fedoraproject.org/wiki/QA:Installation_validation_testing [3] https://fedoraproject.org/wiki/QA:Desktop_validation_testing [4] https://fedoraproject.org/wiki/Fedora_13_Final_Release_Criteria [5] irc://irc.freenode.net/fedora-qa [6] https://admin.fedoraproject.org/mailman/listinfo/test
_______________________________________________ test-announce mailing list test-announce@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce
Hi, It would be nice if Jigdo downloads could be also provided so that people with previous releases (e.g. Beta release) which have downloaded (and cached) updates could easily create new installation media without downloading much (which will be much less than delta isos).
Good luck, Hedayat
/*Andre Robatino andre@bwh.harvard.edu*/ wrote on 04/30/2010 12:14:32 AM +0450:
Fedora 13 Final TC1 is now available [1]. Please refer to the following pages for download links and testing instructions.
Installation:
https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test
Desktop:
https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test
Ideally, all Alpha, Beta, and Final priority test cases for installation [2] and desktop [3] should pass in order to meet the Final Release Criteria [4]. Help is available on #fedora-qa on irc.freenode.net [5], or on the test list [6].
[1] http://poelstra.fedorapeople.org/schedules/f-13/f-13-quality-tasks.html [2] https://fedoraproject.org/wiki/QA:Installation_validation_testing [3] https://fedoraproject.org/wiki/QA:Desktop_validation_testing [4] https://fedoraproject.org/wiki/Fedora_13_Final_Release_Criteria [5] irc://irc.freenode.net/fedora-qa [6] https://admin.fedoraproject.org/mailman/listinfo/test
test-announce mailing list test-announce@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce
On 04/30/2010 04:46 AM, Hedayat Vatankhah wrote:
Hi, It would be nice if Jigdo downloads could be also provided so that people with previous releases (e.g. Beta release) which have downloaded (and cached) updates could easily create new installation media without downloading much (which will be much less than delta isos).
Jigdo/rsync/zsync all have roughly the same efficiency (ignoring the large template file which must initially be downloaded when using jigdo) in that they avoid downloading unchanged packages, but updated packages must be downloaded in full. Deltaisos also avoid downloading unchanged packages, but in addition save space for updated packages by using deltarpms instead of full RPMs. So a deltaiso between 2 given ISOs should always be more efficient (in terms of size) than any of the others in doing the conversion. Of course this is assuming that a single deltaiso between the two ISOs is available (as opposed to having to use several to go from A to B, then from B to C, etc. which is much less efficient). It's not feasible to produce a deltaiso between every pair of ISOs since the number grows quadratically. However, most testers download each TC/RC, so deltaisos just between successive TCs/RCs are usually enough.
On the other hand, using deltarpms is expensive in terms of CPU. The tradeoffs between downloading deltarpms vs. full RPMs are exactly the same for using deltaisos vs. jigdo/rsync/zsync as they are for using yum-presto vs. not using it, so anyone who currently finds yum-presto of benefit should be better off using deltaisos vs. any of the other choices (even if they were available).
Well, I'm not going to insist on providing jigdo. However, the situation in my mind is this one: I've downloaded Fedora 13 Beta DVD iso previously and installed it on my system. Then, I've updated my system regularly (using yum presto) and I use yum's "keepcache=1" option. So, my Fedora Beta DVD iso + cached updated rpms would provide a considerable number of files available in the next DVD iso; so if jigdo is available I would probably be able to create the next iso without downloading many rpm packages.
Certainly, the efficiency in this case depend on the installation. A minimal installation will not have many rpms and so will not receive new versions of most rpms when updating.
Thanks anyway, Hedayat
/*Andre Robatino andre@bwh.harvard.edu*/ wrote on 04/30/2010 2:14:32 PM +0450:
On 04/30/2010 04:46 AM, Hedayat Vatankhah wrote:
Hi, It would be nice if Jigdo downloads could be also provided so that people with previous releases (e.g. Beta release) which have downloaded (and cached) updates could easily create new installation media without downloading much (which will be much less than delta isos).
Jigdo/rsync/zsync all have roughly the same efficiency (ignoring the large template file which must initially be downloaded when using jigdo) in that they avoid downloading unchanged packages, but updated packages must be downloaded in full. Deltaisos also avoid downloading unchanged packages, but in addition save space for updated packages by using deltarpms instead of full RPMs. So a deltaiso between 2 given ISOs should always be more efficient (in terms of size) than any of the others in doing the conversion. Of course this is assuming that a single deltaiso between the two ISOs is available (as opposed to having to use several to go from A to B, then from B to C, etc. which is much less efficient). It's not feasible to produce a deltaiso between every pair of ISOs since the number grows quadratically. However, most testers download each TC/RC, so deltaisos just between successive TCs/RCs are usually enough.
On the other hand, using deltarpms is expensive in terms of CPU. The tradeoffs between downloading deltarpms vs. full RPMs are exactly the same for using deltaisos vs. jigdo/rsync/zsync as they are for using yum-presto vs. not using it, so anyone who currently finds yum-presto of benefit should be better off using deltaisos vs. any of the other choices (even if they were available).
On 04/30/2010 06:25 AM, Hedayat Vatankhah wrote:
Well, I'm not going to insist on providing jigdo. However, the situation in my mind is this one: I've downloaded Fedora 13 Beta DVD iso previously and installed it on my system. Then, I've updated my system regularly (using yum presto) and I use yum's "keepcache=1" option. So, my Fedora Beta DVD iso + cached updated rpms would provide a considerable number of files available in the next DVD iso; so if jigdo is available I would probably be able to create the next iso without downloading many rpm packages.
Certainly, the efficiency in this case depend on the installation. A minimal installation will not have many rpms and so will not receive new versions of most rpms when updating.
That's a good point - if many of the updated RPMs in the new ISO have already been downloaded and cached, then jigdo/rsync/zsync looks much better, since most if not all of the exact RPMs in the new ISO are already available. If rsync or zsync were available, you could get the same benefit as jigdo by concatenating your old ISO and all of your new cached RPMs together into a single large file, and running rsync/zsync on that to convert it into the new ISO. Unfortunately, rsync runs on the server, and turned out to be a resource hog, so it's not currently used for development images. Zsync runs on the client so shouldn't have this problem. Unfortunately, it's not available in Fedora yet. See
http://kparal.wordpress.com/2009/09/01/zsync-transfer-large-files-efficientl...
https://bugzilla.redhat.com/show_bug.cgi?id=490140
https://bugzilla.redhat.com/show_bug.cgi?id=495310
Zsync would also be perfect for converting between different install disc sets (currently the DVD and the CD set) since the packages are exactly the same. It can also be used to efficiently convert from the first disc in either set to the netinst disc. So I'd certainly like to see it in Fedora.
/*Andre Robatino andre@bwh.harvard.edu*/ wrote on 04/30/2010 3:13:26 PM +0450:
On 04/30/2010 06:25 AM, Hedayat Vatankhah wrote:
Well, I'm not going to insist on providing jigdo. However, the situation in my mind is this one: I've downloaded Fedora 13 Beta DVD iso previously and installed it on my system. Then, I've updated my system regularly (using yum presto) and I use yum's "keepcache=1" option. So, my Fedora Beta DVD iso + cached updated rpms would provide a considerable number of files available in the next DVD iso; so if jigdo is available I would probably be able to create the next iso without downloading many rpm packages.
Certainly, the efficiency in this case depend on the installation. A minimal installation will not have many rpms and so will not receive new versions of most rpms when updating.
That's a good point - if many of the updated RPMs in the new ISO have already been downloaded and cached, then jigdo/rsync/zsync looks much better, since most if not all of the exact RPMs in the new ISO are already available. If rsync or zsync were available, you could get the same benefit as jigdo by concatenating your old ISO and all of your new cached RPMs together into a single large file, and running rsync/zsync on that to convert it into the new ISO. Unfortunately, rsync runs on the server, and turned out to be a resource hog, so it's not currently used for development images. Zsync runs on the client so shouldn't have this problem. Unfortunately, it's not available in Fedora yet. See
http://kparal.wordpress.com/2009/09/01/zsync-transfer-large-files-efficientl...
https://bugzilla.redhat.com/show_bug.cgi?id=490140
https://bugzilla.redhat.com/show_bug.cgi?id=495310
Zsync would also be perfect for converting between different install disc sets (currently the DVD and the CD set) since the packages are exactly the same. It can also be used to efficiently convert from the first disc in either set to the netinst disc. So I'd certainly like to see it in Fedora.
Yes, I would certainly prefer zsync if it was available (it would be even better than jigdo, as it does not even need the exact rpms).
Hi all,
It seems like garrick became unresponsive for years. His latest koji build time is 2008-04-17 05:43:55. Some of his packages in rawhide are even older than el-4 branch maintained other maintainers. Should we initiate the non-responsive maintainer process?
e.g. http://koji.fedoraproject.org/koji/packageinfo?packageID=4005
Regards, Chen Lei