Re: [pacman-dev] [PATCH] Add `build/` to gitignore

On 10 Dec 2020, at 6:12 pm -0800, Colin Woodbury wrote: > Right, having `meson` do it automatically would work well. I put > forth the patch in the first place because the instructions on the > Pacman website (master branch), if followed, place the artifacts in > `build/`. Other newcomers to the

Re: [pacman-dev] [BUG] libalpm: symlink to directory causes conflict

On 29 Sep 2020, at 5:59 pm +, Barnabás Pőcze wrote: > Hi Hello, > 2020. szeptember 29., kedd 0:45 keltezéssel, Ivy Foster írta: > > On 28 Sep 2020, at 6:19 pm +, Barnabás Pőcze via pacman-dev wrote: > > > [pacman not following symlinks] may or may

Re: [pacman-dev] [BUG] libalpm: symlink to directory causes conflict

On 28 Sep 2020, at 6:19 pm +, Barnabás Pőcze via pacman-dev wrote: > Hi, Hello, > On my particular system '/lib' is a symbolic link to '/usr/lib'. I was > creating a > PKGBUILD for a program that places a systemd service file into > '/lib/systemd/...' > during installation. Unfortunately,

Re: [pacman-dev] [PATCH] pacman: print colored optdepends install status

On 12 Dec 2018, at 11:31 am +1000, Allan McRae wrote: > On 10/12/18 3:31 am, Michael Straube wrote: > > Colorize [installed] and [pending] when printing optional dependencies. > I'd prefer having less colours in our search operations, rather than > bringing those colours into other operations. >

Re: [pacman-dev] [PATCH] src/pacman/query.c: do not exit -Qo with error if file does not exist

On 12 Nov 2017, at 7:00 pm -0500, Eli Schwartz wrote: > On 11/12/2017 06:00 PM, i...@escondida.tk wrote: > > As a side note, this removes the sole usage of the translated error > > "failed to find '%s' in PATH: %s\n". I have not deleted this string > > from every .po file, but that option now

Re: [pacman-dev] [PATCH] src/pacman/query.c: do not exit -Qo with error if file does not exist

On 12 Nov 2017, at 7:39 pm -0500, Andrew Gregory wrote: > On 11/12/17 at 05:00pm, i...@escondida.tk wrote: > > From: Ivy Foster <i...@escondida.tk> > > diff --git a/src/pacman/query.c b/src/pacman/query.c > > index 024d3e21..64c42f19 100644 > > --- a/src/pa

[pacman-dev] [PATCH v3] makepkg: implement error codes

From: Ivy Foster <ivy.fos...@gmail.com> For your convenience, makepkg now has 16 distinct ways to fail. Also closes FS#54204. --- doc/makepkg.8.txt | 57 + scripts/Makefile.am | 1 + scripts/libmakepkg/util/error.sh.in

[pacman-dev] Changes to v3 of makepkg error codes patch

This attempt fixes the error, pointed out by brainpower, in which I accidentally dropped in an assignment when I was trying to use one of the error variables. This time, this patch depends on the trivial wording patch sent earlier today, rather than the other way around. It also incorporates

Re: [pacman-dev] [PATCH v2 2/2] makepkg: clarify error when user passes -F

Florian Pritz via pacman-dev wrote: > This seems like a very straight forward change. It's generally better if > you commit less invasive/more likely to be merged changes first so that > they can be merged more easily. I've just sent a version of this patch that does

[pacman-dev] [PATCH v3] makepkg: clarify error when user passes -F

From: Ivy Foster <ivy.fos...@gmail.com> --- 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 20e9dd7e..46eefd1f 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -1443,7 +

Re: [pacman-dev] [PATCH v2 2/2] makepkg: clarify error when user passes -F

Florian Pritz via pacman-dev wrote: > On 15.09.2017 20:30, ivy.fos...@gmail.com wrote: > > - error "$(gettext "Do not use the %s option. \ > > This option is only for use by %s.")" "'-F'" "makepkg" > > + error "$(gettext "Do not use the %s option. \ >

Re: [pacman-dev] [PATCH v2 1/2] makepkg: implement error codes

Dave Reisner wrote: > I didn't go over this in detail, but I'll point out a few concerns I > have about this patch... Fair enough, thanks for the feedback. > On Fri, Sep 15, 2017 at 01:30:51PM -0500, ivy.fos...@gmail.com wrote: > > +Errors > > +-- > > +On exit, makepkg

[pacman-dev] [PATCH v2 1/2] makepkg: implement error codes

From: Ivy Foster <ivy.fos...@gmail.com> For your convenience, makepkg now has 16 distinct ways to fail. --- doc/makepkg.8.txt | 60 ++ scripts/Makefile.am | 1 + scripts/libmakepkg/util/error.sh.in | 42 + scripts/makepkg

[pacman-dev] [PATCH v2 2/2] makepkg: clarify error when user passes -F

From: Ivy Foster <ivy.fos...@gmail.com> --- 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 a8a8eb41..953c43fb 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -1442,7 +

Re: [pacman-dev] [PATCH 1/2] makepkg: implement error codes

Allan McRae wrote: > On 15/09/17 08:58, ivy.fos...@gmail.com wrote: > > index 20e9dd7e..8ef3c48d 100644 > > --- a/scripts/makepkg.sh.in > > +++ b/scripts/makepkg.sh.in > > @@ -87,6 +87,26 @@ SPLITPKG=0 > > SOURCEONLY=0 > > VERIFYSOURCE=0 > > > > +# Errors > > +E_OK=0 > >

[pacman-dev] RFC: makepkg errors

I've implemented a patch that allows makepkg to return discrete error values for different errors. This is based on the comments scattered throughout indicating that at some point, somebody intended to implement this. As a side benefit, it also closes [FS#54204][], since being able to return a

[pacman-dev] [PATCH 2/2] makepkg: clarify error when user passes -F

From: Ivy Foster <ivy.fos...@gmail.com> --- 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 8ef3c48d..a0d6f8e7 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -1462,7 +

[pacman-dev] [PATCH 1/2] makepkg: implement error codes

From: Ivy Foster <ivy.fos...@gmail.com> For your convenience, makepkg now has 16 distinct ways to fail. --- doc/makepkg.8.txt | 60 ++ scripts/makepkg.sh.in | 140 -- 2 files changed, 139 insertions(+), 61 del

[pacman-dev] [PATCH v3] makepkg: print files with refs to $srcdir/$pkgdir

From: Ivy Foster <ivy.fos...@gmail.com> Since rewriting build_references() anyway, tweaked quoting. Implements FS#31558. Signed-off-by: Ivy Foster <ivy.fos...@gmail.com> --- scripts/libmakepkg/lint_package/build_references.sh.in | 16 +--- 1 file changed, 9 inse

Re: [pacman-dev] [PATCH v2] makepkg: print filenames and line numbers of references to $srcdir & $pkgdir in built package

On 15 Oct 2016, at 6:52 pm +1000, Allan McRae wrote: > On 15/10/16 12:27, Ivy Foster wrote: > > On 14 Oct 2016, at 10:07 pm -0400, Andrew Gregory wrote: > >> On 10/14/16 at 08:21pm, ivy.fos...@gmail.com wrote: > >>> From: Ivy Foster <ivy.fos...@gmail.com> >

Re: [pacman-dev] [PATCH v2] makepkg: print filenames and line numbers of references to $srcdir & $pkgdir in built package

On 14 Oct 2016, at 10:07 pm -0400, Andrew Gregory wrote: > We're not very strict about this, but please try to keep the first > line of the commit message fairly short, ideally around 50 characters. Noted, thanks. > On 10/14/16 at 08:21pm, ivy.fos...@gmail.com wrote: > > F

[pacman-dev] [PATCH v2] makepkg: print filenames and line numbers of references to $srcdir & $pkgdir in built package

From: Ivy Foster <ivy.fos...@gmail.com> grep -n output is used to match format of compiler warnings. Since rewriting build_references() anyway, tweaked quoting. Implements FS#31558. Signed-off-by: Ivy Foster <ivy.fos...@gmail.com> --- scripts/libmakepkg/lint_package/build_reference

[pacman-dev] [PATCH] makepkg: print filenames and line numbers of references to $srcdir & $pkgdir in built package

From: Ivy Foster <ivy.fos...@gmail.com> grep -n output is used to match format of compiler warnings. Since rewriting build_references() anyway, tweaked quoting. Implements FS#31558. Signed-off-by: Ivy Foster <ivy.fos...@gmail.com> --- scripts/libmakepkg/lint_package/build_reference

[pacman-dev] [PATCH] doc/pacman.8.txt: improve description of -Qt

From: Ivy Foster <ivy.fos...@gmail.com> Though correct, the wording of the description of Query's -t/--unrequired option was confusing. Closes FS#48144. Signed-off-by: Ivy Foster <ivy.fos...@gmail.com> --- doc/pacman.8.txt | 8 1 file changed, 4 insertions(+), 4 deleti

[pacman-dev] [PATCH v3 2/4] Represent bitfields as ints, not enums

From: Ivy Foster <ivy.fos...@gmail.com> Many bitfield variables are declared to be enums, because they are generated using bitwise operations on enums such. However, their actual values aren't necessary members of their parent enum, so declaring them 'int' is more accurate. Signed-off-b

[pacman-dev] Another try at building cleanly with clang's -Wassign-enum

Thanks to feedback from Andrew, I have revised the patch[1] I recently sent in that tries to fix a class of warning offered by clang, -Wassign-enum. To make review a bit easier, I've split it into separate patches, based on the cause of the warning in question. Patch 1: Functions returning

[pacman-dev] [PATCH v3 1/4] Add ALPM_ERR_OK to _alpm_errno_t

From: Ivy Foster <ivy.fos...@gmail.com> This allows functions which return an _alpm_errno_t to always return a genuine _alpm_errno_t for consistency, even in cases where there are no errors. Since ALPM_ERR_OK = 0, their callers can still simply check 'err = some_fn(); if (!err) { ... }'.

[pacman-dev] [PATCH v3 3/4] Declare alpm_pkg_get_(origin|reason) to return int

From: Ivy Foster <ivy.fos...@gmail.com> These functions can return -1 on error, which is not included in the enumerated types they were declared to return. Signed-off-by: Ivy Foster <ivy.fos...@gmail.com> --- lib/libalpm/alpm.h| 6 +++--- lib/libalpm/package.c | 4 ++-- src/pacm

[pacman-dev] [PATCH v3 4/4] Add -Wassign-enum to WARNING_CFLAGS

From: Ivy Foster <ivy.fos...@gmail.com> --- configure.ac | 1 + 1 file changed, 1 insertion(+) diff --git a/configure.ac b/configure.ac index f6b87e5..2c0a350 100644 --- a/configure.ac +++ b/configure.ac @@ -434,6 +434,7 @@ fi AC_MSG_CHECKING(for excessive compiler warning flags) if t

Re: [pacman-dev] [PATCH v2 2/2] Make pacman build cleanly with clang's -Wassign-enum

On 28 Sep 2016, at 1:28 pm -0400, Andrew Gregory wrote: > On 09/03/16 at 10:14pm, ivy.fos...@gmail.com wrote: > > From: Ivy Foster <ivy.fos...@gmail.com> > > > > In many cases, it was enough to add error or "none" values to enums, > > to accoun

[pacman-dev] [PATCH v2] lib/libalpm/be_sync.c: Close memory leaks when mallocing while out of memory

From: Ivy Foster <ivy.fos...@gmail.com> Signed-off-by: Ivy Foster <ivy.fos...@gmail.com> --- lib/libalpm/be_sync.c | 18 ++ 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/lib/libalpm/be_sync.c b/lib/libalpm/be_sync.c index 32a669d..06f9619 100644 --- a

[pacman-dev] (no subject)

For now, I'm just sending in the malloc patch (which, of course, now only frees variables that exist in the original source, not ones invented for the previous patches). To quickly recap an irc conversation with agregory, it looks like implementing checks before overwriting the db is more

Re: [pacman-dev] [PATCH 1/2] alpm: check for invalid sync db before replacing original

On 08 Sep 2016, at 12:55 pm -0400, Andrew Gregory wrote: > On 09/07/16 at 10:28pm, Ivy Foster wrote: > > On 07 Sep 2016, at 10:05 pm -0400, Andrew Gregory wrote: > > > This runs the risk of conflicting with another db if dbext is "" or > > > ".bak",

Re: [pacman-dev] [PATCH 1/2] alpm: check for invalid sync db before replacing original

On 07 Sep 2016, at 10:05 pm -0400, Andrew Gregory wrote: > On 09/07/16 at 07:22pm, ivy.fos...@gmail.com wrote: > > From: Ivy Foster <ivy.fos...@gmail.com> > This is a step in the right direction, but the problem of downloading > an invalid db over a valid one still exis

[pacman-dev] [PATCH 1/2] alpm: check for invalid sync db before replacing original

From: Ivy Foster <ivy.fos...@gmail.com> Closes #46107 Signed-off-by: Ivy Foster <ivy.fos...@gmail.com> --- lib/libalpm/alpm.h| 1 + lib/libalpm/be_sync.c | 26 +- lib/libalpm/error.c | 2 ++ 3 files changed, 28 insertions(+), 1 deletion(-) diff

[pacman-dev] [PATCH 2/2] lib/libalpm/be_sync.c: Close memory leaks when mallocing while out of memory

From: Ivy Foster <ivy.fos...@gmail.com> Signed-off-by: Ivy Foster <ivy.fos...@gmail.com> --- lib/libalpm/be_sync.c | 42 ++ 1 file changed, 34 insertions(+), 8 deletions(-) diff --git a/lib/libalpm/be_sync.c b/lib/libalpm/be_sync.c index ee43

[pacman-dev] [RFC] _RESERVED_IDS & enum assignments, take 2

I've had another go at the patches from yesterday. The first patch, which eliminates use of #define _RESERVED_IDENTIFIERS, has one problem keeping me from adding -Wreserved-id-macro to configure.ac: the autoconf-generated file config.h.in contains one, _DARWIN_USE_64_BIT_INODE. I'm honestly not

[pacman-dev] [PATCH v2 1/2] Do not #define _RESERVED_IDENTIFIERS

From: Ivy Foster <ivy.fos...@gmail.com> Signed-off-by: Ivy Foster <ivy.fos...@gmail.com> --- lib/libalpm/add.h | 6 +++--- lib/libalpm/alpm.h | 6 +++--- lib/libalpm/alpm_list.h | 6 +++--- lib/libalpm/backup.h| 6 +++--- lib/liba

[pacman-dev] [PATCH v2 2/2] Make pacman build cleanly with clang's -Wassign-enum

From: Ivy Foster <ivy.fos...@gmail.com> In many cases, it was enough to add error or "none" values to enums, to account for cases where functions returned either an enumerated value or 0/-1. A common code pattern in pacman is to use enums to create bitfields representin

[pacman-dev] [PATCH 2/2] Add ALPM_ERR_OK = 0 to _alpm_err_t

From: Ivy Foster <ivy.fos...@gmail.com> Functions that expect an _alpm_err_t can now get a true one, even on success. Since previous practice was to return 0 (not included in the _alpm_err_t enum type), anything that just checks !err or (err == 0) should work as is. Signed-off-by: Ivy

[pacman-dev] [PATCH 1/2] Do not #define _RESERVED_IDENTIFIERS

From: Ivy Foster <ivy.fos...@gmail.com> Signed-off-by: Ivy Foster <ivy.fos...@gmail.com> --- lib/libalpm/add.h | 6 +++--- lib/libalpm/alpm.h | 6 +++--- lib/libalpm/alpm_list.h | 6 +++--- lib/libalpm/backup.h| 6 +++--- lib/liba

[pacman-dev] [PATCH v2] Replace CURLOPT_PROGRESSFUNCTION with

On Tue, Aug 30, 2016 at 02:54:31PM -0500, Dave Reisner <d...@falconindy.com> wrote: > From: Ivy Foster <ivy.fos...@gmail.com> > > Curl 7.32.0 added CURLOPT_XFERINFOFUNCTION > Making this change would require that you update configure.ac to bump > the minimum

[pacman-dev] [PATCH] Replace CURLOPT_PROGRESSFUNCTION with CURLOPT_XFERINFOFUNCTION

From: Ivy Foster <ivy.fos...@gmail.com> Curl 7.32.0 added CURLOPT_XFERINFOFUNCTION, which deprecates CURLOPT_PROGRESSFUNCTION and means less casting doubles to size_ts for alpm. This change has no user-facing nor frontend-facing effects. Signed-off-by: Ivy Foster <ivy.fos...@

[pacman-dev] [PATCH] Replace CURLOPT_PROGRESSFUNCTION with CURLOPT_XFERINFOFUNCTION

From: Ivy Foster <ivy.fos...@gmail.com> Curl 7.32.0 added CURLOPT_XFERINFOFUNCTION, which deprecates CURLOPT_PROGRESSFUNCTION and means less casting doubles to size_ts for alpm. This change has no user-facing nor frontend-facing effects. Signed-off-by: Ivy Foster <ivy.fos...@gmail.com&

[pacman-dev] [PATCH] Normalize alpm download callback function's args to frontend

In response to my recent patches attempting to fix pacman's repetitive output with --noprogressbar, agregory kindly pointed out an obvious error I missed and suggested that I tackle the problem by making alpm's download callback function return normalized output[1]. [1]:

[pacman-dev] Error in patchset

In the IRC channel, agregory immediately pointed out a pretty obvious bug I missed: the third patch caues pacman to print "downloading " even if the repository is up-to-date. My apologies; I don't know how I missed that, and I'll put it right.

[pacman-dev] [PATCH 3/3] callback.c: Move --noprogressbar handling from cb_dl_progress to cb_event

From: Ivy Foster <ivy.fos...@gmail.com> Signed-off-by: Ivy Foster <ivy.fos...@gmail.com> --- src/pacman/callback.c | 25 - 1 file changed, 20 insertions(+), 5 deletions(-) diff --git a/src/pacman/callback.c b/src/pacman/callback.c index ab3e14f..9c29e6d 1006

[pacman-dev] [PATCH 1/3] alpm.h: Add new event type, alpm_event_database_refresh_t

From: Ivy Foster <ivy.fos...@gmail.com> New events of this type: ALPM_EVENT_DATABASE_REFRESH_{START,DONE,FAILED} Signed-off-by: Ivy Foster <ivy.fos...@gmail.com> --- lib/libalpm/alpm.h | 21 - 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/lib/liba

[pacman-dev] Another attempt at fixing sync printing multiple times with --noprogressbar

Last month, I sent in a patch[1] trying to fix the issue that when pacman is run with --noprogressbar, pacman sometimes prints the message "downloading foo" multiple times. Allan suggested that I fix the underlying issue; looking at a previous thread[2], I gather that the issue is that a callback

Re: [pacman-dev] [PATCH] callback.c: only print download status message once with --noprogressbar

On 09 Jun 2016, at 4:01 pm +1000, Allan McRae wrote: > On 08/06/16 07:01, Ivy Foster wrote: > > Syncing repos and downloading packages with --noprogressbar specified > > often prints the status message "downloading $foo..." to several > > lines in a row. > &g

[pacman-dev] [PATCH] callback.c: only print download status message once with --noprogressbar

Syncing repos and downloading packages with --noprogressbar specified often prints the status message "downloading $foo..." to several lines in a row. --- src/pacman/callback.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/pacman/callback.c b/src/pacman/callback.c

Re: [pacman-dev] [Patch] Disable colors and progress bars if TERM=dumb

On 26 Mar 2016, at 1:58 pm +1000, Allan McRae wrote: > On 25/03/16 14:13, Ivy Foster wrote: > > I recently noticed that if colors and progress bars are enabled, pacman > > will faithfully attempt to print them even to dumb terminals that cannot > > handle them. This patch f

[pacman-dev] [Patch] Disable colors and progress bars if TERM=dumb

I recently noticed that if colors and progress bars are enabled, pacman will faithfully attempt to print them even to dumb terminals that cannot handle them. This patch fixes that. Cheers, iff >From 08d67cd6bbfd1bc29ebfae8eff80ffbf9e24fdf5 Mon Sep 17 00:00:00 2001 From: Ivy Foster <i

Re: [pacman-dev] [PATCH v3 1/2] Make get_pkg_arch treat arch as an array

On 25 Mar 2015, at 2:39 pm +1000, Allan McRae wrote: On 21/03/15 10:19, joyfulg...@archlinux.us wrote: From: Ivy Foster joyfulg...@archlinux.us This took me a whole lot of reviewing for a single character change! Yeah, I was afraid it might. I did some grepping of my own to make sure

Re: [pacman-dev] [PATCH v3 2/2] Add makepkg option --packagelist; fix bug #42150

On 25 Mar 2015, at 3:09 pm +1000, Allan McRae wrote: On 21/03/15 10:19, joyfulg...@archlinux.us wrote: From: Ivy Foster joyfulg...@archlinux.us Delete the bug number from the subject line, it can be added as a note to the commit message. Thanks, I'll keep that in mind in the future. Also

Re: [pacman-dev] [PATCH] Add makepkg option --printproducts; fix bug #42150

On 20 Mar 2015, at 9:29 pm +0100, Florian Pritz wrote: From: Ivy Foster joyfulg...@archlinux.us I'm not really sure why that is here. Did you set the envelope sender in git (git config --global sendemail.envelopesender) or am I missing some difference between the two addresses? You're

Re: [pacman-dev] [PATCH v2] Add makepkg option --packagelist; fix bug #42150

On 21 Mar 2015, at 12:54 am +0100, Johannes Löthberg wrote: On 20/03, joyfulg...@archlinux.us wrote: Also fixed get_pkg_arch to treat arch as an array when querying pkgbuild_get_attribute. That is an unrelated change that doesn’t really belong in the same commit. I'll redo the patch(es) and

Re: [pacman-dev] [PATCH] Add makepkg option --printproducts; fix bug #42150

On 20 Mar 2015, at 4:19 pm +1000, Allan McRae wrote: On 20/03/15 11:00, joyfulg...@archlinux.us wrote: From: Ivy Foster joyfulg...@archlinux.us New contributor - yay! [patch] [notes] Thanks! I'll fix it up as you've suggested. When that's done, should I send the changes as a patch that's