Re: yum-presto occasionally goes into eternal loop looking for deltas
On Thu, 2010-01-07 at 21:19 +0200, Jonathan Dieter wrote:
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.)
The plugin could require yum = 3.2.25, and then do something like (in
config or prereposetup):
for repo in repos:
repo.mdpolicy.append('prestodelta')
...which would auto download presto MD when yum gets new repomd/primary.
People might complain though :) ... another kind of fix would be for the
plugin to call .cleanExpireCache() if the MD fails to download.
The nice server side fix is to keep around more than one complete set
of MD (possible now we have unique MD filenames), so there would have to
be two updates within the client side cache timeout. But I'm not sure
how easy that is.
--
James Antill - ja...@fedoraproject.org
http://yum.baseurl.org/wiki/releases
http://yum.baseurl.org/wiki/whatsnew/3.2.26
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: ABRT considered painful
On Sun, 2010-01-03 at 13:37 +0100, Jiri Moskovcak wrote: On 01/02/2010 03:32 PM, Jan Kratochvil wrote: Moreover ABRT does not install the whole debuginfo package but only copies the needed specific .debug files out of it somewhere - as know the ABRT people. Exactly, we don't install it, just extract the package to /var/cache/abrt-di. ABRT doesn't remove it automatically, but it's a planned feature. Why do you do this? -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.26 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: packages requiring me to reboot...
On Wed, 2009-12-16 at 08:50 +, Richard Hughes wrote: 2009/12/15 Colin Walters walt...@verbum.org: This exists? Can you point me to the code? I only finished this just this morning. It's just been pushed to git master. You want to see this commit http://cgit.freedesktop.org/packagekit/commit/?id=66d3fc26054abd528ee18017d9c67edb6400f239 for the juicy config bits. Looking at 3cb32ad40af3a38456e09baf1b29b046d82c587e, AIUI the commit with the code bits in it, I'm pretty sure you are now requiring filelists to be downloaded for all updates. The UI isn't very pretty at the moment (it just fails with an update error) but I'll work on something a little bit more user friendly. How do you plan on restarting firefox? Or you just planning to kill() and get the user to restart? -- 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: yum doesn't like installonly_limit=1?
On Thu, 2009-12-10 at 18:00 +0530, Rajeesh K Nambiar wrote: I changed the installonly_limit to 1 from the default value 3 in /etc/yum.conf, and yum blows up. # yum search boinc Loaded plugins: presto, refresh-packagekit Options Error: Error parsing '1': out of range integer value This is an error message, not what I'd usually term blows up. PackageKit gave me a better traceback: This is just more text to say the same thing, 1 is an invalid argument. I changed the value to 0, 2, 3 etc, all of them resulting in a working yum environment. Is it a known issue, or worth filing a bug? Yum version is yum-3.2.25-1.fc12.noarch Maybe3 a better question is: What do you want to achieve by setting this value to 1? -- 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: rawhide and tagging requests
On Thu, 2009-12-10 at 08:16 -0500, Seth Vidal wrote:
On Thu, 10 Dec 2009, Panu Matilainen wrote:
Yup, but this isn't createrepo crashing (the earlier one was):
2009-12-09 20:11:04 mash: createrepo: finished
/mnt/koji/mash/rawhide-20091209/development/x86_64/os/
2009-12-09 20:11:05 mash: Resolving multilib for arch x86_64 using method
devel
2009-12-09 20:11:05 mash: Waiting for depsolve and createrepo to finish...
2009-12-09 20:21:28 mash: Resolving depenencies for arch x86_64
Traceback (most recent call last):
File /usr/bin/mash, line 96, in module
main()
File /usr/bin/mash, line 84, in main
rc = themash.doMultilib()
File /usr/lib/python2.6/site-packages/mash/__init__.py, line 538, in
doMultilib
pid = self.doDepSolveAndMultilib(arch, repocache)
File /usr/lib/python2.6/site-packages/mash/__init__.py, line 511, in
doDepSolveAndMultilib
(rc, errors) = yumbase.resolveDeps()
File /usr/lib/python2.6/site-packages/yum/depsolve.py, line 718, in
resolveDeps
for po, dep in self._checkFileRequires():
File /usr/lib/python2.6/site-packages/yum/depsolve.py, line 1012, in
_checkFileRequires
po = self.getInstalledPackageObject(pkgtup)
File /usr/lib/python2.6/site-packages/yum/__init__.py, line 2421, in
getInstalledPackageObject
raise Errors.RpmDBError, _('Package tuple %s could not be found in
rpmdb') % str(pkgtup)
yum.Errors.RpmDBError: Package tuple ('clamav-scanner-upstart', 'noarch',
'0', '0.95.3', '1301.fc13') could not be found in rpmdb
Gah, I see the problem. clamav-scanner-upstart is in the transaction,
to be installed, but we are only looking in the rpmdb. My fault, off to
do a patch.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide and tagging requests
On Thu, 2009-12-10 at 10:56 +0200, Panu Matilainen wrote: On Wed, 9 Dec 2009, Jesse Keating wrote: On Wed, 2009-12-09 at 06:43 -0800, Jesse Keating wrote: All the broken deps preventing a compose attempt have been cleared out. However the new rpm build was busted in a way that it made the compose fall over, a new build of rpm is coming and I hope to kick off another rawhide attempt when it lands. Ugh, things are still broken on the rpm front. My attempt from earlier fell over, may not get a fix in place for tonight's attempt either :/ Hmm, looking at the traceback at the end of http://kojipkgs.fedoraproject.org/mash/rawhide-20091209/logs/mash.log Note that while I fixed the bug which caused the traceback, the traceback is in a code path that means clamav-scanner-upstart has a file dep. that can't be satisfied ... so I'm not sure if that means the compose will fail anyway? -- 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: yum doesn't like installonly_limit=1?
On Thu, 2009-12-10 at 20:45 +0530, Rajeesh K Nambiar wrote: On 12/10/09, James Antill ja...@fedoraproject.org wrote: On Thu, 2009-12-10 at 18:00 +0530, Rajeesh K Nambiar wrote: I changed the installonly_limit to 1 from the default value 3 in /etc/yum.conf, and yum blows up. # yum search boinc Loaded plugins: presto, refresh-packagekit Options Error: Error parsing '1': out of range integer value This is an error message, not what I'd usually term blows up. I mean - can't install anything, can't search a package. It took me a while to realize that the change made to the config file caused it as I tried to use yum again after couple of days. Fair enough, as Seth said we should probably tell you want option is the problem :). What do you want to achieve by setting this value to 1? Ah, I realize that it would have the same effect as installonly_limit=0 ? No, 0 is special and means the same thing as off. 1 would make it act like a normal package (old version removed as new version is installed) ... except the kernel package doesn't work if you do that, so we just disallow it. -- 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: Promoting i386 version over x86_64?
On Wed, 2009-12-09 at 15:26 +0100, Ralf Corsepius wrote: However, some $DEITY's have decided otherwise ... I am inclined to think inevitably, because such platforms aren't the platforms most developers use nor the platforms RHEL is aiming at ... These people think in terms of Quad machines and RH clients, but forget about the amount of old machines which are still actively being used and about use-case niches. A+ for, eventually, coming to the obvious solution. Although, personally, I haven't had a quad core yet all the computers I currently have running are either laptops or dual cores. The minimum RAM size on any of these 5 boxes is 2GB. I'd be surprised to find that anyone working as a full time developer has any (non-virt) boxes that are spec'd less than that. And yes, shockingly, developers will test on the machines they have easy access to. So, yeh, if _you_ want to support slower machines ... _you_ will have to do the work, you might get help from the community but just ranting on f-d-l Everyone should solve my problems is unlikely to actually help. IMO. -- 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: Upstart 0.6.3 coming to a rawhide near you
On Fri, 2009-12-04 at 16:45 -0500, Bill Nottingham wrote: Miroslav Lichvar (mlich...@redhat.com) said: On Fri, Dec 04, 2009 at 04:10:34PM -0500, Bill Nottingham wrote: https://fedoraproject.org/wiki/Features/Upstart0.6.0 The features highlight list has: Communication with the init daemon over D-Bus. Questions? Comments? Does this mean that running dbus will be required to reboot/shutdown the system? No. The init daemon speaks the dbus protocol, and can be communicated with over the system daemon. But it can also be talked to directly. Looking at upstart-0.6.3-3.fc13.src.rpm, the specfile includes /sbin/shutdown etc. ... and looking at the tarball those seem to come from util/*.c. Which AFAICS require DBus to work. Also given that init now listens and is controlled by DBus, has anyone done any analysis of how resistant DBus services are to DOS attacks? -- 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 Thu, 2009-12-03 at 10:29 +0100, Nicolas Mailhot wrote: Le Mer 2 décembre 2009 23:56, Matt Domsch a écrit : 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. Right now the same package moves from master URL to master URL as it is pushed from testing to updates to GA to whatever. That means the same package gets downloaded many times over because it changed URL (and browsers, proxies, etc understand new url = new file) It only moves once, at least in the vast majority of cases. My proposal is to never move a package, put it in a single unchanging place after a koji build, and just index it or not in the relevant repodata when it gets promoted or demoted. One problem is that atm. when it moves from testing to updates, or rawhide to GA, it also gets resigned with a different key ... so the bits are not the same. Having the URL be the same will not be helpful until that changes. -- 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 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: [RFC] unified i386/x86_64 install media.
On Wed, 2009-11-25 at 13:18 +0100, Jeroen van Meeuwen wrote: On 11/25/2009 03:26 AM, Seth Vidal wrote: On Tue, 24 Nov 2009, Matthew Miller wrote: So would this mean one disk with two repositories on it, or is everything mashed together all in one repository? it'd be easy to have two sets of repodata in two different dirs pointing to the same set of pkgs. On 11/25/2009 07:28 AM, Jesse Keating wrote: Two repos, but with hardlinks. I doubt ISO9660 can deal with hardlinks, but I have to admit I've never really tried (I did try once and gave up pretty quickly I recall). Also, the way I understand this works, you can just include x86_64 packages in the one repository... You can but that will break x86_64, because i386 will need i386 packages that x86_64 must not have as multilib. As Seth said, you can have one giant directory of packages and just different repodata pointing to subsets. As Jesse said you could also use hardlinks/symlinks in the x86_64 repo. Or you could even create three repos. i386, x86_64 and i386-common (not that I think that will be better than the other two options). -- 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: PackageKit policy: background and plans
On Mon, 2009-11-23 at 22:32 +, Colin Walters wrote: On Mon, Nov 23, 2009 at 10:02 PM, James Morris jmor...@namei.org wrote: Possibly (it could simply be that an updated policy is weaker for some reason) -- but it doesn't matter, there should be no way to change MAC policy without MAC privilege. It'd be nice here if we had the ability to only grant the ability to install applications, not packages. applications is still way too broad, IMO. Even if you limit it to what I assume you meant, Desktop applications, it's not obvious that is good enough. A useful end goal seems more likely to be something like allow 'local' users to update/install signed/trusted versions of: fonts, codecs, themes, games, editors. For bonus points you could make it possible for them to remove packages they have installed. If done well this should even allow things like the webadmin role being allowed to update/install apache related packages. -- 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: PackageKit policy: background and plans
On Tue, 2009-11-24 at 10:27 -0500, Seth Vidal wrote: On Tue, 24 Nov 2009, James Antill wrote: On Mon, 2009-11-23 at 22:32 +, Colin Walters wrote: On Mon, Nov 23, 2009 at 10:02 PM, James Morris jmor...@namei.org wrote: Possibly (it could simply be that an updated policy is weaker for some reason) -- but it doesn't matter, there should be no way to change MAC policy without MAC privilege. It'd be nice here if we had the ability to only grant the ability to install applications, not packages. applications is still way too broad, IMO. Even if you limit it to what I assume you meant, Desktop applications, it's not obvious that is good enough. A useful end goal seems more likely to be something like allow 'local' users to update/install signed/trusted versions of: fonts, codecs, themes, games, editors. For bonus points you could make it possible for them to remove packages they have installed. If done well this should even allow things like the webadmin role being allowed to update/install apache related packages. See, this is the problem, with all the exceptions you'd need to codify it would make much more sense to document how to set them up and make it relatively easy to do so that the local admin can do so. Think of it like documentation for sudo but with docs that don't make everyone cry. Oh, I agree 100%. My bad for not explaining what I meant. I'm not saying the GUI pkg installer should come with the above as defaults, just that it should work towards being able to easily provide the above functionality. -- 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: PackageKit policy: background and plans
On Tue, 2009-11-24 at 14:22 -0500, Peter Jones wrote: On 11/23/2009 07:01 PM, Gregory Maxwell wrote: On Mon, Nov 23, 2009 at 6:43 PM, Jesse Keating jkeat...@j2solutions.net wrote: This is precisely the dialog that has been removed from F12 and is not planned to be returned. My understanding was that this was removed because collecting the root password during a user session is insecure because there could be a sniffer or the dialog could be faked. That reason isn't /quite/ right. One big problem is that if you train a user to input the root password over and over, what he learns is to type the root password into a dialog box. The result is that when some non-privileged application asks for the root password so it can do bad things with it later, the user will type in the root password, and voila, a local attack against a user is now a root exploit. Sure, that's _a_ problem ... assuming the user has been trained. But that's a _big_ assumption, esp. when we are only talking about installing _new_ packages (doesn't happen often, so the user isn't trained to accept it). But, of course, taking advantage of a user trained to input a password without thinking is not the only attack ... another area of attack would be when you have an assumed small privilege escalation, that has no authentication (hence this thread). The way around this is role-based privileges, which is what polkit is implementing In so far as role-based privileges is code for can be configured to N number of actual checks, including the auth_as_root check we are comparing it against. Then sure, it has to be at least as secure as auth_as_root because it can be auth_as_root¹. But suggesting that whatever polkit is configured to use is automatically better than auth_as_root is, at best, misleading. Personally I don't think _anyone_ knows how to make a usable and thus. in practice secure desktop. So some of the comments I've read saying basically We know X is insecure, so we are now using Y which is secure/better are not helping (in fact I'd suggest that this mindset is what lead to this problem initially). ¹ Noting that polkit force removed the remember auth option, for no particularly sane reason that I've seen ... so if that option turns out to be the best option, then role-based privileges has (at least currently) hurt security. -- James Antill ja...@fedoraproject.org Fedora -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFC] unified i386/x86_64 install media.
On Tue, 2009-11-24 at 16:48 -0500, Adam Jackson wrote: On Tue, 2009-11-24 at 13:50 -0600, Dennis Gilmore wrote: syslinux would need to be able to detect the arch to install and likely also have a flag to force 32 bit we could easily implement the 64 bit kernel and 32 bit userland idea that was put forward a few releases ago. pungi will need to learn how to make the new iso. but i think it is achievable. As I'm actually trying this on one of the laptops on my desk, I'd point out that this almost certainly requires yum changes to work well. yum gets its idea of arch from uname, which reports what the kernel is, not what the current glibc is. Not that it's not a good idea - it seems to work surprisingly well - but it's not turnkey yet. Also plugins like kmod which use uname directly. And anaconda really doesn't like it, from a previous similar RFE: https://bugzilla.redhat.com/show_bug.cgi?id=437914 RFE: Yum 32bit for installer? -- as 64bit uses twice as much memory ...on the upside IIRC notting tried the 64bit kernel with 32bit userspace for F11, and had a single line patch (to rpmUtils.arch) to make yum happy. -- 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: FC11 packages 'newer' than FC12
On Thu, 2009-11-19 at 13:03 -0500, Przemek Klosowski wrote: I originally reported this through bugzilla, but at Rahul's suggestion, I am posting this to the fedora-devel. Some Fedora 12 packages have versions that do not supersede the versions of Fedora 11 packages, preventing a complete upgrade to FC12. A partial list is: [...] For example, 'yum update iw' does nothing; 'yum install iw' results in an error message Transaction Check Error: package iw-0.9.17-3.fc11.i586 (which is newer than iw-0.9.17-2.fc12.i686) is already installed This is due to the .i586 = .i686 change, probably worth a BZ against yum. downgrade also has problems ... of course this should really be the last time now, so adding any more hacks is going to be a low priority. -- 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: FC11 packages 'newer' than FC12
On Thu, 2009-11-19 at 13:38 -0500, Stu Tomlinson wrote: On Thu, Nov 19, 2009 at 13:19, James Antill ja...@fedoraproject.org wrote: On Thu, 2009-11-19 at 13:03 -0500, Przemek Klosowski wrote: [...] For example, 'yum update iw' does nothing; 'yum install iw' results in an error message Transaction Check Error: package iw-0.9.17-3.fc11.i586 (which is newer than iw-0.9.17-2.fc12.i686) is already installed This is due to the .i586 = .i686 change, probably worth a BZ against yum. downgrade also has problems ... of course this should really be the last time now, so adding any more hacks is going to be a low priority. Surely it's more due to the fact that 3 2. No, the bug is that it fails at Transaction Check time. For instance on an F11 box, I have: % sudo yum list yum --showduplicates Loaded plugins: aliases, keys, noop, presto, security, tmprepo Installed Packages yum.noarch3.2.24-9.fc12 @rawhide Available Packages yum.noarch3.2.22-4.fc11 fedora yum.noarch3.2.24-2.fc11 updates ...and if I try to install yum it says: % sudo yum install yum Loaded plugins: aliases, keys, noop, presto, security, tmprepo Setting up Install Process Package matching yum-3.2.24-2.fc11.noarch already installed. Checking for update. Nothing to do % ...which is what it should be doing in the above cases, but the change from .i586 to .i686 confuses the install/downgrade paths. -- 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: Local users get to play root?
On Wed, 2009-11-18 at 23:18 +0530, Rahul Sundaram wrote: On 11/18/2009 11:19 PM, nodata wrote: Thanks. I have changed the title to: All users get to install software on a machine they do not have the root password to .. if the packages are signed and from a signed repository. So, you left out the important part. Explain why this is a problem in a bit more detail. That is important, and personally I have a lot of sympathy for some of the desired use cases¹ I've heard about. On the other hand this does open up a lot of ways to attack the system, esp. given that there is _no_ authentication ... as I had expected that code running as the user would still have to authenticate as the user (Hello Linux virus makers, welcome to the party). Off the top of my head, these are the first things I'd look at for attacking a system with PK and this config: 1. Does install of obsoleting packages come under the same auth. (if so I can now arbitrarily upgrade certain packages). 2. Does install of installonly come under the same auth. (if so I can now stop kernel upgrades). 3. Are there any attacks due to disk space used? Eg. If /var is low² I can probably install enough pkgs to make logging stop. 4. Are there any attacks against packages with default on services? (Note that you can almost certainly wait until there is an attack, and then install the insecure service). 5. Are there any attacks against packages with set*id apps? (Dito. with the waiting approach in #4). 6. Are there any attacks against packages which provide plugins? (Dito. waiting) 7. And the most obvious one ... how hard is it to get a bad package into one of the repos. that the machine has enabled. ¹ Things like letting a spouse/child install a new game/theme/editor/etc. without having to get their admin to do it. ² If /var is on a separate partition then spamming /var/tmp is a goood first step here. -- 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: Local users get to play root?
On Wed, 2009-11-18 at 16:04 -0500, Steve Grubb wrote: The problem is the *Default* not the fact that you can consciously allow users to update without a password. And I wonder what the audit trail will show? Does it show which user installed these packages? PK has it's own logging, it logs the user the API is running from there. But it doesn't set loginuid, so yum history, auditd, SELinux, etc. don't know. -- 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: RFC: Btrfs snapshots feature for F13
On Tue, 2009-11-17 at 08:10 -0500, Josef Bacik wrote: On Tue, Nov 17, 2009 at 2:48 AM, Jeff Garzik jgar...@pobox.com wrote: As the URL notes under Detailed Description, that is not handled at all. It wraps all file I/O, yum or not, into the snapshot. Yeah but you can't roll back userland transactions. Not to mention you are talking about an interface that may change quite a bit over the next year. That seems like a significant limitation, I'm also not sure that the current transaction API would be usable by rpm. Anyway... We have snapshotting abilities now, and yes it's a big hammer, but just because its a bit of a blunt instrument doesn't mean we shouldn't take advantage of it. This implies that all you have is a hammer but you can already run yum history undo. -- James Antill - ja...@fedoraproject.org I'd just like to see a realistic approach to updates via packages. -- Les Mikesell -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Btrfs snapshots feature for F13
On Tue, 2009-11-17 at 11:48 -0500, Tom Lane wrote: Peter Jones pjo...@redhat.com writes: Do they support rollbacks after commit? If they don't, they're not really as useful for this as they could be. Rollback *after* commit? This must be some other usage of the term commit than is standard to database people. No it's just a new definition of rollback than is standard. The idea is that _ideally_ people seem to _want_ to be able to do: 1. update to new foo 2. run random other things that alter data. 3. update to new bar 4. run random other things that alter data. 5. run new foo, which alters it's data. 6. run random other things that alter data. 7. run new bar, which alters it's data. 8. run random other things that alter data. 9a. Decide foo is bad and thus. rollback just #1 and #5. 9b. Decide bar is bad and thus. rollback just #3 and #7. ...so all solutions tend to be exercises in randomly picking the features you think they really want, from what is desired. Yum history assumes you are happy with just #1 and/or #3. Snapshots assume you are happy to take a lot of collateral damage to get #5 and/or #7. -- 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: How about releasing an update of xorg-x11-drv-intel for Fedora 11
On Fri, 2009-10-16 at 20:47 +0200, Kevin Kofler wrote: What happened is that some IMAP-related feature broke, affecting some users (and I'm sorry you were hit by it), whereas most had their IMAP working just fine. So those bugs weren't trivial to catch. Wow ... it's almost as if we need a place where developers could put _updates_ for a significant amount of time so that users could do some _testing_ on them, under each of their particular conditions. We could maybe use this instead of developers hitting the go button when they didn't get an avalanche of BZs immediately. It'd also be cool if we could have some package management tool to downgrade these updates, so users wouldn't be immediate screwed if they tried an update for testing purposes ... it might even be possible to create a history of package management operations, and then the user could just undo the set of things they got from this place for testing of updates. I must meditate on this. -- James Antill - ja...@fedoraproject.org I'd just like to see a realistic approach to updates via packages. -- Les Mikesell -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: How about releasing an update of xorg-x11-drv-intel for Fedora 11
On Fri, 2009-10-09 at 09:19 +1000, Dave Airlie wrote: On Thu, 2009-10-08 at 09:37 -0700, Adam Williamson wrote: Then please feel free to make one. :) I don't mean that in a snide fashion, but it really is the answer. As noted, having our X.org developers spend time on such a repository directly subtracts that amount of time from the time they would otherwise spend actually developing the drivers (our X.org maintainers are also major upstream developers) and fixing reported bugs. I thought about doing something like this the other day, but really if we had something like Ubuntu PPA, which I think is on the longterm plans for Fedora then it would be a lot easier to do. At the moment its just too distracting to do. The thing with doing updates for F11 is the regression rate due to lack of QA, I put Mesa packages into updates-testing that fixed a lot of r300/r500 bugs back at the start of F11 and it went into testing a few weeks later and broke Intel, I got 0 reports during that u-t phase about breakage. So now I have a package in stable that lets 3D works for x num of people and breaks compiz for y number. The problem is that PPAs/KoPeRs are going to get much less testing than stuff in updates-testing, so if you don't think you are getting enough testing in updates-testing I really don't see how KoPeRs will solve that problem. Personally I'd suggest pushing to updates-testing but wait a _long_ time (maybe even never) before pushing to stable. Of course you are kind of screwed in having a package which might work fine on one machine, but fail on many others. I think for F12 updates we could really do with some sort of side repo setup, so we could have a stability period where QA could happen on packages that may end up in updates a month or two later. How would this be different from updates-testing? If you install yum-plugin-aliases it even has predefined aliases lsuT and upT to get the list of updates from testing, and update to them. bodhi has support for it etc. -- James Antill ja...@fedoraproject.org Fedora -- 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 Mon, 2009-10-05 at 20:32 +0200, Ahmed Kamal wrote: Also the rawhide db itself. A guaranteed 8-12 megabyte download usually swamps out any saving from presto (barring changes to eclipse, kernel and openoffice). Why aren't we rsync'ing that 12MB db, instead of re-downloading ? Wasn't there some web friendly rsync fork zsync, see the recent thread for why it isn't in Fedora. And I doubt they'd be much savings, even if it worked (and you'd have to be clever due to the names changing). Adding delta MD support would be easier, and by easier I mean significant amounts of code and significant problems on the f-i side. -- James Antill ja...@fedoraproject.org Fedora -- 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 Tue, 2009-09-29 at 08:07 -0700, Toshio Kuratomi wrote: On 09/29/2009 05:00 AM, Rahul Sundaram wrote: On 09/29/2009 05:14 PM, Josephine Tannhäuser wrote: Seems that violations of the guidelines are not so important like the violation of the Trademark (The hunting of fedora related sites, like blogs or forums with adhesions contracts)... Are the project related activities are out of balance? They are called guidelines and there are always exceptions. Bundling a library is not ideal but removing rsync would be a extreme step. I don't think the situation warrants that. Let's not loose perspective here. So in this case, I think the following things could be said: * Removing rsync is not an option because of how widely it is used. Sure. * Bundling libraries in zsync is not an option Why is it not? Because you don't use it? Because f-i doesn't currently use it? (remember this thread started because the Fedora QA group wants to use it). Maybe we should split the packaging guidelines into ones everyone has to follow and ones that are really anal and only unpopular packages have to follow. -- James Antill ja...@fedoraproject.org Fedora -- 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 15:22 +0300, Jonathan Dieter wrote: 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. No, we have at least 3 problems I think: 1. Nobody wants to download uncompressed rpms, if they don't have presto. 2. gig signature is over the rpm data (and thus. is over compressed data). 3. createrepo sha256 data is over the entire rpm (and thus. is over compressed data). ...but to me this is all a _problem_in_xz_, not presto/deltarpms. If nobody can fix xz before F12 GA then IMNSO we should revert the compression to something that works ... the minor savings in xz compression isn't worth as much as delta's. -- James Antill - ja...@fedoraproject.org I'd just like to see a realistic approach to updates via packages. -- Les Mikesell -- 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 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. 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. -- James Antill ja...@fedoraproject.org Fedora -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: how to determain those no longer required packages
On Sat, 2009-08-29 at 19:06 -0500, Jason L Tibbitts III wrote: AT == Axel Thimm axel.th...@atrpms.net writes: AT I don't think apt traces whether a packages was a pulled in manually AT or automatically, does it? yum does keep track of many things in the yumdb and I think the reason key is supposed to track this, but for me it seems reason is always user. I think the intent is to track packages which were installed because the user requested them directly separately from packages which were pulled in purely because of dependencies. Yes, the reason attribute in yumdb is there primarily to start on solving this problem. yumdb hasn't been around an entire release yet, which makes it's data somewhat problematic (and the testing somewhat limited). Also atm. we don't carry reason=dep across updates, so if you do yum update with a new version of a package you got as a dep. that would be considered a user install of the new package. Both of which should explain why almost nothing has reason=dep¹. Atm. I have: % yumdb search reason dep Loaded plugins: presto fipscheck-1.2.0-1a.fc11.x86_64 reason = dep ...so it does work, at what it does atm. Probably the sanest request here is that if you do: 1. yum install blah 2. try out blah, don't like it 3. yum remove blah ...you don't get rid of any extra stuff you got with blah, hopefully yum history undo will solve that in a better way by recording what happened at #1 and undoing it instead of trying to piece together what might have happened at #1 after the fact. ¹ It's also true that saving 1 cent of disk space isn't at the top of my list of things to do. -- James Antill ja...@fedoraproject.org Fedora -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Testing libsatsolver on Fedora
On Fri, 2009-07-31 at 14:21 -0400, Bill McGonigle wrote: On 07/31/2009 01:12 AM, James Antill wrote: *sigh*, if you want to do some benchmarking of different package managers available in Fedora (zypp makes the 4th, if apt is working again) then feel free to actually do _a bunch of work_ comparing apples to apples. You'll almost certainly be speaking privately with developers from all of the tools, to make sure you aren't screwing it up. _Then_ post the results somewhere. Raising the bar so high on public discussion of application performance is essentially an attempt to stifle it. You're right, I deeply apologize for asking people to _do the work_ necessary to produce real worthwhile performance numbers ... instead of just posting the first thing that comes to mind, so we can all have a giant flamewar full of yum FTW!, no, solv FTW, you suck! We don't make progress by commissioning scientific studies as soon as new ideas are put forth, we see first if they pass the smell test. We also don't make progress by posting yum is 50x slower than solv for update, and yet _predictably_ that is what this thread degenerated into within hours of your post. I was probably fooling myself hoping to stop that before it started, and likely clinically insane by writing: http://illiterat.livejournal.com/7412.html ...to try and give a more detailed explanation of the problem, but then maybe in the future I can just post a link to that and hit delete thread. If, however, you want to just post yum is slow feel free to not do so on f-d-l. Likewise with quick benchmarks like this (which amounts to the same thing, IMO). Somehow you forgot to quote where I said yum was doing more work and it downloaded twice as fast. It sounds like you're trying to project unrelated anti-yum sentiment onto my simple report of positive progress on Michael's part. Then why post the numbers, if you know they aren't comparable/worthwhile/etc? And, yeh, I'd have at least worded my reply differently (if not just hit delete thread) if you were the first person to ever post weird numbers and call it a yum vs. BLAH benchmark. But that works the other way around too. And to make this clear: I'd be very happy if Michael would take over https://bugzilla.redhat.com/447740 or otherwise help them complete. And I would be even happier if someone wanted to do the significant amount of work to provide some real benchmarks for package management (which in the case of zypper vs. yum would kind of be blocked by 447740, IMO). -- James Antill - ja...@fedoraproject.org I'd just like to see a realistic approach to updates via packages. -- Les Mikesell -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Testing libsatsolver on Fedora
On Fri, 2009-07-31 at 20:30 +0200, Miroslav Lichvar wrote: Yes, but that's not what I'm talking about. I mean the explicit conflicts between current versions of packages. I.e. the thing that makes the complexity exponential. For example: package A: depends on X package B: conflicts with D package C: provides X package D: provides X yum install A B fails here as it tries to install A B D. The solution is to install A B C. Right, yum doesn't do backtracking, so it doesn't solve the above when the conflict is with C. However apart from things like running Sodoku in the depsovler (Michael, feel free to post a comment in the blog for zypper results :): http://illiterat.livejournal.com/6119.html ...this kind of thing is often best handled by eliminating the conflicts, rather than having a mini. version of prolog to write the depsolver in. IMO. There are also similar cases like: pkg-A: depends on X pkg-B: provides X pkg-ZOOM: provides X ...yum install pkg-A pkg-ZOOM will install all three packages, when it doesn't need to install pkg-B. Again this can often be solved much better by fixing the package metadata, rather than trying to make the solver more intelligent. Again, IMO. It's also worth noting that yum doesn't do removal on conflicts, so in your example if pkg-B was already installed then apt (and AIUI zypper) will remove pkg-B and install pkg-A and pkg-C ... where yum will not assume that was the intent. And, yes, in general I agree that's it's probably very hard to compare performance well because of the different design goals and features/etc. I'm not sure I'd say it's impossible though. -- James Antill - ja...@fedoraproject.org I'd just like to see a realistic approach to updates via packages. -- Les Mikesell -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Testing libsatsolver on Fedora
On Thu, 2009-07-30 at 14:49 +0200, Michael Schroeder wrote: I also fixed the no repomd.xml file bug, it didn't occur to me that the mirrorlist/metalink responses can also contain yum's $releasever/$basearch macros. Solv now supports this. What URL was doing this? I mean I'm pretty sure it works in yum when that's the case, but I've never seen it in MM metalink responses. -- James Antill ja...@fedoraproject.org Fedora -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Heads up, python-2.6.2 just built in rawhide
This shouldn't be a rebuild the world kind of update, but 2.6.2 has just built for rawhide and as usual we had to tweak our patches to get it to build etc. ... so there's some room for weirdness, so if you see anything please BZ etc. However I built it locally, in mock, for Fedora 11 and yum still works as did gedit python plugins. For the impatient the koji build was: http://koji.fedoraproject.org/koji/taskinfo?taskID=1567632 -- James Antill ja...@fedoraproject.org Fedora -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Testing libsatsolver on Fedora
On Thu, 2009-07-30 at 21:42 -0400, Bill McGonigle wrote: On 07/30/2009 08:49 AM, Michael Schroeder wrote: Version 0.14.4 should have all fixes. OK, my reported bugs are fixed. It would have been more useful to end the message here, as from what I read Michael just wanted to know how compatible zypp was with Fedora. But alas... On first run of 'update' (me saying 'n' ASAP), solv ran at about twice the real time of yum (both mostly downloading information). But that's not what I was interested in measuring. On a second run, with the local files being current, I got for 'solv update': *sigh*, if you want to do some benchmarking of different package managers available in Fedora (zypp makes the 4th, if apt is working again) then feel free to actually do _a bunch of work_ comparing apples to apples. You'll almost certainly be speaking privately with developers from all of the tools, to make sure you aren't screwing it up. _Then_ post the results somewhere. I would be more than happy to help you, with regards to yum, if only because it'd be nice to have _some_ third party results somewhere that weren't completely insane. If, however, you want to just post yum is slow feel free to not do so on f-d-l. Likewise with quick benchmarks like this (which amounts to the same thing, IMO). HTH. HAND. -- James Antill ja...@fedoraproject.org Fedora -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Do we need split media CDs for F12?
On Sat, 2009-06-13 at 08:46 -0500, Matt Domsch wrote: (Reposting to f-d-l from my blog post last night. http://domsch.com/blog/?p=85 includes a couple nice graphs to help illustrate.) CDs are Dead. Long live CDs. I was running some stats on the Fedora 11 release, and an interesting thing caught my eye. Very few people are downloading the six (or in the case of PPC, seven) CDs to perform a Fedora install. Very Very few. In fact, at most, six people downloaded split media CDs using the Fedora mirror servers in the first few days. I find that hard to believe, unless you mean via. MirrorManager? I know I downloaded all six CD isos directly from the kernel.org mirror, within a few hours of GA. For previous releases I'd tended to use the torrent, to get them all, as it was somewhat easier (but slower). This in contrast to the over 234,000 direct downloads of DVDs and LiveCDs in the same amount of time. BitTorrent statistics are a little better for CDs: 908 completed downloads of the split media CDs, out of 41,235 total downloads (or ~2.2 %). These are believable, but I'd still put money on the fact that more than 2.2% of users use CDs ... one of my machines here is an x86_64 Dell box, about 2 years old. And only has a CD drive. Now, sure, I normally only burn CD 1 ... and then use an exploded http install for anaconda. So I could probably make DVD only work, but it's much easier to just get the CDs. I'm also pretty sure my current laptop is DVD RO, but CD RW. -- James Antill ja...@fedoraproject.org Fedora -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Too eager?
On Tue, 2009-06-09 at 14:55 -0500, Jon Ciesla wrote: Jon Ciesla wrote: James Antill wrote: On Tue, 2009-06-09 at 11:37 -0500, Jon Ciesla wrote: Jonathan Dieter wrote: On Tue, 2009-06-09 at 11:17 -0500, Jon Ciesla wrote: I installed F-11 fedora-release* and did yum clean all ; yum update I got YumRepo Error: All mirror URLs are not using ftp, http[s] or file. This is a fully updated F-10 system. Manually filling in releasever and basearch in fedora.repo for basearch and mirrorlist make no difference. Something up? See https://www.redhat.com/archives/fedora-list/2009-June/msg00783.html , if you have the same line that says Eg. /metalink/, then I think that's the solution. Jonathan That's my error, but that doesn't help. yum-3.2.21-2.fc10.noarch. Easiest thing to do is probably just get the yum from Fed-10 updates-testing, which is 3.2.23 and understands metalink and metalink as mirrorlist. Success! I trust this will be pushed to F-10 stable with a quickness? Thanks all, -J Of course, now we have dependency problems, that --skip-broken won't touch. . . Error: Missing Dependency: libcrypto.so.7 is needed by package nx-3.3.0-33.fc10.i386 (installed) Error: Missing Dependency: libcrypto.so.7 is needed by package ntp-4.2.4p7-1.fc10.i386 (installed) Error: Missing Dependency: python(abi) = 2.5 is needed by package yum-3.2.23-3.fc10.noarch (installed) Normally I'd remove the offending packages, but I sorta need yum. . .and openssl. . . Any suggestions? The yum in Fed-11 updates-testing is yum-3.2.23-3.fc11.noarch.rpm, which is newer than the one in Fed-10 updates-testing. Given you are trying to update via. yum, just enabling updates-testing should be the most fun :). Or you can always just download the above yum, and use yum shell to update everything else and yum via. the local file. Or there is always preupgrade, which is the suppor^W less fun way to do it :). -- James Antill ja...@fedoraproject.org Fedora -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Too eager?
On Tue, 2009-06-09 at 20:22 -0500, Jon Ciesla wrote: Given you are trying to update via. yum, just enabling updates-testing should be the most fun :). Or you can always just download the above yum, and use yum shell to update everything else and yum via. the local file. And how do I install an F-11 yum RPM in F-10, which lacks python 2.6? I get the same thing with or without updates-testing for F-11. As I said: 1. yum upgrade --enablerepo=updates-testing 2. yumdownloader --repoid=updates-testing yum cat EOL | yum shell upgrade install yum-3.2.23-3.fc11.noarch.rpm run EOL #1 means you'll get all the other updates from updates-testing, #2 is more typing. -- James Antill ja...@fedoraproject.org Fedora -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: metalink doesn't match
On Sun, 2009-04-19 at 21:12 -0500, Mike McGrath wrote: Did you 'yum clean all' before testing this? This will never help. The error very likely means that MM hasn't picked up that a new repomd.xml has arrived ... but that repomd.xml has hit all the mirrors. Thus. the only available repodata is invalid. If you have older cached repodata, then instead of: Error: Cannot retrieve repository metadata (repomd.xml) for repository: rawhide. Please verify its path and try again It should revert to the old version and continue to work (so clean is actively harmful here). -- James Antill - ja...@fedoraproject.org I'd just like to see a realistic approach to updates via packages. -- Les Mikesell ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: [PATCH] Add compatibility back in for older versions of Yum.
On Tue, 2009-02-17 at 10:29 -0600, Jeffrey C. Ollie wrote:
We would like for Koji to remain compatible with the version of Yum
that is shipped with RHEL 5.
Signed-off-by: Jeffrey C. Ollie j...@ocjtech.us
---
builder/mergerepos | 11 +++
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/builder/mergerepos b/builder/mergerepos
index defb8c1..cfa3a8d 100755
--- a/builder/mergerepos
+++ b/builder/mergerepos
@@ -95,10 +95,13 @@ class RepoMerge(object):
self.mdconf.verbose = True
self.mdconf.changelog_limit = 3
self.yumbase = yum.YumBase()
-self.yumbase.preconf.fn = '/dev/null'
-self.yumbase.preconf.init_plugins = False
-self.yumbase.preconf.debuglevel = 2
-self.yumbase._getConfig()
+if hasattr(self.yumbase, 'preconf'):
+self.yumbase.preconf.fn = '/dev/null'
+self.yumbase.preconf.init_plugins = False
+self.yumbase.preconf.debuglevel = 2
+self.yumbase._getConfig()
This line should be deleted, the first line after the if will turn the
preconf into the conf.
+else:
+self.yumbase._getConfig('/dev/null', init_plugins=False,
debuglevel=2)
self.yumbase.conf.cachedir = tempfile.mkdtemp()
self.yumbase.conf.cache = 0
self.archlist = arches
--
James Antill ja...@fedoraproject.org
Fedora
--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Disk IO issues
On Fri, 2009-01-02 at 11:57 -0600, Mike McGrath wrote: On Fri, 2 Jan 2009, Sascha Thomas Spreitzer wrote: Hello again, this line looks suspicious to me: # nameactive_objs num_objs objsize objperslab pagesperslab : tunables limit batchcount sharedfactor : slabdata active_slabs num_slabs sharedavail ext3_inode_cache 98472 15026076051 : tunables 54 27 8 : slabdata 30052 30052189 Is it 1 big filesystem with about 1,342,177,280 inodes. Has this amount ever be tested in the wild? Not sure if it has been tested in the wild or not but the filesystem itself contains a _TON_ of hardlinks. Creation of hardlinks is one of the big purposes of this filesystem. Ah ha ... I bet that you'll find tar/cp-a/whatever is having a major problem keeping tabs on which inodes it's seen, so it doesn't copy the same data N times. Try running: cp -a --no-preserve=links ... and see if that is much faster? -- James Antill ja...@fedoraproject.org Fedora ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Disk IO issues
On Wed, 2008-12-31 at 14:42 -0600, Mike McGrath wrote: Lets pool some knowledge together because at this point, I'm missing something. I've been doing all measurements with sar as bonnie, etc, causes builds to timeout. Problem: We're seeing slower then normal disk IO. At least I think we are. This is a PERC5/E and MD1000 array. When I try to do a normal copy cp -adv /mnt/koji/packages /tmp/ I get around 4-6MBytes/s This _might_ not be IO in a normal sense, -a to cp means: file data + file inode + ACLs + selinux + xattrs [+ file capabilities] ...esp. given that you aren't getting large IOWait times, you might want to strace -T the cp and do some perl/whatever on the result to see what is eating up the time. This is a straight 5.2, yeh? -- James Antill ja...@fedoraproject.org Fedora ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: OBS
On Fri, 2008-12-05 at 16:37 +0100, Xavier Lamien wrote: On Fri, Dec 5, 2008 at 3:26 PM, Mike McGrath [EMAIL PROTECTED] wrote: In case you guys are curious I just got a note that the OpenSuse Build Service now supports Fedora 10. I thought I'd pass it along. Any link || feedbacks ? http://liquidat.wordpress.com/2007/07/06/using-the-opensuse-build-service-for-fedora-packages/ http://en.opensuse.org/Build_Service/cross_distribution_package_how_to ...which implies it's been able to do Fedora builds for a while. However: http://en.opensuse.org/Build_Service/cross_distribution_package_how_to#Handling_dependencies ...doesn't give me warm happy feelings, heavily implying that you can't just take your Fedora spec file and have it work. I'd also assume that it's using yum and not zypp behind the scenes, but that's not 100% spelled out. -- James Antill [EMAIL PROTECTED] Fedora ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: [Server-devel] Tying yum to a package stream?
On Tue, 2008-10-14 at 15:57 +1300, Martin Langhoff wrote: On Tue, Oct 14, 2008 at 3:27 PM, seth vidal [EMAIL PROTECTED] wrote: you can use yum's priorities plugin to achieve similar results. It's a bit simpler than apt but I can sure work with this. Thanks! Just as in the apt-world configuring priorities/pinning for longterm/widespread use is a frelling nightmare. :-) -- well stated. If people mess with the repo configs we provide, install random rpms or play their Heavy Metal Rock records backwards, they void their warranty. To expand on what Seth is saying, if you are doing this on your local developer workstation etc. ... feel free to do whatever you want to override the normal behaviour from the repos. (that's what the features are there for). But if you are going to ship a repo to end users which requires/uses the yum-priority plugin (or excludes, or whatever), then the simple advise I would give you is: _don't_. Instead clone the Fedora repo. removing the packages you want to override, or even better get your changes into Fedora. -- James Antill [EMAIL PROTECTED] Fedora -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: [Server-devel] Tying yum to a package stream?
On Tue, 2008-10-14 at 16:48 +1300, Martin Langhoff wrote: On Tue, Oct 14, 2008 at 4:24 PM, James Antill [EMAIL PROTECTED] wrote: But if you are going to ship a repo to end users which requires/uses the yum-priority plugin (or excludes, or whatever), I am shipping a heavily preconfigured spin, the OLPC School Server. It points to the standard F9 repos, plus OLPCXS repos. So far we override... 1 package: ejabberd. Ok, that's kind of the worst case atm. ... I had assumed you'd be doing this to a lot more. then the simple advise I would give you is: _don't_. Can you tell me a bit more about why? (I definitely respect your technical advise, I'm trying to get more depth of info / experience on this...) There are two basic problems: 1. It's a lot less efficient to push the depsolving/repoclosure down to each client, instead of solving it once on the server. So from that point of view yum-priorities/etc. are _always_ going to give a worse experience, even if we have all the data, make the depsolver a full SAT solver while keeping it fast. 2. Fedora doesn't provide all of the data to make the above possible anyway, so for instance F-9 might have foo-1.0-1 and then updates for F-9 might release foo-1.0-2, foo-1.1-1, foo-1.2-1 ... by that point _only_ foo-1.0-1 and foo-1.2-1 will be available (one pkg/version from each repo.). This means that if your repo. has bar-xo-1.0 requires = foo-1.1 ... all the old xo repos. now become broken you have to rush out a fixed bar-xo and wait. You would still have problems if you did everything server side, but you'd actually be able to run repoclose/etc. and see the problem before it hit the clients ... and just not update your cloned repo. until you fixed it, with yum-priorities the first you'll see it is when all the clients don't work anymore. As it's a single package and this could expand to a couple more packages but no more, one alternative is to take that single package and rename it ejabberd-xs and set it to provide:ejabberd, conflicts:ejabberd. This is a lot better, in that it totally solves #1 above. #2 still applies (cross repo. deps. are the suck) although due to the rename it'll be to a lesser extent than trying to override packages with higher NEVRA. Of course how much the cross repo. deps. problem hits you depends a lot on the package, ejabberd doesn't look like it requires anything that might be upgraded in a bad way ... and has no deps. on itself. So there is a certain amount of try it, it'll probably work fine. I am already down that path with Moodle (moodle-xs), which I plan to maintain as a long-term heavily customised package. Instead clone the Fedora repo. removing the packages you want to override Quite a bit of work if I also want to give them access to sec updates in a timely fashion :-) and my conflict with Fedora packages is tiny. Yeh, I completely agree this is harder to do than it should be right now ... as an end game it'd be nice if there was a way so you could just publish a repo. which was Fedora - set of packages but all/most of the package hosting was done via. the Fedora mirrors etc. ... or even better get your changes into Fedora. In some cases Fedora won't want them as they are strictly local customisations -- such is the case of ejabberd and moodle. In others Fedorans are looking into integrating changes in their own timeframes (and I have my own release schedules to work for :-/ ). Is there any way you could make the changes be basically bolt on config. changes? so you have a ejabberd-config-xo or whatever? I'm guessing you already looked at that, but I thought I'd ask... It's a classic upstream/downstream game... Yeh, but think of it like Fedora vs. our upstream ... we copy all the .tar.gz files locally, because we need to be isolated from changes on their side. Ideally you'd do something similar to be isolated from changes on our side, not being able to do that starts you on the road to a bad place ... and yum-priorities is at the heart of the bad place :). -- James Antill [EMAIL PROTECTED] Fedora -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
