[Bug libc/4416] setlocale can fail silently
https://sourceware.org/bugzilla/show_bug.cgi?id=4416 Andreas Schwab changed: What|Removed |Added Summary|setlocales can fail |setlocale can fail silently |silentely | -- You are receiving this mail because: You are watching the reporter of the bug. -- 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/bug-4416-1917-bnldyvn...@http.sourceware.org/bugzilla/
Bug#753542: Bug#753444: Bug#753542: perl-base - Segfaults in libperl.so.5.18
On 05/07/14 08:48, Niko Tyni wrote: > On Sat, Jul 05, 2014 at 02:27:02AM +0200, Emilio Pozuelo Monfort wrote: >> Although I would prefer to wait a bit and do 5.20 directly, I'm not affected >> by >> this breakage as I don't have any s390x machines. So if you think this is >> important enough, we could go ahead and do it now. The only conflict I see >> right >> now is gdal with the poppler transition, but that one should be finished in >> two >> or three days if everything goes well. > > Thanks. I don't use s390x either, but clearly there are people who do, and > broken upgrades for a few weeks don't seem acceptable to me. > > So do I wait until poppler is done? Please ping me when it's OK to upload. I have thought a bit more about this. I was hesitant as there are lots of packages involved, but thinking more about it, this should be pretty smooth. You add perlapi-5.18.2d to perl-base's Provides, but you won't remove perlapi-5.18.1 or perlapi-5.18.2. Then perl-base can migrate immediately, and all the rebuilds can migrate as well. Then after the rebuilds are done, you can remove perlapi-5.18.1 and perlapi-5.18.2 from Provides. > What do we do with packages that fail to build? Remove the old s390x > binaries from testing? The source packages are going to cause trouble > for the 5.20 transition too, of course... For leaf packages, we could possibly remove them. But why not just fix them wherever possible? Do you expect many FTBFS? Emilio -- 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/53b7c92c.9010...@debian.org
Bug#753542: Bug#753444: Bug#753542: perl-base - Segfaults in libperl.so.5.18
On Sat, Jul 05, 2014 at 11:45:16AM +0200, Emilio Pozuelo Monfort wrote: > On 05/07/14 08:48, Niko Tyni wrote: > I have thought a bit more about this. I was hesitant as there are lots of > packages involved, but thinking more about it, this should be pretty smooth. > You > add perlapi-5.18.2d to perl-base's Provides, but you won't remove > perlapi-5.18.1 > or perlapi-5.18.2. Then perl-base can migrate immediately, and all the > rebuilds > can migrate as well. Then after the rebuilds are done, you can remove > perlapi-5.18.1 and perlapi-5.18.2 from Provides. I'm not very enthusiastic about this. It's basically lying: we don't offer the old ABI anymore so we should be straight about it. An uninstallable package seems better than a broken one. But I can see it would help the transition, and it wouldn't cause a regression, it would just make the fix take longer. So yes, I can do that if you want. > > What do we do with packages that fail to build? Remove the old s390x > > binaries from testing? The source packages are going to cause trouble > > for the 5.20 transition too, of course... > > For leaf packages, we could possibly remove them. But why not just fix them > wherever possible? Do you expect many FTBFS? Sure, fixing them is certainly preferrable :) It's just that I've recently rebuilt the same set of packages for the 5.20 transition and ISTR encountering quite a few known long-standing FTBFS bugs. I suppose those packages aren't in testing anymore, though; I didn't look at that part much in my tests. -- Niko Tyni nt...@debian.org -- 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/20140705163118.GA5299@estella.local.invalid
Bug#753542: Bug#753444: Bug#753542: perl-base - Segfaults in libperl.so.5.18
Control: reassign -1 perl-base,release.debian.org Control: user release.debian@packages.debian.org Control: usertags -1 transition On 05/07/14 18:31, Niko Tyni wrote: > On Sat, Jul 05, 2014 at 11:45:16AM +0200, Emilio Pozuelo Monfort wrote: >> On 05/07/14 08:48, Niko Tyni wrote: > >> I have thought a bit more about this. I was hesitant as there are lots of >> packages involved, but thinking more about it, this should be pretty smooth. >> You >> add perlapi-5.18.2d to perl-base's Provides, but you won't remove >> perlapi-5.18.1 >> or perlapi-5.18.2. Then perl-base can migrate immediately, and all the >> rebuilds >> can migrate as well. Then after the rebuilds are done, you can remove >> perlapi-5.18.1 and perlapi-5.18.2 from Provides. > > I'm not very enthusiastic about this. It's basically lying: we don't offer > the old ABI anymore so we should be straight about it. An uninstallable > package seems better than a broken one. > > But I can see it would help the transition, and it wouldn't cause a > regression, it would just make the fix take longer. It would make the fix only take longer for people who do partial uploads, right? The users who do a dist-upgrade and get all the updated perl modules that we have binNMUed should be fine, right? And then after things have been rebuilt and any potential FTBFS have been fixed, we drop the old perlapi Provides, and then partial upgrades won't be possible (thus fixing that case as well). The alternative is delaying the migration until everything has been rebuilt and all the FTBFS bugs have been fixed. I think keeping the provides for now is a better option, but I don't know Perl so I may be missing something. If you want to drop them now, that's fine with me. > So yes, I can do that if you want. > >>> What do we do with packages that fail to build? Remove the old s390x >>> binaries from testing? The source packages are going to cause trouble >>> for the 5.20 transition too, of course... >> >> For leaf packages, we could possibly remove them. But why not just fix them >> wherever possible? Do you expect many FTBFS? > > Sure, fixing them is certainly preferrable :) It's just that I've > recently rebuilt the same set of packages for the 5.20 transition and > ISTR encountering quite a few known long-standing FTBFS bugs. I suppose > those packages aren't in testing anymore, though; I didn't look at that > part much in my tests. I suppose you don't have a list? #735623 could be a problem. #742409 as well. That's not an exhaustive list and I haven't checked if those could be removed from testing (if they are leaf packages). That's why I think a smooth transition (i.e. keeping the provides for now) would be preferable. That said, feel free to upload perl now. Regards, Emilio -- 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/53b832cc.1070...@debian.org
Processed (with 2 errors): Re: Bug#753444: Bug#753542: perl-base - Segfaults in libperl.so.5.18
Processing control commands: > reassign -1 perl-base,release.debian.org Bug #753542 [libc6] perl-base - Segfaults in libperl.so.5.18 Bug reassigned from package 'libc6' to 'perl-base,release.debian.org'. No longer marked as found in versions eglibc/2.19-1 and glibc/2.19-4. Ignoring request to alter fixed versions of bug #753542 to the same values previously set > user release.debian@packages.debian.org Unknown command or malformed arguments to command. > usertags -1 transition Unknown command or malformed arguments to command. -- 753542: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753542 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.b753542.140458056623285.transcr...@bugs.debian.org
Bug#753909: libc6-dev: netinet/in.h lacks several IPv6 socket options
Package: libc6-dev Version: 2.13-38+deb7u1 Severity: normal Tags: upstream ipv6 patch Dear Maintainer, I am writing a daemon program which uses IPv6 socket options specified in RFC 3542, and found some are not defined in but in . I tried to include but it conflicted with so I had to copy the definition into my program. This problem also applies to the upstream version. A patch for the glibc source code (version 2.19) is included below. --- sysdeps/unix/sysv/linux/bits/in.h 2014-07-06 11:02:37+09 1.1 +++ sysdeps/unix/sysv/linux/bits/in.h 2014-07-06 11:03:33+09 @@ -175,6 +175,9 @@ #define IPV6_RTHDR 57 #define IPV6_RECVDSTOPTS 58 #define IPV6_DSTOPTS 59 +#define IPV6_RECVPATHMTU 60 +#define IPV6_PATHMTU 61 +#define IPV6_DONTFRAG 62 #define IPV6_RECVTCLASS66 #define IPV6_TCLASS67 -- System Information: Debian Release: 7.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libc6-dev depends on: ii libc-dev-bin2.13-38+deb7u1 ii libc6 2.13-38+deb7u1 ii linux-libc-dev 3.2.57-3+deb7u2 Versions of packages libc6-dev recommends: ii gcc [c-compiler] 4:4.7.2-1 ii gcc-4.6 [c-compiler] 4.6.3-14 ii gcc-4.7 [c-compiler] 4.7.2-5 Versions of packages libc6-dev suggests: ii glibc-doc 2.13-38+deb7u1 ii manpages-dev 3.44-1 -- no debconf information --- sysdeps/unix/sysv/linux/bits/in.h 2014-07-06 11:02:37+09 1.1 +++ sysdeps/unix/sysv/linux/bits/in.h 2014-07-06 11:03:33+09 @@ -175,6 +175,9 @@ #define IPV6_RTHDR 57 #define IPV6_RECVDSTOPTS 58 #define IPV6_DSTOPTS 59 +#define IPV6_RECVPATHMTU 60 +#define IPV6_PATHMTU 61 +#define IPV6_DONTFRAG 62 #define IPV6_RECVTCLASS 66 #define IPV6_TCLASS 67
