Re: [parisc-linux] J5600 Video
> I think you will fail. > If I remember correctly Vodoo3 needs the on-board i386 Graphics-BIOS to get > into a useful state which can be used by vodoo fbdev driver. > Vodoo1 or Vodoo2 do work as framebuffer devices though. The voodoo1/2 were designed as add on boards so there is enough info in the docs to boot them, and in the source tree for glide to boot them properly. The voodoo3 glide source tree may contain enough info, its hard to tell. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Photoshop, Windows, Office
See attached pict. http://snt.softwandownload.com/ - Everyone turned to look at her Oh Lord, she really didnt have Shes English. Cameron roared t She bumped into Iain. She trie <>
Bug#480433: libc6.1: mkdtemp on ia64 can return xa non null pointer not pointing at the template
Package: libc6.1 Version: 2.7-10 Severity: normal Affects IA64 only Code like... static char buf[20]; strcpy(buf, "/tmp/some_XX"); char * tmpname=mkdtemp(buf); can return tmpname which is non null and for which *tmpname seg faults because it is not a valid address i.e. it does not point at the buf. The template will have been modified correctly to point at a unique name. So a workaround is to add if (!tmpname) tmpname=buf; Bug affects latest version of f2c-20061008-1 on IA64 (to reproduce run with no arguments, call is in the set_temp_names function) -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: ia64 Kernel: Linux 2.6.18-dsa-mckinley (SMP w/2 CPU cores) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages libc6.1 depends on: ii libgcc1 1:4.3.0-4 GCC support library libc6.1 recommends no packages. -- debconf information: glibc/upgrade: true glibc/restart-services: glibc/restart-failed: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#550428: getaddrinfo: AI_CANNONAME should not do PTR lookups
Package: libc6
Version: 2.7-18
Severity: normal
I'm reporting essentially a duplicate of this old bug:
http://sources.redhat.com/bugzilla/show_bug.cgi?id=304
That bug is marked "resolved" but it clearly isn't resolved, since
getaddrinfo() still has a __gethostbyaddr_r() call in it (see
sysdeps/posix/getaddrinfo.c). This bug isn't resolved until that code is
dead! As far as I can tell, that code is still present in the newest glibc
and eglibc too.
Here's a little demonstration, with actual DNS records that exist today:
mail.gnu.org. 300 IN A 199.232.76.166
166.76.232.199.in-addr.arpa. 23360 IN CNAME rev-c76-166.gnu.org.
rev-c76-166.gnu.org.300 IN PTR mail.gnu.org.
rev-c76-166.gnu.org.300 IN PTR mx10.gnu.org.
mx10.gnu.org. 300 IN A 199.232.76.166
mail.gnu.org does not have a CNAME record. If you ask for the canonical name
of mail.gnu.org, the correct answer is mail.gnu.org. But glibc does a reverse
lookup, picks one of the PTRs at not-quite-random, and half the time you get
mx10.gnu.org instead:
$ cat canon.c
#include
#include
#include
int main(void)
{
struct addrinfo *res, hints={.ai_family=AF_INET, .ai_flags=AI_CANONNAME};
int err;
puts((err=getaddrinfo("mail.gnu.org", NULL, &hints, &res)) ?
gai_strerror(err) : res->ai_canonname);
return err;
}
$ cc canon.c -o canon
$ ./canon
mx10.gnu.org
$ ./canon
mail.gnu.org
$ ./canon
mx10.gnu.org
Neither mx10.gnu.org nor mail.gnu.org is the canonical name of the other. No
such relationship exists between those 2 names, and no such relationship can
ever be implied by any PTR records. glibc's behavior is completely bogus.
I believe a correct fix would be to reduce that entire block containing the
__gethostbyaddr_r() call to just these 2 lines:
if (canon == NULL)
canon = orig_name;
But there's a sign that may not be enough. Each time I run the demo program
above, it generates the bogus PTR query twice. I wonder if removing the
__gethostbyaddr_r will take care of both of them, or if there's a similar bug
in the nss_dns module.
-- System Information:
Debian Release: 5.0.3
APT prefers stable
APT policy: (500, 'stable')
Architecture: powerpc (ppc)
Kernel: Linux 2.6.31.2
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Versions of packages libc6 depends on:
ii libgcc1 1:4.3.2-1.1 GCC support library
libc6 recommends no packages.
Versions of packages libc6 suggests:
ii glibc-doc 2.7-18 GNU C Library: Documentation
pn locales(no description available)
-- debconf information:
* glibc/upgrade: true
glibc/restart-failed:
* glibc/restart-services: rsync openbsd-inetd lpd cron atd
--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#551154: libc6-prof: undefined reference to `_dl_prof_resolve'
Package: libc6-prof
Version: 2.7-18
Severity: important
$ cat myprog.c
int main(void)
{
return 0;
}
$ gcc -g -pg -o myprog myprog.c -static-libgcc -lc_p
/usr/lib/gcc/powerpc-linux-gnu/4.3.2/../../../../lib/libc_p.a(dl-machine.op):
In function `__elf_machine_runtime_setup':
(.text+0xd56): undefined reference to `_dl_prof_resolve'
/usr/lib/gcc/powerpc-linux-gnu/4.3.2/../../../../lib/libc_p.a(dl-machine.op):
In function `__elf_machine_runtime_setup':
(.text+0xd5a): undefined reference to `_dl_prof_resolve'
collect2: ld returned 1 exit status
$
Note the gcc command line above is an exact copy of the example in
README.Debian, but it doesn't work. I can't find a way to get this
_dl_prof_resolve linked in. nm /lib/lib* /usr/lib/lib* finds it only in
/usr/lib/libc.a
I haven't made much of an effort to find out what _dl_prof_resolve is
supposed to do, but I did notice that it's defined in
sysdeps/powerpc/powerpc32/dl-trampoline.S, inside #ifndef PROF, which makes
me wonder, is that backwards? A function with "prof" in its name, that's
defined everywhere but the profiling library? Could I fix this by taking the
'n' out of #ifndef?
-- System Information:
Debian Release: 5.0.3
APT prefers stable
APT policy: (500, 'stable')
Architecture: powerpc (ppc)
Kernel: Linux 2.6.31.2
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Versions of packages libc6-prof depends on:
ii libc6 2.7-18 GNU C Library: Shared libraries
libc6-prof recommends no packages.
libc6-prof suggests no packages.
-- debconf-show failed
--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#403709: nss_compat: infinite retrying of read errors
Package: libc6
Version: 2.3.2.ds1-22sarge4
Severity: minor
Due to a recent power failure, my /etc/shadow file morphed into a directory.
You can probably guess that this made it difficult to log in. You might not
guess the symptom: instead of reporting an authentication failure in the
normal way, any attempt to log in causes a long pause with lots of disk
activity. That's because getspnam() gets stuck in an infinite loop allocating
memory and ends up swapping. No one expected the Spanish Inquisition^W^W^W^H
an EISDIR on /etc/shadow.
After poking around the source a bit, and recreating the incident in a
chroot, I suspect but haven't proven that the cause is in
compat-spwd.c:getspent_next_file which returns NSS_STATUS_TRYAGAIN in case of
read error. What exactly is NSS_STATUS_TRYAGAIN supposed to mean? Apparently
in this case it means "try again as many times as you can, as fast as you
can".
Oh, I just got an idea for another test: fgetspent. And it does the same
infinite memory-eating thing, in spite of not using NSS at all!
#include
#include
int main(void)
{
FILE *fp;
struct spwd *sp;
fp=fopen(".", "r");
if(!fp) {
perror("fopen(.)");
return 1;
}
sp=fgetspent(fp);
return 0;
}
Also bombs with fgetpwent and fgetgrent. I suspect it'll do the same with any
read error, not just EISDIR. They all get translated to ERANGE for some
reason, which is then taken as meaning "You need to malloc some more and try
again". Ouch.
nss_files seems to be the only one who got this right.
-- System Information:
Debian Release: 3.1
Architecture: powerpc (ppc)
Kernel: Linux 2.6.17.6
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages libc6 depends on:
ii libdb1-compat 2.1.3-7The Berkeley database routines [gl
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#414222: tzdata: please update to upstream version 2007c
Package: tzdata Version: 2007b-1 Severity: minor Pulaski County, Indiana, which switched to Central time zone last year during the Indiana daylight savings shake-up, have changed their minds. This year they're coming back to Eastern. tzdata 2007c contains this change. I'm unable to confirm the existence of any Debian installations in Pulaski County (I live one county over), and it's probably too late now to get the update pushed out before the switch happens (it's about 30 hours away as I write this). Sorry I didn't notice sooner... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Changing thread limits in glibc
Hello- I am trying to increase the thread limits on my machine to accomodate a java application. I am doing this while following the instructions on www.volano.com. I am to the point where I am trying to increase the STACK_SIZE and PTHREAD_THREADS_MAX in the glibc source. I have done an "apt-get source libc6" in order to pull everythng down. I have edited the header files a couple of times and then tried to re-build the package with "dpkg-buildpackage -rfakeroot -uc -us" only to get the following error during the package build: dpkg-source: building glibc using existing glibc_2.1.3.orig.tar.gz dpkg-source: building glibc in glibc_2.1.3-13.diff.gz dpkg-source: cannot represent change to glibc-linuxthreads-2.1.3.tar: binary file contents changed dpkg-source: warning: ignoring deletion of file glibc-linuxthreads-2.1.3.tar.bz2 dpkg-source: building glibc in glibc_2.1.3-13.dsc dpkg-source: unrepresentable changes to source This is the first time I have tried re-building a package so it is entirely possible that I am editing the wrong instance of the header files. Any help or tips would be greatly appreciated. My machine info- 2.2.18pre21 #1 Sat Nov 18 18:47:15 EST 2000 i686 unknown -- Regards- Alan Holcomb
Re: [PATCH] glibc 2.2.94 - hppa - plt relocations
On Sun, Sep 22, 2002 at 05:23:02PM -0700, Ulrich Drepper wrote: > Carlos O'Donell wrote: > > The next patch fixes plt relocations for hppa. > > Unfortunately this requires 'map' to be passed around > > like a hot potato. Any comments on this patch would > > be much appreciated. > > This patch definitely will not go in. It makes code on sane > architectures run slower without any reason. Every elf_machine_rel*_relative function is declared "static inline". They're all small functions. Therefore, gcc will inline them, and unused parameters will be optimised away. This is not just an idle claim. x86 ld.so built using current gcc has zero differences in generated code after the hppa patch is applied, with the exception of a couple of assert line numbers. Can you show even one architecture where ld.so will "run slower"? > Why don't you step back and redesign the relocations. I don't see the > need for something as this approach. It may be possible to redesign the relocations, or at least the hppa dl-machine.h code, but I don't have time and I think the approach used in the patch is the cleanest available. eg. another approach would be to add the load address to the ltp entry, but RELA targets shouldn't be reading section contents. This would also require a binutils change as ld currently leaves the field zero. I'll also note that the patch as it stands should be rejected for another reason, and that is that it isn't complete. eg. I needed to patch sysdeps/i386/dl-machine.h elf_machine_rela_relative to add the extra param. -- Alan Modra IBM OzLabs - Linux Technology Centre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] glibc 2.2.94 - hppa - revised plt relocation patch
On Wed, Sep 25, 2002 at 01:32:46PM -0400, Carlos O'Donell wrote: > > > +#define DO_ELF_MACHINE_REL_RELATIVE(map, l_addr, reloc) \ > > > + elf_machine_rel_relative (l_addr, reloc, \ > > > + (void *) (l_addr + relative->r_offset)) > >reloc Oops. Yes, this needs fixing. [snip] > The fact that it doesn't have detremental effects > is rather disconcerting. Not really. This macro is only used in one place, and "relative" is in scope where the macro is expanded. -- Alan Modra IBM OzLabs - Linux Technology Centre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#164766: Problem with VIA C3 chip and libcrypto
> >GCC 3.2 still uses CMOVE instructions on -march=i686.
> >
> >On the other hand:
> > {"c3", PROCESSOR_I486, PTA_MMX | PTA_3DNOW},
> >GCC disagrees with you that the C3 is an i686.
gcc uses i486 scheduling because that gives best performance
The situation is as follows
gcc "i686" definition is wrong. The gcc people wont fix it because the 686
definition without cmov is mostly useless anyway.
The C3 is a model 6 cpu, the kernel reports it correctly and wont change
Non Debian packaging systems know how to handle this and regard cmov as
a mandatory CPU attribute for 686 package install. Ugly but works.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#164766: Problem with VIA C3 chip and libcrypto
> I think it may be needed that we add -mcpu=c3 for gcc, which generates > i686 without cmov instruction. You want i486 scheduling for the C3 from testing so far. I've been talking to VIA about releasing all the optimisation info Alan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#314855: tr_TR.ISO-8859-9...LC_MONETARY: `int_curr_symbol' does not correspond to valid name
Package: locales Version: 2.3.5-1 Severity: serious Justification: the installation process breaks apt-get I just did an upgrade today, and locales fails to install, when it is working with tr_TR. Preparing to replace locales 2.3.2.ds1-21 (using /locales_2.3.5-1_all.deb) ... Unpacking replacement locales ... Setting up locales (2.3.5-1) ... Generating locales... [...] tr_TR.ISO-8859-9...LC_MONETARY: value of field `int_curr_symbol' does not correspond to a valid name in ISO 4217 dpkg: error processing locales (--configure): subprocess post-installation script returned error exit status 1 -- System Information: Debian Release: testing/unstable APT prefers experimental APT policy: (990, 'experimental'), (500, 'testing'), (500, 'stable'), (50, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.9 Locale: LANG=C, LC_CTYPE=C (charmap=ISO-8859-1) (ignored: LC_ALL set to en_CA) Versions of packages locales depends on: ii debconf 1.4.51 Debian configuration management sy ii libc6 [glibc-2.3.5-1] 2.3.5-1GNU C Library: Shared libraries an locales recommends no packages. -- debconf information: * locales/default_environment_locale: None * locales/locales_to_be_generated: be_BY CP1251, bg_BG CP1251, br_FR ISO-8859-1, [EMAIL PROTECTED] ISO-8859-15, cs_CZ ISO-8859-2, da_DK ISO-8859-1, [EMAIL PROTECTED] ISO-8859-15, de_AT ISO-8859-1, [EMAIL PROTECTED] ISO-8859-15, de_BE ISO-8859-1, de_CH ISO-8859-1, de_CH.UTF-8 UTF-8, [EMAIL PROTECTED] ISO-8859-15, de_DE ISO-8859-1, [EMAIL PROTECTED] UTF-8, de_DE.UTF-8 UTF-8, [EMAIL PROTECTED] ISO-8859-15, de_LU ISO-8859-1, el_GR ISO-8859-7, el_GR.UTF-8 UTF-8, en_AU ISO-8859-1, en_BW ISO-8859-1, en_CA ISO-8859-1, en_DK ISO-8859-1, en_GB ISO-8859-1, en_HK ISO-8859-1, [EMAIL PROTECTED] ISO-8859-15, en_IE ISO-8859-1, en_IN UTF-8, en_NZ ISO-8859-1, en_PH ISO-8859-1, en_SG ISO-8859-1, en_US ISO-8859-1, en_US.UTF-8 UTF-8, en_ZA ISO-8859-1, en_ZW ISO-8859-1, [EMAIL PROTECTED] ISO-8859-15, es_ES ISO-8859-1, es_US ISO-8859-1, et_EE ISO-8859-1, [EMAIL PROTECTED] ISO-8859-15, eu_ES ISO-8859-1, fa_IR.UTF-8 UTF-8, [EMAIL PROTECTED] ISO-8859-15, fi_FI ISO-8859-1, [EMAIL PROTECTED] ISO-8859-15, fr_BE ISO-8859-1, fr_CA ISO-8859-1, fr_CH ISO-8859-1, [EMAIL PROTECTED] ISO-8859-15, fr_FR ISO-8859-1, [EMAIL PROTECTED] ISO-8859-15, fr_LU ISO-8859-1, [EMAIL PROTECTED] ISO-8859-15, ga_IE ISO-8859-1, [EMAIL PROTECTED] ISO-8859-15, gl_ES ISO-8859-1, gv_GB ISO-8859-1, he_IL ISO-8859-8, hi_IN.UTF-8 UTF-8, hr_HR ISO-8859-2, hu_HU ISO-8859-2, id_ID ISO-8859-1, is_IS ISO-8859-1, it_CH ISO-8859-1, [EMAIL PROTECTED] ISO-8859-15, it_IT ISO-8859-1, iw_IL ISO-8859-8, ja_JP.EUC-JP EUC-JP, ja_JP.UTF-8 UTF-8, lt_LT ISO-8859-13, lv_LV ISO-8859-13, mi_NZ ISO-8859-13, mk_MK ISO-8859-5, mr_IN.UTF-8 UTF-8, ms_MY ISO-8859-1, mt_MT ISO-8859-3, [EMAIL PROTECTED] ISO-8859-15, nl_BE ISO-8859-1, [EMAIL PROTECTED] ISO-8859-15, nl_NL ISO-8859-1, nn_NO ISO-8859-1, no_NO ISO-8859-1, oc_FR ISO-8859-1, pl_PL ISO-8859-2, pt_BR ISO-8859-1, [EMAIL PROTECTED] ISO-8859-15, pt_PT ISO-8859-1, ru_RU ISO-8859-5, ru_RU.KOI8-R KOI8-R, ru_RU.UTF-8 UTF-8, ru_UA KOI8-U, sk_SK ISO-8859-2, sl_SI ISO-8859-2, sq_AL ISO-8859-1, [EMAIL PROTECTED] ISO-8859-15, sv_FI ISO-8859-1, sv_SE ISO-8859-1, ta_IN UTF-8, te_IN UTF-8, th_TH TIS-620, tr_TR ISO-8859-9, uk_UA KOI8-U, vi _VN.UTF-8 UTF-8, zh_CN.GB18030 GB18030, zh_CN GB2312, zh_CN.GBK GBK, zh_CN.UTF-8 UTF-8, zh_HK BIG5-HKSCS, zh_HK.UTF-8 UTF-8, zh_TW Big5, da_DK.ISO-8859-15 ISO-8859-15, en_GB.ISO-8859-15 ISO-8859-15, en_US.ISO-8859-15 ISO-8859-15, sv_SE.ISO-8859-15 ISO-8859-15 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Changing thread limits in glibc
Hello- I am trying to increase the thread limits on my machine to accomodate a java application. I am doing this while following the instructions on www.volano.com. I am to the point where I am trying to increase the STACK_SIZE and PTHREAD_THREADS_MAX in the glibc source. I have done an "apt-get source libc6" in order to pull everythng down. I have edited the header files a couple of times and then tried to re-build the package with "dpkg-buildpackage -rfakeroot -uc -us" only to get the following error during the package build: dpkg-source: building glibc using existing glibc_2.1.3.orig.tar.gz dpkg-source: building glibc in glibc_2.1.3-13.diff.gz dpkg-source: cannot represent change to glibc-linuxthreads-2.1.3.tar: binary file contents changed dpkg-source: warning: ignoring deletion of file glibc-linuxthreads-2.1.3.tar.bz2 dpkg-source: building glibc in glibc_2.1.3-13.dsc dpkg-source: unrepresentable changes to source This is the first time I have tried re-building a package so it is entirely possible that I am editing the wrong instance of the header files. Any help or tips would be greatly appreciated. My machine info- 2.2.18pre21 #1 Sat Nov 18 18:47:15 EST 2000 i686 unknown -- Regards- Alan Holcomb
Bug#774118: libc6:amd64: strspn generates compiler warning
Package: libc6
Version: 2.13-38+deb7u4
Severity: normal
A compiler warning message is generated by the following
test code and compiler options.
irwin@raven> cat >test_strspn.c
#include
#include
int
main(void) {
strcmp(" 8998797857586fasdfljf", " ");
strspn(" 8998797857586fasdfljf", " ");
strcspn(" 8998797857586fasdfljf", " ");
return 0;
}
^D
irwin@raven> gcc -O1 -Wconversion test_strspn.c
test_strspn.c: In function ‘main’:
test_strspn.c:6:3: warning: conversion to ‘long unsigned int’ from
‘int’ may change the sign of the result [-Wsign-conversion]
Note the warning message only occurs for line 6, and does not occur
for the very similar line 5 and line 7. In particular, strcspn has
the exact same return type, argument types, and number of arguments as
strspn, yet strspn generates the warning while strcspn does not.
Therefore, I am pretty sure this warning is due to some difference in
how the strspn and strcspn arguments or returns are defined in libc6
when those should be absolutely identical between the two functions.
That difference (as well as the warning itself about transformation
from int to long unsigned int) is a cause for concern about the
reliability of strspn. So I hope to see vigorous follow up.
-- System Information:
Debian Release: 7.6
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libc6:amd64 depends on:
ii libc-bin 2.13-38+deb7u4
ii libgcc1 1:4.7.2-5
libc6:amd64 recommends no packages.
Versions of packages libc6:amd64 suggests:
ii debconf [debconf-2.0] 1.5.49
ii glibc-doc 2.13-38+deb7u4
ii locales2.13-38+deb7u4
-- debconf information:
glibc/upgrade: true
glibc/restart-services:
* libraries/restart-without-asking: false
glibc/disable-screensaver:
glibc/restart-failed:
--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/20141229005654.5292.36550.reportbug@localhost.localdomain
Bug#774118: Additional information
Apparently, this bug has already been fixed with a two-line patch in the upstream git version of glibc (see <http://sourceware.org/git/?p=glibc.git;a=commit;h=1a4b75a190006bb013a61f2031a4de86e93a629f). So if this fix has not already been propagated to the Debian unstable version of libc please apply it. __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.02.1412281757140.23...@enira.zlyna.ubzr
Bug#774118: closed by Bastian Blank (Re: Bug#774118: Additional information)
This problem is actually fixed in Jessie. So I'm closing the bug report. Hi Bastian: Thanks for that further investigation, and I am glad to hear that once I update to Jessie, I will no longer be seeing these compiler warning messages each time I build one of the libraries for the timeephem software project. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.02.1412300938580.23...@enira.zlyna.ubzr
