Processing control commands:
> reassign -1 libc6
Bug #595790 [coreutils] hostid: useless unless fixed
Bug reassigned from package 'coreutils' to 'libc6'.
No longer marked as found in versions coreutils/8.5-1.
Ignoring request to alter fixed versions of bug #595790 to the same values
previously se
Processing commands for cont...@bugs.debian.org:
> retitle 595790 The value from gethostid() should be more unique and not
> change when the host IP changes
Bug #595790 [libc6] hostid: useless unless fixed
Changed Bug title to 'The value from gethostid() should be more unique and not
change when
Control: reassign -1 libc6
Control: found -1 2.19-18
Control: The value from gethostid() should be more unique and not change when
the host IP changes
Reassigning to glibc as that is the source of gethostid() where the
problem with the missing unique identifier originates. Using the
version numb
On Tue, Sep 27, 2016 at 06:24:20PM +0200, Aurelien Jarno wrote:
> On 2016-09-27 16:00, Florian Weimer wrote:
> Ok. I have seen this change in 4.7.5:
>
> | commit bec4e55b55867ed948a3afd9f9ccf3506bfdad24
> | Author: Michal Hocko
> | Date: Thu Sep 1 16:14:41 2016 -0700
> |
> | mm, oom: preven
* Petter Reinholdtsen:
> Something like this should work, I guess:
>
> if [ ! -f /etc/hostid ]; then
>if [ -e /sys/class/dmi/id/product_uuid ]; then
>sethostidfromuuid $(cat /sys/class/dmi/id/product_uuid)
>else
> dd if=/dev/urandom bs=1 count=4 of=/etc/hostid 2>/dev/null
>
[Florian Weimer]
> That's not very different from /etc/machine-id, isn't it?
Ah, thank you very much for bringing this systemd setting to my
attention. I was not aware of it.
I agree that it seem very similar in purpose and implementation. Will
it be available on non-linux Debian architectures
Hi,
I recently learned that ul (from bsdmainutils) segfaults when run against the
attached file. Some debugging shows that the segfault happens when cleaning up
in errx():
michael@feivel:~$ ul ul.segf
ul: unknown escape sequence in input: 33, 135
Speicherzugriffsfehler
"Speicherzugriffsfehler"
On Wed, Sep 28, 2016 at 12:32:04PM +0200, Florian Weimer wrote:
* Petter Reinholdtsen:
Something like this should work, I guess:
if [ ! -f /etc/hostid ]; then
if [ -e /sys/class/dmi/id/product_uuid ]; then
sethostidfromuuid $(cat /sys/class/dmi/id/product_uuid)
else
dd if=/
* Petter Reinholdtsen:
> [Florian Weimer]
>> That's not very different from /etc/machine-id, isn't it?
>
> Ah, thank you very much for bringing this systemd setting to my
> attention. I was not aware of it.
>
> I agree that it seem very similar in purpose and implementation. Will
> it be availab
* Michael Meskes:
> I recently learned that ul (from bsdmainutils) segfaults when run
> against the attached file. Some debugging shows that the segfault
> happens when cleaning up in errx():
>
> michael@feivel:~$ ul ul.segf
> ul: unknown escape sequence in input: 33, 135
> Speicherzugriffsfehler
* Florian Weimer:
> * Michael Meskes:
>
>> I recently learned that ul (from bsdmainutils) segfaults when run
>> against the attached file. Some debugging shows that the segfault
>> happens when cleaning up in errx():
>>
>> michael@feivel:~$ ul ul.segf
>> ul: unknown escape sequence in input: 33,
On Wed, Sep 28, 2016 at 02:36:49PM +0200, Florian Weimer wrote:
> What's the glibc version and architecture?
Oops, sorry, up-to-date unstable on amd64.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: mic
* Florian Weimer:
>> I can reproduce something like this with 2.24-3 on amd64. valgrind
>> isn't very helpful.
>
> And it needs a UTF-8 locale (C.UTF-8 will do). Another multi-byte
> locale may work as well.
Bisecting this with the attached script leads to:
commit 18d26750dd8fd328a78cf639fd0ec
Processing commands for cont...@bugs.debian.org:
> unarchive 821358
Bug #821358 {Done: Aurelien Jarno } [libc6] nss_hesiod
segfaults in sock_eq
Unarchived Bug 821358
> found 821358 2.19-18+deb8u6
Bug #821358 {Done: Aurelien Jarno } [libc6] nss_hesiod
segfaults in sock_eq
Marked as found in versi
Processing control commands:
> reopen -1
Bug #821358 {Done: Aurelien Jarno } [libc6] nss_hesiod
segfaults in sock_eq
'reopen' may be inappropriate when a bug has been closed with a version;
all fixed versions will be cleared, and you may need to re-add them.
Bug reopened
No longer marked as fixed
Control: reopen -1
Control: found -1 2.19-18+deb8u6
Control: tags -1 + jessie
On Sun, 17 Apr 2016, Anders Kaseorg wrote:
> glibc 2.22 broke nss_hesiod so that it segfaults on almost all uses. To
> reproduce:
>
> # sed -i 's/^passwd:.*/& hesiod/' /etc/nsswitch.conf
> # cat > /etc/hesiod.conf < l
Processing commands for cont...@bugs.debian.org:
> fixed 821358 2.22-8
Bug #821358 [libc6] nss_hesiod segfaults in sock_eq
Marked as fixed in versions glibc/2.22-8.
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
821358: http://bugs.debian.org/cgi-bin/bugreport.cg
On Mon, 15 Aug 2016, Aurelien Jarno wrote:
> + * debian/patches/any/submitted-resolv-ipv6-nameservers.diff: replace by
> +patch cvs-resolv-ipv6-nameservers.diff taken from upstream. This fixes
> +mtr on systems using only IPv6 nameservers. Closes: #818281.
This is the commit that introdu
[Michael Stone]
> Other platforms have deprecated gethostid, that's the best way forward for
> linux, IMO.
Which platforms is this? I find FreeBSD recommend to use sysctl and
KERN_HOSTID to get the hostid integer directly from the kernel instead
of using gethostid(), which isn't really depricati
On Wed, Sep 28, 2016 at 11:11:21PM +0200, Petter Reinholdtsen wrote:
[Michael Stone]
Other platforms have deprecated gethostid, that's the best way forward for
linux, IMO.
Which platforms is this? I find FreeBSD recommend to use sysctl and
KERN_HOSTID to get the hostid integer directly from t
On 2016-09-28 09:33, Petter Reinholdtsen wrote:
> Control: reassign -1 libc6
> Control: found -1 2.19-18
> Control: The value from gethostid() should be more unique and not change when
> the host IP changes
>
> Reassigning to glibc as that is the source of gethostid() where the
> problem with the
On Thu, Sep 29, 2016 at 12:30:39AM +0200, Aurelien Jarno wrote:
Another question is about chroots. The above methods means we might
end-up with the same machine-id in chroots id the DMI UUID is available.
Is it something really wanted?
One of the many ambiguities of gethostid. :) Is it a unique
* Michael Stone:
> Other platforms have deprecated gethostid, that's the best way forward
> for linux, IMO.
I agree. It's the most likely outcome if this issue was reported to
glibc upstream.
Processing control commands:
> severity -1 serious
Bug #821358 [libc6] nss_hesiod segfaults in sock_eq
Severity set to 'serious' from 'important'
--
821358: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=821358
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Control: severity -1 serious
Bumping severity because this is a regression introduced in a stable
update.
Anders
On 09/28/2016 04:41 AM, Petter Reinholdtsen wrote:
> I did not quite understand what you mean here. Do you mean the DMI
> value in your experience isn't unique?
Absolutely, yes. I found this out because, for some reason that I don't
know, libvirtd wants a unique identifier. It defaults to looking
[Aurelien Jarno]
> In any case it looks to me we should not reinvent the wheel. We
> already ended-up with two implementations of a unique machine ID, one
> in dbus and one for systemd (which fortunately now try to just copy
> the other one if it already exists), I am not sure we want a third
> one
27 matches
Mail list logo
