I asked to greedy remove itk.
It removed itk-devel by dependency, as it should, but why it removed
itcl-devel too???
On Thu, Jan 16, 2020 at 04:45:38PM +, PLD th-i686 builder wrote:
> COMMAND (): OK
>
> --- COMMAND::
> Build-Time: user:0.70s sys:0.21s real:1.16s (faults io:0 non-io:62263)
>
On Sat, Jan 11, 2020 at 10:00:30PM +0100, arekm wrote:
> commit 48dac5e93206c31066f91484526df2e4c2c29480
> Author: Arkadiusz Miśkiewicz
> Date: Sat Jan 11 22:00:22 2020 +0100
>
> - up to 1.7.0
>
> apr.spec | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
> ---
> diff --git
On 1/7/20 6:58 PM, Arkadiusz Miśkiewicz via pld-devel-en wrote:
To goal is not to diverge from upstream.
upstream reverted the change:
- https://github.com/shadow-maint/shadow/pull/197
___
pld-devel-en mailing list
On Tue, Jan 07, 2020 at 05:58:46PM +0100, Arkadiusz Miśkiewicz via pld-devel-en
wrote:
> On 07/01/2020 17:06, Jakub Bogusz wrote:
> > On Tue, Jan 07, 2020 at 01:36:44PM +0100, arekm wrote:
> >> commit 2bb4da0ffecbbc08e6e25336b3e1e012b7cd61a5
> >> Author: Arkadiusz Miśkiewicz
> >> Date: Tue Jan
On 07/01/2020 17:06, Jakub Bogusz wrote:
> On Tue, Jan 07, 2020 at 01:36:44PM +0100, arekm wrote:
>> commit 2bb4da0ffecbbc08e6e25336b3e1e012b7cd61a5
>> Author: Arkadiusz Miśkiewicz
>> Date: Tue Jan 7 13:36:34 2020 +0100
>>
>> - shadow puts everything into /bin and /sbin - that's ok but
On Tue, Jan 07, 2020 at 01:36:44PM +0100, arekm wrote:
> commit 2bb4da0ffecbbc08e6e25336b3e1e012b7cd61a5
> Author: Arkadiusz Miśkiewicz
> Date: Tue Jan 7 13:36:34 2020 +0100
>
> - shadow puts everything into /bin and /sbin - that's ok but provide
> symlinks for old (pwdutils) locations
On 19.12.2019 21:27, qboosh wrote:
- restored gcc 6.5.0, the last version with Java support
why not just branch off that repo from the 6.5.0 commit?
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
On Thu, Dec 19, 2019 at 02:44:35PM +0200, Elan Ruusamäe wrote:
> if built package requires newer symbols
...it can just tell so; see set-versions in ALT RPM
(jbj@ knows about that patch, just in case).
But it's no smaller feat than gradually changing
the whole versioning scheme in a repository
On 12/18/19 4:48 PM, Jan Rękorajski wrote:
On Wed, 18 Dec 2019, Elan Ruusamäe wrote:
On 12/18/19 4:12 PM, Jan Rękorajski wrote:
On Wed, 18 Dec 2019, Elan Ruusamäe wrote:
```
15:57:37 root[load: 0.35]@predator ~# fontpostinst TTF
/usr/bin/fc-cache: symbol lookup error:
On Wed, 18 Dec 2019, Elan Ruusamäe wrote:
>
> On 12/18/19 4:12 PM, Jan Rękorajski wrote:
> > On Wed, 18 Dec 2019, Elan Ruusamäe wrote:
> >
> >> ```
> >> 15:57:37 root[load: 0.35]@predator ~# fontpostinst TTF
> >> /usr/bin/fc-cache: symbol lookup error: /usr/lib64/libfontconfig.so.1:
> >>
On 12/18/19 4:12 PM, Jan Rękorajski wrote:
On Wed, 18 Dec 2019, Elan Ruusamäe wrote:
```
15:57:37 root[load: 0.35]@predator ~# fontpostinst TTF
/usr/bin/fc-cache: symbol lookup error: /usr/lib64/libfontconfig.so.1:
undefined symbol: FT_Done_MM_Var
15:57:40 root[load: 0.35]@predator ~#
On Wed, 18 Dec 2019, Elan Ruusamäe wrote:
> ```
> 15:57:37 root[load: 0.35]@predator ~# fontpostinst TTF
> /usr/bin/fc-cache: symbol lookup error: /usr/lib64/libfontconfig.so.1:
> undefined symbol: FT_Done_MM_Var
>
> 15:57:40 root[load: 0.35]@predator ~# pkgbytime fontc
> Thu Jul 5 16:20:39
On 02.12.2019 21:36, qboosh wrote:
commit dab1d12108ed9cf26d3607c30f4b8878e65d2382
Author: Jakub Bogusz
Date: Mon Dec 2 20:37:28 2019 +0100
- (re)added info patch (unify direntry)
can you please submit these upstream? why is pld maintaining these over
decades
On 04.12.2019 21:50, Jakub Bogusz wrote:
Is it intentional?
$ cvs ci ... uid_gid.db.txt
cvs commit: cannot exec /cvsroot/CVSROOT/acl.pl: Permission denied
cvs commit: Pre-commit check failed
cvs [commit aborted]: correct above errors first!
unknown. fixed
```
root@1822-cvs
On 22/11/2019 17:42, Arkadiusz Miśkiewicz wrote:
> On 22/11/2019 16:04, Elan Ruusamäe wrote:
>>
>> On 11/20/19 12:30 PM, Arkadiusz Miśkiewicz wrote:
>>> On 20/11/2019 07:46, Elan Ruusamäe wrote:
On 20.11.2019 01:06, Elan Ruusamäe wrote:
occupied by Refs.git. I never understood that
On 22/11/2019 16:04, Elan Ruusamäe wrote:
>
> On 11/20/19 12:30 PM, Arkadiusz Miśkiewicz wrote:
>> On 20/11/2019 07:46, Elan Ruusamäe wrote:
>>> On 20.11.2019 01:06, Elan Ruusamäe wrote:
>>>
>>> occupied by Refs.git. I never understood that repo purpose...
>>>
>>> whatever the slug_watch-cron is
On 11/20/19 12:30 PM, Arkadiusz Miśkiewicz wrote:
On 20/11/2019 07:46, Elan Ruusamäe wrote:
On 20.11.2019 01:06, Elan Ruusamäe wrote:
occupied by Refs.git. I never understood that repo purpose...
whatever the slug_watch-cron is doing, it's hitting at */15 and creating
another ~500mb failed
On 20/11/2019 07:46, Elan Ruusamäe wrote:
> On 20.11.2019 01:06, Elan Ruusamäe wrote:
>
> occupied by Refs.git. I never understood that repo purpose...
>
> whatever the slug_watch-cron is doing, it's hitting at */15 and creating
> another ~500mb failed pack.
It runs "git gc" and leaves that
On 20.11.2019 01:06, Elan Ruusamäe wrote:
occupied by Refs.git. I never understood that repo purpose...
whatever the slug_watch-cron is doing, it's hitting at */15 and creating
another ~500mb failed pack.
disabling that cron for now. one more run and disk is full again.
```
root@1822-cvs
On 19.11.2019 10:40, Arkadiusz Miśkiewicz wrote:
Yes, added 10GB, another 10GB free left to be assigned.
And it's gone.
21G /cvs/root/gitolite/
gitolite ate that new 10GB.
glen, could you look?
occupied by Refs.git. I never understood that repo purpose...
```
root@1822-cvs
On 18/11/2019 20:32, Arkadiusz Miśkiewicz wrote:
> On 18/11/2019 20:19, Jakub Bogusz wrote:
>> $ git push
>> Enter passphrase for key '/home/comp/.ssh/id_rsa':
>> Enumerating objects: 5, done.
>> Counting objects: 100% (5/5), done.
>> Delta compression using up to 4 threads
>> Compressing objects:
On 18/11/2019 20:19, Jakub Bogusz wrote:
> $ git push
> Enter passphrase for key '/home/comp/.ssh/id_rsa':
> Enumerating objects: 5, done.
> Counting objects: 100% (5/5), done.
> Delta compression using up to 4 threads
> Compressing objects: 100% (3/3), done.
> Writing objects: 100% (3/3), 906
On 04/11/2019 22:42, Elan Ruusamäe wrote:
> wth?
>
>
> ```
>
> Nov 4 23:37:43 glen sshd[17003]: fatal: privsep_preauth: preauth child
> terminated by signal 31
>
> ```
>
> if this is (was) known issue these should be posted to devel list so
> people don't get locked out of their systems.
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
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
On 17/10/2019 17:18, Elan Ruusamäe wrote:
>
> On 16/10/2019 14:24, arekm wrote:
>> commit 89b19f0a628b14fd900f10b9a70868a4feba74a5
>> Author: Arkadiusz Miśkiewicz
>> 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
On 16/10/2019 14:24, arekm wrote:
commit 89b19f0a628b14fd900f10b9a70868a4feba74a5
Author: Arkadiusz Miśkiewicz
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
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
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,
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
> > > Date: Wed Jan 30 20:25:13 2019 +0100
>
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
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
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
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
___
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.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld
On 09/10/2019 23:28, atler wrote:
> commit bd481f0d104c5f88c417cb539c0ab281b925873f
> Author: Jan Palus
> 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
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
On 19/09/2019 18:56, Jakub Bogusz wrote:
> On Sun, Sep 01, 2019 at 06:34:38PM +0200, Arkadiusz Miśkiewicz wrote:
>> On 01/09/2019 17:22, Jakub Bogusz wrote:
>>> On Thu, Aug 29, 2019 at 12:50:26PM +0200, Arkadiusz Miśkiewicz wrote:
On 28/08/2019 20:56, Jakub Bogusz wrote:
> Downloading
On Sun, Sep 01, 2019 at 06:34:38PM +0200, Arkadiusz Miśkiewicz wrote:
> On 01/09/2019 17:22, Jakub Bogusz wrote:
> > On Thu, Aug 29, 2019 at 12:50:26PM +0200, Arkadiusz Miśkiewicz wrote:
> >> On 28/08/2019 20:56, Jakub Bogusz wrote:
> >>> Downloading works, but uploading doesn't:
> >>>
> >>> -
On 04.09.2019 08:01, Arkadiusz Miśkiewicz wrote:
> On 03/09/2019 23:13, atler wrote:
> > commit d43959e98fc5590888c9a43d2345178c34e4f2c4
> > Author: Jan Palus
> > Date: Tue Sep 3 23:08:49 2019 +0200
> >
> > continue using hybrid cgroup hierarchy
> >
> > ...for docker
On 03/09/2019 23:13, atler wrote:
> commit d43959e98fc5590888c9a43d2345178c34e4f2c4
> Author: Jan Palus
> Date: Tue Sep 3 23:08:49 2019 +0200
>
> continue using hybrid cgroup hierarchy
>
> ...for docker compatibility. upstream switched default to unified
> hierarchy exposing
On 01/09/2019 17:22, Jakub Bogusz wrote:
> On Thu, Aug 29, 2019 at 12:50:26PM +0200, Arkadiusz Miśkiewicz wrote:
>> On 28/08/2019 20:56, Jakub Bogusz wrote:
>>> Downloading works, but uploading doesn't:
>>>
>>> - Forwarded message from distfi...@distfiles.pld-linux.org -
>>>
>>> From:
>>>
On 28/08/2019 20:56, Jakub Bogusz wrote:
> Downloading works, but uploading doesn't:
>
> - Forwarded message from distfi...@distfiles.pld-linux.org -
>
> From:
> To: qbo...@pld-linux.org
> Subject: DISTFILES: glpk: ERRORS: glpk-4.65.tar.gz
> X-distfiles-program: file-fetcher.pl
> Date:
On 28/08/2019 22:22, hawk wrote:
commit e356d518636cfc5a412f3e9a5ad163badc267374
Author: Marcin Krol
Date: Wed Aug 28 21:20:09 2019 +0200
- dropped cfg_to_dot (its from examples subdir)
- dropped unstrip and its non-binary *.db files
you should (also) rm them in %install
On Tue, Aug 27, 2019 at 5:55 AM Jakub Bogusz wrote:
> FHS package is too old on th-i686 (missing "ta" man dir), but it cannot
> be simply upgraded.
> Could sb do it manually (possibly adding /proc to netsharedpath or so)?
>
Done.
--
Jan Rękorajski | SysAdm | PLD/Linux |
On 8/6/19 12:59 PM, Adam Gołębiowski wrote:
Looks like we hit -ENOSPC on ftp.
th-test indexes (still?) broken
```
poldek:/all-avail> !poldek --up -n th-test
Retrieving th-test::packages.ndir.md...
Retrieving th-test::packages.ndir.gz...
.. 100.0% [248.1K
Looks like we hit -ENOSPC on ftp.
There's some extra space added now, not sure if pending packages will be synced
from builders or will need to be pushed manually .
- Original Message -
From: "Jan Palus"
To: pld-devel-en@lists.pld-linux.org
Sent: wtorek, 6 sierpień 2019 0:37:29
On 03/08/2019 21:26, Jakub Bogusz wrote:
> ???
>
> Build failed on tests, but builder says, that only upgrade failed...
>
> And what are "foo" RPMs it tried to install?
> python3.spec produces different packages.
python 3 test suite builds foo*.rpm packages and our pld-builder
automatic gets
???
Build failed on tests, but builder says, that only upgrade failed...
And what are "foo" RPMs it tried to install?
python3.spec produces different packages.
On Sat, Aug 03, 2019 at 06:14:49PM +, PLD th-x86_64 builder wrote:
> python3.spec (auto/th/python3-3.7.4-2): FAILED
>
> ---
On 25.07.2019 19:57, PLD th-i686 builder wrote:
> -DQT_NO_DEBUG -Wl,--no-undefined -Wl,--fatal-warnings
...
> /usr/bin/ld: warning: /lib/ld-linux.so.2: corrupt GNU_PROPERTY_TYPE (5) size: > 0
> collect2: error: ld returned 1 exit status
any idea why /lib/ld-linux.so.2 appears to be broken on
On 5/6/19 7:06 PM, Jan Rękorajski wrote:
On Sun, 05 May 2019, Elan Ruusamäe wrote:
the ftp is still unusable for poldek after exactly two months have passed.
please make default poldek config to use http:// (or https://) if unable
to support ftp://
Fix your /etc/resolv.conf and
Happened again:
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 4 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 316 bytes | 316.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0)
remote: fatal: write failure on
On 20/06/2019 00:27, Arkadiusz Miśkiewicz wrote:
On 19/06/2019 22:48, Elan Ruusamäe wrote:
seems all operations that require some kind of interactivity are broken
on carme.
random examples:
1. coreutils prompts fail to prompt with bogus error closing file message
carme has git version of
On 19/06/2019 22:48, Elan Ruusamäe wrote:
> seems all operations that require some kind of interactivity are broken
> on carme.
>
>
> random examples:
>
> 1. coreutils prompts fail to prompt with bogus error closing file message
carme has git version of readline-devel, so there can be mixed
On 19/06/2019 10:22, qboosh wrote:
commit f81d24890fc099cfa33b9951c6d77b0a6fb14c23
Author: Jakub Bogusz
Date: Wed Jun 19 09:23:47 2019 +0200
- updated info patch
(its purpose is to align info directory, ie. default info/pinfo page)
not that i care of this patch, but this
On 03/06/2019 20:58, Jan Rękorajski wrote:
> On Mon, 03 Jun 2019, arekm wrote:
>
>> commit 28dc894f0a27bdc080bbfc821d2841760a70927b
>> Author: Arkadiusz Miśkiewicz
>> Date: Mon Jun 3 15:09:13 2019 +0200
>>
>> - bump libicu-devel to 63.1; builds fine with nodejs 10 even with no
>> read
On Mon, 03 Jun 2019, arekm wrote:
> commit 28dc894f0a27bdc080bbfc821d2841760a70927b
> Author: Arkadiusz Miśkiewicz
> Date: Mon Jun 3 15:09:13 2019 +0200
>
> - bump libicu-devel to 63.1; builds fine with nodejs 10 even with no read
> access to resolv.conf
>
> firefox.spec | 2 +-
> 1
On Mon, Jun 03, 2019 at 08:19:42AM +0200, Jacek Konieczny wrote:
> On 03/06/2019 07.25, Jan Rękorajski wrote>
> > I don't believe it's nodejs problem, I think it's builder
> > security/networking problem.
> But the security/networking restrictions are there for a reason. If we
> allow build
That nodejs in firefox is not downloading anything AFAIK, it's just
convoluted build process that needs nodejs started and it cannot start
without dns :/
I don't remember how we run builds, but maybe if we point resolv.conf at
127.0.0.1 it will be enough for it.
On Mon, Jun 3, 2019 at 8:19 AM
On 03/06/2019 07.25, Jan Rękorajski wrote>
> I don't believe it's nodejs problem, I think it's builder
> security/networking problem.
But the security/networking restrictions are there for a reason. If we
allow build process to download anything it wants, then we could skip
shipping source
On Sun, 02 Jun 2019, Elan Ruusamäe wrote:
> On 02/06/2019 23:13, Jan Rękorajski wrote:
>
> > After long trial and error process I managed to get firefox to build,
> > unfortunately our automation is overprotective and the build doesn't
> > work on builders - I can run it manually on builders,
On 02/06/2019 23:13, Jan Rękorajski wrote:
After long trial and error process I managed to get firefox to build,
unfortunately our automation is overprotective and the build doesn't
work on builders - I can run it manually on builders, but not in
automatated way.
Until someone finds out why
nuked pldnotify tmp files:
```
root@1822-cvs ~# df
Filesystem Type Size Used Avail Use% Mounted on
/dev/sda3 ext3 16G 14G 686M 96% /
root@1822-cvs /tmp# l
total 1022M
-rw--- 1 arekm cvsadm 8.2M Jun 2 00:37 3sUCfg
-rw--- 1 arekm cvsadm 8.2M May 22
On 31/05/2019 12:28, Arkadiusz Miśkiewicz wrote:
Deleted few things - now it's 1.4GB free.
and already down by 700mb. something is continuing to eat space
```
root@1822-cvs repositories/SPECS.git# df /
Filesystem Type Size Used Avail Use% Mounted on
/dev/sda3 ext3 16G 14G
On Fri, May 24, 2019 at 01:21:38AM +0300, Elan Ruusamäe wrote:
>
> On 23/05/2019 21:13, jajcus wrote:
> >+BuildRequires: python3 >= 3
>
> python3 was unfortunately started with epoch: 1, copy paste from python.spec
>
> otoh, if as you don't have more specific version here, just drop the
>
On 23/05/2019 21:13, jajcus wrote:
+BuildRequires: python3 >= 3
python3 was unfortunately started with epoch: 1, copy paste from python.spec
otoh, if as you don't have more specific version here, just drop the
version construct?
___
On 16/05/2019 08:22, baggins wrote:
commit 80789b35d14e465bd1338d2a2e1bb4428fe61911
Author: Jan Rękorajski
Date: Thu May 16 07:22:03 2019 +0200
- don't require programs for build, those are used only at runtime
...
+--- ark-19.04.1/plugins/clirarplugin/CMakeLists.txt~ 2019-05-05
On 06/05/2019 19:06, Jan Rękorajski wrote:
On Sun, 05 May 2019, Elan Ruusamäe wrote:
the ftp is still unusable for poldek after exactly two months have passed.
please make default poldek config to use http:// (or https://) if unable
to support ftp://
Fix your /etc/resolv.conf and
On Sun, 05 May 2019, Elan Ruusamäe wrote:
> the ftp is still unusable for poldek after exactly two months have passed.
>
>
> please make default poldek config to use http:// (or https://) if unable
> to support ftp://
Fix your /etc/resolv.conf and /etc/localtime.
And no, I don't know why it
the ftp is still unusable for poldek after exactly two months have passed.
please make default poldek config to use http:// (or https://) if unable
to support ftp://
```
$ docker run --rm registry.gitlab.com/pld-linux/pld:latest poldek --up
--upgrade-dist -vv
Setting cache directory path
On 11.04.2019 13:00, glen wrote:
> seems ok now.
>
>
> new commit created as:
>
> git diff 625690e48..96bb43df4
thanks!
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
On 4/11/19 11:59 AM, glen wrote:
11:52:52 [load: 2.40 60.00% nproc: 4]
root@1822-cvs repositories/SPECS.git# g gc
error: bad ref for ./logs/refs/heads/master
error: bad ref for ./logs/HEAD
fatal: bad object refs/heads/master
fatal: failed to run repack
```
12:00:39 [load: 1.40 35.00%
On 4/11/19 11:43 AM, glen wrote:
2019-04-11 10:40:01.897377507+02:00 I: Started sudo -Hiu git
bin/specscommit.sh
2019-04-11 10:40:01.930615129+02:00 E: fatal: index file smaller than
expected
2019-04-11 10:40:01.936209583+02:00 I: Finished with exitcode 0
tried fsck. but harder fix
On 4/11/19 10:07 AM, Jan Rękorajski wrote:
On Wed, 10 Apr 2019, Jan Palus wrote:
For some time now it seems that freshness report does not include new changes,
any idea what happened?
http://ep09.pld-linux.org/~pldth/qa.php?q=freshness
Sample missing packages: libbluray tasksh
On Wed, 10 Apr 2019, Jan Palus wrote:
> For some time now it seems that freshness report does not include new changes,
> any idea what happened?
>
> http://ep09.pld-linux.org/~pldth/qa.php?q=freshness
>
> Sample missing packages: libbluray tasksh glib-networking
> gobject-introspection
> vala
On Wed, Apr 10, 2019 at 10:43:02AM +0200, Adam Golebiowski wrote:
> Hi,
>
> I suggest to drop openchange. The project is effectively dead:
> - last commit from Dec 2015 [0]
> - openchange.org domain expired and noone bothered to renew - got hijacked
> - samba's wiki on openchange also states lack
On Sun, Mar 17, 2019 at 02:24:15PM +0100, Adam Golebiowski wrote:
> On Sun, Mar 17, 2019 at 11:48:14AM +0100, Jan Rękorajski wrote:
> > Can someone please take a look at broken dependencies in th-test and fix
> > them?
> >
> > http://ep09.pld-linux.org/~pldth/main-ready-test.txt
>
> I'll handle
On 25/03/2019 14:03, glen wrote:
>
> w... what is going on here?
loop on ca-certificates symlink
>
>
> ```
>
> bash-4.4# rpm -q wget openssl ca-certificates
> wget-1.20.1-4.x86_64
> openssl-1.1.1b-1.x86_64
> ca-certificates-20190110-1.noarch
> bash-4.4# wget
>
On 21.03.2019 09:58, Arkadiusz Miśkiewicz wrote:
> On 21/03/2019 00:35, atler wrote:
> > commit fc41f21cbe3529378b0600ec3e027668b7f878d4
> > Author: Jan Palus
> > Date: Thu Mar 21 00:30:10 2019 +0100
> >
> > build without statx to support kernels older than 4.11
>
>
> Hm, it doesn't
On 21/03/2019 00:35, atler wrote:
> commit fc41f21cbe3529378b0600ec3e027668b7f878d4
> Author: Jan Palus
> Date: Thu Mar 21 00:30:10 2019 +0100
>
> build without statx to support kernels older than 4.11
Hm, it doesn't fallback? It should since it check ENOSYS
int ret = qt_fstatx(fd,
On Sun, Mar 17, 2019 at 11:48:14AM +0100, Jan Rękorajski wrote:
> Can someone please take a look at broken dependencies in th-test and fix them?
>
> http://ep09.pld-linux.org/~pldth/main-ready-test.txt
I'll handle these.
___
pld-devel-en mailing list
On 11/03/2019 23.24, Elan Ruusamäe wrote:
> why not /etc/nginx/conf.avail like rest of the debian/ubuntu world lives?
/etc/nginx/snippets is exactly how Debian does that.
# dpkg -S /etc/nginx/snippets ; echo ; grep NAME /etc/os-release
nginx-common: /etc/nginx/snippets
PRETTY_NAME="Debian
why not /etc/nginx/conf.avail like rest of the debian/ubuntu world lives?
On 11/03/2019 16:50, arekm wrote:
commit 924400caa957d83ab7d2899775b761d54567c86d
Author: Arkadiusz Miśkiewicz
Date: Mon Mar 11 15:50:38 2019 +0100
- rel 3; provide /etc/nginx/snippets dir for custom config
Does anyone have any idea why LD_LIBRARY_PATH is not working on builders in this
case? Issue is not reproducible in my local env.
x86_64-pld-linux-g++ -Wl,--as-needed -Wl,--no-copy-dt-needed-entries
-Wl,-z,relro -Wl,-z,combreloc -Wl,-e,qt_core_boilerplate -Wl,--no-undefined
let them rest well!
On 27/02/2019 00:53, Jan Rękorajski wrote:
Until someone fixes build problems with kde packages that are currently broken
according to http://ep09.pld-linux.org/~pldth/main-ready-test.txt, I am
going to remove ALL kde4 and kde3 packages and everything that depends on
them.
On 25/02/2019 23:28, Arkadiusz Miśkiewicz wrote:
On 24/02/2019 12:57, Jan Palus wrote:
Looks like starting with gcc build
(https://srcbuilder.pld-linux.org/th/queue.html#184029)
buildlogs went missing. Can someone check?
rsyncd required restart on glibc upgrade it seems. Fixed.
perhaps add
On 24/02/2019 12:57, Jan Palus wrote:
> Looks like starting with gcc build
> (https://srcbuilder.pld-linux.org/th/queue.html#184029)
> buildlogs went missing. Can someone check?
rsyncd required restart on glibc upgrade it seems. Fixed.
--
Arkadiusz Miśkiewicz, arekm / ( maven.pl |
On 24.02.2019 13:25, Jakub Bogusz wrote:
> On Sun, Feb 24, 2019 at 12:57:05PM +0100, Jan Palus wrote:
> > Looks like starting with gcc build
> > (https://srcbuilder.pld-linux.org/th/queue.html#184029)
> > buildlogs went missing. Can someone check?
>
> Probably because:
>
> there were problems
On Sun, Feb 24, 2019 at 12:57:05PM +0100, Jan Palus wrote:
> Looks like starting with gcc build
> (https://srcbuilder.pld-linux.org/th/queue.html#184029)
> buildlogs went missing. Can someone check?
Probably because:
there were problems sending files from queue
On 21/02/2019 16:38, glen wrote:
> On 2/21/19 3:03 PM, arekm wrote:
>
>> +%post
>> +if [ -d /sys/fs/pstore ]; then
>> + grep -qE "^none.*/sys/fs/pstore" %{_sysconfdir}/fstab || (echo -e
>> "none\t\t/sys/fs/pstore\tpstore\tdefaults\t 0 0" >>
>> %{_sysconfdir}/fstab && grep -q "/sys/fs/pstore"
On 2/21/19 3:03 PM, arekm wrote:
+%post
+if [ -d /sys/fs/pstore ]; then
+ grep -qE "^none.*/sys/fs/pstore" %{_sysconfdir}/fstab || (echo -e
"none\t\t/sys/fs/pstore\tpstore\tdefaults\t 0 0" >> %{_sysconfdir}/fstab && grep -q
"/sys/fs/pstore" /proc/self/mounts || mount /sys/fs/pstore)
+
On 19/02/2019 16:59, Arkadiusz Miśkiewicz wrote:
On 19/02/2019 15:37, Jacek Konieczny wrote:
Adding external libidn2 dependency to glibc was a very bad idea and
should be reverted. glibc must not have any 'heavy' external
dependencies.
That's why it is "Suggests" not "Requires".
it's rpm
On Tue, Feb 19, 2019 at 09:34:48AM +0100, Jacek Konieczny wrote:
> The bigger problem will be /var/run subdirectories… I have no
> good idea how to make this work without systemd and tmpfiles or
> by re-implementing tmpfiles in rc-scripts…
You might want to have a look at
http://git.alt
On 19/02/2019 15:37, Jacek Konieczny wrote:
> Adding external libidn2 dependency to glibc was a very bad idea and
> should be reverted. glibc must not have any 'heavy' external
> dependencies.
That's why it is "Suggests" not "Requires".
--
Arkadiusz Miśkiewicz, arekm / ( maven.pl |
On 2/19/19 4:37 PM, Jacek Konieczny wrote:
Adding external libidn2 dependency to glibc was a very bad idea and
should be reverted. glibc must not have any 'heavy' external
dependencies. And libidn2 is not even a single library, as it pulls
libunistring.
perhaps pld should go alpine? use musl
On 2/19/19 10:39 AM, Jacek Konieczny wrote:
On 19/02/2019 09.34, Jacek Konieczny wrote:
The systemd preferred way to handle backward compatibility with the old
/var/run directory is to make /var/run a symlink to /run.
Wrong… it is bind-mount of /run over /var/run, which is currently
disabled
On 2/19/19 2:16 PM, jajcus wrote:
-%post
-/sbin/ldconfig
-[ ! -x /usr/sbin/fix-info-dir ] || /usr/sbin/fix-info-dir %{_infodir} >/dev/null
2>&1
+%post -p
+os.execute("/sbin/ldconfig >/dev/null 2>&1")
+os.execute("/usr/sbin/fix-info-dir %{_infodir} >/dev/null 2>&1")
-%postun
On 19/02/2019 09.39, Jacek Konieczny wrote:
> On 19/02/2019 09.34, Jacek Konieczny wrote:
>> The systemd preferred way to handle backward compatibility with the old
>> /var/run directory is to make /var/run a symlink to /run.
>
> Wrong… it is bind-mount of /run over /var/run, which is currently
On 19/02/2019 09.34, Jacek Konieczny wrote:
> The systemd preferred way to handle backward compatibility with the old
> /var/run directory is to make /var/run a symlink to /run.
Wrong… it is bind-mount of /run over /var/run, which is currently
disabled in PLD.
Maybe the way to go is to restore
On 2/14/19 9:38 AM, arekm wrote:
+%triggerun -- syslog-ng < 3.19.1
+grep -q '/etc/syslog-ng.d/'/etc/syslog-ng/syslog-ng.conf || echo '@include
"/etc/syslog-ng.d/"' >> /etc/syslog-ng/syslog-ng.conf
+exit 0
+
argh, again some project decides to do include dir support, but without
actual
601 - 700 of 6904 matches
Mail list logo
