#4262: Provide deltaisos for Alpha, Beta, Final
by Fedora Release Engineering
#4262: Provide deltaisos for Alpha, Beta, Final
----------------------+-----------------------------------------------------
Reporter: robatino | Owner: rel-eng(a)lists.fedoraproject.org
Type: task | Status: new
Milestone: | Component: koji
Keywords: |
----------------------+-----------------------------------------------------
For a while now I've been providing deltaisos between Alpha, Beta, and
Final (in addition to the ones for TCs/RCs) at
[http://thepiratebay.org/user/andre14965/].
* When N Alpha is released I create 2 torrents from (N-1) Final to N
Alpha (one for i386 and one for x86_64).
* When N Beta is released I create 2 torrents from (N-1) Final to N Beta,
and 2 torrents from N Alpha to N Beta.
* When N Final is released I create 2 torrents from (N-1) Final to N
Final, and 2 torrents from N Beta to N Final.
For each milestone, each corresponding torrent consists of
* The old and new signed checksum files for the full ISOs,
* A deltaiso from the old DVD to the new DVD, and
* Deltaisos from the new DVD to each of the new CDs and the new netinst
(since split media is gone for F15 and later, only the one for DVD ->
netinst will be needed in the future).
The size of the diso for DVD -> netinst is negligible (around 50K or
less). The size of the disos starting with (N-1) Final is roughly half the
size of the full ISO, and increases only slightly from N Alpha to N Beta
to N Final. The size of the disos for N Alpha -> N Beta and N Beta -> N
Final is around 10-20% of the full ISO size (you can see the exact sizes
at the above torrent link).
The same exact format could be used to provide these torrents at
[http://torrent.fedoraproject.org]. For direct download mirrors, just the
disos could be posted. It's unnecessary to create any new signed checksum
files. It may be desirable to provide a crude checksum for the disos just
to make sure the download is good before running applydeltaiso (which can
take a significant amount of time - around 40-45 minutes for the disos
starting with (N-1) Final, and around 10-20 minutes for the ones from N
Alpha -> N Beta and N Beta -> N Final - the time for DVD -> netinst is
negligible).
The main obstacle is that each RPM in the new ISO must be compressed using
the exact same compression. For example, the recent change in xz
compression means that Rawhide currently consists of RPMs built using both
the old and new compression, so it would be impossible to generate working
disos from 14 Final to either 15 Alpha, 15 Beta, or 15 Final. Deltaisos
for 15 Alpha -> 15 Beta and 15 Beta -> 15 Final should work (assuming that
the user has the new xz installed on the machine which runs
applydeltaiso). For the user to temporarily change xz version is a minor
nuisance - someone running anything from F11 to F14 can temporarily change
the xz-\* packages to the F15/Rawhide version, and someone running
F15/Rawhide can temporarily downgrade xz-\* to the F14 version. Of course
it's important to restore the original versions of xz-\* after running
applydeltaiso, otherwise yum-presto won't be able to apply drpms in
updates.
Some links regarding the xz compression change:
* https://bugzilla.redhat.com/show_bug.cgi?id=644046
* http://lists.fedoraproject.org/pipermail/devel/2010-October/144651.html
* http://lists.fedoraproject.org/pipermail/test/2010-October/094883.html
* https://fedorahosted.org/rel-eng/ticket/4224
I volunteer to do any necessary work in creating and checking the diso
content (though it's actually pretty trivial) or in writing user
documentation. In closing I'd like to point out that although refining
compression in order to reduce the size of full ISOs is important, at some
point there will be diminishing returns (I don't know if it's reasonable
to expect the large improvement of 10-15% in going from gzip to xz to
happen again). On the other hand, there's no reason to expect delta
compression, which reduces download size by 50% or more, to get any worse.
So in the long run, it doesn't make sense to keep ignoring delta
compression in the quest to make ISOs a few percent smaller.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/4262>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
12 years, 11 months
#3565: Please Tag libproxy-0.3.1-4.fc13 for F-13 Beta - default install of libproxy modules
by Fedora Release Engineering
#3565: Please Tag libproxy-0.3.1-4.fc13 for F-13 Beta - default install of
libproxy modules
----------------------------+-----------------------------------------------
Reporter: kwizart | Owner: rel-eng(a)lists.fedoraproject.org
Type: task | Status: new
Milestone: Fedora 13 Beta | Component: koji
Keywords: |
----------------------------+-----------------------------------------------
Hello,
I request libproxy-0.3.1-4.fc13 to be tagged as F-13 Beta.
This is the last update before the ABI change of the 0.4.0 version that
has already appeared in F-14.
Here is the Changelog between 0.2.3 and 0.3.1:
http://code.google.com/p/libproxy/source/browse/trunk/ChangeLog
On a side note, installing libproxy on a default desktop install of F-13
Alpha will, lead to have:
libproxy
libproxy-bin
libproxy-python
With this package, the default will lead to have:
libproxy
And that will be all, as all unneeded dependencies have been dropped as
described in:
https://bugzilla.redhat.com/show_bug.cgi?id=537569
Once that said, it would be more valuable to have libproxy-gnome installed
as soon as the gnome desktop is selected on install. (1)
Upstream advice is to use Rpm's 'Suggests' instead of 'Requires', as
requires would imply some circle dependencies.
But we don't use Suggests much if possible. So I think it would be better
handled by comps for now.
(1)
Same for:
libproxy-kde and KDE desktop
libproxy-mozjs and firefox
libproxy-webkit and WebKit-gtk
libproxy-networkmanager and NetworkManager
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/3565>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
12 years, 11 months
#4274: delete acidentally created branch
by Fedora Release Engineering
#4274: delete acidentally created branch
---------------------+------------------------------------------------------
Reporter: jvcelak | Owner: rel-eng(a)lists.fedoraproject.org
Type: task | Status: new
Milestone: | Component: git
Keywords: |
---------------------+------------------------------------------------------
Hi,
I accidentally managed to create remote branch by typing:
{{{
$ git push f14:origin/f14/master
}}}
Instead of:
{{{
$ git push origin f14:f14/master
}}}
But I'm unable to delete it now:
{{{
$ git push origin :origin/f14/master
remote: + refs/heads/origin/f14/master tuned jvcelak DENIED by fallthru
remote: error: hook declined to update refs/heads/origin/f14/master
To ssh://jvcelak@pkgs.fedoraproject.org/tuned
! [remote rejected] origin/f14/master (hook declined)
error: failed to push some refs to
'ssh://jvcelak@pkgs.fedoraproject.org/tuned'
}}}
Please, can you delete it for me? It's tuned component.
(Maybe the hooks are wrong if I'm able to create the branch, but not to
delete it.)
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/4274>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
13 years, 2 months
#3575: Provide deltaisos for development releases
by Fedora Release Engineering
#3575: Provide deltaisos for development releases
--------------------+-------------------------------------------------------
Reporter: kparal | Owner: rel-eng(a)lists.fedoraproject.org
Type: task | Status: new
Milestone: | Component: other
Keywords: |
--------------------+-------------------------------------------------------
'''Background:'''
Currently Fedora 13 is in a development, that means Test Composes, Release
Candidates and Final versions of Alpha/Beta/Final milestones are regularly
released. During this period there may be even several releases in one
week. Each release consists of 1x 3.5GB DVD, 6x 700MB CD, 1x 200MB netinst
image and 1x 1GB LiveCD. This is created for i386 and x86_64
architectures.
This is quite large amount of data. Every person interested in occasional
or regular testing must download substantial part of this release. That
makes certain demands on user's internet connection and also !RelEng
infrastructure (internet bandwidth, I/O).
'''Proposal:'''
Release Engineering team will create a deltaiso file for every release of
current Fedora development series. This deltaiso file will contain
differences between that particular release and a previous release. That
means deltaisos will be created in this fashion:
* Fedora 13 Alpha TC1 -> Fedora 13 Alpha TC2
* Fedora 13 Alpha TC2 -> Fedora 13 Alpha RC1
* Fedora 13 Alpha RC1 -> Fedora 13 Alpha
* Fedora 13 Alpha -> Fedora 13 Beta TC1
* Fedora 13 Beta TC1 -> Fedora 13 Beta RC1
* Fedora 13 Beta RC1 -> Fedora 13 Beta RC2
* Fedora 13 Beta RC2 -> Fedora 13 Beta
* Fedora 13 Beta -> Fedora 13 (Final) TC1
* Fedora 13 (Final) TC1 -> Fedora 13 (Final) RC1
* Fedora 13 (Final) RC1 -> Fedora 13 (Final) RC2
* Fedora 13 (Final) RC2 -> Fedora 13 (Final)
Because deltaisos are useful typically for media that consists
[https://fedoraproject.org/wiki/Delta_ISOs mainly of RPM files] this
process would involve mainly DVD image and would not involve LiveCD. For
other media (CD, netinst) the decision is still to be made. Deltaisos for
DVDs are [http://thepiratebay.org/user/andre14965/ typically around
100MB].
Deltaisos will be stored in a single directory (e.g. deltaisos/ in
[http://alt.fedoraproject.org/pub/alt/stage/ /pub/alt/stage]), so it is
easy to convert any older ISO the user currently has into a new one, even
several releases forward. These deltaisos will be stored for the period of
the development release - beginning with Fxx Alpha TC and ending with Fxx
Final (with a small extra time after the final release to allow people to
upgrade their ISOs to the final release).
The deltaiso creation process may be easily automated and
[https://fedoraproject.org/wiki/Delta_ISOs is described on our wiki]. No
additional human interaction should be needed.
'''Rationale:'''
The main reason for this proposal is to enable people with slower internet
connection to participate in installation testing. This often involves not
only developing countries, but also highly-developed countries
[http://lists.fedoraproject.org/pipermail/devel/2010-March/133326.html
like the USA]. I believe that although some more people would be
interested in doing installation testing, it is currently too expensive
for them from download time and bandwidth perspective.
Quite interestingly this also includes me as a Red Hat employee. While it
is my job to perform installation testing regularly, our office does not
have internet line thick enough such that I could afford downloading DVD-
sized images several times a week. Performing regular nightly mirroring is
not an option when new releases may be pushed even daily.
Up till now Andre Robatino (CCed) has been performing the repetitive task
of downloading every development release for every architecture, creating
deltaisos and publishing them [http://thepiratebay.org/user/andre14965/ as
torrents] (because he doesn't have any publicly available storage). Our
evidence shows that these torrents are used, which means they are useful
for people (and his work is invaluable for me personally). QA has started
to exploit his work officially
[https://fedoraproject.org/wiki/Test_Results:Fedora_13_Beta_RC3_Install on
every installation testing page].
The problem is that Andre is usually the only seeder, so the download
speed is really slow and there are connection problems sometimes, so
people often
[http://lists.fedoraproject.org/pipermail/test/2010-March/089110.html
complain about it]. Second problem is that those deltaisos are published
with a noticeable delay (Andre has to detect new release, download, build,
upload and announce). Overall this a huge waste of Andre's time and
energy. A defined and automated process from !RelEng side would simplify
all of this and improve the experience for our users a lot.
Another benefit would be lowered IO/bandwidth load on Fedora
infrastructure.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/3575>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
13 years, 2 months
#4264: 2 Packages missing from mirrors
by Fedora Release Engineering
#4264: 2 Packages missing from mirrors
--------------------+-------------------------------------------------------
Reporter: limb | Owner: rel-eng(a)lists.fedoraproject.org
Type: defect | Status: new
Milestone: | Component: mash
Keywords: |
--------------------+-------------------------------------------------------
gdesklet-SlideShow-0.9-9.fc14 should be in stable since 8/23
kdelibs-4.5.2-8.fc14 should be in stable since 11/3.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/4264>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
13 years, 3 months
#4322: Adding libktorrent-1.0.5 to F13/F14 default buildroot
by Fedora Release Engineering
#4322: Adding libktorrent-1.0.5 to F13/F14 default buildroot
--------------------+-------------------------------------------------------
Reporter: nucleo | Owner: rel-eng(a)lists.fedoraproject.org
Type: task | Status: new
Milestone: | Component: koji
Keywords: |
--------------------+-------------------------------------------------------
Hi,
ktorrent-4.0.5 needs libktorrent-1.0.5 to be added in F13/F14 default
buildroot.
Please add to the F13 and F14 default buildroot
libktorrent-1.0.5-1.fc13 and libktorrent-1.0.5-1.fc14
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/4322>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
13 years, 3 months
#4320: dead package perl-Moose-Policy
by Fedora Release Engineering
#4320: dead package perl-Moose-Policy
----------------------+-----------------------------------------------------
Reporter: mmaslano | Owner: rel-eng(a)lists.fedoraproject.org
Type: task | Status: new
Milestone: | Component: git
Keywords: |
----------------------+-----------------------------------------------------
Please mark this package as dead. The maintainer is on long vacation (see
https://fedorahosted.org/fesco/ticket/507). We (Perl SIG) are taking care
of his packages, so could you please fix this one?
Reason for dead package: upstream mark it as dead.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/4320>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
13 years, 4 months
#4321: Please tag libechonest to buildroot override
by Fedora Release Engineering
#4321: Please tag libechonest to buildroot override
------------------+---------------------------------------------------------
Reporter: oget | Owner: rel-eng(a)lists.fedoraproject.org
Type: task | Status: new
Milestone: | Component: koji
Keywords: |
------------------+---------------------------------------------------------
That is
{{{
libechonest-1.1.0-1.fc14
libechonest-1.1.0-1.fc13
}}}
for F-14 and F-13 respectively. I need them to build the new version of
clementine.
Thanks.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/4321>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
13 years, 4 months
