June 2018 - Dev - lists.clearlinux.org

by Sven Hartrumpf

Hi all. Does Clear Linux support running binaries for the x32 ABI? If I look at the following line # CONFIG_X86_X32 is not set in https://github.com/clearlinux-pkgs/linux-lts/blob/master/config , it seems to be disabled. For many applications, x32 clearly outperforms i386 and x86-64, e.g. (for functional programming): https://lists.gnu.org/archive/html/chicken-users/2015-09/msg00000.html https://sympa.inria.fr/sympa/arc/bigloo/2016-12/msg00015.html In the long run, also compiling x32 binaries could be an important performance option for Clear Linux. Ciao Sven

4 years, 4 months

3
8
0 0

[PATCH clr-bundles] os-installer: add xfsprogs-extras

by Miguel Bernal Marin

The new version of xfsprogs adds new systemd services and the binaries are stored in xfsprogs-extras. --- bundles/os-installer | 1 + 1 file changed, 1 insertion(+) diff --git a/bundles/os-installer b/bundles/os-installer index 8d53d02..6897d4c 100644 --- a/bundles/os-installer +++ b/bundles/os-installer @@ -27,3 +27,4 @@ python-urwid-python3 python3-core qemu-extras xfsprogs-bin +xfsprogs-extras -- 2.18.0

4 years, 11 months

3
2
0 0

Re: [Clr-dev] QT avx2 autospec changes

by Thiago Macieira

On Friday, 29 June 2018 05:13:47 PDT Victor Rodriguez wrote: > one of the things that i really like about CLR is the simplicity on > most of the spec files . One i see a spec with perl inside makes me > wonder if it was necesary. Can we move the logic to autospec and leave > the spec file as caln as possible ? That brings us to where this discussion started: where do I put this script? a) inside autospec, which adds it to the sources of the package and then uses during build b) in the os-clr-on-clr bundle, so it's available in /usr/bin during build (like avxjudge) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center

4 years, 11 months

1
0
0 0

Re: [Clr-dev] QT avx2 autospec changes

by Thiago Macieira

On Monday, 25 June 2018 10:27:08 PDT Douglas, William wrote: > Hi all, > > Looking at https://github.com/clearlinux/autospec/pull/175 we are > considering how to best integrate this kind of feature. Thiago brought > up the idea of a script that could do mv and could be generic for > different build systems that could live in autospec. I liked that idea > but does anybody have other thoughts or do they think the current > proposed patch is better for our needs? As you can see from the patch, the way to build a qmake-based package with AVX2 and have it install in /usr/lib64/haswell is hacky and very ugly. The mv solution would be neater and would allow me to do the same for plugins too. Another reason to do that is that many packages hardcode the library path you passed when configuring --libdir=/usr/lib64/haswell. This may or may not have side-effects we want. For example, if the software in package foo tried to find plugins or other architecture-specific files relative to $libdir, it would fail to find them in /usr/lib64/haswell/foo/bar.so. So letting this particular software be compiled with --libdir=/usr/lib64 and then move the library after installation would make it continue working. The counter-example are self-relocating libraries that read /proc/self/maps to find out where they are stored in the filesystem. If they are configured with --libdir=/usr/lib64 but find themselves at /usr/lib64/libfoo.so, they'd be confused. I think the latter case is very rare and therefore I suggest we start using the former. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center

4 years, 11 months

4
8
0 0

Re: [Clr-dev] QT avx2 autospec changes

by Thiago Macieira

On Thursday, 28 June 2018 20:48:04 PDT Victor Rodriguez wrote: > Did you check this patch? > > https://github.com/clearlinux-pkgs/python3/blob/master/avx2.patch#L62 I don't see how that is relevant, unless you're replying to another email, not to the problem of loading the same library multiple times. But I am doing the equivalent of that patch for Qt. See https://codereview.qt-project.org/232934 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center

4 years, 11 months

1
0
0 0

Re: [Clr-dev] QT avx2 autospec changes

by Thiago Macieira

On Thursday, 28 June 2018 15:14:37 PDT Victor Rodriguez wrote: > Linker will do that for you since versión 2.27. We knew that Yes, we did (and I think it's 2.26). We knew it searches the "haswell" subdir of all library search paths. But my proof shows that Samba isn't directly dlopen'ing this library, it's relying on the dynamic linker to do so by way of a DT_RUNPATH. Therefore, a generic solution to move the files into place needs to guess whether the library is linked to (→ dynamic linker finds it → haswell subdir) or whether it is dlopen'ed (→ append ".avx2" to the name). What happens if you dlopen a library? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center

4 years, 11 months

2
2
0 0

[PATCH clr-bundles] Add keychain utility to manage SSH and GPG agents

by Brett T. Warden

--- packages | 1 + 1 file changed, 1 insertion(+) diff --git a/packages b/packages index 9e533f5..8334980 100644 --- a/packages +++ b/packages @@ -33,6 +33,7 @@ iproute2 irssi joe jq +keychain libva-utils linux-dev linux-tools -- 2.18.0

4 years, 11 months

2
1
0 0

Re: [Clr-dev] QT avx2 autospec changes

by Thiago Macieira

On Tuesday, 26 June 2018 15:48:53 PDT Victor Rodriguez wrote: > > Now, the question is whether we should do this for other build types, > > notably > > for those with configure scripts. > > Do we have a list of those build types? Autospec sources and documentation. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center

4 years, 11 months

1
0
0 0

Re: [Clr-dev] QT avx2 autospec changes

by Thiago Macieira

On Tuesday, 26 June 2018 15:23:26 PDT Douglas, William wrote: > That looks pretty happy to me. Pull request updated. https://github.com/clearlinux/autospec/pull/175 Now, the question is whether we should do this for other build types, notably for those with configure scripts. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center

4 years, 11 months

2
1
0 0

Re: [Clr-dev] [PATCH CLR-BUNDLES] perl-extras: Removing duplicated perl-MIME-Base64

by Douglas

+1 On Tue, Jun 26, 2018 at 2:08 PM, Sonia Leon <sonia.leon.bautista(a)intel.com> wrote: > Package perl-MIME-Base64 is duplicated at lines 17 and 28 so this patch > is removing lastone. > --- > bundles/perl-extras | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/bundles/perl-extras b/bundles/perl-extras > index aa526ca..cc96238 100644 > --- a/bundles/perl-extras > +++ b/bundles/perl-extras > @@ -25,4 +25,3 @@ perl-List-SomeUtils-XS > perl-Test-Deep > perl-CPAN-Meta-Check > perl-Digest-CRC > -perl-MIME-Base64 > -- > 2.17.1 >

4 years, 11 months

1
0
0 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

Dev June 2018