[pacman-dev] [PATCH] pacman-key: warn about time take for master key generation
Generating the pacman master key can take some time on systems
without enough entropy. Warn the user that the generation may
take some time.
Fixes FS#30286.
Signed-off-by: Allan McRae
---
scripts/pacman-key.sh.in | 2 ++
1 file changed, 2 insertions(+)
diff --git a/scripts/pacman-key.sh.in b/scripts/pacman-key.sh.in
index ccfd1b96..59162840 100644
--- a/scripts/pacman-key.sh.in
+++ b/scripts/pacman-key.sh.in
@@ -145,6 +145,8 @@ key_lookup_from_name() {
generate_master_key() {
# Generate the master key, which will be in both pubring and secring
+ msg "$(gettext "Generating pacman master key. This may take some time.")
+
"${GPG_PACMAN[@]}" --gen-key --batch <
[pacman-dev] [GIT] The official pacman repository branch, master, updated. v6.0.0alpha1-26-ga023565e
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "The official pacman repository". The branch, master has been updated via a023565ed370851fd5bf61298460fe0adb0b4189 (commit) via ccdd1e3fd92591755e2b94bf63416c7b30cd217a (commit) via 831fc568fc87a75bb6e05575b93a7541b49e7aba (commit) from 95ffdd68b250af1d37067fe6dd70fc6a6094bc62 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit a023565ed370851fd5bf61298460fe0adb0b4189 Author: Eli Schwartz Date: Mon Dec 28 21:36:35 2020 -0500 doc: make doxygen build from any directory In the autotools build, it only built in-tree, from cwd = doc/ and resolving doc/../lib/libalpm In the meson build, this accidentally worked if cwd = pacman/builddir/ and resolved to builddir/../lib/libalpm/ But... this should always have been configured with the actual path to the inputs. So, we will now proceed to do so. Fixes building man3 if your out of tree builddir doesn't happen to be a direct subdirectory of the source root. Signed-off-by: Eli Schwartz Signed-off-by: Allan McRae commit ccdd1e3fd92591755e2b94bf63416c7b30cd217a Author: Emil Velikov Date: Wed Dec 23 22:43:57 2020 + Move hex_representation() to src/common We'll reuse the function in pacman with a later commit. Signed-off-by: Emil Velikov Signed-off-by: Allan McRae commit 831fc568fc87a75bb6e05575b93a7541b49e7aba Author: Emil Velikov Date: Wed Dec 23 22:43:56 2020 + Remove pre libarchive 3.0 code Pacman has required libarchive 3.0 or later for quite some time mow. Signed-off-by: Emil Velikov Signed-off-by: Allan McRae --- Summary of changes: doc/Doxyfile.in | 4 ++-- doc/meson.build | 1 + lib/libalpm/libarchive-compat.h | 20 lib/libalpm/util.c | 24 src/common/util-common.c| 26 ++ src/common/util-common.h| 1 + 6 files changed, 30 insertions(+), 46 deletions(-) hooks/post-receive -- The official pacman repository
Re: [pacman-dev] [PATCH 3/3] meson: use hidden symbol visiblity by default
On 25/12/20 2:05 am, Emil Velikov wrote:
> On Thu, 24 Dec 2020 at 01:38, Eli Schwartz wrote:
>>
>> On 12/23/20 5:42 PM, Emil Velikov wrote:
>>> All the required public API is annotated with SYMEXPORT, so we can just
>>> add the meson notation, to hide all the symbols by default.
>>>
>>> Thus we no longer spill all the internal API into the global namespace.
>> Thanks for noticing this... it's a regression from autotools, which
>> contained in lib/libalpm/Makefile.am:
>>
>> if ENABLE_VISIBILITY_CC
>> if DARWIN
>> AM_CFLAGS += -fvisibility=hidden
>> else
>> AM_CFLAGS += -fvisibility=internal
>> endif
>> endif
>>
>>
>> I wonder if we had a good reason to use "internal" and if we should
>> continue to do so? IIUC it makes it slightly more optimized at the cost
>> of allowing pointers into private functions (e.g. callbacks) used by
>> other programs to segfault.
>>
> If the output of size is any indication - there is little-to-no
> optimisation happening.
> The former produces the same numbers, while the latter claims that
> binaries built with "internal" are larger by 8 bytes (always).
>
> Fwiw the above snippet is the first time I've seen anyone using
> "internal", after staring at various projects for 5+ years.
> Can bring it back, simply not sure it brings much.
>
> Thanks
> Emil
>
> $ ls
> 812336 build-internal/libalpm.so.12.0.1
> 812328 build-hidden/libalpm.so.12.0.1
> 337176 build-internal/pacman
> 337168 build-hidden/pacman
>
> $ size
> 3167083080 592 320380 4e37c build-internal/libalpm.so.12.0.1
> 3167083080 592 320380 4e37c build-hidden/libalpm.so.12.0.1
> 15528850405808 166136 288f8 build-internal/pacman
> 15528850405808 166136 288f8 build-hidden/pacman
>
It turns out, we have this:
#define SYMHIDDEN __attribute__((visibility("internal")))
But we never flag any functions with this. That would enable a compiler
to optimize for speed and not compatibility, in which case using
-fvisibility=internal would make a difference.
I'm not sure if we removed any usage of that from the codebase, or if it
was never there...
Allan
Re: [pacman-dev] [PATCH 3/3] pacman: add file checksum validation against mtree
On 24/12/20 8:43 am, Emil Velikov wrote:
> With libarchive v3.5.0 we have API to fetch the digest from the mtree.
> Use that to validate if the installed files are modified or not.
>
> As always, a modified backup file will trigger a warning but will not
> result in an actual failure.
>
> TODO: localization... no idea how that is even done :-)
Adding the _() around the strings is all that needed done.
> NOTE: indentation is likely all over the place - first time I see ts=2
For line wraps, we generally just use two indents, so really does not
matter what the tab system is.
> Signed-off-by: Emil Velikov
> ---
> src/pacman/check.c | 66 +-
> 1 file changed, 59 insertions(+), 7 deletions(-)
>
> diff --git a/src/pacman/check.c b/src/pacman/check.c
> index 02217d0f..083c547d 100644
> --- a/src/pacman/check.c
> +++ b/src/pacman/check.c
> @@ -176,19 +176,70 @@ static int check_file_size(const char *pkgname, const
> char *filepath,
> return 0;
> }
>
> -/* placeholders - libarchive currently does not read checksums from mtree
> files
> -static int check_file_md5sum(const char *pkgname, const char *filepath,
> - struct stat *st, struct archive_entry *entry, int backup)
> +#if ARCHIVE_VERSION_NUMBER >= 3005000
This does not need wrapped in #if. There is nothing libarchive specific
in this function.
> +static int check_file_cksum(const char *pkgname, const char *filepath,
> + int backup, const char *cksum_name, const char *cksum_calc,
> const char *cksum_mtree)
> {
> + if(!cksum_calc || !cksum_mtree) {
Only one of these failures matches the error message. Split into
"checkusm information not available" and "failed to calculate checksum"
> + if(!config->quiet) {
> + pm_printf(ALPM_LOG_WARNING, _("%s: %s (failed to
> compute %s checksum)\n"),
> + pkgname, filepath, cksum_name);
> + }
> + return 1;
> + }
> +
> + if(strcmp(cksum_calc, cksum_mtree) != 0) {
> + if(backup) {
> + if(!config->quiet) {
> + printf("%s%s%s: ", config->colstr.title,
> _("backup file"),
> + config->colstr.nocolor);
> + printf(_("%s: %s (%s checksum mismatch)\n"),
> + pkgname, filepath, cksum_name);
> + }
> + return 0;
> + }
> + if(!config->quiet) {
> + pm_printf(ALPM_LOG_WARNING, _("%s: %s (%s checksum
> mismatch)\n"),
> + pkgname, filepath, cksum_name);
> + }
> + return 1;
OK.
> + }
> +
> return 0;
> }
> +#endif
> +
> +static int check_file_md5sum(const char *pkgname, const char *filepath,
> + struct archive_entry *entry, int backup)
> +{
> + int errors = 0;
> +#if ARCHIVE_VERSION_NUMBER >= 3005000
> + char *cksum_calc = alpm_compute_md5sum(filepath);
> + char *cksum_mtree = hex_representation(archive_entry_digest(entry,
> +
> ARCHIVE_ENTRY_DIGEST_MD5), 16);
> + errors = check_file_cksum(pkgname, filepath, backup, "MD5", cksum_calc,
> +
> cksum_mtree);
> + free(cksum_mtree);
> + free(cksum_calc);
> +#endif
> + return (errors != 0 ? 1 : 0);
> +}
>
> static int check_file_sha256sum(const char *pkgname, const char *filepath,
> - struct stat *st, struct archive_entry *entry, int backup)
> + struct archive_entry *entry, int backup)
> {
> - return 0;
> + int errors = 0;
> +#if ARCHIVE_VERSION_NUMBER >= 3005000
> + char *cksum_calc = alpm_compute_sha256sum(filepath);
> + char *cksum_mtree = hex_representation(archive_entry_digest(entry,
> +
> ARCHIVE_ENTRY_DIGEST_SHA256), 32);
> + errors = check_file_cksum(pkgname, filepath, backup, "SHA256",
> cksum_calc,
> +
> cksum_mtree);
> + free(cksum_mtree);
> + free(cksum_calc);
> +#endif
> + return (errors != 0 ? 1 : 0);
> }
> -*/
>
> /* Loop through the files of the package to check if they exist. */
> int check_pkg_fast(alpm_pkg_t *pkg)
> @@ -369,7 +420,8 @@ int check_pkg_full(alpm_pkg_t *pkg)
>
> if(type == AE_IFREG) {
> file_errors += check_file_size(pkgname, filepath, ,
> entry, backup);
> - /* file_errors += check_file_md5sum(pkgname, filepath,
> , entry, backup); */
> + file_errors += check_file_md5sum(pkgname, filepath,
> entry, backup);
> +
Re: [pacman-dev] [PATCH 1/3] Remove pre libarchive 3.0 code
On 24/12/20 8:43 am, Emil Velikov wrote: > Pacman has required libarchive 3.0 or later for quite some time mow. > > Signed-off-by: Emil Velikov > --- > lib/libalpm/libarchive-compat.h | 20 > 1 file changed, 20 deletions(-) > Looks good.
Re: [pacman-dev] [PATCH 1/2] libalpm: const annotate struct pkg_operations
On 24/12/20 8:41 am, Emil Velikov wrote:
> Signed-off-by: Emil Velikov
> ---
This patch does a lot more than just add const annotations. And it
looks to me like the extra bit needs justification, so separate patch
please.
> lib/libalpm/be_local.c | 2 +-
> lib/libalpm/be_package.c | 2 +-
> lib/libalpm/be_sync.c| 20 ++--
> lib/libalpm/package.c| 2 +-
> lib/libalpm/package.h| 4 ++--
> 5 files changed, 23 insertions(+), 7 deletions(-)
>
> diff --git a/lib/libalpm/be_local.c b/lib/libalpm/be_local.c
> index e73a97bb..9c3c8bb3 100644
> --- a/lib/libalpm/be_local.c
> +++ b/lib/libalpm/be_local.c
> @@ -326,7 +326,7 @@ static int _cache_force_load(alpm_pkg_t *pkg)
> * lazy accessor methods that handle any backend loading and caching
> * logic.
> */
> -static struct pkg_operations local_pkg_ops = {
> +static const struct pkg_operations local_pkg_ops = {
> .get_base = _cache_get_base,
> .get_desc = _cache_get_desc,
> .get_url = _cache_get_url,
> diff --git a/lib/libalpm/be_package.c b/lib/libalpm/be_package.c
> index 4dde7167..f855003a 100644
> --- a/lib/libalpm/be_package.c
> +++ b/lib/libalpm/be_package.c
> @@ -138,7 +138,7 @@ static int _package_changelog_close(const alpm_pkg_t
> UNUSED *pkg, void *fp)
> * majority of the default_pkg_ops struct and add only a few operations of
> * our own on top.
> */
> -static struct pkg_operations *get_file_pkg_ops(void)
> +static const struct pkg_operations *get_file_pkg_ops(void)
> {
> static struct pkg_operations file_pkg_ops;
> static int file_pkg_ops_initialized = 0;
> diff --git a/lib/libalpm/be_sync.c b/lib/libalpm/be_sync.c
> index 225df76d..5356b544 100644
> --- a/lib/libalpm/be_sync.c
> +++ b/lib/libalpm/be_sync.c
> @@ -281,6 +281,23 @@ static int _sync_get_validation(alpm_pkg_t *pkg)
> return pkg->validation;
> }
>
> +/** Package sync operations struct accessor. We implement this as a method
> + * rather than a static struct as in be_files because we want to reuse the
> + * majority of the default_pkg_ops struct and add only a few operations of
> + * our own on top.
> + */
> +static const struct pkg_operations *get_sync_pkg_ops(void)
> +{
> + static struct pkg_operations sync_pkg_ops;
> + static int sync_pkg_ops_initalized = 0;
> + if(!sync_pkg_ops_initalized) {
> + sync_pkg_ops = default_pkg_ops;
> + sync_pkg_ops.get_validation = _sync_get_validation;
> + sync_pkg_ops_initalized = 1;
> + }
> + return _pkg_ops;
> +}
> +
> static alpm_pkg_t *load_pkg_for_entry(alpm_db_t *db, const char *entryname,
> const char **entry_filename, alpm_pkg_t *likely_pkg)
> {
> @@ -321,8 +338,7 @@ static alpm_pkg_t *load_pkg_for_entry(alpm_db_t *db,
> const char *entryname,
>
> pkg->origin = ALPM_PKG_FROM_SYNCDB;
> pkg->origin_data.db = db;
> - pkg->ops = _pkg_ops;
> - pkg->ops->get_validation = _sync_get_validation;
> + pkg->ops = get_sync_pkg_ops();
> pkg->handle = db->handle;
>
> /* add to the collection */
> diff --git a/lib/libalpm/package.c b/lib/libalpm/package.c
> index a4356518..5766c600 100644
> --- a/lib/libalpm/package.c
> +++ b/lib/libalpm/package.c
> @@ -138,7 +138,7 @@ static int _pkg_force_load(alpm_pkg_t UNUSED *pkg) {
> return 0; }
> /** The standard package operations struct. Get fields directly from the
> * struct itself with no abstraction layer or any type of lazy loading.
> */
> -struct pkg_operations default_pkg_ops = {
> +const struct pkg_operations default_pkg_ops = {
> .get_base= _pkg_get_base,
> .get_desc= _pkg_get_desc,
> .get_url = _pkg_get_url,
> diff --git a/lib/libalpm/package.h b/lib/libalpm/package.h
> index c37bd11e..b134ad5a 100644
> --- a/lib/libalpm/package.h
> +++ b/lib/libalpm/package.h
> @@ -83,7 +83,7 @@ struct pkg_operations {
> * The actual definition is in package.c so it can have access to the
> * default accessor functions which are defined there.
> */
> -extern struct pkg_operations default_pkg_ops;
> +extern const struct pkg_operations default_pkg_ops;
>
> struct __alpm_pkg_t {
> unsigned long name_hash;
> @@ -121,7 +121,7 @@ struct __alpm_pkg_t {
> alpm_list_t *removes; /* in transaction targets only */
> alpm_pkg_t *oldpkg; /* in transaction targets only */
>
> - struct pkg_operations *ops;
> + const struct pkg_operations *ops;
>
> alpm_filelist_t files;
>
>
[pacman-dev] [GIT] The official pacman repository branch, master, updated. v6.0.0alpha1-23-g95ffdd68
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "The official pacman repository". The branch, master has been updated via 95ffdd68b250af1d37067fe6dd70fc6a6094bc62 (commit) via e67c306f9199fe1fc5e2c82dcaf3ede851a1689c (commit) via ea975c328da8ebae2e13b8ce5c75c319fa3c4ef9 (commit) via 50c9c338fbbdc895484ccaf4043187c56fc8687b (commit) via 6ed82820fe3994c0375c4981be7978c0ba54727a (commit) via 1e8816f13d651997034252d87fba51cd38118f51 (commit) via 2a16434bfd20cc55e554018f5a34870dbca09673 (commit) via 4613527738ce428f2bc8e2b9bc404a1f662d5d99 (commit) via 7b06b5407baffc3895e0861241a048048b6c5788 (commit) via 50d2171ef0a77e0d967195046867adc80ed3efcb (commit) via a321e1f8a539097cf797b21bf69178a71edb9b12 (commit) via 3d60a829e1d3e16116dea1032a3ab1365e471c8c (commit) via 5901ac9cb27595a36edc7b818b94c3fa0271f37e (commit) via af7a1e834f262a24d6ed5eea472ac45830ab1229 (commit) via 55efa43f2305801640f8312e9d494856b8a0a781 (commit) via e9ac13776e7a1aa5899cfdc9a4233d84835c094f (commit) via bf26b6bbf7ee83211c3bcbb5fca05e6aef48b18a (commit) via 5e9635317b46d908f482128e8db63ccdae04aa28 (commit) via ab431f6810ed49045a95fe232cd678d39708fc02 (commit) via 49e33aad7c848c06ca276c71f2db5c057a129178 (commit) via 48c8869339e739b44e0195ded69f1bdc8695b888 (commit) via 48865e7dac673648b8fb96f4cfa2b2994b597983 (commit) from 11e09a23beb89c3b7bf06209a317a4b6ac75ee38 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit 95ffdd68b250af1d37067fe6dd70fc6a6094bc62 Author: morganamilo Date: Mon Dec 7 22:19:56 2020 + doc: remove old libalpm man file Signed-off-by: Allan McRae commit e67c306f9199fe1fc5e2c82dcaf3ede851a1689c Author: morganamilo Date: Mon Dec 7 22:19:54 2020 + doc: add extra documentation to the man page Signed-off-by: Allan McRae commit ea975c328da8ebae2e13b8ce5c75c319fa3c4ef9 Author: morganamilo Date: Mon Dec 7 22:19:53 2020 + doc: rename alpm_api group to alpm Signed-off-by: Allan McRae commit 50c9c338fbbdc895484ccaf4043187c56fc8687b Author: morganamilo Date: Mon Dec 7 22:19:52 2020 + doc: update doxyfile Signed-off-by: Allan McRae commit 6ed82820fe3994c0375c4981be7978c0ba54727a Author: morganamilo Date: Mon Dec 7 22:19:51 2020 + doc: configure doxygen - only document public alpm items (alpm_*) - hide typedef'd structs (_alpm_pkg_t shows as alpm_pkg_t) - enable inline struct definitions (this stops having a man page for every single struct) Signed-off-by: Allan McRae commit 1e8816f13d651997034252d87fba51cd38118f51 Author: morganamilo Date: Mon Dec 7 22:19:50 2020 + doc: move top level items into groups Signed-off-by: Allan McRae commit 2a16434bfd20cc55e554018f5a34870dbca09673 Author: morganamilo Date: Mon Dec 7 22:19:49 2020 + doc: move alpm_api group to top of file Signed-off-by: Allan McRae commit 4613527738ce428f2bc8e2b9bc404a1f662d5d99 Author: morganamilo Date: Mon Dec 7 22:19:48 2020 + doc: document options Signed-off-by: Allan McRae commit 7b06b5407baffc3895e0861241a048048b6c5788 Author: morganamilo Date: Mon Dec 7 22:19:47 2020 + doc: document alpm_list Signed-off-by: Allan McRae commit 50d2171ef0a77e0d967195046867adc80ed3efcb Author: morganamilo Date: Mon Dec 7 22:19:46 2020 + doc: document misc Signed-off-by: Allan McRae commit a321e1f8a539097cf797b21bf69178a71edb9b12 Author: morganamilo Date: Mon Dec 7 22:19:45 2020 + doc: document transactions Signed-off-by: Allan McRae commit 3d60a829e1d3e16116dea1032a3ab1365e471c8c Author: morganamilo Date: Mon Dec 7 22:19:44 2020 + doc: document files and groups Signed-off-by: Allan McRae commit 5901ac9cb27595a36edc7b818b94c3fa0271f37e Author: morganamilo Date: Mon Dec 7 22:19:43 2020 + doc: document packages Signed-off-by: Allan McRae commit af7a1e834f262a24d6ed5eea472ac45830ab1229 Author: morganamilo Date: Mon Dec 7 22:19:42 2020 + doc: document logging Signed-off-by: Allan McRae commit 55efa43f2305801640f8312e9d494856b8a0a781 Author: morganamilo Date: Mon Dec 7 22:19:41 2020 + doc: document databases Signed-off-by: Allan McRae commit e9ac13776e7a1aa5899cfdc9a4233d84835c094f Author: morganamilo Date: Mon Dec 7 22:19:40 2020 + doc: document callbacks Signed-off-by: Allan McRae commit bf26b6bbf7ee83211c3bcbb5fca05e
Re: [pacman-dev] [PATCH 22/23] doc: change group names to libalpm_*
On 8/12/20 8:19 am, morganamilo wrote:
> Also change the group's title to point to the group's man page.
>
> This makes generated man pages be named libalpm_* which is more
> consistent with what library man pages are usually called.
> ---
I have applied all patches up to this point. Bit confiused about a
section below:
> doc/meson.build | 1 -
> lib/libalpm/alpm.h | 80 +
> lib/libalpm/alpm_list.h | 22 ++--
> 3 files changed, 53 insertions(+), 50 deletions(-)
>
> diff --git a/doc/meson.build b/doc/meson.build
> index e24172fd..570dc765 100644
> --- a/doc/meson.build
> +++ b/doc/meson.build
> @@ -9,7 +9,6 @@ manpages = [
>{ 'name': 'PKGBUILD.5', 'extra_depends' : [ 'PKGBUILD-example.txt' ] },
>{ 'name': 'makepkg.conf.5' },
>{ 'name': 'pacman.conf.5' },
> - { 'name': 'libalpm.3' },
>{ 'name': 'BUILDINFO.5' },
>{ 'name': 'pacman-conf.8' },
> ]
> diff --git a/lib/libalpm/alpm.h b/lib/libalpm/alpm.h
> index b2772f19..dd28b191 100644
> --- a/lib/libalpm/alpm.h
> +++ b/lib/libalpm/alpm.h
> @@ -21,13 +21,6 @@
> * along with this program. If not, see <http://www.gnu.org/licenses/>.
> */
>
> -/**
> - * @file alpm.h
> - * @author Pacman Development Team
> - * @date 7 Dec 2020
> - * @brief Arch Linux Package Manager Library
> - */
> -
> /** @mainpage alpm
> *
> * libalpm is a package management library, primaraly used by pacman.
> @@ -50,14 +43,41 @@ extern "C" {
>
> #include
>
> -/** @addtogroup alpm The libalpm Public API
> +/** @addtogroup libalpm The libalpm Public API
> + *
> + *
> + * libalpm is a package management library, primaraly used by pacman.
> + *
> + * For ease of access, the libalpm manual has been split up into several
> sections.
> *
> - * @section see_also See Also
> - * \b alpm_list(3),
> + * @section bugs Bugs
> + * Bugs? You must be kidding; there are no bugs in this software. But if we
> happen to be wrong,
> + * submit a bug report with as much detail as possible at the Arch Linux Bug
> Tracker in the
> + * Pacman section.
> + *
> + * @section see_also See also
> + * \b libalpm-list(3),
> * \b alpm-hooks(5),
> * \b makepkg(8),
> - * \b pacman(8),
> - * \b pacman.conf(5)
> + *
There seems to be a lot of duplication from our footer.asciidoc here. Why?
> + * @section maintainers Maintainers
> + * Current maintainers:
> + *
> + * - Allan McRae
> + * - Andrew Gregory
> + * - Dave Reisner
> + * - Eli Schwartz
> + *
> + * Past major contributors:
> + *
> + * - Judd Vinet
> + * - Aurelien Foret
> + * - Aaron Griffin
> + * - Dan McGee
> + * - Xavier Chantry
> + * - Nagy Gabor
> + *
> + * For additional contributors, use git shortlog -s on the pacman.git
> repository.
> * @{
> */
>
> @@ -68,7 +88,7 @@ extern "C" {
> /** The libalpm context handle.
> *
> * This struct represents an instance of libalpm.
> - * @ingroup alpm_handle
> + * @ingroup libalpm-handle
> */
> typedef struct __alpm_handle_t alpm_handle_t;
>
> @@ -88,7 +108,7 @@ typedef struct __alpm_handle_t alpm_handle_t;
> * the user. They will be freed when the database is unregistered.
> *
> * Databases are automatically unregistered when the \link alpm_handle_t
> \endlink is released.
> - * @ingroup alpm_databases
> + * @ingroup libalpm-databases
> */
> typedef struct __alpm_db_t alpm_db_t;
>
> @@ -101,21 +121,21 @@ typedef struct __alpm_db_t alpm_db_t;
> *
> * Packages can then be queried for metadata or added to a \link
> alpm_trans_t transaction \endlink
> * to be added or removed from the system.
> - * @ingroup alpm_packages
> + * @ingroup libalpm-packages
> */
> typedef struct __alpm_pkg_t alpm_pkg_t;
>
> /** Transaction structure used internally by libalpm
> - * @ingroup alpm_trans
> + * @ingroup libalpm-trans
> * */
> typedef struct __alpm_trans_t alpm_trans_t;
>
>
> /** The time type used by libalpm. Represents a unix time stamp
> - * @ingroup alpm_misc */
> + * @ingroup libalpm-misc */
> typedef int64_t alpm_time_t;
>
> -/** @addtogroup alpm_files Files
> +/** @addtogroup libalpm-files libalpm-files(3)
> * @brief Functions for package files
> * @{
> */
> @@ -160,7 +180,7 @@ alpm_file_t *alpm_filelist_contains(alpm_filelist_t
> *filelist, const char *path)
> /** @} */
>
>
> -/** @addtogroup alpm_groups Groups
> +/** @addtogroup libalpm-groups libalpm-groups(3)
> * @brief Functions for package groups
> * @{
> */
> @@ -186,7 +206,7 @@ alpm_list_t *alpm_find_group_pkgs(alp
[pacman-dev] [GIT] The official pacman repository branch, master, updated. v6.0.0alpha1-1-g11e09a23
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "The official pacman repository". The branch, master has been updated via 11e09a23beb89c3b7bf06209a317a4b6ac75ee38 (commit) from a4240a55e448ffba15a5edbad1a31cb76f821231 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit 11e09a23beb89c3b7bf06209a317a4b6ac75ee38 Author: Anatol Pomozov Date: Tue Dec 8 11:57:27 2020 -0800 Implement TotalDownload functionality With the recent 'multibar' interface changes TotalDownload has been disabled. Now we have a new UI and we need to find another way to display this information. When 'TotalDownload' config option is enabled we are going to have an extra progress bar at the bottom of the screen that shows how much of the entire download has been completed. Closes FS#68202 Signed-off-by: Anatol Pomozov Signed-off-by: Allan McRae --- Summary of changes: doc/pacman.conf.5.asciidoc | 6 +- lib/libalpm/sync.c | 5 -- src/pacman/callback.c | 146 - 3 files changed, 106 insertions(+), 51 deletions(-) hooks/post-receive -- The official pacman repository
Re: [pacman-dev] [PATCH] Add --confirm
On 7/12/20 7:21 pm, morganamilo wrote:
> this is useful for cancelling the automatically passed --noconfirm
> by makechrootpkg
Please explain why I should care what makechrootpkg does?
>
> diff --git a/doc/makepkg.8.asciidoc b/doc/makepkg.8.asciidoc
> index 3b5e61b3..b3ecbe12 100644
> --- a/doc/makepkg.8.asciidoc
> +++ b/doc/makepkg.8.asciidoc
> @@ -184,6 +184,9 @@ Options
> (Passed to pacman) Prevent pacman from waiting for user input before
> proceeding with operations.
>
> +*\--confirm*::
> + Cancels the effects of a previous --noconfirm.
> +
> *\--needed*::
> (Passed to pacman) Tell pacman not to reinstall a target if it is
> already
> up-to-date. (used with '-i' / '\--install').
> diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in
> index b39433f3..1c8e8a0e 100644
> --- a/scripts/makepkg.sh.in
> +++ b/scripts/makepkg.sh.in
> @@ -997,6 +997,7 @@ usage() {
> printf -- "$(gettext " --asdeps Install packages as
> non-explicitly installed")\n"
> printf -- "$(gettext " --needed Do not reinstall the targets
> that are already up to date")\n"
> printf -- "$(gettext " --noconfirm Do not ask for confirmation
> when resolving dependencies")\n"
> + printf -- "$(gettext " --confirmCancels the effects of a
> previous --noconfirm")\n"
> printf -- "$(gettext " --noprogressbar Do not show a progress bar
> when downloading files")\n"
> echo
> printf -- "$(gettext "If %s is not specified, %s will look for
> '%s'")\n" "-p" "makepkg" "$BUILDSCRIPT"
> @@ -1036,7 +1037,7 @@ OPT_LONG=('allsource' 'check' 'clean' 'cleanbuild'
> 'config:' 'force' 'geninteg'
>'skippgpcheck' 'source' 'syncdeps' 'verifysource' 'version')
>
> # Pacman Options
> -OPT_LONG+=('asdeps' 'noconfirm' 'needed' 'noprogressbar')
> +OPT_LONG+=('asdeps' 'confirm' 'noconfirm' 'needed' 'noprogressbar')
>
> if ! parseopts "$OPT_SHORT" "${OPT_LONG[@]}" -- "$@"; then
> exit $E_INVALID_OPTION
> @@ -1050,6 +1051,7 @@ while true; do
> --asdeps) ASDEPS=1;;
> --needed) NEEDED=1;;
> --noconfirm) PACMAN_OPTS+=("--noconfirm") ;;
> + --confirm)PACMAN_OPTS+=("--confirm") ;;
> --noprogressbar) PACMAN_OPTS+=("--noprogressbar") ;;
>
> # Makepkg Options
>
Re: [pacman-dev] Remove skipped warning message for already installed packages when --needed is specified?
On 7/12/20 5:05 am, Daan De Meyer wrote: > Hi, > > I recently added --needed to pacman's invocation in mkosi but noticed > that even when --needed is specified, pacman still prints warning > messages for packages that it's skipping because they are already > installed. My intuition was that by enabling --needed, I was > explicitly telling pacman that there might be packages that are > already installed in the packages that I'm installing and that I want > to skip those and not be warned about them. The skipping works fine > but I still get warnings. Would it make sense to remove the skipped > warning message for packages that are already installed when --needed > is specified since the user is explicitly requesting this behavior? > I'm on the fence here. You have explicitly asked for packages to be installed by providing them on the command line, but then --needed says they don't need installed. That does seem warning-ish to me. Allan
Re: [pacman-dev] Alternatives system
On 7/12/20 3:03 am, Lone_Wolf wrote: > > On 01-04-2019 01:56, Allan McRae wrote: >> Hi all, >> >> I plan to finish implementing an alternatives system for pacman post 5.2 >> release: >> https://wiki.archlinux.org/index.php/User:Allan/Alternatives >> >> Any comments or suggestions? >> >> Thanks, >> Allan > > > pacman 6 .0 alpha has been released, but there's no sign of an > alternatives system I can find. > > > The descriptions suggest the alternatives system could improve at least > one of my aur packages by a lot. > > Is an alternatives system still on the roadmap ? > It is on the roadmap. Unlikely for 6.0, unless I feel motivated over the upcoming holiday season. Allan
Re: [pacman-dev] [PATCH] Implement TotalDownload functionality
On 6/12/20 4:39 am, Anatol Pomozov wrote:
> With the recent 'multibar' interface changes TotalDownload has been disabled.
> Now we have a new UI and we need to find another way to display this
> information.
>
> When 'TotalDownload' config option is enabled we are going to have an extra
> progress bar at the bottom of the screen that shows how much of the entire
> download has been completed.
>
> Closes FS#68202
Thanks - that progress bar looks good.
>
> Signed-off-by: Anatol Pomozov
> ---
> doc/pacman.conf.5.asciidoc | 6 +--
> lib/libalpm/sync.c | 5 --
> src/pacman/callback.c | 108 -
> 3 files changed, 96 insertions(+), 23 deletions(-)
>
> diff --git a/doc/pacman.conf.5.asciidoc b/doc/pacman.conf.5.asciidoc
> index dd1d3d5e..32612eb9 100644
> --- a/doc/pacman.conf.5.asciidoc
> +++ b/doc/pacman.conf.5.asciidoc
> @@ -191,10 +191,8 @@ Options
> not support escape characters.
>
> *TotalDownload*::
> - When downloading, display the amount downloaded, download rate, ETA,
> - and completed percentage of the entire download list rather
> - than the percent of each individual download target. The progress
> - bar is still based solely on the current file download.
> + When downloading, display an extra progress bar with the amount
> downloaded,
> + download rate, ETA, and completed percentage of the entire download
> list.
> This option won't work if XferCommand is used.
OK.
>
> *CheckSpace*::
> diff --git a/lib/libalpm/sync.c b/lib/libalpm/sync.c
> index 5d8652a5..e25e56d4 100644
> --- a/lib/libalpm/sync.c
> +++ b/lib/libalpm/sync.c
> @@ -846,11 +846,6 @@ finish:
> pkg->download_size = 0;
> }
>
> - /* clear out value to let callback know we are done */
> - if(handle->totaldlcb) {
> - handle->totaldlcb(0);
> - }
> -
OK.
> return ret;
> }
>
> diff --git a/src/pacman/callback.c b/src/pacman/callback.c
> index 12ab952f..49bc3df4 100644
> --- a/src/pacman/callback.c
> +++ b/src/pacman/callback.c
> @@ -40,8 +40,9 @@
> #include "conf.h"
>
> /* download progress bar */
> -static off_t list_xfered = 0.0;
Appears that should have been cleaned up a while ago?
> +static int total_enabled = 0;
> static off_t list_total = 0.0;
> +static struct pacman_progress_bar *totalbar;
>
OK
> /* delayed output during progress bar */
> static int on_progress = 0;
> @@ -92,6 +93,10 @@ struct pacman_multibar_ui {
>
> struct pacman_multibar_ui multibar_ui = {0};
>
> +static int dload_progressbar_enabled(void);
> +static void init_total_progressbar(void);
> +static void update_total_finalstats(void);
> +
Why do these need forward declared? Just to avoid moving code around in
the file?
> void multibar_move_completed_up(bool value) {
> multibar_ui.move_completed_up = value;
> }
> @@ -327,6 +332,10 @@ void cb_event(alpm_event_t *event)
> case ALPM_EVENT_PKG_RETRIEVE_START:
> colon_printf(_("Retrieving packages...\n"));
> on_progress = 1;
> + total_enabled = config->totaldownload && list_total;
> + if(total_enabled) {
> + init_total_progressbar();
> + }
OK
> break;
> case ALPM_EVENT_DISKSPACE_START:
> if(config->noprogressbar) {
> @@ -388,6 +397,11 @@ void cb_event(alpm_event_t *event)
> case ALPM_EVENT_PKG_RETRIEVE_DONE:
> case ALPM_EVENT_PKG_RETRIEVE_FAILED:
> console_cursor_move_end();
> + if(total_enabled && dload_progressbar_enabled()) {
> + update_total_finalstats();
> + printf("\n");
> + }
> + total_enabled = 0;
OK.
> flush_output_list();
> on_progress = 0;
> break;
> @@ -679,11 +693,6 @@ void cb_progress(alpm_progress_t event, const char
> *pkgname, int percent,
> void cb_dl_total(off_t total)
> {
> list_total = total;
> - /* if we get a 0 value, it means this list has finished downloading,
> - * so clear out our list_xfered as well */
> - if(total == 0) {
> - list_xfered = 0;
> - }
> }
OK
>
> static int dload_progressbar_enabled(void)
> @@ -726,6 +735,16 @@ static bool find_bar_for_filename(const char *filename,
> int *index, struct pacma
> return false;
> }
>
> +static void init_total_progressbar(void)
> +{
> + totalbar = calloc(1, sizeof(struct pacman_progress_bar));
> + assert(totalbar);
> + totalbar->filename = "Total progress:";
> + totalbar->init_time = get_time_ms();
> + totalbar->total_size = list_total;
> + totalbar->rate = 0.0;
> +}
> +
OK.
> static void draw_pacman_progress_bar(struct pacman_progress_bar *bar)
> {
>
Re: [pacman-dev] [GIT] The official pacman repository tag, last-deltapkgs-commit, created. v5.1.1-144-g377d4714
On 4/12/20 1:54 pm, Allan McRae wrote: > This is an automated email from the git hooks/post-receive script. It was > generated because a ref change was pushed to the repository containing > the project "The official pacman repository". > > The tag, last-deltapkgs-commit has been created > at 377d47142f7aaa01ca782e6587f2d4caf663865b (commit) > > - Log - > commit 377d47142f7aaa01ca782e6587f2d4caf663865b > Author: Jelle van der Waa > Date: Thu Feb 21 13:20:19 2019 +0100 > > doc: add man page for pacman-conf > > Signed-off-by: Jelle van der Waa > Signed-off-by: Allan McRae > --- > > > hooks/post-receive > Hrm... I made the v6.0.0alpha1 tag and pushed the tags and this came along for the ride. Not sure where it came from! Anyone know? Allan
[pacman-dev] [GIT] The official pacman repository tag, last-deltapkgs-commit, created. v5.1.1-144-g377d4714
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "The official pacman repository". The tag, last-deltapkgs-commit has been created at 377d47142f7aaa01ca782e6587f2d4caf663865b (commit) - Log - commit 377d47142f7aaa01ca782e6587f2d4caf663865b Author: Jelle van der Waa Date: Thu Feb 21 13:20:19 2019 +0100 doc: add man page for pacman-conf Signed-off-by: Jelle van der Waa Signed-off-by: Allan McRae --- hooks/post-receive -- The official pacman repository
[pacman-dev] [GIT] The official pacman repository annotated tag, v6.0.0alpha1, created. v6.0.0alpha1
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "The official pacman repository".
The annotated tag, v6.0.0alpha1 has been created
at 09b67861d9c550b0de411f95f36421d48c524499 (tag)
tagging a4240a55e448ffba15a5edbad1a31cb76f821231 (commit)
replaces v5.2.1
tagged by Allan McRae
on Fri Dec 4 13:36:09 2020 +1000
- Log -
Time to road-test the new downloader code
-BEGIN PGP SIGNATURE-
iQEzBAABCAAdFiEEZkWwqMcAXnjbHXhk+Z/+D+rpmb0FAl/Jrs8ACgkQ+Z/+D+rp
mb3T8gf/e6W1zu0Uhs2HqzqTvZHCIHnROKNSMBH/h3iA1iavwqS6fvnZXqOcsIEC
02Nk8H9Tu4V0EIDWck9wjAGddtQNeR1w3/ljaEZmazILH8mUYbHu4t/VSJH68JgP
EBF2BhEL6Ut2g2YuYOZSrIjC6cSdJ7j3uxM7ltuhZibCvux8Q2UxbFdncTvyB6ql
2L2cKWl9RURXu72+JGdGY5xyAv5KG5mwKyEPieWBV5+Mhb5iCDFfH9ILVO/XCwK8
Gv+bb4UT+IZ+UO9zj/rVl07lqqiGf8Ynj2DsdK6t7Vx1QIV+ms6ru27EqcKVkumr
P2LRogLuerYf5CrO/I5saaf+B/LZtg==
=4C8n
-END PGP SIGNATURE-----
Allan McRae (31):
Move update-copyright into build-aux
Remove "Generated from ...; do not edit by hand" from scripts
libalpm/sync.c: Do not download missing keys multiple times
pactest: set package tar format to GNU_FORMAT
Handle .part files that are the size of the correct package
Add Eli to current maintainers
Fix leak in _alpm_db_search on error condition
Improved documentation for alpm_db_search() parameters
Fix documentation of alpm_mtree_next and remove libarchive exposure
tests: Fix typo in test description
Increase meson test timeout
Remove unneeded ltmain patch
Increase maximum database size
Fix "pacman -U " operations
Note that checksums from "makepkg -g" are not ideal
makepkg: add CRC checksums and set these to be the default
Add pacman-hooks.5 man page symlink
build-aux/update-copyright 2019 2020
Remove unneeded goto cleanup
Add file and line number to RET_ERR{,_VOID}
Use STRDUP for error checking in more places
Use GOTO_ERR throughout
pacman.8: Fix typo
Add Gitlab Runner configuration
Convert gitlab valgrind runner to meson
Remove autotools support
libalpm/signing.c: Fix calculation of packet size in parse_subpacket
Revert "makepkg: drop duplicate reporting of missing dependencies"
pacman-key: change signing key to RSA4096
makepkg.conf: Reword "Defaults"
Modify "pacman -h" output for files operations
Anatol Pomozov (33):
Eliminate extra loop over dbs_sync
Simplify construction of payloads in download_files
Do not download files if find_dl_candidates() fails
Move flushing 'output' list into separate function
Add GOTO_ERR() macro to set error and then goto a label
Hide cursor while pacman is running
Add config option to specify amount of parallel download streams
Introduce alpm_dbs_update() function for parallel db updates
Add multi_curl handle to ALPM global context
Inline dload_payload->curlerr field into a local variable
Implement _alpm_multi_download
Implement multiplexed download using mCURL
Introduce event types for start/end database list download
Extend download callback interface with start/complete events
Implement multibar UI
Convert download packages logic to multiplexed API
Convert downloading databases to the new multiplexed API
Swap alpm_db_update() implementation to multiplexed version
Convert '-U pkg1 pkg2' codepath to parallel download
Cleanup the old sequential download code
Move signature payload creation to download engine
Do not use counter for error tracking
Add a utility function to check whether a file exists in the cache
FS#33992: force download *.sig file if it does not exist in the cache
Fallback to detached signatures during keyring check
Build signature remote name based on the main payload name
Do not free payload fields in the middle of this structure use
Check that destfile_name exists before using it
Fix error during keyring checking
Enable sha256/md5 hash verification if detached signatures are used
FS#66472: Remove *.sig file if package corrupted
Go to the end of screen if 'printonly' mode enabled
Move cursor to the end of the screen at the SIGINT
Carson Black (1):
Dull version colour numbers in summary
Chih-Hsuan Yen (1):
util.c: table_print_line: properly align texts involving CJK
Colin Woodbury (1):
Restore usage line for -Fh
Daniel T. Borelli (1):
Dereference double pointer before assigning NULL
Dave Reisner (5):
Ensure regex object is always initialized
Use c99 struct initialization to avoid memset calls
makepkg: drop duplicate
[pacman-dev] [GIT] The official pacman repository branch, master, updated. v5.2.1-134-ga4240a55
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "The official pacman repository". The branch, master has been updated via a4240a55e448ffba15a5edbad1a31cb76f821231 (commit) via 20f2ae56eb4ae1affd274185c173524f5b4fb2f1 (commit) via 5c24f7dd11a241f6414e3ee6f95f224382ec27ce (commit) from 08f4ae709ca00ec9b4c56d92d3cdd7de4e6effc2 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit a4240a55e448ffba15a5edbad1a31cb76f821231 Author: Colin Woodbury Date: Wed Nov 25 12:53:11 2020 -0800 Restore usage line for -Fh Unlike the other main commands, -F was missing its top-level usage line in its help output. Signed-off-by: Colin Woodbury Signed-off-by: Allan McRae commit 20f2ae56eb4ae1affd274185c173524f5b4fb2f1 Author: Allan McRae Date: Thu Dec 3 21:34:01 2020 +1000 Modify "pacman -h" output for files operations pacman -F can take both a file(s) or a package(s) as arguments. Passing a file is more common, so adjust to show that in the help. Signed-off-by: Allan McRae commit 5c24f7dd11a241f6414e3ee6f95f224382ec27ce Author: morganamilo Date: Mon Nov 30 18:21:26 2020 + libalpm: set ret in download files download_files never set ret on failiure, so even when downloading fails, the transaction goes on to commit and error out. :: Retrieving packages... python-packaging-20.4-4-any.pkg.tar.zst failed to download error: failed retrieving file 'python-packaging-20.4-4-any.pkg.tar.zst' from mirror.oldsql.cc : The requested URL returned error: 404 warning: failed to retrieve some files (1/1) checking keys in keyring (1/1) checking package integrity error: failed to commit transaction (wrong or NULL argument passed) Errors occurred, no packages were upgraded. Also make the ret checking more consistent. Signed-off-by: Allan McRae --- Summary of changes: lib/libalpm/sync.c | 6 -- src/pacman/pacman.c | 4 +++- 2 files changed, 7 insertions(+), 3 deletions(-) hooks/post-receive -- The official pacman repository
Re: [pacman-dev] [PATCH] Restore usage line for -Fh
On 27/11/20 1:45 am, Colin Woodbury wrote: >> but "pacman -F" also takes file paths or regex as an argument, not just >> package names. > > It does, yeah. In this case I was going off what `pacman -h` displays for > `-F`, which is just `[packages]`. Should I update both `-h` and `-Fh`, or > just the latter? > You will see my patch on the list changing this to str_file as that is (probably) the most common usage of -F. I adjust this patch to do the same and applied. Allan
[pacman-dev] [PATCH] Modify "pacman -h" output for files operations
pacman -F can take both a file(s) or a package(s) as arguments. Passing a
file is more common, so adjust to show that in the help.
Signed-off-by: Allan McRae
---
src/pacman/pacman.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/pacman/pacman.c b/src/pacman/pacman.c
index fefd3fa4..f98c9a4a 100644
--- a/src/pacman/pacman.c
+++ b/src/pacman/pacman.c
@@ -110,7 +110,7 @@ static void usage(int op, const char * const myname)
printf("%s {-h --help}\n", myname);
printf("%s {-V --version}\n", myname);
printf("%s {-D --database} <%s> <%s>\n", myname, str_opt,
str_pkg);
- printf("%s {-F --files}[%s] [%s]\n", myname, str_opt,
str_pkg);
+ printf("%s {-F --files}[%s] [%s]\n", myname, str_opt,
str_file);
printf("%s {-Q --query}[%s] [%s]\n", myname, str_opt,
str_pkg);
printf("%s {-R --remove} [%s] <%s>\n", myname, str_opt,
str_pkg);
printf("%s {-S --sync} [%s] [%s]\n", myname, str_opt,
str_pkg);
--
2.29.2
[pacman-dev] [GIT] The official pacman repository branch, master, updated. v5.2.1-131-g08f4ae70
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "The official pacman repository". The branch, master has been updated via 08f4ae709ca00ec9b4c56d92d3cdd7de4e6effc2 (commit) via 73e0d7dedc197f71c4fd6b7c18d2b2f2d63bf013 (commit) via 66f9f315cf36a5b73c18c627f7cee060a1360abd (commit) via 75cfce94682fcd0e9bbeed5db1f97dbb5b1be9e7 (commit) via 4b8c274f7fc1ecd8cee9176471f081da3323b258 (commit) via 9dc29ebf5f3c6fe34b5a1b60f6f57f88668d9d20 (commit) via db4092e33dacc6a0bb8afd283a82e6f4327cb865 (commit) via 2859a6eefcb465a382267c6e5981192c6a54f5bb (commit) via 94ac3330dd3a42958ad5d9606ec254bc112936bf (commit) from 4d8f58d3b940f778b27c59e53ea9f3fab20a07ba (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit 08f4ae709ca00ec9b4c56d92d3cdd7de4e6effc2 Author: Ivy Foster Date: Wed Nov 25 22:38:24 2020 -0600 Add fossil scm support to makepkg Signed-off-by: Ivy Foster Signed-off-by: Allan McRae commit 73e0d7dedc197f71c4fd6b7c18d2b2f2d63bf013 Author: morganamilo Date: Tue Nov 24 12:39:08 2020 + libalpm: add alpm_option_get_parallel_downloads Signed-off-by: Allan McRae commit 66f9f315cf36a5b73c18c627f7cee060a1360abd Author: morganamilo Date: Tue Nov 24 12:39:07 2020 + libalpm: set errno when setting parallel downloads with an invalid number Signed-off-by: Allan McRae commit 75cfce94682fcd0e9bbeed5db1f97dbb5b1be9e7 Author: morganamilo Date: Tue Nov 24 12:39:06 2020 + libalpm: clarify alpm_download_event_completed_t status The comment makes it seem that the result itself is an error code. But all it does is simply return -1 to indicate an error occured; Signed-off-by: Allan McRae commit 4b8c274f7fc1ecd8cee9176471f081da3323b258 Author: morganamilo Date: Tue Nov 24 12:39:05 2020 + libalpm: don't call dlcb when not set Fixes FS#68728: Signed-off-by: Allan McRae commit 9dc29ebf5f3c6fe34b5a1b60f6f57f88668d9d20 Author: morganamilo Date: Tue Nov 24 12:39:04 2020 + libalpm: set parallel_downloads to 1 when creating the handle Fixes FS#68729 Signed-off-by: Allan McRae commit db4092e33dacc6a0bb8afd283a82e6f4327cb865 Author: Anatol Pomozov Date: Tue Nov 3 17:04:38 2020 -0800 Move cursor to the end of the screen at the SIGINT It requires exposing 'move cursor to the end' function in a pacman header file. We use it as a chance to make naming of the cursor management functions more consistent. Note that there is still possibility of a race condition in the cursor update logic. 'update cursor index variable' and 'send ASCII control symbols to console' is not an atomic operation. So if an SIGINT is received between these two action then cursor position is going to be screwed. Fixes FS#67973 Signed-off-by: Anatol Pomozov Signed-off-by: Allan McRae commit 2859a6eefcb465a382267c6e5981192c6a54f5bb Author: Anatol Pomozov Date: Thu Oct 22 09:31:14 2020 -0700 Go to the end of screen if 'printonly' mode enabled At the end of download operation our code makes sure the cursor is moved to the end of the drawing area. But 'printonly' mode has its own if() branch that skips this cursor alignment. Add cursor_goto_end() to the 'printonly' codepath to make sure it does not clobber previous output. Fixes FS#68355 Signed-off-by: Anatol Pomozov Signed-off-by: Allan McRae commit 94ac3330dd3a42958ad5d9606ec254bc112936bf Author: Michael Straube Date: Wed Oct 21 10:05:43 2020 +0200 libmakepkg: compress: fix tar extension With commit 74aacf44958e1343b910b3fbdcf753393857f070 creating uncompressed .tar packages fails. -> Compressing package... /usr/share/makepkg/util/compress.sh: line 70: COMPRESS.TAR[@]: invalid variable name bsdtar: Write error Empty the '$ext' variable for the '.tar' extension in get_compress_command() to fix this. We would fallback to cat for 'tar' anyways. Signed-off-by: Michael Straube Signed-off-by: Allan McRae --- Summary of changes: doc/PKGBUILD.5.asciidoc| 3 + etc/makepkg.conf.in| 1 + lib/libalpm/alpm.c | 2 + lib/libalpm/alpm.h | 8 +- lib/libalpm/dload.c| 4 +- lib/libalpm/handle.c | 14 +++- scripts/libmakepkg/executable/vcs.sh.in
Re: [pacman-dev] [PATCH] Restore usage line for -Fh
On 26/11/20 6:53 am, Colin Woodbury wrote:
> Unlike the other main commands, -F was missing its top-level usage line in its
> help output.
>
> Signed-off-by: Colin Woodbury
> ---
> src/pacman/pacman.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/src/pacman/pacman.c b/src/pacman/pacman.c
> index fefd3fa4..69e2e42a 100644
> --- a/src/pacman/pacman.c
> +++ b/src/pacman/pacman.c
> @@ -176,6 +176,8 @@ static void usage(int op, const char * const myname)
> printf("%s: %s {-T --deptest} [%s] [%s]\n", str_usg,
> myname, str_opt, str_pkg);
> printf("%s:\n", str_opt);
> } else if(op == PM_OP_FILES) {
> + printf("%s: %s {-F --files} [%s] [%s]\n", str_usg,
> myname, str_opt, str_pkg);
This gives:
usage: pacman {-F --files} [options] [package(s)]
but "pacman -F" also takes file paths or regex as an argument, not just
package names.
> + printf("%s:\n", str_opt);
> addlist(_(" -l, --list list the files owned
> by the queried package\n"));
> addlist(_(" -q, --quiet show less information
> for query and search\n"));
> addlist(_(" -x, --regex enable searching
> using regular expressions\n"));
>
Re: [pacman-dev] [PATCH 3/5] libalpm: clarify alpm_download_event_completed_t status
On 24/11/20 10:39 pm, morganamilo wrote:
> The comment makes it seem that the result itself is an error code. But
> all it does is simply return -1 to indicate an error occured;
>
> diff --git a/lib/libalpm/alpm.h b/lib/libalpm/alpm.h
> index 614a530c..6a7323e0 100644
> --- a/lib/libalpm/alpm.h
> +++ b/lib/libalpm/alpm.h
> @@ -728,9 +728,9 @@ typedef struct {
> /* total bytes in file */
> off_t total;
> /* download result code:
> - * 0 - download completed successfully
> - * 1 - the file is up-to-date
> - * negative - error code
> + *0 - download completed successfully
> + *1 - the file is up-to-date
> + * -1 - error
I have a suspicion this was supposed to indicate "<0" as a failure, but
given we only use -1, this is fine.
>*/
> int result;
> } alpm_download_event_completed_t;
>
Re: [pacman-dev] [PATCH 2/5] libalpm: don't call dlcb when not set
On 24/11/20 10:39 pm, morganamilo wrote:
> Fixes FS#68728:
>
Thanks - I had a quick skim elsewhere and looks like this covers the
issue fully.
> diff --git a/lib/libalpm/dload.c b/lib/libalpm/dload.c
> index 673e769f..d43e6d45 100644
> --- a/lib/libalpm/dload.c
> +++ b/lib/libalpm/dload.c
> @@ -586,7 +586,7 @@ cleanup:
> unlink(payload->tempfile_name);
> }
>
> - if(!payload->signature) {
> + if(handle->dlcb && !payload->signature) {
> alpm_download_event_completed_t cb_data = {0};
> cb_data.total = bytes_dl;
> cb_data.result = ret;
> @@ -719,7 +719,7 @@ static int curl_download_internal(alpm_handle_t *handle,
> struct dload_payload *payload = payloads->data;
>
> if(curl_add_payload(handle, curlm, payload, localpath)
> == 0) {
> - if(!payload->signature) {
> + if(handle->dlcb && !payload->signature) {
> alpm_download_event_init_t cb_data =
> {.optional = payload->errors_ok};
> handle->dlcb(payload->remote_name,
> ALPM_DOWNLOAD_INIT, _data);
> }
>
Re: [pacman-dev] [PATCH 1/5] libalpm: set parallel_downloads to 1 when creating the handle
On 24/11/20 10:39 pm, morganamilo wrote: > Fixes FS#68729 > > diff --git a/lib/libalpm/alpm.c b/lib/libalpm/alpm.c > index 34c5b4b2..5d36136d 100644 > --- a/lib/libalpm/alpm.c > +++ b/lib/libalpm/alpm.c > @@ -61,6 +61,8 @@ alpm_handle_t SYMEXPORT *alpm_initialize(const char *root, > const char *dbpath, > /* set default database extension */ > STRDUP(myhandle->dbext, ".db", goto nomem); > > + myhandle->parallel_downloads = 1; > + > lockfilelen = strlen(myhandle->dbpath) + strlen(lf) + 1; > MALLOC(myhandle->lockfile, lockfilelen, goto nomem); > snprintf(myhandle->lockfile, lockfilelen, "%s%s", myhandle->dbpath, lf); > Thanks - I moved that line right under the curl bit to keep download stuff together. Allan
Re: [pacman-dev] [PATCH] Move cursor to the end of the screen at the SIGINT
On 4/11/20 11:04 am, Anatol Pomozov wrote: > It requires exposing 'move cursor to the end' function in a pacman > header file. We use it as a chance to make naming of the cursor management > functions more consistent. > > Note that there is still possibility of a race condition in the cursor > update logic. 'update cursor index variable' and 'send ASCII control > symbols to console' is not an atomic operation. So if an SIGINT is > received between these two action then cursor position is going to be > screwed. > > Fixes FS#67973 > > Signed-off-by: Anatol Pomozov > --- Looks good. As an aside, I'd like to boot those console functions into a separate file at some stage. Allan
Re: [pacman-dev] [PATCH v2] libmakepkg: lint all arrays for empty values
On 28/10/20 11:39 am, morganamilo wrote:
> Empty values break pacman's db format, as an empty line indicates an end
> of section.
>
> ---
>
> I've seen this out in the wild:
> https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=vim-coc-highlight-git=3063e1a6d3e72a35528
>
> diff --git a/scripts/libmakepkg/lint_pkgbuild/variable.sh.in
> b/scripts/libmakepkg/lint_pkgbuild/variable.sh.in
> index 1bc49722..22f5fbbb 100644
> --- a/scripts/libmakepkg/lint_pkgbuild/variable.sh.in
> +++ b/scripts/libmakepkg/lint_pkgbuild/variable.sh.in
> @@ -31,7 +31,7 @@ lint_pkgbuild_functions+=('lint_variable')
>
>
> lint_variable() {
> - local i a pkg out bad ret=0
> + local i a pkg out bad array var ret=0
>
> # global variables
> for i in ${pkgbuild_schema_arrays[@]}; do
> @@ -93,5 +93,62 @@ lint_variable() {
> done
> done
>
> + # ensure lists don't contain empty values
> + for i in ${pkgbuild_schema_arrays[@]}; do
> + if declare -p $i > /dev/null 2>&1; then
> + array_build "array" "$i"
> + for var in "${array[@]}"; do
> + if [[ -z "$var" ]]; then
> + error "$(gettext "%s is not allowed to
> be empty")" "$i"
The array here is not empty, but a value in the array. I think this
would be a better error message.
"$(gettext "%s is not allowed to contain empty values")" "$i"
> + ret=1
> + fi
> + done
> + fi
> + done
> +
> + for a in ${arch[@]}; do
> + [[ $a == "any" ]] && continue
> +
> + for i in ${pkgbuild_schema_arch_arrays[@]}; do
> + if declare -p "${i}_${a}" > /dev/null 2>&1; then
> + array_build "array" "${i}_${a}"
> + for var in "${array[@]}"; do
> + if [[ -z "$var" ]]; then
> + error "$(gettext "%s is not
> allowed to be empty")" "${i}_${a}"
> + ret=1
> + fi
> + done
> + fi
> + done
> + done
> +
> + for pkg in ${pkgname[@]}; do
> + for i in ${pkgbuild_schema_arrays[@]}; do
> + if extract_function_variable "package_$pkg" $i 1 out;
> then
> + for val in "${out[@]}" ;do
Switched from var to val here.
> + if [[ -z "$val" ]]; then
> + error "$(gettext "%s is not
> allowed to be empty")" "$i"
> + ret=1
> + fi
> + done
> + fi
> + done
> +
> + for a in ${arch[@]}; do
> + [[ $a == "any" ]] && continue
> +
> + for i in ${pkgbuild_schema_arch_arrays[@]}; do
> + if extract_function_variable "package_$pkg"
> "${i}_${a}" 1 out; then
> + for val in "${out[@]}" ;do
> + if [[ -z "$val" ]]; then
> + error "$(gettext "%s is
> not allowed to be empty")" "${i}_${a}"
> + ret=1
> + fi
> + done
> + fi
> + done
> + done
> + done
> +
> return $ret
> }
>
Re: [pacman-dev] [PATCH v2] Go to the end of screen if 'printonly' mode enabled
On 23/10/20 2:31 am, Anatol Pomozov wrote:
> At the end of download operation our code makes sure the cursor is moved
> to the end of the drawing area. But 'printonly' mode has its own if() branch
> that skips this cursor alignment. Add cursor_goto_end() to the 'printonly'
> codepath to make sure it does not clobber previous output.
>
> Fixes FS#68355
>
Thanks - patch looks good and fixes the issue.
> Signed-off-by: Anatol Pomozov
> ---
> src/pacman/callback.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/pacman/callback.c b/src/pacman/callback.c
> index 4240a779..53518101 100644
> --- a/src/pacman/callback.c
> +++ b/src/pacman/callback.c
> @@ -226,6 +226,7 @@ static int number_length(size_t n)
> void cb_event(alpm_event_t *event)
> {
> if(config->print) {
> + cursor_goto_end();
> return;
> }
> switch(event->type) {
>
Re: [pacman-dev] [PATCH] pacman-key: change signing key to ed25519
On 5/11/20 9:23 am, Jonas Witschel wrote: > On 2020-11-04 21:53, Geert Hendrickx via pacman-dev wrote: >> Larger RSA keys are not the way forward, switch to ed25519 instead. >> This will also become the default in the next version of GnuPG. >> [...] >> -Key-Type: RSA >> -Key-Length: 4096 >> +Key-Type: EDDSA >> +Key-Curve: ed25519 > > I will note that the strength of Ed25519 is estimated to be roughly comparable > to RSA 3027 [1], so the currently chosen RSA 4096 is actually a slightly > stronger algorithm. I am not saying that this is an argument against using > Ed25519, which I believe offers ample security for the foreseeable future, but > to be honest, I do not see a pressing need to switch either: > > One main benefit of elliptic curves is the much smaller key size, but that is > not important for a locally-generated signing key that by design will never be > shared with anyone else. > > On the other hand, Ed25519 is still not formally included in the OpenPGP > specification [2]. (Again, this is not necessarily an argument against its > internal use in pacman, since it only needs to be processable by GnuPG.) > > However, given the above facts, personally I would feel more comfortable > holding back this change for now, at least until GnuPG has actually made the > switch to Ed25519 as its default algorithm. > These are strong arguments to keep the current default. Particularly given there is nothing wrong with the current default at the moment, and you can initialize your pacman keyring "by hand" if you really are concerned. Allan
Re: [pacman-dev] [PATCH] libmakepkg: lint all arrays for empty values
On 28/10/20 9:39 am, Morgan Adamiec wrote: > Accidentally sent off list. resending: > > Because there's no reason for a pkgbuild to ever do this so may as well > make it a hard error. AUR packages can't be trusted to get it right. > > We already make an effort to link pkgbuilds to make sure they're right. > I don't how this is different to the other lints. We lint PKGBUILDs to make sure they do not break assumptions needed by makepkg or pacman. I don't think this check falls in that category - without going through the code, I beleive we do check this for pkgnames/depends/etc where it may be an issue. So I'm not sure this check finds anything in the "break makepkg/pacman" category. My opinion is this is something for namcap or the like. e.g. https://github.com/allanmcrae/pkglint Allan
Re: [pacman-dev] [PATCH] libmakepkg: lint all arrays for empty values
On 28/10/20 7:44 am, morganamilo wrote: > --- > > I've seen this out in the wild: > https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=vim-coc-highlight-git=3063e1a6d3e72a35528 > Why would this be an error?I think it would be a warning at best. Also, I think PKGBUILD linting done by makepkg (as in the lints distributed with the pacman source) should be limited to things that cause issues while packaging. An empty value for the license is "fine" as far as makepkg is concerned. Allan
Re: [pacman-dev] [PATCH] Support parallel download with xfercommand
On 21/10/20 11:54 am, lesto fante wrote: > Hi, > The general idea is to make it possible to have multiple XferCommand > running in parallel. > Rather than trying to keep track of multiple XferCommand, I thought it > would be much easier to let XferCommand to fork/send request to a > daemon and die; then let pacman call a final script `XferLockCommand` > that will block until all download are completed, it will return the > classic 0 on success and -1 on error. > > After the introduction of the parallel download, it has been given an > informal greenlight to submit a patch for XferCommand, so here I am. > > As I choose simplicity, there is currently no way for pacman to know > how many downloads are happening in the background, their status, > which one did fail, just the final result success/error. So, you are just passing the full list of files to download to a download script. Downloads are not managed by pacman at all? Just add three more lines to your script: pacman -Sy pacman -Sup --noconfirm pacman -Su I don't see the point of implementing parallel XferCommand like that within pacman at all. > I see 2 major slowdown to my downloads; > - small file overhead > - mirror bandwidth > > Currently I have a script that will pick all uncommented servers in > pacman list, divide them in groups of 3, and for each group download > one package. This make sure there is only one connection for server (i > assume server will not artificially limit the bandwidth, and if they > do i don't want to bypass their limit) while having multiple file in > download at the same time (good for small file overhead) and full > speed (multiple mirror for each file) > > Also from your presentation it seems like ParallelDownloads will hit > only one server; it says sync issue, not really sure what you meant > there, afaik each package is downloaded with full versioning in the > name. It currently does. In the future that may change. At the moment our download error output is not great, and servers out of sync would result in a lot of download errors. We need to add logic to catch bad servers and exclude them for future downloads, but fixing the output needs to happen first. >> So if you have an update with 150 package, every single one starts >> downloading at the same time? >> [...] >> Any implementation of this needs to respect the ParallelDownloads >> configuration option. > > in this patch it is left to the XferCommand/XferLockCommand > implementation. Also the idea is that XferLockCommand may print on > stdout the information relative to the status of the download, and > those relaid back to the user (I may be wrong but this is the current > behaviour); this way the user will not be left wondering what is going > on. > > -- Alternative 1 -- > Add to XferLockCommands argument the number of maximum parallel > downloads; if the number is reached, the command block. > so the pseudocode became > > for each file > XferCommand //start one download > XferLockCommand 10 // block if all 10 download slot are used > XferLockCommand 0 // special case, block until all download are completed > > -- Alternative 2 -- > build an array of PID, each one refer to a XferCommand, but I am not > sure how much this would be portable and if there may be issues with > PID reuse; but would give pacman a bit more control on the running > process. > Pacman currently monitors a single download in a portable way. I see no reason it could not monitor more than one. Then it could use ParallelDownloads and provided some consistency across download methods. >> Why even need this? A user either has ParallelDownloads set to be >> greater than 1, or does not. > > As far as I understand from the code in dload.c, ParallelDownloads > does not affect XferCommand, only one XferCommand is running and > expected to complete before the next is run. It does not... I'd expect it would after an addition to XferCommand to support parallel downloads.
[pacman-dev] [GIT] The official pacman repository branch, master, updated. v5.2.1-122-g4d8f58d3
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "The official pacman repository".
The branch, master has been updated
via 4d8f58d3b940f778b27c59e53ea9f3fab20a07ba (commit)
via c99a3cc867ee5bf725a5d33d57120c3764aeb41e (commit)
via f76bd2c6c1b94792112d311ac53662d3d9b6821d (commit)
from 406a37206f9afbc3731ac22eda5b45b5a15eddc5 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
commit 4d8f58d3b940f778b27c59e53ea9f3fab20a07ba
Author: Michael Straube
Date: Thu Oct 15 12:56:26 2020 +0200
makepkg: emptydirs: fix typo
Fix typo in a comment in tidy_emptydirs().
Signed-off-by: Michael Straube
Signed-off-by: Allan McRae
commit c99a3cc867ee5bf725a5d33d57120c3764aeb41e
Author: Eli Schwartz
Date: Sun Oct 11 22:22:05 2020 -0400
makepkg: properly localize some internal function variables
We leaked fullver and pkgarch all over the place, and only conditionally
unset the other variables. Marking them local is a more proactive
solution.
Signed-off-by: Eli Schwartz
Signed-off-by: Allan McRae
commit f76bd2c6c1b94792112d311ac53662d3d9b6821d
Author: Eli Schwartz
Date: Sun Oct 11 22:22:04 2020 -0400
makepkg: fix signing of source packages
In commit c6b04c04653ba9933fe978829148312e412a9ea7 the signing stage was
moved out of fakeroot, and thus into the main control flow instead of
create_{,src}package
While the function for signing binary packages has logic to build
and gpg-sign multiple filenames, the source package never got this
special treatment. This would be fine, except it uses the standard
variables to set define the filename... like ${fullver}, which is
usually set beforehand, but in this case is not. We don't define fullver
globally as it's an internal implementation detail, except by sheer
coincidence if PKGVERFUNC is false due to improperly guarded code.
Result: source packages didn't end up signed. Instead, we raised a logic
error:
==> WARNING: Failed to sign package file somepackage-.src.tar.gz.
==> ERROR: An unknown error has occurred. Exiting...
Instead, let's just build the version inline, since we only use it once.
Reported-by: GaKu999
Signed-off-by: Eli Schwartz
Signed-off-by: Allan McRae
---
Summary of changes:
scripts/libmakepkg/tidy/emptydirs.sh.in | 2 +-
scripts/makepkg.sh.in | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
hooks/post-receive
--
The official pacman repository
Re: [pacman-dev] [PATCH 1/2] makepkg: fix signing of source packages
On 12/10/20 12:22 pm, Eli Schwartz wrote:
> In commit c6b04c04653ba9933fe978829148312e412a9ea7 the signing stage was
> moved out of fakeroot, and thus into the main control flow instead of
> create_{,src}package
>
> While the function for signing binary packages has logic to build
> and gpg-sign multiple filenames, the source package never got this
> special treatment. This would be fine, except it uses the standard
> variables to set define the filename... like ${fullver}, which is
> usually set beforehand, but in this case is not. We don't define fullver
> globally as it's an internal implementation detail, except by sheer
> coincidence if PKGVERFUNC is false due to improperly guarded code.
>
> Result: source packages didn't end up signed. Instead, we raised a logic
> error:
>
> ==> WARNING: Failed to sign package file somepackage-.src.tar.gz.
>
> ==> ERROR: An unknown error has occurred. Exiting...
>
> Instead, let's just build the version inline, since we only use it once.
>
> Reported-by: GaKu999
> Signed-off-by: Eli Schwartz
> ---
> scripts/makepkg.sh.in | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in
> index e1e95412..a9e7c691 100644
> --- a/scripts/makepkg.sh.in
> +++ b/scripts/makepkg.sh.in
> @@ -1362,7 +1362,7 @@ if (( SOURCEONLY )); then
>
> if [[ $SIGNPKG = 'y' ]]; then
> msg "$(gettext "Signing package...")"
> - create_signature "$SRCPKGDEST/${pkgbase}-${fullver}${SRCEXT}"
> + create_signature
> "$SRCPKGDEST/${pkgbase}-$(get_full_version)${SRCEXT}"
OK.
> fi
>
> msg "$(gettext "Source package created: %s")" "$pkgbase ($(date +%c))"
>
Re: [pacman-dev] [PATCH 2/2] makepkg: properly localize some internal function variables
On 12/10/20 12:22 pm, Eli Schwartz wrote:
> We leaked fullver and pkgarch all over the place, and only conditionally
> unset the other variables. Marking them local is a more proactive
> solution.
>
OK.
> Signed-off-by: Eli Schwartz
> ---
> scripts/makepkg.sh.in | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in
> index a9e7c691..89da3fab 100644
> --- a/scripts/makepkg.sh.in
> +++ b/scripts/makepkg.sh.in
> @@ -869,6 +869,7 @@ install_package() {
> }
>
> check_build_status() {
> + local fullver pkgarch allpkgbuilt somepkgbuilt
> if (( ! SPLITPKG )); then
> fullver=$(get_full_version)
> pkgarch=$(get_pkg_arch)
> @@ -911,7 +912,6 @@ check_build_status() {
> exit $E_ALREADY_BUILT
> fi
> fi
> - unset allpkgbuilt somepkgbuilt
> fi
> }
>
>
Re: [pacman-dev] [PATCH] makepkg: emptydirs: fix typo
On 15/10/20 8:56 pm, Michael Straube wrote:
> Fix typo in a comment in tidy_emptydirs().
>
> Signed-off-by: Michael Straube
> ---
Thanks.
> scripts/libmakepkg/tidy/emptydirs.sh.in | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/libmakepkg/tidy/emptydirs.sh.in
> b/scripts/libmakepkg/tidy/emptydirs.sh.in
> index 902ea317..ffa0276f 100644
> --- a/scripts/libmakepkg/tidy/emptydirs.sh.in
> +++ b/scripts/libmakepkg/tidy/emptydirs.sh.in
> @@ -33,7 +33,7 @@ tidy_remove+=('tidy_emptydirs')
> tidy_emptydirs() {
> if check_option "emptydirs" "n"; then
> msg2 "$(gettext "Removing empty directories...")"
> - # we are unable to use '-empty' as it is non-POSIX and not
> support by all find variants
> + # we are unable to use '-empty' as it is non-POSIX and not
> supported by all find variants
> find . -depth -type d -exec rmdir '{}' \; 2>/dev/null
> fi
> }
>
Re: [pacman-dev] [PATCH] libmakepkg: compress: fix tar extension
On 21/10/20 1:31 am, Michael Straube wrote:
> With commit 74aacf44958e1343b910b3fbdcf753393857f070 creating uncompressed
> .tar
> packages fails.
>
> -> Compressing package...
> /usr/share/makepkg/util/compress.sh: line 70: COMPRESS.TAR[@]: invalid
> variable name
> bsdtar: Write error
>
> Empty the '$ext' variable for the '.tar' extension in get_compress_command()
> to
> fix this. We would fallback to cat for 'tar' anyways.
>
> Signed-off-by: Michael Straube
> ---
> scripts/libmakepkg/util/compress.sh.in | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/scripts/libmakepkg/util/compress.sh.in
> b/scripts/libmakepkg/util/compress.sh.in
> index d35a01fa..6595e0d6 100644
> --- a/scripts/libmakepkg/util/compress.sh.in
> +++ b/scripts/libmakepkg/util/compress.sh.in
> @@ -65,6 +65,8 @@ get_compression_command() {
> esac
>
> ext=${ext#*.tar.}
> + ext=${ext#*.tar}
> +
My first impression is this is fine, but I will have no idea why it is
fine next week... Can you add a comment?
> if [[ -n $ext ]]; then
> extarray="COMPRESS${ext^^}[@]"
> resolvecmd=("${!extarray}")
>
Re: [pacman-dev] [PATCH] Support parallel download with xfercommand
On 21/10/20 12:21 am, lesto fante wrote: > The idea here is that if XferLockCommand is set, XferCommand can be > non-blocking; all invocations of XferCommand are executed and only > then XferLockCommand is executed to wait for all the downloads to > complete. > So if you have an update with 150 package, every single one starts downloading at the same time? Any implementation of this needs to respect the ParallelDownloads configuration option. > I am also thinking of changing XferLockCommand to XferWaitCommand, if > you have better names please let me know. Why even need this? A user either has ParallelDownloads set to be greater than 1, or does not. > I will fix and resubmit. > BTW i noticed that master fails some check, is it safe to be used for > testing (in a virtual machine) or should i use a specific commit? > There are no test failures. My guess is you need to install fakechroot. Also, please don't top post. Allan
Re: [pacman-dev] pkglint
On 13/10/20 7:37 pm, Michael Straube wrote: > Allan talked about pkglint in Arch Conf and I started to implement some > of the simpler namcap rules. Is there any interest in working on pkglint? > And if so, where should I send patches? Just open pull requests in the > github repo? Github repo is the place. pkglint has nothing to do with pacman development, so here is not the place to discuss it. Allan
Re: [pacman-dev] [PATCH] repo-add: add --include-sigs option
On 29/9/20 6:53 am, Anatol Pomozov wrote: > Hi > > On Thu, Sep 3, 2020 at 7:41 PM Eli Schwartz wrote: >> >> On 9/2/20 11:02 PM, Allan McRae wrote: >>> Pacman now downloads the signature files for all packages when present in a >>> repository. That makes distributing signatures within repository databases >>> redundant and costly. >>> >>> Do not distribute the package signature files within the repo databases by >>> default and add an --include-sigs to revert to the old behaviour. >> >> As I've mentioned on the list before, I would like an --ignore-sigs >> option and continue to distribute sigs by default for pacman 6.0 > > I agree with Eli here. "Using embedded signatures" should stay default > as long as we support clients with pacman 5.x version. > > Otherwise we are going to hit problems when a repo maintainer updated > their system to pacman 6.x and started distributing optimized > databases without signatures while some clients still expect embedded > sigs. > > So I vote for including sigs by default in pacman 6.0 release, and > then flip the default later (during 6.0.1 or 6.1 release). I'll repeat, we will never switch a default in a maintenance release. And the x.y.1 release usually happens within a couple of weeks as bugs are found. So that seems a pointless transition period. Moving it to 6.1 means a likely 18 month wait given our usual release cycle. I think we all agree the default should be not to include signatures in the repo database. The question is about timing. I don't think timing is up to when pacman makes a new release. It is up to the distro or repo provider, and providing a flag to revert to the old behaviour is all that is needed. I am of the opinion if people update a major part of their package provision infrastructure without reading the changes (which will be clearly stated in the release notes), then that is their problem, not ours. A
Re: [pacman-dev] [PATCH] repo-add: add --include-sigs option
On 23/9/20 12:27 pm, Eli Schwartz wrote:
> On 9/21/20 3:02 AM, Allan McRae wrote:
>> On 21/9/20 3:51 pm, Andrew Gregory wrote:
>>> I would suggest just allowing the user to specify either way
>>> (--include-sigs/--no-include-sigs, --include-sigs={yes,no}, etc).
>>> Then uses can specify whatever they want without having to worry about
>>> what we set as a default.
>>>
>>
>> The problem is more the transition. I would like the default to be not
>> to include the signatures in the repo database. So does pacman need to
>> manage the transition from having signatures in a database to not, or do
>> the users need to manage that?
>>
>> With my patch (or any variant the does not include signatures by
>> default), users upgrading to repo-add v6.0 would need to adjust their
>> repo management utilities to add a signature include option immediately,
>> as their users may still be using pacman-5.x.
>>
>> Thinking of Arch here, a dbscripts update would need launched on the
>> server at the same time as updating repo-add. I am OK with that - some
>> updates need done in concert. But Eli was not.
>
> I'm concerned both about the need to time the adjustment of the option,
> and about the desire for what I see as sane defaults.
>
> My preference is to provide both options, but change the default in
> pacman 6.0.1.
We are not making a behaviour change in a point release.
> While we're hacking on repo-add options, we could go ahead and make it
> use parseopts, because the current handling is gross. Also I would like
> an elephant (usually I would request a pony, but this felt more apropos
> if we're talking about repo-add).
I'm not touching repo-add beyond the most minor of changes. A sync db
writing backend should be added to libalpm and repo-add replaced with
something more easily extended.
Allan
[pacman-dev] [GIT] The official pacman repository branch, master, updated. v5.2.1-119-g406a3720
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "The official pacman repository".
The branch, master has been updated
via 406a37206f9afbc3731ac22eda5b45b5a15eddc5 (commit)
via 4533c6a8e0f39c7707e671b7f9687607b46f1417 (commit)
via ff7ff3c58dcdb858c253e8e7fea1d758cdff0312 (commit)
via d85d9c8c6044bc58963c41df8b6c15de1356ab2f (commit)
via 04b69957c8c54b1ad80f3e5c9270657c48fd0b15 (commit)
via f235cea7330ec0ceb98c9474e7a8ea7fd27a3df2 (commit)
from f53ac85ff6cd2f74f8157f23a5e21650cd17f372 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
commit 406a37206f9afbc3731ac22eda5b45b5a15eddc5
Author: Eli Schwartz
Date: Thu May 14 13:05:30 2020 -0400
makepkg: libprovides: don't provide both versioned and unversioned sonames
If multiple files match the pattern libfoo.so*, we want to check each of
them and see if they are shared libraries, and if so, if they have
versions attached.
But some packages can have both shared libraries and random files which
match the filename pattern. This is true at least for files in
/usr/share/gdb/auto-load/, which must match the filename they are paired
with, followed by "-gdb.py" (or some other gdb scripting ext), but
definitely don't contain a shared library. In this case, we don't want
to double-report the library in the generated provides.
It's also possible (probably) for a package to provide a versioned as
well as an unversioned shared library, but in such cases a single
provides entry is sufficient to cover both cases (and the libdepends
for the depending package would contain an unversioned dependency).
Solve this by keeping track of whether we have added a versioned soname
provides already, and then only adding a maximum of one unversioned
provides *iff* there isn't a versioned one yet.
Signed-off-by: Eli Schwartz
Signed-off-by: Allan McRae
commit 4533c6a8e0f39c7707e671b7f9687607b46f1417
Author: Chih-Hsuan Yen
Date: Sun Sep 13 16:41:40 2020 +0800
util.c: table_print_line: properly align texts involving CJK
For printf in C, width is counted as bytes rather than Unicode width. [1]
> If the precision is specified, no more than that many bytes are written.
[1] Section 7.21.6, N2176, final draft for ISO/IEC 9899:2017 (C18)
Thanks Andrew Gregory for suggesting a simpler approach.
Fixes FS#59229
Signed-off-by: Chih-Hsuan Yen
Signed-off-by: Allan McRae
commit ff7ff3c58dcdb858c253e8e7fea1d758cdff0312
Author: Anatol Pomozov
Date: Mon Sep 14 18:52:56 2020 -0700
FS#66472: Remove *.sig file if package corrupted
In case if a package corrupted (e.g. signature or hash is invalid)
pacman tries to remove the package file to redownload it anew the next time.
Remove *.sig file as well to make sure no data is left for the invalid
package.
Signed-off-by: Anatol Pomozov
Signed-off-by: Allan McRae
commit d85d9c8c6044bc58963c41df8b6c15de1356ab2f
Author: Ronan Pigott
Date: Fri Aug 21 20:20:02 2020 -0700
Add pacman-conf zsh completions
Signed-off-by: Ronan Pigott
Signed-off-by: Allan McRae
commit 04b69957c8c54b1ad80f3e5c9270657c48fd0b15
Author: Eli Schwartz
Date: Mon Aug 10 20:52:29 2020 -0400
remove more autotools files
We forgot to remove m4/ in commit 454ea024383eab60295e4c4fdf2c329475887b2c
and now it's tragically reminding me of autotools!
Also take this opportunity to drop some symlinks in lib/libalpm/ for
libcommon source files. In autotools these were built specifically for
libalpm and needed to be available in that directory, but the meson
setup just has libalpm depend on libcommon. So these pseudo source files
aren't needed anymore.
Signed-off-by: Eli Schwartz
Signed-off-by: Allan McRae
commit f235cea7330ec0ceb98c9474e7a8ea7fd27a3df2
Author: Allan McRae
Date: Thu Sep 3 12:44:24 2020 +1000
makepkg.conf: Reword "Defaults"
FS#61661 notes that we have a comment "Defaults" value for BUILDENV and
OPTIONS
but that does not necessarily correspond to what the example makepkg.conf
sets.
Change the comment to "Makepkg defaults" to indicate this is what makepkg
will
do unless told otherwise.
Signed-off-by: Allan McRae
---
Summary of changes:
etc/makepkg.conf.in | 4 +-
lib/libalpm/ini.c| 1 -
lib/libalpm/ini.h| 1 -
lib/libal
Re: [pacman-dev] [PATCH] repo-add: add --include-sigs option
On 21/9/20 3:51 pm, Andrew Gregory wrote:
> On 09/21/20 at 03:19pm, Allan McRae wrote:
>> On 4/9/20 12:55 pm, Allan McRae wrote:
>>> On 4/9/20 12:40 pm, Eli Schwartz wrote:
>>>> On 9/2/20 11:02 PM, Allan McRae wrote:
>>>>> Pacman now downloads the signature files for all packages when present in
>>>>> a
>>>>> repository. That makes distributing signatures within repository
>>>>> databases
>>>>> redundant and costly.
>>>>>
>>>>> Do not distribute the package signature files within the repo databases by
>>>>> default and add an --include-sigs to revert to the old behaviour.
>>>>
>>>> As I've mentioned on the list before, I would like an --ignore-sigs
>>>> option and continue to distribute sigs by default for pacman 6.0
>>>>
>>>> In pacman 6.1 we'll switch by default to ignoring them, and let people
>>>> use --include-sigs to revert to the old behavior.
>>>>
>>>> Ignoring sigs right out of the gate means the default behavior of
>>>> repo-add is to be unusable for people upgrading from pacman N-1. For
>>>> example, Arch Linux would most certainly need to use the option to
>>>> provide backwards compat while upgrading. So do third-party repositories.
>>>>
>>>> Also: this option cannot be added to scripts ahead of time, since
>>>> repo-add will error on an unknown option, and it cannot be added after
>>>> the fact, since some packages will be broken in the meantime.
>>>>
>>>> I don't see what the rush is here to add behavior that no one will want
>>>> to use.
>>>> - It makes sense to make this configurable now that it's useful to be
>>>> able to ignore them.
>>>> - At the same time, defaults should be based on what is more likely for
>>>> people to want.
>>>>
>>>
>>> I really do not like the idea of adding an option, just to remove it in
>>> the next release. But we won't actually be able to remove it for at
>>> least two releases, as you have just made the case that people won't be
>>> able to change their scripts on release.
>>>
>>> Given pacman-6.0 is likely a few months out, can we do a 5.2.3 release
>>> including something like:
>>>
>>
>> Any feedback on this option?
>
> I would suggest just allowing the user to specify either way
> (--include-sigs/--no-include-sigs, --include-sigs={yes,no}, etc).
> Then uses can specify whatever they want without having to worry about
> what we set as a default.
>
The problem is more the transition. I would like the default to be not
to include the signatures in the repo database. So does pacman need to
manage the transition from having signatures in a database to not, or do
the users need to manage that?
With my patch (or any variant the does not include signatures by
default), users upgrading to repo-add v6.0 would need to adjust their
repo management utilities to add a signature include option immediately,
as their users may still be using pacman-5.x.
Thinking of Arch here, a dbscripts update would need launched on the
server at the same time as updating repo-add. I am OK with that - some
updates need done in concert. But Eli was not.
Allan
Re: [pacman-dev] [PATCH] repo-add: add --include-sigs option
On 4/9/20 12:55 pm, Allan McRae wrote:
> On 4/9/20 12:40 pm, Eli Schwartz wrote:
>> On 9/2/20 11:02 PM, Allan McRae wrote:
>>> Pacman now downloads the signature files for all packages when present in a
>>> repository. That makes distributing signatures within repository databases
>>> redundant and costly.
>>>
>>> Do not distribute the package signature files within the repo databases by
>>> default and add an --include-sigs to revert to the old behaviour.
>>
>> As I've mentioned on the list before, I would like an --ignore-sigs
>> option and continue to distribute sigs by default for pacman 6.0
>>
>> In pacman 6.1 we'll switch by default to ignoring them, and let people
>> use --include-sigs to revert to the old behavior.
>>
>> Ignoring sigs right out of the gate means the default behavior of
>> repo-add is to be unusable for people upgrading from pacman N-1. For
>> example, Arch Linux would most certainly need to use the option to
>> provide backwards compat while upgrading. So do third-party repositories.
>>
>> Also: this option cannot be added to scripts ahead of time, since
>> repo-add will error on an unknown option, and it cannot be added after
>> the fact, since some packages will be broken in the meantime.
>>
>> I don't see what the rush is here to add behavior that no one will want
>> to use.
>> - It makes sense to make this configurable now that it's useful to be
>> able to ignore them.
>> - At the same time, defaults should be based on what is more likely for
>> people to want.
>>
>
> I really do not like the idea of adding an option, just to remove it in
> the next release. But we won't actually be able to remove it for at
> least two releases, as you have just made the case that people won't be
> able to change their scripts on release.
>
> Given pacman-6.0 is likely a few months out, can we do a 5.2.3 release
> including something like:
>
Any feedback on this option?
>
> diff --git a/doc/repo-add.8.asciidoc b/doc/repo-add.8.asciidoc
> index 8de4485b..19e2336a 100644
> --- a/doc/repo-add.8.asciidoc
> +++ b/doc/repo-add.8.asciidoc
> @@ -70,6 +70,10 @@ repo-add Options
> Remove old package files from the disk when updating their entry in the
> database.
>
> +*\--include-sigs*::
> + Dummy option for forward compatibility with pacman-6.0.
> + Include package PGP signatures in the repository database (if available)
> +
>
> Example
> ---
> diff --git a/scripts/repo-add.sh.in b/scripts/repo-add.sh.in
> index b0b3505d..ee010dba 100644
> --- a/scripts/repo-add.sh.in
> +++ b/scripts/repo-add.sh.in
> @@ -43,6 +43,7 @@ LOCKFILE=
> CLEAN_LOCK=0
> USE_COLOR='y'
> PREVENT_DOWNGRADE=0
> +INCLUDE_SIGS=0
>
> # Import libmakepkg
> source "$LIBRARY"/util/message.sh
> @@ -631,6 +632,9 @@ while (( $# )); do
> -p|--prevent-downgrade)
> PREVENT_DOWNGRADE=1
> ;;
> + --include-sigs)
> + INCLUDE_SIGS=1
> + ;;
> *)
> args+=("$1")
> ;;
> .
>
Re: [pacman-dev] [PATCH v2] util.c: table_print_line: properly align texts involving CJK
On 13/9/20 6:41 pm, Chih-Hsuan Yen wrote:
> For printf in C, width is counted as bytes rather than Unicode width. [1]
>
>> If the precision is specified, no more than that many bytes are written.
>
> [1] Section 7.21.6, N2176, final draft for ISO/IEC 9899:2017 (C18)
>
> Thanks Andrew Gregory for suggesting a simpler approach.
>
> Fixes FS#59229
>
> Signed-off-by: Chih-Hsuan Yen
> ---
Thanks - looks good to me.
> src/pacman/util.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/src/pacman/util.c b/src/pacman/util.c
> index e9187529..0c6a0c09 100644
> --- a/src/pacman/util.c
> +++ b/src/pacman/util.c
> @@ -522,7 +522,9 @@ static void table_print_line(const alpm_list_t *line,
> short col_padding,
> continue;
> }
>
> - cell_width = (cell->mode & CELL_RIGHT_ALIGN ? (int)widths[i] :
> -(int)widths[i]);
> + /* calculate cell width, adjusting for multi-byte character
> strings */
> + cell_width = (int)widths[i] - string_length(str) + strlen(str);
> + cell_width = cell->mode & CELL_RIGHT_ALIGN ? cell_width :
> -cell_width;
>
> if(need_padding) {
> printf("%*s", col_padding, "");
>
Re: [pacman-dev] [PATCH] FS#66472: Remove *.sig file if package corrupted
On 15/9/20 11:52 am, Anatol Pomozov wrote:
> In case if a package corrupted (e.g. signature or hash is invalid)
> pacman tries to remove the package file to redownload it anew the next time.
> Remove *.sig file as well to make sure no data is left for the invalid
> package.
>
> Signed-off-by: Anatol Pomozov
> ---
> lib/libalpm/sync.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/lib/libalpm/sync.c b/lib/libalpm/sync.c
> index 9350793a..9397575a 100644
> --- a/lib/libalpm/sync.c
> +++ b/lib/libalpm/sync.c
> @@ -688,7 +688,13 @@ static int prompt_to_delete(alpm_handle_t *handle, const
> char *filepath,
> };
> QUESTION(handle, );
> if(question.remove) {
> + char *sig_filename;
> +
> unlink(filepath);
> +
> + sig_filename = _alpm_sigpath(handle, filepath);
> + unlink(sig_filename);
> + FREE(sig_filename);
So... You have "filepath" and use the function "_alpm_sigpath()", and
then call the variable "sig_filename". Needs to be sig_filepath!
I'll change that and apply.
> }
> return question.remove;
> }
>
Re: [pacman-dev] [PATCH] repo-add: add --include-sigs option
On 4/9/20 12:40 pm, Eli Schwartz wrote:
> On 9/2/20 11:02 PM, Allan McRae wrote:
>> Pacman now downloads the signature files for all packages when present in a
>> repository. That makes distributing signatures within repository databases
>> redundant and costly.
>>
>> Do not distribute the package signature files within the repo databases by
>> default and add an --include-sigs to revert to the old behaviour.
>
> As I've mentioned on the list before, I would like an --ignore-sigs
> option and continue to distribute sigs by default for pacman 6.0
>
> In pacman 6.1 we'll switch by default to ignoring them, and let people
> use --include-sigs to revert to the old behavior.
>
> Ignoring sigs right out of the gate means the default behavior of
> repo-add is to be unusable for people upgrading from pacman N-1. For
> example, Arch Linux would most certainly need to use the option to
> provide backwards compat while upgrading. So do third-party repositories.
>
> Also: this option cannot be added to scripts ahead of time, since
> repo-add will error on an unknown option, and it cannot be added after
> the fact, since some packages will be broken in the meantime.
>
> I don't see what the rush is here to add behavior that no one will want
> to use.
> - It makes sense to make this configurable now that it's useful to be
> able to ignore them.
> - At the same time, defaults should be based on what is more likely for
> people to want.
>
I really do not like the idea of adding an option, just to remove it in
the next release. But we won't actually be able to remove it for at
least two releases, as you have just made the case that people won't be
able to change their scripts on release.
Given pacman-6.0 is likely a few months out, can we do a 5.2.3 release
including something like:
diff --git a/doc/repo-add.8.asciidoc b/doc/repo-add.8.asciidoc
index 8de4485b..19e2336a 100644
--- a/doc/repo-add.8.asciidoc
+++ b/doc/repo-add.8.asciidoc
@@ -70,6 +70,10 @@ repo-add Options
Remove old package files from the disk when updating their entry in the
database.
+*\--include-sigs*::
+ Dummy option for forward compatibility with pacman-6.0.
+ Include package PGP signatures in the repository database (if available)
+
Example
---
diff --git a/scripts/repo-add.sh.in b/scripts/repo-add.sh.in
index b0b3505d..ee010dba 100644
--- a/scripts/repo-add.sh.in
+++ b/scripts/repo-add.sh.in
@@ -43,6 +43,7 @@ LOCKFILE=
CLEAN_LOCK=0
USE_COLOR='y'
PREVENT_DOWNGRADE=0
+INCLUDE_SIGS=0
# Import libmakepkg
source "$LIBRARY"/util/message.sh
@@ -631,6 +632,9 @@ while (( $# )); do
-p|--prevent-downgrade)
PREVENT_DOWNGRADE=1
;;
+ --include-sigs)
+ INCLUDE_SIGS=1
+ ;;
*)
args+=("$1")
;;
Re: [pacman-dev] [PATCH] Add pacman-conf zsh completions
On 4/9/20 12:24 pm, Eli Schwartz wrote: > On 9/3/20 9:38 PM, Andrew Gregory wrote: >> On 08/21/20 at 08:20pm, Ronan Pigott wrote: >>> From: Ronan Pigott >>> >>> Signed-off-by: Ronan Pigott >> >> Sure, I guess. pacman-conf is meant for use in scripts; who on Earth >> is running it in a terminal? > > It can be pretty useful for running without options in order to > copy-paste your pacman.conf for help, but that's again not really a use > case for completions. I was working on the principle, that if someone submitted them, we can include them. Adds no overhead, beyond keeping them up to date. > I guess we want the same completions in bash_completion.in, but given I > don't really have a good use for it myself, I'm not sure I'll bother > writing it myself... If someone submits, I will include them. If not, I don't care. A
Re: [pacman-dev] [PATCH v4] libalpm: Add support for trigger dropins
On 31/8/20 6:23 am, Andrew Gregory wrote: > On 08/24/20 at 10:34pm, Daan De Meyer wrote: >>> What about adding Include support to hooks? Then hooks that need this >>> type of functionality could explicitly include trigger files from >>> a particular directory, insulating the process from simple hook >>> renaming and hopefully making it more obvious when changes to the hook >>> will require changes to any package that modifies it. >> >> Just to make sure I understand correctly, does Include support imply >> that hooks opt in to reading triggers from a specific directory and >> that we can rename the hook itself without changing the drop-in >> directory for that hook to avoid breakage? If so, that sounds totally >> reasonable and even preferable since it also avoids packages adding >> triggers to hooks that can't deal with extra targets when NeedsTargets >> is used. I can adapt the patch to use this approach. >> >> Do we pass a full path to Include or just a directory name? The >> advantage of just a directory name is that it could be created in any >> of the hook directories (hook installed in /usr/share/libalpm/hooks >> and the added triggers in /etc/pacman.d/hooks/ for >> example). It doesn't necessarily have to be just a directory name, we >> could interpret it as a relative path and you could still put it in >> each of the hook directories but that might just be adding too much >> complexity. > > Include should take a glob, just like pacman.conf. > I'm trying to figure out how includes would address this problem. We have a hook that runs when its triggers are met. We want to have a package add additional triggers, by dropping in a file into our config, but do not want to duplicate the function of the hook, or to directly edit the hook. An Include would provide a place where we can drop more config files with (e.g.) more triggers, but that requires the original hook to be set up such that it is extendable. Just adding additional triggers does not require the original hook to do anything. Now, just writing as I think here, so don't take this as a good idea... Unless a hooks name defined their include directory? I.e. fontconfig.hook would include fontconfig.d/* automatically. Long story short, I'm not sold on how Includes would work! Allan
[pacman-dev] [PATCH] repo-add: add --include-sigs option
Pacman now downloads the signature files for all packages when present in a
repository. That makes distributing signatures within repository databases
redundant and costly.
Do not distribute the package signature files within the repo databases by
default and add an --include-sigs to revert to the old behaviour.
Signed-off-by: Allan McRae
---
doc/repo-add.8.asciidoc | 2 ++
scripts/repo-add.sh.in | 6 +-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/doc/repo-add.8.asciidoc b/doc/repo-add.8.asciidoc
index 8de4485b..9b903ab1 100644
--- a/doc/repo-add.8.asciidoc
+++ b/doc/repo-add.8.asciidoc
@@ -70,6 +70,8 @@ repo-add Options
Remove old package files from the disk when updating their entry in the
database.
+*\--include-sigs*::
+ Include package PGP signatures in the repository database (if available)
Example
---
diff --git a/scripts/repo-add.sh.in b/scripts/repo-add.sh.in
index 7182d1b8..c153e7bb 100644
--- a/scripts/repo-add.sh.in
+++ b/scripts/repo-add.sh.in
@@ -42,6 +42,7 @@ LOCKFILE=
CLEAN_LOCK=0
USE_COLOR='y'
PREVENT_DOWNGRADE=0
+INCLUDE_SIGS=0
# Import libmakepkg
source "$LIBRARY"/util/compress.sh
@@ -260,7 +261,7 @@ db_write_entry() {
fi
# compute base64'd PGP signature
- if [[ -f "$pkgfile.sig" ]]; then
+ if (( INCLUDE_SIGS )) && [[ -f "$pkgfile.sig" ]]; then
if grep -q 'BEGIN PGP SIGNATURE' "$pkgfile.sig"; then
error "$(gettext "Cannot use armored signatures for
packages: %s")" "$pkgfile.sig"
return 1
@@ -622,6 +623,9 @@ while (( $# )); do
-p|--prevent-downgrade)
PREVENT_DOWNGRADE=1
;;
+ --include-sigs)
+ INCLUDE_SIGS=1
+ ;;
*)
args+=("$1")
;;
--
2.27.0
Re: [pacman-dev] [PATCH] Add pacman-conf zsh completions
On 22/8/20 1:20 pm, Ronan Pigott wrote: > From: Ronan Pigott > > Signed-off-by: Ronan Pigott > --- This looks good to me. Allan
[pacman-dev] [PATCH] makepkg.conf: Reword "Defaults"
FS#61661 notes that we have a comment "Defaults" value for BUILDENV and OPTIONS but that does not necessarily correspond to what the example makepkg.conf sets. Change the comment to "Makepkg defaults" to indicate this is what makepkg will do unless told otherwise. Signed-off-by: Allan McRae --- etc/makepkg.conf.in | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/etc/makepkg.conf.in b/etc/makepkg.conf.in index 1c7988d2..e9582646 100644 --- a/etc/makepkg.conf.in +++ b/etc/makepkg.conf.in @@ -52,7 +52,7 @@ CHOST="@CHOST@" # BUILD ENVIRONMENT # # -# Defaults: BUILDENV=(!distcc !color !ccache check !sign) +# Makepkg defaults: BUILDENV=(!distcc !color !ccache check !sign) # A negated environment option will do the opposite of the comments below. # #-- distcc: Use the Distributed C/C++/ObjC compiler @@ -75,7 +75,7 @@ BUILDENV=(!distcc color !ccache check !sign) # These are default values for the options=() settings # # -# Default: OPTIONS=(!strip docs libtool staticlibs emptydirs !zipman !purge !debug) +# Makepkg defaults: OPTIONS=(!strip docs libtool staticlibs emptydirs !zipman !purge !debug) # A negated option will do the opposite of the comments below. # #-- strip: Strip symbols from binaries/libraries -- 2.27.0
Re: [pacman-dev] [PATCH] Disable embedded signatures by default
On 27/8/20 10:26 am, Anatol Pomozov wrote: > Hi > > On Mon, Aug 10, 2020 at 2:45 PM Eli Schwartz wrote: >> >> On 8/10/20 5:34 PM, Anatol Pomozov wrote: >>> Switching from embedded to detached signatures is a big change. This >>> feature needs to be thoroughly tested before embedded signatures will be >>> completely removed from the database. >>> >>> To help with detached signatures testing we enable it by default. But in >>> case if an user needs to go back to embedded signatures we add a config >>> option to reenable it - "UseEmbeddedSignatures". >> What is the purpose of this? Either signature source should be >> equivalent, > > Indeed the signatures are equivalent. The only difference whether they > are stored inside the database file or as *.sig next to the packages > itself. > >> and you should be able to trivially test this by creating a >> repo with unsigned packages, then bulk-signing the packages after they >> were repo-added. I don't believe that pacman should include such an >> end-user option purely to double-check whether a current feature >> actually works. > > The purpose of the change is to start using the detached signatures > codepath. The detached signatures are shipped with repos for a long > time and pacman can handle it. Now it is time to actually enable it by > default. > > "UseEmbeddedSignatures" option has been added as a fallback plan in > case we find that the detached signatures codepath is broken. Do you > think this is too much hassle and we should just start using detached > signatures by default without any fallback config option? > I think we should test using detached signatures, and release without pacman having a fallback option in and of itself. The fallback option should be in repo-add, whether it adds the signatures to the database or not. >> This is the right approach, yeah. I was thinking we'd wait until pacman >> 6.1 before stopping the signature embedding, to provide a transition >> period for people depending on SigLevel = Required (which should be >> everyone, and certainly includes Arch!) to upgrade to 6.x before >> repo-add starts generating databases useless to pacman 5.x > > There are 2 sets of changes that need to be done: > 1) make pacman to use detached signatures instead of embedded ones > 2) change "repo-add" to avoid adding embedded signatures > > We should release changes for #1 first, test it, make sure that > detached signatures fully work (while dbs still have pacman > 5.x-compatible embedded sigs). And only then release #2 to get smaller > databases compatible with pacman version >= 6.0. > > I was thinking #1 can be released with 6.0 and #2 with 6.1. I was thinking #2 would be an option to repo-add. I'm looking at making signature embedding only occur with the "--add-signatures" option (or whatever I decide to call it). Arch would need to patch devtools to use this option. They would then make a News announcement about the need to have pacman-6.0 installed after 3-6 months and stop repo-add including signatures. However, I think pacman should always use the signatures in the database if they are present. Particularly if they are not embedded by default. So to actually test the detached signature path, I am thinking it best to tag 6.0.0beta1, make a package from that tag with a patch to enable using detached signatures as a priority. While that is not an ideal approach to testing, I think the current code path is well tested, and this should be a reasonably trivial patch. Allan
Re: [pacman-dev] [PATCH v4] libalpm: Add support for trigger dropins
Lets take a step back here... I don't really care about the kernel use case, but more whether this could be more generally used. Here are other examples I came up with. Font caches: A package could drop a config file in /etc/font/conf.d/ to add another directory that is to be used when building font caches. They would also want to add a .trigger file for the hook. OK... I just came up with one other example! But I did not look too hard at what hooks on my system actually do. Back to the question of whether we support this. A quick skim of the patch shows me it is quite long, but relatively simple. (it seems to be doing more than just adding .trigger support - also adding drop in directories - and this seems two patches to me...) So, I am leaning in the direction of this being a useful addition. Further discussion of the usefulness should not focus around the kernel approach, but rather the general idea of the feature. Allan
[pacman-dev] Arch Conf 2020
Hi all, Anyone want to do a pacman talk for Arch Conf 2020? Potentially jointly? https://lists.archlinux.org/pipermail/arch-events/2020-August/000645.html A
[pacman-dev] Making a beta release
Hi all, With the parallel downloader implementation roughly done, I'd like to make a beta release for some wider testing. Is there anything that people particularly want to land before such a testing release? Allan
Re: [pacman-dev] [PATCH] remove more autotools files
On 11/8/20 10:52 am, Eli Schwartz wrote: > We forgot to remove m4/ in commit 454ea024383eab60295e4c4fdf2c329475887b2c > and now it's tragically reminding me of autotools! > > Also take this opportunity to drop some symlinks in lib/libalpm/ for > libcommon source files. In autotools these were built specifically for > libalpm and needed to be available in that directory, but the meson > setup just has libalpm depend on libcommon. So these pseudo source files > aren't needed anymore. > > Signed-off-by: Eli Schwartz Looks good. A
Re: [pacman-dev] [PATCH] Disable embedded signatures by default
On 11/8/20 7:44 am, Eli Schwartz wrote: > On 8/10/20 5:34 PM, Anatol Pomozov wrote: >> Switching from embedded to detached signatures is a big change. This >> feature needs to be thoroughly tested before embedded signatures will be >> completely removed from the database. >> >> To help with detached signatures testing we enable it by default. But in >> case if an user needs to go back to embedded signatures we add a config >> option to reenable it - "UseEmbeddedSignatures". > What is the purpose of this? Either signature source should be > equivalent, and you should be able to trivially test this by creating a > repo with unsigned packages, then bulk-signing the packages after they > were repo-added. I don't believe that pacman should include such an > end-user option purely to double-check whether a current feature > actually works. Agreed - the user should not care where the signatures come from, so this option should not exist. Also, I see this was proposed on arch-dev-public first. I am not subscribed there, and decisions on what is included in pacman are not dictated by Arch Linux. Proposals should be posted here. Now, thinking out loud here... Would an alternative be to add an "--embed-signatures" option to repo-add? So two versions of a repo could be created and those that want to test without embedded signatures can. Allan
Re: [pacman-dev] [PATCH] Highlight changed part of new version numbers to let users easily distiguish between major, minor, bugfix and internal updates
On 13/7/20 8:31 am, Lars Øyvind Hagland wrote: > Signed-off-by: Lars Øyvind Hagland > --- > src/pacman/util.c | 55 ++- > src/pacman/util.h | 2 ++ > 2 files changed, 52 insertions(+), 5 deletions(-) > This has sat in my queue long enough that we can say it is likely I will never look at it. I do not consider it useful as there is no standard that says 5.4.0 -> 6.0.0 is more major than 5.4.0 -> 5.5.0. It really depends on the software being packaged. So I do not find the extra colour that useful. I am open for arguments to be made to counter my opinion.
[pacman-dev] [GIT] The official pacman repository branch, master, updated. v5.2.1-113-gf53ac85f
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "The official pacman repository".
The branch, master has been updated
via f53ac85ff6cd2f74f8157f23a5e21650cd17f372 (commit)
via 62246b9355867ab83566998303c921af6b1e38ef (commit)
via 2403fc97325908043917732b32adf87a2eaff603 (commit)
via 74aacf44958e1343b910b3fbdcf753393857f070 (commit)
from 2a352dc059f696eeda1e18116e468994c1a38430 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
commit f53ac85ff6cd2f74f8157f23a5e21650cd17f372
Author: Anatol Pomozov
Date: Fri Jul 31 09:53:15 2020 -0700
Enable sha256/md5 hash verification if detached signatures are used
Pacman has multiple ways to verify package content integrity:
- gpg signature
- sha256
- md5
These verification mechanisms overlap each other. gpg signatures already
contain
hash value of the package content. So if a package signature is present then
pacman ignored the other 2 hash values. This worked well with signtures
embedded into pacman database.
Recently pacman got an ability to handle detached signatures (*.sig files
located next to the package files). If pacman verifies detached signature
only
then one can replace pkg+sig files with some other content and pacman still
processes it as a valid package. To prevent it we need to verify
database<->package integrity using hash values stored in the database.
This commit fixes FS#67232
The new debug output is:
checking package integrity...
debug: found cached pkg:
/var/cache/pacman/pkg/ruby-2.7.1-2-x86_64.pkg.tar.zst
debug: sha256sum:
77baf61c62c5570b3a37cf0c3b16c5d9a97dde6fedd1a3528bf0cc5f96dd5e52
debug: checking sha256sum for
/var/cache/pacman/pkg/ruby-2.7.1-2-x86_64.pkg.tar.zst
debug: sig data:
debug: checking signature for
/var/cache/pacman/pkg/ruby-2.7.1-2-x86_64.pkg.tar.zst
debug: 1 signatures returned
debug: fingerprint: B5971F2C5C10A9A08C60030F786C63F330D7CB92
Signed-off-by: Anatol Pomozov
Signed-off-by: Allan McRae
commit 62246b9355867ab83566998303c921af6b1e38ef
Author: Anatol Pomozov
Date: Fri Jul 31 09:54:42 2020 -0700
Fix error during keyring checking
With current master version the 'keyring checking' step produces an error:
debug: returning error 6 from alpm_pkg_get_sig (../lib/libalpm/package.c:
274) : wrong or NULL argument passed
The package signature is still checked later at the integrity verification
step though.
This commit fixes keyring checking and now the debug log looks like this:
debug: found cached pkg:
/var/cache/pacman/pkg/ruby-2.7.1-2-x86_64.pkg.tar.zst
debug: found detached signature
/var/cache/pacman/pkg/ruby-2.7.1-2-x86_64.pkg.tar.zst.sig with size 566
debug: found signature key: 786C63F330D7CB92
debug: looking up key 786C63F330D7CB92 locally
debug: key lookup success, key exists
Signed-off-by: Anatol Pomozov
Signed-off-by: Allan McRae
commit 2403fc97325908043917732b32adf87a2eaff603
Author: Eli Schwartz
Date: Wed Aug 5 10:02:10 2020 -0400
repo-add: use more libmakepkg to handle common compression routines
Currently the list of supported formats for an archive, is maintained in
two places. And repo-add does not actually get updated. :(
In the process, remove some of the logical duplication when calling
bsdtar/compress_as.
Signed-off-by: Eli Schwartz
Signed-off-by: Allan McRae
commit 74aacf44958e1343b910b3fbdcf753393857f070
Author: Eli Schwartz
Date: Wed Aug 5 10:02:09 2020 -0400
libmakepkg: extend compress.sh to also permit checking validity
get_compression_command() can now be used to do upfront checks for
whether a given extension is known to do something successfully. This is
useful when writing tools in which an unknown compression type is a
fatal error.
Signed-off-by: Eli Schwartz
Signed-off-by: Allan McRae
---
Summary of changes:
lib/libalpm/be_package.c | 2 +-
lib/libalpm/package.c | 4 +--
scripts/libmakepkg/util/compress.sh.in | 53 +-
scripts/repo-add.sh.in | 32
4 files changed, 54 insertions(+), 37 deletions(-)
hooks/post-receive
--
The official pacman repository
Re: [pacman-dev] [PATCH] Fix error during keyring checking
On 5/8/20 3:16 am, Anatol Pomozov wrote:
> Hello
>
> On Tue, Aug 4, 2020 at 4:45 AM Allan McRae wrote:
>>
>> On 1/8/20 2:54 am, Anatol Pomozov wrote:
>>> With current master version the 'keyring checking' step produces an error:
>>> debug: returning error 6 from alpm_pkg_get_sig (../lib/libalpm/package.c:
>>> 274) : wrong or NULL argument passed
>>>
>>> The package signature is still checked later at the integrity verification
>>> step though.
>>>
>>> This commit fixes keyring checking and now the debug log looks like this:
>>> debug: found cached pkg:
>>> /var/cache/pacman/pkg/ruby-2.7.1-2-x86_64.pkg.tar.zst
>>> debug: found detached signature
>>> /var/cache/pacman/pkg/ruby-2.7.1-2-x86_64.pkg.tar.zst.sig with size 566
>>> debug: found signature key: 786C63F330D7CB92
>>> debug: looking up key 786C63F330D7CB92 locally
>>> debug: key lookup success, key exists
>>>
>>> Signed-off-by: Anatol Pomozov
>>> ---
>>> lib/libalpm/package.c | 4 +---
>>> 1 file changed, 1 insertion(+), 3 deletions(-)
>>>
>>> diff --git a/lib/libalpm/package.c b/lib/libalpm/package.c
>>> index 0885b27b..a4356518 100644
>>> --- a/lib/libalpm/package.c
>>> +++ b/lib/libalpm/package.c
>>> @@ -270,9 +270,7 @@ const char SYMEXPORT
>>> *alpm_pkg_get_base64_sig(alpm_pkg_t *pkg)
>>>
>>> int SYMEXPORT alpm_pkg_get_sig(alpm_pkg_t *pkg, unsigned char **sig,
>>> size_t *sig_len)
>>> {
>>> - if(pkg != NULL) {
>>
>> Surely the fix is to change != to == there. That way we still get some
>> form of error handling and not an abort.
>
> If "pkg == NULL" then the statement "pkg->handle" below is invalid and
> we cannot set the error code to the handle. The best thing we can do
> in case of an absent package is to return "-1" the same way as done in
> the functions above.
>
Good point... Patch is good
A
Re: [pacman-dev] [PATCH v3 1/2] libmakepkg: extend compress.sh to also permit checking validity
On 6/8/20 12:02 am, Eli Schwartz wrote: > get_compression_command() can now be used to do upfront checks for > whether a given extension is known to do something successfully. This is > useful when writing tools in which an unknown compression type is a > fatal error. > > Signed-off-by: Eli Schwartz > --- > > v3: split commit, this first part implements a function useful for > checking if we have a known good compression type > I'm happy with this and the following patch. A
Re: [pacman-dev] [PATCH] Fix error during keyring checking
On 1/8/20 2:54 am, Anatol Pomozov wrote:
> With current master version the 'keyring checking' step produces an error:
> debug: returning error 6 from alpm_pkg_get_sig (../lib/libalpm/package.c:
> 274) : wrong or NULL argument passed
>
> The package signature is still checked later at the integrity verification
> step though.
>
> This commit fixes keyring checking and now the debug log looks like this:
> debug: found cached pkg:
> /var/cache/pacman/pkg/ruby-2.7.1-2-x86_64.pkg.tar.zst
> debug: found detached signature
> /var/cache/pacman/pkg/ruby-2.7.1-2-x86_64.pkg.tar.zst.sig with size 566
> debug: found signature key: 786C63F330D7CB92
> debug: looking up key 786C63F330D7CB92 locally
> debug: key lookup success, key exists
>
> Signed-off-by: Anatol Pomozov
> ---
> lib/libalpm/package.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/lib/libalpm/package.c b/lib/libalpm/package.c
> index 0885b27b..a4356518 100644
> --- a/lib/libalpm/package.c
> +++ b/lib/libalpm/package.c
> @@ -270,9 +270,7 @@ const char SYMEXPORT *alpm_pkg_get_base64_sig(alpm_pkg_t
> *pkg)
>
> int SYMEXPORT alpm_pkg_get_sig(alpm_pkg_t *pkg, unsigned char **sig, size_t
> *sig_len)
> {
> - if(pkg != NULL) {
Surely the fix is to change != to == there. That way we still get some
form of error handling and not an abort.
> - RET_ERR(pkg->handle, ALPM_ERR_WRONG_ARGS, -1);
> - }
> + ASSERT(pkg != NULL, return -1);
>
> if(pkg->base64_sig) {
> int ret = alpm_decode_signature(pkg->base64_sig, sig, sig_len);
>
Re: [pacman-dev] [PATCH] PKGBUILD-vcs.proto: replace bzr with breezy
On 19/7/20 6:01 pm, Michael Straube wrote:
> The bzr package was replaced with breezy a while ago.
> Update the PKGBUILD-vcs.proto file.
>
It was in Arch. Not everywhere else pacman is used. Also, breezy
provides bzr, so it still works as is.
> Signed-off-by: Michael Straube
> ---
> proto/PKGBUILD-vcs.proto | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/proto/PKGBUILD-vcs.proto b/proto/PKGBUILD-vcs.proto
> index ae9956a9..6a76db67 100644
> --- a/proto/PKGBUILD-vcs.proto
> +++ b/proto/PKGBUILD-vcs.proto
> @@ -16,7 +16,7 @@ url=""
> license=('GPL')
> groups=()
> depends=()
> -makedepends=('VCS_PACKAGE') # 'bzr', 'git', 'mercurial' or 'subversion'
> +makedepends=('VCS_PACKAGE') # 'breezy', 'git', 'mercurial' or 'subversion'
> provides=("${pkgname%-VCS}")
> conflicts=("${pkgname%-VCS}")
> replaces=()
>
[pacman-dev] [GIT] The official pacman repository branch, master, updated. v5.2.1-109-g2a352dc0
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "The official pacman repository". The branch, master has been updated via 2a352dc059f696eeda1e18116e468994c1a38430 (commit) via 14c0e53eed4bd0c090e7ed2ebad41335d323c86c (commit) via 1fd95939dbee071f4d7fb30e19c5b3cb22969113 (commit) via a8bdc2e10ad6c942f3f1d77c126578a41bd3 (commit) from b01bcc7d3d680856bd60c4ae03e4ba3f6d889cb2 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit 2a352dc059f696eeda1e18116e468994c1a38430 Author: Morten Linderud Date: Mon Jul 13 22:25:41 2020 +0200 doc/makepkg.8: Added punctuations. Signed-off-by: Morten Linderud Signed-off-by: Allan McRae commit 14c0e53eed4bd0c090e7ed2ebad41335d323c86c Author: Anatol Pomozov Date: Mon Jul 13 09:35:34 2020 -0700 Check that destfile_name exists before using it In some cases (when trust_remote_name is used for a URL without a filename and no Content-Disposition is provided by the server) destfile_name will be NULL. In this case payload data will be stored in tempfile_name and no destfile_name is set. Signed-off-by: Anatol Pomozov Signed-off-by: Allan McRae commit 1fd95939dbee071f4d7fb30e19c5b3cb22969113 Author: Anatol Pomozov Date: Mon Jul 13 09:35:21 2020 -0700 Do not free payload fields in the middle of this structure use At the end of payload use it calls _alpm_dload_payload_reset() that will free() these and other fields anyway. Signed-off-by: Anatol Pomozov Signed-off-by: Allan McRae commit a8bdc2e10ad6c942f3f1d77c126578a41bd3 Author: Anatol Pomozov Date: Mon Jul 13 09:35:05 2020 -0700 Build signature remote name based on the main payload name The main payload final name might be affected by url redirects or Content-Disposition HTTP header value. We want to make sure that accompanion *.sig filename always matches the package filename. So ignore finalname/Content-Disposition for the *.sig file. It also helps to fix a corner case when the download URL does not contain a filename and server provides Content-Disposition for the main payload but not for the signature payload. Signed-off-by: Anatol Pomozov Signed-off-by: Allan McRae --- Summary of changes: doc/makepkg.8.asciidoc | 4 +-- lib/libalpm/dload.c| 74 +- 2 files changed, 45 insertions(+), 33 deletions(-) hooks/post-receive -- The official pacman repository
Re: [pacman-dev] [PATCH] doc/makepkg.8: Added punctuations.
On 14/7/20 6:25 am, foxbo...@archlinux.org wrote: > From: Morten Linderud > > Signed-off-by: Morten Linderud > --- > doc/makepkg.8.asciidoc | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/doc/makepkg.8.asciidoc b/doc/makepkg.8.asciidoc > index 544659fc..3b5e61b3 100644 > --- a/doc/makepkg.8.asciidoc > +++ b/doc/makepkg.8.asciidoc > @@ -274,7 +274,7 @@ Environment Variables > > **GPGKEY=**"keyid":: > Specify a key to use when signing packages, overriding the GPGKEY > setting > - in linkman:makepkg.conf[5] > + in linkman:makepkg.conf[5]. > OK. > **SOURCE_DATE_EPOCH=**"":: > Used for link:https://reproducible-builds.org/docs/[Reproducible > Builds]. > @@ -299,7 +299,7 @@ On exit, makepkg will return one of the following error > codes. > Error in configuration file. > > 3:: > - User specified an invalid option > + User specified an invalid option. OK. > > 4:: > Error in user-supplied function in PKGBUILD. >
Re: [pacman-dev] [PATCH] Check that destfile_name exists before using it
On 14/7/20 2:35 am, Anatol Pomozov wrote: > In some cases (when trust_remote_name is used for a URL without a filename and > no Content-Disposition is provided by the server) destfile_name will be > NULL. In this case payload data will be stored in tempfile_name and no > destfile_name is set. > > Signed-off-by: Anatol Pomozov > --- Thanks. A
Re: [pacman-dev] [PATCH] Build signature remote name based on the main payload name
On 14/7/20 2:35 am, Anatol Pomozov wrote: > The main payload final name might be affected by url redirects or > Content-Disposition HTTP header value. > > We want to make sure that accompanion *.sig filename always matches the > package filename. So ignore finalname/Content-Disposition for the *.sig file. > > It also helps to fix a corner case when the download URL does not contain > a filename and server provides Content-Disposition for the main payload > but not for the signature payload. > > Signed-off-by: Anatol Pomozov > --- Looks good. Thanks. A
[pacman-dev] [GIT] The official pacman repository branch, master, updated. v5.2.1-105-gb01bcc7d
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "The official pacman repository".
The branch, master has been updated
via b01bcc7d3d680856bd60c4ae03e4ba3f6d889cb2 (commit)
via f3dfba73d22b7eca3810a8114f2aab63da488b4c (commit)
via 78d6dcec6c49bd2fa830237a46fd14337bc9fd4c (commit)
via 34ba8d984d89393ab85ca67724b87af67ff004c3 (commit)
via f078c2d3bcb72bafda0dce5fe2c9418ca462bb1a (commit)
from 6b9c1b4d54225b4c2808b5fadc2b6e779ae1916a (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
commit b01bcc7d3d680856bd60c4ae03e4ba3f6d889cb2
Author: Anatol Pomozov
Date: Tue May 26 19:12:08 2020 -0700
Fallback to detached signatures during keyring check
Pacman has a 'key in keyring' verification step that makes sure the
signatures
have a valid keyid. Currently pacman parses embedded package signatures
only.
Add a fallback to detached signatures. If embedded signature is missing
then it
tries to read corresponding *.sig file and get keyid from there.
Verification:
debug: found cached pkg:
/var/cache/pacman/pkg/glib-networking-2.64.3-1-x86_64.pkg.tar.zst
debug: found detached signature
/var/cache/pacman/pkg/glib-networking-2.64.3-1-x86_64.pkg.tar.zst.sig with size
310
debug: found signature key: A5E9288C4FA415FA
debug: looking up key A5E9288C4FA415FA locally
debug: key lookup success, key exists
Signed-off-by: Anatol Pomozov
Signed-off-by: Allan McRae
commit f3dfba73d22b7eca3810a8114f2aab63da488b4c
Author: Anatol Pomozov
Date: Mon May 18 14:30:04 2020 -0700
FS#33992: force download *.sig file if it does not exist in the cache
In case if *.pkg exists but *.sig file does not we still have to pass
the pkg to multi_download API.
To avoid redownloading *.pkg file we use CURLOPT_TIMECONDITION curl option.
Signed-off-by: Anatol Pomozov
Signed-off-by: Allan McRae
commit 78d6dcec6c49bd2fa830237a46fd14337bc9fd4c
Author: Anatol Pomozov
Date: Thu Apr 23 17:28:43 2020 -0700
Add a utility function to check whether a file exists in the cache
It is similar to _alpm_filecache_find() but does not return a
dynamically allocated memory to user. Thus the user does not need to
free this resource.
Signed-off-by: Anatol Pomozov
Signed-off-by: Allan McRae
commit 34ba8d984d89393ab85ca67724b87af67ff004c3
Author: Anatol Pomozov
Date: Mon May 18 14:13:11 2020 -0700
Do not use counter for error tracking
Current code uses an incrementing counter to check whether a function
returned error:
errors += some_function();
if(errors) { goto finish }
Replace with a more standard variable
errors = some_function();
if(errors) { goto finish }
Rename 'errors' variable to a more typical 'ret'.
Avoid reporting both ALPM_EVENT_PKG_RETRIEVE_FAILED and
ALPM_EVENT_PKG_RETRIEVE_DONE in the error path.
Signed-off-by: Anatol Pomozov
Signed-off-by: Allan McRae
commit f078c2d3bcb72bafda0dce5fe2c9418ca462bb1a
Author: Anatol Pomozov
Date: Tue May 12 15:26:38 2020 -0700
Move signature payload creation to download engine
Until now callee of ALPM download functionality has been in charge of
payload creation both for the main file (e.g. *.pkg) and for the accompanied
*.sig file. One advantage of such solution is that all payloads are
independent and can be fetched in parallel thus exploiting the maximum
level of download parallelism.
To build *.sig file url we've been using a simple string concatenation:
$requested_url + ".sig". Unfortunately there are cases when it does not
work. For example an archlinux.org "Download From Mirror" link looks like
this https://www.archlinux.org/packages/core/x86_64/bash/download/ and
it gets redirected to some mirror. But if we append ".sig" to the end of
the link url and try to download it then archlinux.org returns 404 error.
To overcome this issue we need to follow redirects for the main payload
first, find the final url and only then append '.sig' suffix.
This implies 2 things:
- the signature payload initialization need to be moved to dload.c
as it is the place where we have access to the resolved url
- *.sig is downloaded serially with the main payload and this reduces
level of parallelism
Move *.sig payload creation to dload.c. Once the main payload is fetched
successfully we check if the callee asked to download the accompanied
signature. If yes - create a new payload and add
[pacman-dev] [GIT] The official pacman repository branch, master, updated. v5.2.1-100-g6b9c1b4d
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "The official pacman repository".
The branch, master has been updated
via 6b9c1b4d54225b4c2808b5fadc2b6e779ae1916a (commit)
via 84723cab5dfc9b7f4594135295974f771ceb6e5e (commit)
via 16d98d657748fdbf32ab24db56d3cd4a23447673 (commit)
from 59e751f72d09390067045168ac45a09a89419389 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
commit 6b9c1b4d54225b4c2808b5fadc2b6e779ae1916a
Author: Denton Liu
Date: Thu Jun 25 19:29:40 2020 -0400
srcinfo.sh: remove trailing newline
When a .SRCINFO file is generated via `makepkg --printsrcinfo`, each
section is concluded with an empty line. This means that at the end of
the file, an empty line remains. This is considered a trailing
whitespace error. In fact, `git diff --check` will warn about this,
saying "new blank line at EOF."
Instead of closing each section off with an empty line, use the empty
line to separate sections, omitting the empty line at the end of the
file.
Signed-off-by: Denton Liu
Signed-off-by: Allan McRae
commit 84723cab5dfc9b7f4594135295974f771ceb6e5e
Author: Anatol Pomozov
Date: Mon Apr 20 01:42:53 2020 -0700
Cleanup the old sequential download code
All users of _alpm_download() have been refactored to the new API.
It is time to remove the old _alpm_download() functionality now.
This change also removes obsolete SIGPIPE signal handler functionality
(this is a leftover from libfetch days).
Signed-off-by: Anatol Pomozov
commit 16d98d657748fdbf32ab24db56d3cd4a23447673
Author: Anatol Pomozov
Date: Sun Apr 19 02:12:01 2020 -0700
Convert '-U pkg1 pkg2' codepath to parallel download
Installing remote packages using its URL is an interesting case for ALPM
API. Unlike package sync ('pacman -S pkg1 pkg2') '-U' does not deal with
server mirror list. Thus _alpm_multi_download() should be able to
handle file download for payloads that either have 'fileurl' field
or pair of fields ('servers' and 'filepath') set.
Signature for alpm_fetch_pkgurl() has changed and it accepts an
output list that is populated with filepaths to fetched packages.
Signed-off-by: Anatol Pomozov
---
Summary of changes:
lib/libalpm/alpm.h | 15 +-
lib/libalpm/be_sync.c| 2 +-
lib/libalpm/dload.c | 552 ++-
lib/libalpm/dload.h | 11 +-
lib/libalpm/sync.c | 2 +-
scripts/libmakepkg/srcinfo.sh.in | 5 +-
src/pacman/upgrade.c | 102
7 files changed, 204 insertions(+), 485 deletions(-)
hooks/post-receive
--
The official pacman repository
Re: [pacman-dev] [PATCH v2] srcinfo.sh: remove trailing newline
On 26/6/20 9:29 am, Denton Liu wrote:
> When a .SRCINFO file is generated via `makepkg --printsrcinfo`, each
> section is concluded with an empty line. This means that at the end of
> the file, an empty line remains. This is considered a trailing
> whitespace error. In fact, `git diff --check` will warn about this,
> saying "new blank line at EOF."
>
> Instead of closing each section off with an empty line, use the empty
> line to separate sections, omitting the empty line at the end of the
> file.
>
> Signed-off-by: Denton Liu
> ---
Patch looks fine. Will be in the next push.
A
> scripts/libmakepkg/srcinfo.sh.in | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/scripts/libmakepkg/srcinfo.sh.in
> b/scripts/libmakepkg/srcinfo.sh.in
> index 6e783279..d1e39f7d 100644
> --- a/scripts/libmakepkg/srcinfo.sh.in
> +++ b/scripts/libmakepkg/srcinfo.sh.in
> @@ -30,7 +30,7 @@ srcinfo_open_section() {
> printf '%s = %s\n' "$1" "$2"
> }
>
> -srcinfo_close_section() {
> +srcinfo_separate_section() {
> echo
> }
>
> @@ -94,7 +94,6 @@ srcinfo_write_global() {
>
> srcinfo_open_section 'pkgbase' "${pkgbase:-$pkgname}"
> srcinfo_write_section_details ''
> - srcinfo_close_section
> }
>
> srcinfo_write_package() {
> @@ -104,7 +103,6 @@ srcinfo_write_package() {
>
> srcinfo_open_section 'pkgname' "$1"
> srcinfo_write_section_details "$1"
> - srcinfo_close_section
> }
>
> write_srcinfo_header() {
> @@ -118,6 +116,7 @@ write_srcinfo_content() {
> srcinfo_write_global
>
> for pkg in "${pkgname[@]}"; do
> + srcinfo_separate_section
> srcinfo_write_package "$pkg"
> done
> }
>
Re: [pacman-dev] [PATCH] makepkg: libprovides: don't provide both versioned and unversioned sonames
On 15/5/20 3:05 am, Eli Schwartz wrote:
> If multiple files match the pattern libfoo.so*, we want to check each of
> them and see if they are shared libraries, and if so, if they have
> versions attached.
>
> But some packages can have both shared libraries and random files which
> match the filename pattern. This is true at least for files in
> /usr/share/gdb/auto-load/, which must match the filename they are paired
> with, followed by "-gdb.py" (or some other gdb scripting ext), but
> definitely don't contain a shared library. In this case, we don't want
> to double-report the library in the generated provides.
>
> It's also possible (probably) for a package to provide a versioned as
> well as an unversioned shared library, but in such cases a single
> provides entry is sufficient to cover both cases (and the libdepends
> for the depending package would contain an unversioned dependency).
>
> Solve this by keeping track of whether we have added a versioned soname
> provides already, and then only adding a maximum of one unversioned
> provides *iff* there isn't a versioned one yet.
>
> Signed-off-by: Eli Schwartz
> ---
This patch is fine, but I don't like "newp" as a variable name. It will
not help me understand this in a years time.
How about versioned_provides=() instead?
>
> Notes:
> Currently we only have gdb/auto-load/ scripts for shared libraries in:
> - gcc
> - glib2
> - gstreamer
> - efl
>
> In the first 3 cases, libprovides is entirely useless anyway.
>
> libstdc++ is perpetually stable (backwards-compatible ABI) just like
> glibc.
Except when it did get an soname bump... Those were the days!
> glib2 actually does use libprovides, despite that it makes no sense for
> glib2
> to libprovide anything, as the glib2 developers have this thing where they
> always use a soname of "0" and bump ABI versions by changing
> libglib-2.0.so to
> libglib-3.0.so -- as a result if you want to track dependencies you need
> to
> change to a different soname manually, and might as well just depend on
> the
> package itself (which already has a version in the pkgname).
>
> (gstreamer is in the same boat as glib2 because it is part of the same
> ecosystem.)
>
> efl doesn't currently libprovide "libeo.so", but if it did, then the issue
> would exist and be fixed by this patch. And more generally, any project
> wishing
> to implement gdb/auto-load/ scripts could have this issue, so it makes
> sense to
> make it work nicely.
>
> scripts/makepkg.sh.in | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in
> index d1416d15..3f746b77 100644
> --- a/scripts/makepkg.sh.in
> +++ b/scripts/makepkg.sh.in
> @@ -516,9 +516,10 @@ find_libdepends() {
>
>
> find_libprovides() {
> - local p libprovides missing
> + local p newp libprovides missing
> for p in "${provides[@]}"; do
> missing=0
> + newp=()
> case "$p" in
> *.so)
> mapfile -t filename < <(find "$pkgdir" -type f
> -name $p\*)
> @@ -531,7 +532,6 @@ find_libprovides() {
> local sofile=$(LC_ALL=C
> readelf -d "$fn" 2>/dev/null | sed -n 's/.*Library soname: \[\(.*\)\].*/\1/p')
> if [[ -z "$sofile" ]];
> then
> warning
> "$(gettext "Library listed in %s is not versioned: %s")" "'provides'" "$p"
> -
> libprovides+=("$p")
> continue
> fi
>
> @@ -541,25 +541,25 @@ find_libprovides() {
> # extract the library
> major version
> local
> soversion="${sofile##*\.so\.}"
>
> -
> libprovides+=("${p}=${soversion}-${soarch}")
> +
> newp+=("${p}=${soversion}-${soarch}")
> else
> warning "$(gettext
> "Library listed in %s is not a shared object: %s")" "'provides'" "$p"
> - libprovides+=("$p")
> fi
> done
> else
> - libprovides+=("$p")
> missing=1
> fi
> ;;
> - *)
> - libprovides+=("$p")
> -
Re: [pacman-dev] Fix srcinfo sometimes printing double newline at the end
On 26/6/20 9:27 am, Denton Liu wrote: > Hi Marti, > > On Fri, Jun 26, 2020 at 01:09:54AM +0200, Martin Rys wrote: >> Hi, >> this is a bit of an OCD thing, but `makepkg --printsrcinfo` usually >> generates a file with two newlines at the end. > > I agree with you, this bugs me a lot too. > > [...] > >> Which seems to always print out a newline, so I believe the >> srcinfo_close_section function is not needed there and simply >> removing it and the two lines that call it would solve this issue, as >> per the patchfile in the attachment. > > I proposed a similar patch recently[0] but it was rejected as the > newline separators are apparently part of the spec so they should be > retained[1]. I sent out another patch after that only removes the final > newline but it wasn't reviewed so I thought that the pacman devs thought > it was a non-issue. Since you seem to agree with me, though, I'll resend > that patch and hopefully it'll be reviewed this time around. > Please do not resend patches. We have a patch tracking system, which means patches are never lost. I have given this patch a very low priority. That means with limited time available to me, I will likely review other patches first. But it will get considered at some stage. Allan
Re: [pacman-dev] Unable to join translation team
On 24/6/20 8:28 pm, Lukáš Kucharczyk wrote: > Hello, > > I have requested joining the Czech translation team more than a week ago and > as far as I can see, there has been no activity since then. The organization > name is "toofishes" but I cannot find a way to contact the person in charge > via Transifex to ask what is the issue. What are my other options? > > Lukas Kucharczyk Hi, I usually only look at translations every couple of months, or in the lead up to release. You have now been approved to translate. As a note for others that I have not approved - I do not add people to teams that have complete translations. More people does not lead to better translations. Allan
[pacman-dev] [GIT] The official pacman repository branch, master, updated. v5.2.1-97-g59e751f7
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "The official pacman repository". The branch, master has been updated via 59e751f72d09390067045168ac45a09a89419389 (commit) via 7ba8e5f376528fcef9f7613304d8f18b2f664ee8 (commit) from 02ae97b0da220d9079c6c2c1ac3e3ab0d12c1ac7 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit 59e751f72d09390067045168ac45a09a89419389 Author: Eli Schwartz Date: Sun Jun 14 14:52:02 2020 -0400 doc/pacman.8: fix typo Fixes FS#67000 Signed-off-by: Eli Schwartz Signed-off-by: Allan McRae commit 7ba8e5f376528fcef9f7613304d8f18b2f664ee8 Author: Allan McRae Date: Mon Jun 15 19:17:41 2020 +1000 pacman-key: change signing key to RSA4096 RSA2048 may have been fine when this was written many moons ago, but time this has a bump. Signed-off-by: Allan McRae --- Summary of changes: doc/pacman.8.asciidoc| 2 +- scripts/pacman-key.sh.in | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) hooks/post-receive -- The official pacman repository
[pacman-dev] [GIT] The official pacman repository branch, release/5.2.x, updated. v5.2.1-25-g50f5e484
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "The official pacman repository". The branch, release/5.2.x has been updated via 50f5e484f278d3550da71246bfb51d3d8053bae8 (commit) from 1e9cd30e488cd133d24eac7ed9cac7806db2c406 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit 50f5e484f278d3550da71246bfb51d3d8053bae8 Author: Allan McRae Date: Fri Jun 19 09:49:28 2020 +1000 Pull translation updates Signed-off-by: Allan McRae --- Summary of changes: lib/libalpm/po/ar.po | 28 ++--- lib/libalpm/po/ast.po | 34 +++--- lib/libalpm/po/bg.po | 28 ++--- lib/libalpm/po/br.po | 28 ++--- lib/libalpm/po/ca.po | 28 ++--- lib/libalpm/po/cs.po | 28 ++--- lib/libalpm/po/da.po | 28 ++--- lib/libalpm/po/de.po | 45 lib/libalpm/po/el.po | 56 - lib/libalpm/po/en_GB.po | 28 ++--- lib/libalpm/po/eo.po | 262 +- lib/libalpm/po/es.po | 28 ++--- lib/libalpm/po/es_419.po | 32 +++--- lib/libalpm/po/eu.po | 28 ++--- lib/libalpm/po/eu_ES.po | 28 ++--- lib/libalpm/po/fi.po | 28 ++--- lib/libalpm/po/fr.po | 28 ++--- lib/libalpm/po/gl.po | 28 ++--- lib/libalpm/po/hr.po | 28 ++--- lib/libalpm/po/hu.po | 28 ++--- lib/libalpm/po/id.po | 28 ++--- lib/libalpm/po/it.po | 34 +++--- lib/libalpm/po/ja.po | 28 ++--- lib/libalpm/po/kk.po | 28 ++--- lib/libalpm/po/ko.po | 30 ++--- lib/libalpm/po/libalpm.pot| 28 ++--- lib/libalpm/po/lt.po | 28 ++--- lib/libalpm/po/nb.po | 28 ++--- lib/libalpm/po/nl.po | 28 ++--- lib/libalpm/po/pl.po | 41 +++ lib/libalpm/po/pt.po | 28 ++--- lib/libalpm/po/pt_BR.po | 28 ++--- lib/libalpm/po/ro.po | 32 +++--- lib/libalpm/po/ru.po | 28 ++--- lib/libalpm/po/sk.po | 32 +++--- lib/libalpm/po/sl.po | 30 ++--- lib/libalpm/po/sr.po | 28 ++--- lib/libalpm/po/s...@latin.po| 28 ++--- lib/libalpm/po/sv.po | 55 - lib/libalpm/po/tr.po | 36 +++--- lib/libalpm/po/uk.po | 28 ++--- lib/libalpm/po/zh_CN.po | 47 lib/libalpm/po/zh_TW.po | 28 ++--- scripts/po/bg.po | 176 ++-- scripts/po/br.po | 176 ++-- scripts/po/ca.po | 176 ++-- scripts/po/cs.po | 176 ++-- scripts/po/da.po | 176 ++-- scripts/po/de.po | 208 + scripts/po/el.po | 216 +- scripts/po/en_GB.po | 176 ++-- scripts/po/eo.po | 203 scripts/po/es.po | 176 ++-- scripts/po/es_419.po | 180 ++--- scripts/po/eu.po | 176 ++-- scripts/po/eu_ES.po | 176 ++-- scripts/po/fi.po | 176 ++-- scripts/po/fr.po | 178 ++-- scripts/po/gl.po | 176 ++-- scripts/po/hu.po | 176 ++-- scripts/po/id.po | 176 ++-- scripts/po/it.po | 180 ++--- scripts/po/ja.po | 176 ++-- scripts/po/ko.po | 176 ++-- scripts/po/lt.po | 176 ++-- scripts/po/nb.po | 182 ++--- scripts/po/nl.po | 176 ++-- scripts/po/pacman-scripts.pot | 176 ++-- scripts/po/pl.po | 215 +- scripts/po/pt.po | 176 ++-- scripts/po/pt_BR.po | 176 ++-- scripts/po/ro.po | 176 ++-- scripts/po/ru.po | 176 ++-- scripts/po/sk.po | 180 ++--- scripts/po/sl.po | 203 scripts/po/sr.po | 176 ++-- sc
[pacman-dev] [PATCH] pacman-key: change signing key to RSA4096
RSA2048 may have been fine when this was written many moons ago, but time
this has a bump.
Signed-off-by: Allan McRae
---
scripts/pacman-key.sh.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/pacman-key.sh.in b/scripts/pacman-key.sh.in
index 3e952c1b..ccfd1b96 100644
--- a/scripts/pacman-key.sh.in
+++ b/scripts/pacman-key.sh.in
@@ -148,7 +148,7 @@ generate_master_key() {
"${GPG_PACMAN[@]}" --gen-key --batch <
Re: [pacman-dev] [PATCH] Move signature payload creation to download engine
On 14/5/20 8:15 am, Anatol Pomozov wrote:
> Until now callee of ALPM download functionality has been in charge of
> payload creation both for the main file (e.g. *.pkg) and for the accompanied
> *.sig file. One advantage of such solution is that all payloads are
> independent and can be fetched in parallel thus exploiting the maximum
> level of download parallelism.
>
> To build *.sig file url we've been using a simple string concatenation:
> $requested_url + ".sig". Unfortunately there are cases when it does not
> work. For example an archlinux.org "Download From Mirror" link looks like
> this https://www.archlinux.org/packages/core/x86_64/bash/download/ and
> it gets redirected to some mirror. But if we append ".sig" to the end of
> the link url and try to download it then archlinux.org returns 404 error.
>
> To overcome this issue we need to follow redirects for the main payload
> first, find the final url and only then append '.sig' suffix.
> This implies 2 things:
> - the signature payload initialization need to be moved to dload.c
> as it is the place where we have access to the resolved url
> - *.sig is downloaded serially with the main payload and this reduces
> level of parallelism
>
> Move *.sig payload creation to dload.c. Once the main payload is fetched
> successfully we check if the callee asked to download the accompanied
> signature. If yes - create a new payload and add it to mcurl.
>
> *.sig payload does not use server list of the main payload and thus does
> not support mirror failover. *.sig file comes from the same server as
> the main payload.
>
> Refactor event loop in curl_multi_download_internal() a bit. Instead of
> relying on curl_multi_check_finished_download() to return number of new
> payloads we simply rerun the loop iteration one more time to check if
> there are any active downloads left.
> ---
> lib/libalpm/be_sync.c | 34 +++-
> lib/libalpm/dload.c | 91 ++-
> lib/libalpm/dload.h | 4 +-
> 3 files changed, 65 insertions(+), 64 deletions(-)
>
> diff --git a/lib/libalpm/be_sync.c b/lib/libalpm/be_sync.c
> index 82018e15..41675d21 100644
> --- a/lib/libalpm/be_sync.c
> +++ b/lib/libalpm/be_sync.c
> @@ -180,12 +180,10 @@ int SYMEXPORT alpm_db_update(alpm_handle_t *handle,
> alpm_list_t *dbs, int force)
> dbforce = 1;
> }
>
> - CALLOC(payload, 1, sizeof(*payload), GOTO_ERR(handle,
> ALPM_ERR_MEMORY, cleanup));
> + siglevel = alpm_db_get_siglevel(db);
>
> - /* set hard upper limit of 128 MiB */
> - payload->max_size = 128 * 1024 * 1024;
> + CALLOC(payload, 1, sizeof(*payload), GOTO_ERR(handle,
> ALPM_ERR_MEMORY, cleanup));
> payload->servers = db->servers;
> -
> /* print server + filename into a buffer */
> len = strlen(db->treename) + strlen(dbext) + 1;
> MALLOC(payload->filepath, len,
> @@ -194,31 +192,11 @@ int SYMEXPORT alpm_db_update(alpm_handle_t *handle,
> alpm_list_t *dbs, int force)
> payload->handle = handle;
> payload->force = dbforce;
> payload->unlink_on_fail = 1;
> -
> + payload->download_signature = (siglevel & ALPM_SIG_DATABASE);
> + payload->signature_optional = (siglevel &
> ALPM_SIG_DATABASE_OPTIONAL);
> + /* set hard upper limit of 128 MiB */
> + payload->max_size = 128 * 1024 * 1024;
> payloads = alpm_list_add(payloads, payload);
OK.
> -
> - siglevel = alpm_db_get_siglevel(db);
> - if(siglevel & ALPM_SIG_DATABASE) {
> - struct dload_payload *sig_payload;
> - CALLOC(sig_payload, 1, sizeof(*sig_payload),
> GOTO_ERR(handle, ALPM_ERR_MEMORY, cleanup));
> - sig_payload->signature = 1;
> -
> - /* print filename into a buffer (leave space for
> separator and .sig) */
> - len = strlen(db->treename) + strlen(dbext) + 5;
> - MALLOC(sig_payload->filepath, len,
> - FREE(sig_payload); GOTO_ERR(handle,
> ALPM_ERR_MEMORY, cleanup));
> - snprintf(sig_payload->filepath, len, "%s%s.sig",
> db->treename, dbext);
> -
> - sig_payload->handle = handle;
> - sig_payload->force = dbforce;
> - sig_payload->errors_ok = (siglevel &
> ALPM_SIG_DATABASE_OPTIONAL);
> -
> - /* set hard upper limit of 16 KiB */
> - sig_payload->max_size = 16 * 1024;
> - sig_payload->servers = db->servers;
> -
> - payloads = alpm_list_add(payloads, sig_payload);
> - }
> }
>
> event.type = ALPM_EVENT_DB_RETRIEVE_START;
OK.
> diff --git a/lib/libalpm/dload.c b/lib/libalpm/dload.c
> index 4dbb011f..b68dcf6d 100644
> ---
Re: [pacman-dev] [PATCH] Cleanup the old sequential download code
On 12/5/20 3:16 am, Anatol Pomozov wrote:
> All users of _alpm_download() have been refactored to the new API.
> It is time to remove the old _alpm_download() functionality now.
>
> This change also removes obsolete SIGPIPE signal handler functionality
> (this is a leftover from libfetch days).
>
> Signed-off-by: Anatol Pomozov
> ---
> lib/libalpm/dload.c | 323 +---
> lib/libalpm/dload.h | 4 -
> 2 files changed, 3 insertions(+), 324 deletions(-)
>
> diff --git a/lib/libalpm/dload.c b/lib/libalpm/dload.c
> index 43fe9847..4dbb011f 100644
> --- a/lib/libalpm/dload.c
> +++ b/lib/libalpm/dload.c
> @@ -78,10 +78,6 @@ enum {
> };
>
> static int dload_interrupted;
> -static void inthandler(int UNUSED signum)
> -{
> - dload_interrupted = ABORT_SIGINT;
> -}
>
> static int dload_progress_cb(void *file, curl_off_t dltotal, curl_off_t
> dlnow,
> curl_off_t UNUSED ultotal, curl_off_t UNUSED ulnow)
> @@ -236,8 +232,7 @@ static size_t dload_parseheader_cb(void *ptr, size_t
> size, size_t nmemb, void *u
> return realsize;
> }
>
> -static void curl_set_handle_opts(struct dload_payload *payload,
> - CURL *curl, char *error_buffer)
> +static void curl_set_handle_opts(CURL *curl, struct dload_payload *payload)
> {
This change seems beyond the scope for this patch. Can you split that
and the other related changes below into a separate patch.
Otherwise fine.
A
Re: [pacman-dev] [PATCH] Convert '-U pkg1 pkg2' codepath to parallel download
On 11/5/20 6:50 pm, Anatol Pomozov wrote:
> Installing remote packages using its URL is an interesting case for ALPM
> API. Unlike package sync ('pacman -S pkg1 pkg2') '-U' does not deal with
> server mirror list. Thus _alpm_multi_download() should be able to
> handle file download for payloads that either have 'fileurl' field
> or pair of fields ('servers' and 'filepath') set.
>
> Signature for alpm_fetch_pkgurl() has changed and it accepts an
> output list that is populated with filepaths to fetched packages.
>
> Signed-off-by: Anatol Pomozov
Thanks. Very minor comments belown.
> ---
> lib/libalpm/alpm.h | 11 ++-
> lib/libalpm/dload.c | 204 +--
> lib/libalpm/dload.h | 7 +-
> src/pacman/upgrade.c | 102 ++
> 4 files changed, 181 insertions(+), 143 deletions(-)
>
> diff --git a/lib/libalpm/alpm.h b/lib/libalpm/alpm.h
> index 3ea66ccc..c6a13273 100644
> --- a/lib/libalpm/alpm.h
> +++ b/lib/libalpm/alpm.h
> @@ -755,12 +755,15 @@ typedef void (*alpm_cb_totaldl)(off_t total);
> typedef int (*alpm_cb_fetch)(const char *url, const char *localpath,
> int force);
>
> -/** Fetch a remote pkg.
> +/** Fetch a list of remote packages.
> * @param handle the context handle
> - * @param url URL of the package to download
> - * @return the downloaded filepath on success, NULL on error
> + * @param urls list of package URLs to download
> + * @param fetched list of filepaths to the fetched packages, each item
> + *corresponds to one in `urls` list
Can you make it clear that this is filled by the function, and not
something that should be passed.
> + * @return 0 on success or -1 on failure
> */
> -char *alpm_fetch_pkgurl(alpm_handle_t *handle, const char *url);
> +int alpm_fetch_pkgurl(alpm_handle_t *handle, const alpm_list_t *urls,
> + alpm_list_t **fetched);
>
> /** @addtogroup alpm_api_options Options
> * Libalpm option getters and setters
> diff --git a/lib/libalpm/dload.c b/lib/libalpm/dload.c
> index 13aa4086..43fe9847 100644
> --- a/lib/libalpm/dload.c
> +++ b/lib/libalpm/dload.c
> @@ -613,7 +613,9 @@ static int curl_multi_retry_next_server(CURLM *curlm,
> CURL *curl, struct dload_p
> size_t len;
> alpm_handle_t *handle = payload->handle;
>
> - payload->servers = payload->servers->next;
> + if(payload->servers) {
> + payload->servers = payload->servers->next;
> + }
OK.
> if(!payload->servers) {
> _alpm_log(payload->handle, ALPM_LOG_DEBUG,
> "%s: no more servers to retry\n",
> payload->remote_name);
> @@ -622,7 +624,7 @@ static int curl_multi_retry_next_server(CURLM *curlm,
> CURL *curl, struct dload_p
> server = payload->servers->data;
>
> /* regenerate a new fileurl */
> - free(payload->fileurl);
> + FREE(payload->fileurl);
Change unrelated to this patch, but OK.
> len = strlen(server) + strlen(payload->filepath) + 2;
> MALLOC(payload->fileurl, len, RET_ERR(handle, ALPM_ERR_MEMORY, -1));
> snprintf(payload->fileurl, len, "%s/%s", server, payload->filepath);
> @@ -849,20 +851,28 @@ static int curl_multi_add_payload(alpm_handle_t
> *handle, CURLM *curlm,
> struct dload_payload *payload, const char *localpath)
> {
> size_t len;
> - const char *server;
> CURL *curl = NULL;
> char hostname[HOSTNAME_SIZE];
> int ret = -1;
>
> - ASSERT(payload->servers, RET_ERR(handle, ALPM_ERR_SERVER_NONE, -1));
> - server = payload->servers->data;
> -
> curl = curl_easy_init();
> payload->curl = curl;
>
> - len = strlen(server) + strlen(payload->filepath) + 2;
> - MALLOC(payload->fileurl, len, GOTO_ERR(handle, ALPM_ERR_MEMORY,
> cleanup));
> - snprintf(payload->fileurl, len, "%s/%s", server, payload->filepath);
> + if(payload->fileurl) {
> + ASSERT(!payload->servers, GOTO_ERR(handle, ALPM_ERR_WRONG_ARGS,
> cleanup));
> + ASSERT(!payload->filepath, GOTO_ERR(handle,
> ALPM_ERR_WRONG_ARGS, cleanup));
OK.
> + } else {
> + const char *server;
> +
> + ASSERT(payload->servers, GOTO_ERR(handle, ALPM_ERR_SERVER_NONE,
> cleanup));
> + ASSERT(payload->filepath, GOTO_ERR(handle, ALPM_ERR_WRONG_ARGS,
> cleanup));
> +
> + server = payload->servers->data;
> +
> + len = strlen(server) + strlen(payload->filepath) + 2;
> + MALLOC(payload->fileurl, len, GOTO_ERR(handle, ALPM_ERR_MEMORY,
> cleanup));
> + snprintf(payload->fileurl, len, "%s/%s", server,
> payload->filepath);
> + }
>
OK.
> payload->tempfile_openmode = "wb";
> if(!payload->remote_name) {
> @@ -1046,22 +1056,29 @@ int _alpm_multi_download(alpm_handle_t *handle,
> alpm_list_t *s;
> int success = 0;
>
> - for(s = payload->servers; s; s = s->next) {
> -
[pacman-dev] [GIT] The official pacman repository branch, master, updated. v5.2.1-95-g02ae97b0
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "The official pacman repository".
The branch, master has been updated
via 02ae97b0da220d9079c6c2c1ac3e3ab0d12c1ac7 (commit)
via 899d39b635d46f9e2daff1aada75ea07f08fef64 (commit)
via bf458cced7c0845f7b6fabb887d3878ae4cd51b2 (commit)
via 381e11375569fa7588b1297e0e744749bdafe8f5 (commit)
via 817f9fb715b4e90d28bc141dfccfc530b9e951dc (commit)
via 3bd88821bbfc8066a63ddfc9959e78984bc17750 (commit)
via e348ba38814c9cc7c1c9892d0451096234dc39ab (commit)
via 40bbaead44db8fcdef7087f4b05820bf90dee090 (commit)
from 5f6ef895b1dac04c7fb1b63acab2d42c19f91922 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
commit 02ae97b0da220d9079c6c2c1ac3e3ab0d12c1ac7
Author: Eli Schwartz
Date: Mon Jun 8 22:03:18 2020 -0400
makepkg/repo-add: do not accept public-only keys for signing
If it's not listed by --list-secret-key we don't care if it has been
imported into your keyring, it's unusable. And you might not have a
private key at all in the no-keyid-specified case.
Signed-off-by: Eli Schwartz
Signed-off-by: Allan McRae
commit 899d39b635d46f9e2daff1aada75ea07f08fef64
Author: Eli Schwartz
Date: Mon Jun 8 21:59:18 2020 -0400
makepkg/repo-add: handle GPGKEY with spaces
We pass this to gpg -u and this gpg option can accept a number of
different formats, not just the historical hexadecimal fingerprint we
assumed. We should not barf hard if a format is used which happens to
contain spaces.
This also fixes a validation bug. When we initially check if the desired
key is available, we don't quote spaces, so gpg goes ahead and treats
each space-separated string as a *different key* to search for,
returning partial matches, and returning success if at least one key is
found. But gpg --detach-sign -u will certainly not accept multiple keys!
Fixes FS#66949
Signed-off-by: Eli Schwartz
Signed-off-by: Allan McRae
commit bf458cced7c0845f7b6fabb887d3878ae4cd51b2
Author: Eli Schwartz
Date: Tue Jun 2 17:50:24 2020 -0400
libmakepkg: fix regression in sending plain() output to stderr
In commit 882e707e40bbade0111cf3bdedbdac4d4b70453b we changed message
output to go to stdout by default, unless it was an error. The plain()
function doesn't *look* like an error function, but in practice it was
-- it's used to continue multiline messages, and all in-tree uses were
for warning/error.
This is a problem both because we're sending output to the wrong place,
and because in some cases, we were performing error logging from a
function which would otherwise return a value to be captured in a
variable using command substution.
Fix this and straighten out the API by providing two functions: one for
continuing msg output, and one which wraps this by sending output to
stderr, for continuing error output.
Change all callers to use the second function.
commit 381e11375569fa7588b1297e0e744749bdafe8f5
Author: Eli Schwartz
Date: Tue Jun 2 18:16:48 2020 -0400
makepkg: correctly handle missing download clients
This was broken in commit 882e707e40bbade0111cf3bdedbdac4d4b70453b,
which changed 'plain()' messages to go to stdout, which was then
captured as the download client in question: cmdline=("Aborting...").
The result was a very confusing error message e.g.
/usr/share/makepkg/source/file.sh: line 72: $'\E[1m': command not found
or with makepkg --nocolor:
/usr/share/makepkg/source/file.sh: line 72: Aborting...: command not found
The problem here is that we checked to see if an asynchronous subshell,
in our case <(...), failed, by checking if its captured stdout is
non-empty. Which is terrible, and also a limitation of old bash. But
bash 4.4 can use wait $! to retrieve the return value of an asynchronous
subshell. Now we target that as our minimum, we can sanely handle errors
in such functions.
Losing error messages on stdout by capturing them in a variable instead
of printing them, continues to be a problem, but this will be fixed
systematically in a later commit.
Signed-off-by: Eli Schwartz
Signed-off-by: Allan McRae
commit 817f9fb715b4e90d28bc141dfccfc530b9e951dc
Author: Eli Schwartz
Date: Mon May 25 23:52:16 2020 -0400
makepkg: guard against undefined git pinned sources
If something like source=(..."#commit=") is used, e.g. due to failed
variable expansion, we try to check out an empty refsp
Re: [pacman-dev] [PATCH v2] makepkg/repo-add: handle GPGKEY with spaces
On 9/6/20 11:59 am, Eli Schwartz wrote: > We pass this to gpg -u and this gpg option can accept a number of > different formats, not just the historical hexadecimal fingerprint we > assumed. We should not barf hard if a format is used which happens to > contain spaces. > > This also fixes a validation bug. When we initially check if the desired > key is available, we don't quote spaces, so gpg goes ahead and treats > each space-separated string as a *different key* to search for, > returning partial matches, and returning success if at least one key is > found. But gpg --detach-sign -u will certainly not accept multiple keys! > > Fixes FS#66949 > > Signed-off-by: Eli Schwartz > --- > > v2: fix case of GPGKEY="" with signing enabled reporting that no keys > exist in the keyring. Only expand the quoted GPGKEY if it is non-empty. > Ack.
Re: [pacman-dev] [PATCH v2 2/2] libmakepkg: fix regression in sending plain() output to stderr
On 3/6/20 8:16 am, Eli Schwartz wrote: > In commit 882e707e40bbade0111cf3bdedbdac4d4b70453b we changed message > output to go to stdout by default, unless it was an error. The plain() > function doesn't *look* like an error function, but in practice it was > -- it's used to continue multiline messages, and all in-tree uses were > for warning/error. > > This is a problem both because we're sending output to the wrong place, > and because in some cases, we were performing error logging from a > function which would otherwise return a value to be captured in a > variable using command substution. > > Fix this and straighten out the API by providing two functions: one for > continuing msg output, and one which wraps this by sending output to > stderr, for continuing error output. > > Change all callers to use the second function. > > Signed-off-by: Eli Schwartz > --- I did not see this patch before reviewing v1. This approach also looks fine to me. Pulling this version. Allan
Re: [pacman-dev] [PATCH] makepkg: guard against undefined git pinned sources
On 26/5/20 1:52 pm, Eli Schwartz wrote: > If something like source=(..."#commit=") is used, e.g. due to failed > variable expansion, we try to check out an empty refspec as nothing at > all, and end up just running "git checkout". This happens because we > fail at variable expansion too -- so let's quote our variables properly > and make sure git sees this as an empty refspec, so it can error out. > > Also make sure it is interpreted as a ref instead of a path. > > Signed-off-by: Eli Schwartz > --- > > This ensures that something like https://bugs.archlinux.org/task/66729 > cannot happen again. > Patch good. Worth checking if this can happen with other VCS too. A
Re: [pacman-dev] [PATCH] build: add libintl dependency to meson and the .pc file
On 19/5/20 5:18 am, Eli Schwartz wrote: > In order to use gettext on systems where it is not part of libc, the > correct linker flags are needed in libalpm.pc (for static compilation). > This has never been the case. > > The new meson build system currently only checks for ngettext in libc, > but does not fall back to searching for the existence of -lintl; add it > to the libalpm dependencies. > > Signed-off-by: Eli Schwartz > --- > > Fixes build on MSYS2, and possibly others. Part of > https://github.com/msys2/MSYS2-packages/pull/1951 > >From that pull request, I can see the patch has been tested in the land of MSYS2, so all good. A
Re: [pacman-dev] [PATCH] makepkg: correctly handle missing download clients
On 18/5/20 8:34 am, Eli Schwartz wrote:
> This was broken in commit 882e707e40bbade0111cf3bdedbdac4d4b70453b,
> which changed 'plain()' messages to go to stdout, which was then
> captured as the download client in question: cmdline=("Aborting...").
>
> The result was a very confusing error message e.g.
>
> /usr/share/makepkg/source/file.sh: line 72: $'\E[1m': command not found
>
> or with makepkg --nocolor:
>
> /usr/share/makepkg/source/file.sh: line 72: Aborting...: command not found
>
> Solve this on two levels:
> - redirect this error() continuation to stderr so the user sees it.
> - catch erroring returns in get_downloadclient and propagate them
>
> bash 4.4 can use wait $! to retrieve the return value of an asynchronous
> subshell such as <(...), which means, now we target that as our minimum,
> we can sanely handle errors in such functions.
>
> Signed-off-by: Eli Schwartz
> ---
>
> Actually, maybe every use of plain() needs to do this. Or else make
> plain() do this by default. But it's technically used to "continue the
> previous message", and there's no guarantee it merits going to stderr,
> even though every time we use plain(), it does.
> > What to do...
>
I can take this patch as is, but as you point out, this is a more
systemic issue with plain() always being used to follow error() or
warning() so all current usages should be on stderr. So I'd like two
patches - one dealing with global stderr output issue, and one with the
$! usage.
Options for plain() are, we manually add >&2 when needed, or we provide
a wrapper function that does that. My suggestion is:
plain() {
(( QUIET )) && return
local mesg=$1; shift
printf "${BOLD}${mesg}${ALL_OFF}\n" "$@"
}
bet rid of ${BOLD} for plain() and add a bold() function that prints to
stderr.
> scripts/libmakepkg/source/file.sh.in | 1 +
> scripts/libmakepkg/util/source.sh.in | 2 +-
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/scripts/libmakepkg/source/file.sh.in
> b/scripts/libmakepkg/source/file.sh.in
> index 819320c2..28f373fb 100644
> --- a/scripts/libmakepkg/source/file.sh.in
> +++ b/scripts/libmakepkg/source/file.sh.in
> @@ -42,6 +42,7 @@ download_file() {
> # find the client we should use for this URL
> local -a cmdline
> IFS=' ' read -a cmdline < <(get_downloadclient "$proto")
> + wait $! || exit
> (( ${#cmdline[@]} )) || exit
>
> local filename=$(get_filename "$netfile")
> diff --git a/scripts/libmakepkg/util/source.sh.in
> b/scripts/libmakepkg/util/source.sh.in
> index e0490661..1bf5b814 100644
> --- a/scripts/libmakepkg/util/source.sh.in
> +++ b/scripts/libmakepkg/util/source.sh.in
> @@ -165,7 +165,7 @@ get_downloadclient() {
> if [[ ! -x $program ]]; then
> local baseprog="${program##*/}"
> error "$(gettext "The download program %s is not installed.")"
> "$baseprog"
> - plain "$(gettext "Aborting...")"
> + plain "$(gettext "Aborting...")" >&2
> exit 1 # $E_MISSING_PROGRAM
> fi
>
>
Re: [pacman-dev] [PATCH] ci: cache packages
On 21/5/20 9:38 am, Filipe Laíns wrote: > Results in ~40s saved in each job. > > Signed-off-by: Filipe Laíns > --- Pulled. Thanks, A
Re: [pacman-dev] makepkg: package_...() can export variables to each other
On 5/6/20 5:39 pm, Erich Eckner wrote:
> Hi,
>
> I stumbled upon the fact, that variables set in one package_...()
> function of a split package are accessible by following package_...()
> functions. Is this by design or may I try to provide a patch to restore
> env after the call to package_...()?
> Note: packaging-relevant variables (e.g. depends_x86_64) are cleaned
> across function calls.
>
> Simple example:
>
> --8<--8<--8<--
> arch=(any)
> pkgbase=test
> pkgname=(ta tb)
> pkgver=0
> pkgrel=1
>
> package_ta() {
> _test='hi, there!'
> }
>
> package_tb() {
> echo "$_test"
> }
> -->8-->8-->8--
>
PKGBUILDs are bash. Bash scope rules apply.
Allan
Re: [pacman-dev] [PATCH] srcinfo.sh: remove trailing newline
On 4/6/20 9:26 am, Denton Liu wrote:
> When the .SRCINFO file is generated via `makepkg --printsrcinfo`, each
> section is concluded with an empty line. This means that at the end of
> the file, an empty line remains. When running `git diff --check`, Git
> will complain about this as a whitespace error, saying "new blank line
> at EOF."
>
> Remove the empty line after sections. Replace the empty echo with a
> placeholder `true` call in case in the future, we do want to close the
> section with something.
> ---
> scripts/libmakepkg/srcinfo.sh.in | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/libmakepkg/srcinfo.sh.in
> b/scripts/libmakepkg/srcinfo.sh.in
> index 6e783279..e7b5c4be 100644
> --- a/scripts/libmakepkg/srcinfo.sh.in
> +++ b/scripts/libmakepkg/srcinfo.sh.in
> @@ -31,7 +31,7 @@ srcinfo_open_section() {
> }
>
> srcinfo_close_section() {
> - echo
> + true # nothing to be done
> }
This is a very strange approach to implementing your idea. Now the
function is useless and should have been removed completely. And now
there is zero separate between sections - not just the last line was
removed.
Anyway, the justification for this patch is missing. Why does makepkg
care about a minor warning from "git diff --check"?
>
> srcinfo_write_attr() {
>
[pacman-dev] [GIT] The official pacman repository branch, master, updated. v5.2.1-87-g5f6ef895
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "The official pacman repository". The branch, master has been updated via 5f6ef895b1dac04c7fb1b63acab2d42c19f91922 (commit) via 23b50d60e34e324cf6f420c05293f7fa8a909623 (commit) via 3674144a74cfe897ec3ff46c18681df293290caa (commit) via 454ea024383eab60295e4c4fdf2c329475887b2c (commit) from 8ce142a2552418f64a74e773f659d92b065d6209 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit 5f6ef895b1dac04c7fb1b63acab2d42c19f91922 Author: Allan McRae Date: Wed May 20 14:17:11 2020 +1000 libalpm/signing.c: Fix calculation of packet size in parse_subpacket Given RFC 4880 provides the code to do this calculation, I am not sure how I managed to stuff that up! This bug was only exposed when a signature made with "include-key-block" was added to the Arch repos, which provided a subpacket with the required size to hit this issue. Signed-off-by: Allan McRae commit 23b50d60e34e324cf6f420c05293f7fa8a909623 Author: Dave Reisner Date: Wed May 13 14:43:53 2020 -0400 Avoid depending on side effects in assert(...) expressions When building with -DNDEBUG, assert statements are compiled out to no-ops. Thus, we can't depend on assignments or other computations occurring inside the assert(). Signed-off-by: Allan McRae commit 3674144a74cfe897ec3ff46c18681df293290caa Author: Eli Schwartz Date: Mon May 11 00:16:30 2020 -0400 libmakepkg/strip: don't re-add the same debug source multiple times It's either a waste of work, or triggers edge cases in some packages (like coreutils-8.31) where the source file is readonly and cp gets a permission denied error trying to overwrite it with an identical copy of itself. Also while we are at it, make the variable names be something readable, because I could barely tell what this was doing while editing it. Signed-off-by: Eli Schwartz Signed-off-by: Allan McRae commit 454ea024383eab60295e4c4fdf2c329475887b2c Author: Allan McRae Date: Mon May 11 12:59:51 2020 +1000 Remove autotools support This removes support for autotools in favour of meson. --- Summary of changes: .gitignore | 21 -- .gitlab-ci.yml | 17 -- HACKING | 13 - INSTALL | 370 -- Makefile.am | 78 - RELEASE | 9 +- configure.ac| 594 doc/Makefile.am | 162 -- doc/index.asciidoc | 8 +- etc/Makefile.am | 27 -- lib/libalpm/Makefile.am | 78 - lib/libalpm/signing.c | 2 +- scripts/Makefile.am | 287 - scripts/libmakepkg/tidy/strip.sh.in | 11 +- src/common/Makefile.am | 3 - src/pacman/Makefile.am | 69 - src/pacman/callback.c | 8 +- src/util/Makefile.am| 27 -- test/pacman/Makefile.am | 22 -- test/pacman/tests/Makefile.am | 5 - test/scripts/Makefile.am| 10 - test/util/Makefile.am | 8 - 22 files changed, 22 insertions(+), 1807 deletions(-) delete mode 100644 INSTALL delete mode 100644 Makefile.am delete mode 100644 configure.ac delete mode 100644 doc/Makefile.am delete mode 100644 etc/Makefile.am delete mode 100644 lib/libalpm/Makefile.am delete mode 100644 scripts/Makefile.am delete mode 100644 src/common/Makefile.am delete mode 100644 src/pacman/Makefile.am delete mode 100644 src/util/Makefile.am delete mode 100644 test/pacman/Makefile.am delete mode 100644 test/pacman/tests/Makefile.am delete mode 100644 test/scripts/Makefile.am delete mode 100644 test/util/Makefile.am hooks/post-receive -- The official pacman repository
Re: [pacman-dev] [PATCH] libalpm/signing.c: Fix calculation of packet size in parse_subpacket
On 1/6/20 5:51 am, Andrew Gregory wrote: > On 05/20/20 at 02:22pm, Allan McRae wrote: >> Given RFC 4880 provides the code to do this calculation, I am not sure >> how I managed to stuff that up! This bug was only exposed when a >> signature made with "include-key-block" was added to the Arch repos, >> which provided a subpacket with the required size to hit this issue. > > LGTM. Though, it might be worth it to use + instead of | just so we > match 4880 and extract_keyid exactly. > Done.
[pacman-dev] [PATCH] libalpm/signing.c: Fix calculation of packet size in parse_subpacket
Given RFC 4880 provides the code to do this calculation, I am not sure
how I managed to stuff that up! This bug was only exposed when a
signature made with "include-key-block" was added to the Arch repos,
which provided a subpacket with the required size to hit this issue.
Signed-off-by: Allan McRae
---
Also appropriate for 5.2.2
lib/libalpm/signing.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/libalpm/signing.c b/lib/libalpm/signing.c
index c8eaaca2..422523b6 100644
--- a/lib/libalpm/signing.c
+++ b/lib/libalpm/signing.c
@@ -1058,7 +1058,7 @@ static int parse_subpacket(alpm_handle_t *handle, const
char *identifier,
if(length_check(len, spos, 2, handle,
identifier) != 0){
return -1;
}
- slen = (sig[spos] << 8) | sig[spos + 1];
+ slen = (((sig[spos] - 192) << 8) | sig[spos +
1]) + 192;
spos = spos + 2;
} else {
if(length_check(len, spos, 5, handle,
identifier) != 0) {
--
2.26.2
Re: [pacman-dev] [PATCH] Cleanup the old sequential download code
On 14/5/20 6:03 pm, Anatol Pomozov wrote: > Given that in other patches we rename new functions to its old name it > makes sense to rename _alpm_multi_download to _alpm_download. That would make sense. A
Re: [pacman-dev] [PATCH] Avoid depending on side effects in assert(...) expressions
On 14/5/20 4:43 am, Dave Reisner wrote:
> When building with -DNDEBUG, assert statements are compiled out to
> no-ops. Thus, we can't depend on assignments or other computations
> occurring inside the assert().
> ---
Thanks.
> It's perhaps worth mentioning that nowhere else in the ALPM codebase
> do we use assert().
Yes - but we really don't have a way to pass back from our callback to
libalpm. So I am happy with the "shit hit the fan" approach until that
changes.
> src/pacman/callback.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/src/pacman/callback.c b/src/pacman/callback.c
> index 25909e02..4240a779 100644
> --- a/src/pacman/callback.c
> +++ b/src/pacman/callback.c
> @@ -862,12 +862,14 @@ static void dload_progress_event(const char *filename,
> alpm_download_event_progr
> int64_t curr_time = get_time_ms();
> double last_chunk_rate;
> int64_t timediff;
> + bool ok;
>
> if(!dload_progressbar_enabled()) {
> return;
> }
>
> - assert(find_bar_for_filename(filename, , ));
> + ok = find_bar_for_filename(filename, , );
> + assert(ok);
>
> /* compute current average values */
> timediff = curr_time - bar->sync_time;
> @@ -902,12 +904,14 @@ static void dload_complete_event(const char *filename,
> alpm_download_event_compl
> int index;
> struct pacman_progress_bar *bar;
> int64_t timediff;
> + bool ok;
>
> if(!dload_progressbar_enabled()) {
> return;
> }
>
> - assert(find_bar_for_filename(filename, , ));
> + ok = find_bar_for_filename(filename, , );
> + assert(ok);
> bar->completed = true;
>
> /* This may not have been initialized if the download finished before
>
Re: [pacman-dev] [PATCH] Avoid depending on side effects in assert(...) expressions
On 14/5/20 12:54 pm, Andrew Gregory wrote: > The > callback api should be fixed so that callbacks can indicate an error > that should cancel the download. Probably - there are a lot of points in the codebase where we pass an error back but don't really do much with it... Or don't pass back an error. > I'd also say we should be passing the full list of download items to > the callback so that it's possible to write at least a very simple > multi-download callback without having to maintain a bunch of > complicated state information. I was fairly happy with the multi-download callback. It was at a point that it worked and was functionally correct (as far as I could tell), but there are likely ways to make it better such as your idea. However, I'm not letting that stop anything good and working being committed to the tree as improvements can happen later. Perfect being the enemy of good and all that. A
Re: [pacman-dev] [PATCH v2] Swap alpm_db_update() implementation to multiplexed version
On 12/5/20 12:27 am, guilla...@manjaro.org wrote: > Hi Allan, Hi Anatol, > > I was looking to this new multiplexed implementation and I found some > problems: > 1) This implementation can lead to download databases from different > servers, I think it can't be a problem if they are not synced As I said elsewhere, this could happen in the single download code too. So not a new issue. This could be fixed (but note not all repos have the same server - only those provided by a distro), but it is beyond this patch. > 2) Differents download payloads are created for databases and its > signature files, this can this time lead to download the database and > its signature from differents server, I'm sure it's not wanted. Signature files coming from different servers is fine. You probably have that all the time with source code downloaded from places with various load balancing. Signature files for servers in different sync states is an issue - only for databases, packages are fine. > 3) Because signature files have their own download payloads, if the > signature is missing on a the first server (e.g. database signature is > optional), all next servers will be tried and all will give the same error. This is an issue. And I guess the fix would fix #2 too. It would be good to open a bug for this. > I really wanted to suggest a patch but I didn't find a easy way > (understand a small patch) to fix it and I would like your opinion on > point 1) first. > > Regards, > Guillaume. > .
Re: [pacman-dev] [PATCH v2] Swap alpm_db_update() implementation to multiplexed version
On 12/5/20 3:14 am, guilla...@manjaro.org wrote: > Le 2020-05-11 17:10, Eli Schwartz a écrit : >> On 5/11/20 10:27 AM, guilla...@manjaro.org wrote: >>> Hi Allan, Hi Anatol, >>> >>> I was looking to this new multiplexed implementation and I found some >>> problems: >>> 1) This implementation can lead to download databases from different >>> servers, I think it can't be a problem if they are not synced >> >> This should already be the case in the single-download version too, no? >> > > I agree and nothing can be done except ensuring all databases are > downloaded > from the same server. > Except... those database for repos that are hosted on different servers. Because not all repos are provided by the distro. As this was the case in single download code, I don't consider this a bug in the new code. Allan
[pacman-dev] [PATCH] Remove autotools support
This removes support for autotools in favour of meson. --- I'd still like support for including man pages (with --prefix=/usr) when running "ninja dist". However, I am also happy taking the heavy handed approach of adding the built man pages to git if no solution is forthcoming. There is probably some .gitignore cleanup that can be done in the translation directories. .gitignore| 21 -- .gitlab-ci.yml| 17 - HACKING | 13 - INSTALL | 370 - Makefile.am | 78 - RELEASE | 9 +- configure.ac | 594 -- doc/Makefile.am | 162 -- doc/index.asciidoc| 8 +- etc/Makefile.am | 27 -- lib/libalpm/Makefile.am | 78 - scripts/Makefile.am | 287 src/common/Makefile.am| 3 - src/pacman/Makefile.am| 69 src/util/Makefile.am | 27 -- test/pacman/Makefile.am | 22 -- test/pacman/tests/Makefile.am | 5 - test/scripts/Makefile.am | 10 - test/util/Makefile.am | 8 - 19 files changed, 8 insertions(+), 1800 deletions(-) delete mode 100644 INSTALL delete mode 100644 Makefile.am delete mode 100644 configure.ac delete mode 100644 doc/Makefile.am delete mode 100644 etc/Makefile.am delete mode 100644 lib/libalpm/Makefile.am delete mode 100644 scripts/Makefile.am delete mode 100644 src/common/Makefile.am delete mode 100644 src/pacman/Makefile.am delete mode 100644 src/util/Makefile.am delete mode 100644 test/pacman/Makefile.am delete mode 100644 test/pacman/tests/Makefile.am delete mode 100644 test/scripts/Makefile.am delete mode 100644 test/util/Makefile.am diff --git a/.gitignore b/.gitignore index 499d499b..01975fd2 100644 --- a/.gitignore +++ b/.gitignore @@ -1,24 +1,3 @@ *~ *.o -ABOUT-NLS -aclocal.m4 -autom4te.cache -config.h -config.h.in -config.log -config.status -config.status.lineno -configure -configure.lineno -cov-int -cscope.in.out -cscope.out -cscope.po.out -intl -libtool -Makefile -Makefile.in pacman-*.tar.gz -root -stamp-h1 -tags diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index a53d60cf..65b8c729 100644 --- a/.gitlab-ci.yml +++ b/.gitlab-ci.yml @@ -34,23 +34,6 @@ arch-docs: - meson -Ddoc=enabled build - ninja -C build -arch-autoconf: - extends: .arch-test - script: -- pacman -Syu --needed --noconfirm autoconf-archive -- autoreconf -i -- ./configure --enable-warningflags --disable-doc -- make -- fakechroot make check - -arch-distcheck: - extends: .arch-test - script: -- pacman -Syu --needed --noconfirm autoconf-archive asciidoc -- autoreconf -i -- ./configure --enable-warningflags -- fakechroot make distcheck - arch-clang: extends: .arch-test script: diff --git a/HACKING b/HACKING index 009a4682..334b7ac0 100644 --- a/HACKING +++ b/HACKING @@ -176,16 +176,3 @@ For pacman: --- Never directly include config.h. This will always be added via Makefiles. - -GDB and Valgrind Usage -~~ - -When using GDB or valgrind on pacman, you will want to run it on the actual -binary rather than the shell script wrapper produced by libtool. The actual -binary lives at `src/pacman/.libs/lt-pacman`, and will exist after running -`./src/pacman/pacman` at least once. - -For example, to run valgrind: - -./src/pacman/pacman -valgrind --leak-check=full -- src/pacman/.libs/lt-pacman -Syu diff --git a/INSTALL b/INSTALL deleted file mode 100644 index 007e9396.. --- a/INSTALL +++ /dev/null @@ -1,370 +0,0 @@ -Installation Instructions -* - -Copyright (C) 1994-1996, 1999-2002, 2004-2013 Free Software Foundation, -Inc. - - Copying and distribution of this file, with or without modification, -are permitted in any medium without royalty provided the copyright -notice and this notice are preserved. This file is offered as-is, -without warranty of any kind. - -Basic Installation -== - - Briefly, the shell commands `./configure; make; make install' should -configure, build, and install this package. The following -more-detailed instructions are generic; see the `README' file for -instructions specific to this package. Some packages provide this -`INSTALL' file but do not implement all of the features documented -below. The lack of an optional feature in a given package is not -necessarily a bug. More recommendations for GNU packages can be found -in *note Makefile Conventions: (standards)Makefile Conventions. - - The `configure' shell script attempts to guess correct values for -various system-dependent variables used during compilation. It uses -those values to create a `Makefile' in each directory of the package. -It may also create one or more `.h' files containing system-dependent -definitions.
Re: [pacman-dev] [PATCH] Use absolute path for pacman and pacman-conf in makepkg
On 8/5/20 4:13 am, Wouter Wijsman wrote:
> Currently makepkg requires pacman and pacman-conf to be in the path of
> the user. Since these executables should never move, it should be safe
> to add the full paths to the scripts at compile time, assuming the user
> uses the install command as well.
>
> This change works for both autotools and meson.
>
> Signed-off-by: Wouter Wijsman
> ---
Hi,
Can you let us know more detail about the use case for this patch? Why
would the user not add the directory pacman and scripts are installed in
to their path?
I have concerns that hardcoding paths on build will lead to difficulty
when in the future we have a test suite for makepkg.
Allan
> build-aux/edit-script.sh.in | 1 +
> meson.build | 1 +
> scripts/Makefile.am | 3 ++-
> scripts/makepkg.sh.in | 6 --
> 4 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/build-aux/edit-script.sh.in b/build-aux/edit-script.sh.in
> index 661c22d5..44103f08 100644
> --- a/build-aux/edit-script.sh.in
> +++ b/build-aux/edit-script.sh.in
> @@ -20,6 +20,7 @@ mode=$3
>-e "s|@DEBUGSUFFIX[@]|@DEBUGSUFFIX@|g" \
>-e "s|@INODECMD[@]|@INODECMD@|g" \
>-e "s|@FILECMD[@]|@FILECMD@|g" \
> + -e "s|@fullbindir[@]|@FULLBINDIR@|g" \
>"$input" >"$output"
>
> if [[ $mode ]]; then
> diff --git a/meson.build b/meson.build
> index 680cf62b..92e8a9a5 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -257,6 +257,7 @@ substs.set('LOCALEDIR', LOCALEDIR)
> substs.set('sysconfdir', SYSCONFDIR)
> substs.set('localstatedir', LOCALSTATEDIR)
> substs.set('PKGDATADIR', PKGDATADIR)
> +substs.set('FULLBINDIR', '@0@/@1@'.format(PREFIX, get_option('bindir')))
> substs.set('PREFIX', PREFIX)
> substs.set('BASH', BASH.path())
> substs.set('PACKAGE_VERSION', PACKAGE_VERSION)
> diff --git a/scripts/Makefile.am b/scripts/Makefile.am
> index 47455ed2..a79e9389 100644
> --- a/scripts/Makefile.am
> +++ b/scripts/Makefile.am
> @@ -182,7 +182,8 @@ edit = sed \
> -e 's|@DEBUGSUFFIX[@]|$(DEBUGSUFFIX)|g' \
> -e "s|@INODECMD[@]|$(INODECMD)|g" \
> -e "s|@FILECMD[@]|$(FILECMD)|g" \
> - -e 's|@SCRIPTNAME[@]|$@|g'
> + -e 's|@SCRIPTNAME[@]|$@|g' \
> + -e 's|@fullbindir[@]|$(FULLBINDIR)|g'
>
> ## All the scripts depend on Makefile so that they are rebuilt when the
> ## prefix etc. changes. Use chmod -w to prevent people from editing the
> diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in
> index d1416d15..2f7b838e 100644
> --- a/scripts/makepkg.sh.in
> +++ b/scripts/makepkg.sh.in
> @@ -44,6 +44,8 @@ declare -r makepkg_version='@PACKAGE_VERSION@'
> declare -r confdir='@sysconfdir@'
> declare -r BUILDSCRIPT='@BUILDSCRIPT@'
> declare -r startdir="$(pwd -P)"
> +declare -r PACMAN_EXECUTABLE='@fullbindir@/pacman'
> +declare -r PACMAN_CONF_EXECUTABLE='@fullbindir@/pacman-conf'
>
> LIBRARY=${LIBRARY:-'@libmakepkgdir@'}
>
> @@ -235,7 +237,7 @@ run_pacman() {
> else
> cmd=(su root -c "$(printf '%q ' "${cmd[@]}")")
> fi
> - local lockfile="$(pacman-conf DBPath)/db.lck"
> + local lockfile="$(${PACMAN_CONF_EXECUTABLE} DBPath)/db.lck"
> while [[ -f $lockfile ]]; do
> local timer=0
> msg "$(gettext "Pacman is currently in use, please
> wait...")"
> @@ -1123,7 +1125,7 @@ unset var
> PACKAGER=${PACKAGER:-"Unknown Packager"}
>
> # set pacman command if not already defined
> -PACMAN=${PACMAN:-pacman}
> +PACMAN=${PACMAN:-${PACMAN_EXECUTABLE}}
> # save full path to command as PATH may change when sourcing /etc/profile
> PACMAN_PATH=$(type -P $PACMAN)
>
>
[pacman-dev] [GIT] The official pacman repository branch, master, updated. v5.2.1-83-g8ce142a2
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "The official pacman repository". The branch, master has been updated via 8ce142a2552418f64a74e773f659d92b065d6209 (commit) via 8e769ddb8a59a9fbacf4614283d2fb519f022386 (commit) via 7423b166047ff168ef337818958bf86ed1d42a0a (commit) via 559590256c48fa5f995944de3802911e5a56ba7f (commit) from 22a58f5420438f35effb991696d37529d7a31969 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit 8ce142a2552418f64a74e773f659d92b065d6209 Author: Levente Polyak Date: Mon May 11 00:45:49 2020 +0200 makepkg: deterministic PKGINFO libprovides for multiple library versions While iterating over the provides array, the find call for locating a shared library may result in listing multiple entries which by itself does not produce a stable deterministic order and may vary depending on the underlying filesystem. To provide a stable listing and a reproducible .PKGINFO file the result of find is piped to sort with a static LC_ALL=C localisation. Signed-off-by: Levente Polyak Signed-off-by: Allan McRae commit 8e769ddb8a59a9fbacf4614283d2fb519f022386 Author: Eli Schwartz Date: Sun May 10 00:32:39 2020 -0400 Log invalid conf settings as an error This is not a warning, _parse_options() returns failure without even parsing further lines and the attempted pacman/pacman-conf program execution immediately aborts. Warnings are for when e.g. later on if we don't recognize a setting at all, we skip over it and have enough confidence in this to continue executing the program. The current implementation results in pacman-conf aborting with: warning: config file /etc/pacman.conf, line 60: invalid value for 'ParallelDownloads' : '2.5' error parsing '/etc/pacman.conf' or pacman -Syu aborting with the entirely more cryptic: warning: config file /etc/pacman.conf, line 59: invalid value for 'ParallelDownloads' : '2.5' and this isn't just a problem for the newly added ParallelDownloads setting, either, you could get the same problem if you specified a broken XferCommand, but that's harder as it's more accepting of input and you probably don't hit this except with unbalanced quotes. Signed-off-by: Eli Schwartz Signed-off-by: Allan McRae commit 7423b166047ff168ef337818958bf86ed1d42a0a Author: Eli Schwartz Date: Sun May 10 00:32:40 2020 -0400 pacman-conf: fix incomplete support for ILoveCandy This was only partially implemented in the original implementation. `pacman-conf | grep ILoveCandy` would tell you if it was set, but querying directly by name would not. Signed-off-by: Eli Schwartz Signed-off-by: Allan McRae commit 559590256c48fa5f995944de3802911e5a56ba7f Author: Eli Schwartz Date: Sun May 10 00:32:38 2020 -0400 pacman-conf: add support for new ParallelDownloads config option This was forgotten in the initial implementation, so it was impossible to figure out the value from a script, or correctly roundtrip the config file. Signed-off-by: Eli Schwartz Signed-off-by: Allan McRae --- Summary of changes: scripts/makepkg.sh.in| 2 +- src/pacman/conf.c| 8 src/pacman/pacman-conf.c | 15 +++ 3 files changed, 20 insertions(+), 5 deletions(-) hooks/post-receive -- The official pacman repository
Re: [pacman-dev] [PATCH] makepkg: deterministic PKGINFO libprovides for multiple library versions
On 11/5/20 8:49 am, Eli Schwartz wrote: > On 5/10/20 6:45 PM, anthr...@archlinux.org wrote: >> From: Levente Polyak >> >> While iterating over the provides array, the find call for locating a >> shared library may result in listing multiple entries which by itself >> does not produce a stable deterministic order and may vary depending on >> the underlying filesystem. >> To provide a stable listing and a reproducible .PKGINFO file the result >> of find is piped to sort with a static LC_ALL=C localisation. > > Wait, what. Do we have packages with libprovides providing multiple > versions of a shared library? > > I mean yes, given this possibility it does seem like we'd need to sort > them, but still... why does this exist? :p There was historically a package that provided an old compatibility library as well as the new one (you could only build against the new one). Really should have been a separate package. Patch looks good. A
