From baggins at pld-linux.org  Mon Oct  7 09:16:55 2019
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Mon, 7 Oct 2019 09:16:55 +0200
Subject: Please always rebuild your updates
Message-ID: <20191007071655.GB1868@starbug>

Hi,

There is growing number of packages that have been updated in GIT, but
not built. This is causing unneccessary work when something needs
to be rebuilt due to broken deps (current case icu -> rebuld -> surprise
boost update -> more rebuilding).

Please take a look at http://ep09.pld-linux.org/~pldth/freshness.txt and
please, if you update a package, always send it to builders and be
prepared to deal with broken deps - http://ep09.pld-linux.org/~pldth/main-ready-test.txt

-- 
Jan R?korajski                    | PLD/Linux
SysAdm | baggins<at>pld-linux.org | http://www.pld-linux.org/


From adamg at pld-linux.org  Mon Oct  7 13:17:46 2019
From: adamg at pld-linux.org (Adam Golebiowski)
Date: Mon, 7 Oct 2019 13:17:46 +0200
Subject: Please always rebuild your updates
In-Reply-To: <20191007071655.GB1868@starbug>
References: <20191007071655.GB1868@starbug>
Message-ID: <20191007111746.GA14888@adamg.eu>

On Mon, Oct 07, 2019 at 09:16:55AM +0200, Jan R?korajski wrote:
> Hi,
> 
> There is growing number of packages that have been updated in GIT, but
> not built. This is causing unneccessary work when something needs
> to be rebuilt due to broken deps (current case icu -> rebuld -> surprise
> boost update -> more rebuilding).

I'll be going through boost/icu rebuild this week.



From qboosh at pld-linux.org  Wed Oct  9 21:52:47 2019
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Wed, 9 Oct 2019 21:52:47 +0200
Subject: multilib on carme-x32
Message-ID: <20191009195247.GA15557@mail>

Can we have some multilib packages on carme-x32?
At least glibc.x86_64 for now.

I'd like to try to build rust std library there (there is no hosted
rustc or cargo on this arch, so x86_64 ones must be used).


-- 
Jakub Bogusz    http://qboosh.pl/


From arekm at maven.pl  Thu Oct 10 11:34:03 2019
From: arekm at maven.pl (=?UTF-8?Q?Arkadiusz_Mi=c5=9bkiewicz?=)
Date: Thu, 10 Oct 2019 11:34:03 +0200
Subject: [packages/systemd] rel 1
In-Reply-To: <bd481f0d104c5f88c417cb539c0ab281b925873f_refs_heads_master@pld-linux.org>
References: <5232d91932ae520cffefe7aff890890dfbfec88d_refs_heads_master@pld-linux.org>
 <bd481f0d104c5f88c417cb539c0ab281b925873f_refs_heads_master@pld-linux.org>
Message-ID: <2052cb16-951c-f17e-b5b5-06a46e3f592d@maven.pl>

On 09/10/2019 23:28, atler wrote:
> commit bd481f0d104c5f88c417cb539c0ab281b925873f
> Author: Jan Palus <atler at pld-linux.org>
> Date:   Wed Oct 9 23:24:40 2019 +0200
> 
>     rel 1
> 
>  systemd.spec | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

What about

systemctl preset-all

Should we call it in %post like docs say?

-- 
Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org )


From glen at pld-linux.org  Thu Oct 10 12:57:06 2019
From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Thu, 10 Oct 2019 13:57:06 +0300
Subject: carme-x86_64 readline broken?
In-Reply-To: <a1d5db8c-38a8-4e8a-74f2-50e824f9d75c@delfi.ee>
References: <d11256f7-303c-b02e-deee-ca725cd097b1@delfi.ee>
 <74889197-9327-1a1d-ad0a-9582df70fb3f@maven.pl>
 <a1d5db8c-38a8-4e8a-74f2-50e824f9d75c@delfi.ee>
Message-ID: <3a23e5c2-7f1a-1a55-efc7-de2e6f4b0015@delfi.ee>

On 21/06/2019 13:34, Elan Ruusam?e wrote:

> could this be resolved please
this is still exactly the same, please fix or re-install carme.


From gotar at polanet.pl  Fri Oct 11 08:10:06 2019
From: gotar at polanet.pl (Tomasz Pala)
Date: Fri, 11 Oct 2019 08:10:06 +0200
Subject: [packages/systemd] rel 1
In-Reply-To: <2052cb16-951c-f17e-b5b5-06a46e3f592d@maven.pl>
References: <5232d91932ae520cffefe7aff890890dfbfec88d_refs_heads_master@pld-linux.org>
 <bd481f0d104c5f88c417cb539c0ab281b925873f_refs_heads_master@pld-linux.org>
 <2052cb16-951c-f17e-b5b5-06a46e3f592d@maven.pl>
Message-ID: <20191011061006.GA14129@polanet.pl>

On Thu, Oct 10, 2019 at 11:34:03 +0200, Arkadiusz Mi?kiewicz wrote:

> What about
> 
> systemctl preset-all
> 
> Should we call it in %post like docs say?

I think it's too risky since we don't have enough real-life testing.

-- 
Tomasz Pala <gotar at pld-linux.org>


From arekm at maven.pl  Fri Oct 11 09:11:27 2019
From: arekm at maven.pl (=?UTF-8?Q?Arkadiusz_Mi=c5=9bkiewicz?=)
Date: Fri, 11 Oct 2019 09:11:27 +0200
Subject: [packages/systemd] rel 1
In-Reply-To: <20191011061006.GA14129@polanet.pl>
References: <5232d91932ae520cffefe7aff890890dfbfec88d_refs_heads_master@pld-linux.org>
 <bd481f0d104c5f88c417cb539c0ab281b925873f_refs_heads_master@pld-linux.org>
 <2052cb16-951c-f17e-b5b5-06a46e3f592d@maven.pl>
 <20191011061006.GA14129@polanet.pl>
Message-ID: <57b489bb-88c9-3677-37b0-31f795ad03dc@maven.pl>

On 11/10/2019 08:10, Tomasz Pala wrote:
> On Thu, Oct 10, 2019 at 11:34:03 +0200, Arkadiusz Mi?kiewicz wrote:
> 
>> What about
>>
>> systemctl preset-all
>>
>> Should we call it in %post like docs say?
> 
> I think it's too risky since we don't have enough real-life testing.
> 

So right now we end up with services that are not enabled with this
version of systemd that were enabled with earlier version (like getty
for tty1 etc).

If not call it on upgrade then at least on initial install.

-- 
Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org )


From gotar at polanet.pl  Fri Oct 11 11:53:31 2019
From: gotar at polanet.pl (Tomasz Pala)
Date: Fri, 11 Oct 2019 11:53:31 +0200
Subject: [packages/systemd] rel 1
In-Reply-To: <57b489bb-88c9-3677-37b0-31f795ad03dc@maven.pl>
References: <5232d91932ae520cffefe7aff890890dfbfec88d_refs_heads_master@pld-linux.org>
 <bd481f0d104c5f88c417cb539c0ab281b925873f_refs_heads_master@pld-linux.org>
 <2052cb16-951c-f17e-b5b5-06a46e3f592d@maven.pl>
 <20191011061006.GA14129@polanet.pl>
 <57b489bb-88c9-3677-37b0-31f795ad03dc@maven.pl>
Message-ID: <20191011095331.GA31060@polanet.pl>

On Fri, Oct 11, 2019 at 09:11:27 +0200, Arkadiusz Mi?kiewicz wrote:

>>> systemctl preset-all
>>>
>>> Should we call it in %post like docs say?

BTW which docs?

>> I think it's too risky since we don't have enough real-life testing.
> 
> So right now we end up with services that are not enabled with this
> version of systemd that were enabled with earlier version (like getty
> for tty1 etc).

Where were they being enabled? I'm not following this package recently,
and can't find any changes in %post*.

> If not call it on upgrade then at least on initial install.

Install should call preset indeed - this operation requires attention anyway.

I remember fixing something around presets:
http://git.pld-linux.org/gitweb.cgi?p=packages/rpm-build-macros.git;a=commitdiff;h=3303369cd82fe4c2d6297d60fec3272066a322c5
(fixed later in aa13c88c1160df49c87ad3d9586c0bc0b4b3bc5d)


...and I wonder if we could call on upgrade:

systemctl preset-all --preset-mode=enable-only

but personally I wouldn't be happy if upgrade enabled services I've
previously disabled[*] - sometimes masking is inappropriate as it prevents
manual service start.


We must also remember about such cases:

http://git.pld-linux.org/gitweb.cgi?p=packages/systemd.git;a=blob;f=systemd.spec;h=67896daaaafd484b51979edb48046d97d86ab5d0;hb=HEAD#l995

- wouldn't this disable everything (not distro-preset"ted" to on) after "preset-all"?

Note the "default.preset" filename, i.e. without priority prefix, would
be applied last (which is correct as the first match wins), but we do
not provide preset files:

$ ipoldek --skip-installed rsearch -f /systemd.\*\.preset$/

systemd-units-241-2.x86_64
zfs-0.8.1-1.x86_64

So I guess this would result in disabled ssh as well (yikes!)


[*] "If no preset files exist, systemctl preset will enable all units that are installed by default"

PS: had no time to add missing directories:
/var/lib/systemd/journal-upload
/var/log/journal/remote

-- 
Tomasz Pala <gotar at pld-linux.org>


From arekm at maven.pl  Fri Oct 11 16:36:00 2019
From: arekm at maven.pl (=?UTF-8?Q?Arkadiusz_Mi=c5=9bkiewicz?=)
Date: Fri, 11 Oct 2019 16:36:00 +0200
Subject: [packages/systemd] rel 1
In-Reply-To: <20191011095331.GA31060@polanet.pl>
References: <5232d91932ae520cffefe7aff890890dfbfec88d_refs_heads_master@pld-linux.org>
 <bd481f0d104c5f88c417cb539c0ab281b925873f_refs_heads_master@pld-linux.org>
 <2052cb16-951c-f17e-b5b5-06a46e3f592d@maven.pl>
 <20191011061006.GA14129@polanet.pl>
 <57b489bb-88c9-3677-37b0-31f795ad03dc@maven.pl>
 <20191011095331.GA31060@polanet.pl>
Message-ID: <373838ef-a11f-1afd-52d1-d44b3b644961@maven.pl>

On 11/10/2019 11:53, Tomasz Pala wrote:
> On Fri, Oct 11, 2019 at 09:11:27 +0200, Arkadiusz Mi?kiewicz wrote:
> 
>>>> systemctl preset-all
>>>>
>>>> Should we call it in %post like docs say?
> 
> BTW which docs?

NEWS:

        * During package installation (with `ninja install`), we would
create
          symlinks for getty at tty1.service, systemd-networkd.service,
          systemd-networkd.socket, systemd-resolved.service,
          remote-cryptsetup.target, remote-fs.target,
          systemd-networkd-wait-online.service, and
systemd-timesyncd.service
          in /etc, as if `systemctl enable` was called for those units,
to make
          the system usable immediately after installation. Now this is not
          done anymore, and instead calling `systemctl preset-all` is
          recommended after the first installation of systemd.

> 
>>> I think it's too risky since we don't have enough real-life testing.
>>
>> So right now we end up with services that are not enabled with this
>> version of systemd that were enabled with earlier version (like getty
>> for tty1 etc).
> 
> Where were they being enabled? I'm not following this package recently,
> and can't find any changes in %post*.

These were enabled by default by just files existence. Now files were
removed (with update to 242; d482e20e65e32e51e9bdfdecb0d1375d9e62c0d1)

> 
>> If not call it on upgrade then at least on initial install.
> 
> Install should call preset indeed - this operation requires attention anyway.
> 
> I remember fixing something around presets:
> http://git.pld-linux.org/gitweb.cgi?p=packages/rpm-build-macros.git;a=commitdiff;h=3303369cd82fe4c2d6297d60fec3272066a322c5
> (fixed later in aa13c88c1160df49c87ad3d9586c0bc0b4b3bc5d)
> 
> 
> ...and I wonder if we could call on upgrade:
> 
> systemctl preset-all --preset-mode=enable-only
> 
> but personally I wouldn't be happy if upgrade enabled services I've
> previously disabled[*] - sometimes masking is inappropriate as it prevents
> manual service start.
> 
> 
> We must also remember about such cases:
> 
> http://git.pld-linux.org/gitweb.cgi?p=packages/systemd.git;a=blob;f=systemd.spec;h=67896daaaafd484b51979edb48046d97d86ab5d0;hb=HEAD#l995
> 
> - wouldn't this disable everything (not distro-preset"ted" to on) after "preset-all"?
> 
> Note the "default.preset" filename, i.e. without priority prefix, would
> be applied last (which is correct as the first match wins), but we do
> not provide preset files:
> 
> $ ipoldek --skip-installed rsearch -f /systemd.\*\.preset$/
> 
> systemd-units-241-2.x86_64
> zfs-0.8.1-1.x86_64
> 
> So I guess this would result in disabled ssh as well (yikes!)
> 
> 
> [*] "If no preset files exist, systemctl preset will enable all units that are installed by default"
> 
> PS: had no time to add missing directories:
> /var/lib/systemd/journal-upload
> /var/log/journal/remote
> 


-- 
Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org )


From qboosh at pld-linux.org  Sat Oct 12 06:58:18 2019
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Sat, 12 Oct 2019 06:58:18 +0200
Subject: [packages/librsvg] - updated dependencies; librsvg since 2.42 is
 partially in rust (what with th-x32?)
In-Reply-To: <20190130200510.GB19467@tachikoma.lan>
References: <775f4438b11ae12c8700fcab3790c5a384605f95_refs_heads_master@pld-linux.org>
 <fc65f7f1cf360e29b7e44b9835dece9805ad9dbc_refs_heads_master@pld-linux.org>
 <20190130194442.GA4682@mail> <20190130200510.GB19467@tachikoma.lan>
Message-ID: <20191012045818.GA11934@stranger.qboosh.pl>

On Wed, Jan 30, 2019 at 09:05:10PM +0100, Jan R?korajski wrote:
> On Wed, 30 Jan 2019, Jakub Bogusz wrote:
> 
> > On Wed, Jan 30, 2019 at 08:20:00PM +0100, qboosh wrote:
> > > commit fc65f7f1cf360e29b7e44b9835dece9805ad9dbc
> > > Author: Jakub Bogusz <qboosh at pld-linux.org>
> > > Date:   Wed Jan 30 20:25:13 2019 +0100
> > > 
> > >     - updated dependencies; librsvg since 2.42 is partially in rust (what with th-x32?)
> > 
> > According to rust project site, code generation and std lib is supported
> > on x32, but there is no rustc hosted on x32 system - I assume that x86_64
> > rustc must be used...
> 
> 1. librsvg-c for x32? https://lwn.net/Articles/771355/
> 2. get rust functional on x32 (I'm fine with x86_64 runtime and x32 stdlib)
> 3. drop x32 possibly? https://lwn.net/Articles/774734/

Followup:

eog 3.34 already (optionally) requires rust-based librsvg >= 2.44), so sticking
to 2.40.x is no longer an option.


-- 
Jakub Bogusz    http://qboosh.pl/


From gotar at polanet.pl  Sat Oct 12 10:05:40 2019
From: gotar at polanet.pl (Tomasz Pala)
Date: Sat, 12 Oct 2019 10:05:40 +0200
Subject: [packages/systemd] rel 1
In-Reply-To: <373838ef-a11f-1afd-52d1-d44b3b644961@maven.pl>
References: <5232d91932ae520cffefe7aff890890dfbfec88d_refs_heads_master@pld-linux.org>
 <bd481f0d104c5f88c417cb539c0ab281b925873f_refs_heads_master@pld-linux.org>
 <2052cb16-951c-f17e-b5b5-06a46e3f592d@maven.pl>
 <20191011061006.GA14129@polanet.pl>
 <57b489bb-88c9-3677-37b0-31f795ad03dc@maven.pl>
 <20191011095331.GA31060@polanet.pl>
 <373838ef-a11f-1afd-52d1-d44b3b644961@maven.pl>
Message-ID: <20191012080540.GA30316@polanet.pl>

On Fri, Oct 11, 2019 at 16:36:00 +0200, Arkadiusz Mi?kiewicz wrote:

>>>>> systemctl preset-all
>>>>>
>>>>> Should we call it in %post like docs say?
>> 
>> BTW which docs?
> 
> NEWS:
> 
>         * During package installation (with `ninja install`), we would create
[...]
>           done anymore, and instead calling `systemctl preset-all` is
>           recommended after the first installation of systemd.

So this is indeed purely for making system usable after initial install.

We might consider this in %post install, however the base units are/were
enabled directly in systemd.rpm package (i.e. results of this preset-all
are/were already packaged).

The open question would be: how should systemd install behave when done
on system with other packages (like daemons) already installed (e.g. during
migration from SysV)? But the answer is ...irrelevant, since we don't
provide any fine-grained preset files, so after such transition admin is
free to call preset-all by himself after setting the default policy.

>>> So right now we end up with services that are not enabled with this
>>> version of systemd that were enabled with earlier version (like getty
>>> for tty1 etc).
>> 
> These were enabled by default by just files existence. Now files were
> removed (with update to 242; d482e20e65e32e51e9bdfdecb0d1375d9e62c0d1)

Oh, this complicates things a bit...

As we shouldn't (IMHO) call preset-all ...ever(!), and these files
were packaged and put into running systems, they should be simply brought back now.

Otherwise we risk breaking running systems, I can't see any other simply way.

-- 
Tomasz Pala <gotar at pld-linux.org>


From baggins at pld-linux.org  Sat Oct 12 13:36:05 2019
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Sat, 12 Oct 2019 13:36:05 +0200
Subject: multilib on carme-x32
In-Reply-To: <20191009195247.GA15557@mail>
References: <20191009195247.GA15557@mail>
Message-ID: <20191012113605.GD1868@starbug>

On Wed, 09 Oct 2019, Jakub Bogusz wrote:

> Can we have some multilib packages on carme-x32?
> At least glibc.x86_64 for now.
> 
> I'd like to try to build rust std library there (there is no hosted
> rustc or cargo on this arch, so x86_64 ones must be used).

Installed gcc-multilib and glibc-devel.

-- 
Jan R?korajski                    | PLD/Linux
SysAdm | baggins<at>pld-linux.org | http://www.pld-linux.org/


From glen at delfi.ee  Thu Oct 17 17:18:52 2019
From: glen at delfi.ee (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Thu, 17 Oct 2019 18:18:52 +0300
Subject: [packages/sudo] - up to 1.8.28
In-Reply-To: <89b19f0a628b14fd900f10b9a70868a4feba74a5_refs_heads_master@pld-linux.org>
References: <286a79cf91fbb95e3ad5e10737cfb423f2a5a1ca_refs_heads_master@pld-linux.org>
 <89b19f0a628b14fd900f10b9a70868a4feba74a5_refs_heads_master@pld-linux.org>
Message-ID: <167258a7-49fc-f492-f321-d76783f36d0e@delfi.ee>


On 16/10/2019 14:24, arekm wrote:
> commit 89b19f0a628b14fd900f10b9a70868a4feba74a5
> Author: Arkadiusz Mi?kiewicz <arekm at maven.pl>
> Date:   Wed Oct 16 13:24:09 2019 +0200
>
>      - up to 1.8.28
>      
>       * Fixed CVE-2019-14287, a bug where a sudo user may be able to
>         run a command as root when the Runas specification explicitly
>         disallows root access as long as the ALL keyword is listed first.


can we get carme-ac up?


Changing title to carme-ac
ssh: connect to host carme-ac.pld-linux.org port 22: Network is unreachable
=== Command terminated with exit status 255 (Thu Oct 17 18:17:57 2019) ===





From arekm at maven.pl  Thu Oct 17 17:59:40 2019
From: arekm at maven.pl (=?UTF-8?Q?Arkadiusz_Mi=c5=9bkiewicz?=)
Date: Thu, 17 Oct 2019 17:59:40 +0200
Subject: [packages/sudo] - up to 1.8.28
In-Reply-To: <167258a7-49fc-f492-f321-d76783f36d0e@delfi.ee>
References: <286a79cf91fbb95e3ad5e10737cfb423f2a5a1ca_refs_heads_master@pld-linux.org>
 <89b19f0a628b14fd900f10b9a70868a4feba74a5_refs_heads_master@pld-linux.org>
 <167258a7-49fc-f492-f321-d76783f36d0e@delfi.ee>
Message-ID: <6eb9580e-9fea-f9c4-c058-6d1651b77b81@maven.pl>

On 17/10/2019 17:18, Elan Ruusam?e wrote:
> 
> On 16/10/2019 14:24, arekm wrote:
>> commit 89b19f0a628b14fd900f10b9a70868a4feba74a5
>> Author: Arkadiusz Mi?kiewicz <arekm at maven.pl>
>> Date:?? Wed Oct 16 13:24:09 2019 +0200
>>
>> ???? - up to 1.8.28
>> ???? ????? * Fixed CVE-2019-14287, a bug where a sudo user may be able to
>> ??????? run a command as root when the Runas specification explicitly
>> ??????? disallows root access as long as the ALL keyword is listed first.
> 
> 
> can we get carme-ac up?
> 
> 
> Changing title to carme-ac
> ssh: connect to host carme-ac.pld-linux.org port 22: Network is unreachable
> === Command terminated with exit status 255 (Thu Oct 17 18:17:57 2019) ===

Should be up now (until next carme reboot).


-- 
Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org )


From baggins at pld-linux.org  Fri Oct 25 00:45:36 2019
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Fri, 25 Oct 2019 00:45:36 +0200
Subject: [packages/librsvg] - updated dependencies; librsvg since 2.42 is
 partially in rust (what with th-x32?)
In-Reply-To: <20191012045818.GA11934@stranger.qboosh.pl>
References: <775f4438b11ae12c8700fcab3790c5a384605f95_refs_heads_master@pld-linux.org>
 <fc65f7f1cf360e29b7e44b9835dece9805ad9dbc_refs_heads_master@pld-linux.org>
 <20190130194442.GA4682@mail> <20190130200510.GB19467@tachikoma.lan>
 <20191012045818.GA11934@stranger.qboosh.pl>
Message-ID: <20191024224536.GA61201@tachikoma.lan>

On Sat, 12 Oct 2019, Jakub Bogusz wrote:

> On Wed, Jan 30, 2019 at 09:05:10PM +0100, Jan R?korajski wrote:
> > On Wed, 30 Jan 2019, Jakub Bogusz wrote:
> > 
> > > On Wed, Jan 30, 2019 at 08:20:00PM +0100, qboosh wrote:
> > > > commit fc65f7f1cf360e29b7e44b9835dece9805ad9dbc
> > > > Author: Jakub Bogusz <qboosh at pld-linux.org>
> > > > Date:   Wed Jan 30 20:25:13 2019 +0100
> > > > 
> > > >     - updated dependencies; librsvg since 2.42 is partially in rust (what with th-x32?)
> > > 
> > > According to rust project site, code generation and std lib is supported
> > > on x32, but there is no rustc hosted on x32 system - I assume that x86_64
> > > rustc must be used...
> > 
> > 1. librsvg-c for x32? https://lwn.net/Articles/771355/
> > 2. get rust functional on x32 (I'm fine with x86_64 runtime and x32 stdlib)
> > 3. drop x32 possibly? https://lwn.net/Articles/774734/
> 
> Followup:
> 
> eog 3.34 already (optionally) requires rust-based librsvg >= 2.44), so sticking
> to 2.40.x is no longer an option.

This strict version dependency is bullshit. As expected. You are welcome.

-- 
Jan R?korajski                    | PLD/Linux
SysAdm | baggins<at>pld-linux.org | http://www.pld-linux.org/


From qboosh at pld-linux.org  Sat Oct 26 14:32:45 2019
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Sat, 26 Oct 2019 14:32:45 +0200
Subject: th-x32 builder stuck or dead?
Message-ID: <20191026123245.GA24880@mail>

What happened to th-x32 builder?
It either got stuck building python3-typed_ast-1.4.0-2 or died...
carme-x32 builds python3-typed_ast-1.4.0-2 without problems.


-- 
Jakub Bogusz    http://qboosh.pl/


From arekm at maven.pl  Sat Oct 26 15:48:39 2019
From: arekm at maven.pl (=?UTF-8?Q?Arkadiusz_Mi=c5=9bkiewicz?=)
Date: Sat, 26 Oct 2019 15:48:39 +0200
Subject: th-x32 builder stuck or dead?
In-Reply-To: <20191026123245.GA24880@mail>
References: <20191026123245.GA24880@mail>
Message-ID: <ed2c751c-f00c-f000-3b66-01f100125bf1@maven.pl>

On 26/10/2019 14:32, Jakub Bogusz wrote:
> What happened to th-x32 builder?
> It either got stuck building python3-typed_ast-1.4.0-2 or died...
> carme-x32 builds python3-typed_ast-1.4.0-2 without problems.


restarted, tons of cron/python processes... syslog-ng again? hmm


-- 
Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org )


From qboosh at pld-linux.org  Sat Oct 26 20:24:12 2019
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Sat, 26 Oct 2019 20:24:12 +0200
Subject: DNS problems on builders [Fwd: [all] builder queue problem]
Message-ID: <20191026182412.GA27439@mail>

It seems that builders (at least src builder) experiences some problems
with resolving hosts in PLD domain...

One example below.
But also some build requests fail on resolving distfiles to build src.rpm.


----- Forwarded message from PLD all builder <draenog at pld-linux.org> -----

From: PLD all builder <draenog at pld-linux.org>
X-PLD-Builder: all
To: qboosh at pld-linux.org, draenog at pld-linux.org
Date: Sat, 26 Oct 2019 18:13:28 +0000
Subject: [all] builder queue problem

there were problems sending files from queue /home/pld/builderth/pld-builder.new/spool/buildlogs:
problems:
[src: /home/pld/builderth/pld-builder.new/spool/buildlogs/th-src.4a568948-241c-4d51-bbde-e994c7e0187c.liblouisutdml.spec.log]

rsync: getaddrinfo: buildlogs.pld-linux.org 873: No address associated with hostname
rsync error: error in socket IO (code 10) at clientserver.c(125) [sender=3.1.2]


----- End forwarded message -----

-- 
Jakub Bogusz    http://qboosh.pl/