On Sat, 24 Oct 2020, Neal Gompa wrote:
> On Sat, Oct 24, 2020 at 11:16 AM Jan Rękorajski via pld-devel-en
> wrote:
> >
> > I have prepared rpm 4.16, poldek and support packages, they are
> > available on http://ftp1.pld-linux.org/people/baggins/rpm.org/
> >
> > I would appreciate if you could
On 24.10.2020 16:12, baggins wrote:
> commit be07e71c8acd92e61d42ccb1c92200f92ed152c9
> Author: Jan Rękorajski
> Date: Sat Oct 24 15:50:57 2020 +0200
>
> - drop lua hacks and look for default lua version
> -BuildRequires: lua53-devel >= 5.3.5
> +BuildRequires: lua-devel >= 5.1
On Sat, Oct 24, 2020 at 11:17 AM Neal Gompa wrote:
>
> On Sat, Oct 24, 2020 at 11:16 AM Jan Rękorajski via pld-devel-en
> wrote:
> >
> > I have prepared rpm 4.16, poldek and support packages, they are
> > available on http://ftp1.pld-linux.org/people/baggins/rpm.org/
> >
> > I would appreciate
On Sat, Oct 24, 2020 at 11:16 AM Jan Rękorajski via pld-devel-en
wrote:
>
> I have prepared rpm 4.16, poldek and support packages, they are
> available on http://ftp1.pld-linux.org/people/baggins/rpm.org/
>
> I would appreciate if you could test the uprade path, functionality
> and tell me if
On Fri, 23 Oct 2020, Jan Palus wrote:
> On 23.10.2020 14:16, Jan Rękorajski via pld-devel-en wrote:
> > On Thu, 27 Aug 2020, atler wrote:
> >
> > > commit 6e87a2d1330eca8358a494c62b4e85986b95a50b
> > > Author: Jan Palus
> > > Date: Thu Aug 27 18:35:24 2020 +0200
> > >
> > > compatibility
On 23.10.2020 14:16, Jan Rękorajski via pld-devel-en wrote:
> On Thu, 27 Aug 2020, atler wrote:
>
> > commit 6e87a2d1330eca8358a494c62b4e85986b95a50b
> > Author: Jan Palus
> > Date: Thu Aug 27 18:35:24 2020 +0200
> >
> > compatibility package for legacy, unmaintained apps
> >
> >
On Thu, 27 Aug 2020, atler wrote:
> commit 6e87a2d1330eca8358a494c62b4e85986b95a50b
> Author: Jan Palus
> Date: Thu Aug 27 18:35:24 2020 +0200
>
> compatibility package for legacy, unmaintained apps
>
> libupnp.spec => libupnp1.6.spec | 32 ++--
> 1 file
W dniu 21.10.2020 o 09:51, Elan Ruusamäe pisze:
> (from previously whitelisted ip)
>
> ```
>
> $ rsync rsync://rsync.pld-linux.org/pld/dists/
>
> @ERROR: invalid uid nobody
> rsync error: error starting client-server protocol (code 5) at
> main.c(1648) [Receiver=3.1.2]
> ```
Looks like it
On Wed, 21 Oct 2020, Elan Ruusamäe wrote:
> (from previously whitelisted ip)
>
> ```
>
> $ rsync rsync://rsync.pld-linux.org/pld/dists/
>
> @ERROR: invalid uid nobody
> rsync error: error starting client-server protocol (code 5) at
> main.c(1648) [Receiver=3.1.2]
> ```
Client problem?
Works
W dniu 19.10.2020 o 14:35, Jan Rękorajski pisze:
> PHP4 and PHP 5.2 do not build anymore and are so old that keeping them
> around makes little sense. I will removed them and everything that
> depends on them in the following weeks.
>
I'll look at these (still using both).
--
Arkadiusz
On Mon, 19 Oct 2020, Elan Ruusamäe wrote:
> On 10/19/20 1:24 AM, baggins wrote:
>
> > +RPM_FORMAT_VERSION := `pkg-config --modversion rpm | cut -d . -f 1`
> > +RPM_MAJOR_VERSION := `pkg-config --modversion rpm | cut -d . -f 1`
> > +RPM_MINOR_VERSION := `pkg-config --modversion rpm | cut -d . -f
On 10/19/20 7:18 AM, qboosh wrote:
commit d18d7763aef2b08dc8474c8894b2f2923e8723ea
Author: Jakub Bogusz
Date: Mon Oct 19 06:18:22 2020 +0200
- added hye to the list of wanted locales
glibc.spec | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
---
diff --git a/glibc.spec
On 10/19/20 1:24 AM, baggins wrote:
+RPM_FORMAT_VERSION := `pkg-config --modversion rpm | cut -d . -f 1`
+RPM_MAJOR_VERSION := `pkg-config --modversion rpm | cut -d . -f 1`
+RPM_MINOR_VERSION := `pkg-config --modversion rpm | cut -d . -f 1`
these three are all the same, or I'm not seeing
On 10/18/20 6:10 PM, Jan Rękorajski via pld-devel-en wrote:
On Sun, 18 Oct 2020, Elan Ruusamäe wrote:
On 10/18/20 1:37 PM, atler wrote:
Obsoletes: mate-menu-editor
+%{?noarchpackage}
BuildRoot: %{tmpdir}/%{name}-%{version}-root-%(id -u -n)
well. here's what you go it wrong. for
On Sun, 18 Oct 2020, Elan Ruusamäe wrote:
> On 10/18/20 1:37 PM, atler wrote:
>
> > Obsoletes:mate-menu-editor
> > +%{?noarchpackage}
> > BuildRoot:%{tmpdir}/%{name}-%{version}-root-%(id -u -n)
>
> well. here's what you go it wrong. for main package noarch should be
>
On 10/18/20 1:37 PM, atler wrote:
Obsoletes:mate-menu-editor
+%{?noarchpackage}
BuildRoot:%{tmpdir}/%{name}-%{version}-root-%(id -u -n)
well. here's what you go it wrong. for main package noarch should be
always written out.
and therefore perhaps the macro should be renamed to
W dniu 06.10.2020 o 22:29, Jakub Bogusz pisze:
> On Tue, Oct 06, 2020 at 09:47:36PM +0200, Arkadiusz Miśkiewicz wrote:
>> W dniu 06.10.2020 o 15:14, Jakub Bogusz via pld-devel-en pisze:
>>> Can we have rust and cargo installed on carme-x32?
>>> It requires a few x86_64 libraries, so I cannot
On Tue, Oct 06, 2020 at 09:47:36PM +0200, Arkadiusz Miśkiewicz wrote:
> W dniu 06.10.2020 o 15:14, Jakub Bogusz via pld-devel-en pisze:
> > Can we have rust and cargo installed on carme-x32?
> > It requires a few x86_64 libraries, so I cannot install with accessible
> > poldek commands.
> >
> >
W dniu 06.10.2020 o 15:14, Jakub Bogusz via pld-devel-en pisze:
> Can we have rust and cargo installed on carme-x32?
> It requires a few x86_64 libraries, so I cannot install with accessible
> poldek commands.
>
>
> poldek:/all-avail> install cargo-1.44.1-2.x32 rust-1.44.1-2.x32
> Loading
On Tue, Oct 06, 2020 at 04:26:50PM +0200, arekm wrote:
> commit bede0ed9de64c316b06ae86643a2df9422faf130
> Author: Arkadiusz Miśkiewicz
> Date: Tue Oct 6 16:26:44 2020 +0200
>
> - up to 2.5.0
>
> mpdecimal-cpython.patch | 113
>
>
On Mon, Oct 05, 2020 at 01:12:44AM +0200, Jan Rękorajski wrote:
> On Sun, 04 Oct 2020, PLD th-x32 builder wrote:
>
> > rust.spec (auto/th/rust-1.44.1-2): OK
> >
> > --- rust.spec:auto/th/rust-1.44.1-2:
> > upgrading packages
> > Build-Time: user:22480.24s sys:327.35s real:7031.10s (faults io:17
On Fri, 02 Oct 2020, qboosh wrote:
> commit 0b4ebb8c0a63e29ec47b0e6d4f78c9f2759a5a9c
> Author: Jakub Bogusz
> Date: Fri Oct 2 17:11:47 2020 +0200
>
> - version 1.752: "noarchpackage" macro to cut down boilerplate
>
> macros.pld | 8
> rpm-pld-macros.spec | 2 +-
> 2
On Sun, 04 Oct 2020, PLD th-x32 builder wrote:
> rust.spec (auto/th/rust-1.44.1-2): OK
>
> --- rust.spec:auto/th/rust-1.44.1-2:
> upgrading packages
> Build-Time: user:22480.24s sys:327.35s real:7031.10s (faults io:17
> non-io:47582180)
>
> Files queued for ftp:
> 13348158
I tried to execute:
`poldek -iv openssl-devel-1.1.1g-1.x86_64 zlib-devel-1.2.11-2.x86_64`
And why it refused with "equal version installed"?
`rpm -q openssl-devel zlib-devel` returned:
openssl-devel-1.1.1g-1.x32
zlib-devel-1.2.11-2.x32
Adding `--force` helped (but only -devel packages were
On Mon, Sep 28, 2020 at 07:07:54PM +0200, Jakub Bogusz wrote:
> On Mon, Sep 28, 2020 at 04:41:21PM +0200, Jan Palus wrote:
> > On 27.09.2020 20:17, qboosh wrote:
> > > commit a04002a841905f8c84ca1c955e047676994c1ef2
> > > Author: Jakub Bogusz
> > > Date: Sun Sep 27 20:20:03 2020 +0200
> > >
>
On Mon, Sep 28, 2020 at 04:41:21PM +0200, Jan Palus wrote:
> On 27.09.2020 20:17, qboosh wrote:
> > commit a04002a841905f8c84ca1c955e047676994c1ef2
> > Author: Jakub Bogusz
> > Date: Sun Sep 27 20:20:03 2020 +0200
> >
> > - version 1.749: fixed _ver_* macros
> ...
> > -# BuildRequires:
On 27.09.2020 20:17, qboosh wrote:
> commit a04002a841905f8c84ca1c955e047676994c1ef2
> Author: Jakub Bogusz
> Date: Sun Sep 27 20:20:03 2020 +0200
>
> - version 1.749: fixed _ver_* macros
...
> -# BuildRequires: rpmbuild(macros) >= 1.748
> -%_ver_lt() %(test rpmvercmp "%{1}" "%{2}"
On 23.09.2020 20:12, PLD th-src builder wrote:
> crun.spec (HEAD): FAILED
...
> --2020-09-23 22:12:23--
> http://distfiles.pld-linux.org/distfiles/by-md5/f/c/fcb34c867a0acf9fa7f8cba3cae43d4a/crun-0.15.tar.xz
> Resolving distfiles.pld-linux.org... failed: No address associated with
> hostname.
>
W dniu 31.08.2020 o 21:43, Jakub Bogusz via pld-devel-en pisze:
> seems dead?
>
> $ ssh-carme-x32
> Connection closed by 193.239.45.154 port 22
>
>
glibc 2.31 bug
https://sourceware.org/bugzilla/show_bug.cgi?id=26248
Upgrade to 2.32 fixed the problem.
--
Arkadiusz Miśkiewicz, arekm / (
W dniu 21.08.2020 o 09:34, Jan Palus via pld-devel-en pisze:
> On 20.08.2020 18:19, Jakub Bogusz via pld-devel-en wrote:
>> On Thu, Aug 20, 2020 at 11:59:13AM +0200, Jan Palus via pld-devel-en
>> wrote:
>>> Recently mails sent to PLD mailing lists take longer than usual before
>>> they reach me.
On 20.08.2020 18:19, Jakub Bogusz via pld-devel-en wrote:
On Thu, Aug 20, 2020 at 11:59:13AM +0200, Jan Palus via pld-devel-en wrote:
Recently mails sent to PLD mailing lists take longer than usual before
they reach me. Any idea where that 23min delay is coming from?
No idea, but I'm seeing
Dnia czwartek, 20 sierpnia 2020 11:59:13 CEST Jan Palus via pld-devel-en
pisze:
> Recently mails sent to PLD mailing lists take longer than usual before
> they reach me. Any idea where that 23min delay is coming from?
>
>
> Received: from lists.pld-linux.org (lists.pld-linux.org
On Thu, Aug 20, 2020 at 11:59:13AM +0200, Jan Palus via pld-devel-en wrote:
> Recently mails sent to PLD mailing lists take longer than usual before
> they reach me. Any idea where that 23min delay is coming from?
No idea, but I'm seeing even 1-2h delays in the same step.
adamg?
> Received:
On 18.08.2020 10:52, Elan Ruusamäe via pld-devel-en wrote:
>
> On 8/7/20 10:28 AM, mrozowik wrote:
> > - moving gnome shell seahorse-search-provider to separate subpackage
>
> you need to add conflicts for original package berfore splitting:
>
> -
>
On 8/7/20 10:28 AM, mrozowik wrote:
- moving gnome shell seahorse-search-provider to separate subpackage
you need to add conflicts for original package berfore splitting:
-
http://cvs.pld-linux.org/cgi-bin/viewvc.cgi/cvs/PLD-doc/devel-hints-en.txt?revision=1.60=markup#l717
On Thu, Mar 05, 2020 at 02:53:56PM +0100, bszx wrote:
> @@ -427,7 +427,7 @@ fi
> %attr(640,root,root) %config(noreplace) %verify(not md5 mtime size)
> /etc/sysconfig/firebird
> %attr(640,root,root) %config(noreplace) %verify(not md5 mtime size)
> %{_sysconfdir}/tmpfiles.d/firebird.conf
>
On Sat, Jul 11, 2020 at 08:50:53PM +0200, Jan Rękorajski wrote:
> Both packages are unmaintaned in PLD since 2015.
>
> gr-osmosdr does not build with gnuradio 3.8, gqrx requires gr-osmosdr.
Have a look at ALT package if you need those:
* Sun Nov 24 2019 Anton Midyukov 0.1.4-alt5.20190514
- New
On 7/7/20 12:50 PM, Jan Rękorajski wrote:
This package does not build in its current form and it's way, way outdated.
If you care for it, please either fix build or do an update.
thanks for the long support! you can drop the package.
___
On 07.07.2020 12:30, Andrzej Zawadzki wrote:
>Hi!
>
>After upgrade that package KDE4 stop working - flood of core dumps.
>
>Maybe rebuilding KDE4 is enough to fix this issue?
>
>ps. I don't have stack trace.
kde4/qt4 should either get a maintainer -- I propose you -- or be
Hi!
After upgrade that package KDE4 stop working - flood of core dumps.
Maybe rebuilding KDE4 is enough to fix this issue?
ps. I don't have stack trace.
On 04.07.2020 14:16, atler wrote:
commit ea68ef3282f32b532aad4dc6237616b5037beabe
Author: Jan Palus [1]
Date: Sat Jul 4
On Fri, 12 Jun 2020, Jan Palus wrote:
> On 12.06.2020 20:01, Jan Rękorajski wrote:
> > Yes, there must be some intricate issue when updating from 244 to 245.
> > Updating 245 to 245 shows no side effects, clean restart.
> >
> > If you know of anything I should look at, or have any pointers where
On 13/06/2020 04:17, Elan Ruusamäe wrote:
>
> On 6/13/20 12:29 AM, Arkadiusz Miśkiewicz wrote:
>> On 12/06/2020 23:17, 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
On 6/13/20 12:29 AM, Arkadiusz Miśkiewicz wrote:
On 12/06/2020 23:17, 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
this is still not solved. and rpm (berkeleydb?) crashes
On 12.06.2020 20:01, Jan Rękorajski wrote:
> Yes, there must be some intricate issue when updating from 244 to 245.
> Updating 245 to 245 shows no side effects, clean restart.
>
> If you know of anything I should look at, or have any pointers where
> should I dig, I'm open to suggestions.
The
On 12/06/2020 23:17, 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
>>
>
> this is still not solved. and rpm (berkeleydb?) crashes misearably on
> that and unable to recover:
>
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
this is still not solved. and rpm (berkeleydb?) crashes misearably on
that and unable to recover:
- https://gitlab.com/pld-linux/pld/-/jobs/593531470
On Fri, 12 Jun 2020, Jan Rękorajski wrote:
> On Wed, 10 Jun 2020, Jan Rękorajski wrote:
>
> > On Wed, 10 Jun 2020, Jan Palus wrote:
> >
> > > On 10.06.2020 09:35, baggins wrote:
> > > > commit bcc348b831315aef4775c2f8f9c3b349b3337d5b
> > > > Author: Jan Rękorajski
> > > > Date: Wed Jun 10
On Wed, 10 Jun 2020, Jan Rękorajski wrote:
> On Wed, 10 Jun 2020, Jan Palus wrote:
>
> > On 10.06.2020 09:35, baggins wrote:
> > > commit bcc348b831315aef4775c2f8f9c3b349b3337d5b
> > > Author: Jan Rękorajski
> > > Date: Wed Jun 10 09:35:13 2020 +0200
> > >
> > > - this version is broken
On Wed, 10 Jun 2020, Jan Palus wrote:
> On 10.06.2020 09:35, baggins wrote:
> > commit bcc348b831315aef4775c2f8f9c3b349b3337d5b
> > Author: Jan Rękorajski
> > Date: Wed Jun 10 09:35:13 2020 +0200
> >
> > - this version is broken in an interesting way, rebooted during upgrade
> > and
On 10.06.2020 09:35, baggins wrote:
> commit bcc348b831315aef4775c2f8f9c3b349b3337d5b
> Author: Jan Rękorajski
> Date: Wed Jun 10 09:35:13 2020 +0200
>
> - this version is broken in an interesting way, rebooted during upgrade
> and then became unable to boot fully
Any clue what went
click-bait commit message detected.
better commit message would be that describes commit without having to
click (or other means to see diff) to figure out what commit is about.
sane is ambiguous:
1. it's also a product: SANE - Scanner Access Now Easy
2. sane in what way, what was not
On 5/18/20 12:01 PM, Jan Palus wrote:
Thanks. Not a big deal but description is missing -- other packages use Summary:
for this purpose.
fixed.
idea was to emulate package being created, but it was not that easy. had
to hack setdescription.sh to skip checking master branch and remove
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,
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/
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
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
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
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,
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
>
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
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
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
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
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 =
501 - 600 of 6904 matches
Mail list logo
