I'm following the tutorial here: http://home.earthlink.net/~cortana/gpghowto.html to create my PGP signature.
At this section: "If you type ``gpg --armor --export janeq@yoyodyne.com > my_public_key.asc'', GnuPG will create a keyfile that you can email to anyone you like. "
I get the following error message: ]$ gpg --armor --export elwoo@videotron > Elton's_public_key.asc
gpg: /home/abe/.gnupg/gpg.conf:141: argument not expected
Is this a bug in GPG?
Elton
On Wednesday 22 October 2003 13:21, Elton Woo wrote:
gpg: /home/abe/.gnupg/gpg.conf:141: argument not expected
Is this a bug in GPG?
Elton
Well, whats on line 141? It's not necessarily a bug, but it just didn't like something in your config file.
On October 22, 2003 08:50 pm, Jesse Keating , <Jesse Keating jkeating@j2solutions.net> wrote:
On Wednesday 22 October 2003 13:21, Elton Woo wrote:
gpg: /home/abe/.gnupg/gpg.conf:141: argument not expected
Is this a bug in GPG?
Elton
Well, whats on line 141? It's not necessarily a bug, but it just didn't like something in your config file.
Thank you. I had removed the REM from that line: reinserting the # corrected my problem.
Elton ;-)
Hello all-
I am in the process of reading through "Teach yourself Red Hat Linux 9 in 24 Hours" and am learning more than I though possible. I am actually running FC1 Test 3, and for the most part, the book applies.
However, I am reading up on XDMCP to run Gnome over a remote X connection. I am able to turn on XDMCP with no problems in FC1, but the next step is to open up TCP/UDP ports 177 in the firewall. I fire up the Security Level Configuration tool to open up these two ports, but there is not an "other ports" box (as apparently there was in RH9) to open up ports other than http, ssh, ftp, etc...
My questions are as follows:
1) Any reason in particular that this feature would be removed? There are about a million reasons why ports other than the standard 5 would need to be opened, and a simple interface (integrated into the current Security Level Configuration app) for customizing the (nonstandard) open ports would be nice.
2) Am I going to have to play around with iptables at the command line to open up these two ports (if yes, just let me know, and I'll man/info iptables).
Any info would be greatly appreciated. Thanks,
-Sean
Sean Earp said:
I fire up the Security Level Configuration tool to open up these two ports, but there is not an "other ports" box (as apparently there was in RH9) to open up ports other than http, ssh, ftp, etc...
My questions are as follows:
- Any reason in particular that this feature would be removed? There
are about a million reasons why ports other than the standard 5 would need to be opened, and a simple interface (integrated into the current Security Level Configuration app) for customizing the (nonstandard) open ports would be nice.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=105827
Oddly enough, it is still there in redhat-config-securitylevel-tui
- Am I going to have to play around with iptables at the command line
to open up these two ports (if yes, just let me know, and I'll man/info iptables).
Any serious firewall work will most likely require iptables knowledge, or a more advanced frontend (shorewall, firestarter, etc.)
On Oct 26, 2003, at 8:24 PM, William Hooper wrote:
- Any reason in particular that this feature would be removed? There
are about a million reasons why ports other than the standard 5 would need to be opened, and a simple interface (integrated into the current Security Level Configuration app) for customizing the (nonstandard) open ports would be nice.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=105827
Oddly enough, it is still there in redhat-config-securitylevel-tui
William-
Thanks for the response... it is quite interesting that the GUI firewall is lacking in some (basic) functionality, while its EXTREMELY ugly TUI cousin does have it...
in looking over redhat-config-securitylevel-tui, I notice something interesting. The settings in the redhat-config-securitylevel-tui are not the same as they are in the GUI version. I enable (for example) SSH and FTP passthrough in the GUI, save the changes, and then start up the TUI version and nothing is selected. I would think that changing the firewall settings would change them globally... is this a bug???
-Sean
Hello all-
Using FC Test 3, latest updates from Rawhide... In KDE, the "Start Here" icon on the desktop doesn't work... just pops up a message that says:
"Error - KDesktop Malformed URL Start-here:"
Works fine in Gnome, but not in KDE. Am I the only one, or do I need to throw this at Bugzilla?
-Sean
On Sun, 2003-10-26 at 23:20, Sean Earp wrote:
Using FC Test 3, latest updates from Rawhide... In KDE, the "Start Here" icon on the desktop doesn't work... just pops up a message that says:
"Error - KDesktop Malformed URL Start-here:"
Works fine in Gnome, but not in KDE. Am I the only one, or do I need to throw this at Bugzilla?
Configuration error on your end, although perhaps caused by conflicts or packages (this I couldn't say). It does not happen here, no available updates from RawHide.
Mine has this as the URL: vfolder:/start-here.menu/Start Here/
-Sean
-- fedora-test-list mailing list fedora-test-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-test-list
Sean Earp schrieb:
Hello all-
Using FC Test 3, latest updates from Rawhide... In KDE, the "Start Here" icon on the desktop doesn't work... just pops up a message that says:
"Error - KDesktop Malformed URL Start-here:"
Works fine in Gnome, but not in KDE. Am I the only one, or do I need to throw this at Bugzilla?
it's a know bug, and should be fixed in kdebase-3.1.4-5.
Than
Am Mo, den 27.10.2003 schrieb Than Ngo um 16:02:
it's a know bug, and should be fixed in kdebase-3.1.4-5.
This is what happened to me: Start Here worked in Gnome. After some Updates it worked with KDE, too. After changing the icon theme in KDE there was no icon anymore (for KDE themes usually include no Start here), so I changed the Icon to the one from RH artwork.
Now Start here is broken in Gnome: Something like "The application connected to vfolder is not valid." (sorry for the bad translation), and im not able to set up a new application for the button for this doesn't work.
So you can't have Start here in KDE and Gnome. Will this be fixed in kdebase 3.1.4-5?
Thanks a lot
Christoph
Christoph Wickert schrieb:
Am Mo, den 27.10.2003 schrieb Than Ngo um 16:02:
it's a know bug, and should be fixed in kdebase-3.1.4-5.
This is what happened to me: Start Here worked in Gnome. After some Updates it worked with KDE, too. After changing the icon theme in KDE there was no icon anymore (for KDE themes usually include no Start here), so I changed the Icon to the one from RH artwork.
this icon is missed in other Icon Theme. I will fix it in next kdebase-3.1.4-5
Now Start here is broken in Gnome: Something like "The application connected to vfolder is not valid." (sorry for the bad translation), and im not able to set up a new application for the button for this doesn't work.
Problem is that the starthere desktop file, which is created in GNOME, has diffenrent URL=start-here: it's not valid for KDE. I have already fixed this problem.
So you can't have Start here in KDE and Gnome. Will this be fixed in kdebase 3.1.4-5?
yes, kdebase-3.1.4-5 will fix this problem.
Than
Sorry for writing to the test list, but this is a reply to an old mail for the testing times.
Am Di, den 28.10.2003 schrieb Than Ngo um 10:26:
Christoph Wickert schrieb:
This is what happened to me: Start Here worked in Gnome. After some Updates it worked with KDE, too. After changing the icon theme in KDE there was no icon anymore (for KDE themes usually include no Start here), so I changed the Icon to the one from RH artwork.
this icon is missed in other Icon Theme. I will fix it in next kdebase-3.1.4-5
Not really.
So you can't have Start here in KDE and Gnome. Will this be fixed in kdebase 3.1.4-5?
yes, kdebase-3.1.4-5 will fix this problem.
Not really. # rpm -q kdebase kdebase-3.1.4-6
Shortcuts created in Gnome won't work in KDE anymore. Nothing happens, not even a failure in .xsession-errors.
As long, as this doesn't work I vote for separate desktops again.
Christoph
Christoph Wickert wrote:
Sorry for writing to the test list, but this is a reply to an old mail for the testing times.
Am Di, den 28.10.2003 schrieb Than Ngo um 10:26:
Christoph Wickert schrieb:
This is what happened to me: Start Here worked in Gnome. After some Updates it worked with KDE, too. After changing the icon theme in KDE there was no icon anymore (for KDE themes usually include no Start here), so I changed the Icon to the one from RH artwork.
this icon is missed in other Icon Theme. I will fix it in next kdebase-3.1.4-5
Not really.
So you can't have Start here in KDE and Gnome. Will this be fixed in kdebase 3.1.4-5?
yes, kdebase-3.1.4-5 will fix this problem.
Not really. # rpm -q kdebase kdebase-3.1.4-6
Shortcuts created in Gnome won't work in KDE anymore. Nothing happens, not even a failure in .xsession-errors.
As long, as this doesn't work I vote for separate desktops again.
Christoph
I would like to see KDE and GNOME more as separate programs myself. The reason for the separation would be more for time line development between KDE and GNOME coming out at different times.
It would probably be better to have a bluetooth integrator that allows for different developmental cycles. That way, there would be fewer complaints when one might decide to upgrade either manager independently.
I am trying out the beta KDE packages and the conflict with the menus causing me to have to remove openoffice.org to test out the KDE manager gives sight to much more conflicting problems in the future.
Bluetooth probably needs to emerge as an alternative manager, instead of as a meshing between the two GUI managers.
Just my thoughts on the separation or amalgamation with the window managers.
Jim
On 20/11/03 Jim Cornette did say:
I would like to see KDE and GNOME more as separate programs myself. The reason for the separation would be more for time line development between KDE and GNOME coming out at different times.
I'd like to see less bias against KDE in Fedora. I tried KDE, and I took me 30 minutes to enable features to make it half-way decent, like anti-aliased fonts. Why were these disabled by default? Why is the KDE menu full of Gnome programs, with the KDE programs buried deeper? Fedora seems like a terrible place for people who prefer KDE.
Mike
Michael P. Soulier schrieb:
On 20/11/03 Jim Cornette did say:
I would like to see KDE and GNOME more as separate programs myself. The reason for the separation would be more for time line development between KDE and GNOME coming out at different times.
I'd like to see less bias against KDE in Fedora. I tried KDE, and I took me 30 minutes to enable features to make it half-way decent, like anti-aliased fonts. Why were these disabled by default?
strange, anti-aliased fonts is always enable by default in KDE. Perhaps you have disabled it before?
Why is the KDE menu full of Gnome programs, with the KDE programs buried deeper? Fedora seems like a terrible place for people who prefer KDE.
please install all KDE packages from Fedora, you will get more KDE apps in menu ;-)
Than
On October 27, 2003 02:20 am, Sean Earp , <Sean Earp smearp@mac.com> wrote:
Hello all-
Using FC Test 3, latest updates from Rawhide... In KDE, the "Start Here" icon on the desktop doesn't work... just pops up a message that says:
"Error - KDesktop Malformed URL Start-here:"
Works fine in Gnome, but not in KDE. Am I the only one, or do I need to throw this at Bugzilla?
I think it's related to this bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=102533
Elton ;-)
Sean Earp said:
in looking over redhat-config-securitylevel-tui, I notice something interesting. The settings in the redhat-config-securitylevel-tui are not the same as they are in the GUI version. I enable (for example) SSH and FTP passthrough in the GUI, save the changes, and then start up the TUI version and nothing is selected. I would think that changing the firewall settings would change them globally... is this a bug???
IIRC the tui version doesn't read the current config. In the past neither tool did, but I believe they have fixed the GUI version.