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
ts. 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 Vel
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
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:
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.
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 +-
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 McRa
t; * \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 Re
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
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
> ---
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
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
>>
&g
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
>
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-deltapkg
caf663865b (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
24499 (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
mmands, -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
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
>
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
0
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 McRa
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
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
>
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
> @@
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
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
>
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
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
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
>>
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
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
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
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 pkgarc
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
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
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
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
>
>
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
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
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 di
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).
>>
ready, 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
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
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 reposit
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
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:
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.
&g
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?
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
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
On 22/8/20 1:20 pm, Ronan Pigott wrote:
> From: Ronan Pigott
>
> Signed-off-by: Ronan Pigott
> ---
This looks good to me.
Allan
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
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
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
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
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
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
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
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
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 s
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: returnin
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
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
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
> ---
>
/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 c
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
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.
>
>
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
ture
/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: A
ot;
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
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`
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
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.
>
>
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
>
ow.
- 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 McRa
---
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
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
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
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).
>
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
or 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 McRa
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
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
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
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
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
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
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
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
at 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
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-bl
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
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
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
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
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
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
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
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.
>
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
A
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
1 - 100 of 4111 matches
Mail list logo
