repeated key press events?
by Alexandre Oliva
I've been experiencing a somewhat annoying problem on Severn, on both
my desktop and laptop: sometimes, when I press a letter (or number,
arrow, whatever), without holding it, I get, instead of just one
letter, 5-20 copies of the letter (or number, cursor movement,
whatever :-)
Is anyone else experiencing this? I'd like to file this in bugzilla,
but I'd like to make sure the keyboards didn't decide to both start
failing in this odd way at the same time.
--
Alexandre Oliva, GCC Team, Red Hat
20 years, 9 months
RHN Updates
by Matthew Winter
Hi,
Since RedHat has now moved to a community based RHL project, in general
this means no more support. RedHat however will not want to loose this
revenue source, however small it might have been.
I would like to see RedHat enhance the RHN into a subscription based
Package Install / Update / Search system.
Something cross between Synaptic, the Lindows Click2Run and the current
RHN update facility.
I for one would subscribe to such a service, to guarentee that packages
have been properly compiled for a specific release of RHL, and tested.
I also think that the software should allow you to choose from Stable
and Test releases. Allowing a user to decide what they want to install.
Having such a tool would improve the value of the RHN, and provide
RedHat and the community with a means to test packages before the next
Beta ISO is released.
Just my 2 pence worth on the subject.
Matthew
20 years, 9 months
ldapmigrate
by Justin Clacherty
Dax,
I tried to use the ldapmigrate script you wrote but it is giving errors
when I run it. I expect I haven't got ldap set up correctly. Any help
would be appreciated.
[root@leo tmp]# ./ldapmigrate -b "dc=serani,dc=com,dc=au" -D
"cn=Manager,dc=serani,dc=com,dc=au" --prepdb
Password: failed to add entry dc=serani,dc=com,dc=au: value of naming
attribute 'dc' is not present in entry at ./ldapmigrate line 136, <DATA>
line 283.
failed to add entry People: parent does not exist at ./ldapmigrate line
174, <DATA> line 283.
failed to add entry Group: parent does not exist at ./ldapmigrate line
174, <DATA> line 283.
failed to add entry Mounts: parent does not exist at ./ldapmigrate line
174, <DATA> line 283.
[root@leo tmp]#
Justin.
20 years, 9 months
Re: Letting Ordinary Users Write To Disk Key
by Jef Spaleta
did you change the definition of the <flash> device class listing line
in consoles.perms to include the /dev/sda* ?
something like
<flash>=/mnt/flash* /dev/flash* /dev/sda*
though i would have thought the <diskonkey> entry would make more
sense..doesnt really matter.
The one lingering problem i have with usb devices is that they are given
/dev/ listing on a first come first server basis. So that if you have 2
or more usb storage devices like a flash reader and a keydrive, and you
connect them in different orders...it can affect how fstab mount lines
work and confuse things. I guess the best possible solution is to make
sure kudzu is aware of these devices and can autocorrect the fstab
entries as needed.
-jef
20 years, 9 months
Re: Release cycle
by Jef Spaleta
Michael Schwendt wrote:
>One thing for sure, there exist common goals and opportunities. But
>I seriously think it is way to early for both Fedora and the Red Hat
>Linux Project to discuss something like this on a rhl-beta list. We
>should all wait and see what Red Hat has in the queue with regard to
>their more open development model.
I don't think we should ALL wait and see...from my reading of what
redhat employee's have said to date on this list atleast...the shape of
the open development model is still in in need of some defining, and
they seem to be willing to engage in a discussion of some of the core
issues and policies that need to be in place to cede responsibility to
community members. The people that need to be talking to each other
about how to open up the development process of rhlp to community
control, probably know who they are already. And of course its too early
to look so far ahead...but maybe it would be instructive for everyone if
there was a listing of prominent first step issues that need to be
addressed on how we get to something like what Havoc wrote:
"I would say yes in general RHL can have a lot of stuff in it that we
aren't expecting to support."
If RHL is going to contain things redhat is not going to support
directly as a goal...how do we get there from here? What are the obvious
and not so obvious obstacles that would affect an application in rhl
that redhat isn't supporting directly? I would hope that the basic
issue of how to include this community managed applications into rhl
will be worked out in time to see some examples of community based
packages in the next beta cycle. But in this beta cycle there has to be
a focusing on planning for those initial test cases.
-jef"beginnings are hard"spaleta
20 years, 9 months
Release cycle
by Maynard Kuona
I have been doing some thinking about Redhat's (And mandrake and SuSE)
release cycles. It was especially with reference to projects such as
Fedora, which aim to provide high quality third party packages for
Redhat. Are these not being stifled by the release cycles. If these
projects are going to make a commitment to quality, the short release
cycles shall surely hurt them. After a while, you can imagine that they
will begin to ignore older releases, and leaving some people with the
option to either upgrade (Not usually a great option) or remain outdated
and without a source of decent third party packages.
Is Redhat working with these efforts in any direct way through maybe
hardware purchases, paying people to actually package some of the
software etc. I imagine this could be a chance for Redhat to actually
shed some of its responsibility to provide these packages, and have this
volunteer effort actually become the "official: third party source for
packages and updates.
But most importantly, how does the release schedule affect a project
like Fedora. Maybe I just need to understand. Also it may be nice to
include the Fedora repository and pre-configured apt/yum packages so
that users could be good to go after installing. This though would
entail giving Fedora packages for their repository as soon as the iso's
are released.
20 years, 9 months
imap in rawhide
by Mike Chambers
If you upgrade the imap package from rawhide in a severn machine, pop
starts to fail when checking password. Had to downgrade back to the
stock severn package to get it to work again.
Just an FYI..
--
Mike Chambers
Madisonville, KY
"Everyone is entitled to be stupid, but some abuse the privilege."
20 years, 9 months
Upon 'Testing and Updates'
by guran
Hi
First I really miss the possibility to listen to jazz on 'Windows Media
Player' through mplayer or xine. This is much to quiet for my liking and a
test should dare to test. That does not necessarily require RH to deliver
with these players, but for home users they must be a must have.
I further miss LyX in qt dressing.
I can compile the above myself but a community testing would be nice.
Your decission not to give consequitive updates on files that have been
corrected here is pure shit. To me you behave like Microsoft: "You users tell
us what is wrong, and we will absorb it and when it is time for X-mas we will
deliver."
It should be easy to deliver new files to the mirrors every day.
I advice you to let this testing take some more liberal turns.
regards
guran
--
Red Hat Linux Beta 9.0.93 kernel-2.4.21-20.1.2024.2.1.nptl
Only in a society that has 'a priori' defined what is true
can the result from the evolution of life be defined false.
20 years, 9 months
Severn problems encountered.
by Jim Cornette
I had the segmentation fault when using mc. I also missed pine and the
fortune program.
I dislike the graphical boot loader. I cannot determine if the thing is
doing anything or is locked up. It also looks too win 2000 to me. Which
tells the user nothing whatsoever, like windows. I prefer the messages
and the ok or failed.
My sound card is working. I have a GUI, It connected to the Internet and
mounted the CD.
This is on an HP pavilion ze4515us laptop.
Jim
--
Sometime in 1993 NANCY SINATRA will lead a BLOODLESS COUP on GUAM!!
20 years, 9 months
Re: updates
by Jef Spaleta
Michael Young wrote:
>The current "add/remove applications" program is badly broken, and isto
>restrictive of what I can install. If RH had just put the rpms on the
>channel, I probably never would have started this thread.
Now here is a strange thought....maybe redhat developers actually want
you to try to use r-c-p and file bugs against it...why would anyone ever
test r-c-p and file bugs for it...if it were all too easy to use
up2date?
>I have *NEVER* stated I bought entitlements for the beta. I purchased
>them for a released version. Besides, RHN would be a great way for RH to
>notify the beta testers a BUGFIX has been applied to a package. Then we
>could all quickly and easily get it and test it.
>Having to add myself to the CC list on every bug report in Bugzilla just
>so I can stay informed of the status of a bug is time consuming, and a
>poor method of passing information in my opinion.
Holy crap no!!!!!!!!!!!
there is so much movement in rawhide from day to day....rhn's bandwidth
would get munched..not to mention the fact that is not necessarily in
every beta testers best interest to eat every rawhide package that comes
down the pike. Rawhide packages can break as much as they fix...putting
all the rawhide additions into rhn is not a good idea. Not all beta
testers are equal...its one thing to encourage ALL beta testers to use
the prepackaged isos and file bugs against them. Its a far different
thing to say that every beta tester should be completely rawhide
up2date. The isos are the packages sets that need to be consumed by the
general beta tester populace...not the day to day rawhide packages.
And i personally think forcing people to track bugreports is a very good
idea. Developers need to use bugzilla to keep up with feedback. I don't
think its necessarily a good idea to encourage everyone to use the
rawhide packages...if they aren't going to give feedback back to the
bugreport that helped generate the rawhide package. Maybe what bugzilla
needs is a digest mode..so it can hand you a compiled daily list of CC'd
messages for all the bugs you are tracking. That way you can get one
message or so a day for all the bugs you are interested in. if you are
going to file a bugreport...then you should be prepared to communciate
via bugzilla with the developer about the issue, including feedback on
the potential fix that appears in rawhide....well unless all your
bugreports are the 'this font look skinny' variety...then you can
probably safely assuming the developer isn't going to need feedback on
the issue.
-jef"my klingon fonts look too slanted...where is the rhn update to fix
this!!!!"spaleta
20 years, 9 months