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
With kind regards,
Singapore Synchrotron Light Source (SSLS)
5 Research Link,
Email: slsbdfc at nus dot edu dot sg \or\
didierbe at sps dot nus dot edu dot sg
(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...).
william w. austin waustin(a)speakeasy.net
"life is just another phase i'm going through. this time, anyway ..."
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
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
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
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 ...
william w. austin waustin(a)speakeasy.net
"life is just another phase i'm going through. this time, anyway ..."
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:
I don't mind keeping libopenraw, avrdude and uisp unless anyone
_really_ want to maintain these packages.
I'm looking for some feedback on what I've got so far for the Maintainer
== Maintainer Responsibility Policy ==
=== How long to maintain? ===
13 months from initial release.
=== Belong to the appropriate low-traffic mailing list ===
* Package maintainers will receive important announcements through
the moderated fedora-devel-announce mailing list. Maintainers
will be automatically subscribed to this list. Everyone that is
a primary maintainer of a package in Fedora is also strongly
encouraged to subscribe to the fedora-devel list, though this is
=== Manage security issues ===
* Package maintainer should handle security issues quickly, and if
they need help they should contact the Security Response Team.
=== Deal with reported bugs in a timely manner ====
* 'Nuff said.
=== Maintain stability for users ===
* Package maintainers should limit updates within a single Fedora
release to those which do not require special user action. Many
users update automatically, and if their applications stop
working from no action of their own then they will be upset.
This goes doubly for services which may break overnight.
=== Track dependency issues in a timely manner ===
* In the development tree, and to a small degree in the release
trees as well, updates to packages may cause other packages to
have broken dependencies. Maintainers will be alerted when this
happens, and should work to rebuild their packages with all due
haste. Broken dependencies may leave end user systems in a state
where no updates will be applied. In order to keep the
distribution in a reasonable state, someone will step in and
rebuild packages that have had dependency issues for some time,
but package maintainers should not rely on these rebuilds.
=== Notify others of changes that may affect their packages ===
* Some packages are depended upon by others; in this case, changes
to one package may cause issues for others. Maintainers should
be aware of the effects that changes to their packages may have,
and should alert to the fedora-devel-announce mailing list of
updates which contain ABI or API changes which may cause
dependency problems for other packages. The announcement should
occur a week before the packages update, so all maintainers
affected are notified. The announcement should include the
* Nature of the change.
* Branches (devel, F9, etc.) which will be affected by the
* Expected date of the change.
* List of packages which are affected by the change.
Generally, this is merely the list of packages which
depend directly on the package which is being updated,
and can be found with "repoquery --whatrequires package"
where "package" is the package being updated.
* If your package upgrade breaks other packages in Rawhide, you
should try to help fix the packages affected. For example, when
Python-2.5 was integrated into Rawhide, Jeremy Katz at least
fixed the important packages and queued a rebuild for all the
other packages affected.
=== Miscellaneous Items ===
* Maintainers need to maintain an upgrade path for their
* F(current-1) -> F(current) -> Rawhide
* Packages should be pushed to the Rawhide branch first. If it
builds and works fine for a few days, then it can be pushed to
F(current). If there is a good reason to push it to
F(current-1), it should be done after a few days of being in
Brian Pepple <bpepple(a)fedoraproject.org>
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E
On Tue, 2009-03-10 at 19:41 +0200, Jonathan Dieter wrote:
> Ok, I've been trying this, but how can we tell if the sequence is sha256
> or md5 if we're *just* given the sequence (i.e. applydeltarpm -c -s
> audit-libs-1.7.12-1.fc11-04548395de7d18795d88b32ea98897e90140 where it's
> a sha256 sequence)?
Ok, I've got it. We just check against md5 first, then sha256 if md5
doesn't match. It's not elegant, but it should work fine, especially
since we're only checking for verification, *not* security.
>>>>> "AB" == Andreas Bierfert writes:
AB> During the next hours opensync will be downgraded to version 0.22 in rawhide as
AB> has been discussed on the devel list recently and been prepared for a while by
AB> Adam Williamson and me.
AB> Test packages can be found here  a bug for the downgrade has been opened
AB> here .
AB> This downgrade will mean for all packages which depend on opensync in some way
AB> to be rebuild. If there are questions let me and Adam know.
Is anybody actively working on porting these broken deps in rawhide to
the newly downgraded opensync?
Broken deps for i386
libopensync-plugin-kdepim-0.36-2.fc11.i586 requires libopensync.so.1
libopensync-plugin-syncml-0.35-4.fc10.i386 requires libsyncml.so.0
libopensync-plugin-syncml-0.35-4.fc10.i386 requires libopensync.so.1
libopensync-plugin-vformat-0.36-2.fc11.i586 requires libopensync.so.1
One of the continuous problem with pushing out new sonames I've
observed, is that once they are done the person doing the breaking
tends to forget about the breakage that results if they don't happen
to own the broken packages in question. Obviously the active
maintainer should fix them if possible, but in some cases the person
who is experiencing the breakage may not immediately be aware of what
may need fixing or be able to actual implement the fix.
In these cases it should be incumbent on the person creating the
breakage to assist in all porting and fixing of the package
(e.g. provide a guide to porting, open up bugs on the package with
patches to spec files etc.). If the primary maintainer cannot or will
not fix the package themselves in a timely manner (e.g. in a few days
or a week), they should try to rebuild and push the affect package
themselves (especially if they are a provenpackager). Otherwise there
is a tendency to let the broken packages slide to the point that there
is a rush to fix them just before a freeze and that doesn't give
rawhide testers enough time to see if the API/soname fixes actually
worked in the sense of resulting in functioning software that doesn't
fail in weird ways at runtime.
Let's try and avoid that in this circumstance.
I've had multiple friends & colleagues who have fallen prey to our
occupational hazard of RSI. Some ten years ago or more, I worked on
integrating IBM's ViaVoice for Linux with XEmacs for the benefit of a
couple of XEmacs developers who were suffering from that problem at
the time. Unfortunately, IBM dropped support for its Linux product
while I was still working on the integration.
I'm thinking about working on something like that again, but need a
voice recognition product to work with. I've been looking at CMU
Sphinx  as a possibility, and have made test RPMs out of a few
pieces of that project [2,3,4].
Questions for the list:
Is anybody already working on packaging up some voice recognition product?
Does anybody know of anything more accessible than CMU Sphinx (it
appears to be very powerful, but is definitely not for newbies; also,
not all pieces of it have been released yet)?
Is anybody interested in working with me on getting some voice
recognition product packaged up in usable form on Fedora?