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 put firefox-trunk SRPM based on current fedora rawhide one at
Notice: this package breaks the dependency against devhelp and yelp.
Janina Sajka <janina(a)rednote.net> wrote:
> Does anyone know of any rpm builds of Firefox 3? I'm aware it's nowhere
> near ready for prime time, but I have a compelling reason to start using
> ff3 fairly soon and would rather install from rpm, of course.
> BTW: My compelling reason is that FF3 will contain a11y support that
> should prove superior to any yet seen on any platform. Fingers crossed,
> etc ...
Linux system administrator and developer
I develop /etc/net project (http://etcnet.org) and my goal is to integrate it
into Fedora Core.
I am a member of ALTLinux Team. /etc/net is already integrated into ALTLinux
development tree and should soon be seen in 3.0 version.
I know that ArchLinux has /etc/net in its repository. IDMS Linux did so too,
but i haven't heard from them for last months.
My skills include 6 years Linux experience, several programming
languages, 5 years of mixed software development and system/network
administration and so on, but I guess it's not related much to my goal now.
I have reviewed current initscripts buglist.
Some bugs are not bugs in /etc/net:
#65114 RFE: ifup-aliases iproute support, ifup/ifup-aliases scop...
#75390 it would be nice to tie bandwidth shaping into the networ...
#129820 initscripts maclist patch
#132252 Request for addition of routing rule config file
#132912 No additional IP addresses at ethX without aliased devices
#132925 initscripts use old ifconfig instead of iproute2
#154348 Adds support for WPA (Wi-Fi Protected Access) to the ifup...
#168990 No ifup-gre/ifdown-gre scripts.
#170884 MTU of ethernet card can't be set before interface is up
#171763 Enhancement to initscripts
Some bugs gave me ideas how to improve /etc/net:
#59114 .d-style scripts for ifup/ifdown
#119952 RFE: Add hook for "local" network initialization
#124045 Support setting a metric on interface routes
The whole process, if we don't face some unexpected problems, should take
3 to 6 months. What I need:
1. Ability to advocate patches (sometimes heavy) to about 10-20 FC packages.
2. Probably some help with documentation.
How can we start?
pub 1024D/6D1844F2 2002-11-11
Key fingerprint = AF2F DDAE 7EB3 4699 09FF F0FC 00B1 6D41 6D18 44F2
uid Denis Ovsienko <linux(a)pilot.org.ua>
uid Denis Ovsienko (http://pilot.org.ua) <pilot(a)altlinux.ru>
sub 2048g/57B7ACBE 2002-11-11
I have uploaded my current set of specfiles and parallel-installability patches
for KDE 3.80.3. These build on my live FC6 system, Mock builds for FC5, FC6 and
devel still need to be tested. Note that you'll probably need to export
QA_RPATHS=0x0003 to shut up Mock's rpath checking. (There's actually 2 issues
here: 1. CMake's rpath handling is all or nothing, if you enable rpaths
for /opt/kde4/lib, you also get them for /usr/lib and 2. Mock complains even
about the rpaths in /opt/kde4/lib.) There's another RPM issue too: the
debuginfo extraction doesn't want to do its job on the libraries
in /opt/kde4/lib, whereas strangely it works for the binaries in /opt/kde4/bin.
So you end up with unstripped libraries in the main package and missing
debuginfo sources in /usr/src/debug.
I currently have packages for kdelibs4, kdepimlibs4 and kdebase4. This is what
I'm most interested in, because it's all that's needed to port most KDE apps
(the porting scripts in kdesdk can be helpful, but luckily they're scripts so
you don't have to compile them ;-) ). It would be best if the people most
interested in getting the rest of the packages done (e.g. those who can't wait
for Okular, Ligature or whatever ;-) ) would step in to help getting the rest
Be warned that /opt/kde4/bin/konqueror crashes immediately if you run it
without an argument, but if you give it a URL to open, it works (to some
extent... it's obviously not ready for daily use, this is pre-alpha software
Note that I don't know if the kde4.desktop in /usr/share/xsessions actually
does anything useful, I took that from Chitlesh and fixed the obvious syntax
error, but I haven't tested it, I'm not interested in running full KDE 4
sessions anyway at this stage of KDE development.
My specfiles are here:
I'm refactoring a package (perl module) that needs to build on CentOS4/RHEL4
and FC6/RHEL5. This package depends on GnuPG, whose version changed from
FC3 -> FC6. The change from gpg 1.2 to gpg 1.4 actually means that the tests
(%check) will fail unless I use a different set of test results for the two
I would like to test (in a %if %endif block) which version of GnuPG is
installed on the system. I could run an "rpm --queryformat" command to get
the version, but I was hoping that there is a better way, since rpmbuild
already can check versions of installed packages for BuildRequires.
Lamont Peterson <lamont(a)gurulabs.com>
Guru Labs, L.C. [ http://www.GuruLabs.com/ ]
NOTE: All messages from this email address should be digitally signed with my
0xDC0DD409 GPG key. It is available on the pgp.mit.edu keyserver as
well as other keyservers that sync with MIT's.
Now that the planned release date for F7 is 24 May 2007 (a month after
EOL for FF 1.5) and keeping in mind that FC6 will be supported until
F8T2 (so, say until about September 2007 or so), isn't that going to
cause the need for backporting of fixes to FF 1.5 for about 4 to 5
months? Wouldn't it be better (i.e. less effort) to bite the bullet now
and just upgrade the whole FC6 to FF 2.0?
PS. Yes, I'm aware that similar questions have been asked before, but F7
was on a different schedule then.
I am currently reviewing a Tibetan font for inclusion in Fedora.
It is called Tibetan Machine Uni, and we have had a lengthy
polite discussion on the naming of the package both in and out
of bugzilla, also with the upstream maintainer. (The project is hosted
on SourceForge and GPL fwiw). The package was submitted as
tibetan-machine-uni-fonts, so I suggested fonts-tibetan. However since
the font is also good for Bhutanese, the submitter and the maintainer
think fonts-tibetan-dzongkha (bhutanese) would be more appropriate.
It occurred to me that we really need some guideline about naming of
fonts packages. Most of our international fonts follow the naming
scheme "fonts-*" where "*" is the generally the English name of the
language, which makes the package pretty easy to find. And the
remainder are mostly suffixed with "-fonts". Currently in F7T2 there are:
fonts-ISO8859-2 fonts-KOI8-R fonts-arabic fonts-bengali fonts-chinese
fonts-gujarati fonts-hebrew fonts-hindi fonts-japanese fonts-kannada
fonts-korean fonts-malayalam fonts-oriya fonts-punjabi fonts-sinhala
bitmap-fonts bitstream-vera-fonts dejavu-lgc-fonts ghostscript-fonts
tetex-fonts urw-fonts xorg-x11-fonts
In Extras the fonts tend to be more alternative/miscellaneous I guess:
VLGothic-fonts artwiz-aleczapka-fonts charis-fonts dejavu-fonts
doulos-fonts gentium-fonts hunky-fonts linux-libertine-fonts
mathml-fonts mgopen-fonts terminus-font, and fonts-hebrew-fancy
So perhaps we need to set two naming conventions: using
"fonts-<language>" for standard international fonts and "<name>-fonts"
for alternative general fonts?
Of course "fonts-<language>" doesn't quite solve the problem for the
Tibetan font... ;) The name fonts-tibetan-script was also brought up,
and even fonts-bodic.
It would probably be good to add some text about in on
On 2/22/07, Arthur Pemberton <pemboa(a)gmail.com> wrote:
> And this may or may not be the correct -list for this, but here goes.
> I think its fair to say that a lot of the louder voices on the
> internet do not like Fedora for fair and unfair reasons. My question
> is what does this do to Fedora, and RedHat by association. I can't
> imagine that anything good is coming of this. All the developers here
> are bound by the 24hr daily limit, ie. there is a finite amount of
> work that any developer can accomplish, esp. those not being paid to
> work on Fedora. Making the assumption that all these negative word of
> mouth is bleeding Fedora of contributors, then what's the plan?
First I'd stop making unfounded assumptions about how the contributor
numbers are falling.
There's no real evidence of that at all. We we saw this week was
another chapter of the lack of contribution from the same person, a
person with a long standing personal agenda which is at odds with the
policies of this project, and someone who consistently speaks based on
information which appears to be based on the a view of the fedora
project which is 6 months to a year out of date. At the end of the
day, this was not a suddenly new development, and it was not the loss
of an active contributor. What we have been seeing this week is a
skilled politician using what have become very standard tricks of the
trade. Its messy and its ugly, but anyone whose lived through the
last decade of US national political cycles should recognize it for
what it is. To re-use a phrase, Fedora's been swift-boated. It's
really unfortunate that such political skill has been squandered for
such a petty purpose. I fear for the health of the freespire project
if a board member of that project needs to publicly attack a competing
project via personal letters directly to the press.
But unlike politicians, we aren't gearing up for an election day.
There is no drop-dead date
by which we need to convince a majority of contributors to work with
us for X number of years. That's sort of the great thing about...
community. We don't need to strong arm, or twist the truth, or talk
smack about competing ideas. Fedora does not need to win a decisive
victory at the expense of other community projects. Fedora can
continue to build an active community and continue to make the long
term impact that it needs to make and fulfill its stated mission. All
we need to do is do our best is to be upfront about what this project
is, what its goals are, and to be as encompassing and supportive of as
many people's individual itches inside that framework.
If we wanted to run a counter political campaign, then I would very
much suggest everyone who is interested, write Max Spevack with a
short personal testimony with your positive personal pov as to what
you get out of being a contributor to Fedora. What you feel is
important about Fedora that makes it worth the time. Because that's
what matters. its not the number of contributors, or size of the
codebase, or the size of the userbase. What matters when choosing to
be a volunteer for any organization or project is knowing that by
contributing your time and your talents you are personally growing
from the experience and that your efforts are making a difference.
I'm sure Max won't mind compiling selected testimonials into a PR
piece to counter-balance any further poltical manipulation of the
If we don't attract people who are looking for personal control,
instead of personal growth.. that is a perfectly acceptable outcome to
me. We don't need to attract everybody, niether as a user nor as a
contributor. We need to do our best to attract the people who would
work well inside the scope of the project... and at the same time help
others find projects which fit best for them. Fedora should be the
linux distribution like Progressive is to car insurance. If we aren't
the best choice for you, we'll help you find the distribution that is.
For some outspoken media-savvy people, a position on the freespire
board may very well be the project that fits them best. It's just
unfortunate that it took that person as long as it did to figure that
out. If I regret anything with regard to how this project has treated
said individual, it is that we didn't try hard enough earlier on to
help him find linspire sooner.
Does this project has problems to solve? Absolutely, but the important
ones the Fedora needs to focus on right now have nothing to do with
the screed we saw in the press this week. But every single important
problem that this project faces is the result of growth, and growing
pains can hurt like hell some times.
-jef"Fedora's growing up, soon there will be hair growing on it in
some very sensitive places"spaleta
I don't know if somebody is working on this but I've created a live cd
with KDE for fc6-i386 with the livecd-tools. So far it seems to work
The livecd-files based on the ones from David Zeuthen . I've just
created a config for a kde live spin which requires livecd-base-package.
What I have done:
- created 20-fedora-livecd-kde.conf
- removed most gnome packages and gnome settings
- included kde packages  (just to fill the cd)
- not included gdm to start kdm automatically
- inserted "startkde" in /home/fedora/.xsession
- made autologin for user "fedora" work with kdm
- also set user "fedora" as default and recent user (if somebody logs
out of kde)
- replaced redhat-web.desktop and redhat-email.desktop with "konqueror
--profile webbrowsing" and kmail in kicker (firefox and
evolution are not included)
The size of the cd is actually ~570 MB.
The files to create the live cd could be found here:
Perhaps this could be a start for someone (eg. the KDE-SIG?).