Tripwire Update ...
by Keith G. Robertson-Turner
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Good news ...
I've tracked down the installpath bug (some nasty hard coded references
that blatantly ignored opts) so phase one is now complete.
Phase two is post-install scripts for baseline configuration. ETA - one or
two days depending on how much free time I've got.
I'm estimating this whole project will be wrapped up in a week.
- -
Keith G. Robertson-Turner
tripwire-devel at genesis-x.nildram.co.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE/wiPm2XoLj+pGfn8RAk1gAJ93cfYKx0DDoLabn7e4G6BvRJO1AACeMRO8
7ERAAfhoCnbtIC0RK/C9FUM=
=TIyq
-----END PGP SIGNATURE-----
20 years, 5 months
Question about Development
by Anthony Saffer
Hello Everyone,
As most of you know, I am a developer looking for a project. A few weeks
ago, I had decided to sign up and do the GUI Cron scheduler. I was going to
do it in Perl/Tk but was told (with good justification) that using Tk was
really unacceptable for a number of reasons. Well, I've not given up on the
cause! Would anyone have a problem with software being developed in wxPerl
(Wx with Perl bindings)? If not, I'm going to sign up to do a project
tonight.
Anthony Saffer
Miami, OK
=======================================
SCS Consulting Services
Professional Software and Website Development
Affordable Webhosting also Available
Visit: http://www.safferconsulting.com
=======================================
20 years, 5 months
Self-Introduction: Brian Pepple
by Brian Pepple
Name: Brian Pepple
Home: Columbus, OH USA
Profession: IT
Company: None (In-between jobs)
Goals: Help contribute to Fedora. I was working today on an rpm for the
gkrellmms plugin, and figured I would share my work.
Qualifications: Experience with C, Perl, Python. Previously worked at a
Fortune 500 company.
GPG Fingerprint:
pub 1024D/810CC15E 2003-10-03 Brian Pepple <bdpepple(a)ameritech.net>
Key fingerprint = BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C
C15E
uid Brian Pepple <bdpepple(a)yahoo.com>
sub 2048g/A55D2357 2003-10-03 [expires: 2008-10-01]
Thanks,
/B
--
Brian Pepple <bdpepple(a)ameritech.net>
20 years, 5 months
RE: Package tree structure
by marc.miller@amd.com
What is i386_64? Is that what the rest of the world is calling amd64 and x86_64? If so, why that name?
-----Original Message-----
From: David Farning [mailto:dfarning@sbcglobal.net]
Sent: Monday, November 24, 2003 12:26 PM
To: fedora-contacts
Subject: Package tree structure
I am currently working on a channel system for system-config-packages
similar to the one used by red-carpet.
As such, I would like verify the intended download.fedora.redhat.com
hierarchy.
The root level will contain the overall package sets.
[core|extras|alternatives|3rd party|...]
Each of these package sets will contain subsets of packages in different
states of development. The numbered release will freeze at
approximately 2-3 month intervals. Development and Testing are rolling
releases.
[1|2|...|development|test]
Each of these Releases may be compiled for a number of archs.
[i386|i386_64|...]
Additionally, the numbered release will have updates and possibly legacy
packages. Updates will continue for approximately 12 months and the
legacy will continue as long as maintainers are interested
[updates|legacy]
This should result in a tree looking as such.
fedora
-core
-1
-i386
-i386_64
-updates
-i386
-legacy
-i386
-2
-i386
-i386_64
-development
-i386
-i386_64
-test
-i386
-
-extras
-1
-i386
-2
-i386
There is already some deviance from this tree
with
-core
-updates
-1
-testing
Because each numbered release will contain updates, updates should be a
child of it's numbered parent. -updates/test either needs to merge into
-test or -1/updates.
I don't intended to too uptight, but setting standards will help make
the tree more navigable for everyone.
Thanks
Dave Farning
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list
20 years, 5 months
Package tree structure
by David T Farning
I am currently working on a channel system for system-config-packages
similar to the one used by red-carpet.
As such, I would like verify the intended download.fedora.redhat.com
hierarchy.
The root level will contain the overall package sets.
[core|extras|alternatives|3rd party|...]
Each of these package sets will contain subsets of packages in different
states of development. The numbered release will freeze at
approximately 2-3 month intervals. Development and Testing are rolling
releases.
[1|2|...|development|test]
Each of these Releases may be compiled for a number of archs.
[i386|i386_64|...]
Additionally, the numbered release will have updates and possibly legacy
packages. Updates will continue for approximately 12 months and the
legacy will continue as long as maintainers are interested
[updates|legacy]
This should result in a tree looking as such.
fedora
-core
-1
-i386
-i386_64
-updates
-i386
-legacy
-i386
-2
-i386
-i386_64
-development
-i386
-i386_64
-test
-i386
-
-extras
-1
-i386
-2
-i386
There is already some deviance from this tree
with
-core
-updates
-1
-testing
Because each numbered release will contain updates, updates should be a
child of it's numbered parent. -updates/test either needs to merge into
-test or -1/updates.
I don't intended to too uptight, but setting standards will help make
the tree more navigable for everyone.
Thanks
Dave Farning
20 years, 5 months
Tripwire news
by Keith G. Robertson-Turner
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I'm currently working on Tripwire for Fedora.
Proposed release: tripwire-2.3.1-18 (currently alpha)
The status so far is:
Currently implemented:
tripwire-2.3.1-2 source (clean)
rfc822 patch
mkstemp patch
Paul Herman's patch (<=GCC3.3, OpenSSL, STLport and others)
Not implemented:
fhs patch (broken, possibly obsolete, untested)
jbj patch (broken, possibly obsolete, untested)
gcc3 patch (obsolete)
Build environment:
FC1
(2.4.22-1.2115.nptl)
GCC3.2.3
Build status:
Built (target i386), installed, tested. All ok. 22-Nov-03.
All that remains now is the packaging, something that I'm not particularly
good at, however I'm working on it.
To do:
Post-install scripts for baseline configuration.
Fix weirdness with wrong paths in install.
(Currently I'm hard coding paths, rather than using variables)
RPM packaging and testing.
If anyone desperately needs this alpha copy now, please contact me, but be
warned there is zero post install configuration, so you will need to do
this manually. Sorry, but I won't have any time to help you with
configuration.
As you've probably guessed, I'm working from a clean source, rather than
Red Hat's src.rpm. The difficulty is that Red Hat's specs and scripts are
just way too heavily modified and complex for me to work with. As I said,
I'm not great at packaging, so starting from scratch was just a lot easier.
I've been working on this for precisely 3 hours, so don't expect a final
release soon.
Any help (scripts & packaging) would be greatly appreciated.
- -
Keith G. Robertson-Turner
tripwire-devel at genesis-x.nildram.co.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE/v6SW2XoLj+pGfn8RAgWOAJ9YMNLiqpRvw1/76EW4hghH2HXDfQCdHRfD
xYYis9VeF7DkYTcRP8y61jQ=
=C8Ws
-----END PGP SIGNATURE-----
20 years, 5 months
Re: Executable memory: further programs that fail
by Jef Spaleta
Chuck Wolber:
> Thank God that's not the case, otherwise the 2.6 kernel would never
> come out... (referring to the fact that a few changes to 2.5/2.6 broke
> nearly *ALL* loadable modules at one time)
Comparing a kernel feature that doesn't work for nearly all modules
to a kernel feature that maybe affects 1% of binary applications( which
could be argued are doing technically 'illegal' tricks with regard to
the memory space ) .... is a bit of a stretch.
-jef"if only i knew how to prevent shantytowns from appearing in
lincity"spaleta
20 years, 5 months
little patch for kallsyms (kernel2.6) (package : initscripts)
by lupus
#kallsyms is used in kernel 2.6 instead of ksyms
#should the logs off kallsyms be written to /var/log/ksyms.$i or to
/var/log/kallsyms.$i or maybe even both
#to keep compatibility with programs that read these files?!
Kristof Vansant (Belgium)
20 years, 5 months
rawhide report: 20031124 changes
by Build System
Updated Packages:
rpmdb-fedora-1.90-0.20031124
----------------------------
sane-backends-1.0.13-1
----------------------
* Sun Nov 23 2003 Tim Waugh <twaugh(a)redhat.com> 1.0.13-1
- 1.0.13.
- No longer need autoload, gt68xx patches.
20 years, 5 months