Bug#891505: glibc: Causes FTBFS of gcc-8 on hurd-i386

2018-02-26 Thread Samuel Thibault
Svante Signell, on lun. 26 févr. 2018 11:22:22 +0100, wrote:
> creates a defect gen-sysinfo.go file when libc0.3 >= 2.26-* is installed.

A lot of cleanup has happened, yes. The question is what actually made
gcc-8 to break. Just looking at the diff of the build logs, there's

  could not determine number of signals

which seems to come from ./src/libgo/mksigtab.sh, which uses the _NSIG
definition, which does have changed indeed, and the script doesn't seem
to properly deal with it: it discovers the

  #define _NSIG (__SIGRTMAX + 1)

redirection, but not the 

  #define __SIGRTMAX __SIGRTMIN

redirection

To confirm this hypothesis, you could modify your
/usr/include/i386-gnu/bits/signum-generic.h

from

  #define _NSIG  (__SIGRTMAX + 1)

to 

  #define _NSIG  32

and check that gcc-8 then builds fine.  It then means that
./src/libgo/mksigtab.sh needs to be improved to take into account the
abovementioned redirections, like it does between _NSIG and __SIGRTMAX

Samuel



Bug#28250: closed by Credible Finance <y_mai...@yahoo.com> (reply to Credible Finance <crediblefinance....@gmail.com>) (Apply for a Personal/Business Loan)

2018-02-26 Thread Ian Jackson
Control: reopen -1
Control: retitle -1 perl can lose output due to stdio buffering
Control: found -1 5.20.2-3+deb8u9

Debian Bug Tracking System writes ("Bug#28250 closed by Credible Finance 
 (reply to Credible Finance 
) (Apply for a Personal/Business Loan)"):
> It has been closed by Credible Finance  (reply to 
> Credible Finance ).

spam

Also, here is a modern repro.

Reference behaviour in non-buggy case:

chiark:~> perl -mautodie -e '$|=1; print "hi" or die $!; flush STDOUT' 
>/dev/full 
No space left on device at -e line 1.
chiark:~> echo $?
28

Observed behaviour in buggy case:

chiark:~> perl -mautodie -e 'print "hi" or die $!; flush STDOUT' >/dev/full 
chiark:~> echo $?
0

Desired behaviour: print a message to stderr, mentioning at least the
errno value and ideally also the descriptor number or stream name, and
exit nonzero.

I think this is a bug in the libc (#28251).  This does not seem to
have been accepted by libc developers.  Instead the Unix world has
engaged in a decades-long campaign to work around it in all
application softwware.

Ian.



Processed: Re: Bug#28250 closed by Credible Finance <y_mai...@yahoo.com> (reply to Credible Finance <crediblefinance....@gmail.com>) (Apply for a Personal/Business Loan)

2018-02-26 Thread Debian Bug Tracking System
Processing control commands:

> reopen -1
Bug #28250 [libc6] libc should unilaterally report buffered write error on close
Bug #28251 [libc6] libc should unilaterally report buffered write error on close
Bug 28250 is not marked as done; doing nothing.
> retitle -1 perl can lose output due to stdio buffering
Bug #28250 [libc6] libc should unilaterally report buffered write error on close
Bug #28251 [libc6] libc should unilaterally report buffered write error on close
Changed Bug title to 'perl can lose output due to stdio buffering' from 'libc 
should unilaterally report buffered write error on close'.
Changed Bug title to 'perl can lose output due to stdio buffering' from 'libc 
should unilaterally report buffered write error on close'.
> found -1 5.20.2-3+deb8u9
Bug #28250 [libc6] perl can lose output due to stdio buffering
Bug #28251 [libc6] perl can lose output due to stdio buffering
There is no source info for the package 'libc6' at version '5.20.2-3+deb8u9' 
with architecture ''
Unable to make a source version for version '5.20.2-3+deb8u9'
Marked as found in versions 5.20.2-3+deb8u9.
Marked as found in versions 5.20.2-3+deb8u9.

-- 
28250: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=28250
28251: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=28251
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Processed: Re: Bug#28251 closed by Credible Finance <y_mai...@yahoo.com> (reply to Credible Finance <crediblefinance....@gmail.com>) (Apply for a Personal/Business Loan)

2018-02-26 Thread Debian Bug Tracking System
Processing control commands:

> reopen -1
Bug #28251 [libc6] libc should cause programs which leave stuff in stdio to fail
Bug #28250 [libc6] should libc force programs to check stdout/stderr/stdin for 
errors?
Bug 28251 is not marked as done; doing nothing.
> retitle -1 libc should unilaterally report buffered write error on close
Bug #28251 [libc6] libc should cause programs which leave stuff in stdio to fail
Bug #28250 [libc6] should libc force programs to check stdout/stderr/stdin for 
errors?
Changed Bug title to 'libc should unilaterally report buffered write error on 
close' from 'libc should cause programs which leave stuff in stdio to fail'.
Changed Bug title to 'libc should unilaterally report buffered write error on 
close' from 'should libc force programs to check stdout/stderr/stdin for 
errors?'.

-- 
28250: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=28250
28251: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=28251
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#28251: closed by Credible Finance <y_mai...@yahoo.com> (reply to Credible Finance <crediblefinance....@gmail.com>) (Apply for a Personal/Business Loan)

2018-02-26 Thread Ian Jackson
Control: reopen -1
Control: retitle -1 libc should unilaterally report buffered write error on 
close

Debian Bug Tracking System writes ("Bug#28251 closed by Credible Finance 
 (reply to Credible Finance 
) (Apply for a Personal/Business Loan)"):
> It has been closed by Credible Finance  (reply to 
> Credible Finance ).

spam



Bug#891505: glibc: Causes FTBFS of gcc-8 on hurd-i386

2018-02-26 Thread Svante Signell
On Mon, 2018-02-26 at 11:52 +0100, Samuel Thibault wrote:
> Svante Signell, on lun. 26 févr. 2018 11:49:46 +0100, wrote:
> > Ok, here it is. Be prepared that there are duplicates tough, since the
> > entries
> > are generated in different order. (I've made a partial edit by moving around
> > stuff, but that is not complete)
> 
> Rather than moving around by hand, please just process it through
> "sort", so we are sure that there is no manual editting error, for
> instance
> 
> -// unknowndefine SIGRTMAX (__libc_current_sigrtmax ())// unknowndefine REG_GS
> REG_GS
> +// unknowndefine REG_GS REG_GS
> 
> looks very suspicious.

Attached is a diff file of the sorted entries.--- nOK/gen-sysinfo.go.sorted	2018-02-26 12:03:02.446185024 +0100
+++ OK/gen-sysinfo.go.sorted	2018-02-26 12:03:09.162185200 +0100
@@ -1,4 +1,3 @@
-
 const _ACCESSPERMS = (_S_IRWXU|_S_IRWXG|_S_IRWXO)
 const _AF_APPLETALK = _PF_APPLETALK
 const _AF_CCITT = _PF_CCITT
@@ -180,8 +179,6 @@
 const __BITS_BYTESWAP_H = 1
 const __BITS_CONDITION_ATTR_H = 1
 const __BITS_CONDITION_H = 1
-const __BITS_CPU_SET_H = 1
-const __BITS_ERRNO_H = 1
 const ___BITS_IOCTLS_H = 1
 const __BITS_MUTEX_ATTR_H = 1
 const __BITS_MUTEX_H = 1
@@ -190,36 +187,23 @@
 const __BITS_POSIX2_LIM_H = 1
 const __BITS_POSIX_OPT_H = 1
 const __BITS_PTHREAD_H = 1
-const __BITS_PTHREADTYPES_ARCH_H = 1
 const __BITS_PTHREADTYPES_H = 1
 const __BITS_RWLOCK_ATTR_H = 1
-const __BITS_SCHED_H = 1
 const __BITS_SEMAPHORE_H = 1
 const __BITS_SIGCONTEXT_H = 1
-const __BITS_SIGEVENT_CONSTS_H = 1
-const __BITS_SIGINFO_CONSTS_H = 1
-const __BITS_SIGNUM_GENERIC_H = 1
-const __BITS_SIGNUM_H = 1
 const __BITS_SIGSTACK_H = 1
 const __BITS_SIGTHREAD_H = 1
 const __BITS_SOCKADDR_H = 1
 const ___BITS_SOCKET_H = 1
 const __BITS_SPIN_LOCK_H = 1
-const __BITS_SS_FLAGS_H = 1
 const __BITS_STAT_H = 1
-const __BITS_STDINT_INTN_H = 1
-const __BITS_STDINT_UINTN_H = 1
 const __BITS_SYSMACROS_H = 1
 const __BITS_THREAD_ATTR_H = 1
 const __BITS_THREAD_SPECIFIC_H = 1
 const __BITS_TIME_H = 1
 const __BITS_TYPES_H = 1
 const __BITS_TYPESIZES_H = 1
-const __BITS_TYPES___LOCALE_T_H = 1
-const __BITS_TYPES_LOCALE_T_H = 1
 const __BITS_UINTN_IDENTITY_H = 1
-const __BITS_UIO_EXT_H = 1
-const __BITS_UIO_LIM_H = 1
 const __BITS_WCHAR_H = 1
 const ___BIT_TYPES_DEFINED__ = 1
 const _BRKINT = (1 << 1)
@@ -702,7 +686,6 @@
 const _ETXTBSY = 1073741850
 const _EUSERS = 1073741892
 const _EVENP = 0x0080
-const _EWOULDBLOCK = _EAGAIN
 const _EXDEV = 1073741842
 const _EXPR_NEST_MAX = __POSIX2_EXPR_NEST_MAX
 const _EXTA = 19200
@@ -856,7 +839,6 @@
 const _FNOCTTY = _O_NOCTTY
 const _FNONBLOCK = _O_NONBLOCK
 const _F_OK = 0
-const ___FORCE_ERROR_T_CODES_SIGNED = -1
 const _FPC_DE = 0x0002
 const _FPC_DM = _FPC_DE
 const _FPC_IC = 0x1000
@@ -948,15 +930,11 @@
 const ___GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 = 1
 const ___GCC_IEC_559 = 2
 const ___GCC_IEC_559_COMPLEX = 2
-const __GETOPT_CORE_H = 1
-const __GETOPT_POSIX_H = 1
 const ___GLIBC__ = 2
 const ___glibc_c99_flexarr_available = 1
-const ___GLIBC_MINOR__ = 26
-const ___GLIBC_USE_DEPRECATED_GETS = 0
+const ___GLIBC_MINOR__ = 25
 const ___GLIBC_USE_IEC_60559_BFP_EXT = 1
 const ___GLIBC_USE_IEC_60559_FUNCS_EXT = 1
-const ___GLIBC_USE_IEC_60559_TYPES_EXT = 1
 const ___GLIBC_USE_LIB_EXT2 = 1
 const ___GNU__ = 1
 const ___GNUC__ = 8
@@ -987,7 +965,6 @@
 const _HAVE_FACCESSAT = 1
 const _HAVE_FCHMODAT = 1
 const _HAVE_FCHOWNAT = 1
-const ___HAVE_GENERIC_SELECTION = 1
 const _HAVE_GETIPINFO = 1
 const _HAVE_GETXATTR = 1
 const _HAVE_INTTYPES_H = 1
@@ -1019,10 +996,14 @@
 const _HAVE_SEM_TIMEDWAIT = 1
 const _HAVE_SETENV = 1
 const _HAVE_SETXATTR = 1
+const ___have_sigevent_t = 1
+const ___have_siginfo_t = 1
+const ___have_sigval_t = 1
 const _HAVE_SINL = 1
 const _HAVE_STDINT_H = 1
 const _HAVE_STDLIB_H = 1
 const _HAVE_STRERROR_R = 1
+const __HAVE_STRING_ARCH_mempcpy = 1
 const _HAVE_STRING_H = 1
 const _HAVE_STRINGS_H = 1
 const _HAVE_STRSIGNAL = 1
@@ -1221,7 +1202,6 @@
 const _IOC_INOUT = 3
 const _IOC_OUT = 1
 const _IOC_VOID = 0
-const ___iovec_defined = 1
 const _IP_ADD_MEMBERSHIP = 12
 const _IPDEFTTL = 64
 const _IP_DF = 0x4000
@@ -1583,8 +1563,7 @@
 const ___NETINET_IP_H = 1
 const __NETINET_TCP_H = 1
 const __NET_ROUTE_H = 1
-const ___NGREG = 19
-const _NGREG = ___NGREG
+const _NGREG = 19
 const _NGROUPS_MAX = 256
 const _NI_DGRAM = 16
 const _NI_IDN = 32
@@ -1611,8 +1590,8 @@
 const _NOHANG = 0x0100
 const _NOKERNINFO = (1 << 25)
 const _NO_RECOVERY = 3
+const __NSIG = 33
 const _NSIG = __NSIG
-const __NSIG = (___SIGRTMAX + 1)
 const _NSS_BUFLEN_GROUP = 1024
 const _NSS_BUFLEN_PASSWD = 1024
 const _NZERO = 20
@@ -2059,7 +2038,6 @@
 const _RTMSG_NEWROUTE = 0x21
 const _RTMSG_NEWRULE = 0x31
 const _RUSAGE_CHILDREN = -1
-const ___rusage_defined = 1
 const _RUSAGE_SELF = 0
 const _SA_INTERRUPT = 0
 const _SA_NOCLDSTOP = 0x0008
@@ -2378,13 +2356,11 @@
 const _S_IFREG = ___S_IFREG
 const ___S_IFSOCK = 014
 const _S_IFSOCK = ___S_IFSOCK
-const _SIGABRT = 6
 const _SIGALRM 

Processed: reopening 28251

2018-02-26 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> reopen 28251
Bug #28251 [libc6] libc should cause programs which leave stuff in stdio to fail
Bug #28250 [libc6] should libc force programs to check stdout/stderr/stdin for 
errors?
Bug 28251 is not marked as done; doing nothing.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
28250: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=28250
28251: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=28251
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#891505: glibc: Causes FTBFS of gcc-8 on hurd-i386

2018-02-26 Thread Samuel Thibault
Svante Signell, on lun. 26 févr. 2018 11:49:46 +0100, wrote:
> Ok, here it is. Be prepared that there are duplicates tough, since the entries
> are generated in different order. (I've made a partial edit by moving around
> stuff, but that is not complete)

Rather than moving around by hand, please just process it through
"sort", so we are sure that there is no manual editting error, for
instance

-// unknowndefine SIGRTMAX (__libc_current_sigrtmax ())// unknowndefine REG_GS 
REG_GS
+// unknowndefine REG_GS REG_GS

looks very suspicious.

Samuel



Processed: reopening 28250

2018-02-26 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> reopen 28250
Bug #28250 {Done: Credible Finance } [libc6] should libc 
force programs to check stdout/stderr/stdin for errors?
Bug #28251 {Done: Credible Finance } [libc6] libc should 
cause programs which leave stuff in stdio to fail
Bug reopened
Ignoring request to alter fixed versions of bug #28250 to the same values 
previously set
Ignoring request to alter fixed versions of bug #28251 to the same values 
previously set
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
28250: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=28250
28251: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=28251
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#891505: glibc: Causes FTBFS of gcc-8 on hurd-i386

2018-02-26 Thread Samuel Thibault
Hello,

Svante Signell, on lun. 26 févr. 2018 11:22:22 +0100, wrote:
> Attached is a diff of gen-sysinfo generated with glibc-2.26-6 and glibc-2.25-5
> installed: (edited to show only a subset of the diff)

Please send the whole file. There are always evil details in the corners
which do matter.

Samuel



Bug#28251: marked as done (libc should cause programs which leave stuff in stdio to fail)

2018-02-26 Thread Debian Bug Tracking System
Your message dated Mon, 26 Feb 2018 10:22:36 + (UTC)
with message-id <1165894864.8333533.1519640556...@mail.yahoo.com>
and subject line Apply for a Personal/Business Loan
has caused the Debian Bug report #28250,
regarding libc should cause programs which leave stuff in stdio to fail
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 this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
28250: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=28250
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: libc6
Version: 2.0.7t-1
Severity: grave

Many programs (even the standard hello world examples) do this
 int main(void) {
   if (!fputs("hello world\n",stdout)) { perror("stdout"); exit(-1); }
   return 0;
 }

Of course stdout is usually buffered, and the error isn't reported by
the kernel until the implicit close(0) done at exit, but then there is
no application for the libc to pass the error to.

1. All programs which do this are buggy in the sense that they won't
work correctly on any UN*X when the disk becomes full, if they have
less than a stdio buffer of output.  I have filed a several bug
reports about this - some years ago I got `echo' fixed (both /bin/echo
and the builtins in bash and tcsh) - and now I've reported the same
bug in mawk, GNU sed and printf (from shellutils).

2. libc should either:

(a) Cause these programs to fail all the time (eg, the implicit
close(0) should be replaced by a call which aborts if there is
anything in stdio buffers).  This would allow these programs to be
detected, because they'd all break.  This would affect nearly every
stdio-using program, which would all have to be fixed, and should not
be done just before a release :-).  There would have to be an
environment variable to turn the behaviour off for old programs, so
that people can have useability if not reliability.

or

(b) It should do the error handling itself.  Ie, if the implicit
close(0) fails then libc should print a message to stderr (if
possible) and exit with status 255.

I prefer (b) because it means that we don't have to change many
programs, however it is somewhat lazier, and doesn't result in the bug
being fixed anywhere but glibc-based systems.

Neither of (a) or (b) is likely to be standards-compliant, but if the
standard is to be broken then we shouldn't follow it.

Ian.
--- End Message ---
--- Begin Message ---


Credible Loan Application Form.docx
Description: MS-Word 2007 document
--- End Message ---


Bug#891505: glibc: Causes FTBFS of gcc-8 on hurd-i386

2018-02-26 Thread Svante Signell
Source: glibc
Version: 2.26-6
Severity: important
Affects: gcc-8 glibc-2.26-*
User: debian-h...@lists.debian.org
Usertags: hurd

Hi,

glibc versions > 2.25-6 breaks all builds of gcc-8-*/gccgo on GNU/Hurd due to
that -fdump-go-spec is broken.

>From the buildd logs of gcc-8:
8-20180218-1 (sid)  Maybe-Failed 2018-02-18 19:12:07
8-20180207-2 (sid)  Maybe-Failed 2018-02-07 23:22:42
8-20180130-1 (experimental) Maybe-Failed 2018-01-30 22:09:03
8-20180123-1 (experimental) Maybe-Failed 2018-01-24 08:22:30
8-20180110-1 (experimental) Maybe-Failed 2018-01-13 12:14:53
Maybe-Failed 2018-01-13 02:51:42
8-20171229-1 (experimental) Maybe-Successful 2018-01-02 03:39:06

Toolchain package versions: 2018-01-24
binutils_2.29.1-13 dpkg-dev_1.19.0.4 g++-7_7.2.0-19 gcc-7_7.2.0-19 gnumach-
dev_2:1.8+git20171101-1 hurd-dev_1:0.9.git20180108-1 libc0.3-dev_2.26-3
libstdc++-7-dev_7.2.0-19 libstdc++6_7.2.0-19
Toolchain package versions: 2018-01-02
binutils_2.29.1-12 dpkg-dev_1.19.0.4 g++-7_7.2.0-18 gcc-7_7.2.0-18 gnumach-
dev_2:1.8+git20171101-1 hurd-dev_1:0.9.git20171119-3 libc0.3-dev_2.25-6
libstdc++-7-dev_7.2.0-18 libstdc++6_7.2.0-18

The packages in the build environment was downgraded for the failing build and
the only package affecting the build was the libc version.

On gcc-8-8-20171229 the command:

/home/srs/DEBs/gcc-8/gcc-8-8-20171229/build/./gcc/xgcc -B/home/srs/DEBs/gcc-
8/gcc-8-8-20171229/build/./gcc/ -B/usr/i686-gnu/bin/ -B/usr/i686-gnu/lib/ 
-isystem /usr/i686-gnu/include -isystem /usr/i686-gnu/sys-include -isystem
/home/srs/DEBs/gcc-8/gcc-8-8-20171229/build/sys-include-DHAVE_CONFIG_H -I. 
-I../../../src/libgo  -I ../../../src/libgo/runtime 
-I../../../src/libgo/../libffi/include -I../libffi/include -pthread  
-D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O 
-fdump-go-spec=tmp-gen-sysinfo.go -std=gnu99 -S -o sysinfo.s
../../../src/libgo/sysinfo.c
rm -f sysinfo.s
/bin/bash ../../../src/libgo/mvifdiff.sh tmp-gen-sysinfo.go gen-sysinfo.go

creates a defect gen-sysinfo.go file when libc0.3 >= 2.26-* is installed.

Attached is a diff of gen-sysinfo generated with glibc-2.26-6 and glibc-2.25-5
installed: (edited to show only a subset of the diff)

Thanks!--- nOK/gen-sysinfo.go	2018-02-26 10:39:57.970054114 +0100
+++ OK/gen-sysinfo.go	2018-02-26 01:07:07.0 +0100
@@ -137,3 +137,4 @@
 // unknowndefine DT_WHT DT_WHT
 // unknowndefine SSIZE_MAX LONG_MAX
 // unknowndefine NULL ((void *)0)
+// unknowndefine EPERM _HURD_ERRNO (1)
...
+// unknowndefine ENOTRECOVERABLE _HURD_ERRNO (121)
 // unknowndefine errno (*__errno_location ())
 // unknowndefine O_READ O_RDONLY
 // unknowndefine O_WRITE O_WRONLY
@@ -156,6 +259,7 @@
 // unknowndefine SIG_DFL ((__sighandler_t) 0)
 // unknowndefine SIG_IGN ((__sighandler_t) 1)
 // unknowndefine SIG_HOLD ((__sighandler_t) 2)
+// unknowndefine SIGABRT SIGIOT
 // unknowndefine SI_ASYNCIO SI_ASYNCIO
 // unknowndefine SI_MESGQ SI_MESGQ
 // unknowndefine SI_TIMER SI_TIMER
@@ -196,6 +300,7 @@
 // unknowndefine POLL_ERR POLL_ERR
 // unknowndefine POLL_PRI POLL_PRI
 // unknowndefine POLL_HUP POLL_HUP
+// unknowndefine SIGEV_PAD_SIZE ((SIGEV_MAX_SIZE / sizeof (int)) - 3)
 // unknowndefine SIGEV_SIGNAL SIGEV_SIGNAL
 // unknowndefine SIGEV_NONE SIGEV_NONE
 // unknowndefine SIGEV_THREAD SIGEV_THREAD
@@ -211,8 +316,7 @@
 // unknowndefine NULL ((void *)0)
 // unknowndefine SS_ONSTACK SS_ONSTACK
 // unknowndefine SS_DISABLE SS_DISABLE
-// unknowndefine SIGRTMIN (__libc_current_sigrtmin ())
-// unknowndefine SIGRTMAX (__libc_current_sigrtmax ())// unknowndefine REG_GS REG_GS
+// unknowndefine REG_GS REG_GS
 // unknowndefine REG_FS REG_FS
 // unknowndefine REG_ES REG_ES
 // unknowndefine REG_DS REG_DS


Bug#28250: marked as done (should libc force programs to check stdout/stderr/stdin for errors?)

2018-02-26 Thread Debian Bug Tracking System
Your message dated Mon, 26 Feb 2018 10:22:36 + (UTC)
with message-id <1165894864.8333533.1519640556...@mail.yahoo.com>
and subject line Apply for a Personal/Business Loan
has caused the Debian Bug report #28250,
regarding should libc force programs to check stdout/stderr/stdin for errors?
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 this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
28250: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=28250
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: perl
Version: 5.004.04-06
Severity: grave

chiark:~> cat junk/t
hi
chiark:~> perl -pe '1;'  perl -pe '1;' /dev/full
chiark:~> echo $?
0
chiark:~> ll -i /usr/bin/perl*
 188425 -rwxr-xr-x   2 root root   491964 Jun  5 09:55 /usr/bin/perl*
 188425 -rwxr-xr-x   2 root root   491964 Jun  5 09:55 
/usr/bin/perl5.00404*
 188666 -rwxr-xr-x   1 root root28612 Jun  5 09:55 /usr/bin/perlbug*
 188667 -rwxr-xr-x   1 root root12644 Jun  5 09:55 /usr/bin/perldoc*
chiark:~> dpkg -S /usr/bin/perl5.00404
perl-base: /usr/bin/perl5.00404
chiark:~> dpkg -l perl-base
Desired=Unknown/Install/Remove/Purge
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ NameVersionDescription
+++-===-==-
ii  perl-base   5.004.04-6 The Pathologically Eclectic Rubbish Lister
chiark:~>
--- End Message ---
--- Begin Message ---


Credible Loan Application Form.docx
Description: MS-Word 2007 document
--- End Message ---