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
Cannot rely on /dev being present in %post scripts?
by David Woodhouse
According to bug #517013, %post scripts should not assume that /dev is
available -- so we can't do anything that requires the existence of
/dev/null, /dev/urandom, etc.
Is this a known and expected packaging rule, or is it a bug in the way
that the user is attempting to install the packages?
--
David Woodhouse Open Source Technology Centre
David.Woodhouse(a)intel.com Intel Corporation
13 years, 2 months
kernel/accounting question ...
by William W. Austin
(I know that this question might be more reasonable on a kernel list,
but a while back I posted the question twice and got no answers.)
The acct struct is defined in /usr/include/sys/acct.h includes both
ac_io and ac_rw for bytes transferred and blocks read or written,
respectively. Fair and good - works (on paper) similarly to unix,
solaris, hp-ux, etc.
However, in the kernel code [kernel/acct.c], ac_io (char) and ac_rw
(blocks) are always set to 0 by these two lines:
ac.ac_io = encode_comp_t(0 /* current->io_usage */);
ac.ac_rw = encode_comp_t(ac.ac_io / 1024);
For most purposes, this probably wouldn't be an issue, but I also do
extensive performance analysis on several platforms and have written a
fairly compresive accounting package (as a wraparound for psacct or as
a standalone) including both an improved acctcom and a built-in
reporter for it.
Does anyone know wby the kernel zero's out the bytes transferred data?
(Overhead comes to mind.) Not that it makes a huge differnce for my
purposes (I had to write some wraparound code to make a
"best-guestimate" about the data I'm missing), but curiosity is bugging
me now. When I compile my program on other OS's I get useful data for
char and block i/o and I'd like to find out whether there is something
obvious that I'm just totally missing here...).
Thanks
--
william w. austin waustin(a)speakeasy.net
"life is just another phase i'm going through. this time, anyway ..."
13 years, 5 months
acctcom for linux
by William W. Austin
I recently made several updates to a Linux version of of acctcom
(actually another accounting add-on package) which I've been using for
several years, and one of the people testing it asked a question which
I cannot answer. I'm hoping that someone on this list can give me some
info.
I have previously (over a year ago) asked on both this and a couple of
kernel lists (several times there) about this issue, but nobody has
ever answered. So if you have any info about this, I'd really
appreciate it.
As in many (all?) previous Linux kernels, the struct acct (defined in
/usr/include/sys/acct.h) has members ac_io and ac_rw which are
presumably counts of characters transferred and blocks read/written
respectively.
However, in the kernel code, the ac_io is set to 0 and the ac_rw gets
set to (ac_io/512) or some such - it is set to 0 as well (and thus
these are always reported as 0 in process accounting records. not good
if you're trying to measure them...).
Does anybody know why this is done that way? A long time ago (IIRC
late 2.2 and an early 2.4 kernel) I looked into "fixing" this in the
kernel code but was not successful (I finally produced a bootable
kernel, but it was unstable. Then I changed jobs, got swamped at work,
and eventually gave up).
As I said above, I have previously asked about this issue without
success, and I have essentially given up changing or "fixing" it.
But if anyone knows __WHY__ it is this way (I'm hypothesizing that it's
just too much work for too little added value), I'd really appreciate
knowing the reason. Curiosity and the cat and all that ...
Thanks
- Bill
--
william w. austin waustin(a)speakeasy.net
"life is just another phase i'm going through. this time, anyway ..."
13 years, 5 months
Packages looking for new owners
by Trond Danielsen
Hi everyone,
it is becoming clear to me that I can no longer provide the collection
of packages I maintain the love and care that they deserve. If only
there were more hours in a day, but the current situation does no
leave much room for volunteer work on free software :-(. Hopefully I
will find time in the future to return to Fedora related work
The list if packages I maintain is available here:
https://admin.fedoraproject.org/pkgdb/users/packages/trondd?acls=owner
I don't mind keeping libopenraw, avrdude and uisp unless anyone
_really_ want to maintain these packages.
Best regards,
--
Trond Danielsen
13 years, 6 months
Orphaning packages
by Conrad Meyer
Hi,
I intend to orphan the JRuby package and some of the dependencies I don't
believe anything else uses. It's a piece of software upstream really doesn't
intend to be packaged, and bumping to new versions is a constant struggle.
Furthermore, I don't have anymore use for it. Here is the list of packages
I'll orphan sometime in the next week or so:
- bytelist
- constantine
- jcodings
- jline
- jna-posix
- joni
- jvyamlb
If anyone wants any of them, let me know. (In case it's not obvious, they are
all java packages.)
Regards,
--
Conrad Meyer <cemeyer(a)u.washington.edu>
13 years, 7 months
another spin of TeX Live 2009 packages
by Jindrich Novy
Hi,
first off, thanks many people who sent me RFE and bugfix
proposals. I've tried to fix most of them in the current package set
in the testing repository:
rpm -i http://jnovy.fedorapeople.org/texlive/texlive-release-2009-0.1.fc11.noarc...
If you use the older TeX Live 2009 packages, please reinstall them
completely:
yum remove texlive
(and to be sure rm -rf /usr/share/texlive, due to ordering it could
leave some directories there)
yum clean all
yum install texlive <or other packages>
The reason for it is the following list of improvements:
- binary packages do no more have the '.ARCH' postfix, the postfix
changed to '-bin'
- new font support add new 'fedora-fonts' packages which allows you to
use TeX Live 2009 fonts (TrueType and OpenType for now) in Fedora
- packages for TeX Live t1utils and psutils are no more built but
dependencies to existing utilities in Fedora are added
- kpathsea packages should now be correctly obsoleted. The
lcdf-typetools dep errors you might see installing
texlive-collection-fontutils is caused by the fact that
lcdf-typetools in Fedora is linked against kpathsea libraries and
TeX Live 2009 increases the soname so lcdf-typetools will work after
rebuilt with the new kpathsea
- fixed texlive-xetex conflict with older TL2007 packages
- added older tetex-latex, etc. provides for compatibility (you are
now able to install TL2009 together with R analysis package, etc.)
- new packages should automatically clear /var/lib/texmf in %post
scriptlets to avoid format incompatibilities
I haven't added obsoletes to .ARCH packages to keep spes files
readable and because TL2009 packages are not yet imported.
The spec format should be final now. Only some font formats can be
added or the Fedora font support updated for a bit.
I will announce next repo updates here:
http://fedoraproject.org/wiki/Talk:Features/TeXLive
Thanks,
Jindrich
--
Jindrich Novy <jnovy(a)redhat.com> http://people.redhat.com/jnovy/
13 years, 8 months
Possible packages...
by Nathanael D. Noblet
Hello,
So I've been toying with the idea of getting more involved with
fedora. Up till now if there has been a bug or other issue, i'll file
a bug or simply get the srpm and try to update it to a newer version,
or create my own specs / rpms when they don't already exist. Lately
I've figured that I should get more involved with some of the packages
that I use or anything like that. The packaging guidelines kinda
describe entry to the packager group as being done via new packages.
I've offered to try to help on some recently orphaned packages. Though
that may be more work than just submitting a new package.
So after all that rambling, I'm wondering about the two following
pieces of software.
Apple's Calendar Server. It runs using python 2.5 or greater (I've
installed it on a F11 machine and it work well). I've started looking
at some of its dependancies. 90% of them are in fedora already, and of
the ones in F11, only one if I remember correctly isn't at the version
it requires). It seems like a great addition to Fedora if you ask me.
So basically it would require two new packages, and an update to one
other package (libevent) which is a minor version bump it seems if at
all needed.
PS3MediaServer. A Java program to talk to a PS3 with DLNA. I'm
guessing this one would have problems because it requires ffmpeg or
mplayer/mencoder... Plus as a java program its probably a bit more
complex to create a proper spec file for. I've made the other kind
often enough, but java ones not so much...
Any feedback on either?
13 years, 8 months
