From dam at opencsw.org Tue Dec 3 09:15:33 2019 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 3 Dec 2019 09:15:33 +0100 Subject: Question: Have the network configuration of OpenCSW been changed? In-Reply-To: References: Message-ID: <775C803E-71D1-4127-825F-78F42FACB63D@opencsw.org> Hi Yusuke, Am 03.12.2019 um 00:41 schrieb Yusuke Endoh : > I'm Yusuke Endoh, a member of Ruby development team. > > Since 2 A.M. 1st Dec. 2019 UTC, our Ruby CIs on OpenCSW have failed. > The failure looks related to network configuration about localhost. > > https://rubyci.org/logs/rubyci.s3.amazonaws.com/unstable10s/ruby-master/log/20191202T171915Z.fail.html.gz > > ``` > DRb::DRbConnError: drbssl://::1:35909 - # > ``` > > So, I'd like to ask if something network stuff was changed? We rebooted the machine and some of the networking setup doesn?t come up automatically due to routing issues between the global zone and local zones. However, I just looked and as far as I can say it looks good to me. > If it is an intentional change, I'd be happy to tackle to fix the issue on the side of Ruby test suite. > I have seen the issue on unstable10s, 10x, 11s, and 11x. unstable10x, unstable11s and unstable11x have not been rebooted, these are different machines, so if you see the error there too it is not related due to networking on the rebooted host. > FWIW, `nslookup localhost` fails to find 127.0.0.1. > > ``` > rubyci at unstable10s [unstable10s]:~ > nslookup localhost > Server: 192.168.1.6 > Address: 192.168.1.6#53 > > ** server can't find localhost: NXDOMAIN > ``` It is our normal configuration to not resolve localhost via DNS, but you can resolve it locally with the resolver lib: root at unstable10s [unstable10s]:/root > getent hosts localhost 127.0.0.1 localhost root at unstable10s [unstable10s]:/root > nslookup localhost Server: 192.168.1.6 Address: 192.168.1.6#53 ** server can't find localhost: NXDOMAIN zsh: 26934 exit 1 nslookup localhost root at unstable10s [unstable10s]:/root > getent hosts localhost 127.0.0.1 localhost root at unstable10s [unstable10s]:/root > Maybe you can describe what the test actually does and why it technically fails, I am not sure at the moment what has changed, be it the build machine configuration or something in your code or something else. Best regards ? Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jh at baltic-online.de Tue Dec 3 10:12:04 2019 From: jh at baltic-online.de (=?utf-8?Q?Jan_Holzh=C3=BCter?=) Date: Tue, 3 Dec 2019 10:12:04 +0100 Subject: Question: Have the network configuration of OpenCSW been changed? In-Reply-To: <775C803E-71D1-4127-825F-78F42FACB63D@opencsw.org> References: <775C803E-71D1-4127-825F-78F42FACB63D@opencsw.org> Message-ID: <291E4718-74C7-463C-B27B-6CFEA6434A40@baltic-online.de> Hi, hast du ipv6 localhost script laufen lassen? > Am 03.12.2019 um 09:16 schrieb Dagobert Michelsen via buildfarm : > > ?Hi Yusuke, > >> Am 03.12.2019 um 00:41 schrieb Yusuke Endoh : >> I'm Yusuke Endoh, a member of Ruby development team. >> >> Since 2 A.M. 1st Dec. 2019 UTC, our Ruby CIs on OpenCSW have failed. >> The failure looks related to network configuration about localhost. >> >> https://rubyci.org/logs/rubyci.s3.amazonaws.com/unstable10s/ruby-master/log/20191202T171915Z.fail.html.gz >> >> ``` >> DRb::DRbConnError: drbssl://::1:35909 - # >> ``` >> >> So, I'd like to ask if something network stuff was changed? > > We rebooted the machine and some of the networking setup doesn?t come up automatically due to > routing issues between the global zone and local zones. However, I just looked and as far as I can > say it looks good to me. > >> If it is an intentional change, I'd be happy to tackle to fix the issue on the side of Ruby test suite. >> I have seen the issue on unstable10s, 10x, 11s, and 11x. > > unstable10x, unstable11s and unstable11x have not been rebooted, these are different machines, > so if you see the error there too it is not related due to networking on the rebooted host. > >> FWIW, `nslookup localhost` fails to find 127.0.0.1. >> >> ``` >> rubyci at unstable10s [unstable10s]:~ > nslookup localhost >> Server: 192.168.1.6 >> Address: 192.168.1.6#53 >> >> ** server can't find localhost: NXDOMAIN >> ``` > > It is our normal configuration to not resolve localhost via DNS, but you can resolve it locally > with the resolver lib: > > root at unstable10s [unstable10s]:/root > getent hosts localhost > 127.0.0.1 localhost > root at unstable10s [unstable10s]:/root > nslookup localhost > Server: 192.168.1.6 > Address: 192.168.1.6#53 > > ** server can't find localhost: NXDOMAIN > > zsh: 26934 exit 1 nslookup localhost > root at unstable10s [unstable10s]:/root > getent hosts localhost > 127.0.0.1 localhost > root at unstable10s [unstable10s]:/root > > > > Maybe you can describe what the test actually does and why it technically fails, > I am not sure at the moment what has changed, be it the build machine configuration > or something in your code or something else. > > > Best regards > > ? Dago > > > -- > "You don't become great by trying to be great, you become great by wanting to do something, > and then doing it so hard that you become great in the process." - xkcd #896 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Tue Dec 3 10:29:33 2019 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 3 Dec 2019 10:29:33 +0100 Subject: Question: Have the network configuration of OpenCSW been changed? In-Reply-To: <291E4718-74C7-463C-B27B-6CFEA6434A40@baltic-online.de> References: <775C803E-71D1-4127-825F-78F42FACB63D@opencsw.org> <291E4718-74C7-463C-B27B-6CFEA6434A40@baltic-online.de> Message-ID: <7A735665-48F7-4BED-AF92-24C7D69753F2@opencsw.org> Halklo Jan, > Am 03.12.2019 um 10:12 schrieb Jan Holzh?ter : > > Hi, > hast du ipv6 localhost script laufen lassen? Ja, z.B. root at unstable10s [unstable10s]:/root > ifconfig -a lo0:7: flags=2001000849 mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 e1000g1:6: flags=1000843 mtu 1500 index 3 inet 192.168.1.32 netmask ffffff00 broadcast 192.168.1.255 lo0:10: flags=2002000849 mtu 8252 index 1 inet6 ::1/128 das sieht f?r mich gut aus. Und f?r die nicht-gebooteten Rechner m?ssted as ja nach wie vor gehen. Besten DAnk ? Dago > >> Am 03.12.2019 um 09:16 schrieb Dagobert Michelsen via buildfarm : >> >> ?Hi Yusuke, >> >> Am 03.12.2019 um 00:41 schrieb Yusuke Endoh >: >>> I'm Yusuke Endoh, a member of Ruby development team. >>> >>> Since 2 A.M. 1st Dec. 2019 UTC, our Ruby CIs on OpenCSW have failed. >>> The failure looks related to network configuration about localhost. >>> >>> https://rubyci.org/logs/rubyci.s3.amazonaws.com/unstable10s/ruby-master/log/20191202T171915Z.fail.html.gz >>> >>> ``` >>> DRb::DRbConnError: drbssl://::1:35909 - # >>> ``` >>> >>> So, I'd like to ask if something network stuff was changed? >> >> We rebooted the machine and some of the networking setup doesn?t come up automatically due to >> routing issues between the global zone and local zones. However, I just looked and as far as I can >> say it looks good to me. >> >>> If it is an intentional change, I'd be happy to tackle to fix the issue on the side of Ruby test suite. >>> I have seen the issue on unstable10s, 10x, 11s, and 11x. >> >> unstable10x, unstable11s and unstable11x have not been rebooted, these are different machines, >> so if you see the error there too it is not related due to networking on the rebooted host. >> >>> FWIW, `nslookup localhost` fails to find 127.0.0.1. >>> >>> ``` >>> rubyci at unstable10s [unstable10s]:~ > nslookup localhost >>> Server: 192.168.1.6 >>> Address: 192.168.1.6#53 >>> >>> ** server can't find localhost: NXDOMAIN >>> ``` >> >> It is our normal configuration to not resolve localhost via DNS, but you can resolve it locally >> with the resolver lib: >> >> root at unstable10s [unstable10s]:/root > getent hosts localhost >> 127.0.0.1 localhost >> root at unstable10s [unstable10s]:/root > nslookup localhost >> Server: 192.168.1.6 >> Address: 192.168.1.6#53 >> >> ** server can't find localhost: NXDOMAIN >> >> zsh: 26934 exit 1 nslookup localhost >> root at unstable10s [unstable10s]:/root > getent hosts localhost >> 127.0.0.1 localhost >> root at unstable10s [unstable10s]:/root > >> >> >> Maybe you can describe what the test actually does and why it technically fails, >> I am not sure at the moment what has changed, be it the build machine configuration >> or something in your code or something else. >> >> >> Best regards >> >> ? Dago >> >> >> -- >> "You don't become great by trying to be great, you become great by wanting to do something, >> and then doing it so hard that you become great in the process." - xkcd #896 >> -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Tue Dec 3 10:43:01 2019 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 3 Dec 2019 10:43:01 +0100 Subject: Question: Have the network configuration of OpenCSW been changed? In-Reply-To: References: <775C803E-71D1-4127-825F-78F42FACB63D@opencsw.org> Message-ID: Hi Yusuke, > Am 03.12.2019 um 10:38 schrieb Yusuke Endoh : > > Thank you for the answer! > > I suspected the network configuration because: > > * the failures look related to network issue, > * all OpenCSW machines started failing all at once, > * the failures have never occurred on any other machines, and > * I couldn't find any relevant commits whose timestamp is near to that timing. There have been similar errors in the past which disappeared when I added IPv6 localhost, but this was added from the start after the reboot, so this is probably not the issue. > I don't know what the tests do :-) > To be honest, debugging in OpenCSW is painful because it is slow, so I wanted to isolate the problem before debugging. I suggest to start with the *x machine which should be reasonably fast as x86 on our VMware farm, then probably 11s which is a moderately new M3000. The *10s are the slowest ones. Best regards ? Dago > But I understand there has been no network change, so I'll give it a try to debug. Thank you very much! > > Best regards, > > 2019?12?3?(?) 17:15 Dagobert Michelsen >: > Hi Yusuke, > > Am 03.12.2019 um 00:41 schrieb Yusuke Endoh >: >> I'm Yusuke Endoh, a member of Ruby development team. >> >> Since 2 A.M. 1st Dec. 2019 UTC, our Ruby CIs on OpenCSW have failed. >> The failure looks related to network configuration about localhost. >> >> https://rubyci.org/logs/rubyci.s3.amazonaws.com/unstable10s/ruby-master/log/20191202T171915Z.fail.html.gz >> >> ``` >> DRb::DRbConnError: drbssl://::1:35909 <> - # >> ``` >> >> So, I'd like to ask if something network stuff was changed? > > We rebooted the machine and some of the networking setup doesn?t come up automatically due to > routing issues between the global zone and local zones. However, I just looked and as far as I can > say it looks good to me. > >> If it is an intentional change, I'd be happy to tackle to fix the issue on the side of Ruby test suite. >> I have seen the issue on unstable10s, 10x, 11s, and 11x. > > unstable10x, unstable11s and unstable11x have not been rebooted, these are different machines, > so if you see the error there too it is not related due to networking on the rebooted host. > >> FWIW, `nslookup localhost` fails to find 127.0.0.1. >> >> ``` >> rubyci at unstable10s [unstable10s]:~ > nslookup localhost >> Server: 192.168.1.6 >> Address: 192.168.1.6#53 >> >> ** server can't find localhost: NXDOMAIN >> ``` > > It is our normal configuration to not resolve localhost via DNS, but you can resolve it locally > with the resolver lib: > > root at unstable10s [unstable10s]:/root > getent hosts localhost > 127.0.0.1 localhost > root at unstable10s [unstable10s]:/root > nslookup localhost > Server: 192.168.1.6 > Address: 192.168.1.6#53 > > ** server can't find localhost: NXDOMAIN > > zsh: 26934 exit 1 nslookup localhost > root at unstable10s [unstable10s]:/root > getent hosts localhost > 127.0.0.1 localhost > root at unstable10s [unstable10s]:/root > > > > Maybe you can describe what the test actually does and why it technically fails, > I am not sure at the moment what has changed, be it the build machine configuration > or something in your code or something else. > > > Best regards > > ? Dago > > > -- > "You don't become great by trying to be great, you become great by wanting to do something, > and then doing it so hard that you become great in the process." - xkcd #896 > -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Fri Dec 20 20:59:49 2019 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 20 Dec 2019 20:59:49 +0100 Subject: unstable11x: libiconv broken since a long time In-Reply-To: <20191220193529.3dF3-%steffen@sdaoden.eu> References: <20191220193529.3dF3-%steffen@sdaoden.eu> Message-ID: Hi Steffen, Am 20.12.2019 um 20:35 schrieb Steffen Nurpmeso : > On unstable11x i see the following error > > ld: fatal: file /opt/csw/lib/libiconv.so: wrong ELF class: ELFCLASS32 > collect2: error: ld returned 1 exit status > *** Error code 1 > > since some months when using /usr/ccs/bin/gcc. > > Many thanks again for OpenCSW.org, i always find something i can > do better with my thing! > > Ciao, and a nice Christmas time i wish. This usually happens when you try to build 64 bit binaries and link to the 32 bit lib. Please check linker pathes if they append /64 for the correct libs. If that doesn?t help please post a reproducible testcase. Best regards ? Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From dam at opencsw.org Mon Dec 23 12:10:54 2019 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 23 Dec 2019 12:10:54 +0100 Subject: unstable11x: libiconv broken since a long time In-Reply-To: <20191220214826.tnPk5%steffen@sdaoden.eu> References: <20191220193529.3dF3-%steffen@sdaoden.eu> <20191220210546.PXaDY%steffen@sdaoden.eu> <20191220214826.tnPk5%steffen@sdaoden.eu> Message-ID: <1651AA0C-3C98-4D85-B6E9-64FD873F34EB@opencsw.org> Hi Steffen, > Am 20.12.2019 um 22:48 schrieb Steffen Nurpmeso : > > Steffen Nurpmeso wrote in <20191220210546.PXaDY%steffen at sdaoden.eu>: > |Dagobert Michelsen wrote in |w.org>: > ||Am 20.12.2019 um 20:35 schrieb Steffen Nurpmeso : > ||> On unstable11x i see the following error > ... > ||This usually happens when you try to build 64 bit binaries and link \ > ||to the 32 bit lib. > | > |Hmm, we are not specific with -march or so. We just test some > |standard compiler and linker flags and do it. > | > ||Please check linker pathes if they append /64 for the correct libs. \ > ||If that doesn?t help > ||please post a reproducible testcase. > ... > |Reproducable should thus be to log into my account > | > | cd src/nail.git > | git fetch > | git co -B next origin/next > | make devel > > Btw., i helped me out via > > make devel OPT_USE_PKGSYS=no > > which then uses the iconv from the C library and works :) What kind of esoteric buildsystem is this? How does this work? Best would be a simple, reproducible commandline where I can see what happens. The one you posted /usr/ccs/bin/gcc -Dmx_SOURCE -I./ -I/home/sdaoden/src/nail.git/include -I/home/sdaoden/src/nail.git/.obj -I/home/sdaoden/src/nail.git/include/ -I/home/sdaoden/src/nail.git/src/ -I/opt/csw/include -I/usr/xpg4/include -I/home/sdaoden/usr-unstable11x-sunos-i86pc/include -std=c89 -O -g -W -Wall -Wextra -Wbad-function-cast -Wcast-align -Wcast-qual -Winit-self -Wmissing-prototypes -Wshadow -Wunused -Wwrite-strings -Wno-long-long -pedantic -fno-unwind-tables -fno-asynchronous-unwind-tables -fstrict-aliasing -fstrict-overflow -Wstrict-overflow=5 -Wl,--as-needed -Wl,-rpath=/opt/csw/lib -Wl,-rpath=/usr/xpg4/lib -Wl,-rpath=/home/sdaoden/usr-unstable11x-sunos-i86pc/lib -o .obj/___tmp126808 .obj/___tmp126808.c -L/opt/csw/lib -L/usr/xpg4/lib -L/home/sdaoden/usr-unstable11x-sunos-i86pc/lib -liconv contains tempfiles which are not there. Best regards ? Dago > > |A nice Christmas time! > > Ciao, > > --steffen > | > |Der Kragenbaer, The moon bear, > |der holt sich munter he cheerfully and one by one > |einen nach dem anderen runter wa.ks himself off > |(By Robert Gernhardt) -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From dam at opencsw.org Mon Dec 23 12:17:12 2019 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 23 Dec 2019 12:17:12 +0100 Subject: unstable11x: libiconv broken since a long time In-Reply-To: <1651AA0C-3C98-4D85-B6E9-64FD873F34EB@opencsw.org> References: <20191220193529.3dF3-%steffen@sdaoden.eu> <20191220210546.PXaDY%steffen@sdaoden.eu> <20191220214826.tnPk5%steffen@sdaoden.eu> <1651AA0C-3C98-4D85-B6E9-64FD873F34EB@opencsw.org> Message-ID: <1AADC16D-3AF0-45EC-9823-BC5779219B25@opencsw.org> Hi Steffen, > Am 23.12.2019 um 12:10 schrieb Dagobert Michelsen via buildfarm : > > Hi Steffen, > >> Am 20.12.2019 um 22:48 schrieb Steffen Nurpmeso : >> >> Steffen Nurpmeso wrote in <20191220210546.PXaDY%steffen at sdaoden.eu>: >> |Dagobert Michelsen wrote in > |w.org>: >> ||Am 20.12.2019 um 20:35 schrieb Steffen Nurpmeso : >> ||> On unstable11x i see the following error >> ... >> ||This usually happens when you try to build 64 bit binaries and link \ >> ||to the 32 bit lib. >> | >> |Hmm, we are not specific with -march or so. We just test some >> |standard compiler and linker flags and do it. >> | >> ||Please check linker pathes if they append /64 for the correct libs. \ >> ||If that doesn?t help >> ||please post a reproducible testcase. >> ... >> |Reproducable should thus be to log into my account >> | >> | cd src/nail.git >> | git fetch >> | git co -B next origin/next >> | make devel >> >> Btw., i helped me out via >> >> make devel OPT_USE_PKGSYS=no >> >> which then uses the iconv from the C library and works :) > > What kind of esoteric buildsystem is this? How does this work? > Best would be a simple, reproducible commandline where I can see what happens. > The one you posted > > /usr/ccs/bin/gcc -Dmx_SOURCE -I./ -I/home/sdaoden/src/nail.git/include -I/home/sdaoden/src/nail.git/.obj -I/home/sdaoden/src/nail.git/include/ -I/home/sdaoden/src/nail.git/src/ -I/opt/csw/include -I/usr/xpg4/include -I/home/sdaoden/usr-unstable11x-sunos-i86pc/include -std=c89 -O -g -W -Wall -Wextra -Wbad-function-cast -Wcast-align -Wcast-qual -Winit-self -Wmissing-prototypes -Wshadow -Wunused -Wwrite-strings -Wno-long-long -pedantic -fno-unwind-tables -fno-asynchronous-unwind-tables -fstrict-aliasing -fstrict-overflow -Wstrict-overflow=5 -Wl,--as-needed -Wl,-rpath=/opt/csw/lib -Wl,-rpath=/usr/xpg4/lib -Wl,-rpath=/home/sdaoden/usr-unstable11x-sunos-i86pc/lib -o .obj/___tmp126808 .obj/___tmp126808.c -L/opt/csw/lib -L/usr/xpg4/lib -L/home/sdaoden/usr-unstable11x-sunos-i86pc/lib -liconv > > contains tempfiles which are not there. > > > Best regards > > ? Dago > >> >> |A nice Christmas time! Dir auch ein frohes Fest! Beste Gr??e ? Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From dam at opencsw.org Mon Dec 23 22:35:37 2019 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 23 Dec 2019 22:35:37 +0100 Subject: unstable11x: libiconv broken since a long time In-Reply-To: <20191223172408.JN7hZ%steffen@sdaoden.eu> References: <20191220193529.3dF3-%steffen@sdaoden.eu> <20191220210546.PXaDY%steffen@sdaoden.eu> <20191220214826.tnPk5%steffen@sdaoden.eu> <1651AA0C-3C98-4D85-B6E9-64FD873F34EB@opencsw.org> <20191223172408.JN7hZ%steffen@sdaoden.eu> Message-ID: Hallo Steffen, > Am 23.12.2019 um 18:24 schrieb Steffen Nurpmeso : > I attach the actual snippet as a shell script, it creates a t.c > and then tries to compile a t.exe. It fails on unstable11x. Ah yes, I should have noticed earlier: you are using /usr/ccs/bin/gcc which is shipped as part of Solaris. That one defaults to -m64. You can use /opt/csw/bin/gcc instead or use -m32 explicitly. Best regards ? Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From dam at opencsw.org Wed Dec 25 15:39:43 2019 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 25 Dec 2019 15:39:43 +0100 Subject: Please fix the clock skew of unstable10x In-Reply-To: References: Message-ID: Hi Yusuke, Am 25.12.2019 um 14:57 schrieb Yusuke Endoh : > Looks like the clock of unstable10x has been behind one hour since 21st. > This skew makes our AWS S3 upload script fail due to "Aws::S3::Errors::RequestTimeTooSkewed" error. > > Could you confirm the clock please? I can confirm that it is wrong :-/ unstable10x is connected to ncsw (192.168.1.1) which is connected to 10.0.0.19 @Jan, Rolf: have you been working on our NTP server or is this an artifact of the VMWare farm migration? Best regards ? Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From jh at baltic-online.de Wed Dec 25 15:51:39 2019 From: jh at baltic-online.de (=?utf-8?Q?Jan_Holzh=C3=BCter?=) Date: Wed, 25 Dec 2019 15:51:39 +0100 Subject: Please fix the clock skew of unstable10x In-Reply-To: References: Message-ID: 10.0.0.19 is offline. Please use ntp1.baltic-online.de. whatever that resolves to. > Am 25.12.2019 um 15:40 schrieb Dagobert Michelsen via buildfarm : > > ?Hi Yusuke, > >> Am 25.12.2019 um 14:57 schrieb Yusuke Endoh : >> Looks like the clock of unstable10x has been behind one hour since 21st. >> This skew makes our AWS S3 upload script fail due to "Aws::S3::Errors::RequestTimeTooSkewed" error. >> >> Could you confirm the clock please? > > I can confirm that it is wrong :-/ > > unstable10x is connected to ncsw (192.168.1.1) which is connected to 10.0.0.19 > @Jan, Rolf: have you been working on our NTP server or is this an artifact of the VMWare farm migration? > > > Best regards > > ? Dago > > > -- > "You don't become great by trying to be great, you become great by wanting to do something, > and then doing it so hard that you become great in the process." - xkcd #896 > From dam at opencsw.org Wed Dec 25 17:58:42 2019 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 25 Dec 2019 17:58:42 +0100 Subject: Please fix the clock skew of unstable10x In-Reply-To: References:

Message-ID: Hi Yusuke, Am 25.12.2019 um 15:51 schrieb Jan Holzh?ter : > 10.0.0.19 is offline. Please use ntp1.baltic-online.de. whatever that resolves to. Ah, I remember. This should be fixed now. @Yusuke: Please check and thanks for letting me know! Best regards ? Dago >> Am 25.12.2019 um 15:40 schrieb Dagobert Michelsen via buildfarm : >> >> ?Hi Yusuke, >> >>> Am 25.12.2019 um 14:57 schrieb Yusuke Endoh : >>> Looks like the clock of unstable10x has been behind one hour since 21st. >>> This skew makes our AWS S3 upload script fail due to "Aws::S3::Errors::RequestTimeTooSkewed" error. >>> >>> Could you confirm the clock please? >> >> I can confirm that it is wrong :-/ >> >> unstable10x is connected to ncsw (192.168.1.1) which is connected to 10.0.0.19 >> @Jan, Rolf: have you been working on our NTP server or is this an artifact of the VMWare farm migration? >> >> >> Best regards >> >> ? Dago >> >> >> -- >> "You don't become great by trying to be great, you become great by wanting to do something, >> and then doing it so hard that you become great in the process." - xkcd #896 >> > -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From steffen at sdaoden.eu Fri Dec 20 20:35:29 2019 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Fri, 20 Dec 2019 20:35:29 +0100 Subject: unstable11x: libiconv broken since a long time Message-ID: <20191220193529.3dF3-%steffen@sdaoden.eu> Hello. On unstable11x i see the following error ld: fatal: file /opt/csw/lib/libiconv.so: wrong ELF class: ELFCLASS32 collect2: error: ld returned 1 exit status *** Error code 1 since some months when using /usr/ccs/bin/gcc. Many thanks again for OpenCSW.org, i always find something i can do better with my thing! Ciao, and a nice Christmas time i wish. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From steffen at sdaoden.eu Fri Dec 20 22:05:46 2019 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Fri, 20 Dec 2019 22:05:46 +0100 Subject: unstable11x: libiconv broken since a long time In-Reply-To: References: <20191220193529.3dF3-%steffen@sdaoden.eu> Message-ID: <20191220210546.PXaDY%steffen@sdaoden.eu> Hello Dagobert. Dagobert Michelsen wrote in : |Am 20.12.2019 um 20:35 schrieb Steffen Nurpmeso : |> On unstable11x i see the following error |> |> ld: fatal: file /opt/csw/lib/libiconv.so: wrong ELF class: ELFCLASS32 |> collect2: error: ld returned 1 exit status |> *** Error code 1 |> |> since some months when using /usr/ccs/bin/gcc. ... |This usually happens when you try to build 64 bit binaries and link \ |to the 32 bit lib. Hmm, we are not specific with -march or so. We just test some standard compiler and linker flags and do it. |Please check linker pathes if they append /64 for the correct libs. \ |If that doesn?t help |please post a reproducible testcase. Cannot log in at the moment :-) But in tmux history :-) i have /usr/ccs/bin/gcc -Dmx_SOURCE -I./ -I/home/sdaoden/src/nail.git/include -I/home/sdaoden/src/nail.git/.obj -I/home/sdaoden/src/nail.git/include/ -I/home/sdaoden/src/nail.git/src/ -I/opt/csw/include -I/usr/xpg4/include -I/home/sdaoden/usr-unstable11x-sunos-i86pc/include -std=c89 -O -g -W -Wall -Wextra -Wbad-function-cast -Wcast-align -Wcast-qual -Winit-self -Wmissing-prototypes -Wshadow -Wunused -Wwrite-strings -Wno-long-long -pedantic -fno-unwind-tables -fno-asynchronous-unwind-tables -fstrict-aliasing -fstrict-overflow -Wstrict-overflow=5 -Wl,--as-needed -Wl,-rpath=/opt/csw/lib -Wl,-rpath=/usr/xpg4/lib -Wl,-rpath=/home/sdaoden/usr-unstable11x-sunos-i86pc/lib -o .obj/___tmp126808 .obj/___tmp126808.c -L/opt/csw/lib -L/usr/xpg4/lib -L/home/sdaoden/usr-unstable11x-sunos-i86pc/lib -liconv Reproducable should thus be to log into my account cd src/nail.git git fetch git co -B next origin/next make devel which should stop with the above in .obj/mk-config.log, i think. A nice Christmas time! --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From steffen at sdaoden.eu Fri Dec 20 22:48:26 2019 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Fri, 20 Dec 2019 22:48:26 +0100 Subject: unstable11x: libiconv broken since a long time In-Reply-To: <20191220210546.PXaDY%steffen@sdaoden.eu> References: <20191220193529.3dF3-%steffen@sdaoden.eu> <20191220210546.PXaDY%steffen@sdaoden.eu> Message-ID: <20191220214826.tnPk5%steffen@sdaoden.eu> Steffen Nurpmeso wrote in <20191220210546.PXaDY%steffen at sdaoden.eu>: |Dagobert Michelsen wrote in : ||Am 20.12.2019 um 20:35 schrieb Steffen Nurpmeso : ||> On unstable11x i see the following error ... ||This usually happens when you try to build 64 bit binaries and link \ ||to the 32 bit lib. | |Hmm, we are not specific with -march or so. We just test some |standard compiler and linker flags and do it. | ||Please check linker pathes if they append /64 for the correct libs. \ ||If that doesn?t help ||please post a reproducible testcase. ... |Reproducable should thus be to log into my account | | cd src/nail.git | git fetch | git co -B next origin/next | make devel Btw., i helped me out via make devel OPT_USE_PKGSYS=no which then uses the iconv from the C library and works :) |A nice Christmas time! Ciao, --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From steffen at sdaoden.eu Mon Dec 23 18:24:08 2019 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Mon, 23 Dec 2019 18:24:08 +0100 Subject: unstable11x: libiconv broken since a long time In-Reply-To: <1651AA0C-3C98-4D85-B6E9-64FD873F34EB@opencsw.org> References: <20191220193529.3dF3-%steffen@sdaoden.eu> <20191220210546.PXaDY%steffen@sdaoden.eu> <20191220214826.tnPk5%steffen@sdaoden.eu> <1651AA0C-3C98-4D85-B6E9-64FD873F34EB@opencsw.org> Message-ID: <20191223172408.JN7hZ%steffen@sdaoden.eu> Hallo Dagobert. Dagobert Michelsen wrote in <1651AA0C-3C98-4D85-B6E9-64FD873F34EB at opencs\ w.org>: |> Am 20.12.2019 um 22:48 schrieb Steffen Nurpmeso : |> Steffen Nurpmeso wrote in <20191220210546.PXaDY%steffen at sdaoden.eu>: |>|Dagobert Michelsen wrote in |w.org>: |>||Am 20.12.2019 um 20:35 schrieb Steffen Nurpmeso : |>||> On unstable11x i see the following error |> ... |>||This usually happens when you try to build 64 bit binaries and link \ |>||to the 32 bit lib. |>| |>|Hmm, we are not specific with -march or so. We just test some |>|standard compiler and linker flags and do it. |>| |>||Please check linker pathes if they append /64 for the correct libs. \ |>||If that doesn?t help |>||please post a reproducible testcase. |> ... |>|Reproducable should thus be to log into my account |>| |>| cd src/nail.git |>| git fetch |>| git co -B next origin/next |>| make devel |> |> Btw., i helped me out via |> |> make devel OPT_USE_PKGSYS=no |> |> which then uses the iconv from the C library and works :) | |What kind of esoteric buildsystem is this? How does this work? Ah, just a shell script with some test snippets. Nothing special. Very specific to the mailer, at least yet. Will become modularized a bit more when i finally come to my roff port, which hopefully happens somewhen next year, at least a bit. But even then, just enough for these two only. |Best would be a simple, reproducible commandline where I can see what \ |happens. |The one you posted ... |contains tempfiles which are not there. I attach the actual snippet as a shell script, it creates a t.c and then tries to compile a t.exe. It fails on unstable11x. Dagobert Michelsen wrote in <1AADC16D-3AF0-45EC-9823-BC5779219B25 at opencs\ w.org>: |> Am 23.12.2019 um 12:10 schrieb Dagobert Michelsen via buildfarm rm at lists.opencsw.org>: |>> Am 20.12.2019 um 22:48 schrieb Steffen Nurpmeso : |>> Steffen Nurpmeso wrote in <20191220210546.PXaDY%steffen at sdaoden.eu>: |>>|Dagobert Michelsen wrote in >||Am 20.12.2019 um 20:35 schrieb Steffen Nurpmeso : ... |>>|A nice Christmas time! | |Dir auch ein frohes Fest! Dankesch?n. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) -------------- next part -------------- A non-text attachment was scrubbed... Name: dago.sh Type: application/x-sh Size: 1482 bytes Desc: not available URL: From steffen at sdaoden.eu Mon Dec 23 23:22:15 2019 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Mon, 23 Dec 2019 23:22:15 +0100 Subject: unstable11x: libiconv broken since a long time In-Reply-To: References: <20191220193529.3dF3-%steffen@sdaoden.eu> <20191220210546.PXaDY%steffen@sdaoden.eu> <20191220214826.tnPk5%steffen@sdaoden.eu> <1651AA0C-3C98-4D85-B6E9-64FD873F34EB@opencsw.org> <20191223172408.JN7hZ%steffen@sdaoden.eu> Message-ID: <20191223222215.jhzm9%steffen@sdaoden.eu> Hallo! Dagobert Michelsen wrote in : |> Am 23.12.2019 um 18:24 schrieb Steffen Nurpmeso : |> I attach the actual snippet as a shell script, it creates a t.c |> and then tries to compile a t.exe. It fails on unstable11x. | |Ah yes, I should have noticed earlier: you are using /usr/ccs/bin/gcc \ |which is |shipped as part of Solaris. That one defaults to -m64. You can use |/opt/csw/bin/gcc instead or use -m32 explicitly. Aha. Hm, ok. Well -m64 looks good to me, except for all the bits which are 0:-) But want to note that i am a happy user of OpenCSW.org for quite some years now, and keeping my little mailer SunOS 5.9-11 compatible ever since, and never having seen this problem until i would say after August this year (once there was the last release), so something must have changed? I do not keep any logs, i cannot say what, actually. Did the order in $PATH change? But yes, i recognize changes on the boxes. For example it seems that the NFS server changed also on SunOS 5.10, as i now see NFS caused test failures which did not happen in August: both of those now create shadow files when creating links, so that the link count is 2 instead of the tested-against 1. Well. "Cheerio, Miss Sophie!" to all Germans from my side, or Tsch?-??, like they possibly say not only in Hamburg. Ciao, ciao to all the rest :-) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From mame at ruby-lang.org Thu Dec 26 00:15:14 2019 From: mame at ruby-lang.org (Yusuke Endoh) Date: Thu, 26 Dec 2019 08:15:14 +0900 Subject: Please fix the clock skew of unstable10x In-Reply-To: References:

Message-ID: Hi Dago and all, I confirm that the CI is back. Thank you very much for very quick action! 2019?12?26?(?) 1:59 Dagobert Michelsen : > Hi Yusuke, > > Am 25.12.2019 um 15:51 schrieb Jan Holzh?ter : > > 10.0.0.19 is offline. Please use ntp1.baltic-online.de. whatever that > resolves to. > > Ah, I remember. This should be fixed now. > @Yusuke: Please check and thanks for letting me know! > > > Best regards > > ? Dago > > >> Am 25.12.2019 um 15:40 schrieb Dagobert Michelsen via buildfarm < > buildfarm at lists.opencsw.org>: > >> > >> ?Hi Yusuke, > >> > >>> Am 25.12.2019 um 14:57 schrieb Yusuke Endoh : > >>> Looks like the clock of unstable10x has been behind one hour since > 21st. > >>> This skew makes our AWS S3 upload script fail due to > "Aws::S3::Errors::RequestTimeTooSkewed" error. > >>> > >>> Could you confirm the clock please? > >> > >> I can confirm that it is wrong :-/ > >> > >> unstable10x is connected to ncsw (192.168.1.1) which is connected to > 10.0.0.19 > >> @Jan, Rolf: have you been working on our NTP server or is this an > artifact of the VMWare farm migration? > >> > >> > >> Best regards > >> > >> ? Dago > >> > >> > >> -- > >> "You don't become great by trying to be great, you become great by > wanting to do something, > >> and then doing it so hard that you become great in the process." - xkcd > #896 > >> > > > > -- > "You don't become great by trying to be great, you become great by wanting > to do something, > and then doing it so hard that you become great in the process." - xkcd > #896 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: