Re: help
On 01/08/2010 12:04 PM, Alan Cox wrote: On Thu, 7 Jan 2010 23:40:16 + Joseph L. Casale jcas...@activenetwerx.com wrote: we at work have some PC's with 256 MB RAM, the graphical mode doesn't load, so we choice the text mode, but in all machines we get the same error, Anaconda 12.47 do you have an idea how to solve it? Yeah, add ram. Anaconda needs like 1/2 gig, and nevermind trying to Fedora w/ 1/2gig as well... Text mode install for a minimal system, then installgroup xfce and claws and a few other apps instead of evolution and gnome. That's a reasonably quick way to debloat Fedora and actually get work done. Useful on bigger boxes too as the desktop is much snappier and starts far faster. That's a really i.nteresting and useful piece of advice that I haven't heard before. Thanks a lot, and this needs to be written up on a wall somewhere. Andrew. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: RFE: Never, ever steal focus.
On 01/06/2010 06:50 PM, Matthew Garrett wrote: On Wed, Jan 06, 2010 at 01:27:07PM -0500, Fulko Hew wrote: I'd say... only take focus if its a child/creation of the window currently in focus. You don't want ssh passphrase windows to take focus? Hell, no! :-) Andrew. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12 Rkhunter, Have I a rootkit?
On 01/05/2010 10:54 AM, Frank Murphy (Frankly3D) wrote: -- Start Rootkit Hunter Scan -- Warning: Network TCP port 47107 is being used by /usr/lib64/thunderbird-3.0/thunderbird-bin. Possible rootkit: T0rn Use the 'lsof -i' or 'netstat -an' command to check this. Results of lsof -i' and 'netstat -an' http://fpaste.org/xOOO/ Port 47107 isn't being used any more. This was just TCP using a random unreserved port. Andrew. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: F12 Rkhunter, Have I a rootkit?
On 01/05/2010 11:18 AM, Frank Murphy (Frankly3D) wrote: On 05/01/10 11:06, Andrew Haley wrote: On 01/05/2010 10:54 AM, Frank Murphy (Frankly3D) wrote: -- Start Rootkit Hunter Scan -- Warning: Network TCP port 47107 is being used by /usr/lib64/thunderbird-3.0/thunderbird-bin. Possible rootkit: T0rn Use the 'lsof -i' or 'netstat -an' command to check this. Results of lsof -i' and 'netstat -an' http://fpaste.org/xOOO/ Port 47107 isn't being used any more. This was just TCP using a random unreserved port. Basically ignore this in future, with that port? I'm not going to tell you that. All I'm saying is that simply using Port 47107 isn't conclusive evidence of a rootkit. Andrew. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: The Counter-Fedora People At #fedora
On 12/31/2009 04:48 AM, Randy Yates wrote: Why do the following people, time after time, insist on banning me for asking fedora questions on #fedora? VileGent Khaytsus (or however you speel his name) [R] They are absolute pricks. If the Fedora community wants to improve their position with the public, I suggest that they start monitoring #fedora for the utterly vehement, venomous, vicious attitudes these regulars have there and do a little pruning of operator priviledges. That seems reasonable, but you haven't provided us with any specifics. Andrew. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: SELinux denial - F12
On 12/27/2009 07:20 AM, Kurian Thayil wrote:
Hi,
Installed F12 and did a security update. Now, I get SELinux denial error.
SELinux currently in permissive mode.
Summary:
SELinux is preventing access to files with the label, file_t.
Detailed Description:
SELinux permission checks on files labeled file_t are being denied. file_t is
the context the SELinux kernel gives to files that do not have a label. This
indicates a serious labeling problem. No files on an SELinux box should ever
be
labeled file_t. If you have just added a new disk drive to the system you can
relabel it using the restorecon command. Otherwise you should relabel the
entire
file system.
Allowing Access:
You can execute the following command as root to relabel your computer system:
touch /.autorelabel; reboot
Additional Information:
Source Contextsystem_u:system_r:xdm_t:s0-s0:c0.c1023
Target Contextsystem_u:object_r:file_t:s0
Target Objects/home [ dir ]
Sourcegdm-simple-gree
Source Path /usr/libexec/gdm-simple-greeter
Port Unknown
Host home-desktop
Source RPM Packages gdm-2.28.1-24.fc12
Target RPM Packages filesystem-2.4.30-2.fc12
Policy RPMselinux-policy-3.6.32-41.fc12
Selinux Enabled True
Policy Type targeted
MLS Enabled True
Enforcing ModeEnforcing
Plugin Name file
Host Name home-desktop
Platform Linux home-desktop 2.6.31.5-127.fc12.i686.PAE #1
SMP Sat Nov 7 21:25:57 EST 2009 i686 i686
Alert Count 1
First SeenThu 24 Dec 2009 02:30:08 AM IST
Last Seen Thu 24 Dec 2009 02:30:08 AM IST
Local ID 6b1ff85c-05fe-4d37-945b-6cd2d54b92fa
Line Numbers
Raw Audit Messages
node=home-desktop type=AVC msg=audit(1261602008.595:11510): avc: denied {
search } for pid=1357 comm=gdm-simple-gree name=/ dev=sda2 ino=2
scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
tcontext=system_u:object_r:file_t:s0 tclass=dir
node=home-desktop type=SYSCALL msg=audit(1261602008.595:11510): arch=4003
syscall=292 success=no exit=-13 a0=12 a1=8d6f400 a2=1002fce a3=8d6ec48
items=0
ppid=1325 pid=1357 auid=4294967295 uid=42 gid=473 euid=42 suid=42 fsuid=42
egid=473 sgid=473 fsgid=473 tty=(none) ses=4294967295 comm=gdm-simple-gree
exe=/usr/libexec/gdm-simple-greeter subj=system_u:system_r:xdm_t:s0-
s0:c0.c1023 key=(null)
Any idea why this happened after the update? What could be done to prevent
this. I am quite a newbie in SELinux scenario. Does, restorecon command fix
(restorecon /usr/libexec/gdm-simple-greeter)?
Files in your homedir are mis-labelled. The easiest way to fix it is to
You can execute the following command as root to relabel your computer system:
touch /.autorelabel; reboot
Andrew.
--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Raid I/O error
On 12/26/2009 08:20 PM, Allan R. Batteiger wrote: I have a sever with a Raid controller, 4 drives setup as Raid 5. Every night I an getting a report showing a lot ( 200-1000) of I/O errors on DM-0. I have also starting getting reports of I/O errors on files. However I do not seem to be able to get any info on what is causing these issues. I thought if a drive was causing the problems, the raid array would be correcting for them. I would have expecting a warning saying I had a drive going bad but not un recoverable errors. The Hardware config is Tyan GX28 with a LSI Megaraid 1430G controller 4X 500 GB SATA drives. I have been doing online searches but so far not much luck. Does any one have any ideas ? Doesn't the Megaraid BIOS console tell you? Andrew. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: How many people need to use the proprietary nvidia driver ? (Or other non kms driver ?)
On 12/23/2009 09:53 AM, Andrew Haley wrote: On 12/23/2009 04:21 AM, Linuxguy123 wrote: Please reply if you need to ( ie must) use the proprietary nvidia driver instead of the nouveau driver. Or some other video driver that doesn't support kernel mode switching. DON'T reply otherwise, I don't want to hear a debate on the free versions versus proprietary or anything else. I'm still using the proprietary driver because I need full dual-link DVI support at 2560x1600 resolution. I haven't found a free driver that can do that. Actually, I withdraw that comment. I just installed F12 with all the updates and I don't need the proprietary nvidia driver. Big congrats to the developers: one more piece of unfree software I no longer need. Andrew. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: How many people need to use the proprietary nvidia driver ? (Or other non kms driver ?)
On 12/23/2009 04:21 AM, Linuxguy123 wrote: Please reply if you need to ( ie must) use the proprietary nvidia driver instead of the nouveau driver. Or some other video driver that doesn't support kernel mode switching. DON'T reply otherwise, I don't want to hear a debate on the free versions versus proprietary or anything else. I'm still using the proprietary driver because I need full dual-link DVI support at 2560x1600 resolution. I haven't found a free driver that can do that. Andrew. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Can't rebuild emacs RPM in F12
I have installed emacs-23.1-10.fc12.src.rpm Then, when I run $ rpmbuild -ba emacs.spec I get ... + /usr/bin/make bootstrap (cd src; /usr/bin/make bootstrap-clean) make[1]: Entering directory `/home/aph/rpmbuild/BUILD/emacs-23.1/src' Makefile:103: *** commands commence before first target. Stop. make[1]: Leaving directory `/home/aph/rpmbuild/BUILD/emacs-23.1/src' I can't understand this at all. I tried it on two F12 installations. Surely someone must have built emacs? This is x86_64, BTW. Andrew. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Can't rebuild emacs RPM in F12
On 12/23/2009 12:21 AM, Karel Klic wrote: Andrew, this problem is already fixed in the latest version; please see https://bugzilla.redhat.com/show_bug.cgi?id=540921 OK, ta. Andrew. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Tar oddity...
DB wrote: On 12/21/2009 12:45 AM, Roberto Ragusa wrote: DB wrote: The reason I went with tar tvh was (to try) to check the contents of the file after open with ark in Dollphin spat out the errors. I guess that actually trying to extract the files when the table of contents fails would not be any more successful? Run md5sum F11_Home_Dave_20091217.tar.gz on both machines. If you get two different results, something bad is happening. Ah that gives 2 entirely different 32-digit numbers on the F11 desktop cee716a79cc7af0ee8f5f2613ca50578 and on the F12 laptop 802d5ea893af6f936e77b81cf00a45fb Rusult of uname -ar on each: Desktop Linux Fedora-Blue 2.6.30.9-102.fc11.i586 #1 SMP Thu Dec 3 23:46:37 EST 2009 i686 athlon i386 GNU/Linux Laptop Linux Fedora_Toshi 2.6.31.6-166.fc12.i686 #1 SMP Wed Dec 9 11:14:59 EST 2009 i686 i686 i386 GNU/Linux Thanks for the suggestion Roberto. where to next? Copy the file back. See if it changes. Find out where the difference is with cmp. Andrew. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Slowness with ssh in F12 !!!
Luc MAIGNAN wrote: Hi, I have a big problem on a production server. I use a ssh connection with a nagios server to monitor external servers. In f11 there was no problem. But if F12, a ssh connection takes a lot of time. For example : time ssh x 'ls' id_rsa.pub real0m35.633s user0m0.013s sys0m0.003s Does anyone know why the ssh connection is so slow regard to F11 ? ANy help would be appreciated There must be some retrying going on. try ssh -v Andrew. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: linux as router
Adel ESSAFI wrote: Hi list This is the first time I have to configure linux as router. I have a single network card for which I gave to IPs eth0 Link encap:Ethernet HWaddr 00:11:5B:72:7F:D9 inet addr:41.231.X.Y Bcast:41.255.255.255 Mask:255.255.255.0 inet6 addr: fe80::211:5bff:fe72:7fd9/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2595 errors:0 dropped:0 overruns:0 frame:0 TX packets:2295 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1876353 (1.7 MiB) TX bytes:328059 (320.3 KiB) Interrupt:21 Base address:0x8000 eth0:1Link encap:Ethernet HWaddr 00:11:5B:72:7F:D9 inet addr:192.168.10.10 Bcast:192.168.10.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Interrupt:21 Base address:0x8000 and this is the default route [r...@routeur ~]# route Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 41.231.2.0 * 255.255.255.0 U 0 00 eth0 192.168.10.0* 255.255.255.0 U 0 00 eth0 link-local * 255.255.0.0 U 1002 00 eth0 default 41.231.2.81 0.0.0.0 UG0 00 eth0 That looks alright. The problem now, is when I configure a PC with an IP adress 192.168.10.X and I put the gateway as 192.168.10.10, I do not succeed to ping any PC. How can I route all the packages from eth0:1 to eth0?? This isn't making very much sense. What is the address of your gateway? If it is 41.231.2.81, then it makes no sense to move it to the 192.168.10 network. If you're trying to set up a local network with NAT forwarding, then there's more to do. Andrew. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Question about Backing up with tar
kevin wrote: I would like to know if this will work with fc9: # sudo su # cd / # tar cvpzf backup.tgz --exclude=/proc --exclude=/lost+found --exclude=/backup.tgz --exclude=/mnt --exclude=/sys / What I really want to know is this. I have two systems that are identical and would like to just copy one to the other and keep all permissions for each of the files and folders copied. Is this feasible or could someone point me to the right direction with some kind of tutorial? tar isn't going to do it: tar can't cope with files that have holes, for one thing. You have to be careful with mount points too. Something like this will work: umount the file systems mkfs the new filesystem. mount it dump 0f - /dev/filesystem | ssh foobar -c 'cd /restorepoint restore rf -' Andrew. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Assistance finding out what process is writing to the disk drive
Michael Cronenworth wrote: John Nissley wrote: I do not know what is causing the disk drive light to stay on now. # yum install blktrace $ man blktrace # btrace /dev/sda Invalid debug path /sys/kernel/debug: 0/Success Mmm, does this work for anyone else? Andrew. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Promoting i386 version over x86_64?
Mike A. Harris wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 King InuYasha wrote: Except, that could be false advertising. In most cases, where CPU computation is not used heavily, 64-bit is actually SLOWER than the 32-bit counterpart. Optimizations are narrowing the gap, but it still remains true. On ppc versus PPC64, sparc vs. sparc64, and possibly other architectures that may be true, however on x86 vs. x86_64 arch as a whole it is not generally the case, in particular because the x86_64 arch has double the number of available registers for gcc to play with. Also, x86_64 has a much better ABI: args get passed in registers, not on the stack. What applications are you aware of which run slower on x86_64 than on x86 on the same system? There used to be Java slowdowns, but this was fixed with the compressed OOPs option. Andrew. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
Kevin Kofler wrote: The absence of a GUI policy editor combined with lack of documentation for the config files makes bad defaults a big issue. This is a key issue. Do I take it that I have to edit the XML files directly to require authentication for package installs? So far I have: $ pkaction -v --action-id org.freedesktop.packagekit.package-install org.freedesktop.packagekit.package-install: description: Install signed package message: Authentication is required to install a signed package vendor:The PackageKit Project vendor_url:http://www.packagekit.org/ icon: package-x-generic implicit any: no implicit inactive: no implicit active: yes I'm not sure what to change here. I'm guessing that I should change implicit active: yes to implicit active: auth_admin. And that I should do this in /usr/share/polkit-1/actions/org.freedesktop.packagekit.policy Andrew. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
Seth Vidal wrote: On Wed, 18 Nov 2009, nodata wrote: -sv I do if it's in the default DVD install, or was pulled in in an upgrade. I've never intentionally installed it, and yes I do. Never imagined it would be a problem. I'll remove it. Maybe you and I have a different concept of 'Servers'. But I tend to install @core only and then remove items whenever I can for a server. If it is a bad day I'll install X b/c something requires it but for servers I try to avoid anything beside the barest minimal I can have. Maybe you have a different concept of security, but I don't want any user on the server installing software, no matter what. right - which is why I wouldn't install PK on a server. yum doesn't allow users to install pkgs, only root. $ sudo rpm -e PackageKit error: Failed dependencies: ... PackageKit is needed by (installed) setroubleshoot-2.2.42-1.fc12.x86_64 Ouch. I like setroubleshoot. Is there some way to disable PackageKit but keep setroubleshoot? Andrew. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: nuxeo ECM, and where is Context.compressReader() in openJDK?
Robert P. J. Day wrote: let me see how succinct i can make this. i'm writing a doc on how to install and build the open source nuxeo ECM software on fedora using openJDK-1.6.0: http://www.crashcourse.ca/wiki/index.php/Nuxeo_on_Fedora nothing deep about simply downloading and installing the zip file, that works fine. however, trying to build the mercurial checkout fails, as you can read further down that page. as i read it (and i could be wrong), the failure is the result of trying to call the java method Context.compressReader(), which i don't see exists anymore -- it's entirely missing from this page: http://www.mozilla.org/rhino/apidocs/org/mozilla/javascript/Context.html and that certainly seems to be the problem based on the build error message, no? I think it was a nonstandard extension to Rhino to read compressed javascript. someone from nuxeo just pointed out that they don't guarantee a successful build under openJDK, only under *sun's* java. so does that mean sun's java *would* have that class method? or am i misinterpreting this? just for the entertainment value, it would be nice to finish that build with openJDK. does anyone here know what the story is for Context.compressReader()? am i reading correctly that it simply doesn't exist in openJDK? Yes. All you need to do is replace the call to Context.compressReader() with a dynamic lookup. There's an example at http://fisheye5.cenqua.com/browse/dwr/java/org/directwebremoting/impl/ShrinkSafeCompressor.java?r1=1.1r2=1.2u=-1ignore=k=o which shows exactly how to use Context.class.getMethod(compressReader, and compressReaderMethod.invoke Andrew. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: nuxeo ECM, and where is Context.compressReader() in openJDK?
Robert P. J. Day wrote: On Fri, 13 Nov 2009, Andrew Haley wrote: I think it was a nonstandard extension to Rhino to read compressed javascript. so sun's java is using that non-standard extension while openjdk isn't? so what's the story in terms of adherence to formal java standards? Rhino is javascript, not java. It's not part of the Java API. i'm not a java guru, but this tells me that openjdk adheres to the standard (whatever that is) more strictly than sun. is that the conclusion i should be drawing here? No. Rhino is not part of Java: it is present in openjdk, but it isn't strictly part of Java. We need it for LiveConnect. someone from nuxeo just pointed out that they don't guarantee a successful build under openJDK, only under *sun's* java. so does that mean sun's java *would* have that class method? or am i misinterpreting this? just for the entertainment value, it would be nice to finish that build with openJDK. does anyone here know what the story is for Context.compressReader()? am i reading correctly that it simply doesn't exist in openJDK? Yes. All you need to do is replace the call to Context.compressReader() with a dynamic lookup. There's an example at http://fisheye5.cenqua.com/browse/dwr/java/org/directwebremoting/impl/ShrinkSafeCompressor.java?r1=1.1r2=1.2u=-1ignore=k=o which shows exactly how to use Context.class.getMethod(compressReader, and compressReaderMethod.invoke yes, i'd already found that page and realized what was happening there. all i really want to confirm is that the code above that's failing is failing because it's badly-behaved and calling a non-standard extension that will cause it to break under openjdk. That's right. I wouldn't call it badly behaved, but it is depending on a nonstandard extension to Rhino. Andrew. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Old Dual Pentium III 500Mhz Servers
Frode Petersen wrote: I wonder how one could profile an entire OS to find out where the cycles go? Is it feasible? Definitely: OProfile is your friend. I do it all the time. Andrew. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Buyer Beware: A Major Change in NFS (in Rawhide) is about to happen
Ewan Mac Mahon wrote: On Mon, Oct 26, 2009 at 02:06:45PM -0400, Steve Dickson wrote: On 10/26/2009 01:34 PM, Frank Ch. Eigler wrote: Steve Dickson ste...@redhat.com writes: On 10/26/2009 12:06 PM, Frank Ch. Eigler wrote: Unfortunately, this sounds like only. Is it out of the question to make the client look for this case (an upgraded client in an existing unupgraded, unchanged network) and handle it? We talked about it... See http://linux-nfs.org/pipermail/nfsv4/2009-October/011471.html But in the end, I decided not to do this since its not clear how the change would interact with other NFS servers... It's not clear to me how falling back to NFSv3 if v4 fails (and the version wasn't explicitly set to v4) could ever cause a problem - it might not help, but under what circumstances could it possibly be harmful? I had a look at the linked thread from linux-nfs and no-one there seemed to come up with anything concrete. The strongest objection I found was Older versions of ONTAP (like 6.0 through 6.2?), for example, have the same problem as the Linux NFSv4 server does currently, iirc. It's also worth noting that modern Solaris clients do not have this ENOENT workaround. So, if automounter maps are shared with Linux clients _with_ the workaround, mounting a Linux NFSv4 server, there may be some issues. In the long term, I think we are much better off living with a few months of complaints about the new version negotiation behavior, rather than having this mount.nfs workaround. I'm not going to object to it outright, though... (chuck[dot]lever[at]oracle[dot]com) I'm not going to object outright sounds to me like we can fall back to V3. I think this is the best plan for us: we should not break things for users of Fedora clients with RHEL servers or Fedora clients with Fedora servers. Further, On Oct 22, 2009, at 10:04 AM, Steve Dickson wrote: On 10/22/2009 12:21 PM, Chuck Lever wrote: This would be mitigated instantly by leaving the version negotiation default set to v3/v2. Then no workaround would be needed. Right... Or defining the negotiation in the configuration file would also cause the workaround not to be needed... That's what I meant: set defaultvers: 3 in the config file, and allow early adopters to change it. After a while, we can bump the default setting. I think this is roughly what Sun did during their transition. (chuck[dot]lever[at]oracle[dot]com) Leaving the default at Version 3 for the next year or two would mostly solve the problem. Andrew. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Buyer Beware: A Major Change in NFS is about to happen
Steve Dickson wrote: On 09/29/2009 10:10 PM, Jeremy Katz wrote: On Tue, Sep 29, 2009 at 8:15 PM, Steve Dickson ste...@redhat.com wrote: My main concern is with installer, installing from NFS shares from older servers, say RHEL5. How will anaconda handle mounting? Will there be odd errors that are difficult to figure out? Has this been tested in the anaconda environment at all? This issue is this... when the the F12 does a mount to a linux server and that linux server is *not* configured with a / *(ro,fsid=0) export, the mount will fail with ENOENT (or No such file or directory). If the server does have that export, things will work as expected... So my advice is to added that one line to your rhel5 server and every thing should as expected... or may even better... ;-) Another workaround is to added the '-o v3' mount options... would that be hard? Why not just see the error and fall back and try v3 programatically rather than forcing that upon unsuspecting users? If someone explicitly specifies v4, then sure, if that fails, it should fail. But if they don't, we should be forgiving in what we do rather than giving cryptic error messages. I looked into this... Having the kernel give a different kind of error when the V4 beginning mount routine failed did not look feasible so figure it would be impossible to get through upstream I don't really understand this reason. When you get a mount fail, why not try v3? It doesn't matter whether the kernel gives a different kind of error or not. Andrew. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Buyer Beware: A Major Change in NFS is about to happen
Steve Dickson wrote: On 09/30/2009 04:53 AM, Andrew Haley wrote: Steve Dickson wrote: On 09/29/2009 10:10 PM, Jeremy Katz wrote: On Tue, Sep 29, 2009 at 8:15 PM, Steve Dickson ste...@redhat.com wrote: My main concern is with installer, installing from NFS shares from older servers, say RHEL5. How will anaconda handle mounting? Will there be odd errors that are difficult to figure out? Has this been tested in the anaconda environment at all? This issue is this... when the the F12 does a mount to a linux server and that linux server is *not* configured with a / *(ro,fsid=0) export, the mount will fail with ENOENT (or No such file or directory). If the server does have that export, things will work as expected... So my advice is to added that one line to your rhel5 server and every thing should as expected... or may even better... ;-) Another workaround is to added the '-o v3' mount options... would that be hard? Why not just see the error and fall back and try v3 programatically rather than forcing that upon unsuspecting users? If someone explicitly specifies v4, then sure, if that fails, it should fail. But if they don't, we should be forgiving in what we do rather than giving cryptic error messages. I looked into this... Having the kernel give a different kind of error when the V4 beginning mount routine failed did not look feasible so figure it would be impossible to get through upstream I don't really understand this reason. When you get a mount fail, why not try v3? It doesn't matter whether the kernel gives a different kind of error or not. The error that is returned is ENOENT which is fatal error because it means the remote directory does not exist... and I'm not sure it would be good to continue flood the network with mounts requests (I'm thinking about autofs mount storms) for directories that may or may not be there... I can't see how it would cause a mount storm: all you'd be doing is issuing a mount request twice, once in each protocol. Consider the alternative, which is breaking NFS access for enormous numbers (hundreds of thousands?) of people. And, in the process, severely damaging the reputation of Fedora. Andrew. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Buyer Beware: A Major Change in NFS is about to happen
Steve Dickson wrote: On 09/30/2009 06:18 AM, Andrew Haley wrote: Steve Dickson wrote: On 09/30/2009 04:53 AM, Andrew Haley wrote: Steve Dickson wrote: On 09/29/2009 10:10 PM, Jeremy Katz wrote: On Tue, Sep 29, 2009 at 8:15 PM, Steve Dickson ste...@redhat.com wrote: My main concern is with installer, installing from NFS shares from older servers, say RHEL5. How will anaconda handle mounting? Will there be odd errors that are difficult to figure out? Has this been tested in the anaconda environment at all? This issue is this... when the the F12 does a mount to a linux server and that linux server is *not* configured with a / *(ro,fsid=0) export, the mount will fail with ENOENT (or No such file or directory). If the server does have that export, things will work as expected... So my advice is to added that one line to your rhel5 server and every thing should as expected... or may even better... ;-) Another workaround is to added the '-o v3' mount options... would that be hard? Why not just see the error and fall back and try v3 programatically rather than forcing that upon unsuspecting users? If someone explicitly specifies v4, then sure, if that fails, it should fail. But if they don't, we should be forgiving in what we do rather than giving cryptic error messages. I looked into this... Having the kernel give a different kind of error when the V4 beginning mount routine failed did not look feasible so figure it would be impossible to get through upstream I don't really understand this reason. When you get a mount fail, why not try v3? It doesn't matter whether the kernel gives a different kind of error or not. The error that is returned is ENOENT which is fatal error because it means the remote directory does not exist... and I'm not sure it would be good to continue flood the network with mounts requests (I'm thinking about autofs mount storms) for directories that may or may not be there... I can't see how it would cause a mount storm: all you'd be doing is issuing a mount request twice, once in each protocol. Times 1000 very 5 seconds... So 2000 every 5 seconds as opposed to 1000 every 5 seconds. This is surely better than returning an incorrect directory does not exist response to almost every NFS user who upgrades. And it will be almost everyone: maintaining servers on older versions of RHEL and upgrading clients to recent Fedora is normal. I really don't think the server people would appreciate all those extra cycles and network traffic... Doing something like this would be hack... a hack that I could not push upstream... There are other workagrounds (defined in original mail) that I would rather explore... But they are all pretty unpleasant. The user gets an obscure error message that indicates nothing to them except NFS is broken. They then have to either export root from the server or edit their fstab. Consider the alternative, which is breaking NFS access for enormous numbers (hundreds of thousands?) of people. And, in the process, severely damaging the reputation of Fedora. I am not breaking NFS access, I'm changing NFS access for the better, IMHO. Unfortunately its just a bit painful Yep. I don't see how pushing, incorporating and utilizing the latest technology available can severely damaging the reputation of Fedora. Really? Why not? What you are proposing to is indistinguishable to a user from breaking NFS. I can easily see it. To be quite frank, my goal is just the opposite... I want Fedora have a reputation of being on the breaking edge of technology... I think that is a good thing! Me too. So, let's see how we can do that without making Fedora more fragile. Andrew. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12 to require i686, but which CPUs do not qualify?
Deji Akingunola wrote: On Fri, Aug 14, 2009 at 10:04 AM, Joachimjoachim.frie...@googlemail.com wrote: I think there's a valid case for making an exception to this: when a package is an accelerated version of a particular library. That is, when the basic functionality of a library is available in a i686 Fedora package, but a special SSEx version of the library makes use of faster instructions. Right now, there exist a number of packages which explicitly pull in atlas instead of the also available generic packages blas/lapack which do not exhibit these severe restrictions. Earlier versions of the Fedora atlas package actually supported a wider range of processors including even such offering 3dnow! and also plain x86. The current behaviour (code depending on lapack aborts because of illegal instructions) is a regression which has been introduced by the packager. Correction: The current behaviour was not introduced by the packager, it is because of changes in the upstream's design of the package; Yes, we know that it's an upstream change. I was wondering if there were some way to configure things so that the library only gets used when it would work. unless of course you mean we should be stuck with the old version. The only way to produce atlas binary for architectures not provided for in the upstream tarball, is to bootstrap it on that particular arch. Unfortunately none of Fedora build infrastructure is based on PII or less. I don't quite understand this. Why would we need to bootstrap *on* the old arch to compile it *for* the old arch? Some configury weirdness, presumably. That sounds fixable. Would it be OK if I did a little digging to see if I could fix it? Andrew. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12 to require i686, but which CPUs do not qualify?
Kevin Kofler wrote: Joachim wrote: I do not understand then, that there exist i686 packages which have higher requirements. Those packages need to be fixed. I know there are some audio production packages which are building with SSE enabled (and required, those packages don't do runtime detection), IIRC in both Fedora and RPM Fusion, in blatant violation of the guidelines, and the packager(s) refuse(s) to fix this (they even do it intentionally for new packages, despite my objections in the reviews). If I'm not mistaken, most of the offenders are owned by oget (Orcan Ogetbil), but if I were you, I'd check all the audio production packages. Look at the ATLAS library for which I had filed a bug because only SSE/SSE2/SSE3 variants are provided This one needs to get fixed too, of course. I've looked at how Debian is handling this, but they're stuck at an old version (3.6.0), maybe exactly because of this issue. :-( We need to provide architectural defaults for plain i686, even crappy ones, they just need to work at all. I think there's a valid case for making an exception to this: when a package is an accelerated version of a particular library. That is, when the basic functionality of a library is available in a i686 Fedora package, but a special SSEx version of the library makes use of faster instructions. Andrew. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12 to require i686, but which CPUs do not qualify?
Joachim wrote: Quoting Bill Nottingham: Given the loud feedback, I've updated the proposal at: https://fedoraproject.org/wiki/Features/F12X86Support The revised proposal: - Build all packages for i686 (this requires cmov) - Optimize for Atom I do not understand then, that there exist i686 packages which have higher requirements. Look at the ATLAS library for which I had filed a bug because only SSE/SSE2/SSE3 variants are provided, https://bugzilla.redhat.com/show_bug.cgi?id=510498 , which got closed as CANTFIX. This implies that any program linked against these libraries is likely to fail on Pentium Pro and Pentium II systems, the first one being the archetype of the i686 platform. Moreover, it is even pulled in by basic packages like gnome-games (!). From reading the bugzilla, that looks to me like a bug upstream. The tail was If you can create such architectural default let me know, and I'll use it. ... but none ever arrived ... Andrew. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Raising the bar
Paul W. Frields wrote: On Tue, Jun 30, 2009 at 10:45:19AM +0100, Andrew Haley wrote: In Ubuntu there's a Help button on the top menu bar that leads to a nice help application, yelp. We have that app too, but it doesn't seem to have the same contents, which are: New to Ubuntu? Adding and Removing Software Files, Folders and Documents Customising Your Desktop Internet Music, Videos and Photos Assistive Tools Keeping Your Computer Safe Printing, Faxing and Scanning Advanced Topics And under each section there's a clear explanation of what to do. Maybe we have something equivalent for Fedora, but I can't find it. Perhaps this is something you could raise separately with the Fedora Docs team. OK, will do. Andrew. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Raising the bar
Matthias Clasen wrote: we'd like to announce the 'Fit and Finish' initiative for Fedora, http://fedoraproject.org/wiki/Fit_and_Finish with the goal to improve the user experience of the Fedora desktop. We want to identify the small (and sometimes large) roadblocks that make everyday computer use harder than it needs to be, and try to fix them. In Ubuntu there's a Help button on the top menu bar that leads to a nice help application, yelp. We have that app too, but it doesn't seem to have the same contents, which are: New to Ubuntu? Adding and Removing Software Files, Folders and Documents Customising Your Desktop Internet Music, Videos and Photos Assistive Tools Keeping Your Computer Safe Printing, Faxing and Scanning Advanced Topics And under each section there's a clear explanation of what to do. Maybe we have something equivalent for Fedora, but I can't find it. Andrew. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12
Tom Lane wrote: Bill Nottingham nott...@redhat.com writes: drago01 (drag...@gmail.com) said: Moving to i686 is fine, non i686 chips are mostly dead (but the perfomance gain from moving to i686 from i586 is questionable at best). ... how so? It's consistently 1-2% in reasonable benchmarks (real-world code, albeit cpu-specific). I don't understand how this proposal can survive even momentary consideration. We're going to cut off some nontrivial fraction of our userbase to get 1-2% speedup for the rest? As was already mentioned, the people who need speed are probably on x86_64 already. The x86 builds are for legacy hardware *now*, and should be understood as such. I agree. This has been quite a bewildering discussion in many ways. One of the greatest things about free software distros is the way we can keep old hardware running, and running *well*. In the process, we show that community development is less wasteful than that of Microsoft et al. They have their vested interest in making people throw old but otherwise OK computers into landfill. x86_64 for the performance seekers, x86 for everyone else. What's not to like? Andrew. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: OpenJDK / IcedTea is ###p
Kevin Kofler wrote: Robert L Cochran wrote: I'm quite sure of my professional and hobby needs for the Sun Java releases, not OpenJDK. Once again, you're eschewing the actual question: WHAT is the CONCRETE problem with Arduino on OpenJDK??? I can't see the message that you're referring to, nor find it anywhere on the net. Andrew. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: cron.hourly/daily/weekly/etc. in rawhide
Mike Chambers wrote: I looked in /etc/crontab and it only has instructions now it seems on how to setup a crontab. But even reading the anacrontab man page, I can't see where my cron.daily (for example) is set to run at 4:xx ish every night. I do see in /etc/anacrontab about delays and some settings. But guess I don't understand how it works now. I guess the basic question is, now where do I change what time I want cron.daily to run now if not /etc/crontab? Anacron does not run cron.daily: /etc/cron.daily/0anacron runs anacron. /usr/share/doc/anacron-2.3/README Anacron is not an attempt to make cron redundant. It cannot currently be used to schedule commands at intervals smaller than days. It also does not guarantee that the commands will be executed at any specific day or hour. Andrew. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Understanding the mystery of printing?
Dan Haskell (mumblyjoe) wrote: I'm having the same spelling problem with FireFox with a fresh F10 (it's not Fedora Core any more, right? :)) install. If you right click in a text box, at the bottom of the menu is a Languages sub-menu. I think that's where you change dictionaries. Mine was set to en_NZ by default! en_NZ dictionary, eh? I'm just thinking about how it would differ from other non-US English dictionaries. I can think of jandals, dags[1], kumara, puckeroo, and a few others. :-) Andrew. [1] Yeah, I know this one is actually Middle English. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Where's native Eclipse?
Kevin Kofler kevin.kof...@chello.at wrote:
Andrew Overholt wrote:
* Kevin Kofler kevin.kof...@chello.at [2009-01-29 15:10]:
Unfortunately, OpenJDK's JIT is actually faster than GCJ's native
code.
:-(
Why is this unfortunate?
Because it means GCJ sucks at generating native code.
Well, I suppose this depends on whether your glass is half empty or
half full. In the main I'm pleased with gcj's performance: the fact
that it's in the same ball park as the HotSpot server JIT in many
cases makes me very pleased indeed. HotSpot is a tremendous piece of
software, custom written for Java and very highly tuned. gcj's
performance is no shame at all.
I'm not saying that gcj couldn't be improved, of course. We should be
doing more to eliminate array bounds checks, for example, and we could
in principle do escape analysis to remove locks and convert heap
allocation to stack allocation. Also, we don't inline as much as
perhaps we could.
In principle, native code should be more efficient because you don't
have to go and recompile that bytecode all the time.
This is a popular naive view, but it isn't true. A JIT has many
advantages over a static compiler for langauges like Java. For
example, invoke{virtual,interface} can first be compiled
optimistically, on the assumption that it will always be executed with
the same target class; only if that turns out to be untrue will the
call be deoptimized to full virtual dispatch. Also, things like
vtable and field offsets and static field addresses can be hard-coded
by a JIT because the target classes are fully resolved by the time the
JIT is invoked. Finally, a JIT has easy access to profile data to
choose what to optimize and inline.
That a JIT manages to do better than GCJ's native code is a sad
state of affairs. I wish we had a decent AOT compiler for Java so we
can get rid of the slow bytecode once and for all. As it is now,
Java code is a lot slower than compiled code, and GCJ only makes it
worse instead of better.
Well, everyone is entitled to an opinion, I suppose. I don't think
there is any justification for this one.
Andrew.
--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: [fedora-java] Strange build error for classpathx-mail
Orion Poplawski wrote: Andrew Haley wrote: This is probably https://bugzilla.redhat.com/show_bug.cgi?id=459129 Jakub has a patch and we're waiting for gcj to be respun into a new RPM. Andrew. Indeed. Thanks. This one seems to have resurfaced, and may not be the same bug. http://koji.fedoraproject.org/koji/getfile?taskID=898486name=build.log Andrew. ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: [fedora-java] Strange build error for classpathx-mail
Orion Poplawski wrote: Starting looking into updating classpathx-mail to version 1.1.2 (anyone know of a reason not to?). Got a really weird internal compiler error on the ppc64 build: [javac] 1. ERROR in /builddir/build/BUILD/mail-1.1.2/inetlib-1.1.1/source/org/jpackage/mail/inet/imap/IMAPConnection.java (at line 0) [javac] /* [javac] ^ [javac] Internal compiler error [javac] java.lang.NullPointerException [javac]at org.eclipse.jdt.internal.compiler.looku [javac] p.BinaryTypeBinding.cachePartsFrom(BinaryTypeBinding.java:262) [javac]at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:719) [javac]at org.eclipse.jdt.i [javac] nternal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:699) [javac]at org.eclipse.jdt.internal.compiler.Compiler.accept(Compiler.java:294) [javac]at org.eclipse.jdt.internal.com [javac] piler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:128) [javac]at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:179) [javac]at org.eclipse.jdt.inte [javac] rnal.compiler.lookup.CompilationUnitScope.findImport(CompilationUnitScope.java:456) [javac]at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findSingleImport(CompilationUnitScope.java:510) [javac]at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInImports(CompilationUnitScope.java:359) [javac]at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInTypes(Compi [javac] lationUnitScope.java:435) [javac]at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:736) [javac]at org.eclipse.jdt.internal.compiler.ProcessTaskManager.run(ProcessTaskManager.java:137) [javac]at java.lang.Thread.run(libgcj.so.9) Other arches seemed okay but got cancelled. See: http://koji.fedoraproject.org/koji/taskinfo?taskID=809142 This was on ppc7. Resubmitted and it built okay (or at least got past this point). This time on ppc2 http://koji.fedoraproject.org/koji/taskinfo?taskID=809169 Fully successful build (if anyone wants to take a look at the package): http://koji.fedoraproject.org/koji/taskinfo?taskID=809200 This is probably https://bugzilla.redhat.com/show_bug.cgi?id=459129 Jakub has a patch and we're waiting for gcj to be respun into a new RPM. Andrew. ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: java-1.4.2-gcj-compat package problem
Dimi Paun writes: This package is giving me grief as well: [r...@dimi ~]# rpm -e java-1.4.2-gcj-compat-1.4.2.0-40jpp_31rh.FC4.1.i386 /var/tmp/rpm-tmp.84077: line 8: /usr/bin/rebuild-security-providers: No such file or directory error: %postun(java-1.4.2-gcj-compat-1.4.2.0-40jpp_31rh.FC4.1.i386) scriptlet failed, exit status 127 I don't know where this /usr/bin/rebuild-security-providers script is comming from: [r...@dimi ~]# rpm -qf /usr/bin/rebuild-security-providers file /usr/bin/rebuild-security-providers is not owned by any package It's in jpackage-utils. Andrew.
Re: java-1.4.2-gcj-compat package problem
Dimi Paun writes: From: Andrew Haley a...@redhat.com [r...@dimi ~]# rpm -q jpackage-utils jpackage-utils-1.6.6-1jpp You have a bad version of jpackage-utils; remove it and get one from `yum install'. You need version 1jpp_2rh. Heh, 1jpp_2rh 1jpp, yum should update it, no? No. But it can't find it anywhere: [r...@dimi ~]# yum update jpackage-utils-1.6.6-1jpp_2rh Setting up Update Process Setting up repositories dries 100% |=| 951 B00:00 dag 100% |=| 1.1 kB00:00 jpackage16-fc 100% |=| 951 B00:00 freshrpms 100% |=| 951 B00:00 katz 100% |=| 951 B00:00 macromedia100% |=| 951 B00:00 jpackage16-generic100% |=| 951 B00:00 extras100% |=| 1.1 kB00:00 updates-released 100% |=| 951 B00:00 lattica-development 100% |=| 951 B00:00 base 100% |=| 1.1 kB00:00 Reading repository metadata in from local files primary.xml.gz100% |=| 1.1 kB00:00 Could not find update match for jpackage-utils-1.6.6-1jpp_2rh No Packages marked for Update/Obsoletion Am I missing something? Yes. Remove it with `rpm -e'. Install it with `yum install'. Andrew.
Re: java-1.4.2-gcj-compat package problem
Dimi Paun writes: From: Andrew Haley a...@redhat.com Heh, 1jpp_2rh 1jpp, yum should update it, no? No. Why? Something is broken: my system got into this state without me doing anything wrong. Yes. Remove it with `rpm -e'. Install it with `yum install'. Still couldn't be found: I think you've got yum pointing at jpackage.org, not fedora. Get rid of whatever yum config you have pointing at jpackage.org, and you'll see this: Parsing package install arguments Resolving Dependencies -- Populating transaction set with selected packages. Please wait. --- Downloading header for jpackage-utils to pack into transaction set. jpackage-utils-1.6.6-1jpp 100% |=| 20 kB00:00 --- Package jpackage-utils.noarch 0:1.6.6-1jpp_2rh set to be updated -- Running transaction check Dependencies Resolved = Package Arch Version RepositorySize = Installing: jpackage-utils noarch 1.6.6-1jpp_2rh development50 k Transaction Summary = Install 1 Package(s) Update 0 Package(s) Remove 0 Package(s) Total download size: 50 k Downloading Packages: (1/1): jpackage-utils-1.6 100% |=| 50 kB00:01 Running Transaction Test warning: jpackage-utils-1.6.6-1jpp_2rh: Header V3 DSA signature: NOKEY, key ID 4f2a6fd2 Finished Transaction Test Transaction Test Succeeded Running Transaction Installing: jpackage-utils # [1/1] Installed: jpackage-utils.noarch 0:1.6.6-1jpp_2rh Complete! Andrew.
Re: java-1.4.2-gcj-compat package problem
Dimi Paun writes: From: Andrew Haley a...@redhat.com I think you've got yum pointing at jpackage.org, not fedora. Yes. Get rid of whatever yum config you have pointing at jpackage.org, and you'll see this: Do we really need this sort of incompatibilities? = Package Arch Version Repository Size = Installing: jpackage-utils noarch 1.6.6-1jpp_2rh development50 k Transaction Summary = I don't have development enabled! I get this instead: [r...@dimi ~]# rpm -e --nodeps jpackage-utils [r...@dimi ~]# yum install jpackage-utils Setting up Install Process Setting up repositories Reading repository metadata in from local files Parsing package install arguments Resolving Dependencies -- Populating transaction set with selected packages. Please wait. --- Downloading header for jpackage-utils to pack into transaction set. jpackage-utils-1.6.3-1jpp 100% |=| 17 kB00:00 --- Package jpackage-utils.noarch 0:1.6.3-1jpp_1rh set to be updated -- Running transaction check Dependencies Resolved = Package Arch Version RepositorySize = Installing: jpackage-utils noarch 1.6.3-1jpp_1rh base 46 k Transaction Summary = Install 1 Package(s) Update 0 Package(s) Remove 0 Package(s) Total download size: 46 k Is this ok [y/N]: y Downloading Packages: (1/1): jpackage-utils-1.6 100% |=| 46 kB00:00 Running Transaction Test Finished Transaction Test Transaction Test Succeeded Running Transaction Installing: jpackage-utils # [1/1] Installed: jpackage-utils.noarch 0:1.6.3-1jpp_1rh Complete! Much older jpackage-utils, it will get updated from jpackage as soon as I enable it again :( Something is foobared... My guess is your yum is pointed at FC4. Andrew.
Re: java-1.4.2-gcj-compat package problem
Dimi Paun writes: From: Andrew Haley a...@redhat.com My guess is your yum is pointed at FC4. Sorry I didn't mention it, it is indeed. It's just broken for FC4 :) People still use it, no? Well, this is fedora-devel-list. OK, so you've got a configuration problem, with a bleeding-edge jpackage overriding the stable FC4 release. Andrew.
