On Sun, Apr 14, 2013 at 12:31 PM, Richard Hughes hughsi...@gmail.comwrote:
On 13 April 2013 23:09, Kevin Kofler kevin.kof...@chello.at wrote:
Sure you can! It's a basic rule of QA that small isolated changes can be
debugged much better than a huge hodgepodge of many totally unrelated
On 13 April 2013 23:09, Kevin Kofler kevin.kof...@chello.at wrote:
Sure you can! It's a basic rule of QA that small isolated changes can be
debugged much better than a huge hodgepodge of many totally unrelated
changes.
Not true for the majority of GNOME and KDE packages. You can't test
On Wed, Apr 10, 2013 at 5:24 PM, Reindl Harald h.rei...@thelounge.net wrote:
but Fedora IS NOT RHEL
if you want the RHEL way use it
WHO ARE YOU KIDDING?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Richard Hughes wrote:
Not true for the majority of GNOME and KDE packages. You can't test
gnome-control-center 3.9.1 without installing gnome-settings-daemon
3.9.1 as well. Not because of any library interface issue, but because
g-s-d provides the D-Bus API used by g-c-c. The desktop, like it
Am 14.04.2013 12:51, schrieb Dan Mashal:
On Wed, Apr 10, 2013 at 5:24 PM, Reindl Harald h.rei...@thelounge.net wrote:
but Fedora IS NOT RHEL
if you want the RHEL way use it
WHO ARE YOU KIDDING?
??
if someone aks for a monthly patchday for Fedora
instead push updates after bugs are fixed
On Sun, 14 Apr 2013 12:59:06 +0200
Reindl Harald h.rei...@thelounge.net wrote:
if someone aks for a monthly patchday for Fedora
instead push updates after bugs are fixed who is
kidding there?
I don't think anyone actually was asking for that. The proposal around
monthly update packs includes
Richard Hughes wrote:
Using PackageKit and yum on the command line is often painful as we
have to always download metadata unless it's less than a few hours
old. Being able to update the metadata once a week would be awesome
(with the possible exception of security updates) so that we could
Richard Hughes wrote:
You can't QA a trickle.
Sure you can! It's a basic rule of QA that small isolated changes can be
debugged much better than a huge hodgepodge of many totally unrelated
changes.
If packages are small and self-contained then sure, it might work, but
applications depending
Matthew Miller wrote:
Overall, it's a more predictable workload, which *is* a good idea, for
both volunteer and otherwise.
No, sorry, but as volunteers, we have other commitments which mean we cannot
always do our Fedora work when some central Fedora schedule dictates it. The
mad rushes at
Am 14.04.2013 00:03, schrieb Kevin Kofler:
Richard Hughes wrote:
Using PackageKit and yum on the command line is often painful as we
have to always download metadata unless it's less than a few hours
old. Being able to update the metadata once a week would be awesome
(with the possible
7 days is way, way, way too long for an active repository such as any of
the currently supported Fedoras. And yes, it *is* burdensome to download
and keep updating all the time.
If running more than a few servers, I always maintain a local nightly
mirror and point my clients to that by default.
On 9. 4. 2013 at 12:25:56, seth vidal wrote:
On Tue, 9 Apr 2013 11:18:54 -0500
Bruno Wolff III br...@wolff.to wrote:
On Wed, Apr 10, 2013 at 00:05:45 +0800,
Mathieu Bridon boche...@fedoraproject.org wrote:
The current behaviour would be obtained by setting it to 1, and
setting it
Dne 9.4.2013 18:14, Simo Sorce napsal(a):
On Tue, 2013-04-09 at 17:16 +0200, Hans de Goede wrote:
Hi,
Am 09.04.2013 14:27, schrieb Matthew Miller:
On Tue, Apr 09, 2013 at 10:10:26AM +0100, Richard Hughes wrote:
I'm wondering what the interest would be in keeping packages
referenced in
On Wed, Apr 10, 2013 at 09:24:49 +0200,
Jan Zelený jzel...@redhat.com wrote:
I'm not sure this solves the initial problem - downloading new metadata every
6 hours or so ...
Does the metadata really need to be downloaded or just checked to see if
it is current?
--
devel mailing list
Am 10.04.2013 15:47, schrieb Bruno Wolff III:
On Wed, Apr 10, 2013 at 09:24:49 +0200,
Jan Zelený jzel...@redhat.com wrote:
I'm not sure this solves the initial problem - downloading new metadata every
6 hours or so ...
Does the metadata really need to be downloaded or just checked to
On Wed, 10 Apr 2013 09:24:49 +0200
Jan Zelený jzel...@redhat.com wrote:
On 9. 4. 2013 at 12:25:56, seth vidal wrote:
On Tue, 9 Apr 2013 11:18:54 -0500
Bruno Wolff III br...@wolff.to wrote:
On Wed, Apr 10, 2013 at 00:05:45 +0800,
Mathieu Bridon boche...@fedoraproject.org
On Wed, 10 Apr 2013 08:47:38 -0500
Bruno Wolff III br...@wolff.to wrote:
On Wed, Apr 10, 2013 at 09:24:49 +0200,
Jan Zelený jzel...@redhat.com wrote:
I'm not sure this solves the initial problem - downloading new
metadata every 6 hours or so ...
Does the metadata really need to be
From: seth vidal skvi...@fedoraproject.org
The metadata doesn't get downloaded if it hasn't changed - the problem
though is that the metadata DOES change often. Normally everyday.
Is there anything that could be done to make it unnecessary to pull the
complete metadata for every update?
On Wed, 10 Apr 2013 10:53:25 -0400
john.flor...@dart.biz wrote:
From: seth vidal skvi...@fedoraproject.org
The metadata doesn't get downloaded if it hasn't changed - the
problem though is that the metadata DOES change often. Normally
everyday.
Is there anything that could be done to
Mathieu Bridon (boche...@fedoraproject.org) said:
On Tuesday, April 09, 2013 11:52 PM, Bill Nottingham wrote:
If you wanted to keep more versions on the mirrors, you have the following
options:
1) Have mash create everything, and then run a script that prunes versions
older than X, and
On 10. 4. 2013 at 10:53:25, john.flor...@dart.biz wrote:
From: seth vidal skvi...@fedoraproject.org
The metadata doesn't get downloaded if it hasn't changed - the problem
though is that the metadata DOES change often. Normally everyday.
Is there anything that could be done to make it
Once upon a time, john.flor...@dart.biz john.flor...@dart.biz said:
Is there anything that could be done to make it unnecessary to pull the
complete metadata for every update? For example, IIRC this is all sqlite
data, but what if this was in a plain-text data dump form where something
From: Chris Adams cmad...@hiwaay.net
The metadata starts in XML before being loaded into an SQLite DB file,
and the XML is in the repodata directory with the DB. However, both are
compressed, as they are large. For example, the current
updates/18/x86_64 XML is over 34M (5M gzip compressed),
On Wed, 10 Apr 2013 12:24:58 -0400
john.flor...@dart.biz wrote:
I was thinking there had been some xz integration recently. Maybe
that was with the delta rpm support. I don't follow that though
since we have a local mirror, there's not much point in rsycing,
storing, etc. the deltas.
On Wed, 10 Apr 2013 10:33:43 -0500
Chris Adams cmad...@hiwaay.net wrote:
The metadata starts in XML before being loaded into an SQLite DB file,
and the XML is in the repodata directory with the DB. However, both
are compressed, as they are large. For example, the current
updates/18/x86_64
On Wed, 10 Apr 2013 12:24:58 -0400
john.flor...@dart.biz wrote:
I was thinking there had been some xz integration recently. Maybe
that was with the delta rpm support. I don't follow that though
since we have a local mirror, there's not much point in rsycing,
storing, etc. the deltas.
Am 09.04.2013 17:02, schrieb Richard Hughes:
On 9 April 2013 13:48, Reindl Harald h.rei...@thelounge.net wrote:
if i want monthly pacthdays i use Microsoft or Oracle
Not at all. Patchdays make perfect sense for planning
reboots/downtime/maintenance and that kind of thing.
there where i
On 9 April 2013 10:21, Reindl Harald h.rei...@thelounge.net wrote:
metadata_expire=7d
From a package manager point of view, this happens:
1 check expire timeout, all okay
2 depsolve update set
3 download
4 package not found!
5 download needed metadata based on some heuristic
6 goto 2
Richard
On Tue, Apr 09, 2013 at 10:10:26AM +0100, Richard Hughes wrote:
I'm wondering what the interest would be in keeping packages
referenced in metadata on the mirrors for say a month? We'd probably
need a separate fedora-security repo too that's designed to be kept
small enough so that metadata
On Tue, Apr 09, 2013 at 02:48:40PM +0200, Reindl Harald wrote:
depends often on the workload and currect jobs and the cirtical
apllication wheer a bug will hurt you much may change from project
to project
As I understand it, you'll be able to opt for an all-updates track. In fact,
that will be
Am 09.04.2013 11:10, schrieb Richard Hughes:
Using PackageKit and yum on the command line is often painful as we
have to always download metadata unless it's less than a few hours
old. Being able to update the metadata once a week would be awesome
(with the possible exception of security
Am 09.04.2013 14:27, schrieb Matthew Miller:
On Tue, Apr 09, 2013 at 10:10:26AM +0100, Richard Hughes wrote:
I'm wondering what the interest would be in keeping packages
referenced in metadata on the mirrors for say a month? We'd probably
need a separate fedora-security repo too that's
On 9 April 2013 13:48, Reindl Harald h.rei...@thelounge.net wrote:
if i want monthly pacthdays i use Microsoft or Oracle
Not at all. Patchdays make perfect sense for planning
reboots/downtime/maintenance and that kind of thing.
you can hardly classify which bug is for which user critical!
Hi,
Am 09.04.2013 14:27, schrieb Matthew Miller:
On Tue, Apr 09, 2013 at 10:10:26AM +0100, Richard Hughes wrote:
I'm wondering what the interest would be in keeping packages
referenced in metadata on the mirrors for say a month? We'd probably
need a separate fedora-security repo too that's
On 9 April 2013 16:16, Hans de Goede hdego...@redhat.com wrote:
them new packages after upstream bug-fix releases. Lumping these all
together in a single day in the month just does not feel like a Fedora thing
to do.
You can't QA a trickle. If packages are small and self-contained then
sure,
Richard Hughes (hughsi...@gmail.com) said:
Using PackageKit and yum on the command line is often painful as we
have to always download metadata unless it's less than a few hours
old. Being able to update the metadata once a week would be awesome
(with the possible exception of security
On Tuesday, April 09, 2013 11:52 PM, Bill Nottingham wrote:
If you wanted to keep more versions on the mirrors, you have the following
options:
1) Have mash create everything, and then run a script that prunes versions
older than X, and re-runs createrepo.
[... snip ...]
2) Have mash try and
On Tue, Apr 09, 2013 at 05:16:45PM +0200, Hans de Goede wrote:
I've heard of a plan in development about batching non-critical updates into
monthly sets. It seems like these two things could go together
I'm sorry, but that is a very bad idea. When users report bugs, and I mean
real bugs here,
On Tue, 2013-04-09 at 17:16 +0200, Hans de Goede wrote:
Hi,
Am 09.04.2013 14:27, schrieb Matthew Miller:
On Tue, Apr 09, 2013 at 10:10:26AM +0100, Richard Hughes wrote:
I'm wondering what the interest would be in keeping packages
referenced in metadata on the mirrors for say a month?
On Wed, Apr 10, 2013 at 00:05:45 +0800,
Mathieu Bridon boche...@fedoraproject.org wrote:
The current behaviour would be obtained by setting it to 1, and
setting it to 2 would already be a positive change as it would allow
downgrading a package if the update went wrong.
I don't think that is
On Wednesday, April 10, 2013 12:09 AM, Matthew Miller wrote:
On Tue, Apr 09, 2013 at 05:16:45PM +0200, Hans de Goede wrote:
I've heard of a plan in development about batching non-critical updates into
monthly sets. It seems like these two things could go together
I'm sorry, but that is a very
On Tue, 9 Apr 2013 11:18:54 -0500
Bruno Wolff III br...@wolff.to wrote:
On Wed, Apr 10, 2013 at 00:05:45 +0800,
Mathieu Bridon boche...@fedoraproject.org wrote:
The current behaviour would be obtained by setting it to 1, and
setting it to 2 would already be a positive change as it would
Once upon a time, Bill Nottingham nott...@redhat.com said:
So, needless to say, I'd suggest anyone interested in this to look at option
#3. Note that enabling something like that on rawhide would have a large
effect on the repository creation time - there's only so many ways to speed
up
On Tuesday 09 April 2013 16:02:14 Richard Hughes wrote:
now for F18 are really not important at all. Spec file fixups, new
versions without bugfixes, updated artwork; that can all wait until a
certain point in the month.
Security-critical updates are already tagged as such, aren't they? So
44 matches
Mail list logo
