upgrading RH 9 system->Fedora with iso files and apt only
by Didier Casse
I have the yarrow's iso files on my HD in a RH9 system. Let's say I want
to upgrade selected packages using an "apt-get install" pointing to my
iso-mounted files, how do I do it?
i.e I mount the iso into some /mnt/yarrow1, /mnt/yarrow 2 etc..
Then what is the complete procedure to make my apt look into my own HD to
upgrade packages. Can anybody redirect me to the correct
resource or some literature hanging on the web? Thanks.
Assume also that I do not wish to burn CDs! I do not want to use
apt-cdrom. Thanks.
With kind regards,
Didier.
---
PhD student
Singapore Synchrotron Light Source (SSLS)
5 Research Link,
Singapore 117603
Email: slsbdfc at nus dot edu dot sg \or\
didierbe at sps dot nus dot edu dot sg
Website: http://ssls.nus.edu.sg
1 year, 4 months
autoconf breakage on x86_64.
by Sam Varshavchik
I don't know the right way to fix this, but something is definitely broken;
and something needs to be fixed, one way or the other. The question is what
exactly needs to be fixed.
Consider something like this:
LIBS="-lresolv $LIBS"
AC_TRY_LINK_FUNC(res_query, AC_MSG_RESULT(yes), AC_MSG_RESULT(no))
Here's what happens on x86_64:
gcc -o conftest -g -O2 -Wall -I.. -I./.. conftest.c -lresolv >&5
/tmp/ccW7EeDX.o(.text+0x7): In function `main':
/home/mrsam/src/courier/authlib/configure:5160: undefined reference to
`res_query'
collect2: ld returned 1 exit status
configure:5147: $? = 1
configure: failed program was:
[ blah blah blah ]
| /* We use char because int might match the return type of a gcc2
| builtin and then its argument prototype would still apply. */
| char res_query ();
| int
| main ()
| {
| res_query ();
| ;
| return 0;
| }
The same exact test on FC1 x86 will work.
The reason appears to be that you have to #include <resolv.conf> on x86_64
in order to succesfully pull res_query() out of libresolv.so. You don't
need to do this on x86, and the test program generated by AC_TRY_LINK_FUNC
does not include any headers, but uses a manual prototype.
So, what now?
16 years, 8 months
ia32e, er EM64T that is...
by Jesse Keating
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
What are the chances of getting an ia32e specific kernel in the x86_64
version of Fedora Core 3? We're starting to ship Nacona based systems,
and we have always done Fedora Core pre-installs. While the x86_64
kernel of FC2 works now, I thought it was in some sort of 'compatible
64bit' mode rather than ia32e or em64t specific mode.
I guess a better question: With kernel 2.6, is there any need to have a
specific ia32e vs amd64 kernel? Are all the differences worked out at
runtime and thus a non-issue? Thanks.
- --
Jesse Keating RHCE (http://geek.j2solutions.net)
Fedora Legacy Team (http://www.fedoralegacy.org)
GPG Public Key
(http://geek.j2solutions.net/jkeating.j2solutions.pub)
Was I helpful? Let others know:
http://svcs.affero.net/rm.php?r=jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBPJpX4v2HLvE71NURAgLOAJ41i+nTykxeQlOs+SG0Lxu297RM/gCfQ30X
DzP7D/wWGZN0T8LiXAlZFpY=
=7oGl
-----END PGP SIGNATURE-----
18 years, 5 months
APT repository problems with up2date
by Jos Vos
Hi,
Before I start digging in the up2date code myself, maybe someone
can comment on this:
I have a problem when using up2date up2date with my self-created
APT repositories. When updating, it complains about conflicting
files: it just thinks that a long list of directories that are
shared among packages conflict with each other.
Apt-get itself (and synaptic) seems to work fine with the same
repository, only with up2date there is a problem. Also, up2date
with a yum repository of then same package set works fine, as
does yum itself.
FWIW: I generate my APT repositories with --flat --bloat.
Cheers,
--
-- Jos Vos <jos(a)xos.nl>
-- X/OS Experts in Open Systems BV | Phone: +31 20 6938364
-- Amsterdam, The Netherlands | Fax: +31 20 6948204
18 years, 6 months
emacs-nxml-mode new version out.
by Gavin Henry
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all,
If I remember Tim Waugh did an rpm for this.
Tim, do you have an updated one or should I take your src.rpm and update it?
http://www.thaiopensource.com/download/nxml-mode-20040726.tar.gz
- --
Kind Regards,
Gavin Henry.
Managing Director.
T +44 (0) 1224 587369
M +44 (0) 7930 323266
F +44 (0) 1224 742001
E ghenry(a)suretecsystems.com
Open Source. Open Solutions.
http://www.suretecsystems.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBBSOieWseh9tzvqgRAqS7AJ9dw2htkWghGDkqaSSxnDuUj8m5pQCgkm2x
zjEl0ToUdqT4KOugxCowY24=
=hVlR
-----END PGP SIGNATURE-----
18 years, 6 months
gnupg newpg gpgme gpgme03 cryptplug isuses
by Dennis Gilmore
Recently the version of libgcrypt was increased to 1.1.94 as a result of
this newpg would not build against the newer libgcrypt i sent an email to
gcrypt-devel list and this is what i got back
<quote>
Don't build newpg at all. It has been superseded by gnupg-1.9.x .
You would need an old libgcrypt < 1.1.42 to build it. The configure
sscript was not able to detect newer versions with a changed API.
</quote>
we have a problem here seems we no longer need newpg but we need things it
provides for gpgme gpgme03 cryptplug gpa kgpg (which doesnt complain so
much just says its not there) to get these things it provides we need to
go to the newer gnupg or we need to revert back to the older libgcrypt.
being so late in the cycle i dont know which would be best. so i thought id
ask before filling a bug against something. it does need to be fixed before
final is out as people will complain if they cant decrypt email in kmail or
mutt gpa doesnt work etc. i think we should probably go back to the old
version of libgcrypt
Dennis
18 years, 7 months
mozilla 1.7.3?
by D. Stolte
mozilla 1.7.3 has been released some weeks ago and fixes some security
problems. when can we expect to see it packaged?
/ds
18 years, 8 months
QA-process for new packages
by Silke Reimer
Hallo!
Some time ago I submitted a few packages on fedora.us. One of them
(gdal, Bug #1964) got lots of comments so I rebuilt the package and
announced it today. Due to several reasons it took me some time to
rebuild the package and meanwhile I have been set as owner of the
bug (and of all my other bugs (#1965, #2000 and #2001) as well).
Since I am not member of the QA team I don't really understand this
action. I thought that people that are new to fedora can submit
packages thus being submitter of a bug. Afterwards the QA team
assigns someone to do the quality assurance and the submitter will
have to fix the package if there are problems.
So, my question is: Did I misunderstand the process? And what should
I do to ensure that a QA team member might look at my packages? Or
is this perhaps the normal process and I don't have to do anything
at all?
Thanks for all explanation (or some hints to any documention [1]),
Silke
[1] Yes, I already read: http://www.fedora.us/wiki/PackageSubmissionQAPolicy
--
Silke Reimer
Intevation GmbH http://intevation.de/
FreeGIS http://freegis.org/
18 years, 8 months
subversion-1.1 released
by Neal Becker
subversion-1.1 is released. It would be great to include this. It allows
use of subversion without requiring a database. It would be good to
include this capability before many users have migrated to subversion.
18 years, 8 months
