Re: conflict between latest fedora-release and systemd (rawhide)

[Kevin Martin]

On 06/10/2015 10:51 PM, Kevin Martin wrote:
 On 05/22/2015 10:52 PM, Kevin Martin wrote:
 On 05/22/2015 04:53 PM, Kevin Fenzi wrote:
 On Fri, 22 May 2015 16:50:19 -0500
 kevin martin ktm...@gmail.com wrote:

 ...snip...


 Looks like somebody decided to move the 90-default.preset from
 systemd to the fedora-release package without changing the systemd
 package to reflect that and pushing out a new package (as discussed
 about a year ago).

 This was fixed in 
 http://koji.fedoraproject.org/koji/buildinfo?buildID=638190

 (systemd-219-14)

 It should have been in the rawhide compose, but you can get it from
 koji if not. 

 (Or just get systemd-220, but it has some selinux issues going on)

 kevin



 Thanks for the info.

 Kevin

 Tried getting the koji build but there were too many dependency issues to 
 install it and I'm still not getting a Rawhide version
 that can be installed.  Still getting:
 
 Error: Transaction check error:
   file /usr/lib/systemd/system-preset/90-default.preset from install of 
 fedora-release-23-0.13.noarch conflicts with file from
 package systemd-219-13.fc23.x86_64
 
 Error Summary
 -
 
 
 Regards,
 
 Kevin
 
I upgraded fedora-release and can now run an upgrade of my system but it still 
never gets a systemd upgrade past systemd-219-13.  Is
that the latest rawhide version?

Thanks

Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: conflict between latest fedora-release and systemd (rawhide)

[Kevin Martin]

On 05/22/2015 10:52 PM, Kevin Martin wrote:
 On 05/22/2015 04:53 PM, Kevin Fenzi wrote:
 On Fri, 22 May 2015 16:50:19 -0500
 kevin martin ktm...@gmail.com wrote:

 ...snip...


 Looks like somebody decided to move the 90-default.preset from
 systemd to the fedora-release package without changing the systemd
 package to reflect that and pushing out a new package (as discussed
 about a year ago).

 This was fixed in 
 http://koji.fedoraproject.org/koji/buildinfo?buildID=638190

 (systemd-219-14)

 It should have been in the rawhide compose, but you can get it from
 koji if not. 

 (Or just get systemd-220, but it has some selinux issues going on)

 kevin



 Thanks for the info.
 
 Kevin
 
Tried getting the koji build but there were too many dependency issues to 
install it and I'm still not getting a Rawhide version
that can be installed.  Still getting:

Error: Transaction check error:
  file /usr/lib/systemd/system-preset/90-default.preset from install of 
fedora-release-23-0.13.noarch conflicts with file from
package systemd-219-13.fc23.x86_64

Error Summary
-


Regards,

Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: conflict between latest fedora-release and systemd (rawhide)

[kevin martin]

Specifically:

Failed to synchronize cache for repo 'rpmfusion-free-updates' from '
http://mirrors.rpmfusion.org/mirrorlist?repo=free-fedora-updates-released-rawhidearch=x86_64':
Cannot prepare internal mirrorlist: No URLs in mirrorlist, disabling.
Failed to synchronize cache for repo 'rpmfusion-nonfree' from '
http://mirrors.rpmfusion.org/mirrorlist?repo=nonfree-fedora-rawhidearch=x86_64':
Cannot prepare internal mirrorlist: No URLs in mirrorlist, disabling.
Failed to synchronize cache for repo 'rpmfusion-nonfree-updates' from '
http://mirrors.rpmfusion.org/mirrorlist?repo=nonfree-fedora-updates-released-rawhidearch=x86_64':
Cannot prepare internal mirrorlist: No URLs in mirrorlist, disabling.
Last metadata expiration check performed 1:41:07 ago on Fri May 22 15:05:31
2015.
Dependencies resolved.

 Package  Arch   Version  Repository
Size

Upgrading:
 device-mapperx86_64 1.02.97-1.fc23   rawhide
248 k
 device-mapper-event  x86_64 1.02.97-1.fc23   rawhide
193 k
 device-mapper-event-libs x86_64 1.02.97-1.fc23   rawhide
195 k
 device-mapper-libs   x86_64 1.02.97-1.fc23   rawhide
308 k
 fedora-release   noarch 23-0.13  rawhide
 15 k
 fedora-release-servernoarch 23-0.13  rawhide
 12 k
 lvm2 x86_64 2.02.120-1.fc23  rawhide
988 k
 lvm2-libsx86_64 2.02.120-1.fc23  rawhide
868 k

Transaction Summary

Upgrade  8 Packages

Total download size: 2.8 M
Is this ok [y/N]: Downloading Packages:

Total   465 kB/s | 2.3 MB 00:05

Delta RPMs reduced 2.8 MB of updates to 2.3 MB (15.1% saved)
Running transaction check
Transaction check succeeded.
Running transaction test
Error: Transaction check error:
  file /usr/lib/systemd/system-preset/90-default.preset from install of
fedora-release-23-0.13.noarch conflicts with file from package
systemd-219-13.fc23.x86_64

Error Summary
-


Looks like somebody decided to move the 90-default.preset from systemd to
the fedora-release package without changing the systemd package to reflect
that and pushing out a new package (as discussed about a year ago).

Kevin

On Fri, May 22, 2015 at 4:06 PM, kevin martin ktm...@gmail.com wrote:

 Just an FYI, the latest rawhide update gives an error about 
 usr/lib/systemd/system-preset/90-default.preset
 conflicting between the .13 version of fedora-release and systemd.

 Regards,

 Kevin

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

conflict between latest fedora-release and systemd (rawhide)

[kevin martin]

Just an FYI, the latest rawhide update gives an error about
usr/lib/systemd/system-preset/90-default.preset
conflicting between the .13 version of fedora-release and systemd.

Regards,

Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: On/Off problems

[Kevin Martin]

On 11/20/2014 09:05 AM, Lawrence E Graves wrote:
 There is no log to test the results of  this but my computer or laptop 
 running Fedora 21 Beta RC4 will not shutdown or restart. If
 this is my fault, please let me know what to do to fix this problem. If it is 
 not my fault, I guessing I am reporting a bug.
 Thanking you in advance for your help.
 
Lawrence,

 There was a bug reported not that long ago with, I think, systemd, that got a 
fix for this problem.  Have you yum/dnf updated recently?

Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Big problems with the lpr or lp command in F21 since some days: only empty sheets are printed: More details

[Kevin Martin]

-Original Message-
From: Joachim Backes joachim.bac...@rhrk.uni-kl.de
To: Fedora-test test@lists.fedoraproject.org
Sent: Wed, 29 Oct 2014 7:06 AM
Subject: Re: Big problems with the lpr or lp command in F21 since some days: 
only empty sheets are printed: More details

On 10/29/2014 12:22 PM, Joachim Backes wrote:
 Dear F21 testers,
 
 having big problems with printing using the lp or lpd command since 2 or
 3 days: Only empty pages are printed. This happens for my real samsung
 printer or with a cups-PDF printer.
 
 On the other hand, printing to these printers from applications such as
 firefox, thunderbird,... (using the print menu) is OK.
 
 My F21 is fully updated. I downgraded already cups-client (current is
 cups-client-1.7.5-13.fc21.x86_64), but this did not help.
 
 Anybody has these problems too?
 
 Kind regards
 
 Joachim Backes
 

Some more details: If printing to the printers: PS or PDF files are
printed too by lp / lpr, but if I try to print simple text files, only
empty pages are printed.

Joachim Backes

-- 

Fedora release 21 (Twenty One)
Kernel-3.17.1-304.fc21.x86_64


Joachim Backes joachim.bac...@rhrk.uni-kl.de
https://www-user.rhrk.uni-kl.de/~backes
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test



I don't even get a blank page.  I see the printer doing something but nothing 
comes out.  And like you printing from an application works fine.  Cups 
debugging shows nothing.

Kevin-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: can someone suggest why firefox is so $*^%*#^%* slow?

[Kevin Martin]

On 09/24/2014 09:44 AM, Robert P. J. Day wrote:
 
   i am at my wit's end with firefox on my fedora rawhide system -- to
 say it's nad-grindingly slow would be charitable. just now, i tried
 clicking on another tab ... some 30 seconds later, i am still waiting
 for the tab to change, oh, wait, there it is.
 
   watching any sort of youtube video is excruciating ... while audio
 is typically, i will frequently get *maybe* one frame change a second,
 i kid you not. i frequently get javascripts that are not responding,
 and i'm asked whether i want to wait for them.
 
   is there *something* i can do to debug this? what firefox
 configuration settings should i be looking at? i'm willing to try
 anything because, at this point, firefox is utterly unusable. even
 something as simple as scrolling in a window is painfully slow.
 
   oh, and i'm on a quad core i7, so i'm pretty sure horsepower isn't
 the problem.
 
 rday
 
I see this happen when Firefox starts eating memory.  top will show Firefox 
using upwards of a GB of ram...I restart it and then
it's good to go for a couple of days.

Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

jackson-annotations update problem via yum

[Kevin Martin]

When trying to update jackson-annotations via yum I continue to receive the 
following errors:

http://mirrors.mit.edu/fedora/linux/development/rawhide/x86_64/os/Packages/j/jackson-annotations-2.4.1-1.fc21.noarch.rpm:
 [Errno 14]
HTTP Error 416 - Requested Range Not Satisfiable
Trying other mirror.
http://mirrors.ptd.net/fedora/linux/development/rawhide/x86_64/os/Packages/j/jackson-annotations-2.4.1-1.fc21.noarch.rpm:
 [Errno 14]
HTTP Error 416 - Requested Range Not Satisfiable
Trying other mirror.
http://mirror.nexcess.net/fedora/development/rawhide/x86_64/os/Packages/j/jackson-annotations-2.4.1-1.fc21.noarch.rpm:
[Errno 14] HTTP Error 416 - Requested Range Not Satisfiable
Trying other mirror.
http://mirrors.solfo.com/fedora/development/rawhide/x86_64/os/Packages/j/jackson-annotations-2.4.1-1.fc21.noarch.rpm:
 [Errno 14]
HTTP Error 416 - Requested Range Not Satisfiable
Trying other mirror.
http://mirrors.kernel.org/fedora/development/rawhide/x86_64/os/Packages/j/jackson-annotations-2.4.1-1.fc21.noarch.rpm:
[Errno 14] HTTP Error 416 - Requested Range Not Satisfiable
Trying other mirror.
http://fedora.mirror.nexicom.net/linux/development/rawhide/x86_64/os/Packages/j/jackson-annotations-2.4.1-1.fc21.noarch.rpm:
 [Errno
14] HTTP Error 416 - Requested Range Not Satisfiable
Trying other mirror.
https://mirror.dmacc.net/fedora/development/rawhide/x86_64/os/Packages/j/jackson-annotations-2.4.1-1.fc21.noarch.rpm:
 [Errno 14]
HTTPS Error 416 - Requested Range Not Satisfiable
Trying other mirror.
ftp://mirror.cs.princeton.edu/pub/mirrors/fedora/linux/development/rawhide/x86_64/os/Packages/j/jackson-annotations-2.4.1-1.fc21.noarch.rpm:
[Errno 14] curl#36 - Offset (43452) was beyond file size (42348)
Trying other mirror.
http://mirror.symnds.com/distributions/fedora/development/rawhide/x86_64/os/Packages/j/jackson-annotations-2.4.1-1.fc21.noarch.rpm:
[Errno 14] HTTP Error 416 - Requested Range Not Satisfiable
Trying other mirror.
ftp://ftp.gtlib.gatech.edu/pub/fedora.redhat/linux/development/rawhide/x86_64/os/Packages/j/jackson-annotations-2.4.1-1.fc21.noarch.rpm:
[Errno 14] curl#36 - Offset (43452) was beyond file size (42348)
Trying other mirror.
http://mirror.cc.vt.edu/pub/fedora/linux/development/rawhide/x86_64/os/Packages/j/jackson-annotations-2.4.1-1.fc21.noarch.rpm:
[Errno 14] HTTP Error 416 - Requested Range Not Satisfiable
Trying other mirror.
http://fedora.bhs.mirrors.ovh.net/linux/development/rawhide/x86_64/os/Packages/j/jackson-annotations-2.4.1-1.fc21.noarch.rpm:
 [Errno
14] HTTP Error 416 - Requested Range Not Satisfiable
Trying other mirror.
http://mirror.uoregon.edu/fedora/linux/development/rawhide/x86_64/os/Packages/j/jackson-annotations-2.4.1-1.fc21.noarch.rpm:
 [Errno
14] HTTP Error 416 - Requested Range Not Satisfiable
Trying other mirror.
http://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/x86_64/os/Packages/j/jackson-annotations-2.4.1-1.fc21.noarch.rpm:
[Errno 14] HTTP Error 416 - Requested Range Not Satisfiable
Trying other mirror.
http://mirrors.cat.pdx.edu/fedora/linux/development/rawhide/x86_64/os/Packages/j/jackson-annotations-2.4.1-1.fc21.noarch.rpm:
 [Errno
14] HTTP Error 416 - Requested Range Not Satisfiable
Trying other mirror.
http://www.gtlib.gatech.edu/pub/fedora.redhat/linux/development/rawhide/x86_64/os/Packages/j/jackson-annotations-2.4.1-1.fc21.noarch.rpm:
[Errno 14] HTTP Error 416 - Requested Range Not Satisfiable
Trying other mirror.
http://mirror.metrocast.net/fedora/linux/development/rawhide/x86_64/os/Packages/j/jackson-annotations-2.4.1-1.fc21.noarch.rpm:
[Errno 14] HTTP Error 416 - Requested Range Not Satisfiable
Trying other mirror.
http://mirror.seas.harvard.edu/fedora/linux/development/rawhide/x86_64/os/Packages/j/jackson-annotations-2.4.1-1.fc21.noarch.rpm:
[Errno 14] HTTP Error 416 - Requested Range Not Satisfiable
Trying other mirror.
ftp://mirror.nexicom.net/pub/fedora/linux/development/rawhide/x86_64/os/Packages/j/jackson-annotations-2.4.1-1.fc21.noarch.rpm:
[Errno 14] curl#7 - Failed to connect to mirror.nexicom.net port 21: 
Connection refused
Trying other mirror.
http://mirror.cs.pitt.edu/fedora/linux/development/rawhide/x86_64/os/Packages/j/jackson-annotations-2.4.1-1.fc21.noarch.rpm:
 [Errno
14] HTTP Error 416 - Requested Range Not Satisfiable
Trying other mirror.
Error downloading packages:

  jackson-annotations-2.4.1-1.fc21.noarch: [Errno 256] No more mirrors to try.

If I go to one of the ftp mirrors and download the package and then also 
download the package from pbone.net they are different
sizes.  The version from pbone.net installs using a local install.  I didn't 
try to install the version downloaded by hand from the
ftp mirror since yum seems to indicate that it's not a valid package.  
Interestingly, the package that I downloaded from pbone.net
is size 43452 which is specifically one of the errors that yum complains about 
when trying to download from the ftp mirrors:

 [Errno 14] curl#36 - Offset (43452) was beyond file size (42348)

yum error during update (Fatal Error TypeError)

[Kevin Martin]

yum clean all doesn't help, I'll start with that.

The following error occurred with yum update today:

Running transaction check
Running transaction test
TypeError: an integer is required
FATAL ERROR: python callback bound method RPMTransaction.callback of 
yum.rpmtrans.RPMTransaction instance at 0x7f5fbbc3cb00
failed, aborting!


I saw this yesterday as well so decided to try to update each package one at a 
time to see which package this error occurs for.
Interestingly, it's more than one:

===
 Package
   Arch  Version
 Repository  Size
===Updating:
 plexus-containers-component-javadocnoarch1.5.5-18.fc21 
  rawhide 19 k

Transaction Summary
===Upgrade
  1
Package

Total download size: 19 k
Downloading packages:
Finishing delta rebuilds of 1 package(s) (19 k)
Some delta RPMs failed to download or rebuild. Retrying..
plexus-containers-component-javadoc-1.5.5-18.fc21.noarch.rpm
|  19 kB  00:00:00
Running transaction check
Running transaction test
TypeError: an integer is required
FATAL ERROR: python callback bound method RPMTransaction.callback of 
yum.rpmtrans.RPMTransaction instance at 0x7f96fb7ca200
failed, aborting!



===
 Package
Arch  Version
Repository  Size
===Updating:
 seedx86_643.8.1-4.fc22 
  rawhide192 k

Transaction Summary
===Upgrade
  1
Package

Total download size: 192 k
Downloading packages:
Finishing delta rebuilds of 1 package(s) (192 k)
Some delta RPMs failed to download or rebuild. Retrying..
seed-3.8.1-4.fc22.x86_64.rpm
| 192 kB  00:00:00
Running transaction check
Running transaction test
TypeError: an integer is required
FATAL ERROR: python callback bound method RPMTransaction.callback of 
yum.rpmtrans.RPMTransaction instance at 0x7fb7d4c1b830
failed, aborting!


===
 Package
Arch Version  
Repository Size
===Updating:
 setuptool   x86_64   1.19.11-9.fc22
   rawhide65 k

Transaction Summary
===Upgrade
  1
Package

Total download size: 65 k
Downloading packages:
Finishing delta rebuilds of 1 package(s) (65 k)
Some delta RPMs failed to download or rebuild. Retrying..
setuptool-1.19.11-9.fc22.x86_64.rpm 
|  65 kB  00:00:00
Running transaction check
Running transaction test
TypeError: an integer is required
FATAL ERROR: python callback bound method RPMTransaction.callback of 
yum.rpmtrans.RPMTransaction instance at 0x7fcf0c7541b8
failed, aborting!


===
 Package
Arch Version  
Repository Size
===Updating:
 sgpio   x86_64   1.2.0.10-14.fc22  
   rawhide18 k

Transaction Summary
===Upgrade
  1
Package

Total download size: 18 k
Downloading packages:
Finishing delta rebuilds of 1 package(s) (18 k)
Some delta RPMs failed to download or rebuild. Retrying..
sgpio-1.2.0.10-14.fc22.x86_64.rpm   
|  18 kB  00:00:00
Running transaction check
Running transaction test
TypeError: an integer is required
FATAL ERROR: python callback bound method 

Re: Consistent names changed yet again?

[Kevin Martin]

On 08/06/2014 07:08 AM, Tom Horsley wrote:
 On Wed, 6 Aug 2014 07:55:55 -0400
 Matthew Miller wrote:
 
 consistent on the same machine for a given OS release,
 _across any possible hardware changes_
 
 Maybe, but I know I watched the interface names change
 just because a new version of bisodevname was released
 before biosdevname was engulphed by systemd. I wouldn't
 be surprised at all to see a systemd update change
 the names as well :-(.
 
 I also love the new systemd conventions that give me
 a different consistent name for my USB wifi dongle
 depending on which USB port I plug it into :-).
 
 http://home.comcast.net/~tomhorsley/game/biosdevname.html
 
I was having the same issue and finally resolved to make sure that my 
consistent ethernet device was named eth0.  I did that with
the following line in /etc/udev/rules.d/70-my-net-names.rules:

SUBSYSTEM==net, ACTION==add, DRIVERS==?*, 
ATTR{address}==c8:0a:a9:b1:46:c2, ATTR{dev_id}==0x0, ATTR{type}==1, 
NAME=eth0

Thereby forcing my device with that mac address to have name eth0.  dmesg shows 
udev/systemd changing this:

[3.975997] systemd-udevd[232]: renamed network interface eth0 to p6p1
[   21.108994] systemd-udevd[421]: renamed network interface p6p1 to eth0

YMMV.

Kevin

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Consistent names changed yet again?

[Kevin Martin]

On 08/06/2014 09:32 AM, Scott Robbins wrote:
 On Wed, Aug 06, 2014 at 02:38:30PM +0200, Adam Williamson wrote:

 In Fedora 21 we've more or less dropped biosdevname in favour of
 systemd. systemd's system is a cleaner implementation and the weight of
 opinion favours the systemd approach to naming. See the discussion from
 https://bugzilla.redhat.com/show_bug.cgi?id=965718#c76 onwards.

 From F21 onwards new Fedora installations should reliably result in the
 use of the systemd naming scheme. Existing installs that use biosdevname
 will continue to use it (with the same naming scheme, obviously) unless
 the admin intervenes.

 We should probably put this in the release notes.
 
 Currently, as I understand it, to get back the eth0 naming scheme, one has
 remove biosdevname as well as add the net.ifnames=0.  Does that mean that 
 with F21, we will no longer need the step of rpm -e biosdevname?
 
 The term more or less seems a bit unclear.  
 I'm looking at
 https://fedoraproject.org/wiki/Documentation_Networking_Beat as well as the
 bug report linked above, and from *that*, it looks as if it will no longer
 be necessary for the rpm -e biosdevname step.
 
 Thanks
 
 
Hmm, I have biosdevname installed (and always have) and have never put 
net.ifnames=0 anywhere that I'm aware of.  I've used the
syntax that I put thru earlier since F19 and I'm now on F22.

Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

dnf errors that yum doesn't get...

[Kevin Martin]

I'm consistently seeing errors like the following when using dnf in rawhide 
these days:

[MIRROR] dyninst-8.1.2-10.fc21.x86_64.rpm: Downloading successfull, but 
checksum doesn't match. Expected:
667463e85707f75cbd32c24cb484226ab623dd626b2a23721d45ab5877b92d6d(sha256)
[MIRROR] dyninst-8.1.2-10.fc21.x86_64.rpm: Downloading successfull, but 
checksum doesn't match. Expected:
667463e85707f75cbd32c24cb484226ab623dd626b2a23721d45ab5877b92d6d(sha256)
[MIRROR] PyQt4-4.11.1-1.fc21.x86_64.rpm: Downloading successfull, but checksum 
doesn't match. Expected:
86dfd0ddf339e87cb9815c70b568483318c9f6b3ddb0b0326af9b6e2175f0bae(sha256)
[MIRROR] dyninst-8.1.2-10.fc21.x86_64.rpm: Downloading successfull, but 
checksum doesn't match. Expected:
667463e85707f75cbd32c24cb484226ab623dd626b2a23721d45ab5877b92d6d(sha256)
[MIRROR] PyQt4-4.11.1-1.fc21.x86_64.rpm: Downloading successfull, but checksum 
doesn't match. Expected:
86dfd0ddf339e87cb9815c70b568483318c9f6b3ddb0b0326af9b6e2175f0bae(sha256)


When I run a yum update (with skip-broken) I get this:

Transaction Summary
=Install
 ( 1 Dependent package)
Upgrade   8 Packages
Remove4 Packages
Skipped (dependency problems)  1004 Packages

Perhaps the problem is that dnf doesn't have a skip-broken option?  dnf upgrade 
with everything set the same as yum update (as far
as repos and everything else) gives me:

Transaction Summary
=
Install   24 Packages
Upgrade  978 Packages
Remove 4 Packages
Total size: 1.0 GTotal download size: 828 M


my dnf settings are:

[main]
gpgcheck=1
installonly_limit=3
clean_requirements_on_remove=true
deltarpm=true
metadata_expire=-1


is there something else I need in there to enforce skipping broken 
packages/dependency issues?



-- 

Regards,


Kevin Martin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: dnf cache is very large....

[Kevin Martin]

On 07/16/2014 12:26 PM, Rahul Sundaram wrote:
 Hi
 
 
 On Wed, Jul 16, 2014 at 1:13 PM, Kevin Martin wrote:
 
 
 I assume this is not planned nor correct (since my yum cache is much 
 smaller) but can't seem to clear it out with any of the dnf
 commands. Â How can I clear this up gracefully?
 
 
 This should really be reported as a bug against dnf.
 
 Rahul
 
 
ok, did not know if this was a planned result or not.

Thanks.

Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

dnf errors or kernel* rpm problems?

[Kevin Martin]

dnf upgrade doesn't show an error while updating the kernel packages but there 
are missing entries in grub2.conf after an upgrade
that should be for the new kernel that was downloaded and, supposedly, 
installed.  If I attempt a dnf reinstall of the kernel and
related rpms then I get the following errors:



 Package Arch  Version Repository  Size

Reinstalling:
 kernel  x86_643.16.0-0.rc2.git0.1.fc21rawhide 86 k
 kernel-core x86_643.16.0-0.rc2.git0.1.fc21rawhide 18 M
 kernel-modules  x86_643.16.0-0.rc2.git0.1.fc21rawhide 17 M
 kernel-headers  x86_643.16.0-0.rc2.git0.1.fc21rawhide985 k
 kernel-tools-libs   x86_643.16.0-0.rc2.git0.1.fc21rawhide 92 k
 replacing  kernel-tools-libs.x86_64 3.15.0-0.rc7.git0.1.fc21
 replacing  kernel-tools-libs.x86_64 3.15.0-0.rc8.git1.2.fc21
 replacing  kernel-tools-libs.x86_64 3.16.0-0.rc0.git11.1.fc21
 kernel-modules-extrax86_643.16.0-0.rc2.git0.1.fc21rawhide2.2 M
Transaction Summary

Total size: 38 M
Downloading Packages:

Total   3.7 GB/s |  38 MB 00:00
Running transaction check
Transaction check succeeded.
Running transaction test
Error: Transaction check error:
  file /usr/lib64/libcpupower.so.0.0.0 from install of 
kernel-tools-libs-3.16.0-0.rc2.git0.1.fc21.x86_64 conflicts with file from
package kernel-tools-libs-3.15.0-0.rc7.git0.1.fc21.x86_64
  file /usr/lib64/libcpupower.so.0.0.0 from install of 
kernel-tools-libs-3.16.0-0.rc2.git0.1.fc21.x86_64 conflicts with file from
package kernel-tools-libs-3.15.0-0.rc8.git1.2.fc21.x86_64
  file /usr/lib64/libcpupower.so.0.0.0 from install of 
kernel-tools-libs-3.16.0-0.rc2.git0.1.fc21.x86_64 conflicts with file from
package kernel-tools-libs-3.16.0-0.rc0.git11.1.fc21.x86_64
Error Summary
-





Dependencies resolved.

 Package Arch  Version Repository  Size

Reinstalling:
 kernel  x86_643.16.0-0.rc2.git0.1.fc21rawhide 86 k
 kernel-core x86_643.16.0-0.rc2.git0.1.fc21rawhide 18 M
 kernel-modules  x86_643.16.0-0.rc2.git0.1.fc21rawhide 17 M
 kernel-headers  x86_643.16.0-0.rc2.git0.1.fc21rawhide985 k
 replacing  kernel-headers.x86_64 3.16.0-0.rc0.git11.1.fc21
 kernel-tools-libs   x86_643.16.0-0.rc2.git0.1.fc21rawhide 92 k
 replacing  kernel-tools-libs.x86_64 3.15.0-0.rc7.git0.1.fc21
 replacing  kernel-tools-libs.x86_64 3.15.0-0.rc8.git1.2.fc21
 replacing  kernel-tools-libs.x86_64 3.16.0-0.rc0.git11.1.fc21
 kernel-modules-extrax86_643.16.0-0.rc2.git0.1.fc21rawhide2.2 M

Transaction Summary


Total size: 38 M
Downloading Packages:

Total   3.7 GB/s |  38 MB 00:00
Running transaction check
Transaction check succeeded.
Running transaction test
Error: Transaction check error:
  file /usr/lib64/libcpupower.so.0.0.0 from install of 
kernel-tools-libs-3.16.0-0.rc2.git0.1.fc21.x86_64 conflicts with file from
package kernel-tools-libs-3.15.0-0.rc7.git0.1.fc21.x86_64
  file /usr/lib64/libcpupower.so.0.0.0 from install of 
kernel-tools-libs-3.16.0-0.rc2.git0.1.fc21.x86_64 conflicts with file from
package kernel-tools-libs-3.15.0-0.rc8.git1.2.fc21.x86_64
  file /usr/lib64/libcpupower.so.0.0.0 from install of 
kernel-tools-libs-3.16.0-0.rc2.git0.1.fc21.x86_64 conflicts with file from
package kernel-tools-libs-3.16.0-0.rc0.git11.1.fc21.x86_64
  file /usr/include/linux/audit.h from install of 
kernel-headers-3.16.0-0.rc2.git0.1.fc21.x86_64 conflicts with file from package
kernel-headers-3.16.0-0.rc0.git11.1.fc21.x86_64
  file /usr/include/linux/btrfs.h from install of 
kernel-headers-3.16.0-0.rc2.git0.1.fc21.x86_64 conflicts with file from package
kernel-headers-3.16.0-0.rc0.git11.1.fc21.x86_64
  file /usr/include/linux/can.h from install of 
kernel-headers-3.16.0-0.rc2.git0.1.fc21.x86_64 conflicts with file from package
kernel-headers-3.16.0-0.rc0.git11.1.fc21.x86_64
  file /usr/include/linux/can/bcm.h from install of 
kernel-headers-3.16.0-0.rc2.git0.1.fc21.x86_64 conflicts with file from package
kernel-headers-3.16.0-0.rc0.git11.1.fc21.x86_64
  file 

todays dnf kernel update gives conflicts again....

[Kevin Martin]

.x86_64 conflicts with file from
package kernel-headers-3.15.0-0.rc8.git1.2.fc21.x86_64
  file /usr/include/mtd/mtd-abi.h from install of 
kernel-headers-3.16.0-0.rc0.git11.1.fc21.x86_64 conflicts with file from package
kernel-headers-3.15.0-0.rc8.git1.2.fc21.x86_64
  file /usr/include/rdma/rdma_netlink.h from install of 
kernel-headers-3.16.0-0.rc0.git11.1.fc21.x86_64 conflicts with file from
package kernel-headers-3.15.0-0.rc8.git1.2.fc21.x86_64
  file /usr/include/sound/asound.h from install of 
kernel-headers-3.16.0-0.rc0.git11.1.fc21.x86_64 conflicts with file from package
kernel-headers-3.15.0-0.rc8.git1.2.fc21.x86_64
  file /usr/include/sound/firewire.h from install of 
kernel-headers-3.16.0-0.rc0.git11.1.fc21.x86_64 conflicts with file from
package kernel-headers-3.15.0-0.rc8.git1.2.fc21.x86_64

-- 

Regards,


Kevin Martin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

kernel-headers for 3.15 rc8 conflict with kernel-headers-3.15.0-0.rc7.git0.1.fc21.x86_64

[Kevin Martin]

Today while doing a dnf upgrade I got a conflict message about the 
kernel-headers for 3.15 rc8 conflicting with 3.15 rc7.git0.1.  I
was forced to rpm -e the rc7 headers (with --nodeps) to be able to install the 
rc8 versions and allow the whole set of necessary
kernel packages to install so grub2 would update it's config properly.

Just letting you know.

Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: kernel-headers for 3.15 rc8 conflict with kernel-headers-3.15.0-0.rc7.git0.1.fc21.x86_64

[Kevin Martin]

On 06/05/2014 02:30 PM, Adam Williamson wrote:
 On Thu, 2014-06-05 at 13:25 -0500, Kevin Martin wrote:
 Today while doing a dnf upgrade I got a conflict message about the 
 kernel-headers for 3.15 rc8 conflicting with 3.15 rc7.git0.1.  I
 was forced to rpm -e the rc7 headers (with --nodeps) to be able to install 
 the rc8 versions and allow the whole set of necessary
 kernel packages to install so grub2 would update it's config properly.

 Just letting you know.
 
 That sounds like possibly a dnf bug. kernel-headers is like
 kernel-devel, not kernel-core: you should only have one kernel-headers
 at a time. dnf shouldn't have tried to install them alongside each
 other.
 
 IIRC there was a new release of dnf recently - that could be the issue.
 Ales, any ideas?
 
 It'd help if you had the exact dnf output; I believe dnf history should
 be able to show it.
 
dnf history is not showing that output error but I recall dnf complained about 
/usr/include/linux/audit.h conflicting between the
two kernel-header versions.  I'm running dnf-0.5.2-1 fwiw.

Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: kernel-3.15 series fail to load gnome desktop

[Kevin Martin]

On 04/19/2014 12:02 PM, Tom London wrote:
 On Sat, Apr 19, 2014 at 9:49 AM, Tom London seli...@gmail.com 
 mailto:seli...@gmail.com wrote:
 
 On Sat, Apr 19, 2014 at 9:47 AM, Clyde E. Kunkel 
 clydekunkel7...@verizon.net mailto:clydekunkel7...@verizon.net wrote:
 
 On Sat, 19 Apr 2014 12:45:10 -0400
 Clyde E. Kunkel clydekunkel7...@verizon.net 
 mailto:clydekunkel7...@verizon.net wrote:
 
  On Sat, 19 Apr 2014 09:32:00 -0700
  Tom London seli...@gmail.com mailto:seli...@gmail.com wrote:
  snip
  May be a red herring.  The file does not exist on  my machine 
 booted
  with kernel-3.14.
 
 Apologies for not deleting majority of msg in my previous reply.
 --
 
 
 Not sure I understand: which file?  My report was about a deadlock 
 triggered by pulseaudio process causing a hung process.
 
 
 
 BZ'ed here: https://bugzilla.redhat.com/show_bug.cgi?id=1089488
 
 
 
 -- 
 Tom London
 
 
Tom,

You could try *not having pulseaudio installed.  I finally gave up on 
pulseaudio and run as close to a  strict alsa setup as I can
and don't have many of the issues that I once had.  My installed audio rpms 
are:

pulseaudio-libs-glib2-5.0-3.fc21.x86_64
pulseaudio-libs-5.0-3.fc21.x86_64
pulseaudio-libs-devel-5.0-3.fc21.x86_64

python-alsa-1.0.26-3.fc20.x86_64
alsa-utils-1.0.27.2-5.fc21.x86_64
alsa-lib-devel-1.0.27.2-2.fc21.x86_64
alsa-oss-1.0.17-9.fc20.x86_64
alsa-oss-libs-1.0.17-9.fc20.x86_64
alsamixergui-0.9.0-0.16.rc2.fc20.x86_64
alsa-lib-1.0.27.2-2.fc21.x86_64
alsa-firmware-1.0.27-2.fc20.noarch
alsa-tools-firmware-1.0.27-3.fc21.x86_64
alsa-lib-debuginfo-1.0.27.2-2.fc21.x86_64
alsa-tools-1.0.27-3.fc21.x86_64

And I've only got the pulseaudio-libs stuff installed because of dependencies 
from other packages.


Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Modesetting failure with kernel 3.15; ok with kernel 3.14

[Kevin Martin]

On 04/17/2014 01:26 PM, Steven Usdansky wrote:
 Not sure where to report this problem (or what I should be looking for), but 
 when booting any of the 3.15 kernels,
 kernel-modesetting fails and X comes up with a resolution of  1024x768, 
 rather than the 1680x1050 resolution specified in my
 xorg.conf file. xorg.conf is necessary because my monitor does not emit a 
 proper EDID.
 
 ~$ uname -r
 kernel-3.15.0-0.rc1.git1.1.fc21.x86_64
 ~$ lspci | grep 9100
 02:00.0 VGA compatible controller: NVIDIA Corporation C78 [GeForce 9100] (rev 
 a2)
 
 Reverting to kernel -3.13.7-200.fc20.x86_64 avoids the problem (and problems 
 I've been having with firefox-28 locking up with 3.14
 kernels).
 
 --
 RockDoctor
 
 
Oh good, I'm not the only one having these problems (modesetting AND firefox 
lockups).  I find that if I (modprobe nouveau
modeset=1) as root or sudo after logging in from a terminal and before running 
X I get the proper resolution, but the firefox
lockups are definitely a pain.  I'm on 3.15.0-0.rc0.git9.1.fc21.x86_64.

Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Modesetting failure with kernel 3.15; ok with kernel 3.14

[Kevin Martin]

On 04/17/2014 01:48 PM, Steven Usdansky wrote:
 failed with error -22
I probably should have asked this before but are you using the nouveau or 
nvidia driver?  And did you modprobe as root?

Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

this mornings kernel rc6 not signed...

[Kevin Martin]

Tried to do an update this morning and I get:

Error: Package kernel-3.14.0-0.rc6.git1.1.fc21.x86_64.rpm is not signed

Can somebody please fix this?

Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: this mornings kernel rc6 not signed...

[Kevin Martin]

On 03/13/2014 09:24 AM, drago01 wrote:
 On Thu, Mar 13, 2014 at 3:19 PM, Kevin Martin ktm...@gmail.com wrote:
 Tried to do an update this morning and I get:

 Error: Package kernel-3.14.0-0.rc6.git1.1.fc21.x86_64.rpm is not signed

 Can somebody please fix this?
 
 Rawhide packages are never signed ...
 
hmm...I swore I did an update two days ago and it pulled the rc6 and I didn't 
have nogpg_check on but maybe I'm wrong.

Thanks for the info.

Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: /var/log/messages is scrambled!

[Kevin Martin]

On 02/25/2014 01:44 PM, Neal Becker wrote:
 OK, I think there is no question that time did not go back in 
 /var/log/messages.  
 Actually, the messages are scrambled.
 
 First it is Jan 25.  Then it it Jan 8.  We go through normal looking periods 
 of 
 Jan 9 and 10, and Jan 13 before we're back on Feb 25.  I don't think this can 
 be 
 explained by the clock doing that - as the time spent on Jan 9, 10...13 are 
 quite long.  It couldn't have actually been preceeded and followed by Jan 25. 
 
There was another thread today where somebody suggested/commented that 
/var/log/messages can't be trusted to be in line time-wise
and that, to get synced messages, you have to use journalctl.  My $.02, what a 
good idea it is to obfuscate the messages in such a
way that you can't just read them with cat/more/less and have to actually have 
a whole system built around the idea of messaging
(can you say sarcasm).  Anyway, take a look at journalctl to see if your system 
messages are really out of sync or not.

Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Vmware Workstation won't compile

[Kevin Martin]

On 02/14/2014 01:26 PM, Lawrence Graves wrote:
 
 On 2/14/2014 11:06 AM, Joachim Backes wrote:
 On 02/14/2014 05:06 PM, Lawrence E Graves wrote:
 kernel-3.13.2-200.fc20.x86_64
 kernel-modules-extra-3.12.9-301.fc20.x86_64
 kernel-modules-extra-3.12.10-300.fc20.x86_64
 kernel-devel-3.13.2-200.fc20.x86_64
 kernel-3.12.9-301.fc20.x86_64
 kernel-3.12.10-300.fc20.x86_64
 kernel-modules-extra-3.13.2-200.fc20.x86_64
 abrt-addon-kerneloops-2.1.12-2.fc20.x86_64
 kernel-headers-3.13.2-200.fc20.x86_64
 kernel-devel-3.12.9-301.fc20.x86_64
 texlive-l3kernel-svn32204.SVN_4610-4.fc20.noarch
 libreport-plugin-kerneloops-2.1.12-2.fc20.x86_64
 kernel-devel-3.12.10-300.fc20.x86_64
 [

 What about dkms?

 Joachim Backes
 I always install dkms. I have been using Vmware Workstation since 6 edition. 
 Funny thing, it just compiled for some unknown reason
 so I am going to not worry about it now. My laptop is still not able to 
 compile but oh well. Everything is the same on it as on my
 desktop. That is strange. Thanks for your imput.
 
Lawrence,

look at  https://communities.vmware.com/message/2335957 and 
http://ping.com/2013/12/13/vmware-modules-kernel-3-13/ for
instructions on patching this version of VMware for kernel 3.13.  If you have 
problems make sure you read *ALL* of the posts from
the communities site as there are instructions on how to fix the patching issue 
if you have it.

Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

dnf upgrade...some strange errors...

[Kevin Martin]

Did a dnf upgrade tonight and received these errors just prior to the verifying 
step:

  Cleanup : less-458-5.fc21.x86_64

394/399
  Cleanup : iw-3.11-1.fc21.x86_64

395/399
  Cleanup : icedtea-web-1.4.2-0.fc21.x86_64

396/399
  Cleanup : espeak-1.47.11-4.fc21.x86_64

397/399
  Cleanup : boost-python3-1.54.0-10.fc21.x86_64

398/399
  Obsoleting  : lxshortcut-0.1.2-6.fc20.x86_64

399/399
depmod: ERROR: Module 'hci_vhci' has devname (vhci) but lacks major and minor 
information. Ignoring.
05busybox: Could not find command 'busybox'!
90multipath: Could not find command 'multipath'!
95fcoe: Could not find command 'dcbtool'!
95fcoe: Could not find command 'fipvlan'!
95fcoe: Could not find command 'lldpad'!
95fcoe-uefi: Could not find command 'dcbtool'!
95fcoe-uefi: Could not find command 'fipvlan'!
95fcoe-uefi: Could not find command 'lldpad'!
95nbd: Could not find command 'nbd-client'!
05busybox: Could not find command 'busybox'!
90multipath: Could not find command 'multipath'!
95fcoe: Could not find command 'dcbtool'!
95fcoe: Could not find command 'fipvlan'!
95fcoe: Could not find command 'lldpad'!
95fcoe-uefi: Could not find command 'dcbtool'!
95fcoe-uefi: Could not find command 'fipvlan'!
95fcoe-uefi: Could not find command 'lldpad'!
95nbd: Could not find command 'nbd-client'!
chown: cannot access ‘/var/tmp/abrt/ccpp-2013-07-10-14:46:39-1977/*’: No such 
file or directory
chown: cannot access ‘/var/tmp/abrt/ccpp-2013-07-11-09:05:12-4498/*’: No such 
file or directory


Gotta think this isn't a good thing.

Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: dnf upgrade...some strange errors...

[Kevin Martin]

  
399/399
 depmod: ERROR: Module 'hci_vhci' has devname (vhci) but lacks major and 
 minor information. Ignoring.
 05busybox: Could not find command 'busybox'!
 90multipath: Could not find command 'multipath'!
 95fcoe: Could not find command 'dcbtool'!
 95fcoe: Could not find command 'fipvlan'!
 95fcoe: Could not find command 'lldpad'!
 95fcoe-uefi: Could not find command 'dcbtool'!
 95fcoe-uefi: Could not find command 'fipvlan'!
 95fcoe-uefi: Could not find command 'lldpad'!
 95nbd: Could not find command 'nbd-client'!
 05busybox: Could not find command 'busybox'!
 90multipath: Could not find command 'multipath'!
 95fcoe: Could not find command 'dcbtool'!
 95fcoe: Could not find command 'fipvlan'!
 95fcoe: Could not find command 'lldpad'!
 95fcoe-uefi: Could not find command 'dcbtool'!
 95fcoe-uefi: Could not find command 'fipvlan'!
 95fcoe-uefi: Could not find command 'lldpad'!
 95nbd: Could not find command 'nbd-client'!
 chown: cannot access ‘/var/tmp/abrt/ccpp-2013-07-10-14:46:39-1977/*’: No 
 such file or directory
 chown: cannot access ‘/var/tmp/abrt/ccpp-2013-07-11-09:05:12-4498/*’: No 
 such file or directory
 
 They're package bugs. The depmod one is already reported. The rest
 except the two abrt issues are issues in dracut modules, you don't need
 to worry about any of them. Don't know if they've been reported, but
 they probably should be. I wouldn't worry too much about any of those,
 they aren't going to break anything, just ugliness to be cleaned up.
 Nothing dnf-specific.
 
That's kind of what I figured but just wanted to make sure.

Thanks.

Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Seeing this error on bootup with latest 3.14 kernel from rawhide

[Kevin Martin]

[0.527306] ACPI: SSDT bf71a918 0003F0 (v01  PmRef  Cpu0Ist 3000 
INTL 20060912)
[0.531169] ACPI: SSDT   (null) 0003F0 (v01  PmRef  Cpu0Ist 3000 
INTL 20060912)
[0.533083] ACPI: SSDT bf718018 000891 (v01  PmRef  Cpu0Cst 3001 
INTL 20060912)
[0.535783] ACPI: SSDT   (null) 000891 (v01  PmRef  Cpu0Cst 3001 
INTL 20060912)
[0.863195] ACPI: \_PR_.CPU4: failed to get CPU APIC ID.
[0.863401] ACPI: \_PR_.CPU5: failed to get CPU APIC ID.
[0.863580] ACPI: \_PR_.CPU6: failed to get CPU APIC ID.
[0.863762] ACPI: \_PR_.CPU7: failed to get CPU APIC ID.


Have never seen this error before.  This is an AMD  quad core laptop (toshiba 
Qosmio).  Any ideas why I might be seeing this?

Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: yum rawhide failing....

[Kevin Martin]

On 12/13/2013 09:17 AM, Michael Schwendt wrote:
 On Fri, 13 Dec 2013 11:52:58 +0100, poma wrote:
 
 Prefer yum clean metadata (or just yum clean expire-cache) over
 deleting even downloaded/cached packages with all.

 Sí jefe, pero todos es tan hermosa. ;)
 
 yum clean without any additional options could be the default.
 
 Btw, from time to time I kill everything below /var/lib/yum to get rid
 of old history/yumdb files I don't find relevant anymore.
 
It fixed itself shortly after my sending the email.  and every now and again I 
do a yum clean all just to make sure things are good
to go.

Thanks.

Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

yum rawhide failing....

[Kevin Martin]

Every mirror for yum rawhide is failing at this time for me with 404 not found 
messages.  I see this error as well:

One of the configured repositories failed (Fedora - Rawhide - Developmental 
packages for the next Fedora release),
 and yum doesn't have enough cached data to continue.

Is there an issue that should resolve later?

Thanks

Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Fedora 20 broadcast address

[Kevin Martin]

On 11/21/2013 09:06 AM, James Hogarth wrote:
 
 
 
 On 20 November 2013 22:29, Louis Lagendijk lo...@fazant.net 
 mailto:lo...@fazant.net wrote:
 
 On Wed, 2013-11-20 at 16:21 -0600, Kevin Martin wrote:
  On 11/20/2013 03:21 PM, Louis Lagendijk wrote:
   Some time ago I asked a question about the broadcast address on Fedora
   20. On my desktop (installed from one of Alpha TC's) the interface is
   brought up correctly, except that the broadcast address does not get 
 set
   correctly:
   Ifconfig reports:
  
   p5p1: flags=4163UP,BROADCAST,RUNNING,MULTICAST  mtu 1500
   inet 192.168.159.186  netmask 255.255.255.0  broadcast 
 0.0.0.0
   inet6 2001:981:688d:f2:1e6f:65ff:fed5:7742  prefixlen 128
   scopeid 0x0global
   inet6 fe80::1e6f:65ff:fed5:7742  prefixlen 64  scopeid
   0x20link
   ether 1c:6f:65:d5:77:42  txqueuelen 1000  (Ethernet)
   RX packets 568712  bytes 540500284 (515.4 MiB)
   RX errors 0  dropped 0  overruns 0  frame 0
   TX packets 359977  bytes 282238000 (269.1 MiB)
   TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
  
   The broadcast address is not set when I use DHCP, but is also missing
   when I use static address allocation. When I try a
   ifdown p5p1; ifup05p1
   the broadcast address is setup correctly.
  
 
 
 Interestingly enough using the iproute tools mirrors the net-tools here to 
 some extent... although net-tools reports 0.0.0.0 whereas
 iproute shows no broadcast address:
 
  2: p4p1: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc mq state UP group 
 default qlen 1000
 link/ether d4:be:d9:7e:f3:ce brd ff:ff:ff:ff:ff:ff
 inet 10.81.10.110/24 http://10.81.10.110/24 scope global dynamic p4p1
valid_lft 18508sec preferred_lft 18508sec
 inet6 fe80::d6be:d9ff:fe7e:f3ce/64 scope link 
valid_lft forever preferred_lft forever
 
 No brd bit is included in this compared to another interface that does have 
 it:
 
 12: virbr1: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc noqueue state UP 
 group default 
 link/ether 52:54:00:72:fa:28 brd ff:ff:ff:ff:ff:ff
 inet 192.168.244.1/24 http://192.168.244.1/24 brd 192.168.244.255 scope 
 global virbr1
valid_lft forever preferred_lft forever
 
 However I'm curious as to the consequences of this given that broadcast 
 address is just a function of network address against
 network mask anyway ...
 
 
 
 
I'm guessing (and this is only a guess) that most network tools don't derive 
broadcast address on the fly but use the system
settings when the broadcast address information is needed.  It becomes of 
particular importance I would suppose when using a mask
that could be considered atypical (whatever that might be).  I just find it 
disturbing that this has suddenly stopped being set by
default (for example,the network scripts, when not using NetworkManager, use 
ipcalc to set the broadcast address (which is why ifup
sets the address correctly) but dhclient/NetworkManager apparently are ignoring 
this at this time).  I've yet to find anything on
the web that indicates that this was a conscious decision.

Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

cronie rpm error

[Kevin Martin]

/var/tmp/rpm-tmp.9wvQS9: line 2: fg: no job control
error: %preun(cronie-1.4.11-1.fc20.x86_64) scriptlet failed, exit status 1
Error in PREUN scriptlet in rpm package cronie
error: cronie-1.4.11-1.fc20.x86_64: erase failed



-- 

Regards,


Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

dependency issues with gstreamer1-libav...

[Kevin Martin]

Package gstreamer1-libav.x86_64 0:1.1.3-1.fc20 will be an update
-- Processing Dependency: libavformat.so.54(LIBAVFORMAT_54)(64bit) for 
package: gstreamer1-libav-1.1.3-1.fc20.x86_64
-- Processing Dependency: libavcodec.so.54(LIBAVCODEC_54)(64bit) for package: 
gstreamer1-libav-1.1.3-1.fc20.x86_64
-- Processing Dependency: libavcodec.so.54()(64bit) for package: 
gstreamer1-libav-1.1.3-1.fc20.x86_64
-- Processing Dependency: libavformat.so.54()(64bit) for package: 
gstreamer1-libav-1.1.3-1.fc20.x86_64

Unfortunately, the latest vlc needs the .55 versions of the above libraries.


-- 

Regards,


Kevin Martin
NetFuel, Inc.
mailto: kev...@netfuel.com
mailto: tech-supp...@netfuel.com
U.S.). 312.698.9879
U.K.) 208.150.3609
U.S. Alternate). 847.231.3589
FAX) 866.654.3341

For access to our Software and Documentation
please login or register for access at:

http://www.netfuel.com

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: A different way of installing Fedora

[Kevin Martin]

On 09/25/13 20:38, David wrote:
 On 9/25/2013 9:33 PM, Gavin Flower wrote:
 On 26/09/13 13:26, David wrote:
 On 9/25/2013 9:13 PM, Chuck Forsberg WA7KGX wrote:
 On 09/25/2013 05:45 PM, David wrote:
 On 9/25/2013 7:19 PM, Chuck Forsberg WA7KGX wrote:
 Several of my machies have SATA hot swap ports.
 These make it easy to use smaller drives as backup media.

 When RC4 came out I installed it on a 4 TB drive using an
 older E6550 machine.  At my leisure I added lots of apps
 and libs that I normally use.

 Then I slipped that drive in my omen.com server and changed
 the boot order to boot that drive.  I changed hostname and
 domainname, restored some of my control files, and omen.com
 was back on the air relatively quickly.

 I was fortunate this procedure worked as netinst was unable to
 install RC4 while running on the server.

 This trick depends on Fedora apparently being able to make modest
 adjustments to the machine environment on boot up.

 Is this a valid procedure?

 A valid procedure?

 Hmm..

 Sounds like a eclectic procedure and situation to me.

 My concern is wether this procedure results in a kernel that is
 less optimized for the CPU it is running on than if Fedora had
 been installed directly on that machine.

 I don't know enough about Fedora installation to know what,
 if any, processor related optimizations are made in the install
 instead of boot time.


 More clearly said? Name two other people with your situation please.

 This a procedure, that I might like to do something like.

 I have a working F19 installation on a box with a Haswell processor.  It
 would be good if I could clone that, boot the clone on a box with an
 older Intel processor (though also a quad core 64 bit processor) and
 make minor changes.

 I suspect that there will be more than 3 people interested.


 Cheers,
 Gavin

 
 
 Well. Than answers that then. You now have a somewhat limited eclectic
 'circle jerk'. Enjoy.
 
Sounds like he is trying to do a Linux equivalent of Ghost...I see no reason 
for all of the negativity.  If you have enough machines
that are enough alike to be able to clone drives and install them on other 
machines and then make some very minor changes to get
them running, I say go for it.  You could even put a script on the primary 
drive that you then run on the cloned drives after
install that asks you questions about hostname/ip/etc. and finishes the 
configuration for you.  Should be an easy way to provision
boxes it seems to me.

Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Fedora 20 RC3

[Kevin Martin]

On 09/18/13 12:39, Lawrence Graves wrote:
 I am not able to connect to my network. Something about dhclient not working.
 -- 
 All things are workable but don't all things work. Prov. 3:5  6
 
 
Lawrence,

Have you turned off ipv6 on the kernel line in grub?  If you have you need to 
get that out of grub.  There is apparently a bug with
dhclient when you've turned off ipv6.  Also, what version of NetworkManager 
and/or dhclient do you have installed.

Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: blackened screen 2

[Kevin Martin]

On 09/09/13 13:31, Richard Vickery wrote:
 Hi gang:
 
 I'm on F20. The only way I get a screen that anyone can see is not by
 using the portable computer's screen, but plugging it into another
 screen. I tried going into the Power control but it's already on
 maximum brightness. Any Ideas on how else I might try to fix it?
 
 Thanks,
 
 Richard
 

Y'know, I just had this problem with an HP laptop and had to replace the 
screen.  I could *barely* see that the screen had something
on it if I shined a flashlight on it at different angles.  It turned out to be 
a bad screen.  FWIW, this was with Knoppix but the
screen was definitely bad.  Screens on laptops are fairly easy to replace, 
FWIW.  Lots of videos on how to do it and the screens
tend to be  $100.

Otherwise, I couldn't tell you what might be happening.

Good luck.

Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

LibreOffice 4.1 menu display problem.

[Kevin Martin]

I'm using the following package of LibreOffice:

Version: 4.1.1.2
Build ID: 4.1.1.2-1.fc21


When I open a file in LO, the menu's don't display properly (only the icons and 
a - where the words should be).  If I grab the
window border and drag the window a little, then the menu's display properly, 
at least until I actually click on the menu I want,
then it goes back to only showing the icon and a -.  Obviously, something isn't 
painting this particular window correctly but I
don't know what or why.  Any thoughts/recommendations greatly appreciated.

Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: NetworkManager F20 online but no connnection

[Kevin Martin]

On 08/23/13 11:12, Frank Murphy wrote:
 I'm on the www, posting this.
 NM-Applet show no active connection found?
 
  ifconfig
 eth0: flags=4163UP,BROADCAST,RUNNING,MULTICAST  mtu 1500
 inet xxx.xxx.xxx.xxx
 
 dmesg | grep eth
 [   34.491811] r8169 :04:00.0 eth0: RTL8168evl/8111evl at
 0xc9c3c000, 90:2b:34:c8:80:22, XID 0c900800 IRQ 45
 [   34.493623] r8169 :04:00.0 eth0: jumbo features [frames: 9200
 bytes, tx checksumming: ko] [   58.830145] r8169 :04:00.0 eth0:
 link down [   58.830808] r8169 :04:00.0 eth0: link down
 [   58.831863] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
 [   61.756928] r8169 :04:00.0 eth0: link up [   61.757613] IPv6:
 ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
 
 How does one proceed, nm, dbus, aliens?
 
 
 

Might be related to this bug that I posted to bugzilla earlier:

https://bugzilla.redhat.com/show_bug.cgi?id=999176

There has been no forward progress on my report that I've seen.

Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: f19 and nouveau drivers system freeze

[Kevin Martin]

On 07/12/13 00:47, Christopher Meng wrote:
 I hit this error everyday when I've used too much time of Chrome.
 
 Chrome will become freeze and the mouse cursor and everything are
 stopped, and after a while the screen turns black and show it.
 
Hmm, interesting.  I just ran into a system freeze last night in rawhide with 
nouveau and Thunderbird and Firefox running.  I was
unable to login remotely to the box to see what was happening so had to power 
it down.  And those same errors I was seeing in dmesg
yesterday.  My machine is running Linux 3.11.0-0.rc0.git3.1.fc20.x86_64 #1 SMP 
Tue Jul 9 21:34:37 UTC 2013 x86_64 x86_64 x86_64
GNU/Linux.  I actually posted a bugzilla yesterday about X crashing when 
running Mozilla products but perhaps it's more than just that.

Kevin Martin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: ABRT shows a problem with google-chrome-unstable Google Wallet Service...

[Kevin Martin]

On 07/10/13 14:31, Adam Williamson wrote:
 On Wed, 2013-07-10 at 11:50 -0500, Kevin Martin wrote:
 
 Or maybe this from the not-reportable file (a message, by the way, that 
 makes no sense at the point where it says free and Nouveau
 driver):

 Your problem seems to be caused by NVIDIA graphics driver

 The NVIDIA graphics drivers are proprietary, and many kernel developers
 consider this driver to violate the GPL license of the kernel. Fedora
 does not include proprietary software.

 Fedora Suggests: Consider using the free and Nouveau driver instead or use
 a graphics adapter from Intel or AMD or any other manufacturer that provides
 full specifications and/or source code.


 Those are the only files in the abrt directory that even mention nVidia.  
 Does this help?
 
 I was meaning the message the abrt GUI app shows you.
 

What you see above is exactly what the GUI was showing me.  I've since cleaned 
up old nvidia library files so we'll see if this recurs.

Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: ABRT shows a problem with google-chrome-unstable Google Wallet Service...

[Kevin Martin]

On 07/09/13 23:03, Ankur Sinha wrote:
 On Tue, 2013-07-09 at 21:17 -0500, Kevin Martin wrote:
 So how should I report this?  Is there some way to force ABRT to
 report this?
 
 Chrome? I thought ABRT only reports issues for Fedora packages? You may
 be able to save the ABRT log and manually file a bug wherever chrome's
 bug tracker is, but I really don't think ABRT will let you file a bug at
 Fedora's bugzilla for this package.
 
 The exact ABRT error message would be helpful too.
 
 
 
In retrospect, it appears that what abrt caught was Process 
/opt/google/chrome/chrome was killed by signal 6 (SIGABRT) which
probably occurred as a result of my closing chrome but then logging out of X, 
most likely before all of the chrome processes had
completely shut down.  The thing that bugs me most is that the method by which 
abrt determines nVidia vs nouveau is obviously flawed
as I'm not using nVidia (at this time).  That needs to be worked fixed.

Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

ABRT shows a problem with google-chrome-unstable Google Wallet Service...

[Kevin Martin]

But won't let me report it as it says that it's probably due to my using the 
nVidia graphics driver.  Interestingly enough, I'm
*not* using nVidia but nouveau (as the ABRT message suggests and as shown 
below):

$ lsmod |grep nvidia
$ lsmod | grep nouveau
nouveau  1027226  2
mxm_wmi12865  1 nouveau
i2c_algo_bit   13257  1 nouveau
drm_kms_helper 50282  1 nouveau
ttm85078  1 nouveau
drm   281537  4 ttm,drm_kms_helper,nouveau
i2c_core   38416  6 
drm,i2c_i801,drm_kms_helper,i2c_algo_bit,nouveau,videodev
wmi18697  3 toshiba_acpi,mxm_wmi,nouveau
video  19247  1 nouveau


So how should I report this?  Is there some way to force ABRT to report this?

Thanks.

Kevin Martin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

X question...

[Kevin Martin]

In the last week or so I've begun seeing some X applications have no pull-down 
menu's displayed or button decorations until I move
the X window a bit.  LibreOffice and rdesktop are two that come to mind.  
Thunderbird and Firefox are not displaying that behaviour.
 I would appreciate thoughts on what might be causing this.  I'm running the 
latest rawhide kernel and latest X updates, fwiw.


-- 

Regards,


Kevin Martin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: p7zip-plugins and rar extraction.

[Kevin Martin]

On 04/29/13 15:55, Rahul Sundaram wrote:
 On 04/29/2013 12:54 PM, Kevin Martin wrote
 I'll post a bugzilla but, fwiw, unar worked a treat:


 $ unar tomato-K26USB-1.28.9054MIPSR2-beta-vpn3.6.rar
 tomato-K26USB-1.28.9054MIPSR2-beta-vpn3.6.rar: RAR
CHANGELOG  (44863 B)... OK.
tomato-K26USB-1.28.9054MIPSR2-beta-vpn3.6.trx  (6823936 B)... OK.
 Successfully extracted to tomato-K26USB-1.28.9054MIPSR2-beta-vpn3.6.
 
 That's good to know.  Do file one against file-roller and I will test it in 
 Rawhide and see if I can reproduce the problem.
 
 Rahul

Found the problem.

I had an old 32bit version of rar and unrar in /usr/local/bin which was being 
found by file-roller before unar was being found.
/usr/local/bin/rar was getting an error error while loading shared libraries: 
libstdc++.so.6: cannot open shared object file: No
such file or directory which was causing file-roller to fail as it didn't then 
go on to try unar after that failure.  I removed rar
and unrar from /usr/local/bin/ and file-roller worked correctly.

Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: p7zip-plugins and rar extraction.

[Kevin Martin]

On 04/29/13 11:13, Rahul Sundaram wrote:
 Hi
 
 
 On Mon, Apr 29, 2013 at 9:22 AM, Kevin Martin wrote:
 
 On 04/29/13 00:12, Rahul Sundaram wrote:
  Hi
 
 
  On Sun, Apr 28, 2013 at 4:52 PM, Kevin Martin wrote:
 
  On 04/27/13 18:41, Rahul Sundaram wrote:
   Hi
  
  
   On Sat, Apr 27, 2013 at 4:54 PM, Kevin Martinwrote:
 
  One archive it can't open can be found at:
 
 
 
 http://sourceforge.net/settings/mirror_choices?projectname=tomatousbfilename=Experimental%20%28beta%29/K26-MIPSR2/tomato-K26USB-1.28.9054MIPSR2-beta-Ext.rar
 
 
 
  Works fine here.  Are you sure you are using the latest version of 
 file-roller?
 
  
 https://admin.fedoraproject.org/updates/FEDORA-2013-6326/file-roller-3.8.1-2.fc19
 
  Rahul
 
 
 Name: file-roller
 Version : 3.8.1
 Release : 2.fc20
 
 
 Have you tried using unar to extract this RAR file?  In either case, please 
 file a bug report with these details against file-roller
 and paste the link here.   I can followup there.  Thanks
 
 Rahul
 
 
I'll post a bugzilla but, fwiw, unar worked a treat:


$ unar tomato-K26USB-1.28.9054MIPSR2-beta-vpn3.6.rar
tomato-K26USB-1.28.9054MIPSR2-beta-vpn3.6.rar: RAR
  CHANGELOG  (44863 B)... OK.
  tomato-K26USB-1.28.9054MIPSR2-beta-vpn3.6.trx  (6823936 B)... OK.
Successfully extracted to tomato-K26USB-1.28.9054MIPSR2-beta-vpn3.6.

Kevin


-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: p7zip-plugins and rar extraction.

[Kevin Martin]

On 04/27/13 18:41, Rahul Sundaram wrote:
 Hi
 
 
 On Sat, Apr 27, 2013 at 4:54 PM, Kevin Martinwrote:
 
 
 
 Hmm, installed updated file-roller and can't unpack a .rar file.  Is 
 there something else that needs to be installed behind it?  I
 see the error An error occurred while loading the archive..
 
 
 The new file-roller is supposed to pull in unar as a dependency and it should 
 just work.   Any other behavior is a bug.  If you can
 pass me a link to the rar archive I can test it.  If it is not a public 
 archive, feel free to mail me offlist.   Thanks
 
 Rahul
 
 

One archive it can't open can be found at:

http://sourceforge.net/settings/mirror_choices?projectname=tomatousbfilename=Experimental%20%28beta%29/K26-MIPSR2/tomato-K26USB-1.28.9054MIPSR2-beta-Ext.rar

Thanks.

Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: p7zip-plugins and rar extraction.

[Kevin Martin]

On 04/25/13 07:10, drago01 wrote:
 On Thu, Apr 25, 2013 at 10:23 AM, Rahul Sundaram methe...@gmail.com wrote:
 On 04/25/2013 03:36 AM, drago01 wrote:


 Does it work with encrypted rar archives?


 Yes.  Encrypted rar archives are supported and I have tested it explicitly
 as well

 https://code.google.com/p/theunarchiver/wiki/SupportedFormats
 
 OK
 
Hmm, installed updated file-roller and can't unpack a .rar file.  Is there 
something else that needs to be installed behind it?  I
see the error An error occurred while loading the archive..

Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

p7zip-plugins and rar extraction.

[Kevin Martin]

What is the reason that rar archive extraction support is not included in the 
7z.so in the p7zip-plugins rpm?

-- 

Regards,


Kevin Martin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: p7zip-plugins and rar extraction.

[Kevin Martin]

On 04/16/13 15:47, Chris Adams wrote:
 Once upon a time, Kevin Martin ktm...@gmail.com said:
 What is the reason that rar archive extraction support is not included in 
 the 7z.so in the p7zip-plugins rpm?
 
 In the p7zip SRPM SPEC file:
 
# RAR sources removed since their license is incompatible with the LGPL
 
 In a package review attempt for unrar:
 
 https://bugzilla.redhat.com/show_bug.cgi?id=319831#c25
 
 I spoke via email to Eugene Roshal about this issue. He was unaware that 
 clamav
 had used derived code from their implementation in clamav, under the GPL
 license, and stated that he did not grant them permission to do so.
 
 He said that the only way he was willing for such code to be used was with a
 clause like the following:
 
 The unRAR sources cannot be used to re-create the RAR compression algorithm, 
  which is proprietary. Distribution of modified unRAR sources in separate 
 form 
  or as a part of other software is permitted, provided that it is clearly
  stated in the documentation and source comments that the code may
  not be used to develop a RAR (WinRAR) compatible archiver.
 
 Unfortunately, such a restriction conflicts directly with the GPL, and is a
 showstopper.
 
 This code cannot go into Fedora as is. All RAR v3.x support would need to be
 stripped out, before it could be considered. Given that most RAR files are RAR
 v3, that severely limits the usefulness of this application.
 
 
 Basically, the only documentation of the file format is in the unrar
 source code, and it is under a non-free license.  I don't think anyone
 has tried to reverse engineer it to make a clean-room implementation.
 

Thanks for the info.  It seems strange that because the folks at RAR don't want 
7zip to be able to *create* RAR archives that
Redhat/Fedora has to remove even the ability to extract RAR archives with 7z.  
Not being a programmer I guess I don't get how hard
it would be to hobble allowing creation while still allowing extraction.

Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

evince 3.8.0 cores

[Kevin Martin]

Every time I try to print a pdf with evince 3.8.0 it crashes and says that it 
cores but I can't find the core dump and so can't help
figure out where the problem is.  my settings for core dumps are:

::
/proc/sys/kernel/core_pattern

|/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e
::
/proc/sys/kernel/core_pipe_limit

4
::
/proc/sys/kernel/core_uses_pid

1

Any help greatly appreciated.


-- 

Regards,


Kevin Martin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: lxde menu items causing X crash

[Kevin Martin]

On 04/02/13 13:06, Adam Jackson wrote:
 On Tue, 2013-04-02 at 12:45 -0500, Kevin Martin wrote:
 
 I would happily use the nouveau driver (and was using it until going to the 
 3.8+ kernel where it became virtually
 unusable with noaccel turned on)
 
 Option ShadowFB on
 
 Or try vesa instead.
 
 - ajax
 
 

Ok, I'm back to nouveau using ShadowFB on and it's like night and day!  Thanks 
for pointing that option out.  Still have NoAccel on
but using ShadowFB on masks that.

Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Rawhide dead slow on my laptop

[Kevin Martin]

On 04/08/13 06:52, Ozan Çağlayan wrote:
 Rawhide kernels have debugging options enabled, which can cause
 significant slowdowns in many situations.  Try using the
 rawhide-kernel-nodebug repository to get non-debug kernels for Rawhide
 and see if your problems persist:
 http://fedoraproject.org/wiki/RawhideKernelNodebug
 
 Ah I knew about that but completely forgot it. Thanks for this
 valuable pointer :)
 
 --
 Ozan Çağlayan
 Research Assistant
 Galatasaray University - Computer Engineering Dept.
 http://www.ozancaglayan.com
 
What video driver are using, nouveau, nvidia, or something else?  What are your 
X settings?  If X is consistently high then I would
suspect the video driver.  I have seen the same behavior using nouveau under 
3.9 kernel.  I have *not* seen that behavior using
nvidia under the 3.9 driver but I do have other issues using nvidia (like 
machine hangs and X crashes).

Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

lxde menu items causing X crash

[Kevin Martin]

Using lxde with openbox on rawhide and certain menu items under Preferences 
causes the following crash of X:

 from process 3610 (kevinm@ktmtoshiba).
(EE)
(EE) Backtrace:
(EE) 0: /usr/bin/X (OsLookupColor+0x129) [0x46e569]
(EE) 1: /lib64/libpthread.so.0 (__restore_rt+0x0) [0x7fc9e694ef9f]
(EE) 2: ? (?+0x0) [0x0]
(EE)
(EE) Segmentation fault at address 0x0

Fatal server error:
Caught signal 11 (Segmentation fault). Server aborting


I am using the nVidia driver (primarily because I can't run the nouveau driver 
without setting '#Option NoAccel 1' in
/etc/X11/xorg.conf and so screen painting is painfully slow on this machine and 
I've opened repeated bugzilla's about the nouveau
issue with no resolution).  A few of the menu items that cause the crash are 
Preferences - Background and Preferences - Color.


Xorg info:

X.Org X Server 1.14.0
Release Date: 2013-03-05
[  2215.743] X Protocol Version 11, Revision 0
[  2215.743] Build Operating System:  2.6.32-279.19.1.el6.x86_64
[  2215.743] Current Operating System: Linux ktmtoshiba 
3.9.0-0.rc5.git0.2.fc20.x86_64 #1 SMP Mon Apr 1 17:16:49 UTC 2013 x86_64
[  2215.743] Kernel command line: 
BOOT_IMAGE=/vmlinuz-3.9.0-0.rc5.git0.2.fc20.x86_64 
root=UUID=895ff4c3-db90-4071-aeab-a0ec2d6b94cf
ro rd.md=0 rd.lvm=0 rd.d
m=0 rd.luks=0 rhgb quiet nouveau.modeset=0 rd.driver.blacklist=nouveau 
video=vesa:off vga=normal
[  2215.743] Build Date: 22 March 2013  01:08:33PM
[  2215.743] Build ID: xorg-x11-server 1.14.0-3.fc20
[  2215.743] Current version of pixman: 0.28.0



-- 

Regards,


Kevin Martin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: lxde menu items causing X crash

[Kevin Martin]

On 04/02/13 12:21, Adam Williamson wrote:
 On 02/04/13 09:27 AM, Kevin Martin wrote:
 Using lxde with openbox on rawhide and certain menu items under Preferences 
 causes the following crash of X:

   from process 3610 (kevinm@ktmtoshiba).
 (EE)
 (EE) Backtrace:
 (EE) 0: /usr/bin/X (OsLookupColor+0x129) [0x46e569]
 (EE) 1: /lib64/libpthread.so.0 (__restore_rt+0x0) [0x7fc9e694ef9f]
 (EE) 2: ? (?+0x0) [0x0]
 (EE)
 (EE) Segmentation fault at address 0x0

 Fatal server error:
 Caught signal 11 (Segmentation fault). Server aborting


 I am using the nVidia driver (primarily because I can't run the nouveau 
 driver without setting '#Option NoAccel 1' in
 /etc/X11/xorg.conf and so screen painting is painfully slow on this machine 
 and I've opened repeated bugzilla's about the nouveau
 issue with no resolution).  A few of the menu items that cause the crash are 
 Preferences - Background and Preferences - Color.
 
 I understand your frustration with the nouveau issue, but unfortunately, 
 there's very little chance of us being able to fix an X
 server crash using the proprietary driver :/. The nouveau issue is the one to 
 keep bashing at. I believe Ben's been busy with some
 non-bug-fix-y work lately, so the pace of bug fixing for nouveau has slowed 
 down, unfortunately.

I'm unconvinced that it's a nouveau vs. nvidia driver issue that we're dealing 
with here but an openbox/lxde/xorg problem but due to
the fact that I'm using the proprietary driver nobody will actually look at the 
issue or try to determine if, in fact, nvidia is the
cause or not.  I would happily use the nouveau driver (and was using it until 
going to the 3.8+ kernel where it became virtually
unusable with noaccel turned on) but that driver is possibly buggier than the 
proprietary driver but gets useful updates less often
and *no* updates that appear to relate to any of the bugs that I've reported 
against it for over the last two years.

Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

espeak package update fails

[Kevin Martin]

Transaction check error:
  file /usr/share/espeak-data/voices/en from install of 
espeak-1.47.01-1.fc20.x86_64 conflicts with file from package
espeak-1.46.02-8.fc19.x86_64



-- 

Regards,


Kevin Martin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

rawhide updates giving me errors when removing previous kernels....

[Kevin Martin]

  Cleanup: kernel-3.8.0-1.fc19.x86_64   
   73/88
warning: file /lib/modules/3.8.0-1.fc19.x86_64/modules.order: remove failed: No 
such file or directory
warning: file /lib/modules/3.8.0-1.fc19.x86_64/modules.networking: remove 
failed: No such file or directory
warning: file /lib/modules/3.8.0-1.fc19.x86_64/modules.modesetting: remove 
failed: No such file or directory
warning: file /lib/modules/3.8.0-1.fc19.x86_64/modules.drm: remove failed: No 
such file or directory
warning: file /lib/modules/3.8.0-1.fc19.x86_64/modules.builtin: remove failed: 
No such file or directory
warning: file /lib/modules/3.8.0-1.fc19.x86_64/modules.block: remove failed: No 
such file or directory

This is not the first time this has occurred when removing previous 3.8 kernels.

-- 

Regards,


Kevin Martin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

This mornings yum update....

[Kevin Martin]

gives me this error:

Transaction check error:
  file /usr/lib/debug from install of filesystem-3.2-4.fc19.x86_64 conflicts 
with file from package
gstreamer1-plugins-bad-free-debuginfo-1.0.5-1.fc19.x86_64
  file /usr/lib/debug from install of filesystem-3.2-4.fc19.x86_64 conflicts 
with file from package
gstreamer1-plugins-good-debuginfo-1.0.5-2.fc19.x86_64
  file /usr/lib/debug from install of filesystem-3.2-4.fc19.x86_64 conflicts 
with file from package
gstreamer1-plugins-base-debuginfo-1.0.5-2.fc19.x86_64



am excluding the filesystem update for now.


-- 

Regards,


Kevin Martin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: This mornings yum update....

[Kevin Martin]

On 02/21/13 08:49, Michael Schwendt wrote:
 On Thu, 21 Feb 2013 08:42:56 -0600, Kevin Martin wrote:
 
 gives me this error:

 Transaction check error:
   file /usr/lib/debug from install of filesystem-3.2-4.fc19.x86_64 conflicts 
 with file from package
 gstreamer1-plugins-bad-free-debuginfo-1.0.5-1.fc19.x86_64
   file /usr/lib/debug from install of filesystem-3.2-4.fc19.x86_64 conflicts 
 with file from package
 gstreamer1-plugins-good-debuginfo-1.0.5-2.fc19.x86_64
   file /usr/lib/debug from install of filesystem-3.2-4.fc19.x86_64 conflicts 
 with file from package
 gstreamer1-plugins-base-debuginfo-1.0.5-2.fc19.x86_64



 am excluding the filesystem update for now.
 
 https://bugzilla.redhat.com/911831
 

Thanks Michael.

Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Just reporting....

[Kevin Martin]

that in rawhide if I try to edit a grub entry at boot time (too either set or 
unset something in the linux line for example) I get a
blank screen and no ability to edit, boot, etc. without a hard reset.  This is 
with the latest updates from yesterday.  IMO, the
boot menu has taken a step back in looks and, now, in functionality.


-- 

Regards,


Kevin Martin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Rawhide] Re: Just reporting....

[Kevin Martin]

Hasn't worked for quite a while (pretty much ever since they updated the grub 
menu boot time layout).  Is the grub boot menu stuff
in the anaconda package?  I'm not even sure where to start looking for it.

Kevin

On 01/09/13 08:09, Frank Murphy wrote:
 On Wed, 09 Jan 2013 08:05:06 -0600
 Kevin Martin ktm...@gmail.com wrote:
 
 that in rawhide if I try to edit a grub entry at boot time (too
 either set or unset something in the linux line for example) I get
 a blank screen and no ability to edit, boot, etc. without a hard
 reset.  This is with the latest updates from yesterday.  IMO, the
 boot menu has taken a step back in looks and, now, in functionality.


 
 Have you a list of said updates?
 That you can work through to find the culprit.
 

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Rawhide] Re: Just reporting....

[Kevin Martin]

On 01/09/13 08:20, Kevin Martin wrote:
 Hasn't worked for quite a while (pretty much ever since they updated the grub 
 menu boot time layout).  Is the grub boot menu stuff
 in the anaconda package?  I'm not even sure where to start looking for it.
 
 Kevin
 
 On 01/09/13 08:09, Frank Murphy wrote:
 On Wed, 09 Jan 2013 08:05:06 -0600
 Kevin Martin ktm...@gmail.com wrote:

 that in rawhide if I try to edit a grub entry at boot time (too
 either set or unset something in the linux line for example) I get
 a blank screen and no ability to edit, boot, etc. without a hard
 reset.  This is with the latest updates from yesterday.  IMO, the
 boot menu has taken a step back in looks and, now, in functionality.



 Have you a list of said updates?
 That you can work through to find the culprit.

 
Argh, sorry for the top post.  Too used to answering email from those who 
expect top posting!

Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Rawhide] Re: Just reporting....

[Kevin Martin]

On 01/09/13 08:41, Frank Murphy wrote:
 On Wed, 09 Jan 2013 08:20:01 -0600
 Kevin Martin ktm...@gmail.com wrote:
 
 Hasn't worked for quite a while (pretty much ever since they
 updated the grub menu boot time layout).  Is the grub boot menu
 stuff in the anaconda package?  I'm not even sure where to start
 looking for it.

 Kevin

 
 What point did you upgrade to Rawhide.
 New grub2 is in use since Fedora 16 was released.
 
 
Been running rawhide for well over a year.  The boot editing issue has occurred 
essentially since the anaconda changes.  I did a
reinstall of my system with the F18 beta DVD about 4 months ago; that's when I 
started noticing the problem.  I've since then been
updating my system from the rawhide repos.

Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Rawhide] Re: Just reporting....

[Kevin Martin]

On 01/09/13 09:26, Frank Murphy wrote:
 On Wed, 09 Jan 2013 09:11:18 -0600
 Kevin Martin ktm...@gmail.com wrote:
 
 Been running rawhide for well over a year.  The boot editing issue
 has occurred essentially since the anaconda changes.  I did a
 reinstall of my system with the F18 beta DVD about 4 months ago;
 that's when I started noticing the problem.  I've since then been
 updating my system from the rawhide repos.

 Kevin
 
 You don't need anaconda for an installed system.
 Am running Rawhide here with no boot problems.
 Though I have removed all the advanced sub-menu
 as it wasn't necessary in my particular boxes.
 
 Can you boot from an earlier kernel?
 do your logs give any hint of a problem.
 

I understand that anaconda is not needed for a running system.  And I'm not 
having a problem booting into any of my kernels; I found
the problem when I went to add some debug information on the fly to the linux 
line in the kernel I was booting and found that
after hitting 'e' to edit it showed nothing to edit, 'c' for commandline seemed 
to do nothing, the option for booting did nothing,
and I couldn't get back to the grub menu.  I had to hard reset to get back to 
where I could see the grub menu. Tom Horsley mentioned
the gfx stuff in grub. I'm going to look at that and see what happens if I 
disable it.

Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Rawhide] Re: Just reporting....

[Kevin Martin]

On 01/09/13 09:46, Frank Murphy wrote:
 On Wed, 09 Jan 2013 09:32:50 -0600
 Kevin Martin ktm...@gmail.com wrote:
 
 
 
 Just a thought do you have the menu with advanced sub-menu
 Maybe you can only edit those in the sub-menu?
 If that's what you have.
 
 
So setting GRUB_TERMINAL=console and rebuilding my grub2.cfg does the trick.  
I now get the old style grub menu and can edit the
entries, either directly or via the Advanced sub menu.  Seems like another 
example of people fixing a non-existent problem.  The
grub menu doesn't need to be fancy, just operational.  Adding complexity to it 
in the name of trying to make it look good is begging
for problems.

Thanks Tom and Frank for your help.

Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

yum update failing for last 2 days....can't find any mirrors....

[Kevin Martin]

--- Package snakeyaml.noarch 0:1.11-1.fc19 will be installed
-- Running transaction check
--- Package jboss-jaxrpc-1.1-api.noarch 0:1.0.1-1.fc19 will be installed
-- Processing Dependency: jboss-servlet-3.0-api for package: 
jboss-jaxrpc-1.1-api-1.0.1-1.fc19.noarch
--- Package jboss-transaction-1.1-api.noarch 0:1.0.1-2.fc19 will be installed
--- Package sisu.noarch 0:2.3.0-1.fc19 will be an update
-- Processing Dependency: osgi(org.sonatype.sisu.guava) for package: 
sisu-2.3.0-1.fc19.noarch
-- Running transaction check
--- Package jboss-servlet-3.0-api.noarch 0:1.0.1-3.fc18 will be installed
--- Package sisu.noarch 0:2.3.0-1.fc19 will be an update
-- Processing Dependency: osgi(org.sonatype.sisu.guava) for package: 
sisu-2.3.0-1.fc19.noarch
http://mirror.seas.harvard.edu/fedora/linux/development/rawhide/x86_64/os/repodata/e92b9ceb3d0f11e5812bdfbb7ad9f971e5c7b8d95712d9731da91131e49c1462-filelists.sqlite.bz2:
[Errno 14] HTTP Error 404 - Not Found :
http://mirror.seas.harvard.edu/fedora/linux/development/rawhide/x86_64/os/repodata/e92b9ceb3d0f11e5812bdfbb7ad9f971e5c7b8d95712d9731da91131e49c1462-filelists.sqlite.bz2
Trying other mirror.
http://mirrors.tummy.com/pub/fedora.redhat.com/fedora/linux/development/rawhide/x86_64/os/repodata/e92b9ceb3d0f11e5812bdfbb7ad9f971e5c7b8d95712d9731da91131e49c1462-filelists.sqlite.bz2:
[Errno 14] HTTP Error 404 - Not Found :
http://mirrors.tummy.com/pub/fedora.redhat.com/fedora/linux/development/rawhide/x86_64/os/repodata/e92b9ceb3d0f11e5812bdfbb7ad9f971e5c7b8d95712d9731da91131e49c1462-filelists.sqlite.bz2
Trying other mirror.
http://linux.mirrors.es.net/fedora/development/rawhide/x86_64/os/repodata/e92b9ceb3d0f11e5812bdfbb7ad9f971e5c7b8d95712d9731da91131e49c1462-filelists.sqlite.bz2:
[Errno 14] HTTP Error 404 - Not Found :
http://linux.mirrors.es.net/fedora/development/rawhide/x86_64/os/repodata/e92b9ceb3d0f11e5812bdfbb7ad9f971e5c7b8d95712d9731da91131e49c1462-filelists.sqlite.bz2
Trying other mirror.
http://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/x86_64/os/repodata/e92b9ceb3d0f11e5812bdfbb7ad9f971e5c7b8d95712d9731da91131e49c1462-filelists.sqlite.bz2:
[Errno 14] HTTP Error 404 - Not Found :
http://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/x86_64/os/repodata/e92b9ceb3d0f11e5812bdfbb7ad9f971e5c7b8d95712d9731da91131e49c1462-filelists.sqlite.bz2
Trying other mirror.
http://mirrors.syringanetworks.net/fedora/development/rawhide/x86_64/os/repodata/e92b9ceb3d0f11e5812bdfbb7ad9f971e5c7b8d95712d9731da91131e49c1462-filelists.sqlite.bz2:
[Errno 14] HTTP Error 404 - Not Found :
http://mirrors.syringanetworks.net/fedora/development/rawhide/x86_64/os/repodata/e92b9ceb3d0f11e5812bdfbb7ad9f971e5c7b8d95712d9731da91131e49c1462-filelists.sqlite.bz2
Trying other mirror.

-- 

Regards,


Kevin Martin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

since yesterdays update I can't su - anymore....

[Kevin Martin]

su - gives the following error:

su: options --{shell,fast,command,session-command,login} and --user are 
mutually exclusive.


su root allows me to enter the root passwordwhat's happened to su -?


-- 

Regards,


Kevin Martin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

todays yum update....lots of errors....

[Kevin Martin]

Todays yum update came up with lots of errors.  Perhaps they are related to 
ldconfig and/or issues with libraries not getting linked
correctly but who knows?  Anyway, here's the errors:

Running Transaction
  Updating   : 1:libreoffice-ure-3.6.3.2-2.fc19.x86_64
  1/192
  Updating   : nss-util-3.14-2.fc19.x86_64
  2/192
warning: %post(nss-util-3.14-2.fc19.x86_64) scriptlet failed, signal 11
Non-fatal POSTIN scriptlet failure in rpm package nss-util-3.14-2.fc19.x86_64
  Updating   : numactl-libs-2.0.8-1.fc19.x86_64
  3/192
warning: %post(numactl-libs-2.0.8-1.fc19.x86_64) scriptlet failed, signal 11
Non-fatal POSTIN scriptlet failure in rpm package 
numactl-libs-2.0.8-1.fc19.x86_64
  Updating   : libvirt-client-0.10.2.1-1.fc19.x86_64
  4/192
/var/tmp/rpm-tmp.uomyir: line 2: 12552 Segmentation fault  (core dumped) 
/sbin/ldconfig
warning: %post(libvirt-client-0.10.2.1-1.fc19.x86_64) scriptlet failed, exit 
status 139
Non-fatal POSTIN scriptlet failure in rpm package 
libvirt-client-0.10.2.1-1.fc19.x86_64
  Updating   : maven-surefire-2.12.4-2.fc19.noarch
  5/192
  Updating   : mesa-libglapi-9.0-3.fc19.x86_64
  6/192
warning: %post(mesa-libglapi-9.0-3.fc19.x86_64) scriptlet failed, signal 11
Non-fatal POSTIN scriptlet failure in rpm package 
mesa-libglapi-9.0-3.fc19.x86_64
  Updating   : bzip2-libs-1.0.6-7.fc19.x86_64
  7/192
warning: %post(bzip2-libs-1.0.6-7.fc19.x86_64) scriptlet failed, signal 11
Non-fatal POSTIN scriptlet failure in rpm package bzip2-libs-1.0.6-7.fc19.x86_64
  Updating   : openssh-6.1p1-2.fc19.x86_64
  8/192
  Updating   : 2:libwbclient-4.0.0-161.fc19.rc3.x86_64
  9/192
warning: %post(libwbclient-2:4.0.0-161.fc19.rc3.x86_64) scriptlet failed, 
signal 11
Non-fatal POSTIN scriptlet failure in rpm package 
2:libwbclient-4.0.0-161.fc19.rc3.x86_64
  Updating   : 2:samba-libs-4.0.0-161.fc19.rc3.x86_64
 10/192
warning: %post(samba-libs-2:4.0.0-161.fc19.rc3.x86_64) scriptlet failed, signal 
11
Non-fatal POSTIN scriptlet failure in rpm package 
2:samba-libs-4.0.0-161.fc19.rc3.x86_64
  Updating   : 2:samba-common-4.0.0-161.fc19.rc3.x86_64
 11/192
/var/tmp/rpm-tmp.al8sdb: line 1: 12644 Segmentation fault  (core dumped) 
/sbin/ldconfig
  Updating   : nss-softokn-freebl-3.14-2.fc19.x86_64
 12/192
  Updating   : 12:dhcp-libs-4.2.4-20.P2.fc19.x86_64
 13/192
warning: %post(dhcp-libs-12:4.2.4-20.P2.fc19.x86_64) scriptlet failed, signal 11
Non-fatal POSTIN scriptlet failure in rpm package 
12:dhcp-libs-4.2.4-20.P2.fc19.x86_64
  Updating   : 12:dhcp-common-4.2.4-20.P2.fc19.x86_64
 14/192
  Updating   : nss-softokn-3.14-2.fc19.x86_64
 15/192
warning: %post(nss-softokn-3.14-2.fc19.x86_64) scriptlet failed, signal 11
Non-fatal POSTIN scriptlet failure in rpm package nss-softokn-3.14-2.fc19.x86_64
  Updating   : nss-sysinit-3.14-4.fc19.x86_64
 16/192
  Updating   : nss-3.14-4.fc19.x86_64
 17/192
warning: %post(nss-3.14-4.fc19.x86_64) scriptlet failed, signal 11
Non-fatal POSTIN scriptlet failure in rpm package nss-3.14-4.fc19.x86_64
  Updating   : 2:libsmbclient-4.0.0-161.fc19.rc3.x86_64
 18/192
warning: %post(libsmbclient-2:4.0.0-161.fc19.rc3.x86_64) scriptlet failed, 
signal 11
Non-fatal POSTIN scriptlet failure in rpm package 
2:libsmbclient-4.0.0-161.fc19.rc3.x86_64
  Updating   : bzip2-1.0.6-7.fc19.x86_64
 19/192
  Updating   : libvirt-daemon-0.10.2.1-1.fc19.x86_64
 20/192
  Updating   : libvirt-daemon-driver-network-0.10.2.1-1.fc19.x86_64
 21/192
  Updating   : libvirt-daemon-driver-qemu-0.10.2.1-1.fc19.x86_64
 22/192
  Updating   : libvirt-daemon-driver-lxc-0.10.2.1-1.fc19.x86_64
 23/192
  Updating   : libvirt-daemon-driver-interface-0.10.2.1-1.fc19.x86_64
 24/192
  Updating   : libvirt-daemon-driver-secret-0.10.2.1-1.fc19.x86_64
 25/192
  Updating   : libvirt-daemon-config-network-0.10.2.1-1.fc19.x86_64
 26/192
  Updating   : libvirt-daemon-driver-nodedev-0.10.2.1-1.fc19.x86_64
 27/192
  Updating   : libvirt-daemon-driver-uml-0.10.2.1-1.fc19.x86_64
 28/192
  Updating   : libvirt-daemon-driver-nwfilter-0.10.2.1-1.fc19.x86_64
 29/192
  Updating   : libvirt-daemon-config-nwfilter-0.10.2.1-1.fc19.x86_64
 30/192
  Updating   : libvirt-daemon-driver-storage-0.10.2.1-1.fc19.x86_64
 31/192
  Updating   : mesa-libgbm-9.0-3.fc19.x86_64
 32/192
warning: %post(mesa-libgbm-9.0-3.fc19.x86_64) scriptlet failed, signal 11
Non-fatal POSTIN scriptlet failure in rpm package mesa-libgbm-9.0-3.fc19.x86_64
  Updating   : mesa-libGL-9.0-3.fc19.x86_64
 33/192
warning: %post(mesa-libGL-9.0-3.fc19.x86_64) scriptlet failed, signal 11
Non-fatal POSTIN scriptlet failure in rpm package mesa-libGL-9.0-3.fc19.x86_64
  Updating   : maven-surefire-provider-junit-2.12.4-2.fc19.noarch
 34/192
  Updating   : 1:libreoffice-opensymbol-fonts-3.6.3.2-2.fc19.noarch
 

Re: More experiences with F18

[Kevin Martin]

On 10/25/12 23:42, Chuck Forsberg WA7KGX N2469R wrote:
 While waiting for a more functional Anaconda I have been
 running 64 bit F18 with yum updates.
 
 The Noveau driver still crashes.  Fortunately Nvidia still installs.
 
 I am able to run SCO Openserver 5.0.7 under the virtual machine.
 Select i686, pcnet, and 4.4bsd.
 
 Audacity puts its data in the root segment by default.   This eventually
 overflows the small root FS generated by Anaconda.
 
 
 
Hmm, I wonder if they've made changes in upstream nouveau.  I'm running rawhide 
and have not experienced any crashes of nouveau
(although I have other issues with nouveau, just not crashing) and *can't* get 
the nvidia driver to install (either from rpmfusion
or from nvidia directly; it doesn't build from the akmod, there is no kmod 
package for my kernel, and the nvidia .run file won't
build (I've sent a request to nvidia for help after doing some debugging)).  It 
appears that the nvidia builder script doesn't take
into account include files that have been moved to uapi and/or generated/uapi 
(why must something that's working be messed with all
of the time?).

Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: More experiences with F18

[Kevin Martin]

On 10/26/12 10:44, Chuck Forsberg WA7KGX N2469R wrote:
 
 On 10/26/2012 06:21 AM, Kevin Martin wrote:
 On 10/25/12 23:42, Chuck Forsberg WA7KGX N2469R wrote:
 While waiting for a more functional Anaconda I have been
 running 64 bit F18 with yum updates.

 The Noveau driver still crashes.  Fortunately Nvidia still installs.

 I am able to run SCO Openserver 5.0.7 under the virtual machine.
 Select i686, pcnet, and 4.4bsd.

 Audacity puts its data in the root segment by default.   This eventually
 overflows the small root FS generated by Anaconda.



 Hmm, I wonder if they've made changes in upstream nouveau.  I'm running 
 rawhide and have not experienced any crashes of nouveau
 (although I have other issues with nouveau, just not crashing) and *can't* 
 get the nvidia driver to install (either from rpmfusion
 or from nvidia directly; it doesn't build from the akmod, there is no kmod 
 package for my kernel, and the nvidia .run file won't
 build (I've sent a request to nvidia for help after doing some debugging)).  
 It appears that the nvidia builder script doesn't take
 into account include files that have been moved to uapi and/or 
 generated/uapi (why must something that's working be messed with all
 of the time?).

 Kevin
  I am using NVIDIA-Linux-x86_64-304.60.run
 
 1.  Change rhgb quiet to nomodeset in the active grub.cfg entry
 2.  Reboot
 3.  init 3
 4.  sh NV*
 
 As I keyboard this, I am running Xfce with composting on.
 Random screensavers are enabled.  WSPR is running with
 one sound card and a real serial port.  Lady Heather is
 running under Wine using a USB serial port to talk to
 a Trimble Thunderbolt.  Ham Radio Deluxe's rotator control
 under Wine interrogates a rotator 1/sec using the other
 USB serial port.  Audacity has been recording sound
 using the motherboard sound device for 21 hours.
 I have also been playing with SCO Openserver 5.0.7 under
 the virtual machine manager.  Also have been using
 VNC, Firefox to talk to the world.  The system has not crashed
 using the Nvidia driver.  Knock on wood.
 
 
Which kernel are you running?  I can't get 304.60 to build on 
3.7.0-0.rc2.git1.2.fc19.x86_64 (rawhide).  It can't figure out the
kernel version so it won't even try to build.


Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: More experiences with F18

[Kevin Martin]

On 10/26/12 11:25, Chuck Forsberg WA7KGX N2469R wrote:
 
 On 10/26/2012 09:22 AM, Kevin Martin wrote:
 On 10/26/12 10:44, Chuck Forsberg WA7KGX N2469R wrote:
 On 10/26/2012 06:21 AM, Kevin Martin wrote:
 On 10/25/12 23:42, Chuck Forsberg WA7KGX N2469R wrote:
 While waiting for a more functional Anaconda I have been
 running 64 bit F18 with yum updates.

 The Noveau driver still crashes.  Fortunately Nvidia still installs.

 I am able to run SCO Openserver 5.0.7 under the virtual machine.
 Select i686, pcnet, and 4.4bsd.

 Audacity puts its data in the root segment by default.   This eventually
 overflows the small root FS generated by Anaconda.



 Hmm, I wonder if they've made changes in upstream nouveau.  I'm running 
 rawhide and have not experienced any crashes of nouveau
 (although I have other issues with nouveau, just not crashing) and *can't* 
 get the nvidia driver to install (either from rpmfusion
 or from nvidia directly; it doesn't build from the akmod, there is no kmod 
 package for my kernel, and the nvidia .run file won't
 build (I've sent a request to nvidia for help after doing some 
 debugging)).  It appears that the nvidia builder script doesn't take
 into account include files that have been moved to uapi and/or 
 generated/uapi (why must something that's working be messed with all
 of the time?).

 Kevin
   I am using NVIDIA-Linux-x86_64-304.60.run

 1.  Change rhgb quiet to nomodeset in the active grub.cfg entry
 2.  Reboot
 3.  init 3
 4.  sh NV*

 As I keyboard this, I am running Xfce with composting on.
 Random screensavers are enabled.  WSPR is running with
 one sound card and a real serial port.  Lady Heather is
 running under Wine using a USB serial port to talk to
 a Trimble Thunderbolt.  Ham Radio Deluxe's rotator control
 under Wine interrogates a rotator 1/sec using the other
 USB serial port.  Audacity has been recording sound
 using the motherboard sound device for 21 hours.
 I have also been playing with SCO Openserver 5.0.7 under
 the virtual machine manager.  Also have been using
 VNC, Firefox to talk to the world.  The system has not crashed
 using the Nvidia driver.  Knock on wood.


 Which kernel are you running?  I can't get 304.60 to build on 
 3.7.0-0.rc2.git1.2.fc19.x86_64 (rawhide).  It can't figure out the
 kernel version so it won't even try to build.


 Kevin
  uname -a
 Linux omen3.omen.com 3.6.3-3.fc18.x86_64 #1 SMP Tue Oct 23 14:55:06 UTC 2012 
 x86_64 x86_64 x86_64 GNU/Linux
 [caf@omen3 X11]$ ll N*
 -rw-r--r-- 1 root root 64146553 Oct 25 03:47 NVIDIA-Linux-x86_64-304.60.run
 
 Yum update is current.
 
I think between 3.6 and 3.7 there was a change of where some of the kernel 
source include files are held (from
/usr/src/kernels/`uname -r`/include to /usr/src/kernels/`uname -r`/include/uapi 
and /usr/src/kernels/`uname
-r`/include/generated/uapi) that is screwing up building of the nvidia drivers 
(for example, in 3.7, the version.h file found under
include/linux is empty and has been moved to include//generated/uapi/linux but 
the nvidia-installer sript run by the .run script
doesn't find that version (either at all or early enough to be able to use it).

Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

texlive-base fails install (rawhide)

[Kevin Martin]

Todays yum update has a failure for texlive-base:

Downloading Packages:
texlive-base-2012-3.20121019_r28030.fc19.noarch.rpm 
 | 1.3
MB  00:00:03
Running Transaction Check
Running Transaction Test
Transaction Test Succeeded
Running Transaction
  Updating   : 1:texlive-base-2012-3.20121019_r28030.fc19.noarch
1/2
Error unpacking rpm package 1:texlive-base-2012-3.20121019_r28030.fc19.noarch
error: unpacking of archive failed on file /usr/share/texlive/texmf-local: 
cpio: rename
  Verifying  : 1:texlive-base-2012-3.20121019_r28030.fc19.noarch
1/2
1:texlive-base-2012-3.20120926_r27815.fc19.noarch was supposed to be removed 
but is not!
  Verifying  : 1:texlive-base-2012-3.20120926_r27815.fc19.noarch


This happened twice so I'm assuming the rpm is wrong, not the download.

-- 

Regards,


Kevin Martin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Adventures with TC4

[Kevin Martin]

On 10/16/12 22:39, Chuck Forsberg WA7KGX N2469R wrote:
 I have installed TC4 netinst a couple of times.
 The problem with the screen going black during the default install remains.
 
 I did another install after changing quiet to nomodeset in netinst.
 This install proceeded properly, albeit at reduced resolution.
 (Modulo dealing with a non empty HD)
 
 The resulting system ran smoothly but still at less than full 1920x1080 res.
 I successfully installed both the current release and later beta test Nvidia
 display drivers.  Both worked properly doing the usual stuff for many hours
 (WSPR, Audacity recording, LadyHeather in Wine).
 
 Later I went back to the Noveau based HD to do some stuff and Noveau
 spazzed out after about a half hour.
 
 I haven't checked server functions but other than Anaconda it seems
 the cow may be able to give milk.
 
On top of that when I last did a TC4 netinstall (2 days ago) I was unable to 
use the closest mirror option for selecting
software...I ended up using http and putting in a mirror to let me do the 
install.  If closest mirror is an option than, darn it
all to heck, it should work and every time (as long as networking is set up, 
which, in my case, it was).

Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Adventures with TC4

[Kevin Martin]

On 10/17/12 09:06, Chuck Forsberg WA7KGX N2469R wrote:
 
 On 10/17/2012 06:21 AM, Kevin Martin wrote:
 On 10/16/12 22:39, Chuck Forsberg WA7KGX N2469R wrote:
 I have installed TC4 netinst a couple of times.
 The problem with the screen going black during the default install remains.

 I did another install after changing quiet to nomodeset in netinst.
 This install proceeded properly, albeit at reduced resolution.
 (Modulo dealing with a non empty HD)

 The resulting system ran smoothly but still at less than full 1920x1080 res.
 I successfully installed both the current release and later beta test Nvidia
 display drivers.  Both worked properly doing the usual stuff for many hours
 (WSPR, Audacity recording, LadyHeather in Wine).

 Later I went back to the Noveau based HD to do some stuff and Noveau
 spazzed out after about a half hour.

 I haven't checked server functions but other than Anaconda it seems
 the cow may be able to give milk.

 On top of that when I last did a TC4 netinstall (2 days ago) I was unable to 
 use the closest mirror option for selecting
 software...I ended up using http and putting in a mirror to let me do the 
 install.  If closest mirror is an option than, darn it
 all to heck, it should work and every time (as long as networking is set up, 
 which, in my case, it was).

 Kevin
 The last few times I've done F18 netinstall a working mirror was selected 
 automatically.
 It disn't ask and I didn't tell.
 
 I have no idea what mirror was chosen.  The closest mirror may not be the 
 best anyway.
 
Hmm, interesting.  When I did the install it would *not* choose a mirror and 
hence would not give me an option for choosing the
software I wanted to install.  This was an install into a VirtualBox host but 
really, why should that matter?  It allowed me to
setup networking, it saw an ntp server, and it let me install using http, so 
why wouldn't it go ahead and choose a mirror.  Go figure!

Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

yum update failing on rpm-libs update...

[Kevin Martin]

Tried to do a yum update for rawhide and it hangs.  There appears to be 
something wrong with /sbin/ldconfig from
glibc-2.16.90-24.fc19.x86_64.rpm.  Every yum update I do now hangs while trying 
to do an /sbin/ldconfig and if I try to update via
rpm and then attach an strace to the pid doing the ldconfig ldconfig cores and 
the update continues (probably not the behaviour we
want to see).  Is there a newer version of glibc available and/or what changed 
in ldconfig?

Regards,


Kevin Martin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: yum update failing on rpm-libs update...

[Kevin Martin]

On 10/17/12 11:53, Kevin Martin wrote:
 Tried to do a yum update for rawhide and it hangs.  There appears to be 
 something wrong with /sbin/ldconfig from
 glibc-2.16.90-24.fc19.x86_64.rpm.  Every yum update I do now hangs while 
 trying to do an /sbin/ldconfig and if I try to update via
 rpm and then attach an strace to the pid doing the ldconfig ldconfig cores 
 and the update continues (probably not the behaviour we
 want to see).  Is there a newer version of glibc available and/or what 
 changed in ldconfig?
 
 Regards,
 
 
 Kevin Martin
 
ok, more info.  I found (by stracing /sbin/ldconfig) that it was failing as a 
result of the following 3 libraries in /usr/lib64 not
being linked correctly:

libboost_thread-mt.so
libopcodes.so
libbfd.so

Once I rm'd those files and linked them (as shown below) ldconfig ran to 
completion just fine.

ln -sf  /lib64/libboost_thread-mt.so.1.50.0 /lib64/libboost_thread-mt.so
ln -sf libopcodes-2.23.51.0.3-1.fc19.so libopcodes.so
ln -sf libbfd-2.23.51.0.3-1.fc19.so libbfd.so

Now a yum update from 3-4 days ago updated boost-devel and binutils-devel which 
is where those libraries come from.  Somebody needs
to take a look at the boost-devel-1.50.0-4.fc19.x86_64 and the 
binutils-devel-2.23.51.0.3-2.fc19.x86_64 rpm's and make sure that the
linking is correct.

Thanks again.

Kevin

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

ldconfig failing during yum update was :Re: yum update failing on rpm-libs update...

[Kevin Martin]

On 10/17/12 12:34, Kevin Fenzi wrote:
 Just as a datapoint I am not seeing this on my rawhide instance... ;( 
 
 So, not sure if it was an issue because I missed a days updates or
 what.
 
 kevin
 
 
 
It looks like it's not necessarily related to rpm-libs in particular but only 
to the fact that the boost-devel and binutils-devel
rpms don't seem to be linking some files in /usr/lib64 correctly.  Running a 
yum update now and I'm experiencing the same issue as I
was and binutils-devel was one of the updates (I was hoping it was an update 
that was fixing the linking problem but it doesn't
appear to be the case).  After the binutils-devel update I had to relink the 
two .so files again and then strace the ldconfig that
was running to get it to core (should it do that or is that a bug?) so the yum 
update could move forwardnow it's hung trying to
update valgrind but I don't know why.  I think I'm going to kill the yum update 
and run it again with some verbosity to see if I can
see where it's getting hung up.

Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

why would I be seeing kswapd0 using so much CPU?

[Kevin Martin]

I'm seeing this:

# top

top - 10:28:30 up 23:45,  9 users,  load average: 0.75, 0.83, 0.98
Tasks: 221 total,   2 running, 219 sleeping,   0 stopped,   0 zombie
%Cpu(s):  1.0 us, 27.5 sy,  0.0 ni, 69.9 id,  0.8 wa,  0.6 hi,  0.2 si,  0.0 st
KiB Mem:   3952540 total,  2834232 used,  1118308 free, 3024 buffers
KiB Swap:  4095996 total,   332780 used,  3763216 free,   163712 cached

  PID USER  PR  NI  VIRT  RES  SHR S  %CPU %MEMTIME+  COMMAND

   41 root  20   0 000 R  98.0  0.0 262:56.14 kswapd0

I'm not sure why this would be happening since I'm not using all of my memory 
and the swap used is almost nothing.  It's eating an
entire CPU!

Any thoughts?

Thanks.

Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: F18 TC3 No Logout Option?

[Kevin Martin]

snip
 This is a new feature from the GNOME team (i.e. it's intended). They believe 
 there are no use cases for logging out, if you have just a single user.
 
 It is a little more nuanced than that.
 
 We don't offer to log out if there is just a single user, and a single
 session (ie desktop env). I there is just a single user, and you have
 e.g. xfce installed, we currently show 'Switch session'. Unfortunately,
 that doesn't work, so we'll replace it with 'Log out'. If you have
 multiple users, we always show 'Log out'.
 
 The region panel, where you can switch your language (which only takes
 effect after logout currently, unfortunately), will get an explicit
 logout button.
 
 You can always end your session by running gnome-session-quit in a
 terminal.
 

Couple comments:

1). Since I boot to a non-graphical level and then run startx, I use logout 
when I'm doing an update to anything X related so I can
get back to a console, run the yum update, and then startx again without having 
to reboot (so there's a case for having a logout
option).

2). Opening a terminal and running gnome-session-quit is completely 
non-intuitive and a ridiculous option to just having the
logout button available.  I'm a long time user of Linux (and Gnome, KDE, XFCE, 
etc.) and I would have been hard pressed to come up
with this solution very quickly...anybody less experienced would never figure 
this out!

Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: F18 TC3 No Logout Option?

[kevin martin]

snip
 This is a new feature from the GNOME team (i.e. it's intended). They believe 
 there are no use cases for logging out, if you have just a single user.

 It is a little more nuanced than that.

 We don't offer to log out if there is just a single user, and a single
 session (ie desktop env). I there is just a single user, and you have
 e.g. xfce installed, we currently show 'Switch session'. Unfortunately,
 that doesn't work, so we'll replace it with 'Log out'. If you have
 multiple users, we always show 'Log out'.

 The region panel, where you can switch your language (which only takes
 effect after logout currently, unfortunately), will get an explicit
 logout button.

 You can always end your session by running gnome-session-quit in a
 terminal.


Couple comments:

1). Since I boot to a non-graphical level and then run startx, I use
logout when I'm doing an update to anything X related so I can
get back to a console, run the yum update, and then startx again
without having to reboot (so there's a case for having a logout
option).

2). Opening a terminal and running gnome-session-quit is completely
non-intuitive and a ridiculous option to just having the
logout button available.  I'm a long time user of Linux (and Gnome,
KDE, XFCE, etc.) and I would have been hard pressed to come up
with this solution very quickly...anybody less experienced would never
figure this out!

Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Has anybody else seen a delay in xfce?

[Kevin Martin]

On 10/08/12 13:26, Rick Stevens wrote:
 On 10/08/2012 05:15 AM, Kevin Martin issued this missive:
 snip
  
  
   --
  
   Regards,
  
   
   Kevin Martin
   --

  I use F17 and Xfce. My PC is very old (Athlon) so I see a delay when 
 switching to a thunderbird window but it's sometimes less
  than a second, sometimes maybe a couple of seconds.
  So specially if your computer isn't as old then maybe you have a video 
 driver issue? Just a guess that might be wrong.
  So the issue exists but for some reason you're having it exaggerated.
  --
  test mailing list
  test@lists.fedoraproject.org mailto:test@lists.fedoraproject.org
  To unsubscribe:
  https://admin.fedoraproject.org/mailman/listinfo/test


 I don't see any issues on my F18 instances (VirtualBox) and F18 installed 
 on my laptop, so it must be something there is depending
 on hardware.

 Tim


 Hmm, the switching problem is solved.  But a second problem (which I hoped 
 would be fixed if I got the switching problem figured
 out) still exists.

 For a little more background, in order to get the nouveau driver to work 
 with my card I had to set Option NoAccel 1   in the
 Devices section of my xorg.conf filewithout this X would crash every 
 time (there is an open bugzilla about this that nobody
 seems interested in working on).
 
 Are you certain you don't have something else in the
 /etc/X11/xorg.conf.d directory that's turning it back on?
 
  I used to start the OS with nouveau.noaccel=1 in the linux line but that 
 has stopped working (yet
 another bugzilla that nobody is working on that I can tell).  And I solved 
 my switching problem by adding this to my xorg.conf:

 Section Extensions
  Option Composite off
 EndSection

 So I can switch from workspace to workspace with no issue now.  The other 
 issue I'm still seeing is when I move a window within the
 workspace...instead of the window just moving to the new location that I 
 drag it to there is a noticeable delay in the repaint of
 the windowif I set it so that the content of the window is not shown 
 during the move it's less noticeable but still obvious.
 And occasionally the system doesn't recognize when I release the mouse 
 button during the move such that if I release the button but
 continue to move the mouse the window still follows the mouse and ends up in 
 a place that I didn't intend.

 So I'm getting closer and will continue to experiment.  Any thoughts or 
 suggestions greatly appreciated.
 --
 - Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com -
 - AIM/Skype: therps2ICQ: 22643734Yahoo: origrps2 -
 --
 -  Microsoft is a cross between The Borg and the Ferengi.   -
 -  Unfortunately they use Borg to do their marketing and Ferengi to  -
 -   do their programming.  -- Simon Slavin  -
 --
 
FWIW, here's my xorg.conf and contents of the file in the /etc/X11/xorg.conf.d 
directory:

Section ServerLayout
Identifier X.org Configured
Screen  0  Screen0 0 0
InputDeviceMouse0 CorePointer
InputDeviceKeyboard0 CoreKeyboard
EndSection

Section Files
ModulePath   /usr/lib64/xorg/modules
FontPath catalogue:/etc/X11/fontpath.d
FontPath built-ins
EndSection

Section Module
Load  glx
EndSection

Section InputDevice
Identifier  Keyboard0
Driver  kbd
EndSection

Section InputDevice
Identifier  Mouse0
Driver  mouse
Option  Protocol auto
Option  Device /dev/input/mice
Option  ZAxisMapping 4 5 6 7
EndSection

Section Monitor
Identifier   Monitor0
VendorName   Monitor Vendor
ModelNameMonitor Model
EndSection

Section Device
### Available Driver options are:-
### Values: i: integer, f: float, bool: True/False,
### string: String, freq: f Hz/kHz/MHz,
### percent: f%
### [arg]: arg optional
#Option SWcursor  # [bool]
#Option HWcursor  # [bool]
Option NoAccel 1# [bool]
#Option ShadowFB  # [bool]
#Option VideoKey  # i
#Option WrappedFB # [bool]
#Option GLXVBlank # [bool]
#Option ZaphodHeads   # str
#Option PageFlip  # [bool]
#Option SwapLimit # i
#Option AsyncUTSDFS   # [bool]
Identifier  Card0
Driver  nouveau
BusID   PCI:1:0:0
EndSection

Section Screen
Identifier

Has anybody else seen a delay in xfce?

[Kevin Martin]

When I switch from one workspace to another there is a noticeable delay (3-6 
seconds), whether I do it by mouse-wheel, by clicking
on an open application in the taskbar, by using ctl-alt-arrow, or by setting 
the window manager to Wrap workspaces when the pointer
reaches the screen edge and scrolling right or left.  In the last case, the 
smaller the Edge resistance the better but it's still a
noticeable delay.  One thing I *do* notice is that those workspaces with the 
largest number of open GUI applications seem to take
longer to switch to than those that don't.   So, for example, if I switch to a 
workspace that just shows some desktop icons the
switch is virtually instantaneous.  But then when switching to my workspace 
that has, say, Thunderbird running in it, it will take
upwards of 6 seconds or more.  As a matter of fact, while drafting this email I 
switched to a blank ws and then back to this ws and
the return switch took 8 seconds (since I had Thunderbird *and* the screen in 
which I was drafting this email open at the time).  I
then minimized Thunderbird and the new email GUI's and then switched back and 
forth with impunity.  So is this an xfce issue or an
X issue do you think?  I didn't see this behaviour in the past before starting 
to work with F18 and rawhide.


-- 

Regards,


Kevin Martin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

yum update of F18 showing a strange error...

[Kevin Martin]

While doing a yum update of F18 this morning I encountered the below error.  
Any information as to what/why this is would be
appreciated.

Running Transaction
  Updating   : tzdata-2012f-1.fc18.noarch   
   1/40
  Updating   : glibc-2.16-15.fc18.x86_64
   2/40
Failed to issue method call: Did not receive a reply. Possible causes include: 
the remote application did not send a reply, the
message bus security policy blocked the reply, the reply timeout expired, or 
the network connection was broken.
  Updating   : glibc-common-2.16-15.fc18.x86_64 
   3/40
  Updating   : php-common-5.4.7-2.fc18.x86_64   
   4/40
  Updating   : php-cli-5.4.7-2.fc18.x86_64  
   5/40
  Updating   : php-pdo-5.4.7-2.fc18.x86_64  
   6/40
  Updating   : glibc-headers-2.16-15.fc18.x86_64
   7/40
  Updating   : libsepol-2.1.8-1.fc18.x86_64 
   8/40
Failed to issue method call: Did not receive a reply. Possible causes include: 
the remote application did not send a reply, the
message bus security policy blocked the reply, the reply timeout expired, or 
the network connection was broken.

-- 

Regards,


Kevin Martin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: RC 3.1 Really broken

[kevin martin]

On Sep 15, 2012 4:13 AM, Chuck Forsberg WA7KGX N2469R c...@omen.com
wrote:


 On 09/15/2012 01:00 AM, Frank Murphy wrote:

 On 15/09/12 08:57, Chuck Forsberg WA7KGX N2469R wrote:

 I downloaded the  64 bit RC 3.1 and burned another DVD+R.
 This one does not even get to the language choice screen.

 A pxeboot from a locally mirrored rsync copy of
   mirrors1.kernel.org::fedora/development/18/x86_64/os
 wedged in the same place.

 The number of Fedora coasters I've made from DVD+R blanks
 is starting to affect my carbon footprint -;)


 Could you try it with a DVD-R?
 Changed my luck before.

 Same results with DVD-R.  Also same result on an AMD 6000
 with 9600gt card.

 The Fedora carbon footprint is getting larger:-)


 --
 Chuck Forsberg WA7KGX N2469R c...@omen.com   www.omen.com
 Developer of Industrial ZMODEM(Tm) for Embedded Applications
   Omen Technology Inc  The High Reliability Software
 10255 NW Old Cornelius Pass Portland OR 97231   503-614-0430

 --
 test mailing list
 test@lists.fedoraproject.org
 To unsubscribe:
 https://admin.fedoraproject.org/mailman/listinfo/test

Burn it on rw DVD.   It works usually and, if it doesn't you can always
return and you don't lose a DVD.

Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: F18 yum update bricks X

[kevin martin]

On Sep 13, 2012 3:37 PM, Chuck Forsberg WA7KGX N2469R c...@omen.com
wrote:

 After successfully installing RC3 and adding various
 packages to compile gnuradio et al. I issued a
 yum -y --skip-broken update

 This pparently updated Noveau or something to a
 version that doesn't quite work.  The cursor does
 not appear and I was unable to log in by using
 tab and cursor keys.

 This Noveau thing has happened once or twice before with F18.

 This time I was able to install the latest NVIDIA driver but the
 machine then locks up when I try to start X.

 Intel Core CPU, 8GB, Nvidia 480GT


 --
 Chuck Forsberg WA7KGX N2469R c...@omen.com   www.omen.com
 Developer of Industrial ZMODEM(Tm) for Embedded Applications
   Omen Technology Inc  The High Reliability Software
 10255 NW Old Cornelius Pass Portland OR 97231   503-614-0430

 --
 test mailing list
 test@lists.fedoraproject.org
 To unsubscribe:
 https://admin.fedoraproject.org/mailman/listinfo/test

It's nice to know I'm not the only one who can't run X with the latest
nvidia drivers.   Mine locks up with no errors as well.  I think it's
something in the new version of X (only because I've had the latest version
of the nvidia driver working with earlier version of X).

Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Test-Announce] Fedora 18 Alpha Test Compose 6 (TC6) Available Now!

[kevin martin]

On Sep 9, 2012 12:12 PM, Kamil Paral kpa...@redhat.com wrote:

  As per the Fedora 18 schedule [1], Fedora 18 Alpha Test Compose 6
  (TC6)
  is now available for testing.

 Please note that Live images are mislabeled (contain 'TC5' in their
name), but they are TC6 content.
 ___
 test-announce mailing list
 test-annou...@lists.fedoraproject.org .

 https://admin.fedoraproject.org/mailman/listinfo/test-announce
 --
 test mailing list
 test@lists.fedoraproject.org
 To unsubscribe:
 https://admin.fedoraproject.org/mailman/listinfo/test

I found the same problem with tc5.  Selected xfce4 install from DVD and the
city server was not installed.

Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: xorg IOPL issue under rawhide...can't run X

[kevin martin]

On Wed, Sep 5, 2012 at 9:03 AM, Adam Jackson a...@redhat.com wrote:

 On Tue, 2012-09-04 at 19:22 -0500, kevin martin wrote:
  Can't run X on my laptop anymore due to the IOPL error shown below.
  I've also included lines from an strace of xinit that I did at this
  same time.  Anybody with any thoughts on how to get this fixed so I
  can run X again?

 The only reason I can think of for this happening is if your selinux
 policy suddenly decided to start denying iopl.  Anything in dmesg?  Any
 recent selinux policy updates in 'yum history' ?

 - ajax

 --
 test mailing list
 test@lists.fedoraproject.org
 To unsubscribe:
 https://admin.fedoraproject.org/mailman/listinfo/test


Selinux is disabled on my machine and, to answer Josh, I can't run nouveau
on this machine with the 3.6 kernel as, to run nouveau on this machine, I
need to disable acceleration and whenever I do that with the kernel switch
that I used with the 3.5 kernel the machine won't even boot up...it locks
up hard when it tries to load the nouveau driver.  If I leave acceleration
on when I try to run starts X crashes.  I've filed multiple bugzillas about
this with no response so I had to switch to using the nvidia driver (which
I didn't want to do but in order to use the latest rawhide kernels had no
choice) and now even that doesn't work.

[root@ktmtoshiba]# sestatus
SELinux status: disabled

Thanks.

Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

xorg IOPL issue under rawhide...can't run X

[kevin martin]

Can't run X on my laptop anymore due to the IOPL error shown below.  I've
also included lines from an strace of xinit that I did at this same time.
Anybody with any thoughts on how to get this fixed so I can run X again?

[  7855.008]
X.Org X Server 1.12.3
Release Date: 2012-07-09
[  7855.011] X Protocol Version 11, Revision 0
[  7855.012] Build Operating System:  2.6.32-220.17.1.el6.x86_64
[  7855.014] Current Operating System: Linux ktmtoshiba
3.6.0-0.rc2.git2.1.fc18.x86_64 #1 SMP Wed Aug 22 11:54:04 UTC 2012 x86_64
[  7855.015] Kernel command line:
BOOT_IMAGE=/vmlinuz-3.6.0-0.rc2.git2.1.fc18.x86_64
root=UUID=872f0158-7e7d-43f6-9916-5c833804656a ro drm.debug=14
log_buf_len=16M SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us rd.b
river=nouveau nouveau.modeset=0
[  7855.021] Build Date: 09 July 2012  01:43:31AM
[  7855.022] Build ID: xorg-x11-server 1.12.3-1.fc18
[  7855.023] Current version of pixman: 0.27.2
[  7855.024]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[  7855.025] Markers: (--) probed, (**) from config file, (==) default
setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[  7855.036] (==) Log file: /var/log/Xorg.0.log, Time: Tue Sep  4
19:10:49 2012
[  7855.042] (==) Using config file: /etc/X11/xorg.conf
[  7855.043] (==) Using config directory: /etc/X11/xorg.conf.d
[  7855.044] (==) Using system config directory /usr/share/X11/xorg.conf.d
[  7855.053] (==) ServerLayout X.org Configured
[  7855.054] (**) |--Screen Screen0 (0)
[  7855.055] (**) |   |--Monitor Monitor0
[  7855.057] (**) |   |--Device Card0
[  7855.058] (**) |--Input Device Mouse0
[  7855.059] (**) |--Input Device Keyboard0
[  7855.060] (**) Option IgnoreABI true
[  7855.062] (**) Ignoring ABI Version
[  7855.063] (==) Automatically adding devices
[  7855.064] (==) Automatically enabling devices
[  7855.066] (**) FontPath set to:
catalogue:/etc/X11/fontpath.d,
built-ins,
catalogue:/etc/X11/fontpath.d,
built-ins
[  7855.067] (**) ModulePath set to /usr/lib64/xorg/modules
[  7855.069] (WW) Hotplugging is on, devices using drivers 'kbd', 'mouse'
or 'vmmouse' will be disabled.
[  7855.070] (WW) Disabling Mouse0
[  7855.071] (WW) Disabling Keyboard0
[  7855.072] (II) Loader magic: 0x7c6ae0
[  7855.073] (II) Module ABI versions:
[  7855.074]X.Org ANSI C Emulation: 0.4
[  7855.075]X.Org Video Driver: 12.0
[  7855.076]X.Org XInput driver : 16.0
[  7855.077]X.Org Server Extension : 6.0
[  7855.111] (--) PCI:*(0:1:0:0) 10de:0cb1:1179:ff50 rev 162, Mem @
0xcc00/16777216, 0xd000/268435456, 0xce00/33554432, I/O @
0x2000/128, BIOS @ 0x/65536
[  7855.124] (II) extmod will be loaded. This was enabled by default and
also specified in the config file.
[  7855.125] (II) dbe will be loaded. This was enabled by default and
also specified in the config file.
[  7855.125] (II) glx will be loaded. This was enabled by default and
also specified in the config file.
[  7855.126] (II) record will be loaded. This was enabled by default and
also specified in the config file.
[  7855.127] (II) dri will be loaded. This was enabled by default and
also specified in the config file.
[  7855.128] (II) dri2 will be loaded. This was enabled by default and
also specified in the config file.
[  7855.129] (II) LoadModule: dbe
[  7855.141] (II) Loading /usr/lib64/xorg/modules/extensions/libdbe.so
[  7855.145] (II) Module dbe: vendor=X.Org Foundation
[  7855.146]compiled for 1.12.3, module version = 1.0.0
[  7855.148]Module class: X.Org Server Extension
[  7855.149]ABI class: X.Org Server Extension, version 6.0
[  7855.150] (II) Loading extension DOUBLE-BUFFER
[  7855.151] (II) LoadModule: glx
[  7855.162] (II) Loading /usr/lib64/xorg/modules/extensions/libglx.so
[  7855.189] (II) Module glx: vendor=NVIDIA Corporation
[  7855.191]compiled for 4.0.2, module version = 1.0.0
[  7855.193]Module class: X.Org Server Extension
[  7855.194] (II) NVIDIA GLX Module  304.43  Sun Aug 19 20:34:01 PDT 2012
[  7855.194] (II) Loading extension GLX
[  7855.195] (II) LoadModule: extmod
[  7855.204] (II) Loading /usr/lib64/xorg/modules/extensions/libextmod.so
[  7855.215] (II) Module extmod: vendor=X.Org Foundation
[  7855.217]compiled for 1.12.3, module version = 1.0.0
[  7855.218]Module class: X.Org Server Extension
[  7855.220]ABI class: X.Org Server Extension, version 6.0
[  7855.221] (II) Loading extension SELinux
[  7855.222] (II) Loading extension MIT-SCREEN-SAVER
[  7855.224] (II) Loading extension XFree86-VidModeExtension
[  7855.225] (II) Loading extension XFree86-DGA
[  7855.227] (II) Loading extension DPMS
[  7855.228] (II) Loading extension XVideo
[  7855.229] (II) Loading extension XVideo-MotionCompensation
[  7855.231] (II) Loading extension X-Resource
[  7855.232] (II) LoadModule: record
[  7855.248] (II) 

Re: Rawhide file-conflict gnupg gnupg2

[Kevin Martin]

On 07/27/2012 04:37 AM, Frank Murphy wrote:
 Transaction Check Error:
   file /usr/share/man/man1/gpg-zip.1.gz from install of 
 gnupg2-2.0.19-3.fc18.i686 conflicts with file from package
 gnupg-1.4.12-2.fc18.i686
 
Do you need both gnupg and gnupg2 on the same system at the same time?  What 
happens if you yum update with
--setopt=protected_multilib=false in the update line?

Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Rawhide file-conflict gnupg gnupg2

[Kevin Martin]

On 07/27/2012 10:17 AM, Frank Murphy wrote:
 On 27/07/12 14:22, Kevin Martin wrote:
 On 07/27/2012 04:37 AM, Frank Murphy wrote:
 Transaction Check Error:
file /usr/share/man/man1/gpg-zip.1.gz from install of 
 gnupg2-2.0.19-3.fc18.i686 conflicts with file from package
 gnupg-1.4.12-2.fc18.i686

 Do you need both gnupg and gnupg2 on the same system at the same time?
 
 yum erase gnupg, will remove just gnupg
 yum erase gnupg2 want's to erase a lot of pkgs.
 
 so may erase gnupg, see what happens.
 
  What happens if you yum update with
 --setopt=protected_multilib=false in the update line?

 Kevin

 
 yum update --setopt=protected_multilib=false
 Loaded plugins: downloadonly, fastestmirror, langpacks, local, presto, 
 refresh-
   : packagekit, refresh-updatesd, tidy-cache
 Loading mirror speeds from cached hostfile
  * rawhide: vesta.informatik.rwth-aachen.de
 Resolving Dependencies
 -- Running transaction check
 --- Package gnupg2.i686 0:2.0.19-2.fc18 will be updated
 --- Package gnupg2.i686 0:2.0.19-3.fc18 will be an update
 --- Package libGLEW.i686 0:1.6.0-2.fc17 will be updated
 -- Processing Dependency: libGLEW.so.1.6 for package: 
 glx-utils-7.10-7.20101028.fc18.i686
 --- Package libGLEW.i686 0:1.7.0-3.fc18 will be an update
 -- Finding unneeded leftover dependencies
 Found and removing 0 unneeded dependencies
 -- Running transaction check
 --- Package libGLEW.i686 0:1.6.0-2.fc17 will be updated
 --- Package libGLEW.i686 0:1.7.0-3.fc18 will be an update
 -- Running transaction check
 --- Package gnupg2.i686 0:2.0.19-2.fc18 will be updated
 --- Package gnupg2.i686 0:2.0.19-3.fc18 will be an update
 -- Finished Dependency Resolution
 
 Packages skipped because of dependency problems:
 libGLEW-1.7.0-3.fc18.i686 from koji
 
 Dependencies Resolved
 
 
  Package   Arch   Version  Repository Size
 
 Updating:
  gnupg2i686   2.0.19-3.fc18koji1.4 M
 Skipped (dependency problems):
  libGLEW   i686   1.7.0-3.fc18 koji107 k
 
 Transaction Summary
 
 Upgrade1 Package
 Skipped (dependency problems)  1 Package
 
 Total size: 1.4 M
 Is this ok [y/N]: y
 Downloading Packages:
 Running Transaction Check
 Running Transaction Test
 
 
 Transaction Check Error:
   file /usr/share/man/man1/gpg-zip.1.gz from install of 
 gnupg2-2.0.19-3.fc18.i686 conflicts with file from package
 gnupg-1.4.12-2.fc18.i686
 
 Error Summary
 -
 
 
my apologies on the multilib settingthat's to be used, I think, when you 
have the same rpm's installed but for i686 and x86_64
(happens sometimes when running a 32 bit package on a 64 bit system).

Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

thunderbird 14 from rawhide won't install because thunderbird-enigmail needs tbird 14

[Kevin Martin]

I didn't see a thunderbird-enigmail package in koji...is anybody working on 
getting a thunderbird-enigmail package for tbird 14?


-- 

Regards,


Kevin Martin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

need firefox 14 to go with xulrunner 14 from rawhide (x86_64)...

[Kevin Martin]

firefox 13 installed won't run with xulrunner 14 from rawhide.When trying 
to run FF13 with xulrunner 14 I get:

Error: Platform version '14.0.1' is not compatible with
minVersion = 13.0.1
maxVersion = 13.0.1
) = 98

Can somebody please get a version of FF14 into rawhide repository so we can 
update to it?

BTW, FF14 from Mozilla download runs fine.

-- 

Regards,


Kevin Martin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: need firefox 14 to go with xulrunner 14 from rawhide (x86_64)...

[Kevin Martin]

On 07/18/2012 02:37 PM, Adam Williamson wrote:
 On Wed, 2012-07-18 at 14:14 -0500, Kevin Martin wrote:
 firefox 13 installed won't run with xulrunner 14 from rawhide.When 
 trying to run FF13 with xulrunner 14 I get:

 Error: Platform version '14.0.1' is not compatible with
 minVersion = 13.0.1
 maxVersion = 13.0.1
 ) = 98

 Can somebody please get a version of FF14 into rawhide repository so we can 
 update to it?
 
 xulrunner-14.0.1-3.fc18   stransky2012-07-17  13:49:26
 firefox-14.0.1-1.fc18 stransky2012-07-17  14:42:23
 
 Firefox was built less than an hour after xulrunner.
 


Hmm, strange.  This is what I get:

# yum --releasever=rawhide list firefox xulrunner
Loaded plugins: auto-update-debuginfo, changelog, langpacks, presto, 
protectbase, upgrade-helper
0 packages excluded due to repository protections
Installed Packages
firefox.x86_64 13.0.1-2.fc18
@fedora
xulrunner.x86_64   14.0.1-2.fc18
@rawhide
Available Packages
xulrunner.i686 14.0.1-2.fc18
rawhide

And here are my repos.  Am I missing a repo?

# yum --releasever=rawhide repolist
Loaded plugins: auto-update-debuginfo, changelog, langpacks, presto, 
protectbase, upgrade-helper
0 packages excluded due to repository protections
repo id   repo name 
  status
adobe-linux-i386  Adobe Systems Incorporated
  17
adobe-linux-x86_64Adobe Systems Incorporated
   2
fedoraFedora rawhide - x86_64   
  27,845
fedora-debuginfo  Fedora rawhide - x86_64 - Debug   
   6,079
fedora-source Fedora rawhide - Source   
   0
google-chrome google-chrome 
   3
google-earth  google-earth  
   1
google-talkplugin google-talkplugin 
   1
*rawhide  Fedora - Rawhide - Developmental 
packages for the next Fedora release   27,940
*rawhide-debuginfoFedora - Rawhide - Debug  
   6,086
rpmfusion-free-rawhideRPM Fusion for Fedora Rawhide - 
Free   445
rpmfusion-free-rawhide-debuginfo  RPM Fusion for Fedora Rawhide - 
Free - Debug   163
rpmfusion-free-rawhide-source RPM Fusion for Fedora Rawhide - 
Free - Source0
rpmfusion-nonfree-rawhide RPM Fusion for Fedora Rawhide - 
Nonfree204
rpmfusion-nonfree-rawhide-debuginfo   RPM Fusion for Fedora Rawhide - 
Nonfree - Debug 66
rpmfusion-nonfree-rawhide-source  RPM Fusion for Fedora Rawhide - 
Nonfree - Source 0
*updates  Fedora rawhide - x86_64 - Updates 
  27,940
updates-debuginfo Fedora rawhide - x86_64 - Updates 
- Debug6,086
*updates-source   Fedora rawhide - Updates Source   
   0
*updates-testing-source   Fedora rawhide - Test Updates 
Source 0

Thanks.

Kevin Martin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: need firefox 14 to go with xulrunner 14 from rawhide (x86_64)...

[Kevin Martin]

On 07/18/2012 02:44 PM, Kevin Martin wrote:
 On 07/18/2012 02:37 PM, Adam Williamson wrote:
 On Wed, 2012-07-18 at 14:14 -0500, Kevin Martin wrote:
 firefox 13 installed won't run with xulrunner 14 from rawhide.When 
 trying to run FF13 with xulrunner 14 I get:

 Error: Platform version '14.0.1' is not compatible with
 minVersion = 13.0.1
 maxVersion = 13.0.1
 ) = 98

 Can somebody please get a version of FF14 into rawhide repository so we can 
 update to it?

 xulrunner-14.0.1-3.fc18  stransky2012-07-17  13:49:26
 firefox-14.0.1-1.fc18stransky2012-07-17  14:42:23

 Firefox was built less than an hour after xulrunner.

 
 
 Hmm, strange.  This is what I get:
 
 # yum --releasever=rawhide list firefox xulrunner
 Loaded plugins: auto-update-debuginfo, changelog, langpacks, presto, 
 protectbase, upgrade-helper
 0 packages excluded due to repository protections
 Installed Packages
 firefox.x86_64 13.0.1-2.fc18  
   @fedora
 xulrunner.x86_64   14.0.1-2.fc18  
   @rawhide
 Available Packages
 xulrunner.i686 14.0.1-2.fc18  
   rawhide
 
 And here are my repos.  Am I missing a repo?
 
 # yum --releasever=rawhide repolist
 Loaded plugins: auto-update-debuginfo, changelog, langpacks, presto, 
 protectbase, upgrade-helper
 0 packages excluded due to repository protections
 repo id   repo name   
 status
 adobe-linux-i386  Adobe Systems Incorporated  
 17
 adobe-linux-x86_64Adobe Systems Incorporated  
  2
 fedoraFedora rawhide - x86_64 
 27,845
 fedora-debuginfo  Fedora rawhide - x86_64 - Debug 
  6,079
 fedora-source Fedora rawhide - Source 
  0
 google-chrome google-chrome   
  3
 google-earth  google-earth
  1
 google-talkplugin google-talkplugin   
  1
 *rawhide  Fedora - Rawhide - 
 Developmental packages for the next Fedora release   27,940
 *rawhide-debuginfoFedora - Rawhide - Debug
  6,086
 rpmfusion-free-rawhideRPM Fusion for Fedora Rawhide - 
 Free   445
 rpmfusion-free-rawhide-debuginfo  RPM Fusion for Fedora Rawhide - 
 Free - Debug   163
 rpmfusion-free-rawhide-source RPM Fusion for Fedora Rawhide - 
 Free - Source0
 rpmfusion-nonfree-rawhide RPM Fusion for Fedora Rawhide - 
 Nonfree204
 rpmfusion-nonfree-rawhide-debuginfo   RPM Fusion for Fedora Rawhide - 
 Nonfree - Debug 66
 rpmfusion-nonfree-rawhide-source  RPM Fusion for Fedora Rawhide - 
 Nonfree - Source 0
 *updates  Fedora rawhide - x86_64 - 
 Updates   27,940
 updates-debuginfo Fedora rawhide - x86_64 - 
 Updates - Debug6,086
 *updates-source   Fedora rawhide - Updates Source 
  0
 *updates-testing-source   Fedora rawhide - Test Updates 
 Source 0
 
 Thanks.
 
 Kevin Martin
 


yum clean all to the rescuesigh.

Thanks.

Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Beware of rebooting in rawhide right now

[Kevin Martin]

On 07/12/2012 02:53 AM, Zdenek Kabelac wrote:
 Dne 11.7.2012 22:18, Adam Williamson napsal(a):
 On Sun, 2012-07-08 at 13:37 -0700, Chuck Forsberg WA7KGX N2469R wrote:

 Before the next netinst is released perhaps the developers could be
 bothered to make sure it actually works.

 That's not how Rawhide works. The images in the Rawhide tree are
 automatically generated. There's no testing or release process. They
 just get built periodically. If they work, great. If they don't, no-one
 guaranteed that they would.

 
 
 Which is pretty bad plan...
 
 You want to have Rawhide being used by skilled people - to catch bugs early,
 not just a week before new Fedora release.
 
 But if the quality of Rawhide will go to the road of trashing people's hard 
 drives - skilled developers will leave Rawhide and will
 go for another distro.
 
 I just hope there is minority of Fedora people who believe this is the right 
 thing to do
 
 IMHO every package maintainer should seriously care about its package and 
 always test it himself FIRST and avoid releasing packages
 with obvious killer bugs.
 
 Zdenek
 
 
I tend to agree with Kabelac.  There has to be *some* testing that the 
developer is doing.  He/she can't just throw in a bunch of
new code and then let 'er rip, right?

Kevin

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: today's yum dependency issues for rawhide

[Kevin Martin]

On 07/11/2012 08:30 PM, Kevin Martin wrote:
 On 07/11/2012 04:49 PM, Bruno Wolff III wrote:
 On Wed, Jul 11, 2012 at 16:39:28 -0500,
   Kevin Martin ktm...@gmail.com wrote:

 Please explain why that makes any difference in this discussion.  I'm not 
 sure I see the relevance; vlc want's the 0 version, the
 others want the 1 version, so what?

 To get the .1 version the library needs to be updated, but that would remove 
 the .0 version which is required by vlc. Rather than
 remove vlc, the update is blocked. This also blocks the update of packages 
 to versions that require the .1 version.

 Some libraries to provide compatibility versions, but those are special 
 circumstances.
 Ah, I see now.  I assumed that what I was reading was that systemd-libs was 
 obsoleting *all* of the libudev libraries so I didn't
 see what it mattered that both the .0 and .1 versions were being obsoleted.  
 I'll try removing vlc and let you know.
 
 Thanks.
 
 Kevin
 
Annndd, you're correct.  Removed vlc and vlc-core and reran the update 
and the only dependency issues were for kernel
related debuginfo packages.  Thanks all.

Kevin

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: today's yum dependency issues for rawhide

[Kevin Martin]

On 07/11/2012 11:29 AM, Kalev Lember wrote:
 On 07/11/2012 06:12 PM, Kevin Martin wrote:
 -- Processing Dependency: libudev.so.0()(64bit) for package: 
 vlc-core-2.0.1-1.fc18.x86_64
 
 I believe this is holding back most of your updates.
 
 Is vlc-core a rpmfusion package? It should be rebuilt for libudev ABI
 change. File a bug with rpmfusion bugzilla (you can use
 https://bugzilla.redhat.com/show_bug.cgi?id=831987 as a template).
 
 Thanks, I'll start there!

Kevin

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: today's yum dependency issues for rawhide

[Kevin Martin]

On 07/11/2012 11:36 AM, Bruno Wolff III wrote:
 On Wed, Jul 11, 2012 at 10:12:31 -0500,
   Kevin Martin ktm...@gmail.com wrote:
 Two questions:

 1). How do I get rid of the dependency issues shown below?  Do I force the 
 update of systemd-libs or do the packages that are
 dependent on libudev need to be updated?
 
 I like to keep the latest versions of rawhide packages installed unless it 
 would require removing something really critical. The way
 I do a quick check for what is blocking updates is to run:
 yum update -y -v | grep -i fail
 Note that sometimes early failures cause later failures so that you really 
 don't need to remove every package listed. There can also
 be failures that don't show up when doing the above.
 
 My fallback plan is to remove the packages that won't update.
 
 I track all of the packages I remove and regularly try reinstalling them.

Bruno,

 Thanks for that information/suggestion.  I'll give that a try and see where I 
get.

Kevin

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: today's yum dependency issues for rawhide

[Kevin Martin]

On 07/11/2012 11:42 AM, Sandro Mani wrote:
 On Wed, Jul 11, 2012 at 6:36 PM, Bruno Wolff III br...@wolff.to wrote:
 On Wed, Jul 11, 2012 at 10:12:31 -0500,
   Kevin Martin ktm...@gmail.com wrote:

 Two questions:

 1). How do I get rid of the dependency issues shown below?  Do I force the
 update of systemd-libs or do the packages that are
 dependent on libudev need to be updated?


 I like to keep the latest versions of rawhide packages installed unless it
 would require removing something really critical. The way I do a quick check
 for what is blocking updates is to run:
 yum update -y -v | grep -i fail
 Note that sometimes early failures cause later failures so that you really
 don't need to remove every package listed. There can also be failures that
 don't show up when doing the above.

 My fallback plan is to remove the packages that won't update.

 I track all of the packages I remove and regularly try reinstalling them.
 --
 Why not just rebuild them in the meantime? I usually simply bump the
 version by one additional sub-version (i.e.
 vlc-core-2.0.1-1.fc18.x86_64 - vlc-core-2.0.1-1.1.fc18.x86_64),
 rebuild with mock, and that's it.
 
The funny thing is that while vlc is *one* of the packages that has libudev 
dependencies there are a whole bunch more non-rpmfusion
packages that have libudev dependencies as well:

-- Processing Dependency: libudev.so.1(LIBUDEV_183)(64bit) for package: 
6:kdelibs-4.8.95-2.fc18.x86_64
-- Processing Dependency: libudev.so.1(LIBUDEV_183)(64bit) for package: 
device-mapper-multipath-libs-0.4.9-27.fc18.x86_64
-- Processing Dependency: libudev.so.1(LIBUDEV_183)(64bit) for package: 
mesa-libgbm-8.1-0.8.fc18.x86_64
-- Processing Dependency: libudev.so.1(LIBUDEV_183)(64bit) for package: 
device-mapper-multipath-0.4.9-27.fc18.x86_64
-- Processing Dependency: libudev.so.1(LIBUDEV_183)(64bit) for package: 
lvm2-2.02.96-3.fc18.x86_64
-- Processing Dependency: libudev.so.1(LIBUDEV_183)(64bit) for package: 
systemd-186-2.fc18.x86_64
-- Processing Dependency: libudev.so.1(LIBUDEV_183)(64bit) for package: 
qt-mobility-1.2.2-0.2.20120224git.fc18.x86_64
-- Processing Dependency: libudev.so.1(LIBUDEV_183)(64bit) for package: 
gvfs-1.13.2-1.fc18.x86_64
-- Processing Dependency: libudev.so.1(LIBUDEV_183)(64bit) for package: 
util-linux-2.21.2-2.fc18.x86_64
-- Processing Dependency: libudev.so.1(LIBUDEV_183)(64bit) for package: 
device-mapper-libs-1.02.75-3.fc18.x86_64
-- Processing Dependency: libudev.so.1(LIBUDEV_183)(64bit) for package: 
udisks-1.0.4-7.fc18.x86_64
-- Processing Dependency: libudev.so.1(LIBUDEV_183)(64bit) for package: 
system-config-printer-udev-1.3.9-2.fc18.x86_64
-- Processing Dependency: libudev.so.1(LIBUDEV_183)(64bit) for package: 
mesa-libEGL-8.1-0.8.fc18.x86_64
-- Processing Dependency: libudev.so.1(LIBUDEV_183)(64bit) for package: 
1:xorg-x11-drv-nouveau-1.0.1-2.fc18.x86_64
-- Processing Dependency: libudev.so.1(LIBUDEV_183)(64bit) for package: 
libcanberra-0.29-3.fc18.x86_64
-- Processing Dependency: libudev.so.1(LIBUDEV_183)(64bit) for package: 
libatasmart-0.19-2.fc18.x86_64
-- Processing Dependency: libudev.so.1(LIBUDEV_183)(64bit) for package: 
xorg-x11-server-Xorg-1.12.3-1.fc18.x86_64
-- Processing Dependency: libudev.so.1(LIBUDEV_183)(64bit) for package: 
lvm2-libs-2.02.96-3.fc18.x86_64
-- Processing Dependency: libudev.so.1(LIBUDEV_183)(64bit) for package: 
pulseaudio-2.0-3.fc18.x86_64
-- Processing Dependency: libudev.so.1(LIBUDEV_183)(64bit) for package: 
libgudev1-186-2.fc18.x86_64
-- Processing Dependency: libudev.so.1()(64bit) for package: 
6:kdelibs-4.8.95-2.fc18.x86_64
-- Processing Dependency: libudev.so.1()(64bit) for package: 
device-mapper-multipath-libs-0.4.9-27.fc18.x86_64
-- Processing Dependency: libudev.so.1()(64bit) for package: 
mesa-libgbm-8.1-0.8.fc18.x86_64
-- Processing Dependency: libudev.so.1()(64bit) for package: 
device-mapper-multipath-0.4.9-27.fc18.x86_64
-- Processing Dependency: libudev.so.1()(64bit) for package: 
lvm2-2.02.96-3.fc18.x86_64
-- Processing Dependency: libudev.so.1()(64bit) for package: 
systemd-186-2.fc18.x86_64
-- Processing Dependency: libudev.so.1()(64bit) for package: 
qt-mobility-1.2.2-0.2.20120224git.fc18.x86_64
-- Processing Dependency: libudev.so.1()(64bit) for package: 
gvfs-1.13.2-1.fc18.x86_64
-- Processing Dependency: libudev.so.1()(64bit) for package: 
util-linux-2.21.2-2.fc18.x86_64
-- Processing Dependency: libudev.so.1()(64bit) for package: 
device-mapper-libs-1.02.75-3.fc18.x86_64
-- Processing Dependency: libudev.so.1()(64bit) for package: 
udisks-1.0.4-7.fc18.x86_64
-- Processing Dependency: libudev.so.1()(64bit) for package: 
system-config-printer-udev-1.3.9-2.fc18.x86_64
-- Processing Dependency: libudev.so.1()(64bit) for package: 
mesa-libEGL-8.1-0.8.fc18.x86_64
-- Processing Dependency: libudev.so.1()(64bit) for package: 
1:xorg-x11-drv-nouveau-1.0.1-2.fc18.x86_64
-- Processing Dependency: libudev.so.1()(64bit) for package: 
libcanberra-0.29-3.fc18.x86_64
-- Processing Dependency

Re: today's yum dependency issues for rawhide

[Kevin Martin]

On 07/11/2012 01:18 PM, Sandro Mani wrote:
 On Wed, Jul 11, 2012 at 6:59 PM, Kevin Martin ktm...@gmail.com wrote:
 On 07/11/2012 11:42 AM, Sandro Mani wrote:
 On Wed, Jul 11, 2012 at 6:36 PM, Bruno Wolff III br...@wolff.to wrote:
 On Wed, Jul 11, 2012 at 10:12:31 -0500,
   Kevin Martin ktm...@gmail.com wrote:

 Two questions:

 1). How do I get rid of the dependency issues shown below?  Do I force the
 update of systemd-libs or do the packages that are
 dependent on libudev need to be updated?


 I like to keep the latest versions of rawhide packages installed unless it
 would require removing something really critical. The way I do a quick 
 check
 for what is blocking updates is to run:
 yum update -y -v | grep -i fail
 Note that sometimes early failures cause later failures so that you really
 don't need to remove every package listed. There can also be failures that
 don't show up when doing the above.

 My fallback plan is to remove the packages that won't update.

 I track all of the packages I remove and regularly try reinstalling them.
 --
 Why not just rebuild them in the meantime? I usually simply bump the
 version by one additional sub-version (i.e.
 vlc-core-2.0.1-1.fc18.x86_64 - vlc-core-2.0.1-1.1.fc18.x86_64),
 rebuild with mock, and that's it.

 The funny thing is that while vlc is *one* of the packages that has libudev 
 dependencies there are a whole bunch more non-rpmfusion
 packages that have libudev dependencies as well:

 [...]
 Yeah, but vlc wants libudev.so.0()(64bit), the other ones 
 libudev.so.1()(64bit).
 
Please explain why that makes any difference in this discussion.  I'm not sure 
I see the relevance; vlc want's the 0 version, the
others want the 1 version, so what?

Kevin

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: today's yum dependency issues for rawhide

[Kevin Martin]

On 07/11/2012 04:49 PM, Bruno Wolff III wrote:
 On Wed, Jul 11, 2012 at 16:39:28 -0500,
   Kevin Martin ktm...@gmail.com wrote:

 Please explain why that makes any difference in this discussion.  I'm not 
 sure I see the relevance; vlc want's the 0 version, the
 others want the 1 version, so what?
 
 To get the .1 version the library needs to be updated, but that would remove 
 the .0 version which is required by vlc. Rather than
 remove vlc, the update is blocked. This also blocks the update of packages to 
 versions that require the .1 version.
 
 Some libraries to provide compatibility versions, but those are special 
 circumstances.
Ah, I see now.  I assumed that what I was reading was that systemd-libs was 
obsoleting *all* of the libudev libraries so I didn't
see what it mattered that both the .0 and .1 versions were being obsoleted.  
I'll try removing vlc and let you know.

Thanks.

Kevin

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

todays yum update issues for rawhide...

[Kevin Martin]

 will be an update
--- Package stix-fonts.noarch 0:1.0.0-3.fc17 will be updated
--- Package stix-fonts.noarch 0:1.1.0-1.fc18 will be an update
--- Package xorg-x11-server-common.x86_64 0:1.12.2-4.fc18 will be updated
--- Package xorg-x11-server-common.x86_64 0:1.12.3-1.fc18 will be an update
-- Finished Dependency Resolution

Packages skipped because of dependency problems:
dracut-020-55.git20120709.fc18.x86_64 from rawhide
systemd-186-1.fc18.x86_64 from fedora
systemd-analyze-186-1.fc18.x86_64 from fedora
systemd-libs-186-1.fc18.i686 from fedora
systemd-libs-186-1.fc18.x86_64 from fedora
systemd-sysv-186-1.fc18.x86_64 from fedora
xorg-x11-server-Xorg-1.12.3-1.fc18.x86_64 from rawhide

Dependencies Resolved


 Package   Arch  Version
 RepositorySize

Updating:
 digikam   x86_642.7.0-1.fc18   
 rawhide  9.8 M
 digikam-doc   noarch2.7.0-1.fc18   
 rawhide   17 M
 digikam-libs  x86_642.7.0-1.fc18   
 rawhide  2.3 M
 google-chrome-unstablex86_6422.0.1201.0-145644 
 google-chrome 43 M
 iok   x86_642.1.3-1.fc18   
 rawhide  113 k
 kernel-debug-debuginfox86_64
3.5.0-0.rc6.git0.2.fc18 rawhide-debuginfo252 M
 kernel-debuginfo  x86_64
3.5.0-0.rc6.git0.2.fc18 rawhide-debuginfo246 M
 kernel-debuginfo-common-x86_64x86_64
3.5.0-0.rc6.git0.2.fc18 rawhide-debuginfo 40 M
 kernel-tools-debuginfox86_64
3.5.0-0.rc6.git0.2.fc18 rawhide-debuginfo119 k
 libbsdx86_640.4.2-1.fc18   
 rawhide   55 k
 libkface  x86_642.7.0-1.fc18   
 rawhide  1.2 M
 libkgeomapx86_642.7.0-1.fc18   
 rawhide  173 k
 stix-fontsnoarch1.1.0-1.fc18   
 rawhide  1.3 M
 xorg-x11-server-commonx86_641.12.3-1.fc18  
 rawhide   36 k
Skipped (dependency problems):
 dracutx86_64
020-55.git20120709.fc18 rawhide  212 k
 systemd   x86_64186-1.fc18 
 fedora   1.3 M
 systemd-analyze   x86_64186-1.fc18 
 fedora18 k
 systemd-libs  i686  186-1.fc18 
 fedora   108 k
 systemd-libs  x86_64186-1.fc18 
 fedora   102 k
 systemd-sysv  x86_64186-1.fc18 
 fedora17 k
 xorg-x11-server-Xorg  x86_641.12.3-1.fc18  
 rawhide  1.3 M

-- 

Regards,


Kevin Martin
NetFuel, Inc.
mailto: kev...@netfuel.com
mailto: tech-supp...@netfuel.com
U.S.). 312.698.9879
U.K.) 208.150.3609
U.S. Alternate). 847.231.3589
FAX) 866.654.3341

For access to our Software and Documentation
please login or register for access at:

http://www.netfuel.com


-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test