Re: yum-presto and comps
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 package at all and certainly does not belong in the gnome-desktop group. Perhaps the right approach for f13 is to install yum-presto by default but to disable it by default? It looks like there are a couple of questions to deal with: 1) yum-presto is in @gnome-desktop and shouldn't be 2) yum-presto is enabled by default If we don't want (2), then remove it from @gnome-desktop. People who need/want it can install it using yum install yum-presto, and it will start working immediately. If we do want (2), then we just need to work out how to fix (1). If not @gnome-desktop (which is probably not where it belongs), then possibly @base? FWIW, my opinion on (2) (as the yum-presto maintainer) is that it should be installed by default, but I'm obviously biased. Lighter compression might also help to reduce the resource requirements for older machines? IIRC we've already reduced the xz compression level in our rpms from 7 to 2. (See http://osdir.com/ml/fedora-devel-list/2009-09/msg00946.html) Jonathan 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: yum-presto occasionally goes into eternal loop looking for deltas
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 yum clean all; yum update also did the trick once. Still, this can probably be made a lot better. It shouldn't do that even if the mirrors are out-of-sync. Maybe add some logic that just disables presto if the deltas are nowhere to be found after a few attempts? Anyone else even see this happen? Yeah, see https://bugzilla.redhat.com/show_bug.cgi?id=540140. To summarize, the problem is that new updates have been pushed to the server between the time you loaded primary.sqlite and prestodelta.xml. When you run 'yum clean metadata' or 'yum clean all' it removes the outdated cached primary.sqlite and downloads the newer version. The bug has been closed as WONTFIX because there have only been a few reports; I wouldn't mind revisiting that decision if someone has a clever way of fixing it. (And I'm not convinced that checking n mirrors and then giving up is the solution.) Jonathan 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: yum-presto behaviour on arm
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, the compression result was... not good Old RPM: 25424385 txtr-reader-0.1-417.fc11.armv5tel.rpm New RPM: 25465487 txtr-reader-0.1-420.fc11.armv5tel.rpm Delta RPM: 25465402 txtr-reader-0.1-417.fc11_0.1-420.fc11.armv5tel.drpm So it saved me 85 bytes from 25MByte :-) The actual procedure here is the createrepo is run on an x86_64 box over these arm packages and then rsync'd on a server. 2) Using deltarpms fails snip Any advice welcomed, it would be great to reduce this 25MByte package down since the vast bulk of it is exactly the same each time :-) -Andy If you can get me ssh access to an arm machine, I'll look into both of these problems. Please also open a bug against deltarpm (otherwise, I'll totally forget about this). Jonathan 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: Promoting i386 version over x86_64?
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 such support.) That would be SYSLINUX hackery, not GRUB hackery. The CD and DVD images use ISOLINUX to boot. SYSLINUX has a module interface; I don't know if it could handle a quick check for the lm CPU capability and choose a different menu file or not. FWIW, there is a syslinux module named ifcpu64 that will load different kernels/initrds based on whether the cpu is 64-bit. I use it in pxelinux at our school so our 64-bit Fedora image automatically gets installed on the systems that can support it, while our 32-bit Fedora image gets installed on the rest. Jonathan 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: Promoting i386 version over x86_64?
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 a tiny 32-bit image on a 64-bit CD that would say, sorry, you got the wrong CD. They should; it's all the same project. I think the the 64-bit kernel already gives a sane error message when you attempt to run it on a 32-bit machine. Jonathan 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: Security policy oversight needed?
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 removable drives, but not detach physical drives. I would also stop them installing and upgrading (not even give them the option to enter a root password) and also lock down who can change the clock. I would also prevent them from installing debuginfo files and being able to set thier audio system to real-time priority. FWIW, what I set up for our school's Fedora 11 workstations is here: http://jdieter.fedorapeople.org/lesbg-polkit-setup-client.spec There are definitely some ways I could clean it up, but it at least keeps me from having students installing software (or running updates) without permission. Jonathan 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
Package updates not replaced by newer package in -testing
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 received an email from koji saying that -17 has been pushed to updates from updates-testing. I've just pushed -18 into updates, but is there any way to avoid a one or two day delay where -17 makes it into updates before -18 does? Jonathan 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: Package updates not replaced by newer package in -testing
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 it be pushed to stable. I now remember that obsoletes had to be disabled in bodhi due to other bugs :-( so that didn't clue me in. Sorry, mea culpa. rel-eng can unpush packages -- but it might be better if they could just push the new set with the fixed deltarpm instead. No problem, I'll open a ticket for the new version to be pushed. I should have communicated that I'd pushed a new version to testing. Thanks again for your work, Jonathan 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
bodhi question
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 that to 3.4-18? Jonathan 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: bodhi question
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 message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: status of forked zlibs in rsync and zsync
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 that vein, I'd like to say a huge thank you to Toshio for fixing deltarpm to use the system zlib library *without* breaking it (at least as far as my testing has gone). It is hugely appreciated! Jonathan 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: yum-presto not on by default
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 ... The second one has to do with the fact that when rebuilding the rpms, we have to recompress the data, and xz compression is over 10x slower than gzip. Do I understand it right that yum-presto compresses the data and then passes them to rpm which decompresses them back again? Why? Is it because it's currently the only way to verify checksums/signatures? We had a IRC discussion about this yesterday ... it is not yum-presto but delta rpm and it does not make sense at all. It should just create uncompressed rpms (assuming rpm can handle them which it should) ...according to Seth yum does not care whether the rpms are compressed or not. So yes the compression is a useless step here. As I think may have been mentioned elsewhere, the *only* problem is that the rpm signatures must match and the signatures are over the *compressed* rpm. I would *love* to see deltarpm rebuilding uncompressed rpms, but that will require storing two signatures per rpm in the metadata (compressed and uncompressed sha256), and either modifying yum to check the appropriate one, or deltarpm to change the rpm's signature to the uncompressed one. I don't think we want to go down the road of having deltarpm-rebuilt rpms not having their signature checked at all. Jonathan 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: yum-presto not on by default
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 work, but someone needs to try it. Tried it and it works correctly for both directions (old rpm gzip, new rpm xz and vice versa). This would mean that drpms on rawhide will still suck upto F12, but I could live with that :). I assume we don't do F11 = F12 drpms? On the other side of it, does anyone have any stats. on how much was saved by using Xz instead of bzip2? -- Ie. what we'd lose if we did a mass rebuild. Here's one I came across: http://fedoratux.blogspot.com/2009/05/xz-compression.html Jonathan 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: Deltarpm xz problem with PPC generated rpms?
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 is different. To test, using Rawhide's deltarpm, try running applydeltarpm -r anjuta-doc-2.27.3.0-3.fc12.noarch.rpm anjuta-doc-2.27.3.0-3.fc12_2.27.92.0-1.fc12.noarch.drpm test.rpm. You should end up with an md5 mismatch. If you rpm2cpio test.rpm, you'll find that the uncompressed cpio archive is identical to that of anjuta-doc-2.27.92.0-1.fc12.noarch.rpm. As I understand it, noarch rpms are generated on PPC builders. I suspect this problem is because of one of two reasons: 1. The version of xz on the PPC builders is a different version than that on the other builders? 2. xz generates different compressed files when run on different architectures If it is #2, this is a major problem (at least for yum-presto) because the whole purpose of deltarpm is to regenerate the original (compressed) rpm, given an older version and a deltarpm. If we can't do that, the regenerated package won't pass the signature check and will be re-downloaded in full. I have access to i586 and x86_64 systems, but no PPC systems. Could someone either give me access to a PPC system or verify themselves whether xz generates different files on different architectures (all other things being equal). It doesn't. [airl...@pegasus ~]$ md5sum lm93_busted.o d7174fc439c4678927725d06de4f18a2 lm93_busted.o [airl...@pegasus ~]$ xz -z -c lm93_busted.o | md5sum 86dbb83fea5f4e2f77396b3f491a0cc1 - [airl...@ppcg5 ~]$ md5sum lm93_busted.o d7174fc439c4678927725d06de4f18a2 lm93_busted.o [airl...@ppcg5 ~]$ xz -z -c lm93_busted.o | md5sum acf84a6c173b040f6cf8ea96c7daa513 - thats just a random file I had on my machine here, first is x86 32-bit, second is ppc. xz-4.999.9-0.1.beta.fc12 on both. Dave. That really really sucks. Thanks for checking it for me. Jonathan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Deltarpm xz problem with PPC generated rpms?
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 86dbb83fea5f4e2f77396b3f491a0cc1 - [airl...@ppcg5 ~]$ md5sum lm93_busted.o d7174fc439c4678927725d06de4f18a2 lm93_busted.o [airl...@ppcg5 ~]$ xz -z -c lm93_busted.o | md5sum acf84a6c173b040f6cf8ea96c7daa513 - thats just a random file I had on my machine here, first is x86 32-bit, second is ppc. xz-4.999.9-0.1.beta.fc12 on both. Dave. When I was playing around with xz after it came out, it detects the processor and memory available to it and defaults to a different compression quality based on that. Maybe if the compression quality and memory usage is set in the command line, you'd get the same output. boe...@bronto-burt % md5sum eeepc.pdf efbb35dcb6903fa4a8be91a717ae5c97 eeepc.pdf boe...@bronto-burt % xz -c -f eeepc.pdf | md5sum b7d67d9b8b6a3ac00d9fcfab67ebd93b - boe...@bronto-burt % xz -c -f -5 eeepc.pdf | md5sum 56a269074d015f6d46051a5ecf8d32da - [d...@cledwyn ~]$ xz -c -f eeepc.pdf | md5sum 5120f453bf577d58e3e94786e7bc5df1 - [d...@cledwyn ~]$ xz -c -f -5 eeepc.pdf | md5sum 56a269074d015f6d46051a5ecf8d32da - bronto-burt 3.0GHz x86_64 4GB RAM cledwyn 667MHz i686 192MB RAM xz-4.999.8-0.8.beta.20090817git.fc11 for both - --Ben Dave, if you're still around, do you mind running a check on both your machines using xz -c -z -7? IIRC, we do force the compression level in both rpm and deltarpm to be 7. Thanks, Jonathan 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: Deltarpm xz problem with PPC generated rpms?
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 functions are defined in liblzma/lz/lz_encoder_hash.h, and are based on the values in lzma_crc32_table[0]. This table is different between big end little endian. Not having looked at the algorithm... *why*? Is it really that big of a difference? I've been talking to the xz developer on IRC, and he says it's really not a huge difference. He sounds amenable to changing big-endian compression so it uses the little-endian CRC32 table. He said you'd need a new single-dimension CRC32 table that would only be used when doing the big-endian build. To be honest, though, this is all way over my head. Jonathan 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: Deltarpm xz problem with PPC generated rpms?
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 functions are defined in liblzma/lz/lz_encoder_hash.h, and are based on the values in lzma_crc32_table[0]. This table is different between big end little endian. Not having looked at the algorithm... *why*? Is it really that big of a difference? 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. 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 may result in different compressed files. We will probably need to have some kind of freeze for xz during a release (or at the very least, a test case added to the build process that fails when a generated xz file doesn't match a precreated one). Alternatives include a mass rebuild whenever xz's compression format changes and/or removing all deltarpms when xz's compression format changes. Another alternative would be for rpm to have a private copy of the xz-lib code that stays fairly static. Not sure how that would go down. 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. Otherwise, noarch deltarpms will build into an incorrect rpm, and yum-presto will proceed to redownload the full rpm. Jonathan 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: Deltarpm xz problem with PPC generated rpms?
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, forgot to mention, another option would be to sign the *uncompressed* data in an rpm, so if the compressed data was different, it wouldn't matter. This would be a lot easier from the maintenance side of things, but I'm not sure how feasible this big of a change in rpm would be. Jonathan 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: Deltarpm xz problem with PPC generated rpms?
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 may result in different compressed files. ... 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 be different than the file generated using -5 now. Jonathan 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: Deltarpm xz problem with PPC generated rpms?
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 be different than the file generated using -5 now. As long as that file is decompressible by older versions, then it's only a deltarpm issue. That's correct. All of this only affects deltarpm. Sorry if I wasn't clear on that. Jonathan 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: Deltarpm xz problem with PPC generated rpms?
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 it will produce the same output independent of endianess. He hasn't committed to any timeframe, though. snip Sorry, forgot to mention, another option would be to sign the *uncompressed* data in an rpm, so if the compressed data was different, it wouldn't matter. This would be a lot easier from the maintenance side of things, but I'm not sure how feasible this big of a change in rpm would be. That doesn't work, before yum checks the signatures it checks the createrepo checksum ... which is a sha256 (or whatever) of the entire rpm¹. So deltarpm must produce exactly the same bits. ¹ Asking someone to change this to be the headers plus uncompressed data is likely to be unhealthy for you. So I'll just keep my mouth shut and not bring this suggestion up again. :) Along with the other one that I'm never supposed to speak of again. Jonathan 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: Deltarpm xz problem with PPC generated rpms?
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 are being generated, but in Koji, noarch builds can be on any arch, there's no way to predict what arch Koji will be running them on. Sorry, my understanding was that they were all being generated on the PPC builders. Perhaps it's just that they're more likely to be built on those builders. Jonathan 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: FESCo meeting summary for 2009-07-31
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 to. The review for deltarpm says that the reviewer
checked the tarball against upstream:
https://bugzilla.redhat.com/show_bug.cgi?id=202033
This is what's in the current spec:
URL: http://gitorious.org/deltarpm/deltarpm
Source: %{name}-git-20090729.tar.bz2
This doesn't follow the Guidelines but doesn't look as bad as you say.
There is a public source repo on gitorious. jdieter has commit access
there. It seems like all that's needed is the comment that says:
# Generate source by doing:
# git clone -r XX http://gitorious.org/deltarpm/deltarpm
# tar -czf deltrpm-%{version}.tar.gz deltarpm
FWIW, the old deltarpm web page died a while ago, but the source for
official releases has always been available at
ftp://ftp.suse.com/pub/projects/deltarpm/deltarpm-3.4.tar.bz2 (and
that's been the source tag in the spec file up until I branched off of
the new git repo last week).
I'll go ahead and fix the spec file to show where I'm getting the
current source. Sorry about the mistake.
Jonathan
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: Purging the F12 orphans
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 fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F11 deltarpms being built against rawhide base release
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 there is one built for the package, but the source version is wrong. For example gvfs-1.2.3-6.f11 is in the latest set of updates. I currently have 1.2.3-2.f11 installed, but the drpm is gvfs-1.2.3-3.fc12_1.2.3-6.fc11.x86_64.drpm, (f12, not f11, and 1.2.3-3 never got pushed to f11) which won't work... Presumably there should be drpms built against release+prev-update, or ideally one drpm for any update released in the previous week. I would suggest creating a bug report against createrepo for the wrong source rpm. This sounds more like a mash config issue than a createrepo bug. Sorry, yes, you're probably right. Jonathan 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: Changing the default 32-bit x86 arch for Fedora 12
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 architecture is not a particularly production use of resources. The 1% comes from i586 - i686; SSE2 would be additional on top of that. But given the vehement opposition, I can see dropping the SSE2 requirement. I'm still fairly convinced that going to i686 is the right move - we really don't support i586 as a practical matter, and even the Geode should still work with that. Furthermore, it's likely we'll have a mass rebuild for LZMA support and/or debuginfo changes, so it's no additional cost. This may have been asked before, but is the Celeron M processor in the EeePC 701 i686? It supports both SSE2 and cmov, but not PAE. Jonathan 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: F11: install freezes on Thinkpad
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... FWIW, I've installed F11 (well Rawhide a couple of weeks before release) on two Lenovo X61's with no problem. Jonathan 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
