quot; does not fix the known
security problems on your system, that's a huge exploit waiting to
happen ... and one I doubt any users know about.
I've sent a query to security@ to clarify.
--
James Antill - ja...@fedoraproject.org
http://yum.baseurl.org/wiki/releases
http://yum.base
On Wed, 2010-03-03 at 01:54 +0100, Kevin Kofler wrote:
> James Antill wrote:
> > Users don't get a constant firehose of updates they are basically
> > forced to install, a lot more packages should spend a lot more time in
> > testing (thus. the user can choose to
the vanilla fedora 'initscripts' package, then
> tor would still require[1] syslog, cpio, e2fsprogs, ethtool, mount, ...
You are joking, right? I mean apart from the fact that there is a
_huge_ difference between requiring "mount" and "libX*" ... the _kernel_
requ
On Tue, 2010-03-02 at 12:08 -0500, Frank Ch. Eigler wrote:
> James Antill writes:
>
> >> > [...]
> >> > ...but they have almost no options if they are happy to stay with
> >> > the software that they have.
> >>
> >> Doesn't &quo
On Tue, 2010-03-02 at 10:57 -0500, Frank Ch. Eigler wrote:
> James Antill writes:
>
> > https://fedoraproject.org/wiki/Release_Lifecycle_Proposals#Choice_.28james.29
>
> Regarding this, I don't understand this part:
>
> > The idea behind this proposal is
k updates-testing should be bypassed in a significant number of
cases, well then rawhide is that => way.
--
James Antill - ja...@fedoraproject.org
http://yum.baseurl.org/wiki/releases
http://yum.baseurl.org/wiki/whatsnew/3.2.27
http://yum.baseurl.org/wiki/YumMultipleMachineCaching
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Tue, 2010-03-02 at 10:59 +0100, Kevin Kofler wrote:
> James Antill wrote:
> > So I did my proposal, which I think will motivate packagers to do the
> > right thing (giving lots of choice to the users and a reasonable number
> > of packages to test) and not removing the ab
in a Panglossian
> > manner doesn't help your cause, as it just makes you look like you're
> > denying there could ever possibly be any problems with your method.
>
> But that's not a cost for the maintainer (unless the regression breaks
> his/her own system). :
On Tue, 2010-03-02 at 11:22 +0100, Kevin Kofler wrote:
> James Antill wrote:
> > It's still not really usable by normal users, but people on this list
> > can install "yum-plugin-local" ... which will make sure you can do
> > downgrades like this.
>
>
pace in /var, which everyone always
> forgets to make big enough'?
Yeh, single giant partition FTW!
Also, you can configure where it dumps it's arseload.
Ok, on that note time for sleep.
--
James Antill - ja...@fedoraproject.org
http://yum.baseurl.org/wiki/releases
http://yum.baseurl
uck. My last yum-update hit 19 packages, and only 7 can be
> downgraded by yum-history-undo.
It's still not really usable by normal users, but people on this list
can install "yum-plugin-local" ... which will make sure you can do
downgrades like this.
--
James An
ght thing (giving lots of choice to the users and a reasonable number
of packages to test) and not removing the ability of packagers to do
what they want (and have the stable firehose):
https://fedoraproject.org/wiki/Release_Lifecycle(draft)#Choice_.28james.29
--
James Antill - ja...@fedoraproj
e we don't have
the manpower to backport all fixes ... but there's a _big_ difference
between being forced to do it some of the time and guaranteeing that the
firehose breaks it _every_ release for _every_ user.
--
James Antill - ja...@fedoraproject.org
http://yum.baseurl.org/wiki/releases
ht
ads, if you know of a way to speed up a users internet
connection ... feel free to spread your wisdom.
ยน We also have an optimisation for large updates, that we can probably
turn on for F13.
--
James Antill - ja...@fedoraproject.org
http://yum.baseurl.org/wiki/releases
http://yum.baseurl.org/wik
ed out 36GB+ (I'm not sure I
have full package stats. from F11 GA). How many users want that? Hell,
how many developers not on rawhide want that?
But, again, as has been pointed out to you many times now ... the
current proposal is a tiny speed bump in that horrendous amount of
updates.
--
James
pdates" by all sane users. And if not my previous message
should have helped to inform you of that (assuming you are actually
reading other people's comments).
--
James Antill - ja...@fedoraproject.org
http://yum.baseurl.org/wiki/releases
http://yum.baseurl.org/wiki/whatsnew/3.2.27
http
u've started is
that you feel so persecuted by such tiny proposed changes ... certainly
if I was "god" I'd _happily_ ban any non-high-security updates for over
a month without even thinking about it (rawhide is => that way, have fun
IMNSHO).
And that's just from my users pe
you must do X if you want more, less tested,
updates" is backwards for a stable release.
...and as in all threads about this that I can remember, the obvious fix
to the above is having two repos. and let everyone who wants a giant
firehose of mostly working stuff can enable this second repo
e. It's likely that F12 will get a yum update
eventually ... and you can get a 3.2.26+ yum from rawhide now. So for
ideas about changing how rawhide works, that's not a big requirement is
it?
--
James Antill - ja...@fedoraproject.org
http://yum.baseurl.org/wiki/releases
http:
hide forever, without
user intervention, but I'm not sure that's a bad thing (but then I don't
do that).
--
James Antill - ja...@fedoraproject.org
http://yum.baseurl.org/wiki/releases
http://yum.baseurl.org/wiki/whatsnew/3.2.27
http://yum.baseurl.org/wiki/YumMultipleMachineCaching
-
-clients
...putting that in a plugin (or even, in the above plugin) isn't
amazingly hard, but nobody has done it yet (I'll be happy to help
someone, but I'm not dying to do it myself).
Of course, there there's:
[https://bugzilla.redhat.com/show_bug.cgi?id=568488]
yum-plugin
ckages.
So, no, but for a lot of packages I guess you could install
foo-debuginfo instead of just foo (assuming all the debuginfo repos. are
enabled somehow).
--
James Antill - ja...@fedoraproject.org
http://yum.baseurl.org/wiki/releases
http://yum.baseurl.org/wiki/whatsnew/3.2.26
http://yum.baseurl.
On Fri, 2010-01-29 at 12:33 -0500, David Malcolm wrote:
> On Fri, 2010-01-29 at 17:04 +, Mat Booth wrote:
> > On 29 January 2010 17:00, Pierre-Yves wrote:
> > > On Fri, 2010-01-29 at 11:59 -0500, David Malcolm wrote:
> > >> Here's where it gets weird:
> > >> 0.6.10-1 then 0.6.10-2 then 0.6.9-4
On Mon, 2010-02-01 at 12:08 +, M A Young wrote:
> On Mon, 1 Feb 2010, drago01 wrote:
>
> > On Mon, Feb 1, 2010 at 9:30 AM, M A Young wrote:
> >>
> >> That doesn't work as nicely as perhaps it should because
> >> yum downgrade firefox
> >> only downgrades firefox and not xulrunner, and as a re
ured data for upto 10 days, by default.
So personally I'd prefer to just rely on MirrorManager. But saying all
that a lot of people swear by it, and CentOS (who don't use
MirrorManager) require it.
--
James Antill - ja...@fedoraproject.org
http://yum.baseurl.org/wiki/releases
http://y
h local mirrors is that it's often optimal to
download from them as we are atm. ... any attempt to use another mirror
is slower (and sometimes more expensive).
In fact my local mirror is often so fast that I seriously doubt whether
much improvement could be made due to pipelining etc. (which is
yed.
This should use the yum API, IMO. Then you can output the yumdb info.
(esp. from_repo). Also on newer yum's it'd be nice to run "yum check"
and also "needs-restarting" (from newer yum-utils).
Also it'd be nice if the python tracebacks weren't in a
501 - 527 of 527 matches
Mail list logo
