Wouldn't it be a large improvement if supermount was add to kernel 2.6 so people won't have to mount anymore
by lupus
Supermount is a pseudo-filesystem which manages filesystems on removable
media like floppy disks and CD-ROMs. It frees you from need to manually
mount and unmount media.
With supermount, you can change the disk in the drive whenever you want
(with the obvious exception that you shouldn't do it when the filesystem
is actively in use). You don't need to "cd" out of the directory first,
and you don't need to tell the kernel what you're doing --- supermount
will detect the media change automatically.
Supermount will automatically detect whether the media you are mounting
is read-write or readonly, and if you mount a write-protected disk, then
the subfs will be mounted as a readonly filesystem.
Supermount detects when you have finished activity on the subfs, and
will flush all buffers to the disk before completing the operation. So,
if you copy a file onto a supermounted floppy disk, the data will all be
written to disk before the "cp" command finishes. When the command does
complete, it will be safe to remove the disk.
http://supermount-ng.sourceforge.net/
--
lupus (Kristof Vansant Belgium)
20 years, 5 months
Re: QA process was Re: RPM submission procedure
by Toshio Kuratomi
Concerns about the autobuilder downloading a different src.rpm/tarball
than the QA testers can be alleviated (entirely?) by having QA testers
submit hashes of the files they're testing. Then the autobuilder has to
check that the files it's working with match the ones the QA testers
tested.
I agree that QA tester eyeballs aren't necessarily enough (because of
boredom, etc) and that the autobuilder should be resistant to the
package build trying to compromise the machine (because something will
inevitably slip through) but shouldn't QA eyeballs be part of a defense
in depth?
-Toshio
(Forgive my not replying to the thread, I deleted the message before
realizing I had something to say)
--
Toshio <toshio(a)tiki-lounge.com>
20 years, 5 months
Re: Request for Comments: updating RPMs using binary deltas.
by M A Young
Alan Cox wrote:
>Problem 1: Gzip files don't rsync well. bzip2 files I'm not sure of the
>situation. Rusty did work with rsyncable dpkg files and along with Tridge
>hacked up a gzip library that generated slightly larger rsyncable files.
>That change was tested ages ago in rpm and broke stuff so went back out.
>I don't know if anyone ever sat down and debugged it in full
rsync and indeed any other similar program won't work well with compressed
data, and so the rpms need to be uncompressed first.
>Problem 3: Server resources. The rsync computation clobbers the server
>compared to the overhead of just spewing bits. Given people are running
>3000 vsftp sessions in parallel off big servers that is a concern.
There is a feature missing from rsync that would be useful here. It would
be nice if rsync could record a difference between two files, which could
be used later to transform the first file to the second on another
machine. This would be quite a good way to transform an uncompressed copy
of distributed rpm into a later version. In particular the heavy
calculations used to generate rsync differences only need to be done once
on the server. I would have thought that adding this feature to rsync
should be easy (assuming someone hasn't already).
Michael Young
20 years, 5 months
Re: "Official" Companion (was Fedora Core 2 Distribution Size -The separated OS)
by Jef Spaleta
Karsten Wade wrote:
> I had to do some fact checking to be sure this is (mostly) correct.
> Caveat lector: I am writing this as a Fedora docs project member and
> _not_ as a representative of Red Hat, Inc. I.e., I'm a writer, not a
> lawyer. :)
Thank you for the response, that pretty much finishes clearing up
whatever eyebrow raising issues I have with the situation. And the IANAL
advice for avoiding the word 'Official' by anything actually
blessed/produced via the Fedora project in general, seems like a clear
moral imperative to me to shun the use of that word.
I guess my questions about where fedoranews.org fits into the global
view of the community documentation effort is best suited for the
docs-list.
-jef"i wonder if Colin will quote you in the next edition of the news
summary"spaleta
20 years, 5 months
Re: "Official" Companion (was Fedora Core 2 Distribution Size - The separated OS)
by Jef Spaleta
Tom Diehl wrote:
> FWIW when I was in barnes & nobel the other day I saw a book called
> "Fedora Companion" It is by Red Hat Press and contained a 2 CD set of FC1 or
> so the label says. I did not buy it but for those of you wanting a stripped
> down version to install it appears that it is already available. You just
> have to buy the book. :-)
it's actually called "Official Fedora Companion".
And that makes me wonder.... what is the status of the documentation
subproject? I can't help be feel a little miffed that that
a for cost book...an "Official" book...covering things like installing
fedora is coming out before we have a rework of at least the Red Hat
linux install guide...into the Fedora install guide.
I'd personally like to see "Official" status to these sort of for cost
reference resources be withheld until after the documentation subproject
has a chunk of documentation available...in an effort to encourage
writers and editors to contribute to the documentation subproject as a
priority..over individual efforts. Of course, it would do my mind some
good to know that the author of that "Official" companion book is active
in the official documentation subproject as well. But even then, I'm
still not sure I like the idea of deeming for cost resources "Official"
before the official documentation project has at least an install
guide...as a matter of policy to encourage people to work on the
"official" fedora documents.
This isn't exactly a complaint, since i'm not as in the loop on the doc
project as i could be..so my initial negative reaction could easily be
based on ignorance of where things stand. But it did make me raise an
eyebrow, because I want to see documentation coming out of the
documentation subproject be THE priority documentation. If the people
behind the documentation efforts like the "Official Fedora Companion"
book and the tutorials at fedoranews.org aren't contributing directly to
the official fedora doc subproject, that is a problem.
-jef"and wtf? 2 CD install media....thats inconceivable!!!!!!!"spaleta
20 years, 5 months
Missing %defattr in xfsprogs
by Matthias Saou
Hi,
I just noticed with a "yum update" I did today that xfsprogs is missing
%defattr entries for both the main and devel packages, thus I got warnings
about the "bhcompile" user not existing.
Furthermore... there is no "xfsprogs" component for FC in bugzilla yet for
me to file this minor bug under ;-)
Matthias
--
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 1 (Yarrow) - Linux kernel 2.4.22-1.2138.nptl
Load : 0.97 1.04 0.97
20 years, 5 months
RPM submission sanity check
by Bob Billing
Look chaps, I know I'm the newcomer here and all that, but try to see
it my way for a while.
I joined this list because I've written a package. I've been using it
for years to do my own backups - so I know it works. I'd like to enter
into the spirit of the open-source thing by giving it away free.
I'm a little bit mystified by the submission procedure. And the more I
read the submission thread the more mystified I get. While I
understand the need for QA, and can understand why packages ought to
be PGP signed I really would appreciate a few hints about the way I
should go.
For example, do I need to have pre and post install scripts? My little
package contains a C source, a man page, a makefile and a spec file.
Do I need to add other things to get through QA or is that enough?
Would somebody who knows how this works mind pointing me in the right
direction? Thanks.
--
Robert Billing, Tanglewood,
01344-772849 64, Pinehill Road,
rbilling(a)tnglwood.demon.co.uk Crowthorne,
http://www.tnglwood.demon.co.uk/ Berks, RG45 7JR
20 years, 5 months
Re: RPM submission procedure
by Jef Spaleta
Magnus Runesson wrote:
> If the fedora/redhat people want involvement from other people I think
> it is important to inform us how to participate in the "community". As
> long as there are no information about how to help, I can't help.
http://fedora.redhat.com/participate/
<quote>
Right Now
Filing bugs in bugzilla (http://bugzilla.redhat.com/bugzilla/) is the
best way to get changes into packages. You can report problems, request
enhancements, or submit fixes (generally in the form of unified diffs).
You can also contribute by sorting through existing bugs in bugzilla,
confirming their validity or requesting more information for them. You
can particapte in the weekly Wednesday bug days on the #fedora-bugs
channel on freenode IRC, as well.
You can also contribute packages using the process to the older Fedora
Linux project with which the Fedora Project will be merging.
</quote>
http://fedora.redhat.com/about/leadership.html
<quote>
The Merge Team has the "simple" goal to make the merge between the old
Fedora Linux project and the new Fedora Project happen. This includes
policy merges and infrastructure management. This team will be reduced
and reconstituted as the Infrastructure Team once the merge has been
completed. The Merge Team and later the Infrastructure Team will have
participants from inside and outside of Red Hat.
</quote>
It's pretty clear from the available 'Official' documentation that
there is a planned MERGER of what fedora.us IS and what Red Hat WANTS
the Fedora project to be. What exactly is going to change with regard to
merge fedora.us into what will become Fedora Extras has to be discussed.
But fedora.us IS the starting point for that discussion.
-jef"I can NOT stress the idea that everyone needs to read all of the
fedora.redhat.com website like 3 times before really understanding where
things stand on the policy front"spaleta
20 years, 5 months
Re: RPM submission procedure
by Jef Spaleta
> I would certainly prefer it was designed to make it easy for other >
people
> to keep their archive sets compatible. FC1 core doesn't advertise 5 year
> binary compatibility - and doesn't have it, but nobody is proposing to
> completely ignore compatibility and breaking third party repository code.
Too late. If the ideal you are looking for is to preventing breaking
'pre-existing' 3rd party repository structures and processes. It's too
late. Changing the name and the numbering to Fedora Core 1, from the rhl
line has already affected how 3rd parties interpolate. If the ideal is
keep 'pre-existing' 3rd party repository structures from having to do
ANY changes to how they package things...its too late for that
discussion. And frankly in my mind...thats a non-starter discussion to
begin with...simply because 3rd party repos is objective 12..in the
list.
My interpretation of objective (12):
"Create an environment where third party packages are easy to add and
positive encouragement and support exists for third party packaging."
doesn't speak at all the the idea that 'pre-existing' 3rd party
repository efforts are going to interpolate well. My interpretation of
objective 12 is colored by the higher priorties of objectives 4, 6, and
9 which speak to the idea of building a development environment and
toolset for the community to use. I see that toolset as including
technical tools and policy guidelines for 3rd party repositories to
'choose' to use to 'choose' to be compatible with Fedora Core. I
personally don't see making it a priority to bend over backward to make
sure 'pre-existing' repository policies and structures work well with
Core, especially in light of the fact that 3rd party repository and
packaging in objective 12 on a 15 objective list. I'd much rather
concentrate on a comprehensive community packaging standard and policy
that ANY 3rd party could choose to re-implement to ensure being in sync.
If pre-existing 3rd parties feel a heavy burden to continue using their
current policies and procedures to support their established userbase,
then it's going to be unlikely that they will choose to use whatever
development environment comes out of the Fedora process..simply because
their priority list is very out of sync with Fedora's stated
prioritization of things.
-jef
20 years, 5 months
tkill used to implement raise
by Mike Perry
I'm not sure if this is a glibc issue, or a kernel issue, or a
documentation issue.. It seems that raise is implemented as tkill, as
evidenced by the fact that for sigaction handlers, si_code is set to
SI_TKILL for raise()ed signals, when the manpages for sigaction
indicate that raise should cause si_code to be set to SI_USER instead.
I would think that SI_USER is the more standards correct flag to set for
raise.. But who should fix this? I don't remember this being an issue on
my debian system. Is this Fedora specific?
--
Mike Perry
Mad Computer Scientist
fscked.org evil labs
20 years, 5 months