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
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
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
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
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
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
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
