devel August 2003

devel@lists.fedoraproject.org

93 participants
60 discussions

librt.so TLS issues
by Alexander Larsson 24 Aug '03

24 Aug '03

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!

2 2

Re: /usr boot time dependencies
by Michael K. Johnson 23 Aug '03

23 Aug '03

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/

10 20

2 package patching questions
by George J Karabin 23 Aug '03

23 Aug '03

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.html… Thanks, - George

3 3

Re: feature request: additional IPs assign to real device via ip addr add
by Pekka Savola 21 Aug '03

21 Aug '03

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

2 1

Re: Bug 69903 newt -- Why no progress?
by Michael K. Johnson 20 Aug '03

20 Aug '03

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/

2 9

RPM dependency rationale (and kernel packages)?
by Jos Vos 20 Aug '03

20 Aug '03

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

5 11

Misleading message in 'su' info document
by Bruce A. Locke 20 Aug '03

20 Aug '03

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

4 7

bug fixes/patches and developer round-trip time
by Pekka Savola 19 Aug '03

19 Aug '03

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

6 6

RE: Red Hat Linux Arabic Localization Project
by Sharuzzaman Ahmat Raslan 19 Aug '03

19 Aug '03

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

1 0

Re: Goats... [was: Include OpenOffice.org 1.1 in Severn?]
by Michael K. Johnson 18 Aug '03

18 Aug '03

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/

4 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel August 2003