Re: new criterion proposal: core kickstart commands
On Thu, 6 Dec 2012, Adam Williamson wrote: I'm less concerned about changes in anaconda's UI if I know kickstart will continue functioning. Do I see two volunteers to help fix kickstart bugs? :) You see two people who are representative of the majority of linux users in the world - specifically sysadmins/devops people of various flavors. So I'd suspect there are a lot more of us than there are people who care about testing a linux desktop. -sv -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: new criterion proposal: core kickstart commands
On Thu, 6 Dec 2012, Matthew Miller wrote: On Wed, Dec 05, 2012 at 09:39:41PM -0800, Adam Williamson wrote: I think that may be the case _now_ with our current Anaconda situation, but the more I think about it, the more strongly I feel about making this the approach for future releases. When there's _not_ a big Anaconda rewrite, kickstart commands shouldn't change drastically without planning. So, I don't think it's unreasonable in the real world. The commands themselves shouldn't change, but it's certainly possible - and frequently happens - for something to change in anaconda or some layer below anaconda which happens to have the effect of breaking a kickstart directive. ... which should be a blocker. I agree with Matt. Kickstart is not only a lowest common denominator it is a critical functionality for tons of our testing and deployment tools. We don't want revolutionary change in kickstart and we definitely cannot have it be broken. Slow, gradual change properly documented is critical for kickstart. I'm less concerned about changes in anaconda's UI if I know kickstart will continue functioning. -sv -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: post install very slooow
On Sun, 11 Nov 2012, drago01 wrote: On Sat, Nov 10, 2012 at 4:42 PM, John Reiser wrote: I noticed the post install processing in f16 lasted only a few seconds, not the seemingly interminable wait a Fedora 18 install takes. If you have many partitions, then the grub2 operating system prober takes a while to construct grub.cfg: more than half a minute for my three dozen partitions. This is new with grub2 instead of grub. Most of the rest is yum, in two parts. The first is verifying that all the files named in all the packages actually did get installed. The second is constructing the yum database, which uses symbolic links in the filesystem. Look in /var/lib/yum/yumdb to see this monster. You'll notice that the harddrive LED stays on the whole time! Journalling all that is _expensive_. The yum "database" isn't really a database ... this kind of database design costs you that. There are lots of databases available no idea why yum had to invent its own non database and use it as a database. remember - yum has to work at install - so our options were bdb or sqlite. the filesystem made sense b/c anything else incurred a greater cost of having to setup and maintain a schema, forever and hope to be able to update it. The symlinks are actually hardlinks and that was to make it faster to traverse and setup. I understand you just wanted to rant, but I figured you should know that the costs of maintaining them in sqlite was significant, in bdb was mystical and in anything else was simply a dependency nightmare. -sv -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Some days it just doesn't pay to update
On Wed, 2011-08-31 at 17:15 -0600, Jonathan Corbet wrote: > On Wed, 31 Aug 2011 16:03:44 -0700 > Adam Williamson wrote: > > > it would probably help to know what *was* in the update set. > > OK, from yum.log: > while in this case yum.log is fine. I would like to encourage you to use the yum history database: yum history info will show complete details on the last transaction you ran. really quite handy. -sv -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: persistent gnome dep problems (F16 alpha rc3-5, alpha), --skip-broken wants to haul in 32-bit libs
On Thu, 2011-08-25 at 15:15 -0700, Adam Williamson wrote: > > > > yum --setopt="protected_multilib=0" blah blah blah > > > > which might help in situations where things are already deeply sideways. > > worth noting for the record that, as always when using 'force' type > parameters to a package management system, when it breaks - as it > inevitably will - you get a full refund of what you paid for it, and you > get to keep both pieces. =) generally, when yum wants to do something > really funky, the solution is not 'figure out how to let yum do it' but > 'figure out why yum wants to do something funky, and fix that'. > > (this is obviously not aimed at seth, who knows it already, but at the > thread in general.) turning off them protected multilib option is not a 'force type' option. All it does is allows yum to update one pkg w/o changing or matching the the compat arch of the same pkg, too. -sv -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: persistent gnome dep problems (F16 alpha rc3-5, alpha), --skip-broken wants to haul in 32-bit libs
On Thu, 2011-08-25 at 14:28 -0400, Dave Jones wrote: > On Thu, Aug 25, 2011 at 02:20:12PM -0400, seth vidal wrote: > > > > Dunno if that helps anybody... never a dull moment... > > > > When upgrading rawhide from X - use screen. > > and also when upgrading from ssh. > > things have definitely gotten a lot more fragile over the last > release or two. you can disable the multilib protection with: yum --setopt="protected_multilib=0" blah blah blah which might help in situations where things are already deeply sideways. -sv -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: persistent gnome dep problems (F16 alpha rc3-5, alpha), --skip-broken wants to haul in 32-bit libs
On Thu, 2011-08-25 at 11:12 -0600, Jonathan Corbet wrote: > On Wed, 24 Aug 2011 11:08:52 -0400 > Matthias Clasen wrote: > > > > Error: Protected multilib versions: > > > gnome-panel-libs-3.1.5-2.fc16.x86_64 != > > > gnome-panel-libs-3.0.2-3.fc16.i686 > > > > > > > I have no idea what these errors mean or how to fix them. > > Any advice would be appreciated. Actually, this one is kind of > > understandable, but I have also seen 'protected multilib' stuff where > > both sides of the != were the same arch, which left me wondering. > > I've worked my way through this kind of mess a couple of times now, most > recently yesterday. Here's my experience: > > - Do a big rawhide update - in this case, at least two weeks worth. > > - Somewhere in the middle, while I'm not looking, the update kills the >running session and/or X server - I come back to a login screen. It >used to be safe to run "yum update" from a terminal window, but, >seemingly, not anymore. Not really a step in the right direction. > > - If I try to rerun the update, it will tell me to try >yum-complete-transaction. Each time, actually trying that leads to an >infinite loop printing dependency information. > > - If I just run "yum update", I get the "protected multilib versions" >message. > > What I have found in these cases is that there are *two* versions of the > indicated library installed simultaneously (for the same architecture). > In each case, simply removing the older version clears the problem. Once > I've gotten past the gripes, the update actually works. > > Dunno if that helps anybody... never a dull moment... When upgrading rawhide from X - use screen. -sv -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: persistent gnome dep problems (F16 alpha rc3-5, alpha), --skip-broken wants to haul in 32-bit libs
On Wed, 2011-08-24 at 13:09 -0400, Tom Horsley wrote: > On Wed, 24 Aug 2011 17:26:44 +0100 > Richard Hughes wrote: > > > I'm seriously wondering if multilib is worth all this hassle... > > Oh I've never wondered that: It has clearly never been a good > idea. Starting with the total lack of documentation about how > the heck it actually works when (for instance) multilib rpms > both contain /usr/bin binaries of the same name and going > through all the problems it causes with updates (like these). It is documented it is just confusing When you have two pkgs sharing the same binary path - the pkg in the preferred/compat arch for that platform has its files installed. Except when you install them in the wrong order - and then rpm will cough out a conflict. This, I think, has been fixed in more recent changes but I'm not 100% certain of that. > > Seems to me the "problem" should always have been fixed > by simply packaging the rpms correctly with shared noarch > bits in one rpm, /lib bits in another, /lib64 bits in > another, and /bin bits in yet another. that doesn't fix the problem, though.; -sv -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F16 - why yum distro-sync wants to downgrade ?
On Wed, 2011-08-24 at 09:24 -0400, seth vidal wrote: > On Wed, 2011-08-24 at 06:40 +, JB wrote: > > Hi, > > > > could you please interpret what is happening here - why the downgrades ? > > > > $ cat /etc/fedora-release > > Fedora release 16 (Verne) > > > > $ yum repolist enabled > > ... > > repo id repo name status > > adobe-linux-i386 Adobe Systems Incorporated 18 > > fedoraFedora 16 - i38619,714 > > updates-testing Fedora 16 - i386 - Test Updates 2,596 > > repolist: 22,328 > > > Is it safe to assume you were on rawhide? > > If so - then you are ahead of f16 final. Sorry -not final, alpha. -sv -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F16 - why yum distro-sync wants to downgrade ?
On Wed, 2011-08-24 at 06:40 +, JB wrote: > Hi, > > could you please interpret what is happening here - why the downgrades ? > > $ cat /etc/fedora-release > Fedora release 16 (Verne) > > $ yum repolist enabled > ... > repo id repo name status > adobe-linux-i386 Adobe Systems Incorporated 18 > fedoraFedora 16 - i38619,714 > updates-testing Fedora 16 - i386 - Test Updates 2,596 > repolist: 22,328 Is it safe to assume you were on rawhide? If so - then you are ahead of f16 final. -sv -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: New BugZapper Introduction
On Fri, 2011-06-10 at 12:06 -0400, Mathieu Bouffard wrote: > On 06/10/2011 11:08 AM, Nick Jacek wrote: > > My name is Nick Jacek. This summer I'm an intern at Red Hat, where I'll be > > working on yum. > > Congrats and welcome. :P > Will you be working on the yum bacon command per chance? Mathieu, I'm sure you are joking but lest anyone get any clever ideas: there will not be any meat-eating related jokes in yum thanks, -sv -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: My Fedora 15 beta experiences so far
On Tue, 2011-05-31 at 08:56 -0500, Jason D. Clinton wrote: > On Tue, May 31, 2011 at 01:45, Pasha R wrote: > > Care to explain the logic behind this? Because it is really beyond my > > understanding. > > No, I don't. Your attitude is too antagonistic. I don't think there is anything antagonistic about his response at all. Jason, you've been fairly defensive in your replies and I don't see how this is helping fedora users or gnome. please consider being more careful in the tone of your responses. thanks, -sv -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Fedora 14 updates-testing report
On Wed, 2011-04-20 at 14:43 -0500, Michael Cronenworth wrote: > seth vidal wrote: > > wasteful to what? > > When I create updates in the future should I make them hundreds of lines > long like I'm in detention at school, too? I don't like resulting to > sarcasm, but I don't see how you see this as not wasteful. I mean - it's not waste unless there is a limit to the number of bits. you don't NEED to download the updateinfo to get the updates. -sv -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Fedora 14 updates-testing report
On Wed, 2011-04-20 at 14:35 -0500, Michael Cronenworth wrote: > upda...@fedoraproject.org wrote: > > > > cobbler-2.0.11-1.fc14 (FEDORA-2011-5680) > > Boot server configurator > > > > Update Information: > > > > New stable upstream release. See CHANGELOG for full description of updates. > > New upstream release, see CHANGELOG for complete description of changes. > > Upstream bug fix release. > > New upstream release, see CHANGELOG for full details > > > > Cobbler 2.0.4 release > [snip huge, wasteful changelog] > > Can someone edit this so it isn't garbage? > > It also looks like the RPM spec[1] changelog was not properly edited. > > [1] > http://pkgs.fedoraproject.org/gitweb/?p=cobbler.git;a=blobdiff;f=cobbler.spec;h=5fe3df22820a730465a976412011c2d3f8098219;hp=4eecb881280e5bd7c36ad5d454d14e2498b423f8;hb=4da91ec80994fd71e0fe7c40232417f71c9cd3af;hpb=f984a209680b749ad38c93bfeaa049e7bbc8ec2e wasteful to what? -sv -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: yum reinstall using non-identical packages with same EVR
On Sat, 2011-02-26 at 12:38 +, Andre Robatino wrote: > Starting with the current F14 deltarpm src rpm, I used rpmbuild to build > binary > rpms that use the new F15 xz compression. These have the same EVR as the > standard F14 binary rpms but require liblzma.so.5 instead of liblzma.so.0. In > a > yum shell transaction which includes the reinstall command to switch from the > liblzma.so.5 packages back to the standard liblzma.so.0 ones, I get dependency > errors stating that the deltarpm packages depend on liblzma.so.5, which > suggest > that yum is falsely assuming that the packages I'm reinstalling have the same > dependencies as the existing ones. Is this in fact what yum reinstall does? > Here > are the commands. Note the extra "run" which avoids the errors but which I > think > shouldn't be necessary. > > reinstall deltarpm.old/deltaiso-3.6-0.6.20110223git.fc14.x86_64.rpm > deltarpm.old/deltarpm-3.6-0.6.20110223git.fc14.x86_64.rpm > deltarpm.old/python-deltarpm-3.6-0.6.20110223git.fc14.x86_64.rpm > run > remove xz-compat-libs > downgrade xz.old/xz-4.999.9-0.2.beta.20100401git.fc14.x86_64.rpm > xz.old/xz-devel-4.999.9-0.2.beta.20100401git.fc14.x86_64.rpm > xz.old/xz-libs-4.999.9-0.2.beta.20100401git.fc14.x86_64.rpm > run > exit Just to make sure I understand you. You're changing the packages to have different requirements and you're NOT changing the evr of the pkg? Really? Don't do that. but even so - what dep errors are you getting? Can you include them? -sv -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Yum distro-sync makes more problems than solves
On Sat, 2011-02-12 at 22:34 +0100, Adam Pribyl wrote: > On Fri, 11 Feb 2011, Kevin Fenzi wrote: > > > > > Absolutely. Please do improve the page. ;) > > Done. > > > > >> IMHO there are three problems: > >> 1. keys needs to be imported per distro version > >> 2. "yum clean all" can not be followed by "yum update yum" but should > >> be switched, otherwise yum distro-sync is using incorrect metadata > >> 3. should remove --skip-broken and ask users to solve broken deps > >> before distro-sync as skipping brokens is not a solution > > > > Yep. I agree with all those things. > > Would like if somebody can review the page > https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum > > > kevin Just wanted to say to you and Kevin that y'all kinda kick ass. When I first read the subject I said "sigh, another rant." But in 3 or 4 msgs it has turned into a very positive outcome of improved documentation. thank you. -sv -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Skip-broken could not solve problems
On Sun, 2011-01-09 at 21:59 +, Adam Williamson wrote: > On Sun, 2011-01-09 at 21:03 +, Andre Robatino wrote: > > When running "yum --skip-broken update" and getting this message (currently > > in > > Rawhide), should it always be considered a bug and reported? > > Depends what you mean. If you mean 'is it a bug in yum', no. There are > some types of dependency issues that can't really sensibly be resolved > by ignoring some updates. It's clearly a bug in *something*, though. You > should treat each case individually, figure out what the ultimate root > of the problem is, and file a bug against the appropriate package. well some of them are a bug in yum. :) And, in theory, yes we should be able to walk it back. there's a couple of rawhide bugs which are ugly to trace out right now. -sv -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: rawhide report: 20110107 changes
On Fri, 2011-01-07 at 18:06 +0100, Thomas Spura wrote:
> On Fri, 07 Jan 2011 10:01:17 -0500
> seth vidal wrote:
>
> > On Fri, 2011-01-07 at 09:35 -0500, Andre Robatino wrote:
> > > Updating python on x86_64 tries to pull in 32-bit packages
> > > (including one i386):
> > >
> > > [r...@localhost ~]# yum update python
> > > Loaded plugins: downloadonly, langpacks, presto, refresh-packagekit,
> > > security
> > > Adding en_US to language list
> > > Setting up Update Process
> > > Resolving Dependencies
> > > --> Running transaction check
> > > ---> Package python.x86_64 0:2.7.1-1.fc15 will be updated
> > > --> Processing Dependency: python = 2.7.1-1.fc15 for package:
> > > tkinter-2.7.1-1.fc15.x86_64
> > > ---> Package python.i686 0:2.7.1-3.fc15 will be obsoleting
> > > --> Processing Dependency: python-libs(x86-32) = 2.7.1-3.fc15 for
> > > package: python-2.7.1-3.fc15.i686
> >
> > Looks like it is replacing python-argparse?
> >
> > An obsolete will pull in both archs, I believe.
> >
> > -sv
>
> Yes, it now has this in it:
> Provides: python-argparse = %{version}-%{release}
> Obsoletes: python-argparse < 1.1-3
>
> What would be the best solution for that now?
> Maybe this?:
> Provides: python-argparse = %{version}-%{release}%{?_isa}
>
> python-argparse itself was noarch, so this makes no sense either to
> me...
> (CC'ing fpc)
>
> At [1], there is no such case documented...
>
> Thomas
>
> [1]http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Renaming.2Freplacing_existing_packages
Thanks - I'd like to see what the FPC says.
-sv
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
Re: rawhide report: 20110107 changes
On Fri, 2011-01-07 at 09:35 -0500, Andre Robatino wrote: > Updating python on x86_64 tries to pull in 32-bit packages (including > one i386): > > [r...@localhost ~]# yum update python > Loaded plugins: downloadonly, langpacks, presto, refresh-packagekit, > security > Adding en_US to language list > Setting up Update Process > Resolving Dependencies > --> Running transaction check > ---> Package python.x86_64 0:2.7.1-1.fc15 will be updated > --> Processing Dependency: python = 2.7.1-1.fc15 for package: > tkinter-2.7.1-1.fc15.x86_64 > ---> Package python.i686 0:2.7.1-3.fc15 will be obsoleting > --> Processing Dependency: python-libs(x86-32) = 2.7.1-3.fc15 for > package: python-2.7.1-3.fc15.i686 Looks like it is replacing python-argparse? An obsolete will pull in both archs, I believe. -sv -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: yum update and zif
On Wed, 2011-01-05 at 16:54 -0700, Michal Jaegermann wrote: > On Wed, Jan 05, 2011 at 05:09:30PM -0600, Dennis Gilmore wrote: > > On Wednesday, January 05, 2011 04:32:02 pm Michal Jaegermann wrote: > > > This is from a changelog of yum-3.2.28-16.fc15: > > > * Tue Jan 04 2011 Seth Vidal - > > > * 3.2.28-15 > > > - latest head > > > - conflicts zif > > > > > > Only that "Zif is a simple yum-compatible library ..." > > > zif is not yum compatiable and it was using yum private data. > > The quoted text was from a zif package description. > > In any case you totally miss the point which was updating a system. > > > if yu want to > > use zif to manage your packages you must remove yum. > > I do not particularly care about zif and its documentation is > emphatic that it should not be used directly but only through yum > and/or PackageKit so, if its documentation is correct, installing > it by itself would be rather sensless. > > > you would have had to > > install it AFAIK though maybe packagekit brought it in at some > > point. > > That "maybe" is what is all of this is about. Otherwise I would not > even know that such thing exists. Okay - here's the scoop. Zif is something richard has been working on. It's a package manager - it's doing it's own depsolving and installation, etc. He started having zif touch some files that yum owns and therefore opening us up to lots of problems with it modifying them incorrectly so we added a conflict b/c it did conflict. There's been a bunch of discussion with richard today and we're working toward a solution. Looks likely that zif will be fixed to not touch yum's data. -sv -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: broken less
On Thu, 2010-12-23 at 16:54 +0100, Michał Piotrowski wrote: > Hi, > > less-436-7.fc14.x86_64 seems to be broken - anyone else see it? > but is it broken LESS or broken MORE? Zing! sorry, couldn't resist. -sv -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Preupgrade change?
On Mon, 2010-11-01 at 11:21 -0400, James Laska wrote: > On Mon, 2010-11-01 at 11:11 -0400, seth vidal wrote: > > On Sun, 2010-10-31 at 19:26 +, Richard Hughes wrote: > > > On 30 October 2010 19:48, Paul Frields wrote: > > > > * > > > > https://fedorahosted.org/preupgrade/changeset?new=data%40d42e6189dbe4ad7591d422f200a31ad196125dcc&old=data%404157e81ce428be819a957a31be5a19bcc6bd2efe > > > > Shouldn't Rawhide always stay in the list of releases? > > > > > > No, we can no longer preupgrade to rawhide. > > > > > > > > > What changed that keeps preupgrade from working to rawhide? > > Installation images are no longer provided for rawhide. I believe they > may be turned on at some point before we branch for F-15. I'd need to > double-check with rel-eng. > James, Thanks - I couldn't think of any other technical reason so I figured it was a policy decision of some kind. this makes sense. -sv -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Preupgrade change?
On Sun, 2010-10-31 at 19:26 +, Richard Hughes wrote: > On 30 October 2010 19:48, Paul Frields wrote: > > * > > https://fedorahosted.org/preupgrade/changeset?new=data%40d42e6189dbe4ad7591d422f200a31ad196125dcc&old=data%404157e81ce428be819a957a31be5a19bcc6bd2efe > > Shouldn't Rawhide always stay in the list of releases? > > No, we can no longer preupgrade to rawhide. > What changed that keeps preupgrade from working to rawhide? -sv -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Anybody has problems too with totem in F14?
On Fri, 2010-10-01 at 14:22 -0700, Adam Williamson wrote: > On Thu, 2010-09-30 at 14:15 -0500, John Watzke wrote: > > Actually I misspoke it's gtk2 that was changed not glib2. So I > > wonder if this is glib2 related at all since these packages fix the > > problem. > > are you sure you didn't also get a glib2 update in the mean time? There > has been one. yum history list glib2 will tell you which transactions last acted on glib2 -sv -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: why does "yum distro-sync" downgrade pidgin.i686 0:2.7.3-1.fc14 and libpurple.i686 0:2.7.3-1.fc14
On Wed, 2010-09-22 at 16:54 +0200, Joachim Backes wrote: > sudo egrep 'pidgin|libpurple' /var/log/yum.log > Aug 07 09:41:32 Installed: pidgin-2.7.2-1.fc14.i686 > Aug 13 07:14:40 Updated: libpurple-2.7.3-1.fc14.i686 > Aug 13 07:15:05 Updated: pidgin-2.7.3-1.fc14.i686 > Sep 22 16:22:00 Installed: libpurple-2.7.2-1.fc14.i686 > Sep 22 16:22:16 Installed: pidgin-2.7.2-1.fc14.i686 > > What's your opinion? that the version in f14 was rolled back for some reason? It's not unheard of. it looks like it is in pending https://admin.fedoraproject.org/updates/pidgin-2.7.3-2.fc14 -sv -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: why does "yum distro-sync" downgrade pidgin.i686 0:2.7.3-1.fc14 and libpurple.i686 0:2.7.3-1.fc14
On Wed, 2010-09-22 at 16:38 +0200, Joachim Backes wrote: > I runned because of curiosity reasons the command > > yum distro-sync, > > and this command downgraded the installed pidgin.i686 0:2.7.3-1.fc14 and > libpurple.i686 0:2.7.3-1.fc14 to > pidgin.i686 0:2.7.2-1.fc14 and libpurple.i686 0:2.7.2-1.fc14. > > What could be the reason for this? repoquery --releasever=14 --repoid=fedora --repoid=updates -q pidgin pidgin-0:2.7.2-1.fc14.x86_64 looks like 2.7.2-1 is the latest version in f14 updates. -sv -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Question: how to keep /var/lib/yum/plugins/local small?
On Mon, 2010-09-20 at 15:45 +0100, Frank Murphy wrote: > On 20/09/10 14:16, seth vidal wrote: > > repomanage -o /var/lib/yum/plugins/local | xargs rm -f > > Could this be added as a start up script? > in /etc/rc.local up to you, but there's no reason it couldn't be. -sv -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Question: how to keep /var/lib/yum/plugins/local small?
On Mon, 2010-09-20 at 16:22 +0200, Joachim Backes wrote: > On 09/20/2010 03:16 PM, seth vidal wrote: > > On Wed, 2010-09-15 at 09:28 +0200, Joachim Backes wrote: > >> On 09/15/2010 08:04 AM, Steven Haigh wrote: > >>> What plugins do you have installed? I only get: > >>> > >>> # pwd > >>> /var/lib/yum > >>> # du -hs * > >>> 1.2M history > >>> 0 rpmdb-indexes > >>> 4.0K uuid > >>> 9.0M yumdb > >>> > >> > >> Hi Steven, > >> > >> cd /var/lib/yum > >> sudo du -hs * > >> 4.6M history > >> 3.8G plugins > >> 296K rpmdb-indexes > >> 4.0K uuid > >> 19Myumdb > >> > >> Installed yum plugins: yum-plugin-local (has not been installed > >> explictly, but automatically!) > >> > > > > 1. yum-plugin-local is not installed automatically by anything > > 2. repomanage can help you keep the local repo to a reasonable size use: > > > > repomanage -o /var/lib/yum/plugins/local > > that will print out a list of the 'old packages' > > > > then: > >repomanage -o /var/lib/yum/plugins/local | xargs rm -f > > will remove them. > > > > then: > >createrepo -d --update /var/lib/yum/plugins/local > > > > will update the repo to remove those pkgs. > > Hi Seth, > > I'm sure I never applied consciously such commands as > repomanage or createrepo, nor installed yum-plugin-local :-) easy way to find out: yum history info yum-plugin-local see what transaction brought it in. -sv -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Grrr... modprobe.conf
On Mon, 2010-09-20 at 09:53 -0400, Tom Horsley wrote: > > > In the yum.log I see the time on modprobe.conf occurs > > > in a gap in the yum updates: > > > > > > Aug 25 19:37:56 Updated: xorg-x11-drv-aiptek-1.3.1-1.fc14.x86_64 > > > Aug 25 20:02:56 Updated: libgcc-4.5.1-1.fc14.x86_64 > > > > The fix for https://bugzilla.redhat.com/show_bug.cgi?id=589593 was pushed > > to F14 > > updates-testing on Aug. 23. Does yum.log show when system-config-network was > > updated? > > Aug 25 20:05:06 Updated: system-config-network-tui-1.6.1-1.fc14.noarch > Aug 25 20:16:10 Updated: system-config-network-1.6.1-1.fc14.noarch > Instead of searching the yum log - how about using yum history: yum history info system-config-network\* | less That'll list all the transactions that changed system-config-network* -sv -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Question: how to keep /var/lib/yum/plugins/local small?
On Wed, 2010-09-15 at 09:28 +0200, Joachim Backes wrote: > On 09/15/2010 08:04 AM, Steven Haigh wrote: > > What plugins do you have installed? I only get: > > > > # pwd > > /var/lib/yum > > # du -hs * > > 1.2Mhistory > > 0 rpmdb-indexes > > 4.0Kuuid > > 9.0Myumdb > > > > Hi Steven, > > cd /var/lib/yum > sudo du -hs * > 4.6M history > 3.8G plugins > 296K rpmdb-indexes > 4.0K uuid > 19M yumdb > > Installed yum plugins: yum-plugin-local (has not been installed > explictly, but automatically!) > 1. yum-plugin-local is not installed automatically by anything 2. repomanage can help you keep the local repo to a reasonable size use: repomanage -o /var/lib/yum/plugins/local that will print out a list of the 'old packages' then: repomanage -o /var/lib/yum/plugins/local | xargs rm -f will remove them. then: createrepo -d --update /var/lib/yum/plugins/local will update the repo to remove those pkgs. -sv -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: heads-up: upstart reversion coming soon
On Thu, 2010-09-16 at 11:51 +0100, Adam Williamson wrote: > On Wed, 2010-09-15 at 18:41 -0400, Richard Ryniker wrote: > > > since the current justification for having stable releases at all > > > is 'to handle upgrade cases we can't handle with yum' > > > > What about installation from media such as DVD for users who cannot > > reasonably access more than a gigabyte of updates from the Net? > > Frankly, we're not a very good distribution for people who can't > reasonably access more than a gigabyte of updates from the Net, since we > *frequently* provide that much or more within a release cycle. We provide more than a gigabyte of updates in a MONTH. -sv -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: nss in updates-testing - more problems
On Thu, 2010-09-16 at 10:24 -0400, Genes MailLists wrote: > On 09/16/2010 09:48 AM, Michael Schwendt wrote: > > So, you should not have installed nss-tools.i686 manually. > > Ah - but yum update did not work without installing it. I imagine when > I added the i686 libs - I did not do it right ... > > I could find no clean way to make the box multiarch aside from adding > missing libs that the 32 bit apps called for .. > > Is there a correct way to install all i686 libs for which I have x86_64 > ? Something like yum --multiarch=i686 install-libs. > > There must be a proper way to make a box multi-arch - it was not an > option during install as far as I could tell. > > What do you recommend I do now to clean up - Heres what I have > installed (those whose names start with nss): multilib_policy=all in yum.conf [main] it's in the man page. -sv -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs. / Every OS sucks!
On Wed, 2010-09-08 at 23:18 -0500, John Morris wrote: > Sorry everyone, time to vent. > > Bah. This is why I just blocked kernel updates in the first place. > Tried updating now things are worse due to a bad combination of > Fedora policy multiplied by my own stupidity. I KNEW you were supposed > to make darned sure you were running your favorite kernel before letting > yum loose. (Don't ask, long story) That was mistake number one. Number > two came when I looked to the backup server and found to my horror I > fumbled that too, / and /home safely backed up but no /boot! Double > crap! > > So now I lost the only kernel package where everything worked. And of > course Fedora doesn't have it anymore. You can pick the original > package or the current update. Triple crap! If anyone has a pointer > to kernel-2.6.31.12-174.222.x86_64.rpm I'd really appreciate it! > Google, rpmfind, etc. all come up blank as did manually poking around on > the Fedora mirrors. yum install yum-plugin-local then every pkg you install or update on your system will be saved to a local repo and will be available to you via that repo. it sucks the disk space up, obviously but you can clean it up at your leisure. -sv -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Which bugzilla component?
On Wed, 2010-09-08 at 10:07 -0700, John Poelstra wrote: > I tried to run virt-manager as a regular user on a machine that does not > have it installed. > > $ virt-manager > Command not found. > * Cancelling.. The transaction failed: internal-error, The backend > exited unexpectedly. This is a serious error as the spawned backend did > not complete the pending transaction. > > > Which component in bugzilla should I file a bug against to improve this > overly cryptic technical error message--obviously virt-manager isn't it. that's probably PK, actually. Since if the command is not it spawns that pk command search thing. -sv -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Where is runlevel 5?
On Thu, 2010-08-26 at 08:36 -0500, Adam Miller wrote: > I disagree, there really is only so much we as an internet based > community can do to help the users and publicly providing the > documentation in multiple outlets is about as good as it gets. I don't > have everyone's phone number who downloaded the Alpha image so I'm not > able to call them individually and warn them of the changelog. I think the point is that the one thing we can do to help users is to "throw it all away and start over" LESS often. -sv -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: bizarre yum
On Wed, 2010-08-11 at 23:15 -0400, Felix Miata wrote: > 1-updated F13/KDE system this AM. > > 2-cloned the F13 partition to another partition > > 3-changed the clone's UUID > > 4-adjusted the clone's grub.conf & fstab, then booted it > > 5-rpm -Uvh fedora-release-14-0.7.noarch.rpm > > 6-yum update yum rpm (fails) > > 7-yum update yum rpm --nogpgcheck --skip-broken > > Result: > 119 packages installed, among them freetype, kde, fontconfig-devel, akonadi, > qt-webkit, libXinerama-devel, libchamplain-gtk, amarok, qt-webkit, BackupPC, > compat-gdbm > > What happened? Brain fart, bug(s), or is this expected? Gonna need a lot more information to diagnose this. What 'failed' with the step 6? -sv -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F13 > F14-Br with Yum
On Mon, 2010-08-02 at 09:44 +0100, Frank Murphy wrote: > XFCE > Although Yum updated to F14-Br, it stayed with py2.6 > Had to use rpm\yum\apt to get a full working py2.7 system. > > If enough interest I cut put it up somewhere. > I'm curious what the process looked like that required the use of rpm or apt. Pasting the output to a pastebin would be appreciated. -sv -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: QA recommendations for F-14
On Thu, 2010-06-24 at 10:24 -0500, Jason L Tibbitts III wrote: > > "AJ" == Adam Jackson writes: > > AJ> Do people really not do VNC installs? > > Since everyone else is chiming in... I have never done anything other > than VNC installs. I'm not even sure what a regular install looks like. It looks like VNC - except on the monitor that the machine has connected directly. :) -sv -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: QA recommendations for F-14
On Thu, 2010-06-24 at 08:05 -0700, Adam Williamson wrote: > On Thu, 2010-06-24 at 09:48 -0400, Adam Jackson wrote: > > > > I'd really rather not, it's still necessary in quite a lot of cases. My > > > laptop, fr'instance, where intel or nouveau (or both, depending which > > > graphics adapter you select) will cheerfully try to load, but fail > > > miserably and leave the system non-functional. I'd much rather get a > > > full install with VESA than a minimal text install, which would be my > > > only option if you killed 'basic video driver' install. > > > > Do people really not do VNC installs? > > I don't think it's particularly common. It's certainly not as evident a > choice as 'basic video driver', and if you don't use VNC regularly > anyway it's not necessarily going to pop into your mind as an obvious > option. And not everyone has two machines handy at all times. the vnc install is excellent for server installs - but that's mostly just for monitoring a kickstart - not for involved use (at least that's been my experience) -sv -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
