atmel drivers in the main distro?
by Martin Sevior
Hi folks,
I don't know if you've covered this issue already, but I didn't
see it in a google of the devel list.
Is there a reason the atmel wireless drivers are not distributed with the
main Fedora disto?
I have a Belkin wireless card that works beautifully with the atmel
drivers from
http://atmelwlandriver.sourceforge.net
Once compiled against the Fedora-1 kernel.
If these aren't in the next Fedora release I suggest they should be.
Cheers
Martin Sevior
20 years, 1 month
apt-get / mach problems
by Erik LaBianca
Hi All,
In an attempt to put my money where my mouth is, I'm attempting to do
some more QA and write up a streamlined getting started guide. I'm
working on putting together a straightforward way to test buildrequires.
I've patched mach so that it will attempt to install perl(*)
buildrequires, and it more or less works.
However, mach rebuild (and apt-get) fails on the following command:
[erik@mises SPECS]$ sudo apt-get install 'perl(Digest::SHA1)'
'perl(Digest::Nilsimsa)'
Reading Package Lists... Done
Building Dependency Tree... Done
Selecting perl-Digest-SHA1 for 'perl(Digest::SHA1)'
Package perl(Digest::Nilsimsa) is a virtual package provided by:
perl-Digest-Nilsimsa 0:0.06-0.fdr.4.1
You should explicitly select one to install.
E: Package perl(Digest::Nilsimsa) has no installation candidate
Now. You'll notice perl(Digest::SHA1) resolves just fine. However apt
thinks there are multiple perl(Digest::Nilsimsa) packages available,
although it only lists one. Whats going on here? How can I resolve this?
Obviously, I could replace all the buildrequires with explicit ones, but
I've gotten the impression that is NOT the cool way to solve this
problem.
I also tried to manually solve the problem using
mach apt-get install perl-Digest-Nilsimsa
mach rebuild ~/rpm/SRPMS/perl-Razor-Agent-2.36-0.fdr.6.src.rpm
and it STILL tries to install the perl(Digest::Nilsimsa) package and
fails. I mustn't be understanding something about mach in this case...
what?
I don't see anything particularly wrong with the perl-Digest-Nilsimsa
package:
[erik@mises SPECS]$ sudo apt-get install perl-Digest-Nilsimsa
[erik@mises SPECS]$ rpm -qi --provides perl-Digest-Nilsimsa
Name : perl-Digest-Nilsimsa Relocations: (not
relocateable)
Version : 0.06 Vendor: Fedora Linux
Release : 0.fdr.4.1 Build Date: Sun 18 Jan 2004
03:33:46 AM EST
Install Date: Tue 02 Mar 2004 11:18:21 AM EST Build Host:
bmaster.fedora.us
Group : Development/Libraries Source RPM:
perl-Digest-Nilsimsa-0.06-0.fdr.4.1.src.rpm
Size : 47837 License: GPL
Signature : DSA/SHA1, Sun 18 Jan 2004 03:38:26 AM EST, Key ID
29d5ba248df56d05
Packager : Fedora Linux, <http://fedora.us>
URL : http://search.cpan.org/dist/Digest-Nilsimsa/
Summary : Perl interface to the Nilsima Algorithm
Description :
Perl interface to the Nilsima Algorithm.
Nilsimsa.so
perl(Digest::Nilsimsa) = 0.06
perl-Digest-Nilsimsa = 0:0.06-0.fdr.4.1
Help please! :)
Thanks
--erik
20 years, 1 month
rawhide report: 20040228 changes
by Build System
New package gnome-netstatus
Network status applet
New package perl-RPM-Specfile
RPM-Specfile Perl module
New package perl-XML-LibXML-Common
XML-LibXML-Common Perl module
Updated Packages:
XFree86-4.3.0-61
----------------
* Fri Feb 27 2004 Mike A. Harris <mharris(a)redhat.com> 4.3.0-61
- Added XFree86-4.3.0-keyboard-disable-ioport-access-v3.patch as a final patch
without debug logging enabled, to fix (#115769)
- Added spec file macro 'with_savetemps' for debugging purposes, disabling it
by default. When used, it is set up to only get used on x86 for
build_rawhide and build_psyche builds
- Added XFree86-4.3.0-ati-ia64-no-nonpci-ioport-access.patch to fix ati driver
issue on ia64 which causes IBM x455 system to machine check. Also added
"#define ATIAvoidNonPCI YES" to host.def to activate this fix only on ia64
builds (#112175)
* Wed Feb 25 2004 Mike A. Harris <mharris(a)redhat.com> 4.3.0-60
- Added XFree86-4.3.0-keyboard-disable-ioport-access-v2.patch to try to
fix (#115769)
- Changed mkxauth to call chown as foo:bar instead of foo.bar as the latter
syntax has been deprecated
- Added XFree86-4.3.0-minor-typo.patch to fix a trivial typo that I spotted
in an error message in linux int10 code.
- Remove Buildrequires kudzu-devel, pciutils-devel, both of which were added
on Mar 21, 2001 when Glide3 was included in the XFree86 packaging, but are
no longer necessary. I detected this when the buildsystem failed my build
due to being unable to meet the dependancy on kudzu-devel, and further
investigation showed that dependancy is no longer necessary.
- Added XFree86-4.3.0-xcursorgen-check-malloc-return.patch to make xcursorgen
check the return codes on malloc before referencing allocated memory
- Added XFree86-4.3.0-redhat-xcursorgen-do-not-build-included-cursors.patch to
stop building the XFree86 supplied Xcursor cursors as we do not ship them
* Thu Feb 19 2004 Mike A. Harris <mharris(a)redhat.com> 4.3.0-59
- Added XFree86-4.3.0-xrandr-manpage-typo-fix.patch to fix manpage (#83702)
- Added XFree86-4.3.0-radeon-9200-dvi-snow.patch to fix issue on Radeon 9200
when using DVI panel and encountering snow and other artifacts (#112073)
- Updated XFree86-4.3.0-debug-logging-ioport-based-rate-setting.patch to have
it patch both lnx_kbd.c and lnx_io.c because both files insanely contain
identical cut and pasted copies of the exact same source code, so nothing
shows up in the X server log when testing with previous patch as the calls
never got invoked in lnx_kbd.c (#115769)
gail-1.5.6-1
------------
* Wed Feb 25 2004 Alexander Larsson <alexl(a)redhat.com> 1.5.6-1
- update to 2.5.6
gimp-print-4.2.6-8
------------------
* Fri Feb 27 2004 Tim Waugh <twaugh(a)redhat.com> 4.2.6-8
- Fixed dither algorithm selection (bug #116516).
- Fixed another plug-in crash.
glibc-2.3.3-12
--------------
* Fri Feb 27 2004 Jakub Jelinek <jakub(a)redhat.com> 2.3.3-12
- update from CVS
* Fri Feb 27 2004 Jakub Jelinek <jakub(a)redhat.com> 2.3.3-11
- update from CVS
- fix ld.so when vDSO is randomized
gnome-applets-2.5.6-1
---------------------
* Thu Feb 26 2004 Alexander Larsson <alexl(a)redhat.com> 1:2.5.6-1
- update to 2..5.6
gnome-panel-2.5.90-1
--------------------
* Fri Feb 27 2004 Mark McLoughlin <markmc(a)redhat.com> 2.5.90-1
- Update to 2.5.90
- Resolve conflicts with the lockf patch and re-work slightly
gstreamer-plugins-0.7.5-1
-------------------------
* Fri Feb 27 2004 Alexander Larsson <alexl(a)redhat.com> 0.7.5-1
- update to 0.7.5
* Fri Feb 13 2004 Elliot Lee <sopwith(a)redhat.com>
- rebuilt
gtk2-2.3.4-1
------------
* Wed Feb 25 2004 Mark McLoughlin <markmc(a)redhat.com> 2.3.4-1
- Update to 2.3.4
- Remove the xft-prefs patch, its upstream now
- Don't kill libtool's hardcode_libdir_flag_spec anymore
im-sdk-11.4-19
--------------
* Fri Feb 27 2004 Akira TAGOH <tagoh(a)redhat.com> 1:11.4-19
- im-sdk-11.4-canna-no-process-unrelated-keys.patch: applied to allow working
unrelated keys during no preediting. (#114002)
- im-sdk-11.4-canna-draw-off-status.patch: fixed crash issue.
kernel-2.6.3-1.116
------------------
* Fri Feb 27 2004 Dave Jones <davej(a)redhat.com>
- Update to 2.6.4-rc1
- Re-enable Future Domain SCSI controller.
libaio-0.3.98-2
---------------
* Thu Feb 26 2004 Jeff Moyer <jmoyer(a)redhat.com> 0.3.98-2
- bah. fix version nr in changelog.
* Thu Feb 26 2004 Jeff Moyer <jmoyer(a)redhat.com> 0.3.98-1
- fix compiler warnings.
* Thu Feb 26 2004 Jeff Moyer <jmoyer(a)redhat.com> 0.3.97-2
- make srpm was using rpm to do a build. changed that to use rpmbuild if
it exists, and fallback to rpm if it doesn't.
pam-0.77-36
-----------
* Thu Feb 26 2004 Dan Walsh <dwalsh(a)redhat.com> 0.77-36
- fix tty handling
* Thu Feb 26 2004 Dan Walsh <dwalsh(a)redhat.com> 0.77-35
- remove tty closing and opening from pam_selinux, it does not work.
* Fri Feb 13 2004 Elliot Lee <sopwith(a)redhat.com>
- rebuilt
policy-1.6-13
-------------
* Fri Feb 27 2004 Dan Walsh <dwalsh(a)redhat.com> 1.6-13
- Add Russell etc_domain stuff
* Thu Feb 26 2004 Dan Walsh <dwalsh(a)redhat.com> 1.6-12
- Fix fd inheritance
* Thu Feb 26 2004 Dan Walsh <dwalsh(a)redhat.com> 1.6-11
- fix locate
rpm-4.3-0.16
------------
* Wed Feb 25 2004 Jeff Johnson <jbj(a)jbj.org> 4.3-0.15
- serialize rpmtsRun() using fcntl on /var/lock/rpm/transaction.
rpmdb-fedora-1.90-0.20040228
----------------------------
sound-juicer-0.5.10.1-3
-----------------------
* Fri Feb 27 2004 Brent Fox <bfox(a)redhat.com> 0.5.10.1-3
- rebuild
20 years, 1 month
Thoughts on Eric Raymond's Insights
by Jonathan Gardner
I'm thinking of how we as a Fedora team can take the ball that ESR has
identified -- REAL usuability -- and runn with it in a meaningful way.
Here at Fedora, we are really 2 teams. There are the "Morlocks" who are
underground, fixing things, pulling magical levers and making things work
-- generally subscribed to fedora-dev and fedora-test, and several other
technical mailing lists -- and the "Eloi" who maybe make it as far as
actually getting Fedora installed and subcribe to fedora-list.
We need to bridge the gap between the two!
Here's the proposal. We do real usuability studies. But we do it the "open
source" way.
Everyone is a volunteer.
We recruit the users (the "Eloi") and ask them to choose a project they are
interested in, and we hook them up with those specialists.
We recruit some more-technically minded people (the "Morlocks") and have
them develop some usuability plans. These people should not be testers or
developers, but people who understand the software or have the ability to
communicate productively with the authors of the software.
A third set of people will actually engage with the end-users in one-on-one
sessions, following the plans that were developed. They don't have to be
experts in that particular piece of software, they just have to be good at
leading these sessons. The two have to communicate either by phone or by
IRC, or some other instant communication method.
The usuability sessions will be made public, so that other unrelated
projects can derive some benefit from them. We'll allow others who know
more about this kind of thing to comment on the results, summarize it for
the developers, identify the problems and suggest solutions. Then the
developers and testers can use this to develop the software for the end
users.
With enough data, we should be able to identify the biggest problems and
work to solve them before FC3. Then, when FC3 comes out, we can do this all
over again.
The only problems I see are getting people involved and working with each
other. I worry that while we will be able to get participants, those will
always be the *wrong* people we are trying to target. However, never
underestimate the amount of data that one session can produce! So maybe we
don't need that much to actually happen.
Thought, ideas? Should we form a Fedora usuability group to tackle this?
--
Jonathan Gardner
jgardner(a)jonathangardner.net
20 years, 1 month
Re: Thoughts on Eric Raymond's Insights
by Jef Spaleta
Jonathan Gardner wrote:
> Everyone is a volunteer
Everyone is a potential volunteer. You included.
> We recruit the users (the "Eloi") and ask them to choose a project
> they are interested in, and we hook them up with those specialists
Have you looked at the fedora.redhat.com project pages...that looks
like a recruitment effort to me..based on each project. Or are you
talking about hiring a brass band and marching around or something
similar? Recruitment efforts on a lot of fronts are in need of creative
ideas. By the way, for anyone reading fedora.us QA review needs
volunteers. So does the Fedora Core community triage effort, find me on
#fedora-bugs on the irc network if you are interested in helping out
with either of those efforts....
> We recruit some more-technically minded people (the "Morlocks") and
> have them develop some usuability plans. These people should not be
> testers or developers, but people who understand the software or have
> the ability to communicate productively with the authors of the
> software
Have fun trying to identify the people who can do that well.
> A third set of people will actually engage with the end-users in one-
> on-one sessions, following the plans that were developed
Are you keeping a running count in your head about the number of people
you are talking about...and how much time you really expect these
volunteers to contribute consistently? One on One sessions are expensive
in terms of manhours...and you don't have anyone signed up yet..so your
total number of manhours to spend are zero. Don't start building a
process that is manpower expensive..until you have manpower to burn...
you are going to kill the process under its own weight before you even
get someone to volunteer.
> The usuability sessions will be made public, so that other unrelated
> projects can derive some benefit from them
A more cynical view is that, making it public will provide other
'potential' volunteers the opportunity to rip apart your methodology and
reinterpret the result to prove the result you derived from the sessions
are invalid....be careful what you wish for.
> We'll allow others who know more about this kind of thing to comment
> on the results, summarize it for the developers, identify the problems
> and suggest solutions
Unless you have a commitment from the developers to buy into the
methodology that forms the basis of the summaries...this is just going
to lead to a lot of argument. I tell you right now, that you aren't
likely to win over development mindshare just by handing them a
usability summary without their involvement with outlining at least the
methodology you layout. If you are going to experiment with this, you
should first find a project with developers who are open to working with
you on this to see if it really will be helpful. Pushing the summaries
on developers for a project if they aren't interested..is not going to
help.
> With enough data, we should be able to identify the biggest problems
> and work to solve them before FC3. Then, when FC3 comes out, we can do
> this all over again.
This is a very hopeful hypothesis. And I would argue, that the biggest
problems will be defined differently by different segments of the
userbase. It will be interesting how you build a process that matches
biggest problems...to specific usage patterns...in an unbiased manner.
It will be interesting to see how you guard against having your
summaries being biased by a small vocal minority.
> The only problems I see are getting people involved and working with
> each other. I worry that while we will be able to get participants,
> those will always be the *wrong* people we are trying to target
There are LOADS of problems...loads and loads...
i like this handbook on volunteerism
http://www.sport.vic.gov.au/Web/SRV/srvimages.nsf/Images/VMPWorkbookpdf/
$File/VMPWorkbook.pdf
The summary on the first 18 pages are so, is generally useful as a
guideline for any volunteer process...
> However, never underestimate the amount of data that one session can
> produce! So maybe we don't need that much to actually happen.
the amount of data isn't the question, I fear for the quality of the
data, and whether what you will be producing is something the developers
want.
Maybe if you rethink this idea assuming you only have 3 or 4 people who
are energized about working on the problem you see, and think about a
process that can produce a result with just 3 or 4 people's worth of
volunteer time. Think usability strike team, instead of usability
batalion,
-jef"is still looking for someone to head up an accessibility strike
team"spaleta
20 years, 1 month
Multiboot with linux server, fedora and w2k server
by Tat Nam
Hi,
I've a hard drive of 60GMB and have already installed Windows 2000 server
and Linux 9 server. GRUB is the boot loader. Recently, I bought a new hard
drive of 120GMB in size and installed it into the system in order to install
Fedora project. I intended to make the system to make a multiboot and
enable me to select among W2K server, Linux 9 server and Fedora.
However, all papers on the net talking about dual boot, does anybody
have a method to do the multiboot with GRUB?
Thanks in advance.
--
Nam, Tat
20 years, 1 month
KDE3.2.1 and a Japanese locale
by Tadashi Jokagi
Hi,
To warren, KDE maintainer and developpers.
There were the following reports from a KDE Japan user group.
KDE 3.2.1 will be release-planned next week.
A Japanese locale is contained in 3.2.1.
A Japanese locale is *not* contained in 3.2.
Fedora Core 2 adopts KDE 3.2.
However, use of this version displays neither a menu nor a message in Japanese in a KDE desktop.
It seems that the Japanese locale is using 3.1.95 now.
The Japanese locale of this version is not so good.
Is there any idea of management about this problem?
The KDE Japan user group tried hard in order to make a better thing by the appeal of warren.
Can Fedora Project cooperate in it?
--
----.----1----.----2----.----3----.----4----.----5----.----6----.----7
Tadashi Jokagi/Shibuya city mailto:elf@elf.no-ip.org
YokukitanaII http://elf.no-ip.org/
Yokukitawiki http://elf.no-ip.org/wiki/
Yokukitablog http://elf.no-ip.org/blog/
20 years, 1 month
Old gcc directories still on system
by George Garvey
Currently, the system has gcc-3.3.3-2 installed. This is what is on the
disk (I've excluded 3.2.3 and 3.3.3 -- why are these directories still
there?):
/usr/lib/gcc-lib/i386-redhat-linux:
total 16
drwxr-xr-x 3 root root 4096 Feb 18 04:08 3.2.3
drwxr-xr-x 3 root root 4096 Oct 25 10:30 3.3.1
drwxr-xr-x 3 root root 4096 Mar 1 14:39 3.3.2
drwxr-xr-x 5 root root 4096 Mar 1 14:01 3.3.3
/usr/lib/gcc-lib/i386-redhat-linux/3.3.1:
total 4
drwxr-xr-x 2 root root 4096 Oct 25 10:30 include
/usr/lib/gcc-lib/i386-redhat-linux/3.3.1/include:
total 0
/usr/lib/gcc-lib/i386-redhat-linux/3.3.2:
total 4
drwxr-xr-x 2 root root 4096 Mar 1 14:38 include
/usr/lib/gcc-lib/i386-redhat-linux/3.3.2/include:
total 0
20 years, 1 month
Re: Fedora Core 2 Test 2 - delayed
by Jef Spaleta
Vincent wrote:
> The code is fine but it deserves the extra scrutiny it is getting.
The code is getting scrutiny on this list? At best what we are seeing
here is derision, but certainly no comments on this list count as
code scrutiny. So maybe its best to say the code deserve the extra
scrutiny it has gotten upstream already before the decision to include
in the 2.6 kernel codebase was made, instead of talking about the lack
of scrutiny its currently getting on this list. No one here, on this
list, is adding anything of merit to the analysis of the codebase.
-jef"maybe open source developers should create bogus code and license
it under a license that is friendly to proprietary consumption....to
hasten the endgame scenario of propetary software development"spaleta
20 years, 1 month
Fedora for IA-64 ?
by Lucas Peetz Dulley
Hi everyone,
How is the development on Fedora for Ia-64?
Here at our lab we received a brand new Itanium2 machine with MegaRaid
We want run Fedora on it :)
I wanna help in the development of Fedora for IA-64. What should I do?
How can I help?
--
Lucas Peetz Dulley <dulley(a)lsi.usp.br>
Virtual Reality Center - CAVERNA Digital
LSI - POLI - USP Tel: +55-11-3091-5374
Av. Prof. Luciano Gualberto, 158 trav. 3
CEP: 05508-900 - Sao Paulo - SP - Brazil
20 years, 1 month