Bug#91815: Patch to add memusage and memusagestat

2020-07-08 Thread Stephen Kitt
Hi Helmut,

On Wed, 8 Jul 2020 18:49:42 +0200, Helmut Grohne  wrote:
[...]
> > diff --git a/debian/control.in/main b/debian/control.in/main
> > index 659267bd..c513a01a 100644
> > --- a/debian/control.in/main
> > +++ b/debian/control.in/main
> > @@ -12,7 +12,8 @@ Build-Depends: gettext, dpkg (>= 1.18.7), dpkg-dev (>=
> > 1.17.14), xz-utils, file, g++-9, g++-9-multilib [amd64 i386
> > kfreebsd-amd64 mips mipsel mipsn32 mipsn32el mips64 mips64el mipsr6
> > mipsr6el mipsn32r6 mipsn32r6el mips64r6 mips64r6el powerpc ppc64 s390x
> > sparc sparc64 x32] , python3:native, libidn2-0 (>= 2.0.5~)
> > ,
> > - libc-bin (>= @GLIBC_VERSION@) 
> > + libc-bin (>= @GLIBC_VERSION@) ,
> > + libgd-dev
> 
> I suggest adding a trailing comma to make the diff for the next change
> smaller.
> 
> >  Build-Depends-Indep: perl, po-debconf (>= 1.0)
> >  Maintainer: GNU Libc Maintainers 
> >  Uploaders: Clint Adams , Aurelien Jarno
> > , Adam Conrad , Samuel Thibault
> >  @@ -47,11 +48,31 @@ Section: libdevel Priority:
> > optional Multi-Arch: foreign
> >  Depends: ${shlibs:Depends}, ${misc:Depends}
> > -Recommends: manpages, manpages-dev
> > +Recommends: libc-devtools (>> @GLIBC_VERSION@)
> >  Build-Profiles: 
> >  Description: GNU C Library: Development binaries
> >   This package contains utility programs related to the GNU C Library
> >   development package.
> > + .
> > +  * gencat: generate message catalogs
> > +  * rpcgen: compile RPC protocols to C
> > +
> > +Package: libc-devtools
> > +Architecture: any
> > +Section: devel
> > +Priority: optional
> > +Multi-Arch: foreign  
> 
> I doubt that memusage is eligible for Multi-Arch: foreign.
> 
> > +Depends: ${shlibs:Depends}, ${misc:Depends}
> > +Recommends: manpages, manpages-dev
> > +Build-Profiles:
> 
> You need Breaks + Replaces here. With the current patch, piuparts should
> be unhappy.

Thanks for the careful review, I’ve fixed all the above in the attached patch
(using ${binary:Version} for Breaks/Replaces for now).

Regards,

Stephen
From c0322308d2be0a5e54fa39ae1437f0fad7901540 Mon Sep 17 00:00:00 2001
From: Stephen Kitt 
Date: Tue, 21 Apr 2020 20:55:53 +0200
Subject: [PATCH] Build and package memusage*

This builds memusage and memusagestat in the libc pass, and ships them
in a new package, libc-devtools (short for "libc-provided developer
tools", and not libc-dev-tools to avoid making it seem to
closely-related to libc-dev-bin). This involves adding a
build-dependency on libgd-dev (outside stage1 and stage2). Other tools
which are not used to build *with* libc, but useful for development in
general, are moved to libc-devtools: mtrace, sotruss, sprof.

libc-dev-bin recommends libc-devtools to provide a simple
transition (see #91815 for the discussion).

Closes: #91815
Signed-off-by: Stephen Kitt 
---
 debian/control.in/main| 27 +--
 debian/debhelper.in/libc-dev-bin.install  |  3 ---
 debian/debhelper.in/libc-dev-bin.manpages |  1 -
 debian/debhelper.in/libc-devtools.install |  5 
 ...rrides => libc-devtools.lintian-overrides} |  2 ++
 debian/debhelper.in/libc-devtools.manpages|  1 +
 debian/rules  |  3 +++
 debian/rules.d/build.mk   |  8 ++
 8 files changed, 44 insertions(+), 6 deletions(-)
 create mode 100644 debian/debhelper.in/libc-devtools.install
 rename debian/debhelper.in/{libc-dev-bin.lintian-overrides => libc-devtools.lintian-overrides} (58%)
 create mode 100644 debian/debhelper.in/libc-devtools.manpages

diff --git a/debian/control.in/main b/debian/control.in/main
index 659267bd..2a2fb5a8 100644
--- a/debian/control.in/main
+++ b/debian/control.in/main
@@ -12,7 +12,8 @@ Build-Depends: gettext, dpkg (>= 1.18.7), dpkg-dev (>= 1.17.14), xz-utils, file,
  g++-9, g++-9-multilib [amd64 i386 kfreebsd-amd64 mips mipsel mipsn32 mipsn32el mips64 mips64el mipsr6 mipsr6el mipsn32r6 mipsn32r6el mips64r6 mips64r6el powerpc ppc64 s390x sparc sparc64 x32] ,
  python3:native,
  libidn2-0 (>= 2.0.5~) ,
- libc-bin (>= @GLIBC_VERSION@) 
+ libc-bin (>= @GLIBC_VERSION@) ,
+ libgd-dev  ,
 Build-Depends-Indep: perl, po-debconf (>= 1.0)
 Maintainer: GNU Libc Maintainers 
 Uploaders: Clint Adams , Aurelien Jarno , Adam Conrad , Samuel Thibault 
@@ -47,11 +48,33 @@ Section: libdevel
 Priority: optional
 Multi-Arch: foreign
 Depends: ${shlibs:Depends}, ${misc:Depends}
-Recommends: manpages, manpages-dev
+Recommends: libc-devtools (>> @GLIBC_VERSION@)
 Build-Profiles: 
 Description: GNU C Library: Development binaries
  This package contains utility programs related to the GNU C Library
  development package.
+ .
+  * gencat: generate message cat

Bug#91815: Patch to add memusage and memusagestat

2020-07-08 Thread Stephen Kitt
Hi,

On Sat, 16 May 2020 13:35:02 +0200, Aurelien Jarno  wrote:
> On 2020-05-09 12:27, Helmut Grohne wrote:
> > Thank you for not dropping the ball after my initial "it's not that
> > easy" reply.
> > 
> > On Sat, May 09, 2020 at 10:53:10AM +0200, Stephen Kitt wrote:  
> > > There’s another part of the transition which bothers me: if we add
> > > memusage to a package which is depended upon (albeit temporarily) by
> > > libc-dev-bin, it becomes part of build-essential, and adding memusage
> > > means adding libgd3, libfontconfig1, libfreetype6, etc. to all builds...
> > > 
> > > It occurred to me that there is however a way to add memusage while
> > > transitioning cleanly, over a few years. It seems to me that the
> > > binaries in libc-dev-bin can be split into two categories: binaries
> > > that are expected as build tools (gencat and rpcgen), and binaries that
> > > are useful as tools for understanding programs but not building them
> > > (memusage, memusagestat, mtrace, sotruss, sprof). How about the
> > > following?
> > > 
> > > * We add a new package, say libc-devtools, containing the second type of
> > >   tools (mtrace, sotruss, sprof). For transition purposes, libc-dev-bin
> > >   depends on that in Bullseye.
> > > * We add another package, memusage, containing memusage and
> > > memusagestat. That’s the package which ends up with all the annoying
> > > extra dependencies, but nothing depends on it.
> > > * In Bookworm, libc-dev-bin can drop the dependency on libc-devtools,
> > > and we can merge memusage into libc-devtools.
> > > 
> > > Does that make sense?  
> 
> Yes, with the points raised by Helmut, I think it makes sense.
> Unfortunately many changes in glibc requires transitions lasting many
> years...

I don’t mind, it’s not as if this is an urgent bug ;-).

> I just wonder if we should call it libc-devtools or libc-dev-tools to
> match the pattern from libc-dev-bin. But that's a minor detail over the
> whole plan.

I went for libc-devtools to avoid making it too closely-tied to libc-dev-bin,
on purpose; it’s not only useful for people needing libc-dev.

> > All of what you write here makes very much sense to me and the
> > trade-offs seem good to me. What you propose will result in making the
> > bootstrapping/profile stuff simpler/better. That said, I am not a glibc
> > maintainer. I don't see the full picture.
> > 
> > I have two minor remarks:
> >  * Should libc-devtools maybe recommend memusage already?  
> 
> It's something we can do, I think it mostly depends if we basically want
> libc-dev-bin to recommends memusage.
> 
> >  * We cannot simply have libc-devtools absorb memusage in bookworm.
> >Doing so would break upgrades when someone has memusage, but not
> >libc-devtools installed. Therefore memusage likely needs to be a
> >transitional dummy package in bookworm and can only be removed one
> >release later. I'm wondering whether this could be avoided if we had
> >memusage depend on libc-devtools.  
> 
> I agree with that.
> 
> > Neither of these touch the core of your thoughts.  
> 
> Another faster alternative that came to my mind is to rely n the fact
> that recommends are enabled by default, but not used to resolve
> build-dependencies. In that case we can already create libc-devtools
> with memstatusage and also move mtrace, sotruss, sprof there. Those 3
> binaries are very unlikely to be used to build packages, so I don't
> expect breakages. From the user point of view, it's just like if (part
> of) a dependency has been demoted to a recommends. It's something that
> is often done for other packages, and it seems we accept that even if it
> causes breakages (latest example that comes to my mind is util-linux
> dropping the dependency on fdisk). I guess adding an entry in NEWS would
> be necessary though.

I’ve implemented this, see the attached patch. I’m not sure the upgrade
scenario is ideal though: recommends are ignored on upgrades. This means
that, if libc-dev-bin recommends libc-devtools, upgrades won’t install the
latter, but new installations of libc-dev-bin will.

Pushing memusage* to a separate package would result in that being installed
on upgrade: libc-dev-bin would depend on libc-devtools (following the
transition rules strictly), so that would get pulled in automatically on
upgrade, and since it’s a new package, it would count as installation, and
thus pull in its recommendations.

> I don't know if it's something that's acceptable. What do you think?
> Maybe we should ask the release team?

That would be useful! I need to check 

Bug#91815: Patch to add memusage and memusagestat

2020-05-09 Thread Stephen Kitt
Hi Aurélien, hi Helmut,

On Mon, 4 May 2020 07:11:37 +0200, Helmut Grohne  wrote:
> On Mon, May 04, 2020 at 12:00:28AM +0200, Aurelien Jarno wrote:
> > Thanks for the detailed explanations. It looks to me that it's better to
> > add a different package. And while mtrace looks a good candidate to join
> > this package, I am not sure we can handle the transition easily. It
> > would mean that libc6-dev-bin need to depends on that new package at
> > least for one release cycle. And we actually don't want that for stage
> > 2, which means producing different packages for stage2...  
> 
> Let me point out that a transitional dependency is not a huge cost to
> reproducibility. Making the dependency optional to stage2 is reasonable.
> libc packages are not yet reproducible across stages. That's more of a
> vision. In diffoscope, such a dependency difference is very light.

There’s another part of the transition which bothers me: if we add memusage
to a package which is depended upon (albeit temporarily) by libc-dev-bin, it
becomes part of build-essential, and adding memusage means adding libgd3,
libfontconfig1, libfreetype6, etc. to all builds...

It occurred to me that there is however a way to add memusage while
transitioning cleanly, over a few years. It seems to me that the binaries in
libc-dev-bin can be split into two categories: binaries that are expected as
build tools (gencat and rpcgen), and binaries that are useful as tools for
understanding programs but not building them (memusage, memusagestat, mtrace,
sotruss, sprof). How about the following?

* We add a new package, say libc-devtools, containing the second type of
  tools (mtrace, sotruss, sprof). For transition purposes, libc-dev-bin
  depends on that in Bullseye.
* We add another package, memusage, containing memusage and memusagestat.
  That’s the package which ends up with all the annoying extra dependencies,
  but nothing depends on it.
* In Bookworm, libc-dev-bin can drop the dependency on libc-devtools, and we
  can merge memusage into libc-devtools.

Does that make sense?

Regards,

Stephen


pgpCZZtK9enyl.pgp
Description: OpenPGP digital signature


Bug#91815: Patch to add memusage and memusagestat

2020-04-22 Thread Stephen Kitt
Hi,

On Wed, 22 Apr 2020 00:04:32 +0200, Aurelien Jarno  wrote:
> On 2020-04-21 20:58, Stephen Kitt wrote:
> Thanks for trying to fix one of the oldest glibc bugs ;-)

You’re welcome!

> > The attached patch adds memusage and memusagestat to the libc-bin package.
> > This does mean that the latter becomes dependent on libgd3, so it might be
> > better to add a new memusage package; I can take care of that if the
> > maintainers think it’s better.  
> 
> I am not sure we want to add a new dependency for libc-bin, I am sure
> people running embedded systems won't appreciate. Any reason for not
> shipping it in libc-dev-bin instead? For me that looks more like a tool
> to be used for "development". At least the memusagestat is similar to
> the mtrace one that is in libc-dev-bin.

Indeed, especially since libgd3 is a rather heavy-weight dependency. I’m
attaching a patch which adds the tools to libc-dev-bin instead.

> We also have to make sure that this new build-dependency doesn't break
> bootstrapping. I have added Helmut in Cc so that he can have a look.

Isn’t non-cross bootstrapping handled by the stage1 build profile? If this
causes issues with cross bootstrapping then shipping a separate memusage
package ( ) should take care of things.

Regards,

Stephen
From bd3f09edb6296b8a8e2987aefd3169d48903625f Mon Sep 17 00:00:00 2001
From: Stephen Kitt 
Date: Tue, 21 Apr 2020 20:55:53 +0200
Subject: [PATCH] Build and package memusage*

This builds memusage and memusagestat in the libc pass, and ships them
in libc-dev-bin. This involves adding a build-dependency on
libgd-dev (outside stage1) and libc-dev-bin acquires a runtime
dependency on the corresponding library package.

Closes: #91815
Signed-off-by: Stephen Kitt 
---
 debian/control.in/main | 3 ++-
 debian/debhelper.in/libc-dev-bin.install   | 2 ++
 debian/debhelper.in/libc-dev-bin.lintian-overrides | 2 ++
 debian/rules.d/build.mk| 6 +-
 4 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/debian/control.in/main b/debian/control.in/main
index 659267bd..3537b751 100644
--- a/debian/control.in/main
+++ b/debian/control.in/main
@@ -12,7 +12,8 @@ Build-Depends: gettext, dpkg (>= 1.18.7), dpkg-dev (>= 1.17.14), xz-utils, file,
  g++-9, g++-9-multilib [amd64 i386 kfreebsd-amd64 mips mipsel mipsn32 mipsn32el mips64 mips64el mipsr6 mipsr6el mipsn32r6 mipsn32r6el mips64r6 mips64r6el powerpc ppc64 s390x sparc sparc64 x32] ,
  python3:native,
  libidn2-0 (>= 2.0.5~) ,
- libc-bin (>= @GLIBC_VERSION@) 
+ libc-bin (>= @GLIBC_VERSION@) ,
+ libgd-dev 
 Build-Depends-Indep: perl, po-debconf (>= 1.0)
 Maintainer: GNU Libc Maintainers 
 Uploaders: Clint Adams , Aurelien Jarno , Adam Conrad , Samuel Thibault 
diff --git a/debian/debhelper.in/libc-dev-bin.install b/debian/debhelper.in/libc-dev-bin.install
index 0d760a7e..8ced4378 100644
--- a/debian/debhelper.in/libc-dev-bin.install
+++ b/debian/debhelper.in/libc-dev-bin.install
@@ -1,4 +1,6 @@
 debian/tmp-libc/usr/bin/gencat usr/bin
+debian/tmp-libc/usr/bin/memusage usr/bin
+debian/tmp-libc/usr/bin/memusagestat usr/bin
 debian/tmp-libc/usr/bin/mtrace usr/bin
 debian/tmp-libc/usr/bin/rpcgen usr/bin
 debian/tmp-libc/usr/bin/sotruss usr/bin
diff --git a/debian/debhelper.in/libc-dev-bin.lintian-overrides b/debian/debhelper.in/libc-dev-bin.lintian-overrides
index eedd7cbd..1031449a 100644
--- a/debian/debhelper.in/libc-dev-bin.lintian-overrides
+++ b/debian/debhelper.in/libc-dev-bin.lintian-overrides
@@ -1,3 +1,5 @@
 # these manpages are provided by the manpages package
+libc-dev-bin: binary-without-manpage usr/bin/memusage
+libc-dev-bin: binary-without-manpage usr/bin/memusagestat
 libc-dev-bin: binary-without-manpage usr/bin/mtrace
 libc-dev-bin: binary-without-manpage usr/bin/sprof
diff --git a/debian/rules.d/build.mk b/debian/rules.d/build.mk
index 0d03116a..3f664316 100644
--- a/debian/rules.d/build.mk
+++ b/debian/rules.d/build.mk
@@ -37,7 +37,11 @@ $(stamp)configure_%: $(stamp)config_sub_guess $(stamp)patch $(KERNEL_HEADER_DIR)
 	echo "BASH := /bin/bash"  >> $(DEB_BUILDDIR)/configparms
 	echo "KSH := /bin/bash"   >> $(DEB_BUILDDIR)/configparms
 	echo "SHELL := /bin/bash" >> $(DEB_BUILDDIR)/configparms
-	echo "LIBGD = no" >> $(DEB_BUILDDIR)/configparms
+	if [ "$(curpass)" = "libc" ]; then \
+	  echo "LIBGD = yes"  >> $(DEB_BUILDDIR)/configparms; \
+	else \
+	  echo "LIBGD = no"   >> $(DEB_BUILDDIR)/configparms; \
+	fi
 	echo "bindir = $(bindir)" >> $(DEB_BUILDDIR)/configparms
 	echo "datadir = $(datadir)"   >> $(DEB_BUILDDIR)/configparms
 	echo "complocaledir = $(complocaledir)"   >> $(DEB_BUILDDIR)/configparms
-- 
2.20.1



pgpEALW2r4ByK.pgp
Description: OpenPGP digital signature


Bug#91815: Patch to add memusage and memusagestat

2020-04-21 Thread Stephen Kitt
Control: tag -1 + patch

Hi,

The attached patch adds memusage and memusagestat to the libc-bin package.
This does mean that the latter becomes dependent on libgd3, so it might be
better to add a new memusage package; I can take care of that if the
maintainers think it’s better.

Regards,

Stephen
From c2bc49abc1dfba93609544378f3f65dec1b98a7c Mon Sep 17 00:00:00 2001
From: Stephen Kitt 
Date: Tue, 21 Apr 2020 20:55:53 +0200
Subject: [PATCH] Build and package memusage*

This builds memusage and memusagestat in the libc pass, and ships them
in libc-bin. This involves adding a build-dependency on
libgd-dev (outside stage1) and libc-bin acquires a runtime dependency
on the corresponding library package.

Closes: #91815
Signed-off-by: Stephen Kitt 
---
 debian/control.in/main | 4 +++-
 debian/debhelper.in/libc-bin.install   | 2 ++
 debian/debhelper.in/libc-bin.lintian-overrides | 2 ++
 debian/rules.d/build.mk| 6 +-
 4 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/debian/control.in/main b/debian/control.in/main
index 659267bd..3ff82664 100644
--- a/debian/control.in/main
+++ b/debian/control.in/main
@@ -12,7 +12,8 @@ Build-Depends: gettext, dpkg (>= 1.18.7), dpkg-dev (>= 1.17.14), xz-utils, file,
  g++-9, g++-9-multilib [amd64 i386 kfreebsd-amd64 mips mipsel mipsn32 mipsn32el mips64 mips64el mipsr6 mipsr6el mipsn32r6 mipsn32r6el mips64r6 mips64r6el powerpc ppc64 s390x sparc sparc64 x32] ,
  python3:native,
  libidn2-0 (>= 2.0.5~) ,
- libc-bin (>= @GLIBC_VERSION@) 
+ libc-bin (>= @GLIBC_VERSION@) ,
+ libgd-dev 
 Build-Depends-Indep: perl, po-debconf (>= 1.0)
 Maintainer: GNU Libc Maintainers 
 Uploaders: Clint Adams , Aurelien Jarno , Adam Conrad , Samuel Thibault 
@@ -39,6 +40,7 @@ Description: GNU C Library: Binaries
   * iconv, iconvconfig: convert between character encodings
   * ldd, ldconfig: print/configure shared library dependencies
   * locale, localedef: show/generate locale definitions
+  * memusage, memusagestat: measure memory usage
   * tzselect, zdump, zic: select/dump/compile time zones
 
 Package: libc-dev-bin
diff --git a/debian/debhelper.in/libc-bin.install b/debian/debhelper.in/libc-bin.install
index dfab166b..a76d191f 100644
--- a/debian/debhelper.in/libc-bin.install
+++ b/debian/debhelper.in/libc-bin.install
@@ -12,6 +12,8 @@ debian/tmp-libc/usr/bin/iconv usr/bin
 debian/tmp-libc/usr/bin/ldd usr/bin
 debian/tmp-libc/usr/bin/localedef usr/bin
 debian/tmp-libc/usr/bin/locale usr/bin
+debian/tmp-libc/usr/bin/memusage usr/bin
+debian/tmp-libc/usr/bin/memusagestat usr/bin
 debian/tmp-libc/usr/bin/pldd usr/bin
 debian/tmp-libc/usr/bin/tzselect usr/bin
 debian/tmp-libc/usr/lib/pt_chown usr/lib
diff --git a/debian/debhelper.in/libc-bin.lintian-overrides b/debian/debhelper.in/libc-bin.lintian-overrides
index 01eb456c..ba411883 100644
--- a/debian/debhelper.in/libc-bin.lintian-overrides
+++ b/debian/debhelper.in/libc-bin.lintian-overrides
@@ -17,6 +17,8 @@ libc-bin: binary-without-manpage usr/bin/iconv
 libc-bin: binary-without-manpage usr/bin/ldd
 libc-bin: binary-without-manpage usr/bin/locale
 libc-bin: binary-without-manpage usr/bin/localedef
+libc-bin: binary-without-manpage usr/bin/memusage
+libc-bin: binary-without-manpage usr/bin/memusagestat
 libc-bin: binary-without-manpage usr/bin/pldd
 libc-bin: binary-without-manpage usr/bin/zdump
 libc-bin: binary-without-manpage usr/sbin/iconvconfig
diff --git a/debian/rules.d/build.mk b/debian/rules.d/build.mk
index 0d03116a..3f664316 100644
--- a/debian/rules.d/build.mk
+++ b/debian/rules.d/build.mk
@@ -37,7 +37,11 @@ $(stamp)configure_%: $(stamp)config_sub_guess $(stamp)patch $(KERNEL_HEADER_DIR)
 	echo "BASH := /bin/bash"  >> $(DEB_BUILDDIR)/configparms
 	echo "KSH := /bin/bash"   >> $(DEB_BUILDDIR)/configparms
 	echo "SHELL := /bin/bash" >> $(DEB_BUILDDIR)/configparms
-	echo "LIBGD = no" >> $(DEB_BUILDDIR)/configparms
+	if [ "$(curpass)" = "libc" ]; then \
+	  echo "LIBGD = yes"  >> $(DEB_BUILDDIR)/configparms; \
+	else \
+	  echo "LIBGD = no"   >> $(DEB_BUILDDIR)/configparms; \
+	fi
 	echo "bindir = $(bindir)" >> $(DEB_BUILDDIR)/configparms
 	echo "datadir = $(datadir)"   >> $(DEB_BUILDDIR)/configparms
 	echo "complocaledir = $(complocaledir)"   >> $(DEB_BUILDDIR)/configparms
-- 
2.20.1



pgpe_6n3ge4HH.pgp
Description: OpenPGP digital signature


libc6-i386 upgrade seems to cause problems with other packages

2010-09-10 Thread Stephen Kitt
severity 566720 important
reassign 566720 libc6-i386
reassign 595918 libc6-i386
merge 566720 595918
thanks

Dear eglibc maintainers,

The two bugs above describe systems where libraries in /usr/lib32
suddenly disappeared; it seems that this could be caused by the
symlink removal in libc6-i386's preinst, although why it should only
happen now remains mysterious to me.

Do you have any idea what could explain this, if it is actually caused
by libc6-i386?

(Note to the submitters: could you send the result of
  ls -lR /emul/ia32-linux
as a follow-up to these bug reports?)

Regards,

Stephen


-- 
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/20100910212033.gc19...@sk2.org



Bug#438191: tzdata: Europe/Paris replaced with User defined

2007-08-16 Thread Stephen Kitt
Package: tzdata
Version: 2007f-10
Followup-For: Bug #438191


Hi,

The same thing happened to me. Reconfiguring tzdata using
dpkg-reconfigure restored the old setting; incidentally,
dpkg-reconfigure initially suggested Etc, but once I selected Europe
it automatically suggested Paris.

Regards,

Stephen

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable'), (200, 'unstable'), (1, 
'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.22-1-686 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash

Versions of packages tzdata depends on:
ii  debconf [debconf-2.0] 1.5.14 Debian configuration management sy

tzdata recommends no packages.

-- debconf information:
  tzdata/Zones/Asia:
  tzdata/Zones/SystemV:
  tzdata/Zones/Pacific:
  tzdata/Zones/Atlantic:
  tzdata/Zones/US:
  tzdata/Zones/Etc: UTC
  tzdata/Zones/Arctic:
  tzdata/Zones/Antarctica:
  tzdata/Zones/America:
* tzdata/Areas: Europe
  tzdata/Zones/Australia:
  tzdata/Zones/Canada:
* tzdata/Zones/Europe: Paris
  tzdata/Zones/Africa:
  tzdata/Zones/Indian:


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]