- Jan 04, 2021
-
-
Simon McVittie authored
Signed-off-by: Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
The File::Glob module in Ubuntu 12.04 'precise', and therefore also Steam Runtime 1 'scout', doesn't support named keywords like this. Signed-off-by: Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by: Simon McVittie <smcv@collabora.com>
-
- Nov 25, 2020
-
-
Simon McVittie authored
I'm using Exherbo as an example of a host OS with an unusual layout that breaks libcapsule's assumptions. Tested in an x86_64 Docker container, but i386 is symmetrical and should also work. This also puts the framework in place to deal with other distributions' architecture-specific ld.so caches. Signed-off-by: Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This is mostly just a simplification; it also improves the error handling a little. Signed-off-by: Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Exherbo uses the traditional-cross-compilation-style prefix, /usr/<tuple>, which broke the tests' assumptions. Signed-off-by: Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This avoids worrying about which SONAME we're dealing with, and is maybe more common in smallish containers (in particular Exherbo's Docker container has it, which was useful for testing). Signed-off-by: Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
I'm using Exherbo as an example of a host OS with an unusual layout that breaks libcapsule's assumptions, in order to get the framework in place for being able to receive patches from other weirder host OSs. Signed-off-by: Simon McVittie <smcv@collabora.com>
-
- Nov 20, 2020
-
-
Simon McVittie authored
Signed-off-by: Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
The debug symbols for libcapsule-tools-relocatable would be the same as for libcapsule-tools, making them non-co-installable. Use the environment variable instead of --no-automatic-dbgsym for compatibility with Steam Runtime 1 'scout', which is too old to have that option. Signed-off-by: Simon McVittie <smcv@collabora.com>
-
Ludovico de Nittis authored
If you don't want to change the link target for all the symlinks that will be created, instead of using `--link-target`, it is now possible to use the new `--remap-link-prefix` and just list the directories that should be located under a different target. Signed-off-by: Ludovico de Nittis <ludovico.denittis@collabora.com>
-
Ludovico de Nittis authored
This can be used when we want to test some particular cases that we expect should not succeed. Signed-off-by: Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Oct 22, 2020
-
-
Simon McVittie authored
Signed-off-by: Simon McVittie <smcv@collabora.com>
-
- Oct 21, 2020
-
-
Ludovico de Nittis authored
If we have the CAPTURE_FLAG_IF_EXISTS option flag, we should not propagate an error if we are not able to find some dependencies of a library. Instead we should just skip it. This fixes an error that some users reported because they had some leftovers unused libraries in their system and libcapsule reported an error while trying to capture their (missing) dependencies. Signed-off-by: Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Sep 21, 2020
-
-
Simon McVittie authored
Signed-off-by: Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
If we `make dist` with gtk-doc-tools 1.28 from Debian 10 'buster' (the current stable release), it generates a libcapsule-docs.xml in which generation of tree_index.sgml is mandatory. This is incompatible with building this non-GObject library with gtk-doc-tools >= 1.30, in which tree_index.sgml is only generated if the library contains at least one GObject type. Most projects treat the libcapsule-docs.xml generated by gtk-doc as a template and commit it to git, but in this project we don't particularly want to maintain it and would prefer to keep regenerating it during build. Signed-off-by: Simon McVittie <smcv@collabora.com>
-
- Sep 08, 2020
-
-
Simon McVittie authored
Signed-off-by: Simon McVittie <smcv@collabora.com>
-
- Aug 27, 2020
-
-
Ludovico de Nittis authored
Signed-off-by: Ludovico de Nittis <ludovico.denittis@collabora.com>
-
Ludovico de Nittis authored
We are now able to list the symbol versions and/or symbols that are known to be public/private. This is especially useful for comparing libraries that removed symbol versions, or symbols, from one release to another. As this already happened multiple times in the past, like for example with `libdrm_nouveau.so.2` or `libedit.so.2`. Signed-off-by: Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Jul 08, 2020
-
-
Simon McVittie authored
Signed-off-by: Simon McVittie <smcv@collabora.com>
-
- Jul 07, 2020
-
-
Simon McVittie authored
This is mainly to give me a version number I can use in other packages' dependencies. Signed-off-by: Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by: Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This gives capsule-capture-libs a source of library-specific knowledge. For example, if we know that: * libgcc_s.so.1 is installed with an unhelpful name, but it uses versioned symbols the way you'd hope; * libdbus-1.so.3 is installed with a helpful libtool-style name, but has private symbols that defeat our current simplistic comparisons then we can express that as: [Library libgcc_s.so.1] CompareBy=versions;symbols; [Library libdbus-1.so.3] CompareBy=name; A runtime that contains a known set of libraries would be a good place to put library-specific knowledge about those libraries. For example, the maintainers of the Steam Runtime know what libraries it contains, and are well-placed to compare those libraries with their counterparts in mainstream distributions. Signed-off-by: Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by: Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This will let us select the comparator to use for individual libraries. Signed-off-by: Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by: Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by: Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Instead of asserting that the default behaviour is as desired, we now assert that --compare-by=versions,name,symbols behaves the way it ought to, and that the default behaviour is unchanged. It looks as though applying --compare-by=versions,name,symbols indiscriminately could break more than it fixes. Signed-off-by: Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This is primarily useful for testing and experimenting. Using versions by default in preference to filenames (--compare-by="versions,name") looks like it might be viable, but is a destabilising change that we should test more before considering a change of defaults. Meanwhile, counting symbols as a fallback (--compare-by="...,symbols") does not look as safe as we had hoped, because if a library maintainer has cleaned up their ABI by hiding private symbols without adding any new symbols, we will sort libraries in exactly the wrong order - and in reality, that seems to be what has happened in several libraries, for example libX11.so.6 and libXfixes.so.3. Signed-off-by: Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by: Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This is a piece of necessary infrastructure for exposing this as a command-line option, or even as per-library metadata. We were originally going to do the equivalent of "versions,name,symbols" unconditionally, but it looks as though that could break more than it fixes, so let's be a bit more cautious. Signed-off-by: Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
We can pass other state through this, such as the comparators to be used to compare libraries. Signed-off-by: Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by: Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
When two libraries have the same numeric tail we were not able to reliably determine which one was the newer. In particular, many distributions install libgcc_s.so.1 as a regular file, rather than a symlink to a versioned name, so library_cmp_by_name() can't work. These functions let us also check the library's version-definitions and the individual symbols, to make a more nuanced decision. Implementation originally by Ludovico de Nittis, adapted by Simon McVittie to fit the same signature as library_cmp_by_name() so that we can call the comparison functions via function pointers, to set up different comparison weights for each library if necessary. This version also includes Simon's changes to ignore uninteresting symbols for the purposes of library comparison, with a list of uninteresting symbols that are part of various architectures' ABIs, taken from dpkg-gensymbols. Co-authored-by: Ludovico de Nittis <ludovico.denittis@collabora.com> Signed-off-by: Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by: Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This will let us unit-test it more easily. While I'm moving it, re-indent it in libcapsule's coding style (4 rather than 2 space indents). Signed-off-by: Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Inspired by g_ptr_array_free(., FALSE) and g_bytes_unref_to_array(), this lets us convert a ptr_list into a raw array suitable for use with qsort() and bsearch(). Signed-off-by: Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This assumes either a C11 compiler, or as a fallback, a tolerably new version of gcc. Signed-off-by: Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964457 Signed-off-by: Simon McVittie <smcv@collabora.com>
-
- Jul 06, 2020
-
-
Simon McVittie authored
Signed-off-by: Simon McVittie <smcv@collabora.com>
-