Bug#617331: Pushing tzdata updates to stable in time
Hi, On Fri Mar 11, 2011 at 20:07:22 +, Adam D. Barratt wrote: > On Fri, 2011-03-11 at 13:54 -0600, Gunnar Wolf wrote: > > Martin Zobel-Helas dijo [Fri, Mar 11, 2011 at 08:31:36PM +0100]: > > > > Chile was supposed to leave the Summer daylight savings period this > > > > coming weekend, but it was pushed to April 2nd. The fixes have been > > > > accepted to the package in Sid, but many users will undoubtely > > > > appreciate it if it can be updated as well in stable-updates. > [...] > > > the correct way would be to ask the release team for a release of tzdata > > > on stable-updates (formerly known as volatile) and get it updated in the > > > next point release as well. > > > > Yes - although that should be preceded with a suitable package built > > targetted at Squeeze, preferrably by the package maintainers, right? > > There's a tzdata package in the p-u-NEW queue which includes the change. > Unfortunately it was uploaded slightly too late to make it in to the > 1952 dinstall but I'll check the diff this evening and get it marked for > acceptance in to p-u in the 0152. > > Assuming everything goes according to plan (adding packages to > squeeze-updates hasn't actually been tested yet) I'm planning on pushing > the tzdata update in tomorrow morning. will there be an update for oldstable as well? Cheers, Martin -- Martin Zobel-Helas | Debian System Administrator Debian & GNU/Linux Developer | Debian Listmaster GPG key http://go.debian.net/B11B627B | GPG Fingerprint: 6B18 5642 8E41 EC89 3D5D BDBB 53B1 AC6D B11B 627B -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110311201700.gv18...@ftbfs.de
Bug#617331: Pushing tzdata updates to stable in time
Hi, On Fri Mar 11, 2011 at 13:11:52 -0600, Gunnar Wolf wrote: > Hi, > > I was prodded by my Chilean friend, Germán Póo-Caamaño, to help find a > way to push the tzdata corrections needed for Chile's change of > timezone plans. Trying to do so, I found he already did everything > needed (#617331). > > Chile was supposed to leave the Summer daylight savings period this > coming weekend, but it was pushed to April 2nd. The fixes have been > accepted to the package in Sid, but many users will undoubtely > appreciate it if it can be updated as well in stable-updates. > > Sorry for reverberating here on list, but given the timeframe for this > bug to bite, I'd rather have it prominent and not hidden. the correct way would be to ask the release team for a release of tzdata on stable-updates (formerly known as volatile) and get it updated in the next point release as well. Cheers, Martin -- Martin Zobel-Helas | Debian System Administrator Debian & GNU/Linux Developer | Debian Listmaster GPG key http://go.debian.net/B11B627B | GPG Fingerprint: 6B18 5642 8E41 EC89 3D5D BDBB 53B1 AC6D B11B 627B -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110311193136.gs18...@ftbfs.de
Bug#460226: Memory leak in SUNRPC code
Hi, On Sat Jan 12, 2008 at 13:41:12 +0100, Aurelien Jarno wrote: > Hi release managers, > > On Fri, Jan 11, 2008 at 11:59:53AM +, Andre Cruz wrote: > > Package: libc6 > > Version: 2.3.6.ds1-13etch2 > > Severity: serious > > Tags: patch > > > > I've already submitted a patch upstream and it has been integrated. > > > > http://sourceware.org/bugzilla/show_bug.cgi?id=5541 > > > > It should be backported to Etch. > > > > Is it ok to upload a glibc package with this patch to *stable*? go ahead. -- Martin Zobel-Helas <[EMAIL PROTECTED]> | Debian Release Team Member Debian & GNU/Linux Developer | Debian Listmaster Public key http://zobel.ftbfs.de/5d64f870.asc - KeyID: 5D64 F870 GPG Fingerprint: 5DB3 1301 375A A50F 07E7 302F 493E FB8E 5D64 F870 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please hint glibc/2.7-5
Hi, On Sun Dec 30, 2007 at 21:31:07 +0100, Aurelien Jarno wrote: > Hi, > > glibc/2.7-5 is ready to go into testing. It fixes bug that are present > in the testing version, and hasn't any known regression. > > Could you please hint it? done -- [EMAIL PROTECTED] /root]# man real-life No manual entry for real-life -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is it possible to get a fix for libc6 and nfs-kernel-server into etch r1?
Hi, Glibc maintainers, what is your opinion on that? Greetings Martin On Fri May 11, 2007 at 14:00:17 +0200, Steinar H. Gunderson wrote: > On Fri, May 11, 2007 at 01:25:07PM +0200, Rik Theys wrote: > > Is there any chance to get a fix for #423369 and #423108, a memory leak > > in both libc6 and nfs-kernel-server, into etch r1? > > FWIW, here is the proposed patch: > > --- nfs-utils-1.0.10/debian/changelog > +++ nfs-utils-1.0.10/debian/changelog > @@ -1,3 +1,17 @@ > +nfs-utils (1:1.0.10-6.etch1) stable; urgency=medium > + > + * Backport two memory leak fixes from unstable that together could bring > +down a busy rpc.mountd quite fast. (Closes: #423108) > +* In add_name(), free() the old pointer in all code branches. The old > code > + did it only when the malloc() failed, which was an oversight. > +* In client_compose(), free() the hostent structure returned before > + exiting. Normally, gethostbyaddr() returns a pointer to a static > + struct, but this hostent comes from either get_reliable_hostbyaddr() or > + get_hostent(), both which return a pointer they privately xmalloc()ed, > + which thus can and should be free()d. > + > + -- Steinar H. Gunderson <[EMAIL PROTECTED]> Fri, 11 May 2007 12:18:46 +0200 > + > nfs-utils (1:1.0.10-6) unstable; urgency=medium > >* Give --with-tcp-wrappers to configure; for some reason it stopped being > only in patch2: > unchanged: > --- nfs-utils-1.0.10.orig/support/export/client.c > +++ nfs-utils-1.0.10/support/export/client.c > @@ -262,6 +262,7 @@ > name = add_name(name, clp->m_hostname); > } > } > + free(he); > return name; > } > > @@ -329,6 +330,7 @@ > strcat(new, ","); > strcat(new, cp); > } > + free(old); > return new; > } > > I haven't uploaded it to stable-proposed-updates yet, since I'm not sure what > the current versioning number scheme is. > > /* Steinar */ > -- > Homepage: http://www.sesse.net/ > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > -- [EMAIL PROTECTED] /root]# man real-life No manual entry for real-life -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#412562: nscd uninstallable on alpha and ia64
Package: nscd Version: 2.3.2.ds1-22sarge5 Severity: serious the dependency lines of nscd somehow differ Package: nscd - Version: 2.3.2.ds1-22sarge4 + Version: 2.3.2.ds1-22sarge5 Section: admin Priority: optional Architecture: alpha - Depends: libc6.1 (>= 2.3.2.ds1-22sarge4) - Replaces: libc6.1 (<< 2.1-4) + Depends: libc6 (>= 2.3.2.ds1-22sarge5) + Replaces: libc6 (<< 2.1-4) That makes nscd uninstallable. I am currently investigating what happened here... Greetings Martin -- [EMAIL PROTECTED] /root]# man real-life No manual entry for real-life -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#408850: mksh: FTBFS on experimental/alpha (Re:Log for failed build of mksh_28.9.20070118 (dist=experimental))
Hi, > compiles correctly with an almost up to date etch alpha machine. We > will have to wait for an alpha machine to be accessible to developpers > again to test it further. i can give you access to one. Greetings Martin -- [EMAIL PROTECTED] /root]# man real-life No manual entry for real-life -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#382356: glibc: FTBFS on sparc
Package: glibc Severity: important Version: 2.3.2.ds1-22sarge4 Hi, i am opening this bug for documentation reasons. Currently glibc FTBFS on sparc(64?). First investigation showed up it compiles fine with Sarge kernel, but does not with newer kernels. http://buildd.debian.org/fetch.php?&pkg=glibc&ver=2.3.2.ds1-22sarge4&arch=sparc&stamp=1149994175&file=log&as=raw k. please document that somewhere. where do you think it is the better? is there a bug in the bts? otherwise i will open one ok, please open one, I will add a comment then Greetings Martin -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-1-vserver-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- Martin Zobel-Helas credativ GmbHTel: +49 24 61 / 69 07 10 Karl-Heinz-Beckurts-Str. 13 Fax: +49 24 61 / 69 07 11 D-52428 Juelich www: http://www.credativ.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
glibc in proposed-updates blocks security.d.o
Hi Aurel, hi *, the current version of glibc in proposed-updates does not seem to compile on sparc[1]. For that reason i did not accept other archs yet. Joey notified me yesterday evening, that locales is currently uninstallable on all other archs and thus currently breaks builds for debian's stable-security. stable-security and proposed-updates are currently build in the same chroot on the buildds. Please rise the work priority on that issue, as Joey is currently very unhappy with this situation. Greetings Martin [1] http://buildd.debian.org/fetch.php?&pkg=glibc&ver=2.3.2.ds1-22sarge4&arch=sparc&stamp=1149994175&file=log&as=raw -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#375978: timezone variable not set correctly, bug blocking LSB Conformance
Hi Aurelien, On Mon, Jul 03, 2006 at 06:44:16AM +0200, Aurelien Jarno <[EMAIL PROTECTED]> wrote: > Hi SRM team! > > Would such a fix to the glibc be accepted for a stable release? i would be first interested, which LSB versions are effected by this. I don't see any need for fixing newer LSB issues in Sarge, as Sarge was targeted LSB 2.0 compatibility. Greetings Martin > Bye, > Aurelien > > > Martin Dittmar wrote: > >Package: libc6 > >Version: 2.3.2.ds1-22sarge3 > > > >Problem: after calling the C method "ctime" the global variable > >"timezone" is not set correctly with certain TZ environment variables. > >With TZ=JKL3:10PNM4:40 set, the value of "timezone" is expected to be > >11400, but has a nonsense value of 18000. > > > >For a demonstration please see the attched file test.c > > > >This is a libc bug (already in libc Bugzilla (see > >http://sourceware.org/bugzilla/show_bug.cgi?id=2865 )), but can be fixed > >in Debian. > > > >This would be important for LSB compliance (LSB Runtime tests LSB > >runtime tests T.ctime_X 1, T.localtim_X 1, T.mktime_X 1). > >LSB test failure message: > > with TZ=JKL3:10PNM4:40 ctime() did not set timezone correctly > > value of timezone was 18000, expected 11400 > > > >A patch for sarge is attached. > > > >Kernel on tested system: 2.6.14-2-686-smp > >libc version: 2.3.2.ds1-22sarge3 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: timezone data packaged separately and in volatile?
Hi Daniel, On Monday, 06 Feb 2006, you wrote: > On Tue, Feb 07, 2006 at 02:30:01PM +1100, Anand Kumria wrote: > > But that doesn't mean that we can issue an update to a stable package. > > > > Currently they are mainly done for security purposes -- but stable updates > > should not be confined to only that. They should be done to keep the > > system functional. > > > > I also think volatile is precisely the wrong place to put this kind of > > data -- it isn't part of the default apt.sources for one thing; and it > > places an extra burden on the maintainer(s) (who know have to track > > three different upgrade paths, etc.). > > > > It would be good to hear from the glibc maintainers if there are any > > issues addressing bugs such as: 345479, 351049 with an update for > > stable. > > It's not us, but the stable maintainer, that you'd have to talk to; > he has traditionally not been interested in these sorts of updates to > stable as far as I know. I talked to Joey another day, and he said, we should mail him about, and he will decide if this could go in via a point release. I hearby mail him (CC). Lets see what happens. Greetings Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dist-Uprade on HPPA64
Hi Matthew, On Tuesday, 30 Nov 2004, you wrote: > On Tue, Nov 30, 2004 at 02:19:21PM +0100, Andreas Barth wrote: > > Well, IIRC, it is enough to use _only_ the 32bit kernel, and that would > > make it easier for us, because we don't need an extra package in the > > archive. But yes, your reason is also strong. Ok, so I tend to go to the > > backported modutils. Unless somebody vetoes me, I'll try to handle that > > with the modutils maintainer. > > Some machines cannot run a 32 bit kernel, so the "easier" idea will not work. > > Personally, I think the libc dependencies are unnecessarily tight. Maybe > someone should test overriding libc's kernel version test, and running a > new libc on woody's kernel instead? so we would have an other round of tool-chain-changes Greetings Martin -- "The great question... which I have not been able to answer... is, `What does woman want?'" -- Sigmund Freud -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
