On Thu, 2010-01-07 at 04:44 -0500, Jens Petersen wrote:
In F12 we shipped yum-presto in @gnome-desktop - a kind of a compromise I
guess.
Presto/deltarpm is very useful for machines with low net connectivity to
mirrors
but enough resources to rebuild rpms.
But yum-presto is not a desktop
On Thu, 2010-01-07 at 20:44 +0200, Pekka Pietikainen wrote:
Presto is one of the best things ever, but occasionally it ends up not
finding the delta files from any of the mirrors in the mirror list and just
loops through them without making any progress. --disablepresto works
a-ok, I think
On Wed, 2009-12-16 at 14:06 +, Andy Green wrote:
Hi -
Is yum-presto known to work on arm? Today I changed our repo to use
deltarpms and tested it out. I noticed...
1) On a package where I know the bulk of the unpacked data is some fonts
inside an ELF executable that didn't change,
On Fri, 2009-11-20 at 20:02 -0600, Chris Adams wrote:
Once upon a time, Kevin Kofler kevin.kof...@chello.at said:
1. Needs GRUB hackery to support transparently. (For the DVD, Anaconda can
detect the architecture and install a kernel accordingly, but for a live
CD,
we don't have any
On Sun, 2009-11-22 at 00:52 -0500, Bill McGonigle wrote:
On 11/21/2009 03:52 AM, Jonathan Dieter wrote:
FWIW, there is a syslinux module named ifcpu64 that will load different
kernels/initrds based on whether the cpu is 64-bit.
Cool, do syslinux modules work in isolinux? We could have
On Thu, 2009-11-19 at 11:45 +, Richard Hughes wrote:
Surely if you're deploying a workstation (1000s of workstations?) you
would just ship an extra package that set the PolicyKit policies
according to the domain policy, so if I was a school, I would allow
the active users to unplug
A few days ago, I built deltarpm-3.4-18.fc11 which resplit off a
subpackage that had accidentally been merged into the main package in
deltarpm-3.4-17.fc11. I pushed -18 into -testing, and assumed (since it
was newer than -17) that -17 wouldn't get pushed to stable
automatically.
Now I've just
On Thu, 2009-10-08 at 07:44 -0700, Toshio Kuratomi wrote:
This is partially my fault -- my network connection hasn't been good for the
last day so instead of clearing with you which Fedora releases had the new
package, I just looked quickly at bodhi and didn't see any obsoletes so I
requested
I've just built deltarpm-3.4-18.fc11 and pushed it to testing, because
during the security fix in 3.4-17 (which is still in testing), we
accidentally undid the split of drpmsync into a separate subpackage.
I noticed that bodhi has an id (FEDORA-2009-10237) for 3.4-17. Is there
some way to push
On Mon, 2009-10-05 at 08:07 -0400, Josh Boyer wrote:
I noticed that bodhi has an id (FEDORA-2009-10237) for 3.4-17. Is there
some way to push that to 3.4-18?
3.4-18 will get it's own update id when it is pushed.
Ok, thanks.
Jonathan
signature.asc
Description: This is a digitally signed
On Thu, 2009-10-01 at 04:46 -0400, Simo Sorce wrote:
But we also need to reasonable, and unless someone volunteers to do the
actual work *without* breaking the tool in the process, I think a policy
like this need to be evaluated case by case and not just blindly and
rigidly enforced.
And, in
On Wed, 2009-09-23 at 10:49 +0200, drago01 wrote:
On Wed, Sep 23, 2009 at 10:51 AM, Michal Schmidt mschm...@redhat.com wrote:
Dne Wed, 23 Sep 2009 07:04:23 +0300 Jonathan Dieter napsal(a):
https://bugzilla.redhat.com/show_bug.cgi?id=524720
https://bugzilla.redhat.com/show_bug.cgi?id=524982
On Thu, 2009-09-24 at 00:46 -0400, James Antill wrote:
On Wed, 2009-09-23 at 17:22 +0200, Till Maas wrote:
This is all under the assumption, that delta rpm creation from a xz
compressed rpm to a gzip compressed rpm works.
Yeh, I don't know the answer to that. I'd _guess_ that it would
On Mon, Sep 14, 2009 at 1:35 PM, Dave Airlie airl...@redhat.com wrote:
On Sun, 2009-09-13 at 19:43 +0300, Jonathan Dieter wrote:
Deltarpm seems to be unable to generate correct rpms for deltarpms
generated from noarch rpms. The uncompressed payload is correct, but
the compressed xz payload
On Mon, 2009-09-14 at 09:25 -0400, Ben Boeckel wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dave Airlie wrote:
snip
[airl...@pegasus ~]$ md5sum lm93_busted.o
d7174fc439c4678927725d06de4f18a2 lm93_busted.o
[airl...@pegasus ~]$ xz -z -c lm93_busted.o | md5sum
On Mon, 2009-09-14 at 12:30 -0400, Bill Nottingham wrote:
Andreas Schwab (sch...@redhat.com) said:
2. xz generates different compressed files when run on different
architectures
The problem is that the encoder uses different hash functions depending
on the endianess. The hash
On Mon, 2009-09-14 at 12:30 -0400, Bill Nottingham wrote:
Andreas Schwab (sch...@redhat.com) said:
2. xz generates different compressed files when run on different
architectures
The problem is that the encoder uses different hash functions depending
on the endianess. The hash
On Mon, 2009-09-14 at 20:25 +0300, Jonathan Dieter wrote:
Ok, I've just had a conversation on IRC with Lasse Collin, the
maintainer of xz. He's now planning on changing xz so it will produce
the same output independent of endianess. He hasn't committed to any
timeframe, though.
snip
Sorry
On Mon, 2009-09-14 at 13:39 -0400, Bill Nottingham wrote:
Jonathan Dieter (jdie...@gmail.com) said:
He did bring up some other very good points, though. Xz's compression
output hasn't been set in sand, much less stone. The file format will
stay the same, but the same command-line options
On Mon, 2009-09-14 at 14:34 -0400, Bill Nottingham wrote:
Jonathan Dieter (jdie...@gmail.com) said:
... in what way does he mean this? Obviously passing -1 ... -9 causes
different output, much like it does in gzip/bzip2/etc.
He means that the file generated using -5 in the future may
On Mon, 2009-09-14 at 15:43 -0400, James Antill wrote:
On Mon, 2009-09-14 at 20:29 +0300, Jonathan Dieter wrote:
On Mon, 2009-09-14 at 20:25 +0300, Jonathan Dieter wrote:
Ok, I've just had a conversation on IRC with Lasse Collin, the
maintainer of xz. He's now planning on changing xz so
On Mon, 2009-09-14 at 22:25 +0200, Kevin Kofler wrote:
Jonathan Dieter wrote:
So, to summarize, architecture-specific deltarpms are working perfectly
in rawhide right now, and, if you're running a PPC machine, all
deltarpms are working perfectly.
I don't know at what stage the deltarpms
On Fri, 2009-07-31 at 14:17 -0700, Toshio Kuratomi wrote:
On 07/31/2009 01:48 PM, Josh Boyer wrote:
We don't complain about no public source repo. See deltarpm. It's repo
consists of the tarball we use already. It doesn't even have an easily
findable project website.
We're supposed
On Tue, 2009-07-14 at 10:58 -0700, Jesse Keating wrote:
Unblocked orphan tremulous-data
Shouldn't this be owned by whoever owns tremulous? It's the data files
for the game.
Jonathan
signature.asc
Description: This is a digitally signed message part
--
fedora-devel-list mailing list
On Sat, 2009-06-20 at 08:04 -0400, Josh Boyer wrote:
On Sat, Jun 20, 2009 at 01:49:14PM +0300, Jonathan Dieter wrote:
On Sat, 2009-06-20 at 14:08 +1000, Bradley Baetz wrote:
Hi,
Running F11 (x86_64), I've noticed that not all updates have deltarpms
built for them. It looks like
On Tue, 2009-06-16 at 11:42 -0400, Bill Nottingham wrote:
Chris Adams (cmad...@hiwaay.net) said:
Removing support for still-functional hardware is a trademark of
Microsoft, not Linux.
I'd also argue that doing another full rebuild of the OS for a 1%
performance gain on a single
On Sun, 2009-06-07 at 17:49 +0200, Jos Vos wrote:
The laptop has 3 GB of memory, which should be ok, I hope.
I see in /root/install.log on the installed / partition that the last
line says *** FINISHED INSTALLING PACKAGES ***.
I think I should redo the install and keep an eye on it...
27 matches
Mail list logo
