FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 08-06-2008, 05:01 PM
Thorsten Leemhuis
 
Default

On 06.08.2008 18:42, Paul W. Frields wrote:

On Wed, 2008-08-06 at 18:36 +0200, Thorsten Leemhuis wrote:

On 06.08.2008 15:05, Jesse Keating wrote:

On Wed, 2008-08-06 at 12:27 +0200, Michael Schwendt wrote:

> [...]
Level 1 -- rawhide, similar to how it is today (a bit more stable and
less breakage would be nice, but that's in the works already)
Level 2pre -- things that got tested in rawhide, that are still young,
but known to work well in rawhide; similar to what updates-testing for
F9 is today;
Level 2 -- things that worked fine for some time in 2pre; similar to
what F9 is today

Level 3pre -- things that worked fine for some time in 2
Level 3 -- things that worked fine for some time in 2pre

Level 3pre and 3 are like F8-updates-testing and F8, but with the
difference that everything has to be tested and shipped in level 2 (aka
F9) first.


Interestingly, this is is sort of what Seth Vidal recently did for yum
-- kinks were worked out in upstream and Rawhide, he has done several
useful updates for F-9, and only recently has he bundled it up for an
F-8 update. [...]


I liked that and it IMHO makes a whole lot of sense for most of our
other packages as well.


Something like the above was in fact the scheme that some of the long
term packagers used (and still use) during the early Fedora Extras days.
They suggested it to new packagers as well, but the idea got more and
more forgotten over time -- seems it was and is way to easy to just
import and build a new software release to all supported dists
(including EPEL :-// ) at the same time. That didn't matter much for
Extras, because most of the packages were not crucial. But it seems to
me that it's a problem in the merged world. Some user education might be
a good start to solve part of the problem.


Cu
knurd

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 08-06-2008, 05:04 PM
"Jeff Spaleta"
 
Default

On Wed, Aug 6, 2008 at 8:51 AM, seth vidal <skvidal@fedoraproject.org> wrote:
> The problem is this is based on Jesse's feeling that we're issuing a
> bunch of trivial updates and we're having trouble getting a metric on
> how accurate his feeling is.


Can we get a usably narrow definition of 'trivial updates' on record
in the discussion?

-jef"Given a finite number of updates in a release cycle, I'd rather
see more trivial updates than non-trivial API/ABI changing
updates."spaleta

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 08-06-2008, 05:51 PM
"Stephen Mazurek"
 
Default

I am using kernel 2.6.24-etchnhalf.1-686. The last few times I have
attempted to run aptitude update && aptitude upgrade from the command
line I have gotten an error message. gzip: stdin: not in gzip
format
Error http://ftp.us.debian.org etch/main packages
Sub-process gzip returned an error code (1)

Can anyone tell me what is going on? Is there a bug involved? I
don't recall having seen this before. Thanks.

--Steve


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 08-06-2008, 06:01 PM
Michael Schwendt
 
Default

On Wed, 06 Aug 2008 09:05:38 -0400, Jesse Keating wrote:

> The "too many updates" problem is something I've been trying to word so
> that others share my opinion that something is wrong here. I haven't
> been able to effectively communicate what I perceive to be a problem.

From the Fedora Wiki:

| Fedora is a Linux-based operating system that provides users with
| access to the latest free and open source software,

Always? Always "the latest" as in "a rolling release"? Or "the latest"
as in "what was fresh when Fedora N was being developed"?

| by sticking close to upstream development teams,
| Fedora often gets the latest software before anybody else.

The former can be considered good, the latter is not necessarily
good. Especially when reading it like "Fedora includes snapshots of
unreleased software while other distributors spend more time on
testing". The user wants to know what applies to Fedora N-1. Is it
more stable and less fast-moving?

Fine if the next Fedora release will aim at including the latest
technology. Not so fine if an older still maintained Fedora release is
moved to somewhere between a previously tested/stable release and the
next Fedora, N+1.

Fine if package maintainers release bug-fix updates from time to time,
which include accumulated fixes for bugs filed in Fedora bugzilla. Not so
fine if they release each and every upstream version as a "stable" Fedora
update after a ridiculously short time in updates-testing and possibly
even 0 karma (or +1 self-voted). Minor upstream updates often touch more
code than one might assume. A minor update breaks something or introduces
a new bug. Another bug-fix update is needed, and so on. Version upgrades
sometimes lead to a dead end, if their subsequent bug-fix updates require
upgrades of build requirements. Better spend the energy on Fedora N+1.

Look at software in a Fedora release which is not updated at all! It isn't
bug-free either. The next Fedora is only six months away.

| in a stable,
| secure
| and easy to manage form.

An upgrade a day keeps the user away.

Bodhi lists 3947 "stable" updates for Fedora 8 compared with 260 security
updates. Such a high number of updates and upgrades creates unnecessary
work for the users. Every week they are presented with another large
bunch of updates and need to find out how they are affected. For example,
by .rpmsave/.rpmnew madness, regressions, broken dependencies, the
necessity to "sync" configurations and customisations, being forced
to do manual downgrades, being forced to apply all updates in order to
rule out side-effects during trouble-shooting, silent API-breakage,
silent ABI-breakage (we've had it, too), incompatibilities introduced
by version upgrades *after* the final release.

I'm especially concerned about the wasted effort of doing several Test
releases before a final release and then throwing away all that work
gradually when more and more packages get replaced. Too many updates
receive negative karma. You ship a fix for one user and break something
for two other users. No reason to believe that untested updates are
safe(r).

I agree with Thorsten in that _some_ updates are nice to have, e.g. a
fresh kernel from time to time (and particularly if it is used for
a respin). A kernel a week is too much, however.

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 08-06-2008, 07:03 PM
Jason Voorhees
 
Default

Hi:

You're missing the /debian path in your URL. It should be

http://ftp.us.debian.org/debian ...

Bytes!

Stephen Mazurek escribi:

I am using kernel 2.6.24-etchnhalf.1-686. The last few times I have
attempted to run aptitude update && aptitude upgrade from the command
line I have gotten an error message. gzip: stdin: not in gzip
format
Error http://ftp.us.debian.org etch/main packages
Sub-process gzip returned an error code (1)

Can anyone tell me what is going on? Is there a bug involved? I
don't recall having seen this before. Thanks.

--Steve





--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 08-07-2008, 10:20 AM
Max Spevack
 
Default

On Wed, 6 Aug 2008, seth vidal wrote:

Also the reason why we're conservative on yum updates w/older releases
is simple: if yum breaks the ability to get more updates breaks too,
which is a big problem.


Reminds me of the following piece of advice that I received on my first
day working at Red Hat (as a QA guy in RHN):


"Whatever you do, *always* make sure that before we issue a new version
of up2date, it is capable of up2date-ing itself."


--Max

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 08-08-2008, 05:58 AM
Nicu Buculei
 
Default

This was posted on the Marketing list, I know that not all of us are
subscribed there and I think you cah use the laugh too:




-------- Original Message --------
Subject: Comedy: On Art and, Specifically, Fedora Art Concepts
Date: Fri, 08 Aug 2008 10:50:58 +0530
From: Rahul Sundaram
To: fedora-marketing-list@redhat.com

Hi

http://www.linuxloop.com/news/2008/08/07/comedy-on-art-and-specifically-fedora-art-concepts/

"
It is interesting to look at the differences in the styles of different
distributions. This is often best represented in looking at the art
proposals for upcoming versions of various distributions. For example, a
typical theme proposal for Fedora looks something like this:

“I was laying in my hammock one night gazing up at the infinite
stars when suddenly an idea occurred to me. Gazing out at the vastness
of the stars, it seemed to be that those stars perfectly represented
Fedora, since Fedora 9 was called “Sulfur” and there has got to be some
sulfur out there somewhere.”

A typical Ubuntu art submission, on the other hand, looks more like this:

“ubuntu rulz!!! see my awesum desktop: ubuntu should totally look
like dis”

Rahul

_______________________________________________
Fedora-art-list mailing list
Fedora-art-list@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-art-list
 
Old 08-09-2008, 02:42 PM
"William L. Maltby"
 
Default

On Tue, 2008-07-22 at 10:16 -0700, MHR wrote:
> <snip>

SYNOPSIS: In case you missed or lost the start of this thread, I was
setting up two displays, one per video card, on my CentOS 4.6. This was
testing before applying the same setup to my 5.2 system, upon which I
run an application critical to me.

The kudzu detection worked correctly and system-config-display (a
symlink to consolehelper) generated a new xorg.conf.

THIS WAS AN ERRONEOUS CONFIGURATION FILE.

In the second Section "Device" it inserted "Screen 1". This is an error
*unless* there is a second port on the video card and it is being used.
In that case it is mandatory.

> HTH, and ROR (Rots 'O Ruck, as opposed to LOL :-)

Well, didn't get it on the net within a reasonable (? excessive knowing
me) number of searches and threads read. So I decided to make my own
luck.

Genetically, I'm predisposed to banging heads (usually my own,
occasionally heads of others) against brick walls. So I naturally
started reading man pages. I guess I'm masochistic to some degree.

Anyway, about the third one I looked at, xorg.conf, it started laying
out the options and their meanings.

As soon as I saw the description of the "Screen" parameter, I knew
because that card I added doesn't have a second port. The primary card
does have the standard analogue, DVI and S-video outputs. Maybe the
configurator is not intelligent enough to discern between the two cards
when they are both the same chip sets.

Anyway, hurdle 1 cleared. Now to get it to do what I want it too -
spread one view port across the two monitors.

Thanks to all those who responded and tried to help.

If anyone would test and confirm this is not site-specific, I will post
a bug on it. I'll also be doing this on my 5.2 in the near future. I'll
be interested to see if the bug exists there also.

>
> mhr
> <snip sig stuff>

--
Bill

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 08-09-2008, 02:48 PM
Eric Martin
 
Default

Alan McKinnon wrote:

On Friday 08 August 2008 19:58:46 Eric Martin wrote:

On one of my boxes, eix shows every package as (*) which is testing for
my current arch but stable on some other. emerge --info reports x86 as
my arch, so I don't know what the problem is. I don't think it's a huge
problem as it's just an annoyance but I might be missing something. I
don't know where to start on google / forums so I figured I'd start here.


I recall something similar happening to me a while ago, on a disconnected box
that hadn't been updated for 6 months. I was getting weird status symbols just
like you after a sync. In my case, an upgrade to the latest ~arch portage
fixed it.


You seem to be running purely x86 right? I assume as a first step you have
done all the sensible things - remerge latest stable portage, emerge --sync,
checked /etc/portage/* for silly masks that you forgot about?



I figured it out! /etc/make.profile was linked to
/usr/portage/profiles/default/linux/2008.0 rather than


/usr/portage/profiles/default-linux/2007.0

(as all of my other machines are). Changing that solved it. What I
don't get is why that would break things...


--
Eric Martin
Key fingerprint = D1C4 086E DBB5 C18E 6FDA B215 6A25 7174 A941 3B9F
 
Old 08-11-2008, 04:38 PM
"William L. Maltby"
 
Default

On Mon, 2008-08-11 at 11:04 -0500, Lanny Marcus wrote:
> <snip>

> Vi or vim. I think Emacs would just cloud my mind, when I'm trying to absorb
> C++ Lanny

If you have C experience, it'll be quick once you get your head around
constructors, destructors, inheritance, templates (I never did enough of
that to get it), et al.

It essentially implements a bunch of things we used to do as functions,
libraries or modules when we recognized a strong re-usability potential,
and formalizes all that to the object oriented model.

Good luck on it and I know you'll enjoy it once you see results.

> <snip sig stuff>

--
Bill

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 

Thread Tools




All times are GMT. The time now is 08:10 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org