[Yum] unsubscribe

Doktor Gurson (InexpensiveDomains.com) dgurson at inexpensivedomains.com
Sat Aug 13 02:49:05 UTC 2005



Regards,
Doktor Gurson
InexpensiveDomains.com
Toll Free: 877-467-8787 x1121
Direct: 925-634-9100 x1121

-----Original Message-----
From: yum-bounces at lists.dulug.duke.edu
[mailto:yum-bounces at lists.dulug.duke.edu] On Behalf Of
yum-request at lists.dulug.duke.edu
Sent: Friday, August 12, 2005 7:48 PM
To: yum at lists.dulug.duke.edu
Subject: Yum Digest, Vol 25, Issue 11

Send Yum mailing list submissions to
	yum at lists.dulug.duke.edu

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.dulug.duke.edu/mailman/listinfo/yum
or, via email, send a message with subject or body 'help' to
	yum-request at lists.dulug.duke.edu

You can reach the person managing the list at
	yum-owner at lists.dulug.duke.edu

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Yum digest..."


Today's Topics:

   1. Re: (no subject) (Ignacio Vazquez-Abrams)
   2. Re: (no subject) (Robert G. Brown)
   3. legal stuff (Rahul Sundaram)
   4. yum improvement (Ian MacGregor)
   5. Re: yum improvement (Michael Stenner)
   6. Re: yum improvement (Robert G. Brown)
   7. Re: yum improvement (Robert G. Brown)
   8. Re: yum improvement (Greg Knaddison)
   9. Yum book or good documentation (Fong Vang)


----------------------------------------------------------------------

Message: 1
Date: Fri, 12 Aug 2005 13:04:51 -0400
From: Ignacio Vazquez-Abrams <ivazquez at ivazquez.net>
Subject: Re: [Yum] (no subject)
To: "Yellowdog Updater, Modified" <yum at lists.dulug.duke.edu>
Message-ID: <1123866291.6242.6.camel at ignacio.lan>
Content-Type: text/plain; charset="us-ascii"

On Fri, 2005-08-12 at 09:14 -0400, Robert G. Brown wrote:
> One suggestion (for the FC4-based linux at duke but also for other people
> running FC4 repo mirrors plus local extensions).  At least some
> repositories, notably livna (which religiously goes on top of FC4
> base+updates+extras and is apparently maintained by a lot of the FC
> developers to provide a channel for those otherwise patent-encumbered
> packages that we often need and that are actually legal for us to use,
> but that RH cannot safely support in the distro itself) provide a lovely
> rpm that basically contains their repo entry:
> 
>   livna-release-4-0.lvn.2.4.noarch.rpm
> 
> Installing this rpm instantly enables yum to access e.g. nvidia and ATI
> drivers all RPM packaged and ready to go and updated per FC kernel,
> xmms-mp3, and other tidbits.  My suggestion is that this (and perhaps
> others like it) is an excellent candidate for e.g. add-ons/duke (or
> equivalent elsewhere).  So that one can go:
> 
>   yum install livna-release-4

The problem is that since the repos contain packages that for some legal
reason can't be in the distro directly, the distro also can't have any
direct link/connection to said repos. So then you'd need to install a
package to add the repo that has the repo packages in it.

-- 
Ignacio Vazquez-Abrams <ivazquez at ivazquez.net>
http://fedora.ivazquez.net/

gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url :
http://lists.dulug.duke.edu/pipermail/yum/attachments/20050812/67fe8f53/atta
chment-0001.bin

------------------------------

Message: 2
Date: Fri, 12 Aug 2005 13:39:29 -0400
From: "Robert G. Brown" <rgb at phy.duke.edu>
Subject: Re: [Yum] (no subject)
To: Yellowdog Updater, Modified <yum at lists.dulug.duke.edu>
Message-ID: <cone.1123868369.439445.5439.500 at lilith>
Content-Type: text/plain; charset="us-ascii"

Ignacio Vazquez-Abrams writes:

> On Fri, 2005-08-12 at 09:14 -0400, Robert G. Brown wrote:
>> One suggestion (for the FC4-based linux at duke but also for other people
>> running FC4 repo mirrors plus local extensions).  At least some
>> repositories, notably livna (which religiously goes on top of FC4
>> base+updates+extras and is apparently maintained by a lot of the FC
>> developers to provide a channel for those otherwise patent-encumbered
>> packages that we often need and that are actually legal for us to use,
>> but that RH cannot safely support in the distro itself) provide a lovely
>> rpm that basically contains their repo entry:
>> 
>>   livna-release-4-0.lvn.2.4.noarch.rpm
>> 
>> Installing this rpm instantly enables yum to access e.g. nvidia and ATI
>> drivers all RPM packaged and ready to go and updated per FC kernel,
>> xmms-mp3, and other tidbits.  My suggestion is that this (and perhaps
>> others like it) is an excellent candidate for e.g. add-ons/duke (or
>> equivalent elsewhere).  So that one can go:
>> 
>>   yum install livna-release-4
> 
> The problem is that since the repos contain packages that for some legal
> reason can't be in the distro directly, the distro also can't have any
> direct link/connection to said repos. So then you'd need to install a
> package to add the repo that has the repo packages in it.

Why?  I don't see why this is any different from adding a URL to livna's
website or using it an email message on a list like this, or for that
matter stating things like "look for livna if you want some of the
encumbered packages".

Otherwise one cannot "mention" livna, dag, any of the repos out there
that have encumbered rpms, and that seems like it might be a pretty
major violation of that free speech thing.  In fact, it would make it
really difficult to prosecute.

This proposes adding an rpm that contains what amounts to a link to a
site that possesses the rpms and actually distributes them.  If is
already one degree of indirection, and the livna repo rpm is totally
unencumbered itself.  Why is adding an rpm that contains
/etc/yum.repos.d/livna (only, not the CONTENT that livna distributes)
any different from adding an rpm that adds an rpm that contains the
livna repo data?  Or an rpm that adds an rpm that adds...

I'd argue that it is really impossible to restrict adding this rpm even
to the Fedora core repository itself, especially if one adds similar
rpms for ALL (or at least several other) such repositories.  The
decision to actually install the repo data on a system (which is still
absolutely legal) and use it (which may or may not be legal for at least
some of the repos out there -- it actually IS legal for livna in
particular, according to its website, and some things that might be
illegal in the silly old US with the best encumbrance laws that
corporate money has been able to buy are legal in Europe, where
RH/Fedora obviously has a market) is still entirely up to the user, and
those repositories also contain perfectly usable unencumbered rpms.

To put it another way, it may be illegal for me to sell ordinary
pornography out of my garage in my neighborhood (zoning restrictions
etc, non-kiddy porn per se isn't illegal to sell, purchase or possess in
NC, subject to community standard zoning issues), but it is certainly
not illegal for me to put up a website with a phone book on it that
contains (among other things) URLs and address information that can
direct people to stores where it can be purchased.  Otherwise Google and
Yahoo are in Big Trouble.  They're also in big trouble over livna, since
that's how I find things like the repo link in the first place.

    rgb

> 
> -- 
> Ignacio Vazquez-Abrams <ivazquez at ivazquez.net>
> http://fedora.ivazquez.net/
> 
> gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :
http://lists.dulug.duke.edu/pipermail/yum/attachments/20050812/6928da64/atta
chment-0001.bin

------------------------------

Message: 3
Date: Fri, 12 Aug 2005 23:14:18 +0530
From: Rahul Sundaram <sundaram at redhat.com>
Subject: [Yum] legal stuff
To: "Yellowdog Updater, Modified" <yum at lists.dulug.duke.edu>
Cc: "Yellowdog Updater"@redhat.com
Message-ID: <42FCDFF2.5000106 at redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hi

>
> Why?  I don't see why this is any different from adding a URL to livna's
> website or using it an email message on a list like this, or for that
> matter stating things like "look for livna if you want some of the
> encumbered packages".


Law works in strange ways. Red Hat can link to fedorafaq.org or any such 
sources as long as it doesnt provide the legally questionable software 
but it cannot link directly to livna.org or provide the software itself. 
Thats my understanding of it.

http://fedora.redhat.com/docs/release-notes/fc4/errata/#sn-why-no-mp3

Anyway this has nothing to do with yum development.

regards
Rahul;



------------------------------

Message: 4
Date: Fri, 12 Aug 2005 12:34:56 -0700
From: Ian MacGregor <ianmac7 at gmail.com>
Subject: [Yum] yum improvement
To: yum at lists.linux.duke.edu
Message-ID: <42FCF9E0.3090707 at gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hi,
  I love yum and could not function without it.
However, I have an idea that would improve yum.

Please consider the following:
I ran yum check-update at 12:04 pm and got the following..

[root@~]# yum check-update
Setting up repositories
Cannot open/read repomd.xml file for repository: extras
failure: repodata/repomd.xml from extras: [Errno 256] No more mirrors to 
try.
[root@~]#

Something went wrong and yum could not continue. So, I ran it again at 
12:09 pm and got the following..

[root@~]# yum check-update
Setting up repositories
extras                    100% |=========================| 1.1 kB    00:00
livna                     100% |=========================|  951 B    00:00
base                      100% |=========================| 1.1 kB    00:00
updates-released          100% |=========================|  951 B    00:00
Reading repository metadata in from local files
primary.xml.gz            100% |=========================| 557 kB    00:03
extras    : ################################################## 1584/1584
Added 15 new packages, deleted 0 old in 2.57 seconds
primary.xml.gz            100% |=========================| 109 kB    00:01
livna     : ################################################## 333/333
Added 3 new packages, deleted 0 old in 0.47 seconds
[root@~]#
This time it worked, and if it worked the second time, it could have 
worked the first time if yum didn't simply give up.

Although I am not a coder, I am submitting this improvement so that you 
can make yum better than it already is. Please consider the following 
improvement:

If yum fails to get repo data from the first repo, yum should just skip 
over that repo and get the data from the other repos I have enabled and 
then try the skipped repos again. If it worked on the second try, it can 
work on the first try. There should be an option to tell yum "do not 
stop trying until you have recieved all data from all repos".

I hope that this can be done and I would be willing to help in any way I 
can.

Thank you,
Ian MacGregor




------------------------------

Message: 5
Date: Fri, 12 Aug 2005 13:05:12 -0700
From: Michael Stenner <mstenner at ece.arizona.edu>
Subject: Re: [Yum] yum improvement
To: yum at lists.linux.duke.edu
Message-ID: <20050812200512.GG20886 at ece.arizona.edu>
Content-Type: text/plain; charset=us-ascii

On Fri, Aug 12, 2005 at 12:34:56PM -0700, Ian MacGregor wrote:
> If yum fails to get repo data from the first repo, yum should just skip 
> over that repo and get the data from the other repos I have enabled and 
> then try the skipped repos again.

If you want it to try more times or try longer, you should adjust the
"retries" and "timeout" options.

> If it worked on the second try, it can work on the first try.

I hate to tell you this, but the internet is not deterministic.
Sometimes things work, and sometimes things don't.  The chosen
behavior is a balance between overcoming short-term problems and
quickly reporting long-term problems.

> There should be an option to tell yum "do not stop trying until you
> have recieved all data from all repos".

retries = 1000000000

Do it if you dare.

					-Michael

-- 
  Michael D. Stenner                            mstenner at ece.arizona.edu
  ECE Department, the University of Arizona                 520-626-1619
  1230 E. Speedway Blvd., Tucson, AZ 85721-0104                 ECE 524G


------------------------------

Message: 6
Date: Fri, 12 Aug 2005 16:11:57 -0400
From: "Robert G. Brown" <rgb at phy.duke.edu>
Subject: Re: [Yum] yum improvement
To: Yellowdog Updater, Modified <yum at lists.dulug.duke.edu>
Cc: yum at lists.linux.duke.edu
Message-ID: <cone.1123877517.656609.5439.500 at lilith>
Content-Type: text/plain; charset="us-ascii"

Ian MacGregor writes:

> If yum fails to get repo data from the first repo, yum should just skip 
> over that repo and get the data from the other repos I have enabled and 
> then try the skipped repos again. If it worked on the second try, it can 
> work on the first try. There should be an option to tell yum "do not 
> stop trying until you have recieved all data from all repos".
> 
> I hope that this can be done and I would be willing to help in any way I 
> can.

This actually happens pretty often, usually when e.g. livna or freshrpms
are in your repo list.  They get hammered and are sometimes busy enough
to refuse connections or time out, at which point things fail.

A "better" solution at this point is to consider setting up your own
mirror or finding a mirror of these sites that you can add to a fallback
list.  In fact, you may be able to force pretty much the same thing by
simply adding duplicate lines to the baseurl so that it falls back on
itself a few times before quitting.

Adding a loop-forever hammering on the repos would be a nightmare,
though.  If they ever went down, even for a minute, they might never be
able to come back up again with all the queued access requests hammering
away.  Much better to be able to fail and really "try again later".

   rgb

> 
> Thank you,
> Ian MacGregor
> 
> 
> _______________________________________________
> Yum mailing list
> Yum at lists.dulug.duke.edu
> https://lists.dulug.duke.edu/mailman/listinfo/yum
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :
http://lists.dulug.duke.edu/pipermail/yum/attachments/20050812/2b16a6f5/atta
chment-0002.bin

------------------------------

Message: 7
Date: Fri, 12 Aug 2005 16:11:57 -0400
From: "Robert G. Brown" <rgb at phy.duke.edu>
Subject: Re: [Yum] yum improvement
To: Yellowdog Updater, Modified <yum at lists.dulug.duke.edu>
Cc: yum at lists.linux.duke.edu
Message-ID: <cone.1123877517.656609.5439.500 at lilith>
Content-Type: text/plain; charset="us-ascii"

Ian MacGregor writes:

> If yum fails to get repo data from the first repo, yum should just skip 
> over that repo and get the data from the other repos I have enabled and 
> then try the skipped repos again. If it worked on the second try, it can 
> work on the first try. There should be an option to tell yum "do not 
> stop trying until you have recieved all data from all repos".
> 
> I hope that this can be done and I would be willing to help in any way I 
> can.

This actually happens pretty often, usually when e.g. livna or freshrpms
are in your repo list.  They get hammered and are sometimes busy enough
to refuse connections or time out, at which point things fail.

A "better" solution at this point is to consider setting up your own
mirror or finding a mirror of these sites that you can add to a fallback
list.  In fact, you may be able to force pretty much the same thing by
simply adding duplicate lines to the baseurl so that it falls back on
itself a few times before quitting.

Adding a loop-forever hammering on the repos would be a nightmare,
though.  If they ever went down, even for a minute, they might never be
able to come back up again with all the queued access requests hammering
away.  Much better to be able to fail and really "try again later".

   rgb

> 
> Thank you,
> Ian MacGregor
> 
> 
> _______________________________________________
> Yum mailing list
> Yum at lists.dulug.duke.edu
> https://lists.dulug.duke.edu/mailman/listinfo/yum
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :
http://lists.dulug.duke.edu/pipermail/yum/attachments/20050812/2b16a6f5/atta
chment-0003.bin

------------------------------

Message: 8
Date: Fri, 12 Aug 2005 13:36:25 -0700
From: Greg Knaddison <greg.knaddison at gmail.com>
Subject: [Yum] Re: yum improvement
To: "Yellowdog Updater, Modified" <yum at lists.dulug.duke.edu>
Message-ID: <3861c6770508121336482cbf35 at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On 8/12/05, Ian MacGregor <ianmac7 at gmail.com> wrote:
> 
> If yum fails to get repo data from the first repo, yum should just skip 
> over that repo and get the data from the other repos I have enabled and 
> then try the skipped repos again. If it worked on the second try, it can 
> work on the first try. There should be an option to tell yum "do not 
> stop trying until you have recieved all data from all repos".
> 
> I hope that this can be done and I would be willing to help in any way I 
> can.
> 

Ian, 

Please also see http://wiki.linux.duke.edu/YumTodont where the idea of
skipping a repository has been documented as a 'bad idea'.  Your idea
of simply trying over and over and over until the mirror is back up is
slightly different, but also has draw backs as have been laid out
here.

Regards,
Greg


------------------------------

Message: 9
Date: Fri, 12 Aug 2005 19:47:37 -0700
From: Fong Vang <sudoyang at gmail.com>
Subject: [Yum] Yum book or good documentation
To: yum at lists.dulug.duke.edu
Message-ID: <4f52331f05081219474eeb205d at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Is there a good book on Yum?  What about other documentations?


------------------------------

_______________________________________________
Yum mailing list
Yum at lists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/yum


End of Yum Digest, Vol 25, Issue 11
***********************************





More information about the Yum mailing list