Bug#839141: tzdata: Wrong data/timezone for Asia/Baku
control: tag -1 + moreinfo On 2016-09-29 14:05, Saipem-root wrote: > Package: tzdata > Version: 2016f-0+deb8u1 > Severity: important > > Dear Maintainer, > > *** Reporter, please consider answering these questions, where appropriate *** > >* What led up to the situation? >* What exactly did you do (or not do) that was effective (or > ineffective)? >* What was the outcome of this action? >* What outcome did you expect instead? > > *** End of the template - remove these template lines *** > > I choosed the timezone Asia/Baku (supposed to be UTC +0400) but checking the > "date", the system replay with a wrong date (UTC +0200). > I tried to choose also other timezones and all seems ok. > So, I think it's necessary to fix the timezone Asia/Baku. > In the mean time I choosed Asia/Dubai and my system works fine. Unfortunately I am not able to reproduce the issue here, I therefore need more info from your side. Would it be possible to configure the timezone again to Asia/Baku and paste the resulting output? This should be something like this: | Current default time zone: 'Asia/Baku' | Local time is now: Fri Sep 30 00:44:09 AZT 2016. | Universal Time is now: Thu Sep 29 20:44:09 UTC 2016. Thanks, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Processed: Re: Bug#839141: tzdata: Wrong data/timezone for Asia/Baku
Processing control commands: > tag -1 + moreinfo Bug #839141 [tzdata] tzdata: Wrong data/timezone for Asia/Baku Added tag(s) moreinfo. -- 839141: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839141 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#595790: [Pkg-zfsonlinux-devel] Bug#595790: hostid: useless unless fixed
[Richard Laager] > For example, if you want to use the low 32-bits of /etc/machine-id, > that would work too. It'd mean carrying a patch on Debian, but if the > pain of a patch and different behavior is less than the benefits of > the change, go for it. I guess we would have to verify that /etc/machine-id is available in the initrd for this to work with / in zfs. But I guess that is a problem with /etc/hostid too for gethostid(). :) While researching this topic I came across http://stackoverflow.com/questions/9258228/how-to-prevent-gethostid-from-doing-dns-lookups-on-linux > which report that gethostid() might lock up a program if the DNS server become unavailable. A scary scenario just to get the machine ID. I also came across http://0pointer.de/blog/projects/ids.html >, which provide a very useful list of possible IDs to use in addition to the gethostid() value. It agrees that gethostid() have unclear sematics. :) -- Happy hacking Petter Reinholdtsen
Bug#595790: [Pkg-zfsonlinux-devel] Bug#595790: hostid: useless unless fixed
On 09/29/2016 05:19 AM, Michael Stone wrote: > On Wed, Sep 28, 2016 at 09:03:38PM -0700, Richard Laager wrote: >> Getting back to ZFS and /etc/hostid... I would think that a >> randomly-generated /etc/hostid is probably sufficient. Whether that's >> done in the libc, spl, or zfs package makes no difference to me. > > You still haven't explained why zfs doesn't just generate a uuid itself. > > There's a large body of work ensuring reasonable uniqueness for uuids, > and there isn't a clear benefit to clinging to getuid. It can't be a full UUID. The on-disk format of ZFS uses a 32-bit integer. It doesn't really matter what we use to derive it, but a 32-bit integer is the constraint. For example, if you want to use the low 32-bits of /etc/machine-id, that would work too. It'd mean carrying a patch on Debian, but if the pain of a patch and different behavior is less than the benefits of the change, go for it. > Even on solaris > there's a big honkin' warning on the man page that it isn't guaranteed > to be unique (IIRC, getuid on containers reflects the hardware the > container is running on). On Solaris the zone (container) wouldn't import the pool. Pools are imported in the "global zone". So this isn't a problem. -- Richard
Bug#821358: nss_hesiod segfaults in sock_eq
control: severity -1 important On 2016-09-29 00:09, Anders Kaseorg wrote: > Control: severity -1 serious > > Bumping severity because this is a regression introduced in a stable > update. > While this is unfortunate and will be fixed, i don't see why the fact that the regression have been introduced in a stable update changes the severity of the bug. Downgrading it back to important. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Processed: Re: Bug#821358: nss_hesiod segfaults in sock_eq
Processing control commands: > severity -1 important Bug #821358 [libc6] nss_hesiod segfaults in sock_eq Severity set to 'important' from 'serious' -- 821358: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=821358 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#839141: tzdata: Wrong data/timezone for Asia/Baku
Package: tzdata Version: 2016f-0+deb8u1 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** I choosed the timezone Asia/Baku (supposed to be UTC +0400) but checking the "date", the system replay with a wrong date (UTC +0200). I tried to choose also other timezones and all seems ok. So, I think it's necessary to fix the timezone Asia/Baku. In the mean time I choosed Asia/Dubai and my system works fine. -- System Information: Debian Release: 8.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages tzdata depends on: ii debconf [debconf-2.0] 1.5.56 tzdata recommends no packages. tzdata suggests no packages. -- debconf information: tzdata/Zones/America: * tzdata/Zones/Europe: Rome tzdata/Zones/US: tzdata/Zones/Arctic: tzdata/Zones/Australia: tzdata/Zones/Atlantic: * tzdata/Zones/Etc: UTC tzdata/Zones/Indian: tzdata/Zones/Pacific: * tzdata/Areas: Europe tzdata/Zones/SystemV: tzdata/Zones/Antarctica: tzdata/Zones/Africa: * tzdata/Zones/Asia: Dubai
Bug#595790: [Pkg-zfsonlinux-devel] Bug#595790: hostid: useless unless fixed
On Wed, Sep 28, 2016 at 09:03:38PM -0700, Richard Laager wrote: Getting back to ZFS and /etc/hostid... I would think that a randomly-generated /etc/hostid is probably sufficient. Whether that's done in the libc, spl, or zfs package makes no difference to me. You still haven't explained why zfs doesn't just generate a uuid itself. There's a large body of work ensuring reasonable uniqueness for uuids, and there isn't a clear benefit to clinging to getuid. Even on solaris there's a big honkin' warning on the man page that it isn't guaranteed to be unique (IIRC, getuid on containers reflects the hardware the container is running on). Mike Stone
Bug#595790: [Pkg-zfsonlinux-devel] Bug#595790: hostid: useless unless fixed
* Richard Laager: > Getting back to ZFS and /etc/hostid... I would think that a > randomly-generated /etc/hostid is probably sufficient. Whether that's > done in the libc, spl, or zfs package makes no difference to me. As I tried to explain, the risks of collisions without central coordination looks rather high. glibc's current approach, using the IP address associated with the host name, provides a certain level of coordination, avoiding duplicates.
