Bug#347173: glibc: Romanian days are written with mixed case letters/Romanian alplhabet reordered
On 2/23/06, Denis Barbier [EMAIL PROTECTED] wrote: On Thu, Feb 23, 2006 at 02:39:46PM +0200, Eddy Petrişor wrote: I managed to do it today, so here it is (hopefully) the final version of the patch for locale ro_RO. This fixes also: + * locales/ro_RO: first_weekday and first_workday are both Monday + * locales/ro_RO: added terminology and bibliographic codes for RO + reference: http://www.loc.gov/standards/iso639-2/langcodes.html#qr It looks good, I will commit it. Thanks. Of course there is an(other) update (I promise, the last which I am doing from my own will and based on my sole reasoning) :-/ I have added the isbn code for RO and the postal code (I am not 100% sure that is the correct one, but I don't recall seeing another one). All the locales were tested, including ro_RO.ISO-8859-16 (explanation follows). I order not to have a war going on on the basis of the encoding used by ro_RO I have created ro_RO.ISO-8859-16 as another valid locale for ro_RO (although UTF-8 is the only encoding that displays all Roamnian specific characters), but this modification is in an unpublished patch. Taking into account that UTF-8 will become the 'de facto' standard encoding in the world (until another encoding that fixes the han unification problem appears) I made two patches (one with ro_RO.ISO-8859-16 locale and one without) to test them. They both contain the isbn code and the postal code. Notes: - I will promote the one without ISO-8859-16 as the encoding *still* can't encode all Romanian specific codes. Adding yet another broken ro_RO* locale would add suplemental mess to the whole Romanian localisation issues. - The patch with the 8859-16 locale was made as a test to see if the locale would work. Because so few applications are iso-8859-16 aware I feel that introducing this locale will cause more delays towards crossing to UTF-8 and also lots and lots of unnecessary issues. Because of this I am sending only the patch without the ro_RO.ISO-8859-16 locale. Thanks for understanding. -- Regards, EddyP = Imagination is more important than knowledge A.Einstein ro_RO_massive_fix-200602240950-no-8859-16.diff.gz Description: GNU Zip compressed data
Bug#347173: glibc: Romanian days are written with mixed case letters/Romanian alplhabet reordered
On 2/24/06, Eddy Petrişor [EMAIL PROTECTED] wrote: All the locales were tested [snip] I have observed that 'cal' does not take into account the first_weekday/first_workday data. Is this a cal bug? (I know there is an option of cal to display the first week day as Monday, but that is another issue). -- Regards, EddyP = Imagination is more important than knowledge A.Einstein
Re: glibc 2.3.6-3
At Thu, 23 Feb 2006 22:43:26 +0100, Aurelien Jarno wrote: I have just uploaded glibc 2.3.6-2. It is now time to think to the next upload, glibc 2.3.6-3. Gook work! Personally here is the things I would like to see in it: - Split of libc6 and libc6-dev into libraries and binaries. This is required as per policy, but become more important for multiarch support. But maybe there is a reason for having binaries and libraries in the same package? It depends on the policy. You could split them. However, I wonder we need to do so. - More architectures using the multiarch directories for the 64-bit version of the glibc. This will however depends on other packages - A policy for the debian/patches directory. This is currently a bit a mess (and I contributed to it) in this directory, except for the locale data which is separated. I think the information we need in the patch filename is: - a short part telling what the patch does - the architecture for which it applies - the upstream status (debian specific, in upstream BTS, fixed in CVS). For example xfree86 uses number to define that: 000 (patches from upstream or merged in upstream), 001-899 (patches that should be merged in upstream), 900-999 (patches that are specific to debian or were rejected by upstream). I already tried your idea (numbering them), but finally the attempt was failed. 10_cvs.diff is the example of such remains. Maybe some more information could be put in the filename. Don't hesitate to give ideas. Then we could put a README file containing the policy in this directory. I seconded that the information should be always included in the filename. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#227386: libc6-dev: ENOTSUP==EOPNOTSUPP, which violates SUSv3
On Thu, 2006-02-23 at 13:24 +0100, Gabor Gombas wrote: On Thu, Feb 23, 2006 at 04:30:55AM +, Brian M. Carlson wrote: By introducing a new define, you are breaking standard compliance. Well, there is no better way. You want to preserve binary compatibility at the expense of all else. I want to preserve standards compliance at the expense of all else. I am trying to offer a compromise. You can not preseve standards compliance by breaking standards compliance, so that's out. What remains is preserving binary compliance, and that can be achieved by doing nothing. What I'm saying is that I'm trying to make everyone happy, or at least not completely angry. If we went my way, we'd change the numbers, and screw binary compatibility. If we went your way, we'd screw standards compatibility and keep the status quo. Neither side is willing to lose and give in all the way. I tried a compromise. Apparently, that didn't work, so let me try another one: glibc could no longer claim compliance with SUSv3/POSIX 1003.1-2001 or SUSv2. Then there will be no bug, and we can all be happy. Actually, no it won't. It will continue to return the wrong value (EOPNOTSUPP) that existing code returns. At some point, one might want to fix that with new @GLIBC_2.3.7 symbols, but I'm not going to implement that right now. Also, see the paragraph above. Oh, so you _do_ know how to fix it properly: Well, yes, but it doesn't fix it completely. Try the following scenario: * libfoo is compiled against glibc 2.3.6. * bar is compiled against libfoo and glibc 2.3.6. * A new version of bar comes out, and is compiled against glibc 2.3.7 (which no longer has the bug in question, let's say). * Now, several things could happen: + bar passes the error code it gets from some libc function to libfoo, and libfoo tries to handle it, libfoo errors out and bar no longer works. + bar passes the error code it gets from some libc function to libfoo, which then tries to log the error by using strerror. This will cause silent breakage. + Everything still works. This solution will avoid the vast majority of problems, but it isn't perfect. I am getting the impression that the others here want a perfect solution, and other than changing SONAMEs (which no one wants to do), it can't be done, AFAICT. If someone can find a solution which works in all cases, please let me know. - Make ENOTSUP and EOPNOTSUPP have different values in the header - Ensure that the implementations with the current symbol versions continue to return the old value to preserve binary compatibility - Create a new version for every affected function that does the desired error-code remapping So do it and propose a patch to upstream (or hire someone to do it for you). Handwaving and posting completely broken patches will not help. (Oh, and be prepared for Ulrich Drepper rejecting this exact change, as he already did in 1999). I'd be happy to do it. However, I think Ulrich Drepper and the FSF will not accept my patch without copyright assignment, and I don't do copyright assignment, nor do I require others to do so. If the FSF wants to waive that requirement, I'll be happy to do it, but I'm not going to waste time on code that the FSF won't accept if I have to send it upstream. I found the change in question, where Mr. Drepper claims that Linus rejected his patch to create an ENOTSUP, and so he defined ENOTSUP to EOPNOTSUPP. But I cannot find the patch that Linus rejected. I also find his claim in the glibc bug I opened that it is part of the ABI unconvincing, especially now that I know it was he who made the change, and therefore part of the ABI. Also, I have no idea why the two errors were made the same, when item number 2 in the PROJECTS file is: [ 2] Test compliance with standards. If you have access to recent standards (IEEE, ISO, ANSI, X/Open, ...) and/or test suites you could do some checks as the goal is to be compliant with all standards if they do not contradict each other. This has apparently been in that file since it was checked in, 9 years and 8 months ago. If and when that happens, my code will be broken, and I will be happy to fix it. Expecting that I act as if something will happen, when I cannot be certain it will, is silly. By the same argument, expecting that ENOTSUP and EOPNOTSUPP having different values in the future, when you cannot be certain they will (i.e. you haven't written a patch that got accepted upstream, and you have forced every Linux user to upgrade), is silly. So you should fix your code _now_, and remove the extra handling of ENOTSUP/EOPNOTSUPP if/when they will have separate values. No, I can be sure they have separate values now, because glibc defines _POSIX_VERSION to 200112L. That indicates *complete* and *total* support of the base portions of POSIX 1003.1-2001. Such portions include the two error code in question. If glibc didn't define
Bug#353031: posix_fadvise defines missing
At 16 Feb 2006 13:00:08 -0500, Greg Stark wrote: The man pages come from manpages-dev. It seems like the necessary #defines should be included in each man page along with the necessary #includes. I suspect I'll be tilting at windmills trying to convince people of this though. Can we reassign your report to manpages-dev, or just close it? Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: compiling libc with --disable-hidden-plt
At Thu, 23 Feb 2006 10:46:25 +0100, Andrea Gasparini wrote: i'm at first post in this list, and i'm searching for a solution to one problem, so excuse me if it's not pefectly in topic here... So, this is the problem: i want to wrap almost all system call with LD_PRELOAD, and i would like to write a minimal library (rewrite all libc is quite boring... :-P ) I would prefer to write only write(), open() and not having to rewrite functions like fopen(), printf() and so on... I found that with --disable-hidden-plt configure option i can build a dynamic library that can be preloaded with my own library: something like $LD_PRELOAD=./libtest.so ./libc.nohidden.so a.out but it doesn't work... or better: it works for write(),open() that i directly write into libtest.so, but printf doesn't call write, so i can't intercept it... Glibc internally handles system call directly. It also sometimes uses wrapper name prefixed with __ . -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Multiarch support (was Moving 32-bit libraries to (/usr)/lib32on amd64)
Matthias Klose wrote: Bdale Garbee writes: On Fri, 2006-02-24 at 01:12 +0100, Aurelien Jarno wrote: The only change planned is to make libc6-dev-i386 and libc6-i386 provide a glibc on amd64 instead of ia32-libs. It will be in /emul/ia32-linux (I still have to find how to do that cleanly in the debhelper files). Bdale, do you agree with such a change? Yes, I think we can handle that. It means some small work on ia32-libs to stop delivering any conflicting files, but I'm sure we can work that out easily enough. If you want to provide me a patch for ia32-libs that does what you want it to do, that would be welcome. thanks. with this setup we are able to build our toolchain without build dependencies on ia32-libs or with packages conflicting with future multiarch packages (maybe additionally building lib32z1 from zlib). Hello, please consider to install the 32-bit files from libc6(-dev)-i386, lib32gcc1, lib32stdc++ and lib32z1 in /usr/lib32 instead of /emul/ia32-linux/usr/lib. This way the amd64 case would be handled in a similar way as the other 32/64-bit biarch architectures. I think that a future migration to multiarch will be easier if the amd64 case needs no special handling. Also, with /usr/lib32 there will be no need for ugly glibc debhelper file hacks as it would be for /emul/ia32-linux/usr/lib. I suggest the following setup for 32-bit libraries on amd64: 1. The ia32-libs package continues to install the 32-bit libraries in /emul/ia32-linux/usr/lib but it stops to provide the 32-bit libc6(-dev) packages. 2. The ia32-libs package does no longer provide a symlink from /usr/lib32 to /emul/ia32-linux/usr/lib. 3. The 32-bit libraries from libc6(-dev-)-i386, lib32gcc1, lib32stdc++, lib32z1 and other _amd64.deb packages are installed in /usr/lib32 which is not a symlink but a real directory. 4. The (/usr)/lib/i486-linux-gnu directories are reserved for future multiarch installations. These changes could be implemented by simple patches without breaking existing installations. Regards Andreas Jochens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Multiarch support (was Moving 32-bit libraries to (/usr)/lib32on amd64)
Andreas Jochens a écrit : Matthias Klose wrote: Bdale Garbee writes: On Fri, 2006-02-24 at 01:12 +0100, Aurelien Jarno wrote: The only change planned is to make libc6-dev-i386 and libc6-i386 provide a glibc on amd64 instead of ia32-libs. It will be in /emul/ia32-linux (I still have to find how to do that cleanly in the debhelper files). Bdale, do you agree with such a change? Yes, I think we can handle that. It means some small work on ia32-libs to stop delivering any conflicting files, but I'm sure we can work that out easily enough. If you want to provide me a patch for ia32-libs that does what you want it to do, that would be welcome. thanks. with this setup we are able to build our toolchain without build dependencies on ia32-libs or with packages conflicting with future multiarch packages (maybe additionally building lib32z1 from zlib). Hello, please consider to install the 32-bit files from libc6(-dev)-i386, lib32gcc1, lib32stdc++ and lib32z1 in /usr/lib32 instead of /emul/ia32-linux/usr/lib. This way the amd64 case would be handled in a similar way as the other 32/64-bit biarch architectures. IMHO, I think it would be better to use (/usr)/lib32. But I won't do any change without having a mail from Steve Langasek, Matthias Klose and Bdale Garbee telling that they are ok with this change. I think that a future migration to multiarch will be easier if the amd64 case needs no special handling. Also, with /usr/lib32 there will be no need for ugly glibc debhelper file hacks as it would be for /emul/ia32-linux/usr/lib. Here is my opinion: Advantages - Coherency between ports. MIPS will use /usr/lib32 when the tri-arch patch will be finished, the unofficial ppc64 pot uses /usr/lib32. Also this is the counterpart of /usr/lib64 on other arches. - Easier for biarch package maintainers, as they don't need to do special things for amd64. This is essentially true for the glibc. - /usr/lib32 is a search path for gcc /emul/ia32-linux/usr/lib is not, that's why we currently have a symlink. Drawbacks: - We have to change. I suggest the following setup for 32-bit libraries on amd64: 1. The ia32-libs package continues to install the 32-bit libraries in /emul/ia32-linux/usr/lib but it stops to provide the 32-bit libc6(-dev) packages. That was the plan. 2. The ia32-libs package does no longer provide a symlink from /usr/lib32 to /emul/ia32-linux/usr/lib. Removing this link render the ia32-libs-dev package unusable as /emul/ia32-linux/usr/lib is not a search path when linking libraries. 3. The 32-bit libraries from libc6(-dev-)-i386, lib32gcc1, lib32stdc++, lib32z1 and other _amd64.deb packages are installed in /usr/lib32 which is not a symlink but a real directory. Personally I feel we have to remove as much as possible libraries from ia32-libs replacing them by biarch packages, as it has been done for amd64-libs. This package is not build from sources, but uses the binaries from i386.deb files. Yes the sources are also provided in the source package, but that doesn't really help more. Imagine you want to fix something, you can't simply apply a patch to ia32-libs sources and rebuild. That's bad, and at the limit of your policy manual. Bdale, please don't take that as a personal attack. This package is really useful and also it exists! But I think we could do better. 4. The (/usr)/lib/i486-linux-gnu directories are reserved for future multiarch installations. These changes could be implemented by simple patches without breaking existing installations. Yes, they are all on http://people.debian.org/~aurel32/amd64-lib32/ for a while. Bye, Aurelien -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: Spyware Stormer Support Request
Dear Spyware Stormer Customer, Thank you for contacting our support department. Your email was received and your request is currently being processed. The average response time for support inquiries is 24 business hours. During this time, please review the list of frequently experienced problems included below. The list covers the five most commonly experienced support issues, and outlines detailed steps on how to resolve each of these issues. We find that the answers contained below are able to resolve a majority of the support issues experienced by our customers. Our hours of operation are Monday - Friday, 9AM to 5PM Eastern Standard Time. Please do not reply to this email address. You will receive a personalized response from one of our customer support representatives shortly. FREQUENTLY EXPERIENCED PROBLEMS 1. Activation key does not work. (a) The activation system in Spyware Stormer is case sensenitive. This means that both the order number and the activation key must be entered in the same case in which they were provided (eg. abcd = lowercase) (eg. ABCD = uppercase). (b) If you accidentally include any spaces before or after the order number or activation key, the program will not accept the values entered. (c) Zeros Os and Ohs 0s are commonly interchanged for one another. If an O (Oh)is entered in place of a 0 (Zero), then the key will not work. Please ensure that Zeros 0s and Ohs Os are entered correctly. To avoid the above problems, simply copy the key/order number to your computer's clipboard (CTRL + C) and then paste the key/order number into the appropriate field (CTRL + V). 2. Activation key is lost. If you have lost your activation key or order number, please reference the email in your inbox with the subject ClickBank Receipt - automated notification. The email sender will appear as [EMAIL PROTECTED] In the body of the email you will find a link that, when clicked, returns you to the confirmation page on the Spyware Stormer website where you can retrieve your activation key and order number. Look for this text in the body of the email If for some reason you did not receive access to the product immediately after payment, please try again by following this link now: 3. Can't register the product. To register Spyware Stormer, you must return to the application and enter your order number and activation key. Begin by clicking Start on your computer's taskbar, then go to Programs and locate the Spyware Stormer folder. Then click the Spyware Stormer icon to open the application. Once the application loads, click the Register button located in the top-right corner of the application. Then, fill in your order number and activation key exactly as they appear on the confirmation page you were sent to after making your purchase. 4. Infections are not being fully removed. If you have scanned your computer for infections, removed them, and they are still appearing, this may be due to the following: If there are any Internet Explorer windows open while you perform the scanning and removing functions, some infections may attach themselves to the program, which prevents them from being removed. To remove these infections, you must ensure that all Internet Explorer windows are closed while performing the scanning and removing functions. If infections continue to appear after removal, please try rebooting your computer and running a new scan immediately after boot-up, before any other applications are started, and preferably while you are off-line. 5. Can't open Spyware Stormer. To open Spyware Stormer, click Start on your computer's taskbar, then Programs and locate the Spyware Stormer folder. Then click the Spyware Stormer icon to open the application. Thank you, Customer Support Spyware Stormer Inc. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Multiarch support (was Moving 32-bit libraries to (/usr)/lib32on amd64)
On 06-Feb-24 12:06, Aurelien Jarno wrote: Andreas Jochens a écrit : I suggest the following setup for 32-bit libraries on amd64: 1. The ia32-libs package continues to install the 32-bit libraries in /emul/ia32-linux/usr/lib but it stops to provide the 32-bit libc6(-dev) packages. 2. The ia32-libs package does no longer provide a symlink from /usr/lib32 to /emul/ia32-linux/usr/lib. Removing this link render the ia32-libs-dev package unusable as /emul/ia32-linux/usr/lib is not a search path when linking libraries. /emul/ia32-linux/usr/lib _is_ in the search path of the dynamic linker because /emul/ia32-linux/usr/lib is added to /etc/ld.so.conf by ia32-libs.postinst. Consequently, the symlink to /usr/lib32 is not necessary to run 32-bit binaries that use libraries from ia32-libs. As far as I remember, the /usr/lib32 symlink was introduced in ia32-libs because without it 'gcc -m32' did not work correctly because it expects its own 32-bit libraries (e.g. libgcc*) to be in /usr/lib32. This problem with gcc will no occur in my suggested setup because of: 3. The 32-bit libraries from libc6(-dev-)-i386, lib32gcc1, lib32stdc++, lib32z1 and other _amd64.deb packages are installed in /usr/lib32 which is not a symlink but a real directory. Regards Andreas Jochens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Multiarch support (was Moving 32-bit libraries to (/usr)/lib32on amd64)
Andreas Jochens a écrit :
On 06-Feb-24 12:06, Aurelien Jarno wrote:
Andreas Jochens a écrit :
I suggest the following setup for 32-bit libraries on amd64:
1. The ia32-libs package continues to install the 32-bit libraries in
/emul/ia32-linux/usr/lib but it stops to provide the 32-bit libc6(-dev)
packages.
2. The ia32-libs package does no longer provide a symlink from
/usr/lib32 to /emul/ia32-linux/usr/lib.
Removing this link render the ia32-libs-dev package unusable as
/emul/ia32-linux/usr/lib is not a search path when linking libraries.
/emul/ia32-linux/usr/lib _is_ in the search path of the dynamic linker
When I say linking, I don't speak about the dynamic linking, but the
linking that occurs when building a package with gcc.
because /emul/ia32-linux/usr/lib is added to /etc/ld.so.conf by
ia32-libs.postinst. Consequently, the symlink to /usr/lib32 is not
necessary to run 32-bit binaries that use libraries from ia32-libs.
Agreed that part works. Note that I spoke about ia32-libs-dev.
As far as I remember, the /usr/lib32 symlink was introduced in ia32-libs
because without it 'gcc -m32' did not work correctly because it expects
its own 32-bit libraries (e.g. libgcc*) to be in /usr/lib32. This
problem with gcc will no occur in my suggested setup because of:
It expects _all_ libraires to be there or (in /lib), not only the gcc ones:
[EMAIL PROTECTED]:/# echo 'main() {}' test.c
[EMAIL PROTECTED]:/# gcc -m32 -o test test.c -ljpeg
/usr/bin/ld: skipping incompatible
/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../libjpeg.so when searching
for -ljpeg
/usr/bin/ld: skipping incompatible
/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../libjpeg.a when searching
for -ljpeg
/usr/bin/ld: skipping incompatible /usr/bin/../lib/libjpeg.so when
searching for -ljpeg
/usr/bin/ld: skipping incompatible /usr/bin/../lib/libjpeg.a when
searching for -ljpeg
/usr/bin/ld: skipping incompatible /usr/lib/libjpeg.so when searching
for -ljpeg
/usr/bin/ld: skipping incompatible /usr/lib/libjpeg.a when searching for
-ljpeg
/usr/bin/ld: cannot find -ljpeg
collect2: ld returned 1 exit status
[EMAIL PROTECTED]:/# ls /emul/ia32-linux/usr/lib/libjpe*
/emul/ia32-linux/usr/lib/libjpeg.so.62
/emul/ia32-linux/usr/lib/libjpeg.so.62.0.0
So that does not work.
Aurelien
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' [EMAIL PROTECTED] | [EMAIL PROTECTED]
`-people.debian.org/~aurel32 | www.aurel32.net
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Multiarch support (was Moving 32-bit libraries to (/usr)/lib32on amd64)
Hello,
On 06-Feb-24 14:04, Aurelien Jarno wrote:
Andreas Jochens a écrit :
When I say linking, I don't speak about the dynamic linking, but the
linking that occurs when building a package with gcc.
because /emul/ia32-linux/usr/lib is added to /etc/ld.so.conf by
ia32-libs.postinst. Consequently, the symlink to /usr/lib32 is not
necessary to run 32-bit binaries that use libraries from ia32-libs.
Agreed that part works. Note that I spoke about ia32-libs-dev.
The current ia32-libs-dev package contains basically only the 32-bit
files from the i386 libc6-dev package, i.e. it will be completely
replaced by the new libc6-dev-i386 package.
As far as I remember, the /usr/lib32 symlink was introduced in ia32-libs
because without it 'gcc -m32' did not work correctly because it expects
its own 32-bit libraries (e.g. libgcc*) to be in /usr/lib32. This
problem with gcc will no occur in my suggested setup because of:
It expects _all_ libraires to be there or (in /lib), not only the gcc ones:
Yes, you are right. However, the current ia32-libs-dev package does not
contain any development libraries besides libc6-dev anyway, so no
functionality will be lost by removing the symlink from ia32-libs,
provided that all other _amd64.deb packages install their 32-bit
development libraries in /usr/lib32.
[EMAIL PROTECTED]:/# echo 'main() {}' test.c
[EMAIL PROTECTED]:/# gcc -m32 -o test test.c -ljpeg
/usr/bin/ld: cannot find -ljpeg
You will get the same result with or without the symlink, simply because
ia32-libs-dev does not contain the necessary libjpeg.so at all.
In any case, there are other reasons why the ia32-libs-dev package
setup does not allow for any serious 32-bit development (e.g. problems
with architecture specific include files). 32-bit development in the
sense of package building will require either an i386 chroot environment
or maybe in the future a full multiarch environment.
Regards
Andreas Jochens
P.S. Thank you for all your recent work on the glibc package and
especially for the recent upload of version 2.3.6-2. This new version
will make many things a lot easier, especially for amd64,
regardless which of the discussed directory setups will be chosen
finally.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325463: marked as done (glibc: [Patch] Allow for multiarch libraries)
Your message dated Fri, 24 Feb 2006 16:34:45 +0100 with message-id [EMAIL PROTECTED] and subject line Bug#325463: glibc: [Patch] Allow for multiarch libraries has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Package: glibc Severity: wishlist Tags: patch Hi, atached is a patch that will add /lib/arch-os-gnu and /usr/lib/arch-os-gnu to the default-rpath. Those two directories are the placement for libraries in the future multiarch support [...-gnu now since gcc -dumpmachine has it and to allow for e.g. uclibc linked libraries]. The patch is part of work done by Tollef Fog Heen [EMAIL PROTECTED] to multiarch-ify glibc and reduced to just the parts needed to make glibc see other, already multiarch-ified libraries. Adding this would greatly help transitioning to multiarch as it prevents a big testing blockage (libraries don't have to wait for glibc to become multiarch but can transition on their own). MfG Goswin -- System Information: Debian Release: 3.1 Architecture: amd64 (x86_64) Kernel: Linux 2.6.8-frosties-2 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) diff -u glibc-2.3.5.orig/debian/patches/99_multiarch-ld.dpatch glibc-2.3.5/debian/patches/99_multiarch-ld.dpatch --- glibc-2.3.5.orig/debian/patches/99_multiarch-ld.dpatch +++ glibc-2.3.5/debian/patches/99_multiarch-ld.dpatch @@ -0,0 +1,48 @@ +#! /bin/sh -e + +# All lines beginning with `# DP:' are a description of the patch. +# DP: Description: Multiarch support +# DP: Author: Tollef Fog Heen [EMAIL PROTECTED] +# DP: Upstream status: Not submitted +# DP: Date: 2005-01-20 + +if [ $# -ne 2 ]; then +echo 2 `basename $0`: script expects -patch|-unpatch as argument +exit 1 +fi +case $1 in +-patch) patch -d $2 -f --no-backup-if-mismatch -p1 $0;; +-unpatch) patch -d $2 -f --no-backup-if-mismatch -R -p1 $0;; +*) + echo 2 `basename $0`: script expects -patch|-unpatch as argument + exit 1 +esac +exit 0 + +# append the patch here and adjust the -p? flag in the patch calls. +--- glibc-2.3.2/Makeconfig 2004-05-10 19:32:23.0 +0200 glibc-2.3.2/Makeconfig 2004-05-10 19:30:33.0 +0200 +@@ -178,6 +178,12 @@ + endif + inst_slibdir = $(install_root)$(slibdir) + ++# Extra places to look for libraries ++ifndef extra_libdir ++extra_libdir := $(exec_prefix)/lib/$(shell gcc -dumpmachine):/lib/$(shell gcc -dumpmachine) ++endif ++ ++ + # Prefix to put on files installed in $(libdir). For libraries `libNAME.a', + # the prefix is spliced between `lib' and the name, so the linker switch + # `-l$(libprefix)NAME' finds the library; for other files the prefix is +@@ -482,6 +488,10 @@ + default-rpath = $(libdir) + endif + ++ifdef extra_libdir ++default-rpath += :$(extra_libdir) ++endif ++ + ifndef link-extra-libs + ifeq (yes,$(build-shared)) + ifneq ($(common-objpfx),$(objpfx)) diff -u glibc-2.3.5/debian/patches/00list glibc-2.3.5/debian/patches/00list --- glibc-2.3.5/debian/patches/00list +++ glibc-2.3.5/debian/patches/00list @@ -84,0 +85 @@ +99_multiarch-ld ---End Message--- ---BeginMessage--- Version: 2.3.6-2 This bug has been fixed in version 2.3.6-2, using a slightly different patch. Closing the bug. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net ---End Message---
r1234 - in glibc-package/trunk/debian: . debhelper.in local/usr_sbin
Author: schizo
Date: 2006-02-24 15:18:03 + (Fri, 24 Feb 2006)
New Revision: 1234
Modified:
glibc-package/trunk/debian/changelog
glibc-package/trunk/debian/debhelper.in/libc.postinst
glibc-package/trunk/debian/local/usr_sbin/tzconfig
Log:
* Get rid of -o as a binary operator to [ in tzconfig and postinst.
Modified: glibc-package/trunk/debian/changelog
===
--- glibc-package/trunk/debian/changelog2006-02-24 14:38:44 UTC (rev
1233)
+++ glibc-package/trunk/debian/changelog2006-02-24 15:18:03 UTC (rev
1234)
@@ -4,6 +4,9 @@
* Use a shell function instead of ifneq when testing a variable depending on
$(curpass), otherwise it is only evaluated at the first pass.
+ [ Clint Adams ]
+ * Get rid of -o as a binary operator to [ in tzconfig and postinst.
+
-- Aurelien Jarno [EMAIL PROTECTED] Thu, 23 Feb 2006 21:46:25 +0100
glibc (2.3.6-2) unstable; urgency=low
Modified: glibc-package/trunk/debian/debhelper.in/libc.postinst
===
--- glibc-package/trunk/debian/debhelper.in/libc.postinst 2006-02-24
14:38:44 UTC (rev 1233)
+++ glibc-package/trunk/debian/debhelper.in/libc.postinst 2006-02-24
15:18:03 UTC (rev 1234)
@@ -180,7 +180,7 @@
# something weird happened and the new libdb2 is unpacked before we
# get here.
if [ -e /lib/libdb.so.3.old ]; then
- if [ -L /lib/libdb.so.3 -o ! -e /lib/libdb.so.3 ]; then
+ if [ -L /lib/libdb.so.3 ] || [ ! -e /lib/libdb.so.3 ]; then
rm -f /lib/libdb.so.3
cat /lib/libdb.so.3.old /lib/libdb.so.3
fi
@@ -297,7 +297,7 @@
check=$check inetd atd
rl=$(runlevel | awk '{print $2}')
for service in $check; do
- if [ -f /usr/share/file-rc/rc -o -f /usr/lib/file-rc/rc ] [
-f /etc/runlevel.conf ]; then
+ if [ -f /usr/share/file-rc/rc ] || [ -f /usr/lib/file-rc/rc ]
[ -f /etc/runlevel.conf ]; then
idl=$(filerc $rl $service)
else
idl=$(ls /etc/rc${rl}.d/S??${service} 2 /dev/null | head
-1)
@@ -341,7 +341,7 @@
echo Restarting services possibly affected by the upgrade:
failed=
for service in $services; do
- if [ -f /usr/share/file-rc/rc -o -f /usr/lib/file-rc/rc
] [ -f /etc/runlevel.conf ]; then
+ if [ -f /usr/share/file-rc/rc ] || [ -f
/usr/lib/file-rc/rc ] [ -f /etc/runlevel.conf ]; then
idl=$(filerc $rl $service)
else
idl=$(ls /etc/rc${rl}.d/S??${service} 2 /dev/null
| head -1)
Modified: glibc-package/trunk/debian/local/usr_sbin/tzconfig
===
--- glibc-package/trunk/debian/local/usr_sbin/tzconfig 2006-02-24 14:38:44 UTC
(rev 1233)
+++ glibc-package/trunk/debian/local/usr_sbin/tzconfig 2006-02-24 15:18:03 UTC
(rev 1234)
@@ -48,7 +48,7 @@
echo Your current time zone is set to `cat /etc/timezone`
echo -n Do you want to change that? [n]:
read ans
- if [ x$ans = x -o $ans = n -o $ans = no ]; then
+ if [ x$ans = x ] || [ $ans = n ] || [ $ans = no ]; then
echo Your time zone will not be changed
exit 0
fi
@@ -57,7 +57,7 @@
echo Your current time zone is set to $oldtimezone
echo -n Do you want to change that? [n]:
read ans
- if [ x$ans = x -o $ans = n -o $ans = no ]; then
+ if [ x$ans = x ] || [ $ans = n ] || [ $ans = no ]; then
echo Your time zone will not be changed
exit 0
fi
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
r1235 - in glibc-package/trunk/debian: . control.in rules.d sysdeps
Author: aurel32
Date: 2006-02-24 16:00:22 + (Fri, 24 Feb 2006)
New Revision: 1235
Added:
glibc-package/trunk/debian/control.in/powerpc
glibc-package/trunk/debian/sysdeps/ppc64.mk
Modified:
glibc-package/trunk/debian/changelog
glibc-package/trunk/debian/control
glibc-package/trunk/debian/control.in/main
glibc-package/trunk/debian/rules.d/control.mk
Log:
* Add support for the ppc64 architecture. (Closes: #301438).
Modified: glibc-package/trunk/debian/changelog
===
--- glibc-package/trunk/debian/changelog2006-02-24 15:18:03 UTC (rev
1234)
+++ glibc-package/trunk/debian/changelog2006-02-24 16:00:22 UTC (rev
1235)
@@ -3,6 +3,7 @@
[ Aurelien Jarno]
* Use a shell function instead of ifneq when testing a variable depending on
$(curpass), otherwise it is only evaluated at the first pass.
+ * Add support for the ppc64 architecture. (Closes: #301438).
[ Clint Adams ]
* Get rid of -o as a binary operator to [ in tzconfig and postinst.
Modified: glibc-package/trunk/debian/control
===
--- glibc-package/trunk/debian/control 2006-02-24 15:18:03 UTC (rev 1234)
+++ glibc-package/trunk/debian/control 2006-02-24 16:00:22 UTC (rev 1235)
@@ -8,7 +8,7 @@
kfreebsd-kernel-headers [kfreebsd-i386],
gcc-4.0 [!m68k], gcc-3.4 [m68k], binutils (= 2.16.1cvs20051109-1),
autoconf, sed (= 4.0.5-4), gawk, debhelper (= 4.1.76),
- libc6-dev-amd64 [i386], libc6-dev-ppc64 [powerpc], libc6-dev-i386 [amd64] |
ia32-libs-dev (= 1.5) [amd64],
+ libc6-dev-amd64 [i386], libc6-dev-ppc64 [powerpc], libc6-dev-i386 [amd64] |
ia32-libs-dev (= 1.5) [amd64], libc6-dev-powerpc [ppc64],
quilt
Build-Depends-Indep: perl, po-debconf
Maintainer: GNU Libc Maintainers debian-glibc@lists.debian.org
@@ -45,7 +45,7 @@
by default. This created a package that unpacked to an excess of 30 megs.
Package: nscd
-Architecture: alpha amd64 arm armeb i386 m68k mips mipsel powerpc sparc ia64
hppa s390 sh3 sh4 sh3eb sh4eb kfreebsd-i386
+Architecture: alpha amd64 arm armeb i386 m68k mips mipsel powerpc ppc64 sparc
ia64 hppa s390 sh3 sh4 sh3eb sh4eb kfreebsd-i386
Section: admin
Priority: optional
Depends: libc6 (= ${Source-Version})
@@ -56,7 +56,7 @@
slow Services like LDAP, NIS or NIS+
Package: libc6
-Architecture: amd64 arm armeb i386 m68k mips mipsel powerpc sparc s390 hppa
sh3 sh4 sh3eb sh4eb
+Architecture: amd64 arm armeb i386 m68k mips mipsel powerpc ppc64 sparc s390
hppa sh3 sh4 sh3eb sh4eb
Section: libs
Priority: required
Provides: ${locale-compat:Depends}
@@ -67,7 +67,7 @@
Timezone data is also included.
Package: libc6-dev
-Architecture: amd64 arm armeb i386 m68k mips mipsel powerpc sparc s390 hppa
sh3 sh4 sh3eb sh4eb
+Architecture: amd64 arm armeb i386 m68k mips mipsel powerpc ppc64 sparc s390
hppa sh3 sh4 sh3eb sh4eb
Section: libdevel
Priority: standard
Depends: libc6 (= ${Source-Version})
@@ -77,7 +77,7 @@
and link programs which use the standard C library.
Package: libc6-dbg
-Architecture: amd64 arm armeb i386 m68k mips mipsel powerpc sparc s390 hppa
sh3 sh4 sh3eb sh4eb
+Architecture: amd64 arm armeb i386 m68k mips mipsel powerpc ppc64 sparc s390
hppa sh3 sh4 sh3eb sh4eb
Section: libdevel
Priority: extra
Provides: libc-dbg
@@ -91,7 +91,7 @@
Most people will not need this package.
Package: libc6-prof
-Architecture: amd64 arm armeb i386 m68k mips mipsel powerpc sparc s390 hppa
sh3 sh4 sh3eb sh4eb
+Architecture: amd64 arm armeb i386 m68k mips mipsel powerpc ppc64 sparc s390
hppa sh3 sh4 sh3eb sh4eb
Section: libdevel
Priority: extra
Depends: libc6 (= ${Source-Version})
@@ -100,7 +100,7 @@
with gprof.
Package: libc6-pic
-Architecture: amd64 arm armeb i386 m68k mips mipsel powerpc sparc s390 hppa
sh3 sh4 sh3eb sh4eb
+Architecture: amd64 arm armeb i386 m68k mips mipsel powerpc ppc64 sparc s390
hppa sh3 sh4 sh3eb sh4eb
Section: libdevel
Priority: optional
Conflicts: libc-pic
@@ -115,7 +115,7 @@
Package: libc6-udeb
XC-Package-Type: udeb
-Architecture: amd64 arm armeb i386 m68k mips mipsel powerpc sparc s390 hppa
sh3 sh4 sh3eb sh4eb
+Architecture: amd64 arm armeb i386 m68k mips mipsel powerpc ppc64 sparc s390
hppa sh3 sh4 sh3eb sh4eb
Section: debian-installer
Priority: extra
Provides: libc6, libc-udeb, ${locale-compat:Depends}
@@ -431,6 +431,27 @@
which use the standard C library. This is the 64bit version of the
library, meant for AMD64 systems.
+Package: libc6-powerpc
+Architecture: ppc64
+Section: libs
+Priority: standard
+Depends: libc6 (= ${Source-Version})
+Description: GNU C Library: 32bit powerpc shared libraries for ppc64
+ This package includes shared versions of the standard C
+ library and the standard math library, as well as many others.
+ This is the 32bit version of the library, meant for ppc64 systems.
+
+Package: libc6-dev-powerpc
+Architecture: ppc64
+Section: libdevel
+Priority:
Bug#174270: libc6: debians i386 build of glibc incompatible with coroutines
Note that this bug is fixed if you are using a 2.6 kernel. The libc6 package provides an NPTL version of the GNU libc, which is used when running a 2.6 kernel. It is built with MIN_KERNEL_SUPPORTED=2.6. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337368: marked as done (libc6: New upstream version 2.3.6 released)
Your message dated Fri, 24 Feb 2006 17:30:58 +0100 with message-id [EMAIL PROTECTED] and subject line Bug#337368: libc6: New upstream version 2.3.6 release has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Package: libc6 Severity: wishlist Perhaps this might help with some of the annoying toolchain problems plaguing us? ---BeginMessage--- -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Version 2.3.6 of the GNU C Library is now available for download at: http://ftp.gnu.org/gnu/glibc/ ftp://ftp.gnu.org/gnu/glibc/ ftp://sources.redhat.com/pub/glibc/releases/ Please see http://www.gnu.org/order/ftp.html and http://sources.redhat.com/mirrors.html for mirror sites around the world. This release contains only bug fixes, as will future 2.3.x releases. The following bugs in version 2.3.5 are resolved in 2.3.6: 38, 253, 549, 622, 653, 721, 758, 851, 877, 915, 934, 955, 961, 1016, 1037, 1076, 1079, 1080, 1081, 1082, 1083, 1084, 1085, 1086, 1087, 1088, 1090, 1091, 1092, 1093, 1094, 1095, 1096, 1097, 1098, 1099, 1100, 1101, 1102, 1103, 1104, 1105, 1106, 1107, 1108, 1109, 1110, , 1112, 1113, 1125, 1137, 1138, 1249, 1250, 1251, 1252, 1253, 1254, 1350, 1358, 1394, 1438, 1498, 1534 Visit http://sources.redhat.com/bugzilla/ for the details of each bug. For information on reporting bugs in the GNU C Library, see: http://www.gnu.org/software/libc/bugs.html Be advised that updating the C library is no trivial task and it is very easy to damage one's system. Unless you are interested in helping with the development and maintenance of the C library yourself, you will find it much easier to use a binary distribution instead. The code in this release has already been built and tested by maintainers of GNU/Linux and GNU/Hurd binary distributions basing their systems on it. This release can be compiled using GCC 4.0, but you should expect many more compiler warnings than when using GCC 3.4. The development version of libc is better suited to being built with the most recent GCC versions. The following files are available: bfdce99f82d6dbcb64b7f11c05d6bc96 glibc-2.3.6.tar.bz2 (14M) 49dbe06ce830fc73874d6b38bdc5b4db glibc-libidn-2.3.6.tar.bz2(99K) d4eeda37472666a15cc1f407e9c987a9 glibc-linuxthreads-2.3.6.tar.bz2 (238K) 40dce745d34ff80401da2fdfe58f6d53 glibc-ports-2.3.6.tar.bz2 (139K) ae7cb7da3f7c75869fe895101164b15d glibc-2.3.6.tar.gz(18M) 772eac4f7ae2e450346c3314898e9d1b glibc-libidn-2.3.6.tar.gz (123K) 3ac87e9bb424a66f36bc4bb9d851a765 glibc-linuxthreads-2.3.6.tar.gz (320K) b27c2640591d01417b2e02993799330e glibc-ports-2.3.6.tar.gz (197K) Note the `linuxthreads' package is required to build a useful system C library for use with Linux kernels prior to version 2.6. To build a configuration supporting only Linux 2.6 kernels or to build for GNU/Hurd, the package is not required. The main glibc-2.3.6 release package contains the Native POSIX Threads Library (NPTL) contributed by Ulrich Drepper, which supports Linux 2.6 kernels only. Many thanks to these people, who contributed fixes found in this release: Ulrich Drepper Jakub Jelinek Thorsten Kukuk Andreas Jaeger GOTO Masanori Thomas Schwinge H.J. Lu Bob Wilson James A. Morrison Alexandre Oliva Denis Barbier Neal H. Walfield Alfred M. Szmidt Richard Henderson Dmitry V. Levin Andreas Schwab Karl Kelley Darin Petkov Steven Munroe Enjoy! Roland McGrath for the GNU C Library Developers -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 http://mailcrypt.sourceforge.net/ iD8DBQFDar6J2vc1Cn671iURAhAMAJ9X2ESxY6cut25iAqqYIWVdxXNlEgCfYoex ZcqG0Yd1lfHPQPFjKS32VBg= =bKUq -END PGP SIGNATURE- ___ GNU Announcement mailing list info-gnu@gnu.org http://lists.gnu.org/mailman/listinfo/info-gnu ---End Message--- ---End Message--- ---BeginMessage--- Version: 2.3.6-1. glibc version 2.3.6 is in unstable for a couple of weeks. Closing the bug. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED]
Bug#354241: libc6: Dynamic loader doesn't support R_PARISC_PLABEL21L and R_PARISC_PLABEL14R
Package: libc6 Version: 2.3.5-13 Severity: normal The following two fails occur in the CVS binutils testsuite: Running /home/dave/binutils-2.16.91/src/ld/testsuite/ld-pie/pie.exp ... gcc -L/home/dave/binutils-2.16.91/objdir/./ld -pie /home/dave/binutils-2.16.91/s rc/ld/testsuite/ld-pie/pie.c -o tmpdir/pie gcc -B/home/dave/binutils-2.16.91/objdir/ld/tmpdir/gas/ -I/home/dave/binutils-2 .16.91/src/ld/testsuite/ld-pie -g -O2 -L/home/dave/binutils-2.16.91/objdir/./l d -c -g -O2 -fPIC -c /home/dave/binutils-2.16.91/src/ld/testsuite/ld-pie/weakund ef.c -o tmpdir/weakundef.o gcc -L/home/dave/binutils-2.16.91/objdir/./ld -B/home/dave/binutils-2.16.91/objd ir/ld/tmpdir/ld/ -L/home/dave/opt/gnu/hppa-linux/lib -L/home/dave/opt/gnu/lib -L /usr/local/lib -L/lib -L/usr/lib -o tmpdir/weakundef -L/home/dave/binutils-2.16 .91/src/ld/testsuite/ld-pie -pie tmpdir/weakundef.o Running: tmpdir/weakundef tmpdir/weakundef.out tmpdir/weakundef: error while loading shared libraries: unexpected reloc type 0x 42 FAIL: weak undefined gcc -B/home/dave/binutils-2.16.91/objdir/ld/tmpdir/gas/ -I/home/dave/binutils-2 .16.91/src/ld/testsuite/ld-pie -g -O2 -L/home/dave/binutils-2.16.91/objdir/./l d -c -g -O2 -fPIC -c /home/dave/binutils-2.16.91/src/ld/testsuite/ld-pie/weakund ef-data.c -o tmpdir/weakundef-data.o gcc -L/home/dave/binutils-2.16.91/objdir/./ld -B/home/dave/binutils-2.16.91/objd ir/ld/tmpdir/ld/ -L/home/dave/opt/gnu/hppa-linux/lib -L/home/dave/opt/gnu/lib -L /usr/local/lib -L/lib -L/usr/lib -o tmpdir/weakundef-data -L/home/dave/binutils -2.16.91/src/ld/testsuite/ld-pie -pie tmpdir/weakundef-data.o Running: tmpdir/weakundef-data tmpdir/weakundef-data.out tmpdir/weakundef-data: error while loading shared libraries: unexpected reloc ty pe 0x42 FAIL: weak undefined data This is the link for the first fail: /home/dave/binutils-2.16.91/objdir/ld/tmpdir/ld/ld --eh-frame-hdr -dynamic-linke r /lib/ld.so.1 -pie -o tmpdir/weakundef /usr/lib/gcc/hppa-linux-gnu/4.0.3/../../ ../Scrt1.o /usr/lib/gcc/hppa-linux-gnu/4.0.3/../../../crti.o /usr/lib/gcc/hppa-l inux-gnu/4.0.3/crtbeginS.o -L/home/dave/binutils-2.16.91/objdir/./ld -L/home/dav e/opt/gnu/hppa-linux/lib -L/home/dave/opt/gnu/lib -L/usr/local/lib -L/lib -L/usr /lib -L/home/dave/binutils-2.16.91/src/ld/testsuite/ld-pie -L/home/dave/binutils -2.16.91/objdir/ld/tmpdir/ld -L/usr/lib/gcc/hppa-linux-gnu/4.0.3 -L/usr/lib/gcc/ hppa-linux-gnu/4.0.3 -L/usr/lib/gcc/hppa-linux-gnu/4.0.3/../../.. tmpdir/weakund ef.o -v -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s - -no-as-needed /usr/lib/gcc/hppa-linux-gnu/4.0.3/crtendS.o /usr/lib/gcc/hppa-linu x-gnu/4.0.3/../../../crtn.o GNU ld version 2.16.91 20060224 The problematic relocations come from here: [EMAIL PROTECTED]:~/binutils-2.16.91/objdir/ld$ objdump -r /usr/lib/Scrt1.o|less /usr/lib/Scrt1.o: file format elf32-hppa-linux RELOCATION RECORDS FOR [.text]: OFFSET TYPE VALUE R_PARISC_PLABEL21L main 0004 R_PARISC_PLABEL14R main 0010 R_PARISC_PLABEL21L __libc_csu_init 0014 R_PARISC_PLABEL14R __libc_csu_init 0018 R_PARISC_PLABEL21L __libc_csu_fini 001c R_PARISC_PLABEL14R __libc_csu_fini I believe that a patch was submitted by Carlos O'Donell to fix this bug. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (650, 'testing'), (90, 'unstable') Architecture: hppa (parisc64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13-pa1 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#353611: Please update debconf PO translation for the package glibc 2.3.6-2
On Monday, February 20, 2006 at 22.27.03, [EMAIL PROTECTED] wrote: You are noted as the last translator of the debconf translation for glibc. The English template has been changed, and now some messages are marked fuzzy in your translation or are missing. I would be grateful if you could take the time and update it. Updated italian translation is attached. Cheers, Luca it.po.gz Description: GNU Zip compressed data
Bug#354241: marked as done (libc6: Dynamic loader doesn't support R_PARISC_PLABEL21L and R_PARISC_PLABEL14R)
Your message dated Fri, 24 Feb 2006 22:06:47 +0100 with message-id [EMAIL PROTECTED] and subject line Bug#354241: libc6: Dynamic loader doesn't support R_PARISC_PLABEL21L and R_PARISC_PLABEL14R has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Package: libc6 Version: 2.3.5-13 Severity: normal The following two fails occur in the CVS binutils testsuite: Running /home/dave/binutils-2.16.91/src/ld/testsuite/ld-pie/pie.exp ... gcc -L/home/dave/binutils-2.16.91/objdir/./ld -pie /home/dave/binutils-2.16.91/s rc/ld/testsuite/ld-pie/pie.c -o tmpdir/pie gcc -B/home/dave/binutils-2.16.91/objdir/ld/tmpdir/gas/ -I/home/dave/binutils-2 .16.91/src/ld/testsuite/ld-pie -g -O2 -L/home/dave/binutils-2.16.91/objdir/./l d -c -g -O2 -fPIC -c /home/dave/binutils-2.16.91/src/ld/testsuite/ld-pie/weakund ef.c -o tmpdir/weakundef.o gcc -L/home/dave/binutils-2.16.91/objdir/./ld -B/home/dave/binutils-2.16.91/objd ir/ld/tmpdir/ld/ -L/home/dave/opt/gnu/hppa-linux/lib -L/home/dave/opt/gnu/lib -L /usr/local/lib -L/lib -L/usr/lib -o tmpdir/weakundef -L/home/dave/binutils-2.16 .91/src/ld/testsuite/ld-pie -pie tmpdir/weakundef.o Running: tmpdir/weakundef tmpdir/weakundef.out tmpdir/weakundef: error while loading shared libraries: unexpected reloc type 0x 42 FAIL: weak undefined gcc -B/home/dave/binutils-2.16.91/objdir/ld/tmpdir/gas/ -I/home/dave/binutils-2 .16.91/src/ld/testsuite/ld-pie -g -O2 -L/home/dave/binutils-2.16.91/objdir/./l d -c -g -O2 -fPIC -c /home/dave/binutils-2.16.91/src/ld/testsuite/ld-pie/weakund ef-data.c -o tmpdir/weakundef-data.o gcc -L/home/dave/binutils-2.16.91/objdir/./ld -B/home/dave/binutils-2.16.91/objd ir/ld/tmpdir/ld/ -L/home/dave/opt/gnu/hppa-linux/lib -L/home/dave/opt/gnu/lib -L /usr/local/lib -L/lib -L/usr/lib -o tmpdir/weakundef-data -L/home/dave/binutils -2.16.91/src/ld/testsuite/ld-pie -pie tmpdir/weakundef-data.o Running: tmpdir/weakundef-data tmpdir/weakundef-data.out tmpdir/weakundef-data: error while loading shared libraries: unexpected reloc ty pe 0x42 FAIL: weak undefined data This is the link for the first fail: /home/dave/binutils-2.16.91/objdir/ld/tmpdir/ld/ld --eh-frame-hdr -dynamic-linke r /lib/ld.so.1 -pie -o tmpdir/weakundef /usr/lib/gcc/hppa-linux-gnu/4.0.3/../../ ../Scrt1.o /usr/lib/gcc/hppa-linux-gnu/4.0.3/../../../crti.o /usr/lib/gcc/hppa-l inux-gnu/4.0.3/crtbeginS.o -L/home/dave/binutils-2.16.91/objdir/./ld -L/home/dav e/opt/gnu/hppa-linux/lib -L/home/dave/opt/gnu/lib -L/usr/local/lib -L/lib -L/usr /lib -L/home/dave/binutils-2.16.91/src/ld/testsuite/ld-pie -L/home/dave/binutils -2.16.91/objdir/ld/tmpdir/ld -L/usr/lib/gcc/hppa-linux-gnu/4.0.3 -L/usr/lib/gcc/ hppa-linux-gnu/4.0.3 -L/usr/lib/gcc/hppa-linux-gnu/4.0.3/../../.. tmpdir/weakund ef.o -v -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s - -no-as-needed /usr/lib/gcc/hppa-linux-gnu/4.0.3/crtendS.o /usr/lib/gcc/hppa-linu x-gnu/4.0.3/../../../crtn.o GNU ld version 2.16.91 20060224 The problematic relocations come from here: [EMAIL PROTECTED]:~/binutils-2.16.91/objdir/ld$ objdump -r /usr/lib/Scrt1.o|less /usr/lib/Scrt1.o: file format elf32-hppa-linux RELOCATION RECORDS FOR [.text]: OFFSET TYPE VALUE R_PARISC_PLABEL21L main 0004 R_PARISC_PLABEL14R main 0010 R_PARISC_PLABEL21L __libc_csu_init 0014 R_PARISC_PLABEL14R __libc_csu_init 0018 R_PARISC_PLABEL21L __libc_csu_fini 001c R_PARISC_PLABEL14R __libc_csu_fini I believe that a patch was submitted by Carlos O'Donell to fix this bug. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (650, 'testing'), (90, 'unstable') Architecture: hppa (parisc64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13-pa1 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- no debconf information ---End Message--- ---BeginMessage--- Version: 2.3.6-1 John David Anglin a écrit : Package: libc6 Version: 2.3.5-13 Severity: normal The following two fails occur in the CVS binutils testsuite: Running /home/dave/binutils-2.16.91/src/ld/testsuite/ld-pie/pie.exp ... gcc -L/home/dave/binutils-2.16.91/objdir/./ld -pie /home/dave/binutils-2.16.91/s rc/ld/testsuite/ld-pie/pie.c -o tmpdir/pie gcc -B/home/dave/binutils-2.16.91/objdir/ld/tmpdir/gas/ -I/home/dave/binutils-2 .16.91/src/ld/testsuite/ld-pie -g -O2 -L/home/dave/binutils-2.16.91/objdir/./l d -c -g -O2 -fPIC -c /home/dave/binutils-2.16.91/src/ld/testsuite/ld-pie/weakund ef.c -o tmpdir/weakundef.o gcc -L/home/dave
r1236 - in glibc-package/trunk/debian: . patches patches/locale patches/localedata
Author: barbier Date: 2006-02-24 21:49:39 + (Fri, 24 Feb 2006) New Revision: 1236 Added: glibc-package/trunk/debian/patches/localedata/locale-ro_RO.diff Modified: glibc-package/trunk/debian/changelog glibc-package/trunk/debian/patches/locale/iso4217-RON.diff glibc-package/trunk/debian/patches/localedata/first_weekday.diff glibc-package/trunk/debian/patches/series Log: Update localedata/locales/ro_RO. Thanks Eddy Petri?\197?\159or. (Closes: #347173) Modified: glibc-package/trunk/debian/changelog === --- glibc-package/trunk/debian/changelog2006-02-24 16:00:22 UTC (rev 1235) +++ glibc-package/trunk/debian/changelog2006-02-24 21:49:39 UTC (rev 1236) @@ -8,6 +8,9 @@ [ Clint Adams ] * Get rid of -o as a binary operator to [ in tzconfig and postinst. + [ Denis Barbier ] + * Update localedata/locales/ro_RO. Thanks Eddy Petrişor. (Closes: #347173) + -- Aurelien Jarno [EMAIL PROTECTED] Thu, 23 Feb 2006 21:46:25 +0100 glibc (2.3.6-2) unstable; urgency=low Modified: glibc-package/trunk/debian/patches/locale/iso4217-RON.diff === --- glibc-package/trunk/debian/patches/locale/iso4217-RON.diff 2006-02-24 16:00:22 UTC (rev 1235) +++ glibc-package/trunk/debian/patches/locale/iso4217-RON.diff 2006-02-24 21:49:39 UTC (rev 1236) @@ -13,10 +13,11 @@ === --- locale/iso-4217.def.orig +++ locale/iso-4217.def -@@ -127,6 +127,7 @@ +@@ -126,7 +126,7 @@ + DEFINE_INT_CURR(PLN)/* Polish Zloty */ DEFINE_INT_CURR(PYG)/* Paraguay Guarani */ DEFINE_INT_CURR(QAR)/* Qatar Rial */ - DEFINE_INT_CURR(ROL)/* Romanian Leu */ +-DEFINE_INT_CURR(ROL)/* Romanian Leu */ +DEFINE_INT_CURR(RON)/* New Romanian Leu */ DEFINE_INT_CURR(RUR)/* Russian Ruble */ DEFINE_INT_CURR(RWF)/* Rwanda Franc */ Modified: glibc-package/trunk/debian/patches/localedata/first_weekday.diff === --- glibc-package/trunk/debian/patches/localedata/first_weekday.diff 2006-02-24 16:00:22 UTC (rev 1235) +++ glibc-package/trunk/debian/patches/localedata/first_weekday.diff 2006-02-24 21:49:39 UTC (rev 1236) @@ -1670,19 +1670,6 @@ END LC_TIME LC_PAPER -Index: localedata/locales/ro_RO -=== localedata/locales/ro_RO.orig -+++ localedata/locales/ro_RO -@@ -189,6 +189,8 @@ - date_fmt U0025U0061U0020U0025U0062U0020U0025U0065/ - U0020U0025U0048U003AU0025U004DU003AU0025U0053U0020/ - U0025U005AU0020U0025U0059 -+% FIXME: found in CLDR -+first_weekday 2 - END LC_TIME - - LC_PAPER Index: localedata/locales/ru_RU === --- localedata/locales/ru_RU.orig Added: glibc-package/trunk/debian/patches/localedata/locale-ro_RO.diff === --- glibc-package/trunk/debian/patches/localedata/locale-ro_RO.diff 2006-02-24 16:00:22 UTC (rev 1235) +++ glibc-package/trunk/debian/patches/localedata/locale-ro_RO.diff 2006-02-24 21:49:39 UTC (rev 1236) @@ -0,0 +1,408 @@ +# All lines beginning with `# DP:' are a description of the patch. +# DP: Description: Fix Romanian locale +# DP: Dpatch author: Eddy Petrisor [EMAIL PROTECTED] +# DP: Patch author: Eddy Petrisor [EMAIL PROTECTED] +# DP: Upstream status: BZ2125 +# DP: Date: 2006-02-24 + +2006-01-07 Eddy Petrisor [EMAIL PROTECTED] + + * locales/ro_RO: Correct the sorting order of the letters a + circumflex and a with breve according to the Romanian alphabet. + * locales/ro_RO: Do not use capital A with breve within day names + * locales/ro_RO: Use Romanian post-92 writing rules within day + * locales/ro_RO: After denomination starting with the 1st of July 2005, + int'l currency symbol is RON (1 RON = 1 ROL); + see http://publications.eu.int/code/en/en-5000700.htm; + * locales/ro_RO: groupping sign for thousands is .; group of 3 + * locales/ro_RO: short date format is %d.%m.%Y for RO + * locales/ro_RO: placed year before time in date_fmt + * locales/ro_RO: replaced %Z with %z in date formats because %Z is not + used nor widely known in Romania, and Romania uses daylight saving and + the difference is more obvious this way + * locales/ro_RO: changed abday for Saturday as i looks bad and is + incorrect according to post-92 rules + * locales/ro_RO: do not capitalize months and days as it is not correct + in Romanian + * locales/ro_RO: A4 is the prefered paper type; metric system is used + (removed FIXMEs) + * locales/ro_RO: added country_name, country_car,
