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
> New contributor - yay!
> > [patch]
> [notes]
Thanks! I'll fix it up as you've suggested. When that's
done, should I send the chang
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)
On 20 Mar 2015, at 9:29 pm +0100, Florian Pritz wrote:
> >> > From: Ivy Foster
>
> 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 addres
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
> 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.
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
> 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 nothing in t
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
Date: Thu,
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
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
inde
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
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 f
From: Ivy Foster
Signed-off-by: Ivy Foster
---
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 100644
--- a/src/pacman/callback.c
+++ b/src/pacman
From: Ivy Foster
New events of this type:
ALPM_EVENT_DATABASE_REFRESH_{START,DONE,FAILED}
Signed-off-by: Ivy Foster
---
lib/libalpm/alpm.h | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/lib/libalpm/alpm.h b/lib/libalpm/alpm.h
index 168d71b..2b3e116
From: Ivy Foster
Signed-off-by: Ivy Foster
---
lib/libalpm/be_sync.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/lib/libalpm/be_sync.c b/lib/libalpm/be_sync.c
index 32a669d..ad97475 100644
--- a/lib/libalpm/be_sync.c
+++ b/lib/libalpm/be_sync.c
@@ -182,6 +182,10 @@ int
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.
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]: https://wiki.archlinux
From: Ivy Foster
When curl calls alpm's dlcb, alpm calls the frontend's cb with the
following (dlsize, totalsize) arguments:
0, -1: initialize
0, 0: no change since last call
x {x>0, x0}: data downloaded, total size known
x {x>0}, x: download finished
If total size is not kn
From: Ivy Foster
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
---
lib/libalpm/dload.c | 18 +-
1
From: Ivy Foster
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
---
configure.ac| 4 ++--
lib/libalpm
On Tue, Aug 30, 2016 at 02:54:31PM -0500, Dave Reisner
wrote:
> From: Ivy Foster
> > Curl 7.32.0 added CURLOPT_XFERINFOFUNCTION
> Making this change would require that you update configure.ac to bump
> the minimum version for libcurl (which is currently 7.19.4). FWIW 7.32.0
&g
From: Ivy Foster
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 Foster
---
lib/libalpm/alpm.h
First of all, don't worry; I'm under no illusion that the
pie-in-the-sky Subject line is anything that will happen in the near
future, nor even necessarily a goal for the project (given just how
finicky -Weverything is).
Basically, I'm wondering whether sporadic patches addressing the sorts
of thi
From: Ivy Foster
Signed-off-by: Ivy Foster
---
lib/libalpm/add.h | 6 +++---
lib/libalpm/alpm.h | 6 +++---
lib/libalpm/alpm_list.h | 6 +++---
lib/libalpm/backup.h| 6 +++---
lib/libalpm/base64.h| 4 ++--
lib/libalpm/conflict.h
From: Ivy Foster
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
representing various option combinations. Sinc
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
su
From: Ivy Foster
Signed-off-by: Ivy Foster
---
lib/libalpm/add.h | 6 +++---
lib/libalpm/alpm.h | 6 +++---
lib/libalpm/alpm_list.h | 6 +++---
lib/libalpm/backup.h| 6 +++---
lib/libalpm/base64.h| 4 ++--
lib/libalpm/conflict.h
From: Ivy Foster
Closes #46107
Signed-off-by: Ivy Foster
---
lib/libalpm/alpm.h| 1 +
lib/libalpm/be_sync.c | 26 +-
lib/libalpm/error.c | 2 ++
3 files changed, 28 insertions(+), 1 deletion(-)
diff --git a/lib/libalpm/alpm.h b/lib/libalpm/alpm.h
index 168d71b
From: Ivy Foster
Signed-off-by: Ivy Foster
---
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 ee438f8..f61668e 100644
--- a/lib/libalpm/be_sync.c
+++ b/lib
Patch 1 is an attempt to close #46107 [1]. In lib/libalpm/be_sync.c,
pacman 1) backs up the old db, 2) procedes as normal, 3) if new db is
valid, deletes backup; if not, restores backup.
While working on patch 1, I noticed a bunch of TODOs that mentioned
the syncpath not being freed or umask reset
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
> This is a step in the right direction, but the problem of downloading
> an invalid db over a valid one still exists. The errors given in the
>
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",
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 complic
From: Ivy Foster
Signed-off-by: Ivy Foster
---
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/lib/libalpm/be_sync.c
+++ b/lib/libalpm/be_sync.c
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
> >
> > In many cases, it was enough to add error or "none" values to enums,
> > to account for cases where functions returne
From: Ivy Foster
---
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 test "x$warningflags&quo
From: Ivy Foster
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
---
lib/libalpm/alpm.h| 6 +++---
lib/libalpm/package.c | 4 ++--
src/pacman/package.c | 3 ++-
3 files changed, 7 insertions
From: Ivy Foster
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-by: Ivy Foster
-
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 _alpm_e
From: Ivy Foster
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) { ... }'.
Signed-off-by:
From: Ivy Foster
Though correct, the wording of the description of Query's
-t/--unrequired option was confusing. Closes FS#48144.
Signed-off-by: Ivy Foster
---
doc/pacman.8.txt | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/doc/pacman.8.txt b/doc/pacman.
From: Ivy Foster
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
---
scripts/libmakepkg/lint_package/build_references.sh.in | 15 +++
1 file changed, 11
From: Ivy Foster
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
---
scripts/libmakepkg/lint_package/build_references.sh.in | 16 +---
1 file changed, 9
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:
> &
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
> > > +
From: Ivy Foster
Since rewriting build_references() anyway, tweaked quoting.
Implements FS#31558.
Signed-off-by: Ivy Foster
---
scripts/libmakepkg/lint_package/build_references.sh.in | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/scripts/libmakepkg
From: Ivy Foster
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 deletions(-)
diff --git a/doc/makepkg
From: Ivy Foster
---
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 +1462,7 @@ catastrophic damage to your
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 rec
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
> > +E_FAIL=1 # Generic er
From: Ivy Foster
---
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 +1442,7 @@ catastrophic damage to your
From: Ivy Foster
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.sh.in | 120
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 will return one of the
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. \
> > This option is only for
Dave Reisner wrote:
> On Sun, Sep 17, 2017 at 05:34:15PM +1000, Allan McRae wrote:
> > On 16/09/17 06:54, Dave Reisner wrote:
> >>> +Errors
> >>> +--
> >>> +On exit, makepkg will return one of the following error codes.
> >>> +
> >>> +**E_OK**=0::
> >> I don't see the need to document internal
From: Ivy Foster
---
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 +1443,7 @@ catastrophic damage to your
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 not depend on the
makepkg err
From: Ivy Foster
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 | 41
scripts/makepkg.sh.in
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 Dav
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
> > diff --git a/src/pacman/query.c b/src/pacman/query.c
> > index 024d3e21..64c42f19 100644
> > --- a/src/pacman/query.c
> > +++ b/
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 exis
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.
>
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,
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
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 p
63 matches
Mail list logo