date:20091202

The separate updates directory has been a pain for as long as I've been 
using RHL/Fedora Core/Fedora. It means you have two places to look when 
searching for packages manually, and twice as much to configure when 
you're configuring yum. It has never benefitted me, or anybody I know, 
but it has caught me out on any number of occasions. What's more, nobody 
really seems to know why it's like that: it seems it's always been that 
way, and nobody ever bother to fix it.


So lets fix it. The package set at release time is only interesting to 
historians. If any of them are really that bothered, I'm sure somebody 
can come up with a yum module which finds the oldest available version 
of a package in a repo.


Matt
--
Matthew Booth, RHCA, RHCSS
Red Hat Engineering, Virtualisation Team

M:   +44 (0)7977 267231
GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Proposed F13 feature: drop separate updates repository

2009-12-02 Thread Jon Ciesla


Matthew Booth wrote:
The separate updates directory has been a pain for as long as I've 
been using RHL/Fedora Core/Fedora. It means you have two places to 
look when searching for packages manually, and twice as much to 
configure when you're configuring yum. It has never benefitted me, or 
anybody I know, but it has caught me out on any number of occasions. 
What's more, nobody really seems to know why it's like that: it seems 
it's always been that way, and nobody ever bother to fix it.


So lets fix it. The package set at release time is only interesting to 
historians. If any of them are really that bothered, I'm sure somebody 
can come up with a yum module which finds the oldest available version 
of a package in a repo.


Matt
Would not this also provide the minor added benefit that there could now 
be a drpm for the first update for a package?


-J

--
in your fear, seek only peace
in your fear, seek only love

-d. bowie

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Proposed F13 feature: drop separate updates repository


On 12/02/2009 03:39 PM, Matthew Booth wrote:

The separate updates directory has been a pain for as long as I've been
using RHL/Fedora Core/Fedora. It means you have two places to look when
searching for packages manually, and twice as much to configure when
you're configuring yum. It has never benefitted me, or anybody I know,
but it has caught me out on any number of occasions. What's more, nobody
really seems to know why it's like that: it seems it's always been that
way, and nobody ever bother to fix it.

So lets fix it. The package set at release time is only interesting to
historians. If any of them are really that bothered, I'm sure somebody
can come up with a yum module which finds the oldest available version
of a package in a repo.


So your proposal is to drop updates, but to add updates to Everything?

In this case, I am all for it.

Ralf


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Proposed F13 feature: drop separate updates repository

On Wed, Dec 02, 2009 at 09:00:53AM -0600, Jon Ciesla wrote:
 Matthew Booth wrote:
 The separate updates directory has been a pain for as long as I've  
 been using RHL/Fedora Core/Fedora. It means you have two places to  
 look when searching for packages manually, and twice as much to  
 configure when you're configuring yum. It has never benefitted me, or  
 anybody I know, but it has caught me out on any number of occasions.  
 What's more, nobody really seems to know why it's like that: it seems  
 it's always been that way, and nobody ever bother to fix it.

 So lets fix it. The package set at release time is only interesting to  
 historians. If any of them are really that bothered, I'm sure somebody  
 can come up with a yum module which finds the oldest available version  
 of a package in a repo.

 Matt
 Would not this also provide the minor added benefit that there could now  
 be a drpm for the first update for a package?

We already have that if the update is done after GA.

josh

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Proposed F13 feature: drop separate updates repository

On Wed, Dec 02, 2009 at 02:39:30PM +, Matthew Booth wrote:
 The separate updates directory has been a pain for as long as I've been  
 using RHL/Fedora Core/Fedora. It means you have two places to look when  
 searching for packages manually, and twice as much to configure when  
 you're configuring yum. It has never benefitted me, or anybody I know,  
 but it has caught me out on any number of occasions. What's more, nobody  
 really seems to know why it's like that: it seems it's always been that  
 way, and nobody ever bother to fix it.

 So lets fix it. 

And how do you propose to do that?

josh

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: livecds in the future

On 12/01/2009 11:49 AM, Sir Gallantmon wrote:

 Couldn't something like that be implemented into GRUB/GRUB2? Unlike PLoP,
 GRUB doesn't really have a size restriction, so maybe smarter methods of
 detection could be implemented.

The approach of loading what amounts to DOS TSRs is something you could
do with pretty much any x86 bootloader (though it's worlds simpler with
syslinux than grub). But we're still basically talking about writing a
bunch of 16-bit device drivers.

I'm thinking it's not going to happen.

-- 
Peter

Growth for the sake of growth is the ideology of the cancer cell.

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Proposed F13 feature: drop separate updates repository


On 02/12/09 15:26, Josh Boyer wrote:

On Wed, Dec 02, 2009 at 02:39:30PM +, Matthew Booth wrote:

The separate updates directory has been a pain for as long as I've been
using RHL/Fedora Core/Fedora. It means you have two places to look when
searching for packages manually, and twice as much to configure when
you're configuring yum. It has never benefitted me, or anybody I know,
but it has caught me out on any number of occasions. What's more, nobody
really seems to know why it's like that: it seems it's always been that
way, and nobody ever bother to fix it.

So lets fix it.


And how do you propose to do that?


Unfortunately I'm not intimately familiar with Fedora infrastructure 
under-the-hood. However, I would hope that, technically at least, it 
wouldn't be much more than a systematic removal of all updates 
repositories and redirecting files which would have gone into them into 
the main repositories instead. This stems from the observation that if 
you copied everything from the main repository into updates you would 
have created the repository which people unfamiliar with the history 
would expect. The infrastructure side of this, on the face of it, sounds 
very simple.


More involved would be:

1. Updating all packages which expect 2 repos to only expect 1.
2. Communicating the change effectively.

Matt
--
Matthew Booth, RHCA, RHCSS
Red Hat Engineering, Virtualisation Team

M:   +44 (0)7977 267231
GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Proposed F13 feature: drop separate updates repository

2009-12-02 Thread Jon Ciesla


Josh Boyer wrote:

On Wed, Dec 02, 2009 at 09:00:53AM -0600, Jon Ciesla wrote:
  

Matthew Booth wrote:

The separate updates directory has been a pain for as long as I've  
been using RHL/Fedora Core/Fedora. It means you have two places to  
look when searching for packages manually, and twice as much to  
configure when you're configuring yum. It has never benefitted me, or  
anybody I know, but it has caught me out on any number of occasions.  
What's more, nobody really seems to know why it's like that: it seems  
it's always been that way, and nobody ever bother to fix it.


So lets fix it. The package set at release time is only interesting to  
historians. If any of them are really that bothered, I'm sure somebody  
can come up with a yum module which finds the oldest available version  
of a package in a repo.


Matt
  
Would not this also provide the minor added benefit that there could now  
be a drpm for the first update for a package?



We already have that if the update is done after GA.

josh

  
If that's the case, then good. In that case, I see no huge benefit to 
leaving it or changing it.


--
in your fear, seek only peace
in your fear, seek only love

-d. bowie

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Proposed F13 feature: drop separate updates repository

On Wed, Dec 02, 2009 at 03:44:08PM +, Matthew Booth wrote:
 On 02/12/09 15:26, Josh Boyer wrote:
 On Wed, Dec 02, 2009 at 02:39:30PM +, Matthew Booth wrote:
 The separate updates directory has been a pain for as long as I've been
 using RHL/Fedora Core/Fedora. It means you have two places to look when
 searching for packages manually, and twice as much to configure when
 you're configuring yum. It has never benefitted me, or anybody I know,
 but it has caught me out on any number of occasions. What's more, nobody
 really seems to know why it's like that: it seems it's always been that
 way, and nobody ever bother to fix it.

 So lets fix it.

 And how do you propose to do that?

 Unfortunately I'm not intimately familiar with Fedora infrastructure  
 under-the-hood. However, I would hope that, technically at least, it  
 wouldn't be much more than a systematic removal of all updates  
 repositories and redirecting files which would have gone into them into  
 the main repositories instead. This stems from the observation that if  
 you copied everything from the main repository into updates you would  
 have created the repository which people unfamiliar with the history  
 would expect. The infrastructure side of this, on the face of it, sounds  
 very simple.

What you describe is effectively how the development repository is built,
so it's certainly a technical possibility.  It does have implications
though.  Off the top of my head, I can think of:

1) Composing a new everything tree for updates would lead to larger
compose times.  That could possibly mean that getting updates out would
take  1 day per 'push'.  We've been trying to improve updates push
times so it would be a bit detrimental to that goal.

2) There might be GPL compliance issues

3) You would still need an 'updates-testing' repository given that this
is a supposedly stable release.  So there is still going to be at least
one additional repo regardless.

However, other than 'browsing manually for packages', I'm not really
sure what problem you are trying to solve by getting rid of the
updates repository.  It would seem like this has quite a bit of cost
for relatively little to no real gain?

josh

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Blocking radeonhd (was Re: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?)

2009-12-02 Thread Bill Nottingham

Matěj Cepl (mc...@redhat.com) said: 
 Moreover, I don't know what's your problem with radeonhd driver in
 Fedora. Hanz does IMHO excellent job on maintaining it and it
 doesn't drag much additional resources on anybody (except on me,
 perhaps, because I triage bugs for him as well, which is the reason
 that this time I even a little know what I am talking about ;)). And
 of course comparing -radeonhd bugs (http://is.gd/59Hc0) with -ati
 bugs (http://is.gd/59Hp0) is unfair, because there are many more
 users of -ati driver, but at least it shows that radeonhd is really
 not burning issue.
 
 What's the problem?

Does not work at all with KMS, which is on by default; is unsupported
by the people that maintain the servers and the rest of the drivers.
Following a sane OAOO strategy, we'll get better results if we
try and get all fixes on a single driver path moving forwards.

Bill

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: abrt issues

2009-12-02 Thread Jiri Moskovcak


What is the question here, so I try to describe what's abrt trying so say:
On 12/02/2009 02:28 PM, Neal Becker wrote:

Wondering about these odd messages:

Dec  2 07:40:12 nbecker6 python: abrt: Pyhook: Detected unhandled
exception in /tmp/hgtests.eYmApF/install/bin/hg


- hook detected an unhandled exception


Dec  2 07:40:12 nbecker6 abrtd: Directory 'pyhook-1259757612-30443'
creation detected


- abrt daemon detected a new directory containing info about some crash


Dec  2 07:40:12 nbecker6 abrtd: Lock file
'/var/cache/abrt/pyhook-1259757612-30443.lock' is locked by process
30445


- but at that time hook wasn't done with writing the info into, so the 
daemon had to wait...



Dec  2 07:40:12 nbecker6 python: abrt: Pyhook: Detected unhandled
exception in /tmp/hgtests.eYmApF/install/bin/hg


- and the same crash occured again ...


Dec  2 07:40:13 nbecker6 abrtd: Executable doesn't belong to any
package


- now the daemon examined the info written by the hook and noticed that 
it doesn't belong to any package



Dec  2 07:40:13 nbecker6 abrtd: Corrupted or bad crash, deleting


- so the daemon deleted it (saying this confusing message)

Dec  2 07:40:13 nbecker6 abrtd: Directory 'pyhook-1259757612-30446'
creation detected


- now the daemon noticed the second crash

Dec  2 07:40:13 nbecker6 abrtd: Executable doesn't belong to any
package
Dec  2 07:40:13 nbecker6 abrtd: Corrupted or bad crash, deleting


- and did the same as with the first one..

Dec  2 07:45:56 nbecker6 python: abrt: Pyhook: Detected unhandled
exception in dumb.py
Dec  2 07:45:56 nbecker6 abrtd: Directory 'pyhook-1259757956-4737'
creation detected
Dec  2 07:45:56 nbecker6 abrtd: Lock file
'/var/cache/abrt/pyhook-1259757956-4737.lock' is locked by process
4773
Dec  2 07:45:56 nbecker6 abrtd: Executable doesn't belong to any
package
Dec  2 07:45:56 nbecker6 abrtd: Corrupted or bad crash, deleting



- and again ...


attachment: jmoskovc.vcf-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Proposed F13 feature: drop separate updates repository

2009-12-02 Thread Naheem Zaffar

2009/12/2 Justin M. Forbes jmfor...@linuxtx.org

 The only downside to merging updates into the main repository...


I would also assume that the repo data will need to be regenerated and often
be much larger than the one that is for the updates only repository, so
there will be acost to end users with this proposed change?
-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Ubuntu Xorg Guru calls for help. Was Re: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?

2009-12-02 Thread Adam Jackson

On Wed, 2009-12-02 at 11:01 +, Ikem Krueger wrote:
  Nope, Bryce doesn't get to work on upstream in any significant way as
  part of his Ubuntu work. I was chatting with Dave about this on IRC the
  other day. The most significant submission to upstream X.org that's ever
  come out of Ubuntu is a quirk table. (yippee.)
 
 Did you chatted with Bryce?

Let's chat with git:

atropine:~/xserver% git log --author=bryce | grep -c ^commit  
0

atropine:~/drivers/intel% git log --author=bryce --pretty=oneline
6b93afc564a5e74b0eaaa46c95f557449951b3b9 add pipe a force quirk for Dell mini
6c56521bdc0443c0656271caaa795feb13bc1d6b pipe-a quirk for thinkpad x30
83377b543defdca7226d7c1a7794e4ff3d8b4c84 Pipe-A quirk for HP 2730p (bug #18852)
6c4e134a1a30785c2e5c6d57b21fde54a2dd3413 PipeA quirk for Quanta/W251U 
(launchpad bug #244242)
afa630b448e5993850433c9f0b129758ec4d37b5 Add TV out quirk for HP Compaq nx6110
231a302013981cc597ba09ee89b367c8ab56e8ba Two more Dell quirks
d91d9e6a2f2ba18b35cb6fd7bc3fe8bc617eb44f More Pipe A force quirks
be746a90a87d7a9807fa4243493e7e4d48f7f1c0 More quirks from ubuntu/dell
37bc23660a8c346f1eaa6c93ed2c7a840828f0b0 Quirks from Ubuntu/Dell

atropine:~/drivers/ati% git log --author=bryce --pretty=oneline
c71b2f050e8996787eae463eddbfdb5864ffa65a radeon: AGPMode quirk needed for SiS
e3659ed06fc5bb8817f1dbd7c2d6bc94c67b30f7 radeon: AGPMode quirk needed for IBM 
Thinkpad T40 with Mobility M7 LW
2391531ed6b7c11ddd5ab91b2369821cc5f8b8a7 radeon: AGPMode quirk needed for HP 
Omnibook 6200
49b57767d0d2c041517b0764c2ed2d2ba5a7092c Quirk for RV280 on 82865G/PE/P DRAM 
Controller/Host-Hub
fe73d9a7dfe8ec5c8f1a8dc08e14b4e138aa9276 Add another AGP quirk
36a7dc6ea1e1929e986ab1159497c71521cb2f10 Additional AGP quirks
937b7ac2a259cf504a19dcf62a58b1db1afb8eb9 Add AGP quirk table
1cf7a5494fa94e8d9f30f9b2905dfbe6d4faa445 radeon: Fix pasto in connector table 
setup for vga powerbooks

- ajax


signature.asc
Description: This is a digitally signed message part
-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Proposed F13 feature: drop separate updates repository

2009-12-02 Thread Daniel P. Berrange

On Wed, Dec 02, 2009 at 10:01:51AM -0600, Justin M. Forbes wrote:
 On Wed, Dec 02, 2009 at 02:39:30PM +, Matthew Booth wrote:
  The separate updates directory has been a pain for as long as I've been 
  using RHL/Fedora Core/Fedora. It means you have two places to look when 
  searching for packages manually, and twice as much to configure when you're 
  configuring yum. It has never benefitted me, or anybody I know, but it has 
  caught me out on any number of occasions. What's more, nobody really seems 
  to know why it's like that: it seems it's always been that way, and nobody 
  ever bother to fix it.
 
 The only downside to merging updates into the main repository is that
 network installs from the repository will no longer install the release
 they will install the updated release.  QA that goes into that first
 impression is no longer there, and your installs are not repeatable because
 installing system A on one day and system B on another could end up with
 different versions of packages.  Of course you can always install from the
 ISOs to avoid these problems. As things are, you have the choice of the
 release as it was, or the updated release at install time.  I am not
 saying that this is a bad idea, in fact I rather like it, but there are
 things to consider.

I think this is quite a compelling reason not to touch it. Much as we'd
like the updates repository to always be perfectly stable, there are 
still plenty of occassions when we hit problems with updates. Being able
to reliably install the release at all times is pretty critical  saying
we should install off ISO if we want a reliable install is not really an
acceptable alternative since many people do all their installs straight
off the network.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Proposed F13 feature: drop separate updates repository

2009-12-02 Thread Paul W. Frields

On Wed, Dec 02, 2009 at 11:09:41AM -0500, Bill Nottingham wrote:
 Matthew Booth (mbo...@redhat.com) said: 
  The separate updates directory has been a pain for as long as I've
  been using RHL/Fedora Core/Fedora. It means you have two places to
  look when searching for packages manually, and twice as much to
  configure when you're configuring yum. It has never benefitted me,
  or anybody I know, but it has caught me out on any number of
  occasions. What's more, nobody really seems to know why it's like
  that: it seems it's always been that way, and nobody ever bother to
  fix it.
  
  So lets fix it. The package set at release time is only interesting
  to historians. If any of them are really that bothered, I'm sure
  somebody can come up with a yum module which finds the oldest
  available version of a package in a repo.
 
 The separate Everything tree that does not get obsoleted is required
 in some form for GPL compliance, with respect to the ISO images that
 we ship. Any new solution would have to preserve this.

Might there also be export compliance implications too?

-- 
Paul W. Frieldshttp://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
  http://redhat.com/   -  -  -  -   http://pfrields.fedorapeople.org/
  irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Proposed F13 feature: drop separate updates repository

2009-12-02 Thread Kevin Fenzi

On Wed, 02 Dec 2009 17:27:17 +0100
Ralf Corsepius rc040...@freenet.de wrote:

 On 12/02/2009 05:09 PM, Bill Nottingham wrote:
  Matthew Booth (mbo...@redhat.com) said:
  The separate updates directory has been a pain for as long as I've
  been using RHL/Fedora Core/Fedora. It means you have two places to
  look when searching for packages manually, and twice as much to
  configure when you're configuring yum. It has never benefitted me,
  or anybody I know, but it has caught me out on any number of
  occasions. What's more, nobody really seems to know why it's like
  that: it seems it's always been that way, and nobody ever bother to
  fix it.
 
  So lets fix it. The package set at release time is only interesting
  to historians. If any of them are really that bothered, I'm sure
  somebody can come up with a yum module which finds the oldest
  available version of a package in a repo.
 
  The separate Everything tree that does not get obsoleted is required
  in some form for GPL compliance, with respect to the ISO images that
  we ship.
 Isn't this the Fedora repo?
 
 To my knowledge the Fedora repos corresponds 1:1 to the isos.

To the DVD iso, yes. 

To any of the spins/desktop/live... nope. They use packages from
Everything/

kevin


signature.asc
Description: PGP signature
-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Proposed F13 feature: drop separate updates repository

2009-12-02 Thread Bill Nottingham

Ralf Corsepius (rc040...@freenet.de) said: 
 Does the FSF/GPL demand to keep a repo around for ISOs?
 A rolling Everything would not touch the ISOs. They would still be around.

The LiveCD/spins satisfy their source requirements via the source
repositories; they do not compose separate live source images.

Bill

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Proposed F13 feature: drop separate updates repository

2009-12-02 Thread Casey Dahlin

On Wed, Dec 02, 2009 at 11:28:24AM -0500, Paul W. Frields wrote:
  
  The separate Everything tree that does not get obsoleted is required
  in some form for GPL compliance, with respect to the ISO images that
  we ship. Any new solution would have to preserve this.
 
 Might there also be export compliance implications too?

What manner of export issues? This change doesn't, afaik, affect where
export-restricted software appears in any way.

--CJD

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Proposed F13 feature: drop separate updates repository

2009-12-02 Thread Casey Dahlin

On Wed, Dec 02, 2009 at 11:06:22AM -0500, Josh Boyer wrote:
 1) Composing a new everything tree for updates would lead to larger
 compose times.  That could possibly mean that getting updates out would
 take  1 day per 'push'.  We've been trying to improve updates push
 times so it would be a bit detrimental to that goal.
 

This might be a good opportunity to look at some way of pushing
incremental sets of packages rather than re-building the entire yum repo
each time. Mashing is not a cheap operation.

 2) There might be GPL compliance issues
 
 3) You would still need an 'updates-testing' repository given that this
 is a supposedly stable release.  So there is still going to be at least
 one additional repo regardless.
 

We have tags for updates that mark them as bugfix/feature/security.
Maybe we could have one for testing which would keep yum from
installing the package unless explicitly asked or specially configured.

 However, other than 'browsing manually for packages', I'm not really
 sure what problem you are trying to solve by getting rid of the
 updates repository.  It would seem like this has quite a bit of cost
 for relatively little to no real gain?
 

This is true. I don't know that manual package browsing is a use case
we've ever been interested in, and if we're going to be interested in it
there's probably a better way (search engine in the Fedora community
portal comes to mind).

 josh

You owe me $5.

--CJD

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Proposed F13 feature: drop separate updates repository




On Wed, 2 Dec 2009, Paul W. Frields wrote:


On Wed, Dec 02, 2009 at 11:09:41AM -0500, Bill Nottingham wrote:

we ship. Any new solution would have to preserve this.


Might there also be export compliance implications too?



A larger isssue is constantly having the repodata for the everything repo 
be:


1. growing
2. changing

So now instead of having a 15K pkg repo that never changes you have an 
ever-growing repo that never shrinks in size that changes what? 3 times a 
week?


-sv

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Proposed F13 feature: drop separate updates repository


On 12/02/2009 06:01 PM, Casey Dahlin wrote:

On Wed, Dec 02, 2009 at 11:06:22AM -0500, Josh Boyer wrote:



However, other than 'browsing manually for packages', I'm not really
sure what problem you are trying to solve by getting rid of the
updates repository.  It would seem like this has quite a bit of cost
for relatively little to no real gain?



This is true.

It is not true.

* It shifts costs from users to vendor
and from mirrors to master.
* It helps users who are using networked installs to spare bandwidth 
(avoids downloading obsolete packages from Everything/Fedora).


Admitted, for most users, it would change almost nothing.

Ralf


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Proposed F13 feature: drop separate updates repository


On 02/12/09 16:01, Justin M. Forbes wrote:

On Wed, Dec 02, 2009 at 02:39:30PM +, Matthew Booth wrote:

The separate updates directory has been a pain for as long as I've been
using RHL/Fedora Core/Fedora. It means you have two places to look when
searching for packages manually, and twice as much to configure when you're
configuring yum. It has never benefitted me, or anybody I know, but it has
caught me out on any number of occasions. What's more, nobody really seems
to know why it's like that: it seems it's always been that way, and nobody
ever bother to fix it.


The only downside to merging updates into the main repository is that
network installs from the repository will no longer install the release
they will install the updated release.  QA that goes into that first
impression is no longer there, and your installs are not repeatable because
installing system A on one day and system B on another could end up with
different versions of packages.  Of course you can always install from the
ISOs to avoid these problems. As things are, you have the choice of the
release as it was, or the updated release at install time.  I am not
saying that this is a bad idea, in fact I rather like it, but there are
things to consider.


That's not a bug, it's a feature! Seriously, wasn't it a specific F10 or 
F11 feature that anaconda allowed the user to specify that updates be 
installed at installation time? Certainly I used to have Debianites crow 
at me that my installation was vulnerable until I updated it. Not only 
that, but I had to download updated packages twice. These days I always 
install with updates. I find the installation argument dubious at best.


Still, we could rename the main repo the 'installation' repo, and 
nothing but anaconda would ever look at it. Everything else would look 
at the main repo, which would be the same as the current updates repo 
except with everything in it from the start.


Matt
--
Matthew Booth, RHCA, RHCSS
Red Hat Engineering, Virtualisation Team

M:   +44 (0)7977 267231
GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Proposed F13 feature: drop separate updates repository


On 02/12/09 16:09, Bill Nottingham wrote:

Matthew Booth (mbo...@redhat.com) said:

The separate updates directory has been a pain for as long as I've
been using RHL/Fedora Core/Fedora. It means you have two places to
look when searching for packages manually, and twice as much to
configure when you're configuring yum. It has never benefitted me,
or anybody I know, but it has caught me out on any number of
occasions. What's more, nobody really seems to know why it's like
that: it seems it's always been that way, and nobody ever bother to
fix it.

So lets fix it. The package set at release time is only interesting
to historians. If any of them are really that bothered, I'm sure
somebody can come up with a yum module which finds the oldest
available version of a package in a repo.


The separate Everything tree that does not get obsoleted is required
in some form for GPL compliance, with respect to the ISO images that
we ship. Any new solution would have to preserve this.


This argument sounds weird to me. However, there no reason you can't 
keep around as many repositories as you like as long as the One True 
Repository exists and people can use it exclusively. Currently it 
doesn't exist.


Matt
--
Matthew Booth, RHCA, RHCSS
Red Hat Engineering, Virtualisation Team

M:   +44 (0)7977 267231
GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: F12 Yum/package kit bug??




On Wed, 2 Dec 2009, Nathanael D. Noblet wrote:

Over the last few days I have been unable to install updates via the package 
kit applet that pops up. I get the following output after clicking 'install 
updates'.


Error Type: class 'yum.Errors.RepoError'
Error Value: Error getting repository data for installed, repository not 
found
 File : /usr/share/PackageKit/helpers/yum/yumBackend.py, line 3125, in 
module

   main()
 File : /usr/share/PackageKit/helpers/yum/yumBackend.py, line 3122, in main
   backend.dispatcher(sys.argv[1:])
 File : /usr/lib/python2.6/site-packages/packagekit/backend.py, line 710, in 
dispatcher

   self.dispatch_command(args[0], args[1:])
 File : /usr/lib/python2.6/site-packages/packagekit/backend.py, line 657, in 
dispatch_command

   self.update_packages(only_trusted, package_ids)
 File : /usr/share/PackageKit/helpers/yum/yumBackend.py, line 1948, in 
update_packages

   signed = self._is_package_repo_signed(pkg)
 File : /usr/share/PackageKit/helpers/yum/yumBackend.py, line 1437, in 
_is_package_repo_signed

   repo = self.yumbase.repos.getRepo(pkg.repoid)
 File : /usr/lib/python2.6/site-packages/yum/repos.py, line 121, in getRepo
   'Error getting repository data for $s, repository not found' $ (repoid)


However yum update functions properly. Is this a known bug?



yes. It's in PK and I believe it's been fixed upstream.


-sv

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Proposed F13 feature: drop separate updates repository

2009-12-02 Thread Chris Adams

Once upon a time, Matthew Booth mbo...@redhat.com said:
 The separate updates directory has been a pain for as long as I've been 
 using RHL/Fedora Core/Fedora. It means you have two places to look when 
 searching for packages manually, and twice as much to configure when 
 you're configuring yum.

Are these really significant issues for a significant number of users?

Not many people go looking manually for packages, since there are many
tools to do it easier (yum, PK, repoquery, etc.).

The repos are automatically configured with fedora-release; how often
are you configuring yum?

The only time I have to care about this is if I'm writing a kickstart
file, but it is one extra line (and then I copy the same kickstart base
over and over).
-- 
Chris Adams cmad...@hiwaay.net
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Proposed F13 feature: drop separate updates repository




On Wed, 2 Dec 2009, Nicolas Mailhot wrote:


Since people are posting wishes, here is mine:

1. stop shuffling packages from directory to directory as they get
promoted/demoted from release to release


we sort of do this now with hardlinks - the problem is when  we have to 
resign the pkgs.




2. have a single authoritative URL for each package


packagedb...




3. replace static mirrors with proxy-ing of kojipkgs.fedoraproject.org
(make sure it works with web infrastructure instead of fighting it)


I don't think that would work fine with a lot of our mirrors.



4. generate indexes of the kojipkgs.fedoraproject.org tree that
represent Fedora X, Fedora X + updates, Fedora X + testing, etc.


this is intriguing but expensive on kojipkgs.

-sv

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Blocking radeonhd (was Re: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?)

2009-12-02 Thread Hans Ulrich Niedermann

On Thu, 03 Dec 2009 06:20:20 +1000
Dave Airlie airl...@redhat.com wrote:

 The big issue is with KMS on using radeonhd is like shooting yourself
 in the face. Either we need to patch radeonhd in Fedora to not start
 with KMS enabled or remove it from the distro.

I am working on such a patch to radeonhd right now.

For some reason, the necessary information on how to do that is much
easier to find now than it was back then when KMS was first introduced
to Fedora when I first tried to write one.

-- 
Hans Ulrich Niedermann

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: F12: NetworkManager-Firefox: Firefox is currently in offline mode and can't browse the Web

2009-12-02 Thread Dan Williams

On Tue, 2009-12-01 at 10:24 +, Terry Barnaby wrote:
 On 12/01/2009 07:50 AM, Dan Williams wrote:
  On Mon, 2009-11-30 at 19:52 +, Terry Barnaby wrote:
  On 11/30/2009 06:12 PM, Dan Williams wrote:
  On Mon, 2009-11-30 at 09:55 +, Terry Barnaby wrote:
  On 11/29/2009 11:30 PM, Dan Williams wrote:
  On Sat, 2009-11-28 at 09:10 +, Terry Barnaby wrote:
  On 11/28/2009 08:35 AM, Rakesh Pandit wrote:
  2009/11/28 Terry Barnaby wrote:
  If the NetworkManager service is running, but not managing the 
  current
  network connection, then Firefox starts up in offline mode.
 
  Is this a bug in NetworkManager or Firefox ?
 
 
  This is odd behaviour and needs to be fixed. I would suggest open up a
  bug against firefox. I know one can change
  toolkit.networkmanager.disable preference, but it is a PITA for our
  users. One of use cases is: Sometime network manager does not connect
  me via my CDMA usb modem (in case signal is weak), but wvdial does and
  once I switch from NM to wvdial, my firefox gets to offline mode,
  which I don't expect it to as I am connected.
 
  Ok, filed as: 542078
 
  NetworkManager is intended to control the default internet connection.
  If NetworkManager cannot control the default internet connection, then
  you may not want to use NetworkManager.
 
  In your case, you're using a mobile broadband device.  The real bug here
  is that for whatever reason, NM/MM aren't connecting your modem, and we
  should follow up on that bug instead.
 
  Dan
 
  I am not using a mobile broadband device. The network connection my 
  systems
 
  My mistake.  I guess it was Rakesh Pandit who was using a CDMA 3G
  connection.
 
  use is not just the Internet it is a local network LAN connection that 
  also
  serves the internet. Most of my systems use a local network server which
  provides NIS, /home and /data using NFS and VPN etc. I normally use the
  service network to bring up wired or wireless networking for this. 
  Fedora,
  by default, uses NetworkManager to manage all network devices though. I 
  use
  the service network as, for some reason, the NetworkManager service is
  started after the netfs and other services are started. Is there a reason
  for this ??
 
  No particular reason, in fact that looks like a bug.  NM no longer
  depends on HAL, but that dependency is still in the initscript, which
  looks like it pushes NM later than netfs.
 
  But in reality, you're looking for a dependency based initsystem which
  we don't quite yet have.  There are already scripts that kick netfs to
  mount stuff when NM brings the network up
  (/etc/NetworkManager/dispatcher.d/05-netfs), so you get asynchronous
  bootup *and* your mounts.  The rest of the system, if it requires
  something from the mounted directories, needs to be smart enough to know
  that.
 
  If you need to, you can set NETWORKWAIT=yes in /etc/sysconfig/network,
  which causes the NetworkManager initscript to block until a network
  connection is brought up, or 30 seconds have passed.
 
  I can obviously turn of the NetworkManager service, which I have done on 
  the
  desktop systems. However, I also have a few Laptops that can roam. In 
  F11 and
  before I have used the network and NetworkManager services. When the 
  laptop
  boots away from home, the network service fails and I can then use the
  NetworkManager service to connect to whatever wireless network or G3 
  network is
  available.
 
  It does seem sensible to me that the system provides applications with 
  info
  on if the network is up (not just the Internet). The NetworkManager 
  service
  seems the place to do this and it looks like the applications are 
  starting
  to use it for this purpose.
  So maybe a generic NM isNetworkUp() API call is called for ?
 
  See the other mail; the problem with a generic isUp() is that it simply
  says hey, is there a connection?  It doesn't provide enough information
  about the networking state of the system for anything to make an
  intelligent decision about anything.  It's a hey I'm connected to
  something but there's no information about *what* you're connected to;
  whether it's a secure home network, whether it's a slow 3G network,
  whether it's billed by the  minute or the hour or unlimited, etc.
 
  Dan
 
  Hi, Thanks for the info.
  I would have thought that a generic isUp() is good enough for the likes
  of Firefox and Pidgen though to decide if to start offline. Being 
  connected to a
  Network is probably all you need, you may be accessing an Intranet as all
  my systems Firefox home pages do ...
 
  Anyway, following your email (And notes in Bugzilla) I thought I'd try and
  use NM properly for my config. However I have a problem, which may be
  a bug. I have turned off the Network services and turned on NetworkManger.
  I have two main network interfaces eth0 (wired) and eth1 (Wifi), both are
  set to be managed by NM and to start at boot. I have also added
  NETWORKWAIT=yes in

Re: F12: NetworkManager-Firefox: Firefox is currently in offline mode and can't browse the Web

2009-12-02 Thread Terry Barnaby


On 12/02/2009 09:32 PM, Dan Williams wrote:

On Tue, 2009-12-01 at 10:24 +, Terry Barnaby wrote:

On 12/01/2009 07:50 AM, Dan Williams wrote:

On Mon, 2009-11-30 at 19:52 +, Terry Barnaby wrote:

On 11/30/2009 06:12 PM, Dan Williams wrote:

On Mon, 2009-11-30 at 09:55 +, Terry Barnaby wrote:

On 11/29/2009 11:30 PM, Dan Williams wrote:

On Sat, 2009-11-28 at 09:10 +, Terry Barnaby wrote:

On 11/28/2009 08:35 AM, Rakesh Pandit wrote:

2009/11/28 Terry Barnaby wrote:

If the NetworkManager service is running, but not managing the current
network connection, then Firefox starts up in offline mode.

Is this a bug in NetworkManager or Firefox ?



This is odd behaviour and needs to be fixed. I would suggest open up a
bug against firefox. I know one can change
toolkit.networkmanager.disable preference, but it is a PITA for our
users. One of use cases is: Sometime network manager does not connect
me via my CDMA usb modem (in case signal is weak), but wvdial does and
once I switch from NM to wvdial, my firefox gets to offline mode,
which I don't expect it to as I am connected.


Ok, filed as: 542078


NetworkManager is intended to control the default internet connection.
If NetworkManager cannot control the default internet connection, then
you may not want to use NetworkManager.

In your case, you're using a mobile broadband device.  The real bug here
is that for whatever reason, NM/MM aren't connecting your modem, and we
should follow up on that bug instead.

Dan


I am not using a mobile broadband device. The network connection my systems


My mistake.  I guess it was Rakesh Pandit who was using a CDMA 3G
connection.


use is not just the Internet it is a local network LAN connection that also
serves the internet. Most of my systems use a local network server which
provides NIS, /home and /data using NFS and VPN etc. I normally use the
service network to bring up wired or wireless networking for this. Fedora,
by default, uses NetworkManager to manage all network devices though. I use
the service network as, for some reason, the NetworkManager service is
started after the netfs and other services are started. Is there a reason
for this ??


No particular reason, in fact that looks like a bug.  NM no longer
depends on HAL, but that dependency is still in the initscript, which
looks like it pushes NM later than netfs.

But in reality, you're looking for a dependency based initsystem which
we don't quite yet have.  There are already scripts that kick netfs to
mount stuff when NM brings the network up
(/etc/NetworkManager/dispatcher.d/05-netfs), so you get asynchronous
bootup *and* your mounts.  The rest of the system, if it requires
something from the mounted directories, needs to be smart enough to know
that.

If you need to, you can set NETWORKWAIT=yes in /etc/sysconfig/network,
which causes the NetworkManager initscript to block until a network
connection is brought up, or 30 seconds have passed.


I can obviously turn of the NetworkManager service, which I have done on the
desktop systems. However, I also have a few Laptops that can roam. In F11 and
before I have used the network and NetworkManager services. When the laptop
boots away from home, the network service fails and I can then use the
NetworkManager service to connect to whatever wireless network or G3 network is
available.

It does seem sensible to me that the system provides applications with info
on if the network is up (not just the Internet). The NetworkManager service
seems the place to do this and it looks like the applications are starting
to use it for this purpose.
So maybe a generic NM isNetworkUp() API call is called for ?


See the other mail; the problem with a generic isUp() is that it simply
says hey, is there a connection?  It doesn't provide enough information
about the networking state of the system for anything to make an
intelligent decision about anything.  It's a hey I'm connected to
something but there's no information about *what* you're connected to;
whether it's a secure home network, whether it's a slow 3G network,
whether it's billed by the  minute or the hour or unlimited, etc.

Dan


Hi, Thanks for the info.
I would have thought that a generic isUp() is good enough for the likes
of Firefox and Pidgen though to decide if to start offline. Being connected to a
Network is probably all you need, you may be accessing an Intranet as all
my systems Firefox home pages do ...

Anyway, following your email (And notes in Bugzilla) I thought I'd try and
use NM properly for my config. However I have a problem, which may be
a bug. I have turned off the Network services and turned on NetworkManger.
I have two main network interfaces eth0 (wired) and eth1 (Wifi), both are
set to be managed by NM and to start at boot. I have also added
NETWORKWAIT=yes in /etc/sysconfig/network.

When I boot with this the network (eth1 (eth0 is disconnected)) does not
come up at boot. There is a message stating a failure on the line
where

Re: F12: NetworkManager-Firefox: Firefox is currently in offline mode and can't browse the Web

2009-12-02 Thread Bill Nottingham

Dan Williams (d...@redhat.com) said: 
  ONBOOT=yes
  BOOTPROTO=dhcp
  TYPE=Wireless
  NM_CONTROLLED=yes
  USERCTL=yes
  PEERDNS=yes
  IPV6INIT=no
  MODE=Auto
 
  This is the problem.  Auto is not a valid mode.

It's a valid mode according to the iwconfig man page. I have no idea
what cards actually support it.

Bill

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Proposed F13 feature: drop separate updates repository

2009-12-02 Thread Jesse Keating

On Wed, 2009-12-02 at 15:52 -0500, Seth Vidal wrote:
 Isn't this, eventually, what the packagedb is supposed to be able to
 do?

I gather it's a ls in a directory kind of thing, not an interface to
one tool or another kind of thing.  But I could be wrong.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating


signature.asc
Description: This is a digitally signed message part
-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Proposed F13 feature: drop separate updates repository

2009-12-02 Thread Matěj Cepl


Dne 2.12.2009 17:06, Josh Boyer napsal(a):

However, other than 'browsing manually for packages', I'm not really
sure what problem you are trying to solve by getting rid of the
updates repository.  It would seem like this has quite a bit of cost
for relatively little to no real gain?


I am usually too lazy, so I use yumdownloader anyway. So, I really don't 
see any real use case covered.


Matěj

--
http://www.ceplovi.cz/matej/, Jabber: mceplatceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC

If Patrick Henry thought that taxation without representation was
bad, he should see how bad it is with representation.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Proposed F13 feature: drop separate updates repository

(on my on tangent...)

On 12/02/2009 12:48 PM, Jesse Keating wrote:
 I hypothesize that we could place all rpms for a given release
 in a single directory (seth will hate this as he wants to split them up
 based on first letter of their name for better filesystem performance),

Ugh, first letter isn't really a great plan anyway. First (few) letters
of a hash of the filename is much better, but obviously hurts browsability. 
Next best is probably something like how a dead-tree dictionary index works;
list everything, split the list up by starting letters evenly, so the
directories (given a really unlikely hypothetical package set) are 

0/  # contains packages named 0 through 3*
4/  # 4 through 9*
a/  # a through ay*
az/ # az through bw*
bx/ # bx through cz*
da/ # da through whatever's next
...

so that every directory has about the same number of things.

-- 
Peter

I'd like to start a religion. That's where the money is.
-- L. Ron Hubbard to Lloyd Eshbach, in 1949;
quoted by Eshbach in _Over My Shoulder_.

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Proposed F13 feature: drop separate updates repository

On 12/02/2009 05:03 PM, Jesse Keating wrote:
 On Wed, 2009-12-02 at 15:52 -0500, Seth Vidal wrote:
 Isn't this, eventually, what the packagedb is supposed to be able to
 do?
 
 I gather it's a ls in a directory kind of thing, not an interface to
 one tool or another kind of thing.  But I could be wrong.

Sure, but the better optimization for this is don't do it.

-- 
Peter

I'd like to start a religion. That's where the money is.
-- L. Ron Hubbard to Lloyd Eshbach, in 1949;
quoted by Eshbach in _Over My Shoulder_.

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Proposed F13 feature: drop separate updates repository

On 12/02/2009 03:53 PM, Seth Vidal wrote:
 On Wed, 2 Dec 2009, Nicolas Mailhot wrote:
 3. replace static mirrors with proxy-ing of kojipkgs.fedoraproject.org
 (make sure it works with web infrastructure instead of fighting it)
 
 I don't think that would work fine with a lot of our mirrors.

I think it probably /could/ if we put some (relatively major) work in
on the server side to make it look like the directories it isn't. Not
that I'm endorsing such a plan.

-- 
Peter

I'd like to start a religion. That's where the money is.
-- L. Ron Hubbard to Lloyd Eshbach, in 1949;
quoted by Eshbach in _Over My Shoulder_.

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Proposed F13 feature: drop separate updates repository

On Wed, Dec 02, 2009 at 02:03:51PM -0800, Jesse Keating wrote:
 On Wed, 2009-12-02 at 15:52 -0500, Seth Vidal wrote:
  Isn't this, eventually, what the packagedb is supposed to be able to
  do?
 
 I gather it's a ls in a directory kind of thing, not an interface to
 one tool or another kind of thing.  But I could be wrong.

We're at a point where 'ls in a directory' is becoming difficult even;
you can't glob 15k package names in a shell.

find .   is your friend.

-- 
Matt Domsch
Technology Strategist, Dell Office of the CTO
linux.dell.com  www.dell.com/linux

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Proposed F13 feature: drop separate updates repository

On Wed, Dec 02, 2009 at 07:35:03PM +0100, Nicolas Mailhot wrote:
 3. replace static mirrors with proxy-ing of kojipkgs.fedoraproject.org
 (make sure it works with web infrastructure instead of fighting it)

Sorry, I don't understand this.  Can you elaborate?  That would help
me scope the impact to MirrorManager.

Thanks,
Matt

-- 
Matt Domsch
Technology Strategist, Dell Office of the CTO
linux.dell.com  www.dell.com/linux

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Proposed F13 feature: drop separate updates repository




On Wed, 2 Dec 2009, Peter Jones wrote:


(on my on tangent...)

On 12/02/2009 12:48 PM, Jesse Keating wrote:

I hypothesize that we could place all rpms for a given release
in a single directory (seth will hate this as he wants to split them up
based on first letter of their name for better filesystem performance),


Ugh, first letter isn't really a great plan anyway. First (few) letters
of a hash of the filename is much better, but obviously hurts browsability.
Next best is probably something like how a dead-tree dictionary index works;
list everything, split the list up by starting letters evenly, so the
directories (given a really unlikely hypothetical package set) are

0/  # contains packages named 0 through 3*
4/  # 4 through 9*
a/  # a through ay*
az/ # az through bw*
bx/ # bx through cz*
da/ # da through whatever's next
...

so that every directory has about the same number of things.


If you're looking for perfect division, sure - but the reality is this:

19K items in a single dir and ext3 and nfs and many many other things crap 
themselves returning that list.


If you make 36 subdirs (26+10) performance gets DRAMATICALLY better for 
producing the same list of files.


I tested it on our backend to be sure. getting the complete pkglist goes 
from taking 5 minutes to take 30s.


yes, I said 5 minutes.

-sv





--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Proposed F13 feature: drop separate updates repository

On Wed, Dec 02, 2009 at 11:09:41AM -0500, Bill Nottingham wrote:
 The separate Everything tree that does not get obsoleted is required
 in some form for GPL compliance, with respect to the ISO images that
 we ship. Any new solution would have to preserve this.

?  We provide Fedora-*-source-disc*.iso and Fedora-*-source-DVD.iso
images on the mirrors already.

-- 
Matt Domsch
Technology Strategist, Dell Office of the CTO
linux.dell.com  www.dell.com/linux

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Proposed F13 feature: drop separate updates repository




On Wed, 2 Dec 2009, Peter Jones wrote:


On 12/02/2009 03:53 PM, Seth Vidal wrote:

On Wed, 2 Dec 2009, Nicolas Mailhot wrote:

3. replace static mirrors with proxy-ing of kojipkgs.fedoraproject.org
(make sure it works with web infrastructure instead of fighting it)


I don't think that would work fine with a lot of our mirrors.


I think it probably /could/ if we put some (relatively major) work in
on the server side to make it look like the directories it isn't. Not
that I'm endorsing such a plan.


we'd have to make all our mirrors use that.

not gonna fly.

-sv

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Proposed F13 feature: drop separate updates repository

On 12/02/2009 05:58 PM, Seth Vidal wrote:
 
 
 On Wed, 2 Dec 2009, Peter Jones wrote:
 
 On 12/02/2009 03:53 PM, Seth Vidal wrote:
 On Wed, 2 Dec 2009, Nicolas Mailhot wrote:
 3. replace static mirrors with proxy-ing of kojipkgs.fedoraproject.org
 (make sure it works with web infrastructure instead of fighting it)

 I don't think that would work fine with a lot of our mirrors.

 I think it probably /could/ if we put some (relatively major) work in
 on the server side to make it look like the directories it isn't. Not
 that I'm endorsing such a plan.
 
 we'd have to make all our mirrors use that.
 
 not gonna fly.

Well, you just wouldn't get the benefits of this if you're using a mirror.

Which, yes, is pretty lame.

-- 
Peter

I'd like to start a religion. That's where the money is.
-- L. Ron Hubbard to Lloyd Eshbach, in 1949;
quoted by Eshbach in _Over My Shoulder_.

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Proposed F13 feature: drop separate updates repository

On 12/02/2009 05:58 PM, Seth Vidal wrote:
 
 
 On Wed, 2 Dec 2009, Peter Jones wrote:
 
 (on my on tangent...)

 On 12/02/2009 12:48 PM, Jesse Keating wrote:
 I hypothesize that we could place all rpms for a given release
 in a single directory (seth will hate this as he wants to split them up
 based on first letter of their name for better filesystem performance),

 Ugh, first letter isn't really a great plan anyway. First (few) letters
 of a hash of the filename is much better, but obviously hurts
 browsability.
 Next best is probably something like how a dead-tree dictionary index
 works;
 list everything, split the list up by starting letters evenly, so the
 directories (given a really unlikely hypothetical package set) are

 0/# contains packages named 0 through 3*
 4/# 4 through 9*
 a/# a through ay*
 az/# az through bw*
 bx/# bx through cz*
 da/# da through whatever's next
 ...

 so that every directory has about the same number of things.
 
 If you're looking for perfect division, sure - but the reality is this:
 
 19K items in a single dir and ext3 and nfs and many many other things
 crap themselves returning that list.
 
 If you make 36 subdirs (26+10) performance gets DRAMATICALLY better for
 producing the same list of files.
 
 I tested it on our backend to be sure. getting the complete pkglist goes
 from taking 5 minutes to take 30s.
 
 yes, I said 5 minutes.

Yeah, I buy that.

-- 
Peter

I'd like to start a religion. That's where the money is.
-- L. Ron Hubbard to Lloyd Eshbach, in 1949;
quoted by Eshbach in _Over My Shoulder_.

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Proposed F13 feature: drop separate updates repository




On Wed, 2 Dec 2009, Peter Jones wrote:


On 12/02/2009 05:58 PM, Seth Vidal wrote:



On Wed, 2 Dec 2009, Peter Jones wrote:


On 12/02/2009 03:53 PM, Seth Vidal wrote:

On Wed, 2 Dec 2009, Nicolas Mailhot wrote:

3. replace static mirrors with proxy-ing of kojipkgs.fedoraproject.org
(make sure it works with web infrastructure instead of fighting it)


I don't think that would work fine with a lot of our mirrors.


I think it probably /could/ if we put some (relatively major) work in
on the server side to make it look like the directories it isn't. Not
that I'm endorsing such a plan.


we'd have to make all our mirrors use that.

not gonna fly.


Well, you just wouldn't get the benefits of this if you're using a mirror.

Which, yes, is pretty lame.


we won't get the benefits in fedora then. Our mirror infrastructure is a 
HUGE reason why we can do what we do.


If we can't farm things out to our mirrors then we might as well go home 
b/c our users will NEVER be able to get our bits.


-sv

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Proposed F13 feature: drop separate updates repository

2009-12-02 Thread James Antill

On Wed, 2009-12-02 at 17:46 -0500, Peter Jones wrote:
 (on my on tangent...)
 
 On 12/02/2009 12:48 PM, Jesse Keating wrote:
  I hypothesize that we could place all rpms for a given release
  in a single directory (seth will hate this as he wants to split them up
  based on first letter of their name for better filesystem performance),
 
 Ugh, first letter isn't really a great plan anyway.

 It's not great but it's better than the current all in one dir. and
easy to do, and I haven't heard of any downsides (that aren't applicable
to all in one dir.).

  First (few) letters
 of a hash of the filename is much better, but obviously hurts browsability.

 Right, which is important enough to not do that IMO. I'm sure Jesse
wouldn't like finding packages to mean using find.

 Next best is probably something like how a dead-tree dictionary index works;
 list everything, split the list up by starting letters evenly, so the
 directories (given a really unlikely hypothetical package set) are 
 
 0/# contains packages named 0 through 3*
 4/# 4 through 9*
 a/# a through ay*
 az/   # az through bw*
 bx/   # bx through cz*
 da/   # da through whatever's next
 ...
 
 so that every directory has about the same number of things.

 This should be fairly easy to code, but has a big downside:

 Packages will move directories.

1. This will upset yum (old repo. MD == no packages download).
2. This might upset mirrors.
3. This will probably upset users:
i. URLs will only be safe until the next mash, they
won't even be able to bookmark prefix/y if they just
want to see yum each time.
ii. Users have to look/parse the directory layout each
time they visit to see what blah is.

-- 
James Antill - ja...@fedoraproject.org
http://yum.baseurl.org/wiki/releases
http://yum.baseurl.org/wiki/whatsnew/3.2.25
http://yum.baseurl.org/wiki/YumMultipleMachineCaching

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Proposed F13 feature: drop separate updates repository

On 12/02/2009 06:05 PM, James Antill wrote:
 On Wed, 2009-12-02 at 17:46 -0500, Peter Jones wrote:
 so that every directory has about the same number of things.
 
  This should be fairly easy to code, but has a big downside:
 
  Packages will move directories.
 
 1. This will upset yum (old repo. MD == no packages download).
 2. This might upset mirrors.
 3. This will probably upset users:
 i. URLs will only be safe until the next mash, they
 won't even be able to bookmark prefix/y if they just
 want to see yum each time.
 ii. Users have to look/parse the directory layout each
 time they visit to see what blah is.

Yeah. Seth makes a good point - first letter is such vast improvement that
we probably don't need to worry about doing better - at least for now.

-- 
Peter

I'd like to start a religion. That's where the money is.
-- L. Ron Hubbard to Lloyd Eshbach, in 1949;
quoted by Eshbach in _Over My Shoulder_.

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Proposed F13 feature: drop separate updates repository

2009-12-02 Thread Jesse Keating

On Wed, 2009-12-02 at 16:58 -0600, Matt Domsch wrote:
 On Wed, Dec 02, 2009 at 11:09:41AM -0500, Bill Nottingham wrote:
  The separate Everything tree that does not get obsoleted is required
  in some form for GPL compliance, with respect to the ISO images that
  we ship. Any new solution would have to preserve this.
 
 ?  We provide Fedora-*-source-disc*.iso and Fedora-*-source-DVD.iso
 images on the mirrors already.
 

As stated elsewhere, that doesn't carry the packages found on all the
live images we produce.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating


signature.asc
Description: This is a digitally signed message part
-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Proposed F13 feature: drop separate updates repository

On Wed, Dec 02, 2009 at 03:08:06PM -0800, Jesse Keating wrote:
 On Wed, 2009-12-02 at 16:58 -0600, Matt Domsch wrote:
  On Wed, Dec 02, 2009 at 11:09:41AM -0500, Bill Nottingham wrote:
   The separate Everything tree that does not get obsoleted is required
   in some form for GPL compliance, with respect to the ISO images that
   we ship. Any new solution would have to preserve this.
  
  ?  We provide Fedora-*-source-disc*.iso and Fedora-*-source-DVD.iso
  images on the mirrors already.
  
 
 As stated elsewhere, that doesn't carry the packages found on all the
 live images we produce.

All the more reason to put more effort into 
  http://git.fedorahosted.org/git/correspondingsource.git


-- 
Matt Domsch
Technology Strategist, Dell Office of the CTO
linux.dell.com  www.dell.com/linux

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Proposed F13 feature: drop separate updates repository

2009-12-02 Thread Bruno Wolff III

On Wed, Dec 02, 2009 at 17:58:24 -0500,
  Seth Vidal skvi...@fedoraproject.org wrote:
 
 I tested it on our backend to be sure. getting the complete pkglist
 goes from taking 5 minutes to take 30s.
 
 yes, I said 5 minutes.

Have you tried any of the tunning knobs to have the directory cache be
alotted more space or given higher priority? For example:

vfs_cache_pressure
--

Controls the tendency of the kernel to reclaim the memory which is used for
caching of directory and inode objects.

At the default value of vfs_cache_pressure=100 the kernel will attempt to
reclaim dentries and inodes at a fair rate with respect to pagecache and
swapcache reclaim.  Decreasing vfs_cache_pressure causes the kernel to prefer
to retain dentry and inode caches.  Increasing vfs_cache_pressure beyond 100
causes the kernel to prefer to reclaim dentries and inodes.

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Proposed F13 feature: drop separate updates repository




On Wed, 2 Dec 2009, Bruno Wolff III wrote:


On Wed, Dec 02, 2009 at 17:58:24 -0500,
 Seth Vidal skvi...@fedoraproject.org wrote:


I tested it on our backend to be sure. getting the complete pkglist
goes from taking 5 minutes to take 30s.

yes, I said 5 minutes.


Have you tried any of the tunning knobs to have the directory cache be
alotted more space or given higher priority? For example:

vfs_cache_pressure
--

Controls the tendency of the kernel to reclaim the memory which is used for
caching of directory and inode objects.

At the default value of vfs_cache_pressure=100 the kernel will attempt to
reclaim dentries and inodes at a fair rate with respect to pagecache and
swapcache reclaim.  Decreasing vfs_cache_pressure causes the kernel to prefer
to retain dentry and inode caches.  Increasing vfs_cache_pressure beyond 100
causes the kernel to prefer to reclaim dentries and inodes.


Not tried that - worth giving it a shot - but it still won't help the 
'holy crap there are 15K items on this webpage and it won't render' 
problem.


-sv

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Proposed F13 feature: drop separate updates repository

2009-12-02 Thread Kevin Kofler

Seth Vidal wrote:
 If you're looking for perfect division, sure - but the reality is this:
 
 19K items in a single dir and ext3 and nfs and many many other things crap
 themselves returning that list.
 
 If you make 36 subdirs (26+10) performance gets DRAMATICALLY better for
 producing the same list of files.

The problem is, a few of those starting letters still correspond to A LOT of 
packages, e.g. p* matches perl-*, python-* and php-* and that's a lot of 
stuff (especially Perl and Python). And adding python3-* (and perl6-*, or 
are we going to use the rakudo-* namespace there?) won't make it any less.

Kevin Kofler

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Proposed F13 feature: drop separate updates repository




On Thu, 3 Dec 2009, Kevin Kofler wrote:


Seth Vidal wrote:

If you're looking for perfect division, sure - but the reality is this:

19K items in a single dir and ext3 and nfs and many many other things crap
themselves returning that list.

If you make 36 subdirs (26+10) performance gets DRAMATICALLY better for
producing the same list of files.


The problem is, a few of those starting letters still correspond to A LOT of
packages, e.g. p* matches perl-*, python-* and php-* and that's a lot of
stuff (especially Perl and Python). And adding python3-* (and perl6-*, or
are we going to use the rakudo-* namespace there?) won't make it any less.




And yet, when tested, just making those 36 subdirs made a HUGE difference.

What I've found is getting any one dir down below 3K entries makes things 
faster, by a lot.


-sv

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Proposed F13 feature: drop separate updates repository

On Wed, Dec 02, 2009 at 12:01:49PM -0500, Casey Dahlin wrote:

You owe me $5.

It hasn't been a week and you haven't sent me your address.
I did notice though, so keep up the good work ;)

josh

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Proposed F13 feature: drop separate updates repository

2009-12-02 Thread Mike McGrath

On Wed, 2 Dec 2009, Bruno Wolff III wrote:

 On Wed, Dec 02, 2009 at 17:58:24 -0500,
   Seth Vidal skvi...@fedoraproject.org wrote:
 
  I tested it on our backend to be sure. getting the complete pkglist
  goes from taking 5 minutes to take 30s.
 
  yes, I said 5 minutes.

 Have you tried any of the tunning knobs to have the directory cache be
 alotted more space or given higher priority? For example:

 vfs_cache_pressure
 --

 Controls the tendency of the kernel to reclaim the memory which is used for
 caching of directory and inode objects.

 At the default value of vfs_cache_pressure=100 the kernel will attempt to
 reclaim dentries and inodes at a fair rate with respect to pagecache and
 swapcache reclaim.  Decreasing vfs_cache_pressure causes the kernel to prefer
 to retain dentry and inode caches.  Increasing vfs_cache_pressure beyond 100
 causes the kernel to prefer to reclaim dentries and inodes.


We have experimented with this for the purposes of rsync on our mirrors
but haven't experimented for this specific issue.

-Mike

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Proposed F13 feature: drop separate updates repository

On 12/02/2009 06:40 PM, Jesse Keating wrote:

On Wed, 2009-12-02 at 18:09 +0100, Ralf Corsepius wrote:

* It shifts costs from users to vendor
and from mirrors to master.
* It helps users who are using networked installs to spare bandwidth
(avoids downloading obsolete packages from Everything/Fedora).

Admitted, for most users, it would change almost nothing.

People doing network installs can either add the updates repo to their
kickstart, or check the box in the anaconda UI, so that the updates
repos are considered at install time. No download of duplicate data.
Yes, for people who are doing full featured networked installs w/
custom kickstart files. I've never met such a person.

In fact, having separate repos would likely cost less bandwidth. If we
only had one combined repo, there would be many duplicate packages,
Where? Unlike now, where you have each package twice (in Everything and
updates), you would have each package only once: In Everything.

It would help people like me, who are locally reusing downloaded
packages in a networked environment, instead of letting each machine
accesses the original repos directly.

especially if we went the route of having updates-testing mixed in and
only marked by some update tag.

Updates-testing is an add-on repo to Everything+updates.

A merged new Everything would not change anything wrt.
updates-testing. The only difference would be packages being pushed to
Everything instead of updates.

We'd have to keep sets of what's in
updates-testing, updates, and the GA release set, and all of that would
be in one repodata set. Everybody doing a network install, whether they
wanted updates, updates-testing, or not would have to download and
consume that larger repodata, introducing a higher cost for them.

Your concern is the bigger repodata?

Reality check:
# ls -h -s releases/11/Everything/x86_64/os/repodata/*.sqlite.bz2
updates/11/x86_64/repodata/*.sqlite.bz2

16M
releases/11/Everything/x86_64/os/repodata/0301ed1cbf01c00cdf9c42b71df6c74947d9c76a3c9767e8f85a99ef6fdccb86-filelists.sqlite.bz2
11M
releases/11/Everything/x86_64/os/repodata/6a8bfab8ebcbc79f9827f5b16bc1bd1573c068f141bf47c6f216e72dd8b60ff0-primary.sqlite.bz2
5.8M
releases/11/Everything/x86_64/os/repodata/d3405c970a0c27e9dc3fd3ed179af33fee9a72bf704f45f1ed96a9063b40d7c7-other.sqlite.bz2

9.0M
updates/11/x86_64/repodata/3a725e07adff9d7e56e7fd8bd3091f38107723987b3b614220df72494dc6814d-filelists.sqlite.bz2
6.0M
updates/11/x86_64/repodata/54ca116c2a00e87eaca6491adb9e077f4d3f0d5b20e7cbab984774aefb042d0f-primary.sqlite.bz2
3.2M
updates/11/x86_64/repodata/646eb24cfe113de569853a4e05f55773b3ad9531dee646e7d843b8dc4a849780-other.sqlite.bz2

= An estimate for the increase in downloaded files's sizes you are
talking about is ca. factor 2, from 18.2M (current updates)

to 32.8M+ (current Everything+newly introduced packages)

Whether this increase in download-size is significant is up to the
beholder. For me, it gets lost in the noise of accessing a good or a
bad connection to a mirror and in the time required to download
packages from mirrors.

On the other hand, the content (the packages referenced inside) of
updates overlaps with packages in Everything
= The number of packages to be considered in dep-computation should
become much (?) smaller. However, I am not knowledgable enough with
yum's internals to estimate the impact this would have on
turnaround-times, memory and diskspace requirements this would have on yum.

Ralf

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Proposed F13 feature: drop separate updates repository


On 12/02/2009 07:09 PM, Seth Vidal wrote:


the merger of repos is already happening at the yum layer.


On the client's side - With a combined Everything+updates, this would 
happen on the server side.


It's one of the aspects which made me said a combined 
Everything+updates shifts costs from client to server.


Ralf

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Proposed F13 feature: drop separate updates repository




On Thu, 3 Dec 2009, Ralf Corsepius wrote:


On 12/02/2009 07:09 PM, Seth Vidal wrote:


the merger of repos is already happening at the yum layer.


On the client's side - With a combined Everything+updates, this would happen 
on the server side.


It's one of the aspects which made me said a combined Everything+updates 
shifts costs from client to server.


except they wouldn't be merged on the server side -it would just be 
additive.



We wouldn't be talking about removing the original GA set - just adding 
updated pkgs into the path. So you'd still have the number of pkgs -just 
all in one repo, that you have to download all of the metadata for all of 
the more often, despite that 15K of them don't CHANGE.


this is why it is less good for our users.

-sv

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Proposed F13 feature: drop separate updates repository


On 12/03/2009 06:32 AM, Seth Vidal wrote:



On Thu, 3 Dec 2009, Ralf Corsepius wrote:


On 12/02/2009 07:09 PM, Seth Vidal wrote:


the merger of repos is already happening at the yum layer.


On the client's side - With a combined Everything+updates, this would
happen on the server side.

It's one of the aspects which made me said a combined
Everything+updates shifts costs from client to server.


except they wouldn't be merged on the server side -it would just be
additive.


We wouldn't be talking about removing the original GA set - just adding
updated pkgs into the path.


Woa!!! With all due respect, but this would seem an stupid and silly 
plan to me.



So you'd still have the number of pkgs -just
all in one repo, that you have to download all of the metadata for all
of the more often, despite that 15K of them don't CHANGE.

this is why it is less good for our users.


Yes - cf. above. I have nothing to add.

Ralf


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Proposed F13 feature: drop separate updates repository

2009-12-02 Thread shmuel siegel


Ralf Corsepius wrote:

Your concern is the bigger repodata?

My download of repodata towards the end of a release, or from rawhide, 
is usually bigger than my download of packages. So yes, this would make 
a difference. On the otherhand, there probably could be a repodiff that 
would alleviate a lot of this problem.


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Bug 540340] [patch] Update Finance::Quote to fix ASX quotes

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=540340





--- Comment #6 from Fedora Update System upda...@fedoraproject.org  
2009-12-03 00:08:52 EDT ---
perl-Finance-Quote-1.17-1.fc12 has been pushed to the Fedora 12 stable
repository.  If problems still persist, please make note of it in this bug
report.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list

[Bug 540340] [patch] Update Finance::Quote to fix ASX quotes

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=540340


Fedora Update System upda...@fedoraproject.org changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||1.17-1.fc12
 Resolution||ERRATA




-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list

[Bug 533734] Can we have perl-XML-LibXSLT for EPEL - EL5

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=533734


Marcela Mašláňová mmasl...@redhat.com changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
 Resolution||CURRENTRELEASE




--- Comment #6 from Marcela Mašláňová mmasl...@redhat.com  2009-12-03 
02:07:57 EDT ---
perl-XML-LibXSLT-1.58-5.el5

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list

[Bug 539174] FTBFS perl-XML-LibXSLT-1.68-4.fc12