cc: list
Forwarded Message
Subject: Re: [packages/dehydrated] - run always via sudo as
root:dehydrated to allow dehydrated group to read certificates and keys,
Date: Fri, 21 Dec 2018 22:35:54 +0200
From: Elan Ruusamäe
To: h...@pld-linux.org
provides user
(somewhy arekm wrote privately to me only).
anyway, the rel 44 (from th-test) still fails:
[root@2e971bacdb48 app]# echo '{}'> composer.json
[root@2e971bacdb48 app]# composer install; echo $?
Loading composer repositories with package information
139
[root@2e971bacdb48 app]# rpm -q php53-common
On 31/01/2019 21.34, Elan Ruusamäe wrote:
> what should be .spec named?
>
>
> python3-foo.spec?
>
> python-foo.spec?
I think using python-foo.spec for the source and build only python3-foo
package from that is the most consistent way.
E.g. what if python4 appears? What if a package loses
On 31/01/2019 21:34, Elan Ruusamäe wrote:
> what should be .spec named?
>
>
> python3-foo.spec?
>
> python-foo.spec?
I would go with python-foo.spec with python2 bcond disabled for
standalone packages (in case if it gets python2 support somehow).
If you are sure that it won't get python2
On Thu, Jan 31, 2019 at 06:30:59AM +0100, Arkadiusz Miśkiewicz wrote:
> On 30/01/2019 21:05, Jan Rękorajski wrote:
>
> > 3. drop x32 possibly? https://lwn.net/Articles/774734/
>
>
> Is anyone using x32 here? Speak up.
>
>
> (just to be clear x32 != i686)
nope, i686/x86_64 only.
On 31/01/2019 07:30, Arkadiusz Miśkiewicz wrote:
On 30/01/2019 21:05, Jan Rękorajski wrote:
3. drop x32 possibly?https://lwn.net/Articles/774734/
Is anyone using x32 here? Speak up.
(just to be clear x32 != i686)
nope. did not even manage to build clean chroot, as that time not all
On 30/01/2019 21:05, Jan Rękorajski wrote:
> 3. drop x32 possibly? https://lwn.net/Articles/774734/
Is anyone using x32 here? Speak up.
(just to be clear x32 != i686)
--
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )
___
pld-devel-en
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
> >
> > - updated dependencies; librsvg since 2.42 is partially in rust
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
>
> - updated dependencies; librsvg since 2.42 is partially in rust (what
> with th-x32?)
According to rust project
On Tue, Jan 29, 2019 at 01:53:33PM +0100, Jan Rękorajski wrote:
> On Tue, 29 Jan 2019, Adam Golebiowski wrote:
>
> >
> > > --- libxcrypt.spec:HEAD:
> > > cannot remove pam because it's required by util-linux, that is crucial
> >
> > what's the proper way to work with builders here?
>
>
On Tue, 29 Jan 2019, Adam Golebiowski wrote:
>
> > --- libxcrypt.spec:HEAD:
> > cannot remove pam because it's required by util-linux, that is crucial
>
> what's the proper way to work with builders here?
make-request -r -c '
poldek --up ;
poldek -iv libxcrypt-NEW_VERSION (--force may be
In ALT, we've moved exactly towards multiple versions so that
people switch (and dump/restore) between them when they know it,
and not after an overlooked line in dist-upgrade's output...
(when it's too late to use the upgraded "dumper" for that)
With multiple versions installed it is easier to
On Fri, Jan 25, 2019 at 09:14:10PM +0100, Marcin Krol wrote:
> P.S. For same reasons I'm not merging back some other changes,
> ie. versioned PostgreSQL allowing parallel install of multiple
> versions (in which I have yet to move configs to /etc BTW) and
> newer versions of some packages.
In
/etc/mail was a bad idea, so such migration in all MTAs and tools is
welcome :)
Except sendmail where /etc/mail seems to be "worldwide" default.
/etc/ftpd is next to go in TLD.
About merging back such changes...
1) I don't use PLD at all so I have no way to test changes in real
environment
On 25/01/2019 19.13, Arkadiusz Miśkiewicz wrote:
> On 25/01/2019 18:54, hawk wrote:
>> commit d545a6c3390ab2ebc284896499594a8d46ec94a1
>> Author: Marcin Krol
>> Date: Fri Jan 25 18:53:51 2019 +0100
>>
>> - migrate configuration to /etc/postfix
>
> /etc/mail was a bad idea, so such
On 25/01/2019 18:54, hawk wrote:
> commit d545a6c3390ab2ebc284896499594a8d46ec94a1
> Author: Marcin Krol
> Date: Fri Jan 25 18:53:51 2019 +0100
>
> - migrate configuration to /etc/postfix
/etc/mail was a bad idea, so such migration in all MTAs and tools is
welcome :)
--
Arkadiusz
On 07/01/2019 21:12, Jan Rękorajski wrote:
On Mon, 07 Jan 2019, glen wrote:
can't find mysql client package:
error: mysql-client: no such package
i don't see any dropping or deprecation notice: https://www.pld-linux.org/
Huh?
poldek:/all-avail> ls mysql-client
On Mon, 07 Jan 2019, glen wrote:
> can't find mysql client package:
>
> error: mysql-client: no such package
>
> i don't see any dropping or deprecation notice: https://www.pld-linux.org/
Huh?
poldek:/all-avail> ls mysql-client
mysql-client-5.7.24-2.x86_64
1 package
poldek:/all-avail>
llvm built successfully for all Th archs.
BTW - ouch...
1889870589 llvm-debuginfo-7.0.0-3.x86_64.rpm
--
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
On Fri, Dec 14, 2018 at 05:56:50PM +0100, Jan Rękorajski wrote:
> You need to revert this:
>
> http://git.pld-linux.org/?p=packages/llvm.git;a=commitdiff;h=f8b4baa198f262d3bff6af0ba38065ad386881a5;hp=fba35f645ed4c3ec1fd41765993175a580cd2c91
>
> I've been testing if newly added builders disk
You need to revert this:
http://git.pld-linux.org/?p=packages/llvm.git;a=commitdiff;h=f8b4baa198f262d3bff6af0ba38065ad386881a5;hp=fba35f645ed4c3ec1fd41765993175a580cd2c91
I've been testing if newly added builders disk capacity is enough for
this beast ;)
On Fri, Dec 14, 2018 at 4:02 PM Jakub
On Fri, Dec 14, 2018 at 11:26:24AM +0100, Jacek Konieczny wrote:
> On 12/12/2018 16.06, Jakub Bogusz wrote:
> >
> > THEY just changed the way of enabling rtti (from make variable to cmake
> > define).
> > As we had rtti in previous versions of llvm and it's needed by other
> > packages (i.e.
On 12/12/2018 16.06, Jakub Bogusz wrote:
>
> THEY just changed the way of enabling rtti (from make variable to cmake
> define).
> As we had rtti in previous versions of llvm and it's needed by other
> packages (i.e. Mesa/pipe-*), IMO we should just keep it enabled (and
> rebuild packages already
On 13/12/2018 12:42, Jan Palus wrote:
> On 13.12.2018 12:37, Arkadiusz Miśkiewicz wrote:
>> On 13/12/2018 12:30, Jan Palus wrote:
>>> On 13.12.2018 12:28, atler wrote:
Request by: atler
sqlite3: undefined macro lua:vn=rpm.expand("%vnum");v="";for i in
On 13.12.2018 12:37, Arkadiusz Miśkiewicz wrote:
> On 13/12/2018 12:30, Jan Palus wrote:
> > On 13.12.2018 12:28, atler wrote:
> >> Request by: atler
> >>
> >> sqlite3: undefined macro lua:vn=rpm.expand("%vnum");v="";for i in
> >> string.gmatch(string.format("%08d", vn), "..") do
On 13/12/2018 12:30, Jan Palus wrote:
> On 13.12.2018 12:28, atler wrote:
>> Request by: atler
>>
>> sqlite3: undefined macro lua:vn=rpm.expand("%vnum");v="";for i in
>> string.gmatch(string.format("%08d", vn), "..") do v=v.."."..i:gsub("^0",
>> "");end;v=v:gsub("^.",""):gsub("\.0$","");print(v)
On 13.12.2018 12:28, atler wrote:
> Request by: atler
>
> sqlite3: undefined macro lua:vn=rpm.expand("%vnum");v="";for i in
> string.gmatch(string.format("%08d", vn), "..") do v=v.."."..i:gsub("^0",
> "");end;v=v:gsub("^.",""):gsub("\.0$","");print(v)
>
>
>
> Files fetched: 0
>
> ALREADY
On Tue, Dec 11, 2018 at 03:37:40PM +0100, Jacek Konieczny wrote:
> Hi,
>
> I am preparing package for Mesa 18.3.0, switching the build system to
> Meson, as autoconf/automake is deprecated.
>
> I made it build, but without OpenCL. The problem is the Clover part of
> Mesa requires RTTI to build
On 11/12/2018 14:55, glen wrote:
> On 12/11/18 2:52 PM, arekm wrote:
>
>> - rel 3; use separate config, so nagios_nrpe rpm macros can deal
>> with it
>
> why not just patch and enable bbu by default?
>
Fine with me (there is no option to disable it though, on per host basis).
Kind of
On 12/11/18 2:52 PM, arekm wrote:
- rel 3; use separate config, so nagios_nrpe rpm macros can deal with it
why not just patch and enable bbu by default?
--
glen
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
On 12/11/18 2:13 PM, arekm wrote:
commit 5fe36881db12eb4ba498c749cb310450ce57138d
Author: Arkadiusz Miśkiewicz
Date: Tue Dec 11 13:13:17 2018 +0100
- rel 2; plugin doesn't monitor bbu by default, so provide separate
template command and template for that
you can just use:
On Mon, Dec 03, 2018 at 11:51:12PM +0100, Marcin Krol wrote:
> >>diff --git a/rsync.spec b/rsync.spec
> >>index d663909..a257e2d 100644
> >>--- a/rsync.spec
> >>+++ b/rsync.spec
> >>@@ -1,3 +1,4 @@
> >>+# TODO: 3.1.3 rsyncd segfaults very early in server rsync:// mode
> >>(both inetd and
On 04/12/2018 00:04, Arkadiusz Miśkiewicz wrote:
It isn't:
the repo is updating (maybe always was), i.e
contents of ~/SPECS is being committed to
/cvs/root/gitolite/repositories/SPECS.git
but your spec is not written to SPECS:
```
root@1822-cvs services/git# l -rt ~git/SPECS|tail
On 04/12/2018 00:51, Marcin Krol wrote:
diff --git a/rsync.spec b/rsync.spec
index d663909..a257e2d 100644
--- a/rsync.spec
+++ b/rsync.spec
@@ -1,3 +1,4 @@
+# TODO: 3.1.3 rsyncd segfaults very early in server rsync:// mode
(both inetd and standalone)
FYI...
diff --git a/rsync.spec b/rsync.spec
index d663909..a257e2d 100644
--- a/rsync.spec
+++ b/rsync.spec
@@ -1,3 +1,4 @@
+# TODO: 3.1.3 rsyncd segfaults very early in server rsync:// mode
(both inetd and standalone)
FYI...
https://www.mail-archive.com/rsync@lists.samba.org/msg32342.html
a/rsync.spec b/rsync.spec
index d663909..a257e2d 100644
--- a/rsync.spec
+++ b/rsync.spec
@@ -1,3 +1,4 @@
+# TODO: 3.1.3 rsyncd segfaults very early in server rsync:// mode (both inetd
and standalone)
can you re-test your scenario?
seems working with this test:
[~/rpm/packages/rsync(3.1.3
On 03/12/2018 21:49, Elan Ruusamäe wrote:
>
>
> On 03/12/2018 22:32, Elan Ruusamäe wrote:
>> Script used git.pld-linux.org/SPECS.git repo which is outdated
> it's actually up to date. at least now
>
> ```
> [~/all-specs (master)★] ➔ g fetch git://git.pld-linux.org/SPECS
> From
On 03/12/2018 22:32, Elan Ruusamäe wrote:
Script used git.pld-linux.org/SPECS.git repo which is outdated
it's actually up to date. at least now
```
[~/all-specs (master)★] ➔ g fetch git://git.pld-linux.org/SPECS
From git://git.pld-linux.org/SPECS
* branch HEAD ->
On 03/12/2018 21:30, Arkadiusz Miśkiewicz wrote:
On 02/12/2018 13:37, Jan Palus wrote:
Is this update job working correctly? Just few examples that are out of date:
avfs(11) [OLD] 1.0.0 [NEW] 1.0.6 --> 1.0.6 is in Git for a week now
ell(12) [OLD] 0.12 [NEW] 0.14 --> the latest version is
On 02/12/2018 13:37, Jan Palus wrote:
> Is this update job working correctly? Just few examples that are out of date:
>
>
> avfs(11) [OLD] 1.0.0 [NEW] 1.0.6 --> 1.0.6 is in Git for a week now
> ell(12) [OLD] 0.12 [NEW] 0.14 --> the latest version is 0.15 not 0.14 and 0.15
>
Is this update job working correctly? Just few examples that are out of date:
avfs(11) [OLD] 1.0.0 [NEW] 1.0.6 --> 1.0.6 is in Git for a week now
ell(12) [OLD] 0.12 [NEW] 0.14 --> the latest version is 0.15 not 0.14 and 0.15
is in repo for 2 weeks now
On 01/12/2018 08:24, Jakub Bogusz wrote:
> When trying to build pixman, on th-i686 tests fail impredictably
> - at least one of alphamap, composite, tolerance-test, but almost each
> time set of failing tests is different.
> Disabling openmp or parallel make seems to lower the number of failures,
On Wed, Nov 14, 2018 at 03:49:37PM +0100, Arkadiusz Miśkiewicz wrote:
> On 03/11/2018 11:11, Jan Rękorajski wrote:
> > The below packages will be removed from Th next week (~10th Nov) along
> > with any broken deps their removal will cause.
>
> Side note from bacula commit:
>
> "+
On 03/11/2018 11:11, Jan Rękorajski wrote:
> The below packages will be removed from Th next week (~10th Nov) along
> with any broken deps their removal will cause.
Side note from bacula commit:
"+TLSv1_method() should not be used and SSLv23_method() should be
+preferred because the
On 05/11/2018 13:04, Jan Palus wrote:
> On 05.11.2018 11:45, PLD th-x32 builder wrote:
>> cups-filters.spec (HEAD): FAILED
> ...
>> installing BR: php55\-devel
>> + poldek --noask --caplookup -Q -v '--ignore=hhvm-*' '--ignore=php4-*'
>> '--ignore=php52-*' '--ignore=php54-*' '--ignore=php55-*'
On 05.11.2018 11:45, PLD th-x32 builder wrote:
> cups-filters.spec (HEAD): FAILED
...
> installing BR: php55\-devel
> + poldek --noask --caplookup -Q -v '--ignore=hhvm-*' '--ignore=php4-*'
> '--ignore=php52-*' '--ignore=php54-*' '--ignore=php55-*' '--ignore=php56-*'
> '--ignore=php70-*'
W dniu 2018-11-03 11:11, Jan Rękorajski napisał(a):
The below packages will be removed from Th next week (~10th Nov) along
with any broken deps their removal will cause.
john
I will commit this one today, need to fix x32 build.
--
Adam Gołębiowski, PLD Linux
On Sat, 03 Nov 2018, Elan Ruusamäe wrote:
> On 03/11/2018 12:11, Jan Rękorajski wrote:
>
> > The below packages will be removed from Th next week (~10th Nov) along
> > with any broken deps their removal will cause.
> >
> > ossp-uuid
> dependency of rpm. can we switch to apk package manager
On 03/11/2018 12:11, Jan Rękorajski wrote:
The below packages will be removed from Th next week (~10th Nov) along
with any broken deps their removal will cause.
ossp-uuid
dependency of rpm. can we switch to apk package manager please? :)
___
W dniu 2018-10-31 07:48, Bartek Szady napisał(a):
What do you think about splitting bind package to bind-base and bind?
bind-base will contain server and init scripts/units, will have minimal
dependencies (no python dependency) and can be used as eg. caching
recursive server.
bind will contain
On Mon, Oct 29, 2018 at 12:52:17PM +0200, glen wrote:
> when you move lines, move comments as well...
I just restored original context (from cf40821233ef6534f5ad15bbb10409c699012d99)
lost in 4139e8458f99923b5290c8ce523d5d801c135ced...
> On 10/28/18 5:51 PM, qboosh wrote:
> > %package ld
> >
On 25/10/2018 15:21, Adam Gołębiowski wrote:
W dniu 2018-10-23 13:01, Arkadiusz Miśkiewicz napisał(a):
On 23/10/2018 12:43, glen wrote:
any plans to fix cvs.pld-linux.org?
cvs-nserver segfaults and needs some debugging or better switching to
other maintained cvs
cvs [status aborted]:
W dniu 2018-10-23 13:20, Jacek Konieczny napisał(a):
On 2018-10-23 13:01, Arkadiusz Miśkiewicz wrote:
On 23/10/2018 12:43, glen wrote:
any plans to fix cvs.pld-linux.org?
cvs-nserver segfaults and needs some debugging or better switching to
other maintained cvs
cvs [status aborted]:
W dniu 2018-10-23 13:01, Arkadiusz Miśkiewicz napisał(a):
On 23/10/2018 12:43, glen wrote:
any plans to fix cvs.pld-linux.org?
cvs-nserver segfaults and needs some debugging or better switching to
other maintained cvs
cvs [status aborted]: reading from server: Connection reset by peer
On 2018-10-01 16:42, glen wrote:
> On 10/1/18 11:36 AM, Jacek Konieczny wrote:
>> Possible solutions:
>> – disable autogenerated dependency for ldconfig, to force installing it
>> before glibc
>> – include ldconfig in the main glibc package
>> – change glibc %post so it won't fail on ldconfig
On 10/23/18 2:01 PM, Arkadiusz Miśkiewicz wrote:
On 23/10/2018 12:43, glen wrote:
any plans to fix cvs.pld-linux.org?
cvs-nserver segfaults and needs some debugging or better switching to
other maintained cvs
downgrade glibc. perhaps helps
--
glen
On 21.10.2018 22:13, Adam Golebiowski wrote:
On Sun, Oct 21, 2018 at 01:37:14PM +0200, Jan Rekorajski wrote:
On Thu, 27 Sep 2018, Arkadiusz Miskiewicz wrote:
On 20/09/2018 20:37, Arkadiusz Miskiewicz wrote:
openssl 1.1.1 rebuild, if anyone wants to help here is TODO list:
On 2018-10-23 13:01, Arkadiusz Miśkiewicz wrote:
> On 23/10/2018 12:43, glen wrote:
>> any plans to fix cvs.pld-linux.org?
>
> cvs-nserver segfaults and needs some debugging or better switching to
> other maintained cvs
>
>
>> cvs [status aborted]: reading from server: Connection reset by peer
On 23/10/2018 12:43, glen wrote:
any plans to fix cvs.pld-linux.org?
cvs-nserver segfaults and needs some debugging or better switching to
other maintained cvs
cvs [status aborted]: reading from server: Connection reset by peer
--
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org
On Sun, Oct 21, 2018 at 10:57:26PM +0200, Arkadiusz Miśkiewicz wrote:
> On 21/10/2018 22:13, Adam Golebiowski wrote:
>
> > And by the same time drop php < 5.6 as well.
> > apache1 had its last release 8+ years ago, php 5.5 last release in July
> > 2016.
> >
> > We can drop php5.6 in couple of
On 10/21/18 11:13 PM, Adam Golebiowski wrote:
Current status update:
android-tools drop
apache1-mod_ssl drop
side note - drop apache1 all together. And by the same time drop php < 5.6 as
well.
apache1 had its last release 8+ years ago, php 5.5 last release in July 2016.
We
On 21/10/2018 22:13, Adam Golebiowski wrote:
And by the same time drop php < 5.6 as well.
apache1 had its last release 8+ years ago, php 5.5 last release in July 2016.
We can drop php5.6 in couple of months - it will be eol-ed upstream by the end
of the year.
I'm using all these old phps,
On Thu, 27 Sep 2018, Arkadiusz Miśkiewicz wrote:
> On 20/09/2018 20:37, Arkadiusz Miśkiewicz wrote:
> >
> > openssl 1.1.1 rebuild, if anyone wants to help here is TODO list:
> >
> > http://ep09.pld-linux.org/~pldth/qa.php?q=main-ready-test
> >
> > Examples on how to fix things are at
On 25.09.2018 21:37, Jan Palus wrote:
> On 25.09.2018 19:14, PLD th-i686 builder wrote:
> > firefox.spec (auto/th/firefox-62.0.2-1): FAILED
>
> I got failed firefox build on i686 in some random place, followed by OK test
> build, followed by this failure in another random place. Can someone have
Any thoughts? Anybody ready to do proper testing for the new package? Or
am I doing this just for sport?
I'll try to test it however tests will be done on TLD, not PLD and I'll
need some time to adjust/rebuild packages and port my 2.2 configs.
M.
On Sun, Oct 7, 2018 at 2:43 PM Elan Ruusamäe wrote:
>
> why is invoking ninja hidden behind these macros?
>
>
> %build
> %meson build
> %meson_build -C build
>
> %install
> rm -rf $RPM_BUILD_ROOT
> %meson_install -C build
>
>
> i.e %meson_build and %meson_install expand to ninja, just have %ninja
On 9/24/18 9:54 PM, Jakub Bogusz wrote:
can someone have look at i686 and x32 builds (-r dev-7.3 branch)
i'm pretty ok to just to have ExclusiveArch: %{x8664} for 7.3 branch
--
glen
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
On 01/10/2018 22.17, Elan Ruusamäe wrote:
> On 29/09/2018 02:37, adwol wrote:
> altho i prefer just to keep same package multiple versions installed:
>
>
> # rpm -q openssl
> openssl-1.0.2o-1.x86_64
> openssl-1.1.1-1.x86_64
This does not work well with upgrades (e.g. „upgrade *” in poldek
On 29/09/2018 02:37, adwol wrote:
commit 9fc1b1b87b259e8a327c99835865e91a391efc9e
Author: Adam Osuchowski
Date: Sat Sep 29 00:55:56 2018 +0200
- cloned from openssl branch v1.0.2 as openssl102 to make it
parallel-installable with current 1.1.1 and newer
openssl-man-namespace.patch
On 10/1/18 11:36 AM, Jacek Konieczny wrote:
From my logs of (automated) building a fresh system in a chroot:
build 01-Oct-2018 09:25:17warning: LOOP:
build 01-Oct-2018 09:25:17warning: removing glibc-2.28-5.aos1.i686
"Requires(postun): /sbin/ldconfig" from tsort relations.
On 27/09/2018 18.59, Arkadiusz Miśkiewicz wrote:
>
> +- current TODO:
>
> pjproject.spec
Does anything use it? Except Asterisk, which uses own bundled version
(the patches and configuration included there is quite important for
proper Asterisk operation).
If not, then we can drop it and
On 9/26/18 2:43 PM, glen wrote:
perl-base-5.26.2-3.x86_64 marks perl-dirs-5.28.0-2.x86_64 (cap
/usr/share/perl5/vendor_perl)
ok. perl-dirs needs to be moved back.
done.
pldth@ep09-pld SRPMS/.metadata$ pfa-mvpkg PLD test
perl-dirs-5.28.0-2.src.rpm.info
pldth@ep09-pld SRPMS/.metadata$
On 9/26/18 2:43 PM, glen wrote:
super broken deps:
https://gitlab.com/pld-linux/cleanbuild/-/jobs/101752687
Installing set #3
Processing dependencies...
perl-modules-5.26.2-3.x86_64 marks perl-base-5.26.2-3.x86_64 (cap
/usr/lib64/perl5/5.26.2/x86_64-pld-linux-thread-multi)
error:
On 25.09.2018 19:14, PLD th-i686 builder wrote:
> firefox.spec (auto/th/firefox-62.0.2-1): FAILED
I got failed firefox build on i686 in some random place, followed by OK test
build, followed by this failure in another random place. Can someone have look
at th-i686 builder? Is there any trace of
On Thu, Sep 20, 2018 at 08:37:36PM +0200, Arkadiusz Miśkiewicz wrote:
>
> openssl 1.1.1 rebuild, if anyone wants to help here is TODO list:
>
> http://ep09.pld-linux.org/~pldth/qa.php?q=main-ready-test
>
> Examples on how to fix things are at packages/*/openssl.patch mostly.
> Also patches
On 24/09/2018 21:54, Jakub Bogusz wrote:
can someone have look at i686 and x32 builds (-r dev-7.3 branch)
http://buildlogs.pld-linux.org//index.php?dist=th=i686=0=php=3a224baa-8fb9-499a-a8a3-8d03d0d83f41=tail
/usr/bin/ld: ext/standard/.libs/base64.o: unsupported non-PIC call to IFUNC
On Mon, Sep 24, 2018 at 08:54:20PM +0300, Elan Ruusamäe wrote:
> hi
>
> can someone have look at i686 and x32 builds (-r dev-7.3 branch)
>
>
> http://buildlogs.pld-linux.org//index.php?dist=th=i686=0=php=3a224baa-8fb9-499a-a8a3-8d03d0d83f41=tail
>
> /usr/bin/ld: ext/standard/.libs/base64.o:
On 09/20/18 20:37, Arkadiusz Miśkiewicz wrote:
>
> openssl 1.1.1 rebuild, if anyone wants to help here is TODO list:
>
> http://ep09.pld-linux.org/~pldth/qa.php?q=main-ready-test
qt4-plugin-qca-ossl is obsoleted by qca.
Bartek
___
pld-devel-en
On 20/09/2018 22:47, Jacek Konieczny wrote:
On 20/09/2018 20.57, Adam Osuchowski wrote:
I think, first of all we should to ensure that openssl 1.0.2 and 1.1.1 are
parallel installable,
Be aware that mixing openssl libraries can lead to segfaults (if binary
uses libraries that are linked to
On 20/09/2018 20.57, Adam Osuchowski wrote:
> Arkadiusz Miśkiewicz wrote:
>> openssl 1.1.1 rebuild, if anyone wants to help here is TODO list:
>>
>> http://ep09.pld-linux.org/~pldth/qa.php?q=main-ready-test
>>
>> Examples on how to fix things are at packages/*/openssl.patch mostly. Also
>>
Arkadiusz Miśkiewicz wrote:
> openssl 1.1.1 rebuild, if anyone wants to help here is TODO list:
>
> http://ep09.pld-linux.org/~pldth/qa.php?q=main-ready-test
>
> Examples on how to fix things are at packages/*/openssl.patch mostly. Also
> patches sometimes in debian, archlinux or upstream git of
i was thinking too, why the include_shell was in place, but did not
bother to look to git history.
digged now, and no obvious reason written. so i guess the glob include
didn't exist at the time
https://github.com/pld-linux/lighttpd/commit/4ea50529e182703e064e0053d13c9e7953f0d201
Yes, glob
On 9/18/18 11:12 AM, Marcin Krol wrote:
On 18-Sep-18 09:23, glen wrote:
the same host, updated
wintersunset /etc/lighttpd # rpm -q glibc lighttpd; ls -l
/etc/lighttpd/vhosts.d/
glibc-2.28-3.x86_64
lighttpd-1.4.50-2.x86_64
total 0
wintersunset /etc/lighttpd #
so it's lighttpd behavior
On 18-Sep-18 09:23, glen wrote:
the same host, updated
wintersunset /etc/lighttpd # rpm -q glibc lighttpd; ls -l
/etc/lighttpd/vhosts.d/
glibc-2.28-3.x86_64
lighttpd-1.4.50-2.x86_64
total 0
wintersunset /etc/lighttpd #
so it's lighttpd behavior change.
Since 1.4.50 include_shell behavior
the same host, updated
wintersunset /etc/lighttpd # rpm -q glibc lighttpd; ls -l
/etc/lighttpd/vhosts.d/
glibc-2.28-3.x86_64
lighttpd-1.4.50-2.x86_64
total 0
wintersunset /etc/lighttpd #
so it's lighttpd behavior change.
On 9/18/18 9:15 AM, Elan Ruusamäe wrote:
on some other system, empty
on some other system, empty vhosts.d does not result such error as on carme:
wintersunset lighttpd/vhosts.d # rpm -q glibc lighttpd; ls -l
/etc/lighttpd/vhosts.d/
glibc-2.28-3.x86_64
lighttpd-1.4.49-3.x86_64
total 0
wintersunset lighttpd/vhosts.d # grep vhosts.d /etc/lighttpd/lighttpd.conf
On 17/09/2018 11:53, Arkadiusz Miśkiewicz wrote:
On 17/09/2018 00:24, Elan Ruusamäe wrote:
poldek:/all-avail> !sh -c '/sbin/service lighttpd configtest'
Checking Lighttpd Web Server
On 17/09/2018 00:24, Elan Ruusamäe wrote:
poldek:/all-avail> !sh -c '/sbin/service lighttpd configtest'
Checking Lighttpd Web Server
configuration[
FAIL ]
2018-09-17
On 14/09/2018 14:44, glen wrote:
should be merged to master if openssl 1.1 build for th is planned.
It's TODO item.
In meantime busy with rebuilds and patching.
--
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )
___
pld-devel-en mailing
On Tue, Sep 04, 2018 at 01:23:45PM +0200, Jan Palus wrote:
> On 02.09.2018 18:06, adamg wrote:
> > commit 21d43020dfd7dc915c941739408c48f91b9681f5
> > Author: Adam Gołębiowski
> > Date: Sun Sep 2 18:03:55 2018 +0200
> >
> > we don't provide vmxnet module, drop support for it
>
> I'm not
On 9/6/18 1:42 PM, glen wrote:
So it is just upgrading the package you want and glibc, not a big
issue.
services need to be restarted, especially ones using locale data. and
that means services need to be restarted, and it's a big issue here.
--
glen
On 9/6/18 11:59 AM, Jacek Konieczny wrote:
openssl upgrades are much more problematic.
openssl we have artificial dependency in pld because openssl library
tended to change symbols(?), and those were not versioned. probably git
blame to find detailed answer.
for example sslv3 drop would
On 9/6/18 11:59 AM, Jacek Konieczny wrote:
On 2018-09-06 10:50, glen wrote:
could we make not so often glibc upgrades in th?
at least keep builders glibc version low, so that built packages do not
require the latest and bleeding glibc SONAME symbols? (unless there's
actual benefit in that
On 2018-09-06 10:50, glen wrote:
> could we make not so often glibc upgrades in th?
>
> at least keep builders glibc version low, so that built packages do not
> require the latest and bleeding glibc SONAME symbols? (unless there's
> actual benefit in that package for newer glibc)
>
> it's very
On 9/6/18 11:56 AM, Arkadiusz Miśkiewicz wrote:
On 06/09/2018 10:50, glen wrote:
could we make not so often glibc upgrades in th?
glibc is released every ~6 months and that's not "often"
that's your opinion.
and what is often or not to one's system was not the question in the
original post.
On 06/09/2018 10:50, glen wrote:
could we make not so often glibc upgrades in th?
glibc is released every ~6 months and that's not "often"
--
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )
___
pld-devel-en mailing list
On 9/5/18 9:58 PM, Arkadiusz Miśkiewicz wrote:
On 05/09/2018 20:08, Elan Ruusamäe wrote:
More specifically, how the problem manifests?
http://buildlogs.pld-linux.org/index.php?dist=th=i686=0=php=941f6728-d625-428e-8926-c70fd96187c5=tail
on i686
+ PHP=./sapi/cli/php
On 05/09/2018 20:08, Elan Ruusamäe wrote:
More specifically, how the problem manifests?
http://buildlogs.pld-linux.org/index.php?dist=th=i686=0=php=941f6728-d625-428e-8926-c70fd96187c5=tail
on i686
--
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )
More specifically, how the problem manifests?
[root@blodnatt php73]# rpm -q php73-hash php73-mysqli; php73 -r
'mysqli_connect();'package php73-hash is not installed
php73-mysqli-7.3.0-0.beta3.1.x86_64
PHP Warning: mysqli_connect(): (HY000/2002): Connection refused in Command
line code on line 1
On 04/09/2018 21:23, Adam Osuchowski wrote:
Fixed. BTW, ChangeLog in 0.4.16 ended at 2015-11-26 09:21:44, 9 commits
before 0.4.16 commit, so it was already outdated in previous version.
Does anyone look at it?
changelog is created from git log.
have look at changelog.sh in repository
so you
701 - 800 of 6901 matches
Mail list logo
