Vic^H^Holunteers needed for updated SATA code testing
by Pekka Pietikäinen
Hiya
Due to popular demand on #fedora-devel, I merged the latest libata code to
the FC1 kernel. This is basically identical to 2.4.22-bk53-libata1.patch.gz,
except for two PCI id's added to sata_promise (0x3376 and 0x3378) and
¤t->sigmask_lock -> ¤t->sighand->siglock in libata-core.c.
Pre-built RPMS + the patches I used (linux-2.4.22-libata.patch
and linux-2.4.22-intel-esb-drivers.patch) can be found from
http://www.ee.oulu.fi/~pp/fc1-libata (sorry, no yum support :-) )
Please test it out and if it works like it should, I'll file a RFE in
bugzilla to get this merged.
Open questions:
- Did I break anything? (the amount of changes in header files I merged from
2.4.22-bk to fc1 like scsi.h were a bit worrying...) Promise 376 + athlon
works ok, and it did compile, so I decided to ship it :-)
- Is the Promise 378 PCI id 0x3378 and does the code work on one?
- driver disk or boot.iso that would let people install FC1 on SATA-only
boxes
--
Pekka Pietikainen
20 years, 4 months
Re: Fedora LiveCD : Looking for Betatesters - Port of redhat 9.0base to fedora core 1
by Jef Spaleta
Alan Cox wrote:
> Sure, and thats one of the big reasons that Fedora is a trademark, so
> it stands for something in terms of quality and protects the name and
> the users.
> However if someone puts together a LiveCD worthy of the Fedora name there
> is no fundamental reason it can't become a "Fedora LiveCD" providing its
> up to it.
Sure, no fundamental reason that this community could not embrace a liveCD or
even several liveCD images that filled specific niche roles (like an
easy bake mosix cluster node.) As long as the software incorporated into
the liveCD was all officially blessed code. I think i even weakly held
out an olive branch about that in my wrap up paragraph. I did most of
the fist pounding in that post because the discussion was veering off
about features that fedora core will not have, like ntfs support were
claiming are prerequisites for a 'useful' demoing liveCD. So their
might not be a fundamental issue with having a blessed liveCD
image...but somehow, given the non-technical constraints, I'm not all
that sure there is going to be a groundswell of community desire to
build a liveCD image that stays within the non-technical constraints
that a trademark blessing would demand. If a demo liveCD image requires
ntfs support, then official demo liveCD image is pretty much a
non-starter. Though fedora branded easy-bake cluster node liveCD would
be..fascinating, though somewhat resource limited if they had to run out
of ramdisk, which would take away from the available ram resources to
run on each cluster node.
-jef
20 years, 4 months
MapiVi - Linux Image Management Software
by Keith G. Robertson-Turner
Image Management Software is a bit thin on the ground in the Linux
world. Apart from Kalbum and Gthumb (neither one of which has IPTC
editing) the only app available seems to be MapiVi (Martin's Picture
Viewer - http://herrmanns-stern.de/software/mapivi/mapivi.shtml
After some considerable effort, I managed to get this installed on
Yarrow, however I'd like to do something to make this available as a
Fedora'ized set of RPMs. The problem is, that MapiVi is dependent on a
number of components that are poorly maintained and almost impossible to
acquire in RPM or even SRPM form.
The Perl module sources I worked from were obtained mainly using the
cpan tool, but if anyone has any links to either RPMs or SRPMs that
install/compile properly under Yarrow, I'd be very grateful.
Here's the components I need, preferably in SRPM form:
MapiVi - I'm working on an RPM now - Work In Progress
libjpeg-6b-29 - With the lossless patch - Done
Image Magick - Included with Yarrow - Done
****
Perl/Tk - Where's the source, Luke? - Lost In Space
Image::Info - Ditto - Ditto
****
Tk::JPEG - Done - Done
Image::IPTCInfo - Done - Done
The Perl/Tk thing has me stumped. Has it been dropped? Is GTk the new
Tk? What is the relationship between Tk, GTk and tcl? What is the
specific reason that Perl/Tk is not a core part of the distro? Is it too
old and crap ... to put it bluntly?
--
Keith G. Robertson-Turner
"The only liberties people have, are those they take."
Palladium is not the solution, it is the problem.
www.antitcpa.com
20 years, 4 months
Bug Day 8: Dec 03,2003: For a change of pace, this reminder is a a day before the actual bugday
by Jef Spaleta
Do NOT be alarmed! Today is not Wednesday! But tomorrow is! and that
means.....
Fedora Bug Day Tomorrow!!!!!!
Theme: A general call to arms, for bugbusting!!!!!
Not really sure there is a specific issue that needs to be addressed
from the community side of things, other than the increasing and
consistent pile-up of packages sitting at fedora.us waiting for
community QA. Or at least developers haven't pulled my ear about it. So
there is no specific bughunting theme.
There are in fact several long term issues that I personally want to
encourage several segments of the community to help me explore in the
bughunting and bug triaging solution space. This is probably going to be
an extremely rambling email.
package maintainers specifically:
*not necessarily tomorrow but as soon as you can find the time....
I'm trying to establish a collection of biolerplate responses that a
crack triage team can use when hunting over reported bugs concerning a
set of packages. My hope is that a triager can save package maintainers
some time, by using a 'stock' reply that maintainers find themselves
using in needsinfo bug reports situations.
http://www.fedora.us/wiki/BoilerPlate.
*please try to run bugzilla queries against the triage comments
http://www.fedora.us/wiki/CannedQueries
i would enjoy feedback on the usefulness or abuse of the triage comment
concept.
everybody else:
*Become involved in the fedora.us QA process and help QA packages that
are waiting to be published in the fedora.us addon repo:
http://www.fedora.us/QA . There are 293 packages sitting waiting for
QA. That's 293 packages the Fedora community could be enjoying in the
published fedora.us repository trees, once they have made it through the
community QA process. Remember, until the full merge is completed and
Fedora Extras and Alternatives is up and running...community packagers
are being advised
to use fedora.us's process. How do you become involved in the fedora.us
QA process? Easy, read:
http://www.fedora.us/wiki/PackageSubmissionQAPolicy
*Help triage the fedora core bugzilla reports by reviewing open bugzilla
bug tickets and trying to use simple comment strings as a way to
categorize bug reports to make it easier for developers to quickly find
bugs that can be marked closed. For more information take a look at:
http://www.fedora.us/wiki/TriageComment
http://www.fedora.us/wiki/CannedQueries
But if you are unsure on how to use the triage comment idea, discussion
in #fedora-bugs on the freenode irc network is encouraged.
*there is also going to be an opportunity for bug triagers to test a set
of xmlrpc bugzilla interface tools, very soon now. I'm not directly
involved with the tool building, but Mr. Nasrat should be sending a
follow up post with some more detailed directions about some example
tools...its all too very exciting for me to talk about in a fashion
approximating coherence.
-jef"all this and only on one cup of coffee"spaleta
20 years, 4 months
Re: new leadership draft being posted...
by Jef Spaleta
Paul Nasrat wrote:
> "Infrastructure Team"
>
> Which isn't detailed in the rest of the document.
Sure it is...in the paragraph describing the merge team:
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.
-jef"still pulling for the official Fedora logo to be 'Scapegoat:the hat
eating goat'"spaleta
20 years, 4 months
python / tkinter interaction
by Chris Wright
Tkinter seems to fail
[root@localhost caw]# apt-get install tkinter
Reading Package Lists... Done
Building Dependency Tree... Done
tkinter is already the newest version.
0 upgraded, 0 newly installed, 0 removed and 0 not upgraded.
[root@localhost caw]# python
Python 2.2.3 (#1, Oct 15 2003, 23:33:35)
[GCC 3.3.1 20030930 (Red Hat Linux 3.3.1-6)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import Tkinter
>>> Tkinter._test()
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "/usr/lib/python2.2/lib-tk/Tkinter.py", line 3118, in _test
label = Label(root, text=text)
File "/usr/lib/python2.2/lib-tk/Tkinter.py", line 2285, in __init__
Widget.__init__(self, master, 'label', cnf, kw)
File "/usr/lib/python2.2/lib-tk/Tkinter.py", line 1780, in __init__
self.tk.call(
SystemError: Py_UNICODE and Tcl_UniChar differ in size
>>>
What's the right place to help sort this out?
cheers
Chris
--
Chris Wright
Medical Director,
ICU Monash Medical Centre
Clayton, VIC AUSTRALIA
20 years, 4 months
Re: CPAN RPM archive?
by Ville Skyttä
[fedora-devel-list back to Cc and quoted in full, I don't know if the
copy was accidentally omitted]
On Mon, 2003-12-01 at 10:50, Stan Bubrouski wrote:
> On Sun, 2003-11-30 at 08:15, Ville Skyttä wrote:
> > Some minor corrections and my IMHO, YMMV status:
> >
> > I haven't really looked into cpan2rpm but I have made some improvements
> > to the perl-RPM-Specfile package (be sure to grab the fedora.us version
> > as all changes have been submitted upstream, but not applied yet).
>
> Good to know, but this is not enough.
I agree. But for whatever reason, since people tend to use these tools
anyway, improving them shouldn't hurt.
> > Anyway, both cpanflute2 and cpan2rpm produce pretty obfuscated
> > specfiles. Instead of using them, there's a bunch of perl-* packages in
> > the www.fedora.us/QA queue (and lots more not-yet-submitted ones at
> > cachalot.mine.nu/1/SRPMS.fdr/) which are based on a template which is
> > based on earlier discussions in bugzilla.fedora.us and fedora-devel at
> > fedora.us list.
> >
> Still there are not enough packages handled to be useful for the masses
> of perl programmers.
But of course not. I have no intention to package the whole CPAN, and I
hope nobody else tries it alone either :) 20-30 modules is pretty
manageable per packager though.
> I myself typically end up requiring 20-30 modules
> for one project alone. This has given me the motivation to pursue this
> fully and I intend to begin the process of creating packages for every
> perl module to start with, then automating building from there.
I have more confidence in packagers continuously cross-QA'ing each
others work than the above (alone). Automating is good whenever it
makes sense though.
> > I've just submitted the specfile template to
> > https://bugzilla.fedora.us/show_bug.cgi?id=1010 for comments.
> > cpanflute2 and/or cpan2rpm could possibly be tweaked more towards this.
> > The main difference currently with the template and cpanflute2 is that
> > the template takes care of removing more unneeded files and bluntly
> > works around the unowned dirs issue in the past and current RH and FC
> > perl packages,
> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=73970
> >
>
> I'm past thinking of using those automated cpan2rpm type tools. I've
> gotten enough response where I feel that we need to handle each package
> individually and build a repository from there.
+1
> Contributions are more than welcome (of spec files of course).
> ATRPMs is willing to accept
> submissions, which works for me. In the meantime I can host a testing
> repository for packages until something more formal is worked out.
I'm personally more comfortable with the fedora.us process, it has been
designed for submissions and has almost all the building blocks in place
already, even if there are some rough edges here and there.
> > For some weird reason, even though perl module packages (especially when
> > a template is consistently used) are trivial to review, the QA process
> > seems to take a long time. Help is certainly welcome in this area.
> >
>
> It's not wierd at all.
Let me rephrase: I find the (lack|rarity) of reviews weird, given that
interested folks certainly exist.
> It takes a long time to ensure that everything
> in a perl CPAN module is handled correctly. And correctness is exactly
> what I'm striving for. Little bugs will not do. My intention is to get
> this started right from the get-go, that means cpan2rpm for instance
> is out. Individual spec files need to be made for each module initially
> (although a template would be great for about half, and if you can help
> with this please let me know). I appreciate any and all help, afterall
> we are a community (feel free to make suggestions or call me an idiot, I
> thrive off of criticism) ;-)
Well, we seem to have similar goals. I'd suggest taking advantage of
the fedora.us submission/QA procedures at least until the corresponding
fedora.redhat.com is completely up and running.
20 years, 4 months
FC1 tag in ethereal-0.9.16-2.FC1.1.i386.rpm
by Nathan Grennan
I don't like the idea of adding the FC1 tag to future updates, and
would love to see this update get replaced with an untagged version.
Anyone have any information or comments on this?
20 years, 4 months
Self-Introduction: Ian Kent
by Ian Kent
Ian Maxwell Kent
Australia, Perth
Profession: Computing - Infrastructure and Operations
Company:
Woodside Energy - on contract via Icon Recruitment
I don't speak for Woodside, Open Source development
is a part time activity for me.
Goals here:
1) As maintainer of the autofs v4 package I would like
to see my package included in Fedora and hopefully
have it migrated into the RedHat Professional
distribution.
2) Have my autofs4 kernel module patch (supporting
above package) into the distribution kernel.
3) Have the QA system of Fedora help with the testing
of above packages.
Historical qualifications:
None really!
Languages are C, Perl, Fortran and a little C++ and Java.
Trust me? Well you will have to work that out for yourselves.
There is no reason not to trust me. I have contributed
considerable time to my automounter project over the last
couple of years and would like to see a wider audience
take advantage of the enhancements I have made.
GPG KEYID:
pub 1024D/D4BEE989 2003-09-03 Ian Kent <raven(a)themaw.net>
Key fingerprint = E16B E1A9 F99B 3413 B903 613C 7966 66EC D4BE E989
sub 1024g/42074EC9 2003-09-03
--
,-._|\ Ian Kent
/ \ Perth, Western Australia
*_.--._/ E-mail: raven(a)themaw.net
v Web: http://themaw.net/
20 years, 4 months
