6:30 p.m.
Hi!
just thought I write down a rough list of things that I plan to do
for
RPM Fusion over the next couple of weeks. I'm sending it here in the
hope that some people help me with some of those task; then we hopefully
get RPM Fusion running quite soon.
Here is a updated version; most important things at the top of the list;
not all of the points necessarily have to be done, but ideally they all
get done; if I missed anything just tell me ;-)
- get the mirror manager that adrianr put in place (see
http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2008-October/00...
listed as mirrors.rpmfusion.org in DNS;
Needs
* adrianr: IP address
* thias: DNS update
Afterwards update rpmfusion-release packages accordingly.
- get the remaining packages from dribble and livna into the repo and
eveything fixed up; latest status can be found here:
http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2008-October/00...
- start importing and building the packages from freshrpms; I can do
that, but I want to get the ACK from thias first; especially as
http://rpmfusion.org/InitialPackageMerge likely is not fully up to date
Having a list of packages that are ready for importing would help things
a lot
- someone should run dep checks (e.g. for F8, F9 rawhide; once with only
free and once with both free and nonfree enabled); I suspect that some
problems will be found that way
- check that the upgrade path from Livna -> RPM Fusion is sane for each
package in each of the supported Fedora releases (I did a rough check on
F9; looks good, but there are some packages still missing; maybe we can
ignore those for now, as some of them are broken in livna, so it's not
much of a difference)
- get the dep checker script from Fedora Extras/EPEL in place and let it
automatically run after each successful push; if possible without to
much work get upgradecheck running as well (Xavier is working on it afaik)
- make sure all the kernel-modules from freshrpms are converted to
kmods; also make sure all the update path for frehsrpms dkms users to
akmods work
- prepare a announcement mail
- put rpmfusion-release packages into livna-testing repos for F-8 and
F-9 to move all the testing users over
- move packages from testing -> stable for F-8 and F-9; build new
rpmfusion-release packages that have the testing repo disabled!
- put rpmfusion-release packages into livna repos for F-8 and F-9 to
move all the users over
- announce
- vacation
= not that important =
- in parallel to all the above: work further on getting the crucial
packages into the EL repo for RPM Fusion (
http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2008-September/...
). Libmp4v2 (needed by faad2) is still blocking that work right now;
https://bugzilla.redhat.com/show_bug.cgi?id=466951
- test if current comps.xml stuff works on rawhide-anaconda; if yes then
convert comps.xml from nonfree as well; details:
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02105...
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02600...
- are the nvidia bits sane? There were some mails about the 177series,
but seems some questions were not answered yet
= End =
That's round about it from the top of my head. Did I miss anything?
Likely, but I think I'm optimistic that I got the most important things
on the list :-)
Help for all the remaining tasks much appreciated. The mroe help, the
quicker we can start RPM Fusion for real.
Cu
knurd
2:18 a.m.
Thorsten Leemhuis wrote:
- are the nvidia bits sane? There were some mails about the 177series,
but seems some questions were not answered yet
As far as I know (correct me if I'm wrong Nicolas), we're dropping 177 for
Livna F-8/9 and focus on the move to RPM Fusion and provide it there
instead. Nicolas is still testing the final bits of the parallel-installable
drivers, from there I'm going to write a quick initscript and redo bits of
livna-config-display and then everything should be ready.
(for fglrx, if rumors prove true then as soon as Catalyst 8.10 is released
later this month I'll build and it will be ready.)
Stewart
4:52 a.m.
On 15.10.2008 04:18, Stewart Adam wrote:
Thorsten Leemhuis wrote:
> - are the nvidia bits sane? There were some mails about the 177series,
> but seems some questions were not answered yet
As far as I know (correct me if I'm wrong Nicolas), we're dropping 177 for
Livna F-8/9 and focus on the move to RPM Fusion and provide it there
instead. Nicolas is still testing the final bits of the parallel-installable
drivers, from there I'm going to write a quick initscript and redo bits of
livna-config-display and then everything should be ready.
Well, I posted some comments to the plan that was posted last week on
this list and mentioned that I see some serious trouble ahead in regards
to kmods:
http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2008-October/00...
Nobody answered that mail afaics, that's why I added this point to the
list. I just want to prevent you two spend a lot of time in a scheme
that has some well known problems that we imho should avoid.
CU
knurd
9:06 a.m.
2008/10/15 Thorsten Leemhuis <fedora(a)leemhuis.info>:
On 15.10.2008 04:18, Stewart Adam wrote:
>
> Thorsten Leemhuis wrote:
>>
>> - are the nvidia bits sane? There were some mails about the 177series,
>> but seems some questions were not answered yet
>
> As far as I know (correct me if I'm wrong Nicolas), we're dropping 177 for
> Livna F-8/9 and focus on the move to RPM Fusion and provide it there
> instead. Nicolas is still testing the final bits of the parallel-installable
> drivers, from there I'm going to write a quick initscript and redo bits of
> livna-config-display and then everything should be ready.
Well, I posted some comments to the plan that was posted last week on this
list and mentioned that I see some serious trouble ahead in regards to
kmods:
http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2008-October/00...
Nobody answered that mail afaics, that's why I added this point to the list.
I just want to prevent you two spend a lot of time in a scheme that has some
well known problems that we imho should avoid.
The reason why I have previously
requested one week of delay was about
some light changes in the common part for the parallele scheme.
That been said, the parallele mode isn't planned to be activated out
of the box right now. so the xorg-x11-drv-nvidia* could be reused
without problem. (And then, the parallele mode will be activated using
a --with serie conditionnal for experimental use).
The only serious problem is see is upgrade path and replacement scheme
(from the kmod side).
The result would mean that we need to update nvidia-kmod to 177
thought the livna/rpmfusion transition for F-8/F-9.
I will answear this mail later...
Nicolas (kwizart)
CU
knurd
6:11 a.m.
On Tue, Oct 14, 2008 at 08:30:25PM +0200, Thorsten Leemhuis wrote:
> just thought I write down a rough list of things that I plan to
do for
> RPM Fusion over the next couple of weeks. I'm sending it here in the
> hope that some people help me with some of those task; then we
> hopefully get RPM Fusion running quite soon.
Here is a updated version; most important things at the top of the list;
not all of the points necessarily have to be done, but ideally they all
get done; if I missed anything just tell me ;-)
- get the mirror manager that adrianr put in place (see
http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2008-October/00...
listed as mirrors.rpmfusion.org in DNS;
Needs
* adrianr: IP address
Right now the mirrorlist code runs on 129.143.116.10
* thias: DNS update
We should be able to change the DNS entry of mirrors.rpmfusion.org very
fast in case the mirrorlist server is not available. The mirrorlist code
depends on two dynamically generated files which can be easiy also copied
to another host. In case my machine goes down we could change the DNS
entry and it could then point to the backup mirrorlist machine.
Adrian
9:42 a.m.
Thorsten Leemhuis wrote:
Hi!
> just thought I write down a rough list of things that I plan to do for
> RPM Fusion over the next couple of weeks. I'm sending it here in the
> hope that some people help me with some of those task; then we
> hopefully get RPM Fusion running quite soon.
Here is a updated version; most important things at the top of the list;
not all of the points necessarily have to be done, but ideally they all
get done; if I missed anything just tell me ;-)
As Fedora 10 is creeping closer and closer I would really like to see us go
live sooner rather then later, so I would like to suggest to sort this list in
SHOULD and MUST fix before going live items
- get the mirror manager that adrianr put in place (see
http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2008-October/00...
listed as mirrors.rpmfusion.org in DNS;
Needs
* adrianr: IP address
* thias: DNS update
Afterwards update rpmfusion-release packages accordingly.
As we have old style mirrorlists in place on download1.rpmfusion.org right now,
and as this needs Thias, who seems to have dropped of the radar, I think this
is a SHOULD
- get the remaining packages from dribble and livna into the repo and
eveything fixed up; latest status can be found here:
http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2008-October/00...
I've send a reply to test outlining which things are must fix and which things
are should fix (IMHO). As always with any package build failures, if anyone
needs any help just ask and I'll gladly help.
- start importing and building the packages from freshrpms; I can do
that, but I want to get the ACK from thias first; especially as
http://rpmfusion.org/InitialPackageMerge likely is not fully up to date
Having a list of packages that are ready for importing would help things
a lot
First of all for moving livna (and dribble) user over, which is our first big
step I think, this is a SHOULD FIX.
I think it would be good to have freshrpms packages not in livna/dribble in
rpmfusion no matter what, so I think it would be good to start working on this
as time permits without waiting for input from Thias. If you encounter any non
trivial buildfailures let me know and I'll gladly help.
- someone should run dep checks (e.g. for F8, F9 rawhide; once with
only
free and once with both free and nonfree enabled); I suspect that some
problems will be found that way
This has just been done I believe, MUST FIX
- check that the upgrade path from Livna -> RPM Fusion is sane for
each
package in each of the supported Fedora releases (I did a rough check on
F9; looks good, but there are some packages still missing; maybe we can
ignore those for now, as some of them are broken in livna, so it's not
much of a difference)
AFAIK we have (used to have?) some automated scripts for this in Fedora, maybe
we can use those ?
- get the dep checker script from Fedora Extras/EPEL in place and let
it
automatically run after each successful push; if possible without to
much work get upgradecheck running as well (Xavier is working on it afaik)
SHOULD FIX
- make sure all the kernel-modules from freshrpms are converted to
kmods; also make sure all the update path for frehsrpms dkms users to
akmods work
SHOULD FIX
- prepare a announcement mail
MUST "FIX"
- put rpmfusion-release packages into livna-testing repos for F-8 and
F-9 to move all the testing users over
MUST "FIX"
- move packages from testing -> stable for F-8 and F-9; build new
rpmfusion-release packages that have the testing repo disabled!
MUST "FIX"
- put rpmfusion-release packages into livna repos for F-8 and F-9 to
move all the users over
MUST "FIX"
- announce
MUST "FIX"
- vacation
Whats that ?
Regards,
Hans
9:56 a.m.
2008/10/15 Hans de Goede <j.w.r.degoede(a)hhs.nl>:
Thorsten Leemhuis wrote:
> - move packages from testing -> stable for F-8 and F-9; build
new
> rpmfusion-release packages that have the testing repo disabled!
>
MUST "FIX"
I would say must fix without delay as it leads to strange
behaviour
when using mockcfg i'm testing
What i plan is to have the testing repositories present but commented
in the rpmfusion_{non}free.cfg ones.
I don't plan to have them in a separate cfg file as it will lead to
have another root for each.
Any advices ?
5:30 p.m.
On 15.10.2008 11:42, Hans de Goede wrote:
Thorsten Leemhuis wrote:
>> just thought I write down a rough list of things that I plan to do for
>> RPM Fusion over the next couple of weeks. I'm sending it here in the
>> hope that some people help me with some of those task; then we
>> hopefully get RPM Fusion running quite soon.
> Here is a updated version; most important things at the top of the list;
> not all of the points necessarily have to be done, but ideally they all
> get done; if I missed anything just tell me ;-)
As Fedora 10 is creeping closer and closer I would really like to see us go
live sooner rather then later, so I would like to suggest to sort this list in
SHOULD and MUST fix before going live items
+1
> - get the mirror manager that adrianr put in place (see
> http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2008-October/00...
>
> listed as mirrors.rpmfusion.org in DNS;
>
> Needs
> * adrianr: IP address
> * thias: DNS update
>
> Afterwards update rpmfusion-release packages accordingly.
As we have old style mirrorlists in place on download1.rpmfusion.org right now,
and as this needs Thias, who seems to have dropped of the radar, I think this
is a SHOULD
A strong "SHOULD" IMHO. Would be really nice to get this in place. And
it would be really good to have at least two different people that are
able to update the DNS. But I suppose that's not that easy to realize?
[...]
> - start importing and building the packages from freshrpms; I can do
> that, but I want to get the ACK from thias first; especially as
> http://rpmfusion.org/InitialPackageMerge likely is not fully up to date
> Having a list of packages that are ready for importing would help things
> a lot
First of all for moving livna (and dribble) user over, which is our first big
step I think, this is a SHOULD FIX.
I think it would be good to have freshrpms packages not in livna/dribble in
rpmfusion no matter what, so I think it would be good to start working on this
as time permits without waiting for input from Thias. If you encounter any non
trivial buildfailures let me know and I'll gladly help.
I'll try to take a closer look; but I feel not that well with this plan
-- even during imports from livna there were a few odd things. Most of
them I could deal with on my own because I knew livna quite well, which
is not the case for freshrpms...
> - someone should run dep checks (e.g. for F8, F9 rawhide; once
with only
> free and once with both free and nonfree enabled); I suspect that some
> problems will be found that way
This has just been done I believe,
Yeah, thx again for your help Michael!
MUST FIX
Most of them are not that important or rare corner-cases; I think I
commented on all the relevant ones and CCed the maintainers in those mails.
> - check that the upgrade path from Livna -> RPM Fusion is sane
for each
> package in each of the supported Fedora releases (I did a rough check on
> F9; looks good, but there are some packages still missing; maybe we can
> ignore those for now, as some of them are broken in livna, so it's not
> much of a difference)
AFAIK we have (used to have?) some automated scripts for this in Fedora, maybe
we can use those ?
Setting those up just for the dribble/freshrpms/livna transition to RPM
Fusion is afaics not worth the trouble
[...]
> - move packages from testing -> stable for F-8 and F-9; build new
> rpmfusion-release packages that have the testing repo disabled!
MUST "FIX"
But for now I think it's best to leave everything in testing to make it
obvious that we are still in the testing phase.
[...]
CU
knurd
9:24 p.m.
2008/10/15 Thorsten Leemhuis <fedora(a)leemhuis.info>:
...
>> - move packages from testing -> stable for F-8 and F-9;
build new
>> rpmfusion-release packages that have the testing repo disabled!
>
> MUST "FIX"
But for now I think it's best to leave everything in testing to make it
obvious that we are still in the testing phase.
That's annoying, as even if the
rpmfusion-(non)free-release have them
all magically enabled
this is not as easy for thoses who try to test packages using mock.
Right now i'm only able to test in rawhide because of that.
As rpmfusion*-release have testing enabled this remains completely
silent for the end-users and just multiplicate the chance to have
outdated repodata. (this seems to happen sometime, for example
rpmfusion-rawhide before yesterday).
Nicolas (kwizart)
> [...]
CU
knurd
6:42 a.m.
On Tue, Oct 14, 2008 at 08:30:25PM +0200, Thorsten Leemhuis wrote:
> just thought I write down a rough list of things that I plan to
do for
> RPM Fusion over the next couple of weeks. I'm sending it here in the
> hope that some people help me with some of those task; then we
> hopefully get RPM Fusion running quite soon.
Here is a updated version; most important things at the top of the list;
not all of the points necessarily have to be done, but ideally they all
get done; if I missed anything just tell me ;-)
- get the mirror manager that adrianr put in place (see
http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2008-October/00...
listed as mirrors.rpmfusion.org in DNS;
Needs
* adrianr: IP address
* thias: DNS update
This has been done.
http://mirrors.rpmfusion.org/mirrorlist?repo=free-fedora-9&arch=i386
Adrian
7:18 a.m.
On 03.11.2008 07:42, Adrian Reber wrote:
On Tue, Oct 14, 2008 at 08:30:25PM +0200, Thorsten Leemhuis wrote:
>> just thought I write down a rough list of things that I plan to do for
>> RPM Fusion over the next couple of weeks. I'm sending it here in the
>> hope that some people help me with some of those task; then we
>> hopefully get RPM Fusion running quite soon.
> Here is a updated version; most important things at the top of the list;
> not all of the points necessarily have to be done, but ideally they all
> get done; if I missed anything just tell me ;-)
>
> - get the mirror manager that adrianr put in place (see
> http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2008-October/00...
> listed as mirrors.rpmfusion.org in DNS;
>
> Needs
> * adrianr: IP address
> * thias: DNS update
This has been done.
http://mirrors.rpmfusion.org/mirrorlist?repo=free-fedora-9&arch=i386
Thias, thx for taking care of it. Some issues:
- we need something better for http://mirrors.rpmfusion.org ;-)
- the current release files and the mirrormanager use different names
for the repo files; Example:
release.rpm right now has:
[...]?repo=rpmfusion-free-debug-f$releasever[...]
mirror manager expects:
[...]?repo=free-debug-fedora$releasever[...]
We need to change one of the two (or both).
- back a few weeks ago you iirc said that we need to be able to adjust
DNS quickly in case the machine goes down; that's not solved yet
CU
knurd
7:49 a.m.
On Mon, Nov 03, 2008 at 08:18:47AM +0100, Thorsten Leemhuis wrote:
>> - get the mirror manager that adrianr put in place (see
>>
http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2008-October/00...
>> listed as mirrors.rpmfusion.org in DNS;
>>
>> Needs
>> * adrianr: IP address
>> * thias: DNS update
>
> This has been done.
>
> http://mirrors.rpmfusion.org/mirrorlist?repo=free-fedora-9&arch=i386
Thias, thx for taking care of it. Some issues:
- we need something better for http://mirrors.rpmfusion.org ;-)
This should be fixed.
- the current release files and the mirrormanager use different names
for the repo files; Example:
release.rpm right now has:
[...]?repo=rpmfusion-free-debug-f$releasever[...]
mirror manager expects:
[...]?repo=free-debug-fedora$releasever[...]
We need to change one of the two (or both).
Mirrormanager uses:
https://hosted.fedoraproject.org/mirrormanager/browser/server/mirrormanag...
It can be changed, but I would prefer if I do not have to change it ;-)
- back a few weeks ago you iirc said that we need to be able to
adjust
DNS quickly in case the machine goes down; that's not solved yet
No, it is not. We need a another machine running the mirrorlist which
would then get the necessary data from the main mirrormanager instance.
And in a case of a failure we need someone who can changes the DNS entry
very fast.
Adrian
8:06 a.m.
Adrian Reber wrote:
On Mon, Nov 03, 2008 at 08:18:47AM +0100, Thorsten Leemhuis wrote:
>>> - get the mirror manager that adrianr put in place (see
>>>
http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2008-October/00...
>>> listed as mirrors.rpmfusion.org in DNS;
>>>
>>> Needs
>>> * adrianr: IP address
>>> * thias: DNS update
>> This has been done.
>>
>> http://mirrors.rpmfusion.org/mirrorlist?repo=free-fedora-9&arch=i386
> Thias, thx for taking care of it. Some issues:
>
> - we need something better for http://mirrors.rpmfusion.org ;-)
This should be fixed.
> - the current release files and the mirrormanager use different names
> for the repo files; Example:
> release.rpm right now has:
> [...]?repo=rpmfusion-free-debug-f$releasever[...]
> mirror manager expects:
> [...]?repo=free-debug-fedora$releasever[...]
> We need to change one of the two (or both).
Mirrormanager uses:
https://hosted.fedoraproject.org/mirrormanager/browser/server/mirrormanag...
It can be changed, but I would prefer if I do not have to change it ;-)
> - back a few weeks ago you iirc said that we need to be able to adjust
> DNS quickly in case the machine goes down; that's not solved yet
No, it is not. We need a another machine running the mirrorlist which
would then get the necessary data from the main mirrormanager instance.
And in a case of a failure we need someone who can changes the DNS entry
very fast.
Why not having a second mirrormanager running on another machine and
have in DNS 2 A records?
-of
PS: I should be able to provide you with some space/storage/whatever if
you need...
11:05 a.m.
On Mon, Nov 03, 2008 at 09:06:20AM +0100, Oliver Falk wrote:
>> - back a few weeks ago you iirc said that we need to be able
to
>> adjust DNS quickly in case the machine goes down; that's not solved
>> yet
>
> No, it is not. We need a another machine running the mirrorlist which
> would then get the necessary data from the main mirrormanager instance.
> And in a case of a failure we need someone who can changes the DNS entry
> very fast.
Why not having a second mirrormanager running on another machine and
have in DNS 2 A records?
I just tested it and it works. I had two entries in DNS; one pointing to
a not existing host and another to an existing. Depending on the answer
from the DNS yum first connects to the existing host and everything just
works. If it connects to the non existing host it times out and then
goes to the existing host. I am surprised that it works.
If we do that, some users might get a short timeout using yum, but it
seems like it should work.
The important thing is then to keep the data the same on both hosts,
which should be possible if the cronjobs updating the mirrorlist are
updated at roughly the same time.
So if everybody is okay with it I would then say let's run the second
mirrorlist instance at Oliver's server...
Adrian
11:07 a.m.
On Mon, Nov 03, 2008 at 12:05:30PM +0100, Adrian Reber wrote:
> Why not having a second mirrormanager running on another machine
and
> have in DNS 2 A records?
I just tested it and it works. I had two entries in DNS; one pointing to
a not existing host and another to an existing. Depending on the answer
from the DNS yum first connects to the existing host and everything just
works. If it connects to the non existing host it times out and then
goes to the existing host. I am surprised that it works.
If we do that, some users might get a short timeout using yum, but it
seems like it should work.
In the case one of the machines goes down.
Adrian
12:56 p.m.
Adrian Reber wrote:
On Mon, Nov 03, 2008 at 12:05:30PM +0100, Adrian Reber wrote:
>> Why not having a second mirrormanager running on another machine and
>> have in DNS 2 A records?
> I just tested it and it works. I had two entries in DNS; one pointing to
> a not existing host and another to an existing. Depending on the answer
> from the DNS yum first connects to the existing host and everything just
> works. If it connects to the non existing host it times out and then
> goes to the existing host. I am surprised that it works.
>
> If we do that, some users might get a short timeout using yum, but it
> seems like it should work.
In the case one of the machines goes down.
Or the Webserver dies...
What if the Service throws a 404 or similar?
-of
11:34 a.m.
On 03.11.2008 12:05, Adrian Reber wrote:
On Mon, Nov 03, 2008 at 09:06:20AM +0100, Oliver Falk wrote:
>>> - back a few weeks ago you iirc said that we need to be able to
>>> adjust DNS quickly in case the machine goes down; that's not solved
>>> yet
>> No, it is not. We need a another machine running the mirrorlist which
>> would then get the necessary data from the main mirrormanager instance.
>> And in a case of a failure we need someone who can changes the DNS entry
>> very fast.
> Why not having a second mirrormanager running on another machine and
> have in DNS 2 A records?
I just tested it and it works. I had two entries in DNS; one pointing to
a not existing host and another to an existing. Depending on the answer
from the DNS yum first connects to the existing host and everything just
works. If it connects to the non existing host it times out and then
goes to the existing host. I am surprised that it works.
If we do that, some users might get a short timeout using yum, but it
seems like it should work.
The important thing is then to keep the data the same on both hosts,
which should be possible if the cronjobs updating the mirrorlist are
updated at roughly the same time.
So if everybody is okay with it I would then say let's run the second
mirrorlist instance at Oliver's server...
Sounds good. I'll in the meantime prepare update release rpms and will
push them to rpmfusion-testing later.
Cu
knurd
1:41 p.m.
On 03.11.2008 12:34, Thorsten Leemhuis wrote:
I'll in the meantime prepare update release rpms and will
push them to rpmfusion-testing later.
Done. It was quite a bit of work and it's easy to get something wrong in
that area. hence I'd be glad if someone could review the changes before
I push the updated packages to the testing repos:
F-8
http://buildsys.rpmfusion.org/plague-results/fedora-8-rpmfusion_free/rpmf...
http://buildsys.rpmfusion.org/plague-results/fedora-8-rpmfusion_nonfree/r...
F-9
http://buildsys.rpmfusion.org/plague-results/fedora-9-rpmfusion_free/rpmf...
http://buildsys.rpmfusion.org/plague-results/fedora-9-rpmfusion_nonfree/r...
Rawhide:
http://buildsys.rpmfusion.org/plague-results/fedora-development-rpmfusion...
http://buildsys.rpmfusion.org/plague-results/fedora-development-rpmfusion...
Commits with diffs can be found at:
http://lists.rpmfusion.org/pipermail/rpmfusion-commits/2008-November/thre...
tia!
CU
knurd
7:48 a.m.
On Mon, Nov 03, 2008 at 02:41:26PM +0100, Thorsten Leemhuis wrote:
On 03.11.2008 12:34, Thorsten Leemhuis wrote:
> I'll in the meantime prepare update release rpms and will
> push them to rpmfusion-testing later.
Done. It was quite a bit of work and it's easy to get something wrong in
that area. hence I'd be glad if someone could review the changes before
I push the updated packages to the testing repos:
I tried them all:
http://mirrors.rpmfusion.org/mirrorlist?repo=nonfree-fedora-rawhide-sourc...
http://mirrors.rpmfusion.org/mirrorlist?repo=nonfree-fedora-rawhide-debug...
http://mirrors.rpmfusion.org/mirrorlist?repo=nonfree-fedora-rawhide&a...
http://mirrors.rpmfusion.org/mirrorlist?repo=free-fedora-rawhide-source&a...
http://mirrors.rpmfusion.org/mirrorlist?repo=free-fedora-rawhide-debug&am...
http://mirrors.rpmfusion.org/mirrorlist?repo=free-fedora-rawhide&arch...
The debug links are not working. I did not yet look into it why.
And I tried those
http://mirrors.rpmfusion.org/mirrorlist?repo=nonfree-fedora-updates-testi...
http://mirrors.rpmfusion.org/mirrorlist?repo=nonfree-fedora-updates-testi...
http://mirrors.rpmfusion.org/mirrorlist?repo=nonfree-fedora-updates-testi...
http://mirrors.rpmfusion.org/mirrorlist?repo=nonfree-fedora-updates-relea...
http://mirrors.rpmfusion.org/mirrorlist?repo=nonfree-fedora-updates-relea...
http://mirrors.rpmfusion.org/mirrorlist?repo=nonfree-fedora-updates-relea...
http://mirrors.rpmfusion.org/mirrorlist?repo=nonfree-fedora-source-9&...
http://mirrors.rpmfusion.org/mirrorlist?repo=nonfree-fedora-9&arch=i386
http://mirrors.rpmfusion.org/mirrorlist?repo=nonfree-fedora-debug-9&a...
http://mirrors.rpmfusion.org/mirrorlist?repo=free-fedora-updates-testing-...
http://mirrors.rpmfusion.org/mirrorlist?repo=free-fedora-updates-testing-...
http://mirrors.rpmfusion.org/mirrorlist?repo=free-fedora-updates-testing-...
http://mirrors.rpmfusion.org/mirrorlist?repo=free-fedora-updates-released...
http://mirrors.rpmfusion.org/mirrorlist?repo=free-fedora-updates-released...
http://mirrors.rpmfusion.org/mirrorlist?repo=free-fedora-updates-released...
http://mirrors.rpmfusion.org/mirrorlist?repo=free-fedora-source-9&arc...
http://mirrors.rpmfusion.org/mirrorlist?repo=free-fedora-9&arch=i386
http://mirrors.rpmfusion.org/mirrorlist?repo=free-fedora-debug-9&arch...
They all work. So your changes look pretty good.
Adrian
9:18 a.m.
On 04.11.2008 08:48, Adrian Reber wrote:
On Mon, Nov 03, 2008 at 02:41:26PM +0100, Thorsten Leemhuis wrote:
> On 03.11.2008 12:34, Thorsten Leemhuis wrote:
>> I'll in the meantime prepare update release rpms and will
>> push them to rpmfusion-testing later.
> Done. It was quite a bit of work and it's easy to get something wrong in
> that area. hence I'd be glad if someone could review the changes before
> I push the updated packages to the testing repos:
I tried them all:
http://mirrors.rpmfusion.org/mirrorlist?repo=nonfree-fedora-rawhide-sourc...
http://mirrors.rpmfusion.org/mirrorlist?repo=nonfree-fedora-rawhide-debug...
http://mirrors.rpmfusion.org/mirrorlist?repo=nonfree-fedora-rawhide&a...
http://mirrors.rpmfusion.org/mirrorlist?repo=free-fedora-rawhide-source&a...
http://mirrors.rpmfusion.org/mirrorlist?repo=free-fedora-rawhide-debug&am...
http://mirrors.rpmfusion.org/mirrorlist?repo=free-fedora-rawhide&arch...
The debug links are not working. I did not yet look into it why.
Sorry, forgot to mention that. I spotted that yesterday already. But
there are no debug repos for rawhide at all in the list:
http://mirrors.rpmfusion.org/mirrorlist?repo=foobar&arch=foobar
But I think I know why: The Debug directory in
http://download1.rpmfusion.org/free/fedora/development/i386/
was missing until yesterday, as our push script puts the debuginfo files to
http://download1.rpmfusion.org/free/fedora/development/i386/os/debug
I created a symlink in the place where mirrormanager likely expect it to
be. That way the directory structure also matches the one from Fedora.
They all work. So your changes look pretty good.
I'll push the package to testing then.
CU
knurd
1:40 p.m.
On Tue, Nov 04, 2008 at 10:18:35AM +0100, Thorsten Leemhuis wrote:
On 04.11.2008 08:48, Adrian Reber wrote:
> On Mon, Nov 03, 2008 at 02:41:26PM +0100, Thorsten Leemhuis wrote:
>> On 03.11.2008 12:34, Thorsten Leemhuis wrote:
>>> I'll in the meantime prepare update release rpms and will
>>> push them to rpmfusion-testing later.
>> Done. It was quite a bit of work and it's easy to get something wrong
>> in that area. hence I'd be glad if someone could review the changes
>> before I push the updated packages to the testing repos:
> I tried them all:
>
>
http://mirrors.rpmfusion.org/mirrorlist?repo=nonfree-fedora-rawhide-sourc...
>
http://mirrors.rpmfusion.org/mirrorlist?repo=nonfree-fedora-rawhide-debug...
> http://mirrors.rpmfusion.org/mirrorlist?repo=nonfree-fedora-rawhide&a...
>
http://mirrors.rpmfusion.org/mirrorlist?repo=free-fedora-rawhide-source&a...
> http://mirrors.rpmfusion.org/mirrorlist?repo=free-fedora-rawhide-debug&am...
> http://mirrors.rpmfusion.org/mirrorlist?repo=free-fedora-rawhide&arch...
>
> The debug links are not working. I did not yet look into it why.
Sorry, forgot to mention that. I spotted that yesterday already. But
there are no debug repos for rawhide at all in the list:
http://mirrors.rpmfusion.org/mirrorlist?repo=foobar&arch=foobar
But I think I know why: The Debug directory in
http://download1.rpmfusion.org/free/fedora/development/i386/
was missing until yesterday, as our push script puts the debuginfo files to
http://download1.rpmfusion.org/free/fedora/development/i386/os/debug
I created a symlink in the place where mirrormanager likely expect it to
be. That way the directory structure also matches the one from Fedora.
Unfortunately symlinks are not good enough. Could the push
scripts be changed so that the layout matches the one from Fedora?
Or hardlinked files would also work...
Adrian
7:21 p.m.
On Tue, 4 Nov 2008 14:40:39 +0100, Adrian Reber wrote:
> But I think I know why: The Debug directory in
> http://download1.rpmfusion.org/free/fedora/development/i386/
> was missing until yesterday, as our push script puts the debuginfo files to
> http://download1.rpmfusion.org/free/fedora/development/i386/os/debug
> I created a symlink in the place where mirrormanager likely expect it to
> be. That way the directory structure also matches the one from Fedora.
Unfortunately symlinks are not good enough. Could the push
scripts be changed so that the layout matches the one from Fedora?
Or hardlinked files would also work...
I would advise against using too many manually created links. Better patch
the scripts to support the "os" subdir where necessary (or make the repo
paths more customisable).
The old default is
$treeroot/$target/$basearch
$treeroot/$target/$basearch/debug
with no "os" subdir. That matches Fedora (Updates, Test Updates, EPEL,
Extras). The "os" subdirs seems to be specific to the "releases" and
"development" trees, where the repodata path must be constructed
differently (e.g. $treeroot/$target/Everything/$basearch/os).
7:36 a.m.
On Tue, Nov 04, 2008 at 08:21:39PM +0100, Michael Schwendt wrote:
On Tue, 4 Nov 2008 14:40:39 +0100, Adrian Reber wrote:
> > But I think I know why: The Debug directory in
> > http://download1.rpmfusion.org/free/fedora/development/i386/
> > was missing until yesterday, as our push script puts the debuginfo files to
> > http://download1.rpmfusion.org/free/fedora/development/i386/os/debug
> > I created a symlink in the place where mirrormanager likely expect it to
> > be. That way the directory structure also matches the one from Fedora.
>
> Unfortunately symlinks are not good enough. Could the push
> scripts be changed so that the layout matches the one from Fedora?
> Or hardlinked files would also work...
I would advise against using too many manually created links. Better patch
the scripts to support the "os" subdir where necessary (or make the repo
paths more customisable).
There is a special function in mirrormanager called
trim_os_from_dirname(), which removes anything including "/os" from the
path string before starting to guess to which repository this path might
belong. I would really prefer if I do not have to provide an extra code
path just for the rpmfusion development release. From what I see on my
Fedora mirror the debug directory is never under the os directory and
for rpmfusion this is only the case for the development directory.
Is it possible to change the push script to create the debug directory
next to the os directory and not below it? Is there a reason why it
creates the debug directory at another place for the development
repository?
The old default is
$treeroot/$target/$basearch
$treeroot/$target/$basearch/debug
with no "os" subdir. That matches Fedora (Updates, Test Updates, EPEL,
Extras). The "os" subdirs seems to be specific to the "releases" and
"development" trees, where the repodata path must be constructed
differently (e.g. $treeroot/$target/Everything/$basearch/os).
Adrian
12:57 p.m.
On Wed, 5 Nov 2008 08:36:08 +0100, Adrian Reber wrote:
> I would advise against using too many manually created links.
Better patch
> the scripts to support the "os" subdir where necessary (or make the repo
> paths more customisable).
There is a special function in mirrormanager called
trim_os_from_dirname(), which removes anything including "/os" from the
path string before starting to guess to which repository this path might
belong. I would really prefer if I do not have to provide an extra code
path just for the rpmfusion development release. From what I see on my
Fedora mirror the debug directory is never under the os directory and
for rpmfusion this is only the case for the development directory.
Is it possible to change the push script to create the debug directory
next to the os directory and not below it? Is there a reason why it
creates the debug directory at another place for the development
repository?
The answer to that was in my previous reply. Quoted here:
> The old default is
>
> $treeroot/$target/$basearch
> $treeroot/$target/$basearch/debug
>
> with no "os" subdir. That matches Fedora (Updates, Test Updates, EPEL,
> Extras). The "os" subdirs seems to be specific to the "releases"
and
> "development" trees, where the repodata path must be constructed
> differently (e.g. $treeroot/$target/Everything/$basearch/os).
In other words, the development repository (and the "release" trees) paths
are created with a different scheme. Simply defining a "development" dist
in the pushscript config file doesn't achieve that.
In pushscript cvs, the "development" dist (and only the development dist!)
is handled differently now and creates paths like
$treeroot/development/$basearch/os/
$treeroot/development/$basearch/debug/
$treeroot/development/source/SRPMS/
which also matches the Everything release tree AFAICS (except for
the "Packages" directory). I've updated several files in order to not
break the multilib resolver, repoview generator and other scripts.
Customisation beyond that would require config file changes (and the
config file is big enough already due to details about external core
repos and the old ability to use these for repoclosure etc.)
5:59 p.m.
On 06.11.2008 13:57, Michael Schwendt wrote:
On Wed, 5 Nov 2008 08:36:08 +0100, Adrian Reber wrote:
In other words, the development repository (and the "release" trees) paths
are created with a different scheme. Simply defining a "development" dist
in the pushscript config file doesn't achieve that.
In pushscript cvs, the "development" dist (and only the development dist!)
is handled differently now and creates paths like
$treeroot/development/$basearch/os/
$treeroot/development/$basearch/debug/
$treeroot/development/source/SRPMS/
which also matches the Everything release tree AFAICS (except for
the "Packages" directory). [...]
Many many for those changes (and thx for one more change that we
discussed in private). I updated our push scripts and did a few tests --
seems everything works well.
The debug/ directories for rawhide are now at the right place; hopefully
MirrorManager doesn#t get confused again by that change...
The push scripts now afaics do all we need; so thx again Michael, they
make a whole lot of things a lot easier to handle.
CU
knurd
8:48 p.m.
On Fri, Nov 07, 2008 at 06:59:24PM +0100, Thorsten Leemhuis wrote:
On 06.11.2008 13:57, Michael Schwendt wrote:
> On Wed, 5 Nov 2008 08:36:08 +0100, Adrian Reber wrote:
>
> In other words, the development repository (and the "release" trees) paths
> are created with a different scheme. Simply defining a "development" dist
> in the pushscript config file doesn't achieve that.
>
> In pushscript cvs, the "development" dist (and only the development dist!)
> is handled differently now and creates paths like
>
> $treeroot/development/$basearch/os/
> $treeroot/development/$basearch/debug/
> $treeroot/development/source/SRPMS/
>
> which also matches the Everything release tree AFAICS (except for
> the "Packages" directory). [...]
Many many for those changes (and thx for one more change that we
discussed in private). I updated our push scripts and did a few tests --
seems everything works well.
The debug/ directories for rawhide are now at the right place; hopefully
MirrorManager doesn#t get confused again by that change...
I have removed my hack in MM and it seems like the development
repository mirrorlist now contains the correct information for the debug
and the non-debug repositories.
Adrian
12:17 p.m.
New subject: mirrorlist returning no results
Adrian Reber wrote:
I have removed my hack in MM and it seems like the development
repository mirrorlist now contains the correct information for the debug
and the non-debug repositories.
It appears that both free-rawhide and f9
mirrorlists are having trouble:
http://mirrors.rpmfusion.org/mirrorlist?repo=free-fedora-rawhide&arch...
# repo = free-fedora-rawhide arch = i386 error: invalid repo or arch
# following repositories are available:
[at least from my PC]
Adrian: I know you got the mirrorlist response to list the valid repo=
values, and that is what I expected if I actually got the repo incorrect .
DaveT.
3:43 p.m.
New subject: mirrorlist returning no results
On Sat, Nov 08, 2008 at 11:17:54PM +1100, David Timms wrote:
Adrian Reber wrote:
> I have removed my hack in MM and it seems like the development
> repository mirrorlist now contains the correct information for the debug
> and the non-debug repositories.
It appears that both free-rawhide and f9 mirrorlists are having trouble:
http://mirrors.rpmfusion.org/mirrorlist?repo=free-fedora-rawhide&arch...
# repo = free-fedora-rawhide arch = i386 error: invalid repo or arch
# following repositories are available:
[at least from my PC]
Adrian: I know you got the mirrorlist response to list the valid repo=
values, and that is what I expected if I actually got the repo incorrect
Something eats our repository information and everything seems to
disappear....
I am now disabling all the cronjobs and I am running with only two
mirrors for now. I need to find out what is causing the data loss.
Adrian
1:09 p.m.
On 04.11.2008 20:21, Michael Schwendt wrote:
On Tue, 4 Nov 2008 14:40:39 +0100, Adrian Reber wrote:
>> But I think I know why: The Debug directory in
>> http://download1.rpmfusion.org/free/fedora/development/i386/
>> was missing until yesterday, as our push script puts the debuginfo files to
>> http://download1.rpmfusion.org/free/fedora/development/i386/os/debug
>> I created a symlink in the place where mirrormanager likely expect it to
>> be. That way the directory structure also matches the one from Fedora.
> Unfortunately symlinks are not good enough. Could the push
> scripts be changed so that the layout matches the one from Fedora?
See below.
> Or hardlinked files would also work...
I would advise against using too many manually created links.
And you are very right with that. Nevertheless I did them and they
mostly did the trick up to now:
Better patch the scripts to support the "os" subdir where
necessary
(or make the repo paths more customisable).
Fully agreed, but my python skills are not good enough to do that (I
really wanted/want to improve my programming skills, but all the other
Fedora work keeps me/kept me completely busy over the past few years
:-/). I just work with the scripts and set them up as somebody just had
to do it to get things running :-/
That, btw, was one of the reasons why I send a mail to this list many
months ago where I said: I don't want to do infrastructure work -- I
just do it as it seems somebody has to do it to get things running. But
nobody stepped up to help, hence I continued to do the best I can.
So how to move forward? I'd suggest this: If you are a trusted
packager/contributor and if you have python skills to work on this let
me know and I'll try to get access to the machine in question organized.
The "trusted" part is a bit important here, as that's the machine where
plague runs/where the master repo is hosted ;-)
Michael, you of course would be the best for that job. But I got the
impression that you don't want to get involved to deep into RPM Fusion,
hence I never wanted to ask you to take care of things like this.
Note: I'm not sure how much work we want to spend on the push scripts at
all, as we hopefully sooner or later switch to koji and bodhi.
Cu
knurd
12:55 p.m.
Adrian Reber wrote:
On Mon, Nov 03, 2008 at 09:06:20AM +0100, Oliver Falk wrote:
>>> - back a few weeks ago you iirc said that we need to be able to
>>> adjust DNS quickly in case the machine goes down; that's not solved
>>> yet
>> No, it is not. We need a another machine running the mirrorlist which
>> would then get the necessary data from the main mirrormanager instance.
>> And in a case of a failure we need someone who can changes the DNS entry
>> very fast.
> Why not having a second mirrormanager running on another machine and
> have in DNS 2 A records?
I just tested it and it works. I had two entries in DNS; one pointing to
a not existing host and another to an existing. Depending on the answer
from the DNS yum first connects to the existing host and everything just
works. If it connects to the non existing host it times out and then
goes to the existing host. I am surprised that it works.
Great. Trying is better than guessing, right? :-)
If we do that, some users might get a short timeout using yum, but
it
seems like it should work.
That's fine.
The important thing is then to keep the data the same on both hosts,
which should be possible if the cronjobs updating the mirrorlist are
updated at roughly the same time.
Or the main server just triggers the job on the other server... A simple
xinetd-based service would do I think...
So if everybody is okay with it I would then say let's run the
second
mirrorlist instance at Oliver's server...
That's fine for me, just let me know what you need.
-of
7:35 a.m.
On Mon, Nov 03, 2008 at 01:55:33PM +0100, Oliver Falk wrote:
> The important thing is then to keep the data the same on both
hosts,
> which should be possible if the cronjobs updating the mirrorlist are
> updated at roughly the same time.
Or the main server just triggers the job on the other server... A simple
xinetd-based service would do I think...
> So if everybody is okay with it I would then say let's run the second
> mirrorlist instance at Oliver's server...
That's fine for me, just let me know what you need.
Just that everybody knows: Oliver and I are working on getting the
second mirrorlist setup running. After that is done I will look at
getting the correct information about our mirrormanager setup in the
rpmfusion wiki.
Adrian
10:43 a.m.
Adrian Reber wrote :
On Mon, Nov 03, 2008 at 01:55:33PM +0100, Oliver Falk wrote:
>> The important thing is then to keep the data the same on both hosts,
>> which should be possible if the cronjobs updating the mirrorlist are
>> updated at roughly the same time.
>
> Or the main server just triggers the job on the other server... A simple
> xinetd-based service would do I think...
>
>> So if everybody is okay with it I would then say let's run the second
>> mirrorlist instance at Oliver's server...
>
> That's fine for me, just let me know what you need.
Just that everybody knows: Oliver and I are working on getting the
second mirrorlist setup running. After that is done I will look at
getting the correct information about our mirrormanager setup in the
rpmfusion wiki.
Let me know the 2nd IP address to point "mirrors" to when it's ready!
Note also that it would be a good thing to have the way they work
outlined somewhere in the wiki.
Matthias
--
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora release 9 (Sulphur) - Linux kernel 2.6.26.5-45.fc9.x86_64
Load : 0.78 0.85 2.03
1:03 p.m.
Matthias Saou wrote:
Adrian Reber wrote :
> On Mon, Nov 03, 2008 at 01:55:33PM +0100, Oliver Falk wrote:
>>> The important thing is then to keep the data the same on both hosts,
>>> which should be possible if the cronjobs updating the mirrorlist are
>>> updated at roughly the same time.
>> Or the main server just triggers the job on the other server... A simple
>> xinetd-based service would do I think...
>>
>>> So if everybody is okay with it I would then say let's run the second
>>> mirrorlist instance at Oliver's server...
>> That's fine for me, just let me know what you need.
> Just that everybody knows: Oliver and I are working on getting the
> second mirrorlist setup running. After that is done I will look at
> getting the correct information about our mirrormanager setup in the
> rpmfusion wiki.
Let me know the 2nd IP address to point "mirrors" to when it's ready!
Note also that it would be a good thing to have the way they work
outlined somewhere in the wiki.
http://zipfer.linux-kernel.at/mirrorlist?arch=i386&repo=free-fedora-9
This looks good, doesn't it?
-of
4:33 p.m.
On Tue, Nov 04, 2008 at 02:03:08PM +0100, Oliver Falk wrote:
Matthias Saou wrote:
> Adrian Reber wrote :
>> Just that everybody knows: Oliver and I are working on getting the
>> second mirrorlist setup running. After that is done I will look at
>> getting the correct information about our mirrormanager setup in the
>> rpmfusion wiki.
>
> Let me know the 2nd IP address to point "mirrors" to when it's ready!
>
> Note also that it would be a good thing to have the way they work
> outlined somewhere in the wiki.
http://zipfer.linux-kernel.at/mirrorlist?arch=i386&repo=free-fedora-9
This looks good, doesn't it?
We are ready. The data is synced hourly to the second mirrorlist server
which Oliver is providing.
Matthias, you can now add 213.129.242.84 as the 2nd IP address pointing
to "mirrors".
I will update the wiki in the next few days.
Adrian
9:24 a.m.
Adrian Reber wrote :
>
http://zipfer.linux-kernel.at/mirrorlist?arch=i386&repo=free-fedora-9
>
> This looks good, doesn't it?
We are ready. The data is synced hourly to the second mirrorlist server
which Oliver is providing.
Matthias, you can now add 213.129.242.84 as the 2nd IP address pointing
to "mirrors".
I will update the wiki in the next few days.
Done. It's managed directly at Gandi, so it might take a little while
before the change is noticeable even though the TTL of the entry is set
to 10 minutes.
Matthias
--
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora release 9 (Sulphur) - Linux kernel 2.6.26.5-45.fc9.x86_64
Load : 0.66 0.61 0.39
8:14 a.m.
On 03.11.2008 08:49, Adrian Reber wrote:
> - we need something better for http://mirrors.rpmfusion.org ;-)
This should be fixed.
thx
> - the current release files and the mirrormanager use different
names
> for the repo files; Example:
> release.rpm right now has:
> [...]?repo=rpmfusion-free-debug-f$releasever[...]
> mirror manager expects:
> [...]?repo=free-debug-fedora$releasever[...]
> We need to change one of the two (or both).
Mirrormanager uses:
https://hosted.fedoraproject.org/mirrormanager/browser/server/mirrormanag...
It can be changed, but I would prefer if I do not have to change it ;-)
Okay, then I'd say changing the release packages is the easier way for
everyone.
> - back a few weeks ago you iirc said that we need to be able to
adjust
> DNS quickly in case the machine goes down; that's not solved yet
No, it is not. We need a another machine running the mirrorlist which
would then get the necessary data from the main mirrormanager instance.
And in a case of a failure we need someone who can changes the DNS entry
very fast.
Do we want to ignore this for now and nevertheless switch to use
mirrormanager? (If we ignore this now I fear that this will never get
fixed...)
CU
knurd
8:19 a.m.
On Mon, Nov 03, 2008 at 09:14:19AM +0100, Thorsten Leemhuis wrote:
>> - the current release files and the mirrormanager use
different names
>> for the repo files; Example:
>> release.rpm right now has:
>> [...]?repo=rpmfusion-free-debug-f$releasever[...]
>> mirror manager expects:
>> [...]?repo=free-debug-fedora$releasever[...]
>> We need to change one of the two (or both).
>
> Mirrormanager uses:
>
https://hosted.fedoraproject.org/mirrormanager/browser/server/mirrormanag...
> It can be changed, but I would prefer if I do not have to change it ;-)
Okay, then I'd say changing the release packages is the easier way for
everyone.
thx
>> - back a few weeks ago you iirc said that we need to be able
to
>> adjust DNS quickly in case the machine goes down; that's not solved
>> yet
> No, it is not. We need a another machine running the mirrorlist which
> would then get the necessary data from the main mirrormanager instance.
> And in a case of a failure we need someone who can changes the DNS entry
> very fast.
Do we want to ignore this for now and nevertheless switch to use
mirrormanager? (If we ignore this now I fear that this will never get
fixed...)
I would say: let's set up a backup mirrorlist server and hope that in an
emergency we will manage to switch the DNS fast enough.
All I need is an account on the "backup mirrorlist server" and someone
who can do some changes to the webserver configuration to get it
running.
The mirrorlist is in python and needs mod_wsgi. It needs to be able to
run a cronjob and that should be enough (more or less).
Adrian
8:49 a.m.
Adrian Reber wrote:
On Mon, Nov 03, 2008 at 09:14:19AM +0100, Thorsten Leemhuis wrote:
>>> - the current release files and the mirrormanager use different names
>>> for the repo files; Example:
>>> release.rpm right now has:
>>> [...]?repo=rpmfusion-free-debug-f$releasever[...]
>>> mirror manager expects:
>>> [...]?repo=free-debug-fedora$releasever[...]
>>> We need to change one of the two (or both).
>> Mirrormanager uses:
>>
https://hosted.fedoraproject.org/mirrormanager/browser/server/mirrormanag...
>> It can be changed, but I would prefer if I do not have to change it ;-)
> Okay, then I'd say changing the release packages is the easier way for
> everyone.
thx
>>> - back a few weeks ago you iirc said that we need to be able to
>>> adjust DNS quickly in case the machine goes down; that's not solved
>>> yet
>> No, it is not. We need a another machine running the mirrorlist which
>> would then get the necessary data from the main mirrormanager instance.
>> And in a case of a failure we need someone who can changes the DNS entry
>> very fast.
> Do we want to ignore this for now and nevertheless switch to use
> mirrormanager? (If we ignore this now I fear that this will never get
> fixed...)
I would say: let's set up a backup mirrorlist server and hope that in an
emergency we will manage to switch the DNS fast enough.
All I need is an account on the "backup mirrorlist server" and someone
who can do some changes to the webserver configuration to get it
running.
Couldn't we list multiple IP addresses under mirrors.rpmfusion.org? Or isn't
yum smart enough to try the second address if the first one fails ?
Regards,
Hans
9:15 a.m.
Hans de Goede wrote:
[ ... ]
Couldn't we list multiple IP addresses under
mirrors.rpmfusion.org? Or
isn't yum smart enough to try the second address if the first one fails ?
Exactly what I meant. And I believe the python http stuff is able to do
that, but I'm not sure if yum is able to handle it correctly...
-of
10:04 a.m.
On Mon, Nov 3, 2008 at 9:49 AM, Hans de Goede <j.w.r.degoede(a)hhs.nl> wrote:
Or isn't
yum smart enough to try the second address if the first one fails ?
it is.
Otherwise seth is the right person who can have more thought on that.
--
Xavier.t Lamien
--
http://fedoraproject.org/wiki/XavierLamien
GPG-Key ID: F3903DEB
Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB
12:28 p.m.
On Monday, 03 November 2008 at 08:18, Thorsten Leemhuis wrote:
On 03.11.2008 07:42, Adrian Reber wrote:
>On Tue, Oct 14, 2008 at 08:30:25PM +0200, Thorsten Leemhuis wrote:
>>>just thought I write down a rough list of things that I plan to do for
>>>RPM Fusion over the next couple of weeks. I'm sending it here in the
>>>hope that some people help me with some of those task; then we
>>>hopefully get RPM Fusion running quite soon.
>>Here is a updated version; most important things at the top of the list;
>>not all of the points necessarily have to be done, but ideally they all
>>get done; if I missed anything just tell me ;-)
>>
>>- get the mirror manager that adrianr put in place (see
>>http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2008-October/001393.html
>>listed as mirrors.rpmfusion.org in DNS;
>>
>>Needs
>> * adrianr: IP address
>> * thias: DNS update
>
>This has been done.
>
>http://mirrors.rpmfusion.org/mirrorlist?repo=free-fedora-9&arch=i386
Thias, thx for taking care of it. Some issues:
Another issue. The mirrorlist contains
http://sunsite.icm.edu.pl/pub/Linux/distributions/rpmfusion/
which doesn't work (403 error), when it should contain
http://ftp.icm.edu.pl/pub/Linux/distributions/rpmfusion/
which works. Perhaps the list was made before I fixed up
the address on the wiki (which is showing the correct URL).
Regards,
R.
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
12:36 p.m.
On Mon, Nov 03, 2008 at 01:28:25PM +0100, Dominik 'Rathann' Mierzejewski wrote:
>
>http://mirrors.rpmfusion.org/mirrorlist?repo=free-fedora-9&arch=i386
>
> Thias, thx for taking care of it. Some issues:
Another issue. The mirrorlist contains
http://sunsite.icm.edu.pl/pub/Linux/distributions/rpmfusion/
This works from the machine which is running mirrormanager.
which doesn't work (403 error), when it should contain
http://ftp.icm.edu.pl/pub/Linux/distributions/rpmfusion/
which works. Perhaps the list was made before I fixed up
the address on the wiki (which is showing the correct URL).
Only working and URLs which are up to date should appear in that list,
and the sunsite link works from here. I can change it in mirrormanager
if you want...
Adrian
12:44 p.m.
On Monday 03 November 2008 04:36:57 am Adrian Reber wrote:
On Mon, Nov 03, 2008 at 01:28:25PM +0100, Dominik 'Rathann'
Mierzejewski
wrote:
> >
>http://mirrors.rpmfusion.org/mirrorlist?repo=free-fedora-9&arch=i386
> >
> > Thias, thx for taking care of it. Some issues:
>
> Another issue. The mirrorlist contains
> http://sunsite.icm.edu.pl/pub/Linux/distributions/rpmfusion/
This works from the machine which is running mirrormanager.
> which doesn't work (403 error), when it should contain
> http://ftp.icm.edu.pl/pub/Linux/distributions/rpmfusion/
> which works. Perhaps the list was made before I fixed up
> the address on the wiki (which is showing the correct URL).
Only working and URLs which are up to date should appear in that list,
and the sunsite link works from here. I can change it in mirrormanager
if you want...
Adrian
Seems to work fine here as well.
--
Conrad Meyer <konrad(a)tylerc.org>
5857
days inactive
5882
days old
rpmfusion-developers@lists.rpmfusion.org
42 comments
12 participants
participants (12)
-
Adrian Reber -
Agnes Jones -
Conrad Meyer -
Dominik 'Rathann' Mierzejewski -
Hans de Goede -
Matthias Saou -
Michael Schwendt -
Nicolas Chauvet -
Oliver Falk -
Stewart Adam -
Thorsten Leemhuis -
Xavier Lamien