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
9 years, 9 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 ..."
9 years, 11 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 ..."
9 years, 11 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
10 years
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>
10 years, 1 month
preupgrade from f11 to rawhide broken? python traceback
by Pasi Kärkkäinen
Hello,
I have fully updated Fedora 11 x86_64 system, and when I run
"preupgrade-cli" I get this:
..
..
Saving Primary metadata
Saving file lists metadata
Saving other metadata
Generating sqlite DBs
(process:1779): GLib-WARNING **: GError set over the top of a previous GError or uninitialized memory.
This indicates a bug in someone's code. You must ensure an error is NULL before it's set.
The overwriting error message was: Parsing primary.xml error: Couldn't find end of Start Tag rpm:entry line 99665
Traceback (most recent call last):
File "/usr/share/preupgrade/preupgrade-cli.py", line 305, in <module>
pu.main(myrelease)
File "/usr/share/preupgrade/preupgrade-cli.py", line 270, in main
self.generate_repo(cachedir, comps) # TODO: callback?
File "/usr/lib/python2.6/site-packages/preupgrade/__init__.py", line 651, in generate_repo
misc.generate_repodata(dir,comps,callback)
File "/usr/lib/python2.6/site-packages/preupgrade/misc.py", line 131, in generate_repodata
generate_repodata(dir, comps, callback)
File "/usr/lib/python2.6/site-packages/preupgrade/misc.py", line 148, in generate_repodata_f9
mdgen.doRepoMetadata()
File "/usr/lib/python2.6/site-packages/createrepo/__init__.py", line 829, in doRepoMetadata
rp.getPrimary(complete_path, csum)
File "/usr/lib64/python2.6/site-packages/sqlitecachec.py", line 45, in getPrimary
self.repoid))
TypeError: Parsing primary.xml error: attributes construct error
Known problem? How to fix it?
-- Pasi
10 years, 2 months
Opinions on packaging ATLAS (for the x86 architecture)
by Deji Akingunola
Hi all,
I would like to know your opinion (or any guideline, if it exists) for
the best way to package the ATLAS library for the x86 arch ATM. ATLAS
(Automatically Tuned Linear Algebra Software) basically provides
lapack and blas libraries tuned and optimized for specific cpu
instruction sets, and speed-ups derived from it are very significant.
The library is mostly used for scientific applications, but I've heard
gnome-games also uses it to enhance one of its games.
Currently its packaging for Fedora on the x86_32 arch creates 3
variants (sub-packages) based on the SSE instruction sets -
atlas-sse(1), atlas-sse2, and atlas-sse3, and just recently we gained
the ability to build it for CPUs without SSE. I am trying to decide
which variant to provide as the default one that would be picked to
satisfy atlas library dependency out of the following 2 possibilities;
i). Create a generic x86 'atlas' main package for the P6 architecture,
which is a non-SSE and minimum CPU that Fedora can support ATM.
atlas-sse, atlas-sse2, and atlas-sse3 would then be sub-packages that
users will have to specifically install to benefit from the atlas
optimizations.
ii). According to smolt statistics, cpus with speeds <= 512 MHz (which
is a superset of the non-SSE P6 architecture) is only 0.8% of Fedora
install-base, and cpus with speed >2 GHz (which are subset of SSE2
capable cpus)
are more than 58%. Therefore to support the majority, the main 'atlas'
package will be the sse2 variants, which will provides 'atlas-sse2'
and there will be sub-packages for atlas-no_sse, atlas-sse, and
atlas-sse3.
I personally favour the second option, as I think most people just
installing 'atlas' (who might not have seen the package descriptions)
will likely get the better optimized variant. Right now the
'atlas-sse2' subpackage provides 'atlas', but yum will select the
'atlas-sse' subpackage to satisfy library dependence for libatlas
(shortest name win scenario).
Thanks for your contribution.
Deji
10 years, 2 months