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
2 years, 3 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
14 years, 1 month
2009-10-22 - Power Management Test Day report
by Phil Knirsch
Here a short report from the Power Management Fedora Test day on
10/22/09 [1]. First of all many thanks to all the people who
participated in it and who reported their findings. In order to make
things easier for testers and to make sure we get a lot more stable and
comparable results Marcela Maslanova, Jan Vcelak and Petr Lautrbach put
together a rpm that consisted of all our test scripts, an easy
call-script to easily run them and a "collect" script to pack together
all results. Additionally the rpm itself has requirements against all
the packages we needed for the tests, so a simple installation of the
testday rpm provided a solid and easy method for every tester. This
worked out really well and made test results very consistent.
Unfortunately time ran out for including the automatic upload script
from Mike McGrath and the ALPM test script, but that didn't seem to pose
a big problem, roughly half of the testers provided results for ALPM as
well.
We got 30 results overall with half of them including ALPM test results,
too. Overall the results showed us what we wanted to know:
- The tools we're shipping are working as expected, no crashes or
anything like that observed
- Wakeups and system behavior in genereral in comparison to our Fedora
11 test day doesn't show any regressions
- New features seem to be working as expected
Rudolf Kastel discovered one strange bug with one of the profiles which
we couldn't reproduce yet, but we're still investigating with him.
All in all the whole test day was a real success. Especially the great
idea of Marcela, Jan and Petr to make a rpm for the testday which
automated a lot of the work that needed to be done.
For the next testday we already plan to expand that idea and include the
automated upload script which will make it even easier for the testers.
[1] https://fedoraproject.org/wiki/Test_Day:2009-10-22
--
Philipp Knirsch | Tel.: +49-711-96437-470
Team Lead Core Services | Fax.: +49-711-96437-111
Red Hat GmbH | Email: Phil Knirsch <pknirsch(a)redhat.com>
Hauptstaetterstr. 58 | Web: http://www.redhat.com/
D-70178 Stuttgart, Germany
Motd: You're only jealous cos the little penguins are talking to me.
14 years, 4 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 ..."
14 years, 4 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 ..."
14 years, 4 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
14 years, 4 months
texlive 2009 - should set TEXMFCNF?
by Neal Becker
I wonder if texlive should include a /etc/profile.d package to set TEXMFCNF,
so that other packages, such as xdvipdfmx will work? Or, should texlive
just obsolete xdvipdfmx and include it's own version?
14 years, 5 months
does fedora have anything requiring :mail rw access?
by Michal Hlavinka
Hi all!
I've got quite simple question from dovecot's upstream: Why do we have rw
access on mails for mail group? Why /var/mail/<username> files have 0660
<username>:mail permissions instead of 0600 permissions? The fact is, I don't
know the answer and I'd appreciate your help.
Some facts:
distro | group | perm
---------+-------+---------
Fedora | mail | 0660
Ubuntu | mail | 0600
openSuSE | users | 0600 (user is member of users group)
debian 4.0 | mail | 0660
(Note: This is result of my own investigations on installed systems or
livecds, I don't know if any installed system had changed settings.)
Interesting thing is, that when new user is added to the system, useradd
creates /var/mail/<username> file with <username>:mail 0660 permissions, but
when you delete this file and the user gets new email, this file will be
autocreated with 0600 permissions (still <username>:group owned) and it seems
everything still works.
useradd command comes from shadow-utils and fedora contains no patch changing
permissions to 0660.
The most important question is: Is there anything that requires these files can
be read and written by mail group?
If you have any info regarding this, please share.
Thanks,
Michal Hlavinka
14 years, 5 months
