Bug#864480: why is en_DK included but not en_DE?

2024-01-22 Thread Marc Haber
Control: tags -1 
thanks

On Fri, Jun 09, 2017 at 11:14:20AM +0200, Samuel Thibault wrote:
> So what you want is actually LC_LANG=de_DE LANGUAGE=en, right?

After revisiting some ancient things still maked as unsolved in my
notes, I have been running my system with that setting for a couple of
years now and it reasonably seems to do the thing I expect it to.

Maybe it is asking too much to have a setting to have T.M.D. date format
but english monthh names ;-)

For me this issue can be closed if you agree.

Greetings
Marc



Bug#1030742: tzdata: Can’t configure the package

2023-02-07 Thread Marc Haber
Control: tags -1 
thanks

On Tue, Feb 07, 2023 at 10:11:48AM +0100, Marc Haber wrote:
> On Tue, Feb 07, 2023 at 06:28:32AM +0100, Nicolas Patrois wrote:
> > tzdata can’t be configured:
> >  installed tzdata package post-installation script subprocess returned error
> > exit status 10
> > Thus, ntpsec can’t be upgraded (it depends on tzdata’s installation).
> 
> This also breaks setup of build chroots, test environments etc. I am not
> sure whether severity important is high enough for this.

On my systems where things fail, /etc/localtime is a relative symlink
pointing to ../usr/share/zoneinfo/Europe/Berlin. Manually replacing this
with an absolute link allows the tzdata update to proceed. Sadly, this
is not an option in a debspawn container (because that tool doesnt allow
manual tinkering with the container).

Greetings
Marc



Bug#1030742: tzdata: Can’t configure the package

2023-02-07 Thread Marc Haber
Control: severity -1 important
thanks

On Tue, Feb 07, 2023 at 06:28:32AM +0100, Nicolas Patrois wrote:
> tzdata can’t be configured:
>  installed tzdata package post-installation script subprocess returned error
> exit status 10
> Thus, ntpsec can’t be upgraded (it depends on tzdata’s installation).

This also breaks setup of build chroots, test environments etc. I am not
sure whether severity important is high enough for this.

Greetings
Marc



Re: Bug#1025243: sudo: autopkgtest fails if glibc is upgraded in testbed (on s390x)

2022-12-09 Thread Marc Haber
On Thu, Dec 01, 2022 at 01:02:45PM +0100, Paul Gevers wrote:
> And right after hitting the send button I realized that my reasoning is at
> least partially flawed. The testbed will always update glibc, because the
> testbed is build from testing, and glibc hasn't migrated yet. Still, it's a
> weird pattern.

Is there still something that sudo can do here? I fixed an issue in the
ldap autopkgtest¹ recently, but your logs looks like the test gets
further than the place where this issue errors out.

Would more output in the test help? What is the canonical way to write a
test that can have its verbosity turned up for debugging, how is this
wish communicated to a system that runs the tests in an automated way?
Can a mere mortal DD run an autopkgtest on a porterbox?

Greetings
Marc



Re: Seeking clarification for nscd invalidation

2022-07-07 Thread Marc Haber
[is the glibc maintainers mailing list still the correct venue?]

Hi,

I really appreciate your help, it is insightful.

On Wed, Jul 06, 2022 at 04:57:47PM -0400, Carlos O'Donell wrote:
> On Wed, Jul 6, 2022 at 10:10 AM Marc Haber  
> wrote:
> > On Wed, Jul 06, 2022 at 09:29:22AM -0400, Carlos O'Donell wrote:
> > > You can verify that nscd is catching the cases you care about by running
> > > it in '--debug' mode to let you see the cache invalidation.
> >
> > I regret to say that I don't use nscd in any of my installations. My
> > last superficial contact to nscd was like two decades ago.
> >
> > Would it help with an educated guess to install nscd, let it run in
> > --debug mode, run our test suite and compare nscd's output with the
> > output it generates running our test suite without the explicit
> > invalidation?
> 
> That sounds like a good approach. You should be able to compare
> the logs of both runs looking for the missing explicit invalidation
> and you should see that nscd detects the database changes.

I have uploaded two typescripts from nscd -d with debug_level 0 to
https://q.bofh.de/~mh/stuff/ - one with the invalidation code in adduser
in place, one with the invalidation code removed. Both logs show the
adduser test suite running.

Unfortunately, that doesnt look like I can make any sense from that. I
see nscd seeing changes to /etc/passwd and /etc/group, so I guess that
what we do is correctly reflected by nscd even without the explicit
invalidation. Additionally, I guess that adduser is invalidating caches
that don't need invalidation (logs showing explicit invalidations
without the software noticing changed files).

I am wondering about the following though:

monitored file `/etc/group` was deleted, removing watch
monitored file `/etc/group` was created, adding watch

without seeing actual caches being invalidated. Could it be possible
that /etc/group is rewritten and renamed and that nscd is only watching
for changes? Or am I missing something here?

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421



Re: Seeking clarification for nscd invalidation

2022-07-06 Thread Marc Haber
Hi Carlos,

thank you for commenting.

I am one of the adduser maintainers in Debian and we would like to ditch
the parts of our code that invalidate nscd explicitly in one of the
future versions of the software.

On Wed, Jul 06, 2022 at 09:29:22AM -0400, Carlos O'Donell wrote:
> You can verify that nscd is catching the cases you care about by running
> it in '--debug' mode to let you see the cache invalidation.

I regret to say that I don't use nscd in any of my installations. My
last superficial contact to nscd was like two decades ago.

Would it help with an educated guess to install nscd, let it run in
--debug mode, run our test suite and compare nscd's output with the
output it generates running our test suite without the explicit
invalidation?

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421



Seeking clarification for nscd invalidation

2022-07-04 Thread Marc Haber
[Please Cc: me on replies, I am not subscribed to Debian-glibc]

Hi,

adduser still has code to invalidate nscd cache after doing changes to
the user database. I would like to get rid of this and just document
that people using nscd should use the provided hook to invalidate their
nscd cache after creating or deleting users.

I am wondering whether this is actually needed any more. The nscd source
code contains numerous calls to inotify, and
https://man7.org/linux/man-pages/man8/nscd.8.html suggests that it
actually notices changes to the passwd/group "database" files and
invalidates automatically at least since 2015. The nscd manpage in
Debian seems to have been taken from a different source. I guess it was
not updated.

Do we still need to invalidate nscd cache "manually" or will nscd cover
the basic use cases automatically?

Greetings
Marc

-- 
-----
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421



Re: Seeing clarification for locale names

2021-03-16 Thread Marc Haber
Hi,

I apologize for the late answer. Please keep me in Cc:, I am not
subscribed.

On Mon, Feb 15, 2021 at 05:20:30PM +0100, Florian Weimer wrote:
> * Marc Haber:
> > I would appreciate pointers to documentation, personal opinions, war
> > stories, encoding tales, historic lectures, anything that might
> > enlighten me and help me build the knowlegde and understanding about
> > UNIX locales are supposed to work in Debian GNU/Linux. Thank you in
> > advance!
> 
> For the charset normalization, it's in the manual:



> This code dates back to the mid-90s, I think.

Took me 20+ years to finally notice.

> I general, I think it is best to treat locale names as opaque strings.

What is the recommended setting for the LANG and LC_ variables?
de-DE.UTF-8 or the normalized version?

> Parsing them to derive charsets is not going to work (e.g., no charset
> can mean ISO-8859-1 or UTF-8, depending on the age of the locale).  To
> get the charset of the current locale, you can use “locale -k charmap”,
> for example.  It corresponds to the glibc charmap name (of which there
> aren't too many).

So the recommended way is to just set LANG to the wanted value and then
look whether locale -k charmap will return the expected value? And
'charmap="ANSI_X3.4-1968"' is a telltale sign that I set LANG to a value
that isnt generated on the local system?

Greetings
Marc

-- 
-----
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421



Seeing clarification for locale names

2021-02-14 Thread Marc Haber
[Please Cc: me on replies, I am not subscribed to Debian-glibc]

Hi,

I am a bit confused about locale names. In literature, one can see that
a proper locale name is, for example, en_US.UTF-8. This is also what I
write in /etc/locale.gen to have one locale "generated" on my system.

locale -a, however, will print en_US.utf8. I _think_ this is the
intended behavior since there is a normalizing function somewhere in the
glibc sources which lowercases everything and thows out all
interpunction.

Otoh, there are applications that will malfuntion or print a warning if
the locale isn't explicitly set to .UTF-8 (upper case, hyphen).

In my shell profile scripts, I have code that will check whether the
intended locale is actually present on the local system by comparing to
locale -a's output (avoiding a fallback to a non-UTF-8 locale not
knowing about German umlauts if one is available). Hence, my locale
environment variables are all set to the respective .utf8 suffix since
that's what locale -a will print. Is this a wrong approach?

I would appreciate pointers to documentation, personal opinions, war
stories, encoding tales, historic lectures, anything that might
enlighten me and help me build the knowlegde and understanding about
UNIX locales are supposed to work in Debian GNU/Linux. Thank you in
advance!

Greetings
Ma 'Schei? Encoding!' rc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421



Bug#968252: gai.conf should mention ip addrlabel

2020-08-11 Thread Marc Haber
Package: libc-bin
Version: 2.31-3
Severity: normal
Tags: ipv6

Hi,

it looks like the label values set in the gai.conf file are ignored.
Instead, the values configured in the live kernel via ip addrlabel are
used.


It might be possible that there is some magic at bootup reading gai.conf
and poking the content in the kernel, but in the running system it looks
like ip addrlabel is the way to do configuration.

This should be properly reflected in the comments inside the gai.conf
file that comes with libc-bin.

Greetings
Marc

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.8.0-zgws1 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libc-bin depends on:
ii  libc6  2.31-3

Versions of packages libc-bin recommends:
ii  manpages  5.07-1

libc-bin suggests no packages.

-- no debconf information



Bug#932644: reconfigure writes to /usr/lib/locale/locale-archive

2019-07-24 Thread Marc Haber
On Mon, Jul 22, 2019 at 07:20:42PM +0200, Aurelien Jarno wrote:
> On 2019-07-21 17:11, Marc Haber wrote:
> > Package: locales
> > Version: 2.28-10
> > Severity: minor
> > 
> > Hi,
> > 
> > reconfiguring the locales package updates the file
> > /usr/lib/locale/locale-archive.
> 
> This is indeed where the libc looks for the compiled locales.

And it wouldn't follow a symlink to /var/lib/locale/locale-archive,
where variable data would belong?

> > I am not sure whether this is allowed by policy, hence severity: minor.
> 
> I do not find anything that prevents that in the policy. In addition
> many other packages are also writing files to /usr when they are
> configured (for example __pycache__ files or the various kernel
> modules.* files used by depmod, udev hwdb.bin, etc.).

But they only do that on package installation. And: "look, how bad the
neighbor is" is hardly an excuse. I happened to stumble upon that in
locales, and it's the first time that I actually noticed that.

> > Maybe this file would better be in /var.
> 
> /var is for files whose content is expected to continually change during
> normal operation of the system. This is not the case of the
> locale-archive file which doesn't change until the next reconfiguration
> of the package. As such it doesn't prevent for example mounting the / or
> /usr partition read-only once apt or dpkg have finished their work.

You're of course entitled to your opinion and I respect the decision.

Just assume:

- ansible/puppet/salt etc has a /etc/locale.gen which for some reason
  doesn't have the current set of comments
- a handler calls dpkg-reconfigure locales to handle the change in
  /etc/locale.gen
- locales rewrites /etc/locale.gen with the current set of comments
- ansible/puppet/salt runs again, notices that /etc/locale.gen is not as
  it should be according to its opinion
- repeat starting with step 1

locales' current behavior forces people to have the /etc/locale.gen file
with current comments in the configuraiton management code, and possible
to have this "current" differently according to whether we have
oldoldstable, oldstable, stable, testing od unstable. This is
unnecessary work and might cause unnecessary issues.

Please reconsider.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421



Bug#932708: rewrites comments in /etc/locale.gen

2019-07-21 Thread Marc Haber
Package: locales
Version: 2.28-10
Severity: minor

Hi,

a least in buster and later, reconfiguring locales will rewrite
the comments in /etc/locale.gen which indicate available locales. This
might confuse file integrity checkers and causes value ping-pong with
configuration management systems.

Please consider making the addition of commented-out locale indicators
configurable.

Greetings
Marc

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.2.1-zgws1 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages locales depends on:
ii  debconf [debconf-2.0]  1.5.72
ii  libc-bin   2.28-10
ii  libc-l10n  2.28-10

locales recommends no packages.

locales suggests no packages.

-- debconf information excluded



Bug#932644: reconfigure writes to /usr/lib/locale/locale-archive

2019-07-21 Thread Marc Haber
Package: locales
Version: 2.28-10
Severity: minor

Hi,

reconfiguring the locales package updates the file
/usr/lib/locale/locale-archive.

I am not sure whether this is allowed by policy, hence severity: minor.
Maybe this file would better be in /var.

Greetings
Marc

-- System Information:
Debian Release: 10.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.2.1-zgsrv20080 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages locales depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  libc-bin   2.28-10
ii  libc-l10n  2.28-10

locales recommends no packages.

locales suggests no packages.

-- debconf information:
* locales/locales_to_be_generated: de_DE.UTF-8 UTF-8, en_US.UTF-8 UTF-8
* locales/default_environment_locale: en_US.UTF-8



Bug#930486: rewrites /etc/default file even if no functional change

2019-06-13 Thread Marc Haber
Package: locales
Version: 2.28-10
Severity: minor
File: /usr/sbin/update-locale

Hi,

when I invoke /usr/sbin/update-locale, the /etc/default/locale file gets
changed even if there was no functional change. This might trigger
intrusion detection mechanisms.

Please consider adapting the script to do the following:

- write new file /etc/default/locale.tmp
- compare files, ignoring order ot environment variables, whitespace and
  comment lines
- if no change, remove /etc/default/locale.tmp
- if changed, mv /etc/default/locale.tmp /etc/default/locale

This avoids unnecessary alarms. Thanks!

Greetings
Marc


-- System Information:
Debian Release: 10.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.1.9-zgws1 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages locales depends on:
ii  debconf [debconf-2.0]  1.5.72
ii  libc-bin   2.28-10
ii  libc-l10n  2.28-10

locales recommends no packages.

locales suggests no packages.

-- debconf information excluded



Bug#864480: why is en_DK included but not en_DE?

2017-06-15 Thread Marc Haber
On Fri, Jun 09, 2017 at 12:15:15PM +0200, Marc Haber wrote:
> On Fri, Jun 09, 2017 at 11:14:20AM +0200, Samuel Thibault wrote:
> > So what you want is actually LC_LANG=de_DE LANGUAGE=en, right?
> 
> If all software was correct, yes. I have a few programs from the GNOME
> ecosystem that still insist on their German l10n with this setting.
> 
> I must admit that I have never fully understood all the locale stuff in
> Unix :-(

I tried reading up on this again. Which man page should I read aside
from locale (5) and locale(7), which does explain a bunch of LC_foo, but
neither LC_LANG nor LANGUAGE?

Greetings
Marc

-- 
-----
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421



Bug#864480: why is en_DK included but not en_DE?

2017-06-09 Thread Marc Haber
On Fri, Jun 09, 2017 at 11:14:20AM +0200, Samuel Thibault wrote:
> Marc Haber, on ven. 09 juin 2017 10:57:12 +0200, wrote:
> > frankly, I don't have a clue whether I am filing this against the
> > correct package
> 
> No problem, we reassign :)

Thanks!

> > I am a native speaker of German, living in Germany. And I do detest
> > software translated to German since German translations of technical
> > terms are often clumsy. I would therefore love having my Debian in
> > English, but with German punctuation, collation order, monetary and date
> > display setting etc.
> 
> So what you want is actually LC_LANG=de_DE LANGUAGE=en, right?

If all software was correct, yes. I have a few programs from the GNOME
ecosystem that still insist on their German l10n with this setting.

I must admit that I have never fully understood all the locale stuff in
Unix :-(

> I guess this is what #842630 ("localechooser: Should support separating
> language from localization") is about, then: no need for a new locale,
> just a need for separating the language from the rest of the locale.

Yes, looks that way.

> Otherwise we'd end up with a flurry of language/country combination,
> that'd be unmaintainable.

I was just astonished that the Danish get the privilege, and ther
Germans dont.

Greetings
Marc
-- 
-----
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421



Bug#864480: why is en_DK included but not en_DE?

2017-06-09 Thread Marc Haber
Package: locales
Version: 2.24-11
Severity: wishlist

Hi,

frankly, I don't have a clue whether I am filing this against the
correct package or whether I would need to talk to some (which?)
upstream for this, but maybe you can point me in the correct direction
if I am wrong here.

I am a native speaker of German, living in Germany. And I do detest
software translated to German since German translations of technical
terms are often clumsy. I would therefore love having my Debian in
English, but with German punctuation, collation order, monetary and date
display setting etc.

Since an en_DK exists, but no en_DE, I usually run my systems with en_DK
and correct the few differences between Danish and German customs
manually. This is, however, getting clumsy as well.

What do I do to bring a proper en_DE locale into Debian? I am willing to
do some work by trying to give a patch and to maintain it in the future.
Please advise what to do.

Greetings
Marc



Bug#627531: mishandles 'options rotate' if only one IPv6 nameserver is given

2011-05-21 Thread Marc Haber
Package: libc6
Version: 2.11.2-11
Severity: normal

Hi,

this may be a duplicate of #593571, and I am not in the situation to
test the patch given in #593571 at the moment due to time constraints,
but I'll file it separately since it is easier to merge than to split ;)

Steps to reproduce:
  - in /etc/resolv.conf
- set options rotate
- set a single nameserver with an IPv6 address
- do not set nameservers with IPv4 addresses
- set search zugschlus.de
  - ping6 torres
  - ping6 torres.zugschlus.de

Expected behavior:
  - clean ping to 2a01:238:4071:3201::1

What's happening:
  - both ping6 commands result in unknown host
  - with ping6 torres no DNS query can be seen going out to the DNS
server
  - with ping6 torres.zugschlus.de, a DNS query for
torres.zugschlus.de.zugschlus.de goes out and is answered with
NXDOMAIN

Greetings
Marc

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

Kernel: Linux 2.6.38.4-zgws1 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libc6 depends on:
ii  libc-bin  2.11.2-11  Embedded GNU C Library: Binaries
ii  libgcc1   1:4.6.0-6  GCC support library

Versions of packages libc6 recommends:
ii  libc6-i6862.11.2-11  Embedded GNU C Library: Shared lib

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0] 1.5.39 Debian configuration management sy
pn  glibc-doc none (no description available)
ii  locales   2.11.2-11  Embedded GNU C Library: National L

-- debconf information:
  glibc/upgrade: true
  glibc/disable-screensaver:
  glibc/restart-failed:
  glibc/restart-services:



-- 
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/20110521173522.31249.19788.report...@swivel.zugschlus.de



Bug#466026: libc6: doesn't upgrade from etch

2008-02-15 Thread Marc Haber
Package: libc6
Version: 2.3.6.ds1-13etch4
Severity: important

Hi,

libc6 does not cleanly upgrade from etch to sid. Steps to reproduce:

unpack etch chroot
update sources.list to sid
aptitude update
aptitude install libc6

[5/[EMAIL PROTECTED] etch]:~$ dpkg --list libc6
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name   VersionDescription
+++-==-==-
ii  libc6  2.3.6.ds1-13et GNU C Library: Shared libraries
[6/[EMAIL PROTECTED] etch]:~$ sudo aptitude install libc6
Reading package lists... Done
Building dependency tree... Done
Reading extended state information
Initializing package states... Done
Writing extended state information... Done
Building tag database... Done
The following packages are BROKEN:
  libc6 locales
The following packages have been kept back:
  apt apt-utils aptitude base-files base-passwd bash bsdutils coreutils
  debconf debconf-english debian-archive-keyring debianutils diff dpkg
  e2fslibs e2fsprogs findutils gcc-4.1-base gnupg gpgv grep gzip hostname
  initscripts jed jed-common less libacl1 libattr1 libblkid1 libbz2-1.0
  libcomerr2 libdb4.2 libdb4.3 libdb4.4 libgcc1 libgcrypt11 libgnutls13
  libgpg-error0 libldap2 libncurses5 libncursesw5 libnewt0.52
  libpam-modules libpam-runtime libpam0g libreadline5 libsasl2-2
  libselinux1 libsepol1 libslang2 libss2 libssl0.9.8 libstdc++6 libtasn1-3
  libusb-0.1-4 libuuid1 login lsb-base makedev mime-support mktemp mount
  ncurses-base ncurses-bin perl-base procps psmisc python python-central
  python-minimal python2.4 python2.4-minimal readline-common reportbug sed
  sudo sysv-rc sysvinit sysvinit-utils tar tzdata util-linux whiptail
  zlib1g
1 packages upgraded, 0 newly installed, 0 to remove and 86 not upgraded.
Need to get 4394kB of archives. After unpacking 451kB will be freed.
The following packages have unmet dependencies:
  locales: Depends: glibc-2.3.6.ds1-1 which is a virtual package.
  libc6: Conflicts: tzdata ( 2007k-1) but 2007j-1etch1 is installed and it is 
kept back.
Resolving dependencies...
The following actions will resolve these dependencies:

Upgrade the following packages:
locales [2.3.6.ds1-13etch4 (now) - 2.7-8 (unstable)]
tzdata [2007j-1etch1 (now) - 2007k-3 (unstable)]

Score is 10

Accept this solution? [Y/n/q/?] y
The following packages have been kept back:
  apt apt-utils aptitude base-files base-passwd bash bsdutils coreutils
  debconf debconf-english debian-archive-keyring debianutils diff dpkg
  e2fslibs e2fsprogs findutils gcc-4.1-base gnupg gpgv grep gzip hostname
  initscripts jed jed-common less libacl1 libattr1 libblkid1 libbz2-1.0
  libcomerr2 libdb4.2 libdb4.3 libdb4.4 libgcc1 libgcrypt11 libgnutls13
  libgpg-error0 libldap2 libncurses5 libncursesw5 libnewt0.52
  libpam-modules libpam-runtime libpam0g libreadline5 libsasl2-2
  libselinux1 libsepol1 libslang2 libss2 libssl0.9.8 libstdc++6 libtasn1-3
  libusb-0.1-4 libuuid1 login lsb-base makedev mime-support mktemp mount
  ncurses-base ncurses-bin perl-base procps psmisc python python-central
  python-minimal python2.4 python2.4-minimal readline-common reportbug sed
  sudo sysv-rc sysvinit sysvinit-utils tar util-linux whiptail zlib1g
The following packages will be upgraded:
  libc6 locales tzdata
3 packages upgraded, 0 newly installed, 0 to remove and 84 not upgraded.
Need to get 9550kB of archives. After unpacking 1667kB will be used.
Do you want to continue? [Y/n/?] y
Writing extended state information... Done
Get:1 http://debian.debian.zugschlus.de sid/main tzdata 2007k-3 [727kB]
Get:2 http://debian.debian.zugschlus.de sid/main locales 2.7-8 [4429kB]
Get:3 http://debian.debian.zugschlus.de sid/main libc6 2.7-8 [4394kB]
Fetched 9550kB in 1s (6032kB/s)
Preconfiguring packages ...
(Reading database ... 6764 files and directories currently installed.)
Preparing to replace tzdata 2007j-1etch1 (using .../tzdata_2007k-3_all.deb) ...
Unpacking replacement tzdata ...
Setting up tzdata (2007k-3) ...

User defined timezone, leaving /etc/localtime unchanged.
Local time is now:  Sat Feb 16 00:12:28 UTC 2008.
Universal Time is now:  Sat Feb 16 00:12:28 UTC 2008.
Run 'dpkg-reconfigure tzdata' if you wish to change it.


(Reading database ... 6764 files and directories currently installed.)
Preparing to replace locales 2.3.6.ds1-13etch4 (using 
.../archives/locales_2.7-8_all.deb) ...
Unpacking replacement locales ...
Preparing to replace libc6 2.3.6.ds1-13etch4 (using 
.../archives/libc6_2.7-8_i386.deb) ...

Name Service Switch update in the C Library: pre-installation question.

Running services and programs that are using NSS need to be restarted,
otherwise they might not be able to do lookup or authentication any more.
The installation process is able to restart some services (such as ssh or
telnetd), but other 

Bug#466027: tzdata: does not update from etch to sid

2008-02-15 Thread Marc Haber
Package: tzdata
Version: 2007k-3
Severity: important

Hi,

# debootstrap --resolve-deps etch foo http://your.mirror.example/debian/
# chroot foo apt-get update
# chroot foo apt-get install debfoster
# chroot foo debfoster -o MaxPriority=required -o UseRecommends=no -f -n apt 
debfoster
# chroot foo dpkg --purge debfoster
# chroot foo apt-get update
# chroot foo mount -t proc proc /proc
# edit foo/etc/apt/sources.list from etch to sid
# chroot foo apt-get update
# chroot foo apt-get install tzdata
Reading package lists... Done
Building dependency tree... Done
The following extra packages will be installed:
  debconf debconf-i18n libc6 liblocale-gettext-perl libtext-charwidth-perl
  libtext-iconv-perl libtext-wrapi18n-perl perl-base
Suggested packages:
  debconf-doc debconf-utils libgnome2-perl libnet-ldap-perl libqt-perl
  libterm-readline-gnu-perl whiptail dialog gnome-utils locales glibc-doc
  libc6-i686
Recommended packages:
  apt-utils
The following NEW packages will be installed:
  debconf debconf-i18n liblocale-gettext-perl libtext-charwidth-perl
  libtext-iconv-perl libtext-wrapi18n-perl
The following packages will be upgraded:
  libc6 perl-base tzdata
3 upgraded, 6 newly installed, 0 to remove and 61 not upgraded.
Need to get 0B/6269kB of archives.
After unpacking 2691kB of additional disk space will be used.
Do you want to continue [Y/n]? y
WARNING: The following packages cannot be authenticated!
  liblocale-gettext-perl libtext-charwidth-perl libtext-iconv-perl
  libtext-wrapi18n-perl debconf-i18n debconf tzdata libc6 perl-base
Install these packages without verification [y/N]? y
E: Internal Error, Could not perform immediate configuration (2) on tzdata


This is incidentally the procedure piuparts uses for upgrading, so
this issue seems to hinder piuparts tests. I do not have enough clue
about tzdata to find out whether this is really a tzdata bug. The
error message is not very conclusive.

Greetings
Marc

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

Kernel: Linux 2.6.24.2-zgsrv (SMP w/1 CPU core; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

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

tzdata recommends no packages.

-- debconf information excluded



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



Bug#425610: locales: dpkg-reconfigure fails: unexpected end of file

2007-07-12 Thread Marc Haber
On Wed, May 30, 2007 at 04:16:15PM +0200, Marc Haber wrote:
 On Wed, May 30, 2007 at 11:11:02AM +0200, Aurelien Jarno wrote:
  I am unable to reproduce this bug. Could you please add a -x to the
  first line of /var/lib/dpkg/info/locales.postinst (after #! /bin/sh) and
  rerun it again? This should tell us the location of the problem.
 
 $ sudo /usr/sbin/update-locale LANG=de_DE.UTF-8
 sh: -c: line 0: unexpected EOF while looking for matching '
 sh: -c: line 1: syntax error: unexpected end of file
 $
 
 After stracing, it looks like that update-locale (perl) at some place
 does
 
 execve(/bin/sh, [sh, -c, LANG= LC_CTYPE= LC_NUMERIC= LC_TIME= 
 LC_COLLATE= LC_MONETARY= LC_MESSAGES= LC_PAPER= LC_NAME= LC_ADDRESS= 
 LC_TELEPHONE= LC_MEASUREMENT= LC_IDENTIFICATION= LC_ALL= LANG=de_DE.UTF-8 
 LC_MESSAGES=\en_US.UTF-8 locale charmap 21], [/* 13 vars */]) = 0
 
 (note the missing quote after en_US.UTF-8 in the setting of
 LC_MESSAGES) which finally makes the shell barf.

My fault. I had
LC_MESSAGES=en_US.UTF-8
in /etc/default/locales (note the missing quote).

Greetings
Marc

-- 
-
Marc Haber | I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things.Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835


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



Bug#425610: locales: dpkg-reconfigure fails: unexpected end of file

2007-05-30 Thread Marc Haber
On Wed, May 30, 2007 at 11:11:02AM +0200, Aurelien Jarno wrote:
 I am unable to reproduce this bug. Could you please add a -x to the
 first line of /var/lib/dpkg/info/locales.postinst (after #! /bin/sh) and
 rerun it again? This should tell us the location of the problem.

$ sudo /usr/sbin/update-locale LANG=de_DE.UTF-8
sh: -c: line 0: unexpected EOF while looking for matching '
sh: -c: line 1: syntax error: unexpected end of file
$

After stracing, it looks like that update-locale (perl) at some place
does

execve(/bin/sh, [sh, -c, LANG= LC_CTYPE= LC_NUMERIC= LC_TIME= 
LC_COLLATE= LC_MONETARY= LC_MESSAGES= LC_PAPER= LC_NAME= LC_ADDRESS= 
LC_TELEPHONE= LC_MEASUREMENT= LC_IDENTIFICATION= LC_ALL= LANG=de_DE.UTF-8 
LC_MESSAGES=\en_US.UTF-8 locale charmap 21], [/* 13 vars */]) = 0

(note the missing quote after en_US.UTF-8 in the setting of
LC_MESSAGES) which finally makes the shell barf.

Greetings
Marc

-- 
-
Marc Haber | I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things.Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 3221 2323190


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



Bug#425610: locales: dpkg-reconfigure fails: unexpected end of file

2007-05-22 Thread Marc Haber
Package: locales
Version: 2.5-8
Severity: normal

$ sudo env DEBIAN_FRONTEND=readline dpkg-reconfigure locales
Configuring locales
---

Locales are a framework to switch between multiple languages and allow users to
use their language, country, characters, collation order, etc.

Please choose which locales to generate. UTF-8 locales should be chosen by
default, particularly for new installations. Other character sets may be useful
for backwards compatibility with older systems and software.

  1. All locales  200. fr_LU ISO-8859-1
snip
  199. [EMAIL PROTECTED] ISO-8859-15

(Enter the items you want to select, separated by spaces.)

Locales to be generated: 90 91 127


Many packages in Debian use locales to display text in the correct language for
the user. You can choose a default locale for the system from the generated
locales.

This will select the default language for the entire system. If this
system is a multi-user system where not all users are able to speak
the default language, they will experience difficulties.

  1. None  2. de_DE.UTF-8  3. [EMAIL PROTECTED]  4. en_US.UTF-8

Default locale for the system environment: 2


Generating locales (this might take a while)...
  de_DE.UTF-8... done
  [EMAIL PROTECTED] done
  en_US.UTF-8... done
Generation complete.
sh: -c: line 0: unexpected EOF while looking for matching `'
sh: -c: line 1: syntax error: unexpected end of file
$


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

Kernel: Linux 2.6.21.1-scyw00225 (PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages locales depends on:
ii  debconf [debconf-2.0] 1.5.13 Debian configuration management sy
ii  libc6 [glibc-2.5-1]   2.5-8  GNU C Library: Shared libraries

locales recommends no packages.

-- debconf information:
* locales/default_environment_locale: de_DE.UTF-8
* locales/locales_to_be_generated: de_DE.UTF-8 UTF-8, [EMAIL PROTECTED] UTF-8, 
en_US.UTF-8 UTF-8


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



please provide package to allow static link agains libc6-xen

2006-10-06 Thread Marc Haber
clone #391353 -1
retitle -1 please provide package to allow static link agains libc6-xen
reassign -1 glibc
submitter -1 Marc Haber [EMAIL PROTECTED]
block #391353 with -1
thanks

On Fri, Oct 06, 2006 at 08:58:16AM +0200, Raphael Hertzog wrote:
[snip bug report about statically linked aide binary DoSsing xen guest]
 However it looks like there's no libc6-xen-dev to link statically a
 xen-enabled libc6... 

Please allow static linking of xen-enabled libc6.

Greetings
Marc

-- 
-
Marc Haber | I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things.Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835


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



Bug#345639: marked as done (nl_langinfo(YESEXPR) ignores LANGUAGE, no apparent workaround)

2006-02-12 Thread Marc Haber
On Sun, Feb 12, 2006 at 06:18:16AM -0800, Debian Bug Tracking System wrote:
 There is no bug, LANGUAGE is only used to determine which message
 catalog is displayed.  Bug submitter should instead set LANG=de_CH.UTF-8
 and LC_* variables to en_GB.UTF-8 if needed.

Claudio, can you verify this?

Denis, is there any documentation about the LC, LANG, LANGUAGE
variables where I could read up on this stuff?

Greetings
Marc

-- 
-
Marc Haber | I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things.Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835


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



Bug#330929: how can adduser reliably find out wheter nscd is running?

2005-10-04 Thread Marc Haber
On Tue, Oct 04, 2005 at 01:28:07PM +0200, Gabor Gombas wrote:
 On Mon, Oct 03, 2005 at 06:07:26PM +0200, Marc Haber wrote:
  That's how we're going to do it in the future. I would, however, like
  to have the fact documented that it is not an error to run nscd -i if
  no daemon is running.
 
 What do you mean by not an error? nscd -i of course will return a
 non-0 exit code since it cannot invalidate the cache if the daemon is
 not running, but that is OK for adduser. I think you simply should not
 care if nscd -i succeeds or fails.

I am concerned about nscd suddenly giving an actual error message
instead of silently returning non-zero, which might confuse the users.

Greetings
Marc

-- 
-
Marc Haber | I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things.Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835


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



Bug#330929: how can adduser reliably find out wheter nscd is running?

2005-10-04 Thread Marc Haber
On Tue, Oct 04, 2005 at 02:38:56PM +0200, Gabor Gombas wrote:
 On Tue, Oct 04, 2005 at 02:18:18PM +0200, Marc Haber wrote:
  I am concerned about nscd suddenly giving an actual error message
  instead of silently returning non-zero, which might confuse the users.
 
 Well, my personal preference would be not to worry about this until it
 becomes a real issue (that future error message may be descriptive
 enough, after all).

Adduser has _a lot_ of installations and is mainly used by maintainer
scripts. Thus, _a lot_ of people are bound to see error messages
generated by adduser and are bound to be confused by them.

 Or you can just add 2/dev/null to the nscd -i
 invocation.

That will also kill real error messages.

Greetings
Marc

-- 
-
Marc Haber | I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things.Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835


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



Bug#330929: how can adduser reliably find out wheter nscd is running?

2005-10-04 Thread Marc Haber
On Tue, Oct 04, 2005 at 03:17:33PM +0200, Gabor Gombas wrote:
 Are there any useful real error messages now? For example, if nscd is
 not running, trying to invalidate a non-existing map will not produce an
 error message, and if nscd is running, the error message is misleading.

I don't know, as I have never used nscd.

 I still prefer not fixing what is not broken. glibc upgrades are always
 complex and require lots of testing. So I think even if nscd behavior is
 changed upstream in the future, there will be enough time before the
 next Debian release to discover any problems and update adduser if
 neccessary.

Thanks for trying to help. You can close this bug if you want to.

Greetings
Marc

-- 
-
Marc Haber | I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things.Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835


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



Bug#330929: how can adduser reliably find out wheter nscd is running?

2005-10-03 Thread Marc Haber
On Mon, Oct 03, 2005 at 05:52:59PM +0200, Gabor Gombas wrote:
 On Fri, Sep 30, 2005 at 04:05:40PM +0200, Marc Haber wrote:
  However, this heuristics has recently begun to fail because the
  pidfile has moved from /var/run to /var/run/nscd. Instead of changing
  adduser to check for both files (and probably fail on the next
  location change), I'd like to have a clearly drawn interface to find
  out whether it is necessary to invalidate nscd or not.
 
 Why do you need to know if it is running or not? Why not just call
 nscd -i unconditionally if nscd is installed?

That's how we're going to do it in the future. I would, however, like
to have the fact documented that it is not an error to run nscd -i if
no daemon is running.

Greetings
Marc

-- 
-
Marc Haber | I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things.Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835


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



Bug#330929: how can adduser reliably find out wheter nscd is running?

2005-09-30 Thread Marc Haber
Package: nscd
Severity: wishlist

adduser needs to invalidate certain nscd tables after changes were
done. Today, it looks for the pid file of nscd to find out whether
nscd is running, and then calls nscd via system() with -i and the
appropriate arguments.

However, this heuristics has recently begun to fail because the
pidfile has moved from /var/run to /var/run/nscd. Instead of changing
adduser to check for both files (and probably fail on the next
location change), I'd like to have a clearly drawn interface to find
out whether it is necessary to invalidate nscd or not.

What do you, as nscd maintainer(s) recommend to have adduser do?

Thanks for your opinion.

Greetings
Marc

-- System Information:
Debian Release: testing/unstable
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.13-zgsrv
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)


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



Bug#321719: libc6: locale -a returns values even if locales package is not installed

2005-08-17 Thread Marc Haber
On Wed, Aug 17, 2005 at 11:47:43AM +0900, GOTO Masanori wrote:
 Please try: ls -al /usr/lib/locale/locale-archive .
 If it's existed, then try to remove this file and invoke locale -a again.
 I guess it's simply locales.prerm bug.

The file exists, and removing it makes locale -a return C and POSIX.

Greetings
Marc

-- 
-
Marc Haber | I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things.Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835


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



Bug#321719: libc6: locale -a returns values even if locales package is not installed

2005-08-07 Thread Marc Haber
Package: libc6
Version: 2.3.2.ds1-22
Severity: normal

Hi,

$ locale -a
locale: Cannot set LC_CTYPE to default locale: No such file or directory
C
POSIX
de_DE
de_DE.iso88591
[EMAIL PROTECTED]
de_DE.utf8
[EMAIL PROTECTED]
deutsch
german
$ dpkg --list locales
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name   VersionDescription
+++-==-==-
pn  localesnone (no description available)
[57/[EMAIL PROTECTED] sid-clamav-getfiles]:~$

Since the man page says that -a writes the names of _available_
locales, and no locales are available without the locales package. So,
locale should notice this.

This was the case in previous versions, and is not that way any more.

Greetings
Marc

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12.2-zgsrv
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)

Versions of packages libc6 depends on:
ii  libdb1-compat 2.1.3-7The Berkeley database routines [gl

libc6 recommends no packages.

-- no debconf information


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



Bug#321719: libc6: locale -a returns values even if locales package is not installed

2005-08-07 Thread Marc Haber
found #321719 2.3.5-3
thanks

On Sun, Aug 07, 2005 at 09:43:06AM +0200, Marc Haber wrote:
 Package: libc6
 Version: 2.3.2.ds1-22
 Severity: normal

Actually, the system I have found that bug on runs 2.3.5-3. I cannot
verify wether 2.3.2.ds1-22 actually has the bug since I do not have a
2.3.2 system without locales readily available.

Greetings
Marc

-- 
-
Marc Haber | I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things.Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835


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



Bug#225872: linux-kernel-headers: build and clean give truckload of [: =: unary operator expected errors

2004-01-02 Thread Marc Haber
Package: linux-kernel-headers
Version: 2.5.999-test7-bk-11
Severity: normal

Hi,

the attached typescript shows examples where debian/rules clean and
build show some errors in the patch scripts, complaining about wrong
use of test operators.

I don't know about cdbs to debug any further. This is caused by the
almost complete absence of cdbs documentation (see #220756).

Greetings
Marc

Script started on Fri Jan  2 08:21:41 2004
$ fakeroot debian/rules clean
test -x debian/rules
test `id -u` = 0
if test -n   test  != .; then rmdir ; fi
if test . != .; then rmdir .; fi
dh_clean
patches: debian/patches/alpha-asm-param.patch debian/patches/arm-query-module.patch 
debian/patches/asm-i386-byteorder-u64.patch 
debian/patches/asm-system-and-padding.patch debian/patches/byteorder-const.patch 
debian/patches/byteorder.patch debian/patches/ia64-modutils.patch 
debian/patches/ia64-pal.patch debian/patches/ia64-pt-unwind-warning.patch 
debian/patches/ioctl-signedness.patch debian/patches/linux-fb-compilefix.patch 
debian/patches/linux-list-quiet-warning.patch 
debian/patches/linux-netlink-compilation.patch debian/patches/linux-pci.patch 
debian/patches/linux-radix-tree.patch debian/patches/linux-types-and-time.patch 
debian/patches/linux-types-long-long.patch debian/patches/linux-types-ustat.patch 
debian/patches/linux-unistd-errno.patch debian/patches/mips-ansi-fixes.patch 
debian/patches/msdos-fs.patch debian/patches/msqid64_ds-inconsistency.patch 
debian/patches/no-linux-compiler-h.patch debian/patches/videodev2-timeval.patch
Not reversing not applied patches.
if [ reverse-patches = debian/stamp-patched ]; then touch debian/stamp-patched; fi
rm -f debian/stamp-patch*
rm -f debian/patches/*.log
/usr/bin/make -C testsuite clean
make[1]: Entering directory 
`/home/mh/linux-kernel-headers/linux-kernel-headers-2.5.999-test7-bk/testsuite'
rm -f attribute-used.o cdrom.o dev-t.o fs.o msdos-fs.o netlink.o pci.o videodev-time.o 
videodev.o 295-attribute-used.o 295-cdrom.o 295-dev-t.o 295-fs.o 295-msdos-fs.o 
295-netlink.o 295-pci.o 295-videodev-time.o 295-videodev.o ansi-attribute-used.o 
ansi-dev-t.o ansi-fs.o ansi-msdos-fs.o ansi-netlink.o ansi-pci.o cc-attribute-used.o 
cc-cdrom.o cc-dev-t.o cc-fs.o cc-msdos-fs.o cc-pci.o cc-videodev-time.o cc-videodev.o 
cc-ansi-attribute-used.o cc-ansi-cdrom.o cc-ansi-dev-t.o cc-ansi-fs.o 
cc-ansi-msdos-fs.o cc-ansi-pci.o
make[1]: Leaving directory 
`/home/mh/linux-kernel-headers/linux-kernel-headers-2.5.999-test7-bk/testsuite'
rm -f stamp-lkh-install
$ fakeroot debian/rules build
test -x debian/rules
if [ -n  ]; then \
  mkdir -p ; \
fi
if [ ! -d . ]; then \
  mkdir -p .; \
fi
if [ -z  ]; then \
  if ! test -f debian/compat; then echo 4  debian/compat; fi; \
fi
patches: debian/patches/alpha-asm-param.patch debian/patches/arm-query-module.patch 
debian/patches/asm-i386-byteorder-u64.patch 
debian/patches/asm-system-and-padding.patch debian/patches/byteorder-const.patch 
debian/patches/byteorder.patch debian/patches/ia64-modutils.patch 
debian/patches/ia64-pal.patch debian/patches/ia64-pt-unwind-warning.patch 
debian/patches/ioctl-signedness.patch debian/patches/linux-fb-compilefix.patch 
debian/patches/linux-list-quiet-warning.patch 
debian/patches/linux-netlink-compilation.patch debian/patches/linux-pci.patch 
debian/patches/linux-radix-tree.patch debian/patches/linux-types-and-time.patch 
debian/patches/linux-types-long-long.patch debian/patches/linux-types-ustat.patch 
debian/patches/linux-unistd-errno.patch debian/patches/mips-ansi-fixes.patch 
debian/patches/msdos-fs.patch debian/patches/msqid64_ds-inconsistency.patch 
debian/patches/no-linux-compiler-h.patch debian/patches/videodev2-timeval.patch
Trying patch debian/patches/alpha-asm-param.patch at level 0.../bin/sh: line 1: [: =: 
unary operator expected
success.
Trying patch debian/patches/arm-query-module.patch at level 0.../bin/sh: line 1: [: =: 
unary operator expected
success.
Trying patch debian/patches/asm-i386-byteorder-u64.patch at level 0.../bin/sh: line 1: 
[: =: unary operator expected
success.
Trying patch debian/patches/asm-system-and-padding.patch at level 0.../bin/sh: line 1: 
[: =: unary operator expected
success.
Trying patch debian/patches/byteorder-const.patch at level 0.../bin/sh: line 1: [: =: 
unary operator expected
success.
Trying patch debian/patches/byteorder.patch at level 0.../bin/sh: line 1: [: =: unary 
operator expected
success.
Trying patch debian/patches/ia64-modutils.patch at level 0.../bin/sh: line 1: [: =: 
unary operator expected
success.
Trying patch debian/patches/ia64-pal.patch at level 0.../bin/sh: line 1: [: =: unary 
operator expected
success.
Trying patch debian/patches/ia64-pt-unwind-warning.patch at level 0.../bin/sh: line 1: 
[: =: unary operator expected
1.../bin/sh: line 1: [: =: unary operator expected
success.
Trying patch debian/patches/ioctl-signedness.patch at level 0.../bin/sh: line 1: [: =: 
unary operator expected
success.
Trying patch 

Bug#225671: linux-kernel-headers: please consider making target directory configurable on build time

2004-01-02 Thread Marc Haber
On Wed, Dec 31, 2003 at 01:24:01PM +0100, Marc Haber wrote:
 Affected files would be:
 
 debian/linux-kernel-headers.install
 debian/linux-kernel-headers.preinst
 debian/rules
 debian/generate-asm.sh

testsuite/Makefile

Greetings
Marc

-- 
-
Marc Haber | I don't trust Computers. They | Mailadresse im Header
Karlsruhe, Germany |  lose things.Winona Ryder | Fon: *49 721 966 32 15
Nordisch by Nature |  How to make an American Quilt | Fax: *49 721 966 31 29


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



Bug#225872: linux-kernel-headers: build and clean give truckload of [: =: unary operator expected errors

2004-01-02 Thread Marc Haber
Package: linux-kernel-headers
Version: 2.5.999-test7-bk-11
Severity: normal

Hi,

the attached typescript shows examples where debian/rules clean and
build show some errors in the patch scripts, complaining about wrong
use of test operators.

I don't know about cdbs to debug any further. This is caused by the
almost complete absence of cdbs documentation (see #220756).

Greetings
Marc

Script started on Fri Jan  2 08:21:41 2004
$ fakeroot debian/rules clean
test -x debian/rules
test `id -u` = 0
if test -n   test  != .; then rmdir ; fi
if test . != .; then rmdir .; fi
dh_clean
patches: debian/patches/alpha-asm-param.patch 
debian/patches/arm-query-module.patch 
debian/patches/asm-i386-byteorder-u64.patch 
debian/patches/asm-system-and-padding.patch 
debian/patches/byteorder-const.patch debian/patches/byteorder.patch 
debian/patches/ia64-modutils.patch debian/patches/ia64-pal.patch 
debian/patches/ia64-pt-unwind-warning.patch 
debian/patches/ioctl-signedness.patch debian/patches/linux-fb-compilefix.patch 
debian/patches/linux-list-quiet-warning.patch 
debian/patches/linux-netlink-compilation.patch debian/patches/linux-pci.patch 
debian/patches/linux-radix-tree.patch debian/patches/linux-types-and-time.patch 
debian/patches/linux-types-long-long.patch 
debian/patches/linux-types-ustat.patch debian/patches/linux-unistd-errno.patch 
debian/patches/mips-ansi-fixes.patch debian/patches/msdos-fs.patch 
debian/patches/msqid64_ds-inconsistency.patch 
debian/patches/no-linux-compiler-h.patch debian/patches/videodev2-timeval.patch
Not reversing not applied patches.
if [ reverse-patches = debian/stamp-patched ]; then touch 
debian/stamp-patched; fi
rm -f debian/stamp-patch*
rm -f debian/patches/*.log
/usr/bin/make -C testsuite clean
make[1]: Entering directory 
`/home/mh/linux-kernel-headers/linux-kernel-headers-2.5.999-test7-bk/testsuite'
rm -f attribute-used.o cdrom.o dev-t.o fs.o msdos-fs.o netlink.o pci.o 
videodev-time.o videodev.o 295-attribute-used.o 295-cdrom.o 295-dev-t.o 
295-fs.o 295-msdos-fs.o 295-netlink.o 295-pci.o 295-videodev-time.o 
295-videodev.o ansi-attribute-used.o ansi-dev-t.o ansi-fs.o ansi-msdos-fs.o 
ansi-netlink.o ansi-pci.o cc-attribute-used.o cc-cdrom.o cc-dev-t.o cc-fs.o 
cc-msdos-fs.o cc-pci.o cc-videodev-time.o cc-videodev.o 
cc-ansi-attribute-used.o cc-ansi-cdrom.o cc-ansi-dev-t.o cc-ansi-fs.o 
cc-ansi-msdos-fs.o cc-ansi-pci.o
make[1]: Leaving directory 
`/home/mh/linux-kernel-headers/linux-kernel-headers-2.5.999-test7-bk/testsuite'
rm -f stamp-lkh-install
$ fakeroot debian/rules build
test -x debian/rules
if [ -n  ]; then \
  mkdir -p ; \
fi
if [ ! -d . ]; then \
  mkdir -p .; \
fi
if [ -z  ]; then \
  if ! test -f debian/compat; then echo 4  debian/compat; fi; \
fi
patches: debian/patches/alpha-asm-param.patch 
debian/patches/arm-query-module.patch 
debian/patches/asm-i386-byteorder-u64.patch 
debian/patches/asm-system-and-padding.patch 
debian/patches/byteorder-const.patch debian/patches/byteorder.patch 
debian/patches/ia64-modutils.patch debian/patches/ia64-pal.patch 
debian/patches/ia64-pt-unwind-warning.patch 
debian/patches/ioctl-signedness.patch debian/patches/linux-fb-compilefix.patch 
debian/patches/linux-list-quiet-warning.patch 
debian/patches/linux-netlink-compilation.patch debian/patches/linux-pci.patch 
debian/patches/linux-radix-tree.patch debian/patches/linux-types-and-time.patch 
debian/patches/linux-types-long-long.patch 
debian/patches/linux-types-ustat.patch debian/patches/linux-unistd-errno.patch 
debian/patches/mips-ansi-fixes.patch debian/patches/msdos-fs.patch 
debian/patches/msqid64_ds-inconsistency.patch 
debian/patches/no-linux-compiler-h.patch debian/patches/videodev2-timeval.patch
Trying patch debian/patches/alpha-asm-param.patch at level 0.../bin/sh: line 1: 
[: =: unary operator expected
success.
Trying patch debian/patches/arm-query-module.patch at level 0.../bin/sh: line 
1: [: =: unary operator expected
success.
Trying patch debian/patches/asm-i386-byteorder-u64.patch at level 0.../bin/sh: 
line 1: [: =: unary operator expected
success.
Trying patch debian/patches/asm-system-and-padding.patch at level 0.../bin/sh: 
line 1: [: =: unary operator expected
success.
Trying patch debian/patches/byteorder-const.patch at level 0.../bin/sh: line 1: 
[: =: unary operator expected
success.
Trying patch debian/patches/byteorder.patch at level 0.../bin/sh: line 1: [: =: 
unary operator expected
success.
Trying patch debian/patches/ia64-modutils.patch at level 0.../bin/sh: line 1: 
[: =: unary operator expected
success.
Trying patch debian/patches/ia64-pal.patch at level 0.../bin/sh: line 1: [: =: 
unary operator expected
success.
Trying patch debian/patches/ia64-pt-unwind-warning.patch at level 0.../bin/sh: 
line 1: [: =: unary operator expected
1.../bin/sh: line 1: [: =: unary operator expected
success.
Trying patch debian/patches/ioctl-signedness.patch at level 0.../bin/sh: line 
1: [: =: unary operator expected
success.
Trying patch 

Bug#225671: linux-kernel-headers: please consider making target directory configurable on build time

2004-01-02 Thread Marc Haber
On Wed, Dec 31, 2003 at 01:24:01PM +0100, Marc Haber wrote:
 Affected files would be:
 
 debian/linux-kernel-headers.install
 debian/linux-kernel-headers.preinst
 debian/rules
 debian/generate-asm.sh

testsuite/Makefile

Greetings
Marc

-- 
-
Marc Haber | I don't trust Computers. They | Mailadresse im Header
Karlsruhe, Germany |  lose things.Winona Ryder | Fon: *49 721 966 32 15
Nordisch by Nature |  How to make an American Quilt | Fax: *49 721 966 31 29




Bug#225671: linux-kernel-headers: please consider making target directory configurable on build time

2004-01-02 Thread Marc Haber
On Thu, Jan 01, 2004 at 12:27:43PM +, Colin Watson wrote:
 Almost all of the patch would simply be adding files, and then you might
 have a trivial change to the include path if you're unlucky. This
 wouldn't be hard at all. Plus, you can probably get the maintainer to
 include the same patch in later versions.

I feel we're at cross-purposes here. What I would like to have is the
possibility to build a linux-kernel-headers package that _doesn't_
install 2.6 headers to /usr/include, leaving the 2.4 kernel headers
intact.

A package needing 2.6 headers could depend on my local
linux-kernel-headers package and carry
-I/usr/include/linux-kernel-headers in its Makefile.

I don't see where this setup would break the local libc.

Greetings
Marc

-- 
-
Marc Haber | I don't trust Computers. They | Mailadresse im Header
Karlsruhe, Germany |  lose things.Winona Ryder | Fon: *49 721 966 32 15
Nordisch by Nature |  How to make an American Quilt | Fax: *49 721 966 31 29




Bug#225671: linux-kernel-headers: please consider making target directory configurable on build time

2003-12-31 Thread Marc Haber
On Wed, Dec 31, 2003 at 04:59:48PM +, Colin Watson wrote:
 Wouldn't it be much easier and less confusing to users to copy the
 relevant headers into the packages that need them to build?

Probably. But that's a politics decision. I only want my backports to
work, and I prefer not spending entire working days for a single
backport ;)

 This has the
 added advantage of being what you're supposed to do anyway, but it
 should be easy enough to do that in a backport ...

The problem is that my experience shows that a backport works best the
less you have changed in the packages. Additionally, huge backport
patches make it harder to backport later versions.

Greetings
Marc

-- 
-
Marc Haber | I don't trust Computers. They | Mailadresse im Header
Karlsruhe, Germany |  lose things.Winona Ryder | Fon: *49 721 966 32 15
Nordisch by Nature |  How to make an American Quilt | Fax: *49 721 966 31 29


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



Bug#225650: linux-kernel-headers: missing symlink include/asm - asm-$ARCH causes /usr/include/asm to be used

2003-12-31 Thread Marc Haber
Package: linux-kernel-headers
Version: 2.5.999-test7-bk-10
Severity: wishlist

Hi,

when the package is built, there is no include/asm. This causes
/usr/include/asm to be used during package build, which breaks on
woody. This will probably cause interesting effects when packaging the
next kernel-headers version that has differing include/asm definitions.

IMO, a symlink include/asm - asm-$ARCH needs to be generated on
package build, otherwise building the test suite will fail.

Greetings
Marc

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux kes 2.4.23-kes #1 Mon Dec 22 10:14:13 UTC 2003 i686
Locale: LANG=C, LC_CTYPE=C

-- no debconf information





Bug#225671: linux-kernel-headers: please consider making target directory configurable on build time

2003-12-31 Thread Marc Haber
Package: linux-kernel-headers
Version: 2.5.999-test7-bk-10
Severity: wishlist

Hi,

linux-kernel-headers places the headers in /usr/include, which is fine
for a sarge or sid system. On woody, however, this makes
linux-kernel-headers uninstallable if one doesn't want to update glibc
(which is usually exactly what you want to avoid when using
woody+backports).

Some packages need more recent kernel headers to build (for example,
devmapper). To help backporting these packages, it would be a good
idea to have an option to build a linux-kernel-headers package that
doesn't conflict with woody's libc6-dev.

This would be more easily possible if there were a debian/rules option
to set the target directory from /usr/include to /usr/include/foo.

Please consider adding that option to ease backporting efforts..

Affected files would be:

debian/linux-kernel-headers.install
debian/linux-kernel-headers.preinst
debian/rules
debian/generate-asm.sh

Greetings
Marc

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux kes 2.4.23-kes #1 Mon Dec 22 10:14:13 UTC 2003 i686
Locale: LANG=C, LC_CTYPE=C

-- no debconf information





Bug#225650: linux-kernel-headers: missing symlink include/asm - asm-$ARCH causes /usr/include/asm to be used

2003-12-31 Thread Marc Haber
On Wed, Dec 31, 2003 at 09:12:42AM -0500, Daniel Jacobowitz wrote:
 On Wed, Dec 31, 2003 at 11:21:11AM +0100, Marc Haber wrote:
  Package: linux-kernel-headers
  Version: 2.5.999-test7-bk-10
  Severity: wishlist
  
  Hi,
  
  when the package is built, there is no include/asm. This causes
  /usr/include/asm to be used during package build, which breaks on
  woody. This will probably cause interesting effects when packaging the
  next kernel-headers version that has differing include/asm definitions.
  
  IMO, a symlink include/asm - asm-$ARCH needs to be generated on
  package build, otherwise building the test suite will fail.
 
 Please give more details.

I am going to try.

When building the package, the testsuite is built with something along
the lines of -I../include which points to include/asm in the source
package root directory.

That directory doesn't have an include/asm symlink at this time of
building, causing #include asm/foo to pull in /usr/include/asm/foo
instead of ../include/asm-$ARCH/foo. This is not a problem on sid
since sid systems _currently_ have a compatible (identical?) file in
/usr/include, but fails on woody. And it's bound to fail when the
kernel headers are changed in a way that include/asm will differ.

 I know that changes to asm-i386/ show up in the testsuite results so it
 works here.  Perhaps a different version of debhelper is breaking some
 assumption?

Probably, since I am talking woody here.

If this doesn't help, I will give more explicit results when I have
again access to the build host.

Greetings
Marc

-- 
-
Marc Haber | I don't trust Computers. They | Mailadresse im Header
Karlsruhe, Germany |  lose things.Winona Ryder | Fon: *49 721 966 32 15
Nordisch by Nature |  How to make an American Quilt | Fax: *49 721 966 31 29




Bug#225671: linux-kernel-headers: please consider making target directory configurable on build time

2003-12-31 Thread Marc Haber
On Wed, Dec 31, 2003 at 04:59:48PM +, Colin Watson wrote:
 Wouldn't it be much easier and less confusing to users to copy the
 relevant headers into the packages that need them to build?

Probably. But that's a politics decision. I only want my backports to
work, and I prefer not spending entire working days for a single
backport ;)

 This has the
 added advantage of being what you're supposed to do anyway, but it
 should be easy enough to do that in a backport ...

The problem is that my experience shows that a backport works best the
less you have changed in the packages. Additionally, huge backport
patches make it harder to backport later versions.

Greetings
Marc

-- 
-
Marc Haber | I don't trust Computers. They | Mailadresse im Header
Karlsruhe, Germany |  lose things.Winona Ryder | Fon: *49 721 966 32 15
Nordisch by Nature |  How to make an American Quilt | Fax: *49 721 966 31 29