librt.so TLS issues
by Alexander Larsson
There was a change in glibc somewhere between 2.3.2-57 and 2.3.2-66 that
adds /usr/lib/librt.so.1 to glibc-devel. The file is just a symlink to
librt.so. This change seems wrong to me, and its causing breakage with
TLS.
I have an app not linking to librt, but it dlopens a library that links
to librt.so.1. The app gets the tls libc at /lib/tls/libc.so.6, but when
resolving the librt.so.1 DT_NEEDED it first looks in the system library,
finding /usr/lib/librt.so.1. However, following this symlink gets you
/lib/librt.so.1 which is the non-TLS version of librt. This means we
have mismatched librt and libc versions, causing:
/usr/lib/librt.so.1: symbol __librt_disable_asynccancel, version
GLIBC_PRIVATE not defined in file libc.so.6 with link time reference
Having the soname librt in /usr/lib just seems wrong to me. What was the
reason for introducing it?
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
alexl(a)redhat.com alla(a)lysator.liu.se
He's an obese moralistic sorceror with a passion for fast cars. She's a
strong-willed goth cab driver fleeing from a Satanic cult. They fight crime!
20 years, 1 month
Re: /usr boot time dependencies
by Michael K. Johnson
Since this is really a development discussion, please followup to
rhl-devel-list. Thanks!
On Sat, Aug 16, 2003 at 04:18:57PM +0100, Paul Jakma wrote:
> On Fri, 15 Aug 2003, Michael K. Johnson wrote:
>
> > That /usr is required to init IPv6 would be a bug.
>
> Indeed.
>
> [root@fogarty network-scripts]# egrep '\<(id|uniq)\>' *
> init.ipv6-global: sysctl -a | grep "^net\.ipv6\.conf\."
> | awk -F. '{ print $4 }' | sort | uniq | while read interface; do
> init.ipv6-global: sysctl -a | grep "^net\.ipv6\.conf\."
> | awk -F. '{ print $4 }' | sort | uniq | while read interface; do
> init.ipv6-global: sysctl -a | grep "^net\.ipv6\.conf\."
> | awk -F. '{ print $4 }' | sort | uniq | while read interface; do
> network-functions: if [ "`id -u`" = "0" ]; then
>
> neither id nor uniq should be considered available before netfs and
> autofs have run.
OK, sort -u is the obvious answer IRT uniq.
do_netreport will never need to call id if it doesn't exist, so
! -x /usr/bin/id -o ...
should resolve that issue.
> either these 2 utils should be installed to /bin, not /usr/bin (sort
> is installed to /bin) or network init scripts should not use them.
In these cases, the latter.
> > > - portmap resides in /bin but links to libwrap.so - which is in
> > > /usr/lib and may not be available.
> >
> > Again, a bug one way or another.
>
> I suggest either portmap should statically link libwrap, or
> libwrap.so should install to /lib.
In either case, bugzilla. :-)
michaelkjohnson
"He that composes himself is wiser than he that composes a book."
Linux Application Development -- Ben Franklin
http://people.redhat.com/johnsonm/lad/
20 years, 1 month
2 package patching questions
by George J Karabin
I've got two questions that have come up while making some minor patches
lately. Hopefully the answers (if forthcoming) will be useful to others
who are starting to get more involved with RHLP.
Question #1:
Are all of the packages in RHL/RHLP available for anonymous CVS access
at this point in time, or just the subset that I see on
rhlinux.redhat.com?
Every once in a while I find a trivial bug in some package and want to
make a patch against its .spec file, or usually, its .spec.in file.
If the package is hosted on the one anonymous RedHat CVS server that I
know of - CVSROOT=pserver:anoncvs@rhlinux.redhat.com:/usr/local/CVS - no
problems. If it's a package that's not in CVSROOT/modules, then I'm at a
loss.
Question #2:
Does anyone have a take on whether or not it's appropriate to use the
"-a" option to add binary files (like graphics) to a patch? I can't
recall ever seeing a patch distributed with one, and reading such a
thing probably does wonders for terminals (random escaped character
sequences) but the following page seems to indicate that it's an OK
practice:
http://www.gnu.org/manual/diffutils/html_node/Tips-for-Patch-Producers.ht...
Thanks,
- George
20 years, 1 month
Re: feature request: additional IPs assign to real device via ip addr add
by Pekka Savola
I think this discussion should go rhl-devel list. Please send the
followups only there.
On Thu, 21 Aug 2003, Alexander Dalloz wrote:
> I would like a feature for setting up additional IPs to a real device by
> just giving it a list of IPs. Well, I know it is possible to use aliased
> devices, but that is not often neccessary, even more work. And those
> aliased devices are not usable by iptables rules as device instructions.
>
> In /etc/sysconfig/network-scripts/ifup the real device is already set up by
> the command "ip addr add". So it would be nice to give the script just a
> list of IPs to be added to the real device. It could be done by a variable
> in /etc/sysconfig/network-scripts/ifcfg-ethX in which the administrator will
> just put the space separated list of additional IPs.
Note that this is how it's done with IPv6.
A problem, at least in the past, was that ifconfig(8) would not show these
addresses at all. I'm not sure if that has been fixed.
Anyone remember the details of this case?
Personally I also think that the concept of alias interfaces is a bit
obsolete.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
20 years, 1 month
Re: Bug 69903 newt -- Why no progress?
by Michael K. Johnson
Because this is a development issue, please followup to rhl-devel-list.
On Thu, Aug 07, 2003 at 01:51:06PM -0400, Janina Sajka wrote:
> The cursor tracking problem first reported against newt well over a year
> ago, and recently re-opened as the community of blind users tracked down
> the problem and created the resolution patch, continues unresolved as
> shown by Bugzilla just a few moments ago. May I point out that this fix
> is extremely important to thousands of users of Speakup worldwide?
>
> So, is there a problem with the fix submitted? It would be most helpful
> to have newt working properly in Cambridge.
The problem is, I think, reviewing it to make sure that it doesn't break
anything else. A description of exactly why the change is a fix can help
for things like this.
- newtGotorc(co->top + (li->currItem - li->startShowItem) + 1, co->left + 1);+ newtGotorc(co->top + (li->currItem - li->startShowItem) + li->bdyAdjust,
+ co->left + li->bdxAdjust);
I note that bdxAdjust is set only to 0 or 2, and it's not at all clear
to me how changing bdxAdjust applies to this bug report from the
description. It might still be correct or an improvement, but it is
not clear at a short read why it is either.
The change to bdyAdjust makes sense to me as a fix for this bug report.
michaelkjohnson
"He that composes himself is wiser than he that composes a book."
Linux Application Development -- Ben Franklin
http://people.redhat.com/johnsonm/lad/
20 years, 1 month
RPM dependency rationale (and kernel packages)?
by Jos Vos
Hi,
Short intro:
Every package provides itself implicitly, as if the line
"Provides: foo = 5.0-2" was in the spec file. This means that any
dependency on "foo", "foo = 5.0", or "foo = 5.0-2" is satisfied
(as well as relational dependencies, like "foo >= 5.0" etc.).
This is all the basic RPM dependency behaviour and pretty
straightforward.
It now seems that rpm also has the following behaviour:
If you put an explicit "Provides" line in the spec file *omitting*
the release, say "Provides: foo = 5.0", then *any* dependency on
version 5.0 of foo, whatever release is required (!), is satisfied.
So, a package having "Require: foo = 5.0-6" happily coexists with
the foo-5.0-2 package. I don't understand this. Or it's a bug,
or there is some rationale for this that I don't know of (yet).
It also is the case that every kernel package provides
"kernel = %{version}" explicitly. AFAIK this is mainly done to let
kernel-smp, kernel-bigmem, etc. all "provide" the basic kernel too
(but Arjan can tell much more about this, see also our disussion
on https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=102639
earlier today).
In my case, I wanted to let a pseudo-package require specifically
"kernel = 2.4.20-18.9", to pull that kernel package in with APT
(more details on request) and I then detected that "kernel-2.4.20-8"
was good enough for rpm (and APT) to satisfy "kernel = 2.4.20-18.9".
So, now the main issues:
- Is the rpm bahaviour a bug or a feauture (if a feature, why)?
- Arjan has good reasons for the current kernel provides lines,
but I'm mainly objecting against the rpm bahaviour, so could
a different behaviour coexist with Arjans kernel packaging goals?
Note that the bug report Panu submitted (see above) mainly resulted
in a kernel packaging discussion, although the core question lays
at the rpm level.
--
-- Jos Vos <jos(a)xos.nl>
-- X/OS Experts in Open Systems BV | Phone: +31 20 6938364
-- Amsterdam, The Netherlands | Fax: +31 20 6948204
20 years, 1 month
Misleading message in 'su' info document
by Bruce A. Locke
I'm sure by now most of you have read the "Why GNU 'su' does not support
the 'wheel' group" rant from RMS written years ago. If you have not
seen it yet do a quick 'info su' and scroll down to the bottom.
What surprises me is this has not been pulled from the 'su' info page
years(?) after pam_wheel showed up in pam. The statement that GNU 'su'
does not support the 'wheel' group may be technically true in the form
shipped by the GNU but it is misleading when used in Red Hat. If I were
looking for wheel support and decided to check the su info page (as
suggested by the su man page) I would have read this statement and may
never have figured out the functionality was actually being provided!
In my opinion such historical baggage is harmful and should be pulled
from at least Red Hat's copy of the 'su' info page.
Any opinions?
--
---------------------------------------------------------------------
Bruce A. Locke
blocke(a)shivan.org
20 years, 1 month
bug fixes/patches and developer round-trip time
by Pekka Savola
Hi,
Perhaps I should bring up one issue that may have not been discussed too
much.
A lot of bug reports which no one has time to fix is bad, of course.
But what's worse, is that when someone from the community provides e.g.
patches or works for fixing those issues, it takes a LONG time to actually
get a developer to commit such a fix and get the problem solved.
IMHO, in cases I've seen this, most of the time it has taken entirely too
long (even many weeks or months, even for trivial fixes).
This alienates people who actually sometimes fix problems rather than
"just" complain about them. (Complaining, when done properly, is very
important too, of course :-).
This is something that needs to be fixed, and should be a first priority
item to fix in the RHL project.
Whether that requires new priorization for developers, giving out CVS
commit access, or whatever, I don't know .. but the situation MUST
improve, and soon.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
20 years, 1 month
RE: Red Hat Linux Arabic Localization Project
by Sharuzzaman Ahmat Raslan
The language is still used today, even though most of us will use the Romanised Malay.
I will forward the info to the interested parties and ask them to join this mailing list or the one you mention in your first email.
"Sherif R. Abdelgawad" <sabdelg(a)redhat.com> wrote:
>
>> Are you planning to include other Arabic character language such as the
>> Old Malay (Jawi)?
>
>You are most welcome to lead an effort if you would like. I am not
>familiar with the Jawi, and not sure what are the challanges.
>Is that Lang still being used in Maly?
>
>
>
>--
>Rhl-devel-list mailing list
>Rhl-devel-list(a)redhat.com
>http://www.redhat.com/mailman/listinfo/rhl-devel-list
>
--
------------------------
Sharuzzaman Ahmat Raslan
__________________________________________________________________
McAfee VirusScan Online from the Netscape Network.
Comprehensive protection for your entire computer. Get your free trial today!
http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397
Get AOL Instant Messenger 5.1 free of charge. Download Now!
http://aim.aol.com/aimnew/Aim/register.adp?promo=380455
20 years, 1 month
Re: Goats... [was: Include OpenOffice.org 1.1 in Severn?]
by Michael K. Johnson
I suppose this is going off in the direction of being a development-related
discussion, so rhl-devel-list is probably the best place to discuss it.
On Fri, Aug 15, 2003 at 03:27:57PM -0600, Jared Smith wrote:
> Actually, I was just wondering... What parts of Red Hat Linux require
> the most work to get ready for a new version? Is there anything mere
> mortals like myself can do to help out the situation, with a little
> effort, in our spare time?
Hmm. One of the things that fits the "spare time" model better than
trying to contribute to packaging is probably bugzilla triage. In
particular, looking for dups, bugs filed against the wrong component,
and bugs that need more info would be quite helpful.
When you have a set of duplicate bugs, the first thing to do is
to find not the earliest report of the bug, but the clearest one
with the most information. This is often not the earliest report;
if it were, chances are better it would have been resolved already.
Then mark the other bugs as duplicates of the best report, with
like "this bug might be a duplicate of bug #nnnnn". If you use
that exact form, "bug #" followed by the bug number, bugzilla will
helpfully convert the text into a hyperlink. :-)
When you are looking for bugs filed against the wrong component,
there are two possibilities: bugs that filed against 4suite (the
first component in the list) and bugs that are more subtly wrong.
Common "subtle wrongness" includes bugs filed against mount, pppd,
acpid, etc. that are really kernel bugs (and vice versa), and bugs
filed against applications that are really in libraries used by
the applications.
Bugs that need more info are often "foo breaks" without much
more information. If you see a vague bug report that you know
how to get more information on, you can chime in and politely
suggest some ways to get more information. If you can actually
reproduce the bug, providing more information, especially on
how to reproduce it, is wonderful.
If you are a developer, you can even write candidate patches.
When you have one, please feel free to bring it to rhl-devel-list
for discussion if the bug owner doesn't respond within a few
business days.
The GNOME triage guidelines are at
http://developer.gnome.org/projects/bugsquad/triage/
and aren't bad reading, though our process is a bit different.
We should probably write up our own triage guidelines; I guess
this email (and perhaps a thread it might spawn) could be the
start of that.
Thanks!
michaelkjohnson
"He that composes himself is wiser than he that composes a book."
Linux Application Development -- Ben Franklin
http://people.redhat.com/johnsonm/lad/
20 years, 1 month
