gcc -m32 failure on FC2 x86_64
by Scott Saccone
I'm using the x86_64 of FC2 and FC3 and I cannot use gcc with the -m32
option. Compiling helloworld using gcc -m32 yields "/usr/bin/ld: crt1.o:
No such file: No such file or directory collect2: ld returned 1 exit
status".
Is this because the glibc package has not installed the files needed for
the -m32 option? The file /usr/lib64/crt1.o exists, but not
/usr/lib/crt1.o. I've installed the latest versions of this package with
up2date.
Others have reported this, and have flirted with the idea of installing
files from the i386 version of glibc, but I would prefer to find a
"real" solution.
This is pretty serious problem for me as there are some apps that don't
seem to run with plain gcc - seg faults perhaps due to the assumption of
4 byte pointers. Also in the lastest version GRUB the configure program
fails when it attempts to compile something using -m32.
SPECS:
CPU: 2 x 3.2GHz Xeon Nocona
Linux: 2.6.5-1.358smp
Distro: FC2 x86_64
gcc: 3.3.3 20040412 (Red Hat Linux 3.3.3-7)
and
CPU: AMD64 3400+
Linux: not sure (no access at the moment)
Distro: FC3 x86_64
gcc: not sure
19 years, 4 months
XDMCP Core 3
by Jonathan Andrews
Is XDMCP, remote X bust in core 3 ?
I've tried the gui configuration for tool gdm. The machine has no
firewall enabled - all I get the "gdm_child_action: Aborting display
jonspc:1" in the log ?
I've googled for this message and I get the same useless file over and
over again with no comments that help me.
Before somebody cries this is the wrong list, I disagree - if the GUI
tool in core3 (and soon core 4) pretends you can enabled XDMCP and
remote greeter then it should work, its getting a bit rarer - but it
ain't dead yet !
Thanks,
Jon
19 years, 4 months
Reopen a request for gpgme in Core
by Toshio Kuratomi
Hi -- I made a request for gpgme in Core a while back but it was closed
until some Core apps used it [1].
I've confirmed that Balsa works with gpgme 1.0.1.
Rex Dieter has confirmed that kmail works as well.
I've created a patch for sylpheed that gets it to use gpgme 1.0.1 as
well. (Just introduced it upstream so I haven't heard if it's
acceptable there yet.)
So that's two and a half Core packages that would be significantly
enhanced with the inclusion of gpgme 1.0.x. Should I open a new
enhancement request or can someone reopen the old one?
Also, should I post my sylpheed patch into the redhat bugzilla somewhere
(For instance, [2]) or just follow the upstream mantra? (It's currently
1618 lines so it's not a trivial fix.)
[1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=140168
[2] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=80978
-Toshio
--
Toshio <toshio(a)tiki-lounge.com>
19 years, 4 months
HowTo read/write /dev/port from a user not root
by Dario Lesca
Hi, is possible read and write on /dev/port via a normal user (not
root)?
> sh-3.00$ ls -l /dev/port
> crw-rw-rw- 1 root kmem 1, 4 29 dic 10:38 /dev/port
> sh-3.00$ cat -v /dev/port
> cat: /dev/port: Operation not permitted
> sh-3.00$
Many thanks
--
Dario Lesca <d.lesca(a)solinos.it>
19 years, 4 months
Re: Fedora Core 4
by Dag Wieers
On Wed, 19 Jan 2005, Jeff Spaleta wrote:
> On Thu, 20 Jan 2005 04:12:16 +0100 (CET), Dag Wieers <dag(a)wieers.com> wrote:
> > I bet you will get more rants than bug reports. Especially if important
> > security fixes are in the pipeline and they are not installed because of a
> > single unrelated problem.
>
> I'm not talking about unrelated problems... or stopping the full set
> of unrelated transactions cold because of one package problem. I'm
> trying to confine my arguments to the scope of how the broken dep
> wireless-tools update should be working... without the extra
> complication of additional unrelated transactions.
Yes, and you fail to indicate where Smart does it wrong :) Smart actually
does what you said it should be doing.
> What I am arguing is that there needs to be an ecoding of an
> understanding of inherent channel policy and inherent inter-channel
> policy to avoid presenting transactions that are clearly only going to
> be presented to the user if there has been a packaging error. This is
> orthogonal to channel priorities or per-package priorties. We know..
> as competent users.. that updates-releases should never implicitly
> require a removal of a Core package. We know this because this is a
> policy of how updates-released is defined. The tools like smart
> should be able to codify that knowledge so that clearly contrary
> transactions will not be presented to the user.
In the case of wireless-tools, there would not be any removals if you
just do an upgrade. The smart-gui would not upgrade to a newer
wireless-tools because it considers the cost of the removals more
important for not upgrading, than the gain of a newer wireless-tools.
Unless, of course, you specify that you want to upgrade wireless-tools
_specifically_. In that case smart-gui will show you exactly _what_ it
will do and _why_ it will do that. (The removals)
> I as a user should not be shown a transaction that includes the removal
> of a NetworkManager and kdenetwork from Core because of the busted
> wireless-tools update from updates-released.
Exactly, smart-gui would not show that transaction if you update. It would
only show you when you select the newer wireless-tools despite what it
suggests. Did you try this or is this based on how you think Smart works ?
> > Smart has this, look in smart-gui at:
> >
> > Edit > Check All Packages
>
> This does not appear to be what I am trying to describe at all.
> Perhaps if you give me a a few sentences as to what I'm actually
> seeing in this dialog this might clear up my confusion.
Jeff, you removed what you said. Actually what you said did not describe
what you wanted, it just gave a general disagreement. Here is what you
said and what I commented on:
> > > There is a better way in my head, involving keeping up with 'channel
> > > policies' instead of 'priorities'.. i just have to find the words
> > > and the time to articulate it. A way that allows smart to do exactly what
> > > it does now when it needs to deal with overlapping addon repos when
> > > you want to install something new... but flags reportable problems
> > > when a channel or group of channels aren't self-consistent when they
> > > should be.
I commented on the self-consistency. The dialog I talked about does
exactly that. It shows what packages have unresolved dependencies. Sure it
can be improved, send your suggestions to Gustavo when you succeed in
formulating them.
> The dialog certaintly didn't notice the wireless-tools update
> deficiency afaict. I certaintly can't use that dialog to ask
> questions like 'Are there any packages in updates-released that
> require the removal of Core packages to be installed?'
Any older package could be causing the removal of a package that requires
the newer packager. So that definition would not be good.
What would be useful though, and I'm certainly going to ask Gustavo this,
is that this dialog should show which newer versions would cause other
newer versions to be uninstalled. (Maybe a special debug-menu is in order)
(In the pretense that a newer package is introduced with the sole aim to
become updated, because with Smart you could be introducing an older
package, to fix a situation that RPM fails to detect, and keep the new one
in the repo :))
That's where Smart differs, it does not only take the E-V-R into
account. It does not try to force a new version on to you because it
happens to be available, it looks at what cost. And I understand the
uncomfortable feeling of this seemingly undeterministic behaviour, but it
works.
And you can make use of this cleverness if you want to mix repositories.
-- dag wieers, dag(a)wieers.com, http://dag.wieers.com/ --
[all I want is a warm bed and a kind word and unlimited power]
19 years, 4 months
Improving security
by Hans de Goede
Hi,
I just read this interesting article on lwn:
http://lwn.net/Articles/106214/
(lwn subscriber only)
This talks about things like:
1 Stack Smash Protection
2 PAX (alternative Exec Shield)
3 Position Independent Executables.
Stack Smash Protection sounds like a cool feature to me. I don't know
what the performance impact is, but as a developer even if it is to slow
to use by default I would love to have it intergrated into the gcc
shipped by Fedora to make debugging easier.
PAX uses tricks to get a non executable stack, and assignes random
addresses to PIE executables, which Fedora already has in the form of
Exec Shield, good! But if I undertand it correctly PAX does more for
example also make data pages non executable, this might be something
worth looking into.
PIE we already have, good!
Regards,
Hans
19 years, 4 months
RFE: php-mcrypt + libmcrypt
by Alexander Dalloz
Hi!
Before writing a bugzilla RFE ticket I like to ask whether there are
good reasons to not ship PHP with mcrypt support, means a php-mcrypt
module and the required libmcrypt package. Are there such specific
reasons?
I know there is
http://phprpms.sourceforge.net/mcrypt
but think it would be worth to have it in the Core packages.
Alexander
--
Alexander Dalloz | Enger, Germany | new address - new key: 0xB366A773
legal statement: http://www.uni-x.org/legal.html
Fedora GNU/Linux Core 2 (Tettnang) on Athlon kernel 2.6.10-1.9_FC2smp
Serendipity 20:57:46 up 5 days, 4:19, load average: 0.74, 0.81, 0.66
19 years, 4 months
perl INSTALLDIRS=vendor
by Alan Milligan
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
People,
I'm having a few problems source compiling a number of perl modules. I
don't really like this vendor concept, whats wrong with site_perl??
But the problem I face is that the %files is inconsistent. For example,
in perl-HTML-Parser, the line is as follows:
%dir %{_libdir}/perl5/%(perl -MConfig -le 'print
"$Config{version}/$Config{archname}"')/HTML
but of course the files have been placed in vendor_perl/5.8.5. The
correct line in this case is:
%dir %(perl -MConfig -le 'print "$Config{vendorarch}"')/HTML
There are a number of other modules similarly broken. Comments please.
Alan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFB2VAwCfroLk4EZpkRAvwbAKCTqyw6VfkfKIfTnYJOXRNjycUnswCfXi1c
AsQmAB0RKyvZTNBf2I+hGpA=
=Qw+6
-----END PGP SIGNATURE-----
19 years, 4 months
rawhide report: 20050119 changes
by Build System
New package linux-atm
Tools to support ATM networking under Linux.
Updated Packages:
createrepo-0.4.2-2
------------------
* Tue Jan 18 2005 Jeremy Katz <katzj(a)redhat.com> - 0.4.2-2
- add the manpage
* Tue Jan 18 2005 Jeremy Katz <katzj(a)redhat.com> - 0.4.2-1
- 0.4.2
foomatic-3.0.2-13
-----------------
* Tue Jan 18 2005 Tim Waugh <twaugh(a)redhat.com> 3.0.2-13
- Updated db to 20050118.
* Mon Jan 10 2005 Tim Waugh <twaugh(a)redhat.com>
- Added IEEE 1284 information for Epson Stylus Photo R200 (bug #144631).
* Tue Jan 04 2005 Tim Waugh <twaugh(a)redhat.com>
- Added IEEE 1284 information for Okidata Okipage 6ex (bug #143964).
- Added IEEE 1284 information for Epson Stylus Photo R300 (bug #143939).
gaim-1:1.1.1-3
--------------
* Tue Jan 18 2005 Chip Turner <cturner(a)redhat.com> 1:1.1.1-3
- rebuild for new perl
gcc-3.4.3-15
------------
* Tue Jan 18 2005 Jakub Jelinek <jakub(a)redhat.com> 3.4.3-15
- add gcc-gnat and libgnat on ppc, x86_64 and ia64 again
- fix Ada bootstrap problems on 64-bit architectures (PR ada/13470)
- run ACATS tests under expect, so that if they hang, they'll be timed
out
gcc4-4.0.0-0.20
---------------
* Tue Jan 18 2005 Jakub Jelinek <jakub(a)redhat.com> 4.0.0-0.20
- update from trunk
- fix PR c++/19406
jpackage-utils-0:1.6.2-1jpp_2rh
-------------------------------
* Tue Jan 18 2005 Thomas Fitzsimmons <fitzsim(a)redhat.com> - 0:1.6.2-1jpp_2rh
- Import jpackage-utils 0:1.6.0-2jpp from jpackage.org.
mkinitrd-4.2.0.1-1
------------------
* Tue Jan 18 2005 Jeremy Katz <katzj(a)redhat.com> - 4.2.0.1-1
- fix grubby tests to run on systems with /boot = /
* Tue Jan 18 2005 Jeremy Katz <katzj(a)redhat.com> - 4.2.0-1
- grubby: add multiboot support for xen0
- new-kernel-pkg: likewise
mod_perl-1.99_17-2
------------------
* Tue Jan 18 2005 Chip Turner <cturner(a)redhat.com> 1.99_17-2
- rebuild for new perl
postgresql-8.0.0-1
------------------
* Wed Jan 19 2005 Tom Lane <tgl(a)redhat.com> 8.0.0-1
- Update to PostgreSQL 8.0.0, PyGreSQL 3.6.1, pgtcl 1.5.2,
and jdbc driver build 309.
- Extensive cleanout of obsolete cruft in patch set.
- Regression tests are run during RPM build (NOTE: cannot build as root when
this is enabled).
- Postmaster stderr goes someplace useful, not /dev/null (bz#76503, #103767)
- Make init script return a useful exit status (bz#80782)
- Move docs' tutorial directory to %{_libdir}/pgsql/tutorial, since it
includes .so files that surely do not belong under /usr/share.
- Remove useless .sgml files from docs RPM (bz#134450)
- Put regression tests under /usr/lib64 on 64-bit archs, since .so files
are not architecture-independent.
readline-5.0-2
--------------
* Tue Jan 18 2005 Tim Waugh <twaugh(a)redhat.com> 5.0-2
- Fix line-wrapping (bug #145329).
- Apply "read -e" patch from bash package.
rp-pppoe-3.5-25
---------------
* Wed Jan 19 2005 David Woodhouse <dwmw2(a)redhat.com> 3.5-25
- Kill br2684ctl after ifdown if we started it
* Wed Jan 19 2005 David Woodhouse <dwmw2(a)redhat.com> 3.5-24
- Add support for RFC2684 Ethernet-over-ATM (for PPPoE-over-ATM)
rpmdb-fedora-1:4-0.20050119
---------------------------
vim-1:6.3.058-2
---------------
* Tue Jan 18 2005 Chip Turner <cturner(a)redhat.com> 1:058-2
- rebuild for new perl
* Tue Jan 18 2005 Karsten Hopp <karsten(a)redhat.de> 6.3.058-1
- Patchlevel 58
- rebuild with new perl
- remove all rpm backup files
xchat-1:2.4.1-3
---------------
* Tue Jan 18 2005 Chip Turner <cturner(a)redhat.com> 1:2.4.1-3
- rebuild for new perl
19 years, 4 months
Building rpms on AMD64
by Per Steinar Iversen
I tried this question on fedora-list yesterday, and got a number of
messages from other users with the same problem, but no resolution.
Perhaps this list is a better place to ask?
A silly question: How does one build or rebuild src rpms under x86_64?
On a freshly installed FC3 (full install) nearly everything fails to build
as configure looks at the wrong X11 libraries. As an example, rebuilding
mozilla:
$ rpmbuild --rebuild mozilla-1.7.5-3.src.rpm
...lines deleted...
checking GLIB_LIBS... -lglib-2.0
configure: error: Could not find the following X libraries: -lX11 -lXext -lXt
error: Bad exit status from /var/tmp/rpm-tmp.13288 (%build)
Modifying the spec-file to add a line like this cures the problem:
--x-libraries=/usr/X11R6/lib64
But this is probably too crude - what is the proper incantation to make
rpmbuild understand where the X11 libraries are placed on x86_64?
-psi
19 years, 4 months