On 18.05.2020 11:34, Elan Ruusamäe wrote:
> > Since commit reached git.pld-linux.org just fine, I believe the issue is
> > caused
> > by missing package on github:
> >
> > https://github.com/pld-linux/dxr2-driver
>
>
> repo created
>
>
> ```
>
>
> root@1822-cvs hooks/post-receive.d# sudo
On 5/18/20 9:52 AM, Jan Palus wrote:
Just got following error when pushing to dxr2-driver:
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 8 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 311 bytes | 311.00 KiB/s,
Just got following error when pushing to dxr2-driver:
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 8 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 311 bytes | 311.00 KiB/s, done.
Total 3 (delta 2), reused 0 (delta
On 5/14/20 11:35 AM, arekm wrote:
commit 78bc5c965406bd2b174fe2cc530aaf8caa175f8c
Author: Arkadiusz Miśkiewicz
Date: Thu May 14 10:35:12 2020 +0200
- rel 4; keep proper version in config file
syslog-ng.conf | 2 +-
syslog-ng.spec | 4 ++--
2 files changed, 3 insertions(+), 3
On 11.05.2020 10:01, Andrzej Zawadzki wrote:
>On 07.05.2020 23:20, Jan Palus wrote:
>
> On 06.05.2020 13:04, Andrzej Zawadzki wrote:
>
>Hi,
>
>after upgrade Mesa* to 20.0.6, kwin dies as below:
>
> >From which version you have upgraded (what was the last working version)?
>
>
On Fri, 08 May 2020, Elan Ruusamäe wrote:
> hallo?
>
>
> please moderator look at the moderation queue!
What moderation queue? You mean the spam that's sent to feedback?
--
Jan Rękorajski| PLD/Linux
SysAdm | bagginspld-linux.org | http://www.pld-linux.org/
For the last couple of days I've been boostrapping PLD for aarch64 and I'm happy
to report that my Pinebook Pro boots into PLD now (with just a little help from
Manjaro's kernel and wifi firmware). Basically everything works fine including,
but not limited to: rpm, poldek, X, Mesa, MATE, firefox,
hallo?
please moderator look at the moderation queue!
On 5/6/20 9:28 AM, Elan Ruusamäe wrote:
who knows list manager password? or has access to lists hosts?
information in wiki is outdated, the host akcyza dns does not exist
- https://www.pld-linux.org/machines
-
On 06.05.2020 13:04, Andrzej Zawadzki wrote:
>Hi,
>
>after upgrade Mesa* to 20.0.6, kwin dies as below:
>From which version you have upgraded (what was the last working version)?
Which GPU?
What driver?
Is there anything in xorg log?
Is there anything in dmesg?
Can you provide stack
Dnia środa, 6 maja 2020 13:04:26 CEST Andrzej Zawadzki pisze:
>Hi,
>
>after upgrade Mesa* to 20.0.6, kwin dies as below:
>
>Application: KWin (kwin), signal: Aborted
>
>Using host libthread_db library "/lib64/libthread_db.so.1".
>
>[KCrash Handler]
>
>#7
Hi,
after upgrade Mesa* to 20.0.6, kwin dies as below:
Application: KWin (kwin), signal: Aborted
Using host libthread_db library "/lib64/libthread_db.so.1".
[KCrash Handler]
#7 0x7f30bb60ac65 in raise () from /lib64/libc.so.6
#8 0x7f30bb5f4547 in abort () from
On 06.05.2020 09:26, Elan Ruusamäe wrote:
> On 5/3/20 9:05 PM, atler wrote:
>
> > commit dbd044c3e9564926c69806df3133b1322dd32d0b
> > Author: Jan Palus
> > Date: Sun May 3 20:02:33 2020 +0200
> >
> > add aarch64 to supported archs
>
> are you building pld for arm?
>
> do you have
who knows list manager password? or has access to lists hosts?
information in wiki is outdated, the host akcyza dns does not exist
- https://www.pld-linux.org/machines
- https://www.pld-linux.org/machines/akcyza
___
pld-devel-en mailing list
On 5/3/20 9:05 PM, atler wrote:
commit dbd044c3e9564926c69806df3133b1322dd32d0b
Author: Jan Palus
Date: Sun May 3 20:02:33 2020 +0200
add aarch64 to supported archs
are you building pld for arm?
do you have boostrap packages available?
On Sat, 25 Apr 2020, Jan Rękorajski wrote:
> On Sat, 25 Apr 2020, Jakub Bogusz wrote:
>
> > Why poldek ignores glibc-2.31-5.x86_64 upgrade, even when specified
> > explicitly on command
> > line?
> >
> > (I started with "-n th-all -Uvg glibc", then tried to add more and more
> > explicit
On Sat, 25 Apr 2020, Jakub Bogusz wrote:
> Why poldek ignores glibc-2.31-5.x86_64 upgrade, even when specified
> explicitly on command
> line?
>
> (I started with "-n th-all -Uvg glibc", then tried to add more and more
> explicit package names... but in each case third arch glibc (base) package
Why poldek ignores glibc-2.31-5.x86_64 upgrade, even when specified explicitly
on command
line?
(I started with "-n th-all -Uvg glibc", then tried to add more and more
explicit package names... but in each case third arch glibc (base) package is
ignored
and upgrade fails).
make-request -b
On 4/18/20 11:02 AM, Jan Rękorajski wrote:
A copy-paste of the error message into Google gives me this:
https://github.com/bitnami/bitnami-docker-laravel/issues/102
Try running the container with 'privileged: true'
it fits as a workaround, but not as a solution. and is obviously rather
On Sat, 18 Apr 2020, Elan Ruusamäe wrote:
>
> On 4/3/20 9:47 PM, Arkadiusz Miśkiewicz wrote:
> > On 03/04/2020 20:09, Elan Ruusamäe wrote:
> >> is this fix for this problem?
> >>
> >> -
> >> https://github.com/pld-linux/util-linux/commit/67a912cd50464cae095fbdb7b3cf90daf495fb90
> >>
> >>
> >> -
On 18/04/2020 08:32, Elan Ruusamäe wrote:
>
> On 4/3/20 9:47 PM, Arkadiusz Miśkiewicz wrote:
>> On 03/04/2020 20:09, Elan Ruusamäe wrote:
>>> is this fix for this problem?
>>>
>>> -
>>> https://github.com/pld-linux/util-linux/commit/67a912cd50464cae095fbdb7b3cf90daf495fb90
>>>
>>>
>>>
>>> -
>>>
On 4/3/20 9:47 PM, Arkadiusz Miśkiewicz wrote:
On 03/04/2020 20:09, Elan Ruusamäe wrote:
is this fix for this problem?
-
https://github.com/pld-linux/util-linux/commit/67a912cd50464cae095fbdb7b3cf90daf495fb90
-
http://lists.pld-linux.org/mailman/pipermail/pld-devel-en/2020-March/025883.html
Feel free to merge updated ceph from TLD. Or use it as starting point
for your own spec (with systemd support etc.)
https://git.tld-linux.org/?p=packages/ceph.git;a=summary
Note: ceph is now x64 only, x86 is officially not supported anymore.
Also frontend is not being build (downloads "to be
On 03/04/2020 20:09, Elan Ruusamäe wrote:
> is this fix for this problem?
>
> -
> https://github.com/pld-linux/util-linux/commit/67a912cd50464cae095fbdb7b3cf90daf495fb90
>
>
> -
> http://lists.pld-linux.org/mailman/pipermail/pld-devel-en/2020-March/025883.html
No.
Do you use systemd-nspawn
is this fix for this problem?
-
https://github.com/pld-linux/util-linux/commit/67a912cd50464cae095fbdb7b3cf90daf495fb90
-
http://lists.pld-linux.org/mailman/pipermail/pld-devel-en/2020-March/025883.html
On 16.03.2020 23:46, Elan Ruusamäe wrote:
i've got reports that cp -a (or just cp
On Mon, 30 Mar 2020, Elan Ruusamäe wrote:
> On 3/29/20 11:52 AM, Jan Rękorajski wrote:
>
> >> i think the pear dependency generator should be disabled by default,
> >> pear is considered dead in php world.
> > `
> > Then disable it, or even better, delete the scripts and config.
> what is the
On Mon, Mar 30, 2020 at 2:14 AM Elan Ruusamäe wrote:
>
> On 3/29/20 11:52 AM, Jan Rękorajski wrote:
>
> >> i think the pear dependency generator should be disabled by default,
> >> pear is considered dead in php world.
> > `
> > Then disable it, or even better, delete the scripts and config.
>
On 3/29/20 11:52 AM, Jan Rękorajski wrote:
i think the pear dependency generator should be disabled by default,
pear is considered dead in php world.
`
Then disable it, or even better, delete the scripts and config.
what is the rpm4/rpm5 plan again? i'd rather do this only once, not both
On 3/29/20 10:20 AM, Elan Ruusamäe wrote:
On 3/29/20 9:17 AM, Elan Ruusamäe wrote:
On 3/29/20 9:07 AM, Elan Ruusamäe wrote:
On 3/24/20 11:16 PM, Jan Rękorajski wrote:
On a side note, this is exactly why we should not have all those weird
hacks in deps generators and just run them always.
On 3/29/20 9:17 AM, Elan Ruusamäe wrote:
On 3/29/20 9:07 AM, Elan Ruusamäe wrote:
On 3/24/20 11:16 PM, Jan Rękorajski wrote:
On a side note, this is exactly why we should not have all those weird
hacks in deps generators and just run them always. To chatch stuff like
this.
this enabled
On 3/29/20 9:07 AM, Elan Ruusamäe wrote:
On 3/24/20 11:16 PM, Jan Rękorajski wrote:
On a side note, this is exactly why we should not have all those weird
hacks in deps generators and just run them always. To chatch stuff like
this.
this enabled pear dependencies breaks packages that does
On 3/24/20 11:16 PM, Jan Rękorajski wrote:
On a side note, this is exactly why we should not have all those weird
hacks in deps generators and just run them always. To chatch stuff like
this.
this enabled pear dependencies breaks packages that does not want them
(bundles everything, handles
On Tue, 24 Mar 2020, Elan Ruusamäe wrote:
> i would not like bunch of perl deps in base package.
>
> i think these dependencies are new due recent updates in the repo
>
>
> ```
>
> [root@4195c311335e /]# rpm -q rpm-build --requires|grep perl
> /usr/bin/perl
> perl(Carp)
> perl(Config)
>
On 24.03.2020 21:20, Elan Ruusamäe wrote:
> does i686 even work for someone really?
>
>
> some errors here and there
FWIW my up-to-date i686 VM (QEMU) used for package testing purposes works fine.
___
pld-devel-en mailing list
On Tue, Mar 24, 2020 at 09:20:19PM +0200, Elan Ruusamäe wrote:
> On 3/16/20 11:46 PM, Elan Ruusamäe wrote:
> >i've got reports that cp -a (or just cp --preserve=timestamps) fails
> >on i686 and glibc 2.31
> does i686 even work for someone really?
Which kernel and fs?
I don't see such problems,
On 3/16/20 11:46 PM, Elan Ruusamäe wrote:
i've got reports that cp -a (or just cp --preserve=timestamps) fails
on i686 and glibc 2.31
from strace i've grabbed such error:
utimensat_time64(4, NULL, [{tv_sec=1584393052, tv_nsec=0} /*
2020-03-16T23:10:52+0200 */, {tv_sec=1584393052,
i would not like bunch of perl deps in base package.
i think these dependencies are new due recent updates in the repo
```
[root@4195c311335e /]# rpm -q rpm-build --requires|grep perl
/usr/bin/perl
perl(Carp)
perl(Config)
perl(Cwd)
perl(File::Basename)
perl(File::Copy)
perl(File::Path)
On Mon, Mar 16, 2020 at 10:15:33PM +0100, mis wrote:
> commit 651f3f75747a091b5c3df9f9ac9fc8a93734cf8c
> Author: mis
> Date: Mon Mar 16 22:13:04 2020 +0100
>
> - up to 0.42.1
> - turn off tests running
>
> FIXME: some tests use internal, non-exported libpoldek symbols
>
PLD images have been merged by LXC-CI ([1]), means that create PLD's
LXD containers is now as easy as:
$ lxc launch images:pld c1
2 architectures are available:
$ lxc image ls -c=fdas images:pld
+--++--+-+
| FINGERPRINT |
i've got reports that cp -a (or just cp --preserve=timestamps) fails on
i686 and glibc 2.31
from strace i've grabbed such error:
utimensat_time64(4, NULL, [{tv_sec=1584393052, tv_nsec=0} /*
2020-03-16T23:10:52+0200 */, {tv_sec=1584393052, tv_nsec=0} /*
2020-03-16T23:10:52+0200 */],
On Tue, Mar 10, 2020 at 09:25:12PM +0100, Arkadiusz Miśkiewicz wrote:
> On 10/03/2020 19:01, Jakub Bogusz wrote:
> > What happened to th-x32?
> builder 13256 199 19.3 4190584 3974900 ? Rl Mar08 6045:49
^^^ ^^^
>
On 10/03/2020 19:01, Jakub Bogusz wrote:
> What happened to th-x32?
>
>
builder 13256 199 19.3 4190584 3974900 ? Rl Mar08 6045:49
/tmp/B.Cfmfdm/BUILD/gegl-0.4.22/build/tools/gegl-tester --all -o
/tmp/B.Cfmfdm/BUILD/gegl-0.4.22/build/docs/ophtml -d
What happened to th-x32?
--
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
On Sun, Feb 09, 2020 at 10:13:37 +0100, Jan Rękorajski wrote:
> What about plugging all this symlinking into geninitrd / dracut?
> This way we would have everything sorted before we even start booting to
> the filesystem in question.
Won't work on systems without initrd, won't be functional
On Sun, 26 Jan 2020, Marcin Krol wrote:
> On 23-Jan-20 12:36, Jan Rękorajski wrote:
> > I want to drop nopae, 4.4 and 4.14 kernels from Th,
> > leaving us with longterm releases 4.9 (the last kernel that supports
> > vserver),
> > 4.19, 5.4 and a latest stable.
> >
> > Thoughs? Cons?
>
> 4.14
On Thu, 06 Feb 2020, Arkadiusz Miśkiewicz wrote:
>
> Hi.
>
> We need to finally do this while still keeping sysvinit compatibility
> (using symlinks).
>
> Migrate
>
> /var/run to /run and keep /var/run -> /run symlink
> /var/lock to /run/lock and /var/lock -> /run/lock symlink
> /run/shm ->
On Sat, 08 Feb 2020, Jacek Konieczny wrote:
> On 2/8/20 6:52 PM, Tomasz Pala wrote:
> > On Thu, Feb 06, 2020 at 19:20:26 +0100, Arkadiusz Miśkiewicz wrote:
> >
> >> We need to finally do this while still keeping sysvinit compatibility
> >> (using symlinks).
> >
> > Why do we need to do this?
On Sat, Feb 08, 2020 at 20:00:47 +0100, Jacek Konieczny wrote:
> New systemd won't even boot properly when /run is a symlink. And many
How about mount --bind?
> That is why the /var/run -> /run symlink should be provided.
Yes, what is I'm afraid is that our rpm doesn't handle dir->symlink
On 2/8/20 6:52 PM, Tomasz Pala wrote:
> On Thu, Feb 06, 2020 at 19:20:26 +0100, Arkadiusz Miśkiewicz wrote:
>
>> We need to finally do this while still keeping sysvinit compatibility
>> (using symlinks).
>
> Why do we need to do this? Legacy SysVinit uses /var/run and works,
> while systemd
On Thu, Feb 06, 2020 at 19:20:26 +0100, Arkadiusz Miśkiewicz wrote:
> We need to finally do this while still keeping sysvinit compatibility
> (using symlinks).
Why do we need to do this? Legacy SysVinit uses /var/run and works,
while systemd systems are already handled well (tmpfiles etc.) in
Hi.
We need to finally do this while still keeping sysvinit compatibility
(using symlinks).
Migrate
/var/run to /run and keep /var/run -> /run symlink
/var/lock to /run/lock and /var/lock -> /run/lock symlink
/run/shm -> /dev/shm symlink
(any other?)
I wonder what is the best approach to do
On Wed, Feb 05, 2020 at 07:57:59PM +0100, Tomasz Pala wrote:
> On Wed, Feb 05, 2020 at 14:23:07 +, Saleem Khan wrote:
> > Can we have following packages added to the repositories please?
> > 1 ) Bleachbit
> > 2 ) Stacer
> Unless someone provides spec files, I doubt such programs would land in
Hello,
On Wed, Feb 05, 2020 at 14:23:07 +, Saleem Khan wrote:
> Can we have following packages added to the repositories please?
>
> 1 ) Bleachbit
> 2 ) Stacer
Unless someone provides spec files, I doubt such programs would land in
PLD anytime soon. Both seem of little use for properly
Hello,
Can we have following packages added to the repositories please?
1 ) Bleachbit
2 ) Stacer
Regards,
--
Dr.Saleem Khan Marwat
Abbottabad
Khyber-Pakhtunkhwa
Pakistan
Cell # +92333-5393854
WhatsApp # +92333-5393854
Email: drmar...@gmail.com
Web: http://saleem-khan.blogspot.com
Registered
On 1/9/20 12:32 PM, Elan Ruusamäe wrote:
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
and it's released now:
-
On Sun, Jan 26, 2020 at 06:55:19PM +0100, Jan Rękorajski wrote:
> On Sun, 26 Jan 2020, Jakub Bogusz wrote:
>
> > On Sat, Jan 25, 2020 at 02:06:07PM +0100, baggins wrote:
> > > commit f75adea6b3f6c1343989e98a27167605ed55b780
> > > Author: Jan Rękorajski
> > > Date: Sat Jan 25 14:03:53 2020
On Sun, 26 Jan 2020, Jakub Bogusz wrote:
> On Sat, Jan 25, 2020 at 02:06:07PM +0100, baggins wrote:
> > commit f75adea6b3f6c1343989e98a27167605ed55b780
> > Author: Jan Rękorajski
> > Date: Sat Jan 25 14:03:53 2020 +0100
> >
> > - stop including perl macros, it's not needed, rpm does this
On 23-Jan-20 12:36, Jan Rękorajski wrote:
I want to drop nopae, 4.4 and 4.14 kernels from Th,
leaving us with longterm releases 4.9 (the last kernel that supports vserver),
4.19, 5.4 and a latest stable.
Thoughs? Cons?
4.14 has longest planned support - up to Jan 2024 while 4.19 will EOL on
On Sat, Jan 25, 2020 at 02:06:07PM +0100, baggins wrote:
> commit f75adea6b3f6c1343989e98a27167605ed55b780
> Author: Jan Rękorajski
> Date: Sat Jan 25 14:03:53 2020 +0100
>
> - stop including perl macros, it's not needed, rpm does this on its own
I wonder how to specify dependency on
I want to drop nopae, 4.4 and 4.14 kernels from Th,
leaving us with longterm releases 4.9 (the last kernel that supports vserver),
4.19, 5.4 and a latest stable.
Thoughs? Cons?
--
Jan Rękorajski| PLD/Linux
SysAdm | bagginspld-linux.org | http://www.pld-linux.org/
On Thu, 2020-01-16 at 17:54 +0100, Jakub Bogusz wrote:
> I asked to greedy remove itk.
> It removed itk-devel by dependency, as it should, but why it removed
> itcl-devel too???
>
> mark itk-4.1.0-1.i686
> > Processing dependencies...
> > itk-4.1.0-1.i686 marks itk-devel-4.1.0-1.i686 (req itk =
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)
>
2019 snapshot of PLD/Linux Th has been released. It is available on
ftp://ftp.pld-linux.org/dists/th/2019/PLD/ and as poldek sources th-2019.
The main highlights of this release are:
* kernels 4.4.207, 4.9.207, 4.14.160, 4.19.91 and 5.4.6 (4.4 and 4.9 have
vserver enabled)
* GCC 9.2.0
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
```
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 2018 fontconfig-libs-2.13.0-3.x86_64
Thu Jul 5 16:20:41
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
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!
--
Jakub Boguszhttp://qboosh.pl/
___
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
The packages listed below will be dropped from Th soon (as in a week or two)
until someone takes care of them.
python-flask
python-flask-cache
python-flask-debugtoolbar-lineprofilerpanel
python-flask-debugtoolbar
python-flask-mail
python-flask-script
python-flask_sqlalchemy
python-ipykernel
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.
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.
err sigsys: openssh-8.0p1-3.x86_64
ok:
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 -
From: PLD all builder
X-PLD-Builder:
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
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 Boguszhttp://qboosh.pl/
___
pld-devel-en mailing list
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
701 - 800 of 8277 matches
Mail list logo
