Re: [pacman-dev] [PATCH 22/23] doc: change group names to libalpm_*

On 21/12/2020 01:47, Allan McRae wrote: > There seems to be a lot of duplication from our footer.asciidoc here. Why? Just because I don't know how to de duplicate it. Doxygen does not seem to provide a way to use asciidoc or include a raw footer. I don't know how else to do about it.

Re: [pacman-dev] [PATCH 02/23] doc: add doc header to alpm.h

On 09/12/2020 19:29, Colin Woodbury wrote: > Spelling of "primarily". > > On Mon, 7 Dec 2020, at 14:19, morganamilo wrote: >> --- >> lib/libalpm/alpm.h | 13 + >> 1 file changed, 13 insertions(+) >> >> diff --git a/lib/libalpm/alpm.h b/lib/libalpm/alpm.h >> index 50c4bb6b..48ba7fdc

Re: [pacman-dev] [PATCH 00/23] Docs Docs Docs 2: electric boogaloo

On 07/12/2020 22:59, Colin Woodbury wrote: > I enjoy writing docs, is there anywhere you'd like a hand? > > On Mon, 7 Dec 2020, at 14:19, morganamilo wrote: >> Here's a redo of my original docs patch and more. >> >> This time it's split in to many commits so it's hopefully easier to >>

Re: [pacman-dev] [PATCH] libalpm: set ret in download files

On 30/11/2020 7:02 pm, Anatol Pomozov wrote: > > "if(ret)" is semantically equivalent to "if(ret != 0)". Is the change > really needed here? > I don't particularity care what format is used, just as long as they're all the same. Comparing against 0 was already used twice in that file so just

Re: [pacman-dev] [PATCH] libmakepkg: lint all arrays for empty values

On 28/10/2020 01:13, Eli Schwartz wrote: > On 10/27/20 8:59 PM, Morgan Adamiec wrote: >> On 28/10/2020 00:46, Eli Schwartz wrote: >>> It remains unclear to me, why the ambiguity matters. >>> >> >> I guess if you were to officially declare `Key =` means to

Re: [pacman-dev] [PATCH] libmakepkg: lint all arrays for empty values

On 28/10/2020 00:46, Eli Schwartz wrote: > On 10/27/20 8:25 PM, Morgan Adamiec wrote: >> On 28/10/2020 00:04, Allan McRae wrote: >> >>> pkgnames/depends/etc where it may be an issue. So I'm not sure this >>> check finds anything in the "break make

Re: [pacman-dev] [PATCH] libmakepkg: lint all arrays for empty values

On 28/10/2020 00:04, Allan McRae wrote: > pkgnames/depends/etc where it may be an issue. So I'm not sure this > check finds anything in the "break makepkg/pacman" category. I disagree, it actually does break something, the srcinfio file Consider the following pkgbuild: pkgbase=foo pkgname=(a

Re: [pacman-dev] [PATCH] libmakepkg: lint all arrays for empty values

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

Re: [pacman-dev] [PATCH] pacman: print error message for -F with invalid regex

On Thu, 7 Nov 2019 at 11:42, Allan McRae wrote: > > On 6/11/19 12:00 pm, morganamilo wrote: > > > > diff --git a/src/pacman/files.c b/src/pacman/files.c > > index 19191dd8..05b6f223 100644 > > --- a/src/pacman/files.c > > +++ b/src/pacman/files.c > > @@ -115,7 +115,8 @@ static int

Re: [pacman-dev] [PATCH] pacman+libalpm: handle search errors

On Wed, 6 Nov 2019 at 01:44, morganamilo wrote: > > Previously, pacman treated no matches and an error during search the > same. > > To fix this, alpm_db_search now returns its status as an int and > instead takes the to be returned list as a param. Allowing front ends to > easily differentiate

Re: [pacman-dev] [PATCH v2] pacman-key: ignores keys already lsigned/deleted

On Mon, 4 Nov 2019 at 19:36, Matthew Sexton wrote: > > Added two new functions, lsigned_already() and revoked_already() > that check whether a key has been locally signed or revoked > respectively during --populate. If the key is already signed > or revoked, it is quietly ignored. > >

Re: [pacman-dev] [PATCH] pacman: new config to highlight testing packages

On Tue, 10 Sep 2019 at 10:54, Matthew Sexton wrote: > > Only during Install/Upgrade, and not to verbosepkglist > > Signed-off-by: Matthew Sexton > --- > src/pacman/conf.c| 2 ++ > src/pacman/conf.h| 2 ++ > src/pacman/pacman-conf.c | 1 + > src/pacman/util.c| 20

Re: [pacman-dev] [PATCH] libalpm: fix documentation for alpm_pkg_mtree_next

On Thu, 20 Jun 2019 at 05:46, Allan McRae wrote: > > On 14/6/19 11:26 pm, Dave Reisner wrote: > > On Fri, Jun 14, 2019 at 02:19:52PM +0100, Morgan Adamiec wrote: > >> On Fri, 14 Jun 2019 at 14:09, Dave Reisner wrote: > >>> > >>> On Fri, Jun 14

Re: [pacman-dev] [PATCH] libalpm: fix documentation for alpm_pkg_mtree_next

On Fri, 14 Jun 2019 at 14:09, Dave Reisner wrote: > > On Fri, Jun 14, 2019 at 02:51:14AM +0100, morganamilo wrote: > > libarchive uses 1 for EOF, not 0. Instead of using the actual ints, use > > libarchive's error codes. > > --- > > > > By the way, not familiar with doxygen. Is my wording fine or

Re: [pacman-dev] [PATCH] repo-add: should have option to prevent downgrading

On Sun, 28 Apr 2019 at 13:21, Ralph Corderoy wrote: > > Hi ekardnam, > > > +printf -- "$(gettext " --dont-downgrade do not add package to > > database if a newer version is already present\n")" > ... > > +warning "$(gettext "A newer version for '%s' is already > >

Re: [pacman-dev] [PATCH v2] wip: pacman: rework the UI of -F

On Sat, 20 Apr 2019 at 19:38, morganamilo wrote: > > Reworks the UI of -F according to FS#47949 > > In short -F replaces both -Fs and -Fo. > --regex/-x has been replaced with --search/-s. > --oneline/-o can be used to change the output format to match the old -Fo > > Signed-off-by: morganamilo >

Re: [pacman-dev] [PATCH 2/2] wip: pacman: rework the UI of -F

On Thu, 7 Feb 2019 at 03:13, Eli Schwartz wrote: > > On 2/6/19 9:22 PM, Morgan Adamiec wrote: > > On Thu, 7 Feb 2019 at 01:31, Allan McRae wrote: > >> > >> On 3/2/19 4:42 am, morganamilo wrote: > >>> Reworks the UI of -F according to FS#47949 > &g

Re: [pacman-dev] [PATCH 2/2] wip: pacman: rework the UI of -F

On Thu, 7 Feb 2019 at 01:31, Allan McRae wrote: > > On 3/2/19 4:42 am, morganamilo wrote: > > Reworks the UI of -F according to FS#47949 > > > > In short -F replaces both -Fs and -Fo. > > --regex/-x has been replaced with --search/-s. > > > > Signed-off-by: morganamilo > > --- > > > > This patch

Re: [pacman-dev] [PATCH v5 4/4] libmakepkg: lint disallowed architecture specific variables

On Fri, 25 Jan 2019 at 16:05, Dave Reisner wrote: > > On Fri, Jan 25, 2019 at 03:47:14PM +, Morgan Adamiec wrote: > > On Fri, 25 Jan 2019 at 00:52, Allan McRae wrote: > > > > > > On 24/1/19 11:34 pm, Dave Reisner wrote: > > > > On Thu, Jan 24, 2019

Re: [pacman-dev] [PATCH v5 4/4] libmakepkg: lint disallowed architecture specific variables

On Fri, 25 Jan 2019 at 00:52, Allan McRae wrote: > > On 24/1/19 11:34 pm, Dave Reisner wrote: > > On Thu, Jan 24, 2019 at 09:09:59AM +0000, Morgan Adamiec wrote: > >> On Thu, 24 Jan 2019 at 03:01, Allan McRae wrote: > >>> > >>> On 22/1/19

Re: [pacman-dev] [PATCH v5 4/4] libmakepkg: lint disallowed architecture specific variables

On Thu, 24 Jan 2019 at 03:01, Allan McRae wrote: > > On 22/1/19 10:05 am, morganamilo wrote: > > Variables such as 'pkgdesc_x86_64' are invalid, instead of ignoring them > > raise an error. > > > > This also disallows using 'any' as an architecture specific variable > > > > Signed-off-by:

Re: [pacman-dev] [PATCH v5 2/4] libmakepkg: add exists_function_variable helper

On Tue, 22 Jan 2019 at 00:45, Dave Reisner wrote: > > On Mon, Jan 21, 2019 at 07:40:14PM -0500, Dave Reisner wrote: > > On Mon, Jan 21, 2019 at 11:59:30PM +, morganamilo wrote: > > > This helpers functions allows checking for the existence of a package > > > variable without worrying if it is

Re: [pacman-dev] [PATCH] libmakepkg: fix linting arrays of empty strings

On Sun, 21 Oct 2018 at 13:10, Allan McRae wrote: > > On 21/10/18 9:56 pm, Morgan Adamiec wrote: > > On Sun, 21 Oct 2018 at 10:16, Allan McRae wrote: > >> The error this gives is: > >> ==> ERROR: depends is not allowed to be empty. > > > > Whe

Re: [pacman-dev] [PATCH] libmakepkg: fix linting arrays of empty strings

On Sun, 21 Oct 2018 at 10:16, Allan McRae wrote: > The error this gives is: > ==> ERROR: depends is not allowed to be empty. Where so you get this error? pkgname=foo pkgver=1 pkgrel=1 arch=(any) depends=('') This pkgbuild manages to pass linting for me without this patch. (resend,

Re: [pacman-dev] [PATCH v2] libalpm: process needed before group selection

On Thu, 18 Oct 2018 at 01:34, Andrew Gregory wrote: > I wasn't concerned about the misleading message for this patch, but > the failing test is another thing. If you're not testing your patches > with `make check`, please do. We could update the test, but let's > just go ahead and fix the

Re: [pacman-dev] [PATCH 1/2] pacman: fix possible buffer overflow

On Sat, 22 Sep 2018 at 22:57, Andrew Gregory wrote: > Set errno to ENAMETOOLONG and return NULL, just like realpath. The problem still remains. You can input a filename that's < PATH_MAX and have it resolve to something > PATH_MAX. You have no way to print what that resolved path was. You can

Re: [pacman-dev] [PATCH 2/2] pacman: give path too long error after strcat

On Sat, 22 Sep 2018 at 21:54, Andrew Gregory wrote: > > On 09/22/18 at 09:16pm, morganamilo wrote: > > The string only becomes longer than PATH_MAX once adding "/" to the end. > > The error message should give this version of the path. > > > > Signed-off-by: morganamilo > > NACK. The trailing

Re: [pacman-dev] [PATCH] during -Qu add [ignored] for repos without Usage = Upgrade

On Wed, 19 Sep 2018 at 22:28, Allan McRae wrote: > My concern is of users of that function other than pacman (if there are > any...). Adding a parameter at least flags the change in behaviour an > allows other users to keep it the way it was. Ah yeah good point, forgot that other frontends are

Re: [pacman-dev] [PATCH] during -Qu add [ignored] for repos without Usage = Upgrade

Yeah -Qu is still a little funky. > It gets better... packages in databases with Usage = Upgrade do not > show up in -Qu. That is clearly wrong! I left the requirement on Usage = Search after every one disagreed with my patch [1] to change it. Although I would prefer it if Search had no

Re: [pacman-dev] [PATCH] libalpm/sync.c: restrict alpm_sync_newversion by USAGE_UPGRADE

On Wed, 29 Aug 2018 at 06:03, Allan McRae wrote: > Someone should send the pacman-contrib maintainers a patch to use that > instead of -Qu. Sadly you would need some sort of 'currentpkgver' formatter `--print-format "%n %currentpkgver -> %v"`.

Re: [pacman-dev] [PATCH] libalpm/sync.c: restrict alpm_sync_newversion by USAGE_UPGRADE

On Wed, 25 Jul 2018 at 02:28, Andrew Gregory wrote: > It makes no mention of upgrading either It is called alpm_sync_*newversion* >How is that different from just putting that repo below the one you want it to use normally? pacman -S pkg should return an error. These packages are not in any

Re: [pacman-dev] [PATCH] libalpm/sync.c: restrict alpm_sync_newversion by USAGE_UPGRADE

On Tue, 24 Jul 2018 at 20:40, Andrew Gregory wrote: > Based on how it's used, I'd say it should be SEARCH; it's being used > as a filter for -Q and no upgrade transaction is being performed, or > even prepared. > > Really, though, I'd say this is a great example as to why usages > should have

Re: [pacman-dev] [PATCH 3/7] libmakepkg: lint disallowed variables in package()

though. I'd like to get the current issues reviewed and out the way first. On Sun, 24 Jun 2018 at 03:26, Eli Schwartz wrote: > > On 06/23/2018 10:01 PM, Morgan Adamiec wrote: > > Silly mistakes aside. > > > >> These are not variables being overridden... pkgn

Re: [pacman-dev] [PATCH 3/7] libmakepkg: lint disallowed variables in package()

Silly mistakes aside. > These are not variables being overridden... pkgname_i686 is just not a > thing as far as makepkg is concerned. The point of this is specifically disallow things like 'pkgname_i686' rather than just ignore them. > Also, this is nothing to do with > overriding in a

Re: [pacman-dev] [PATCH 7/7] libmakepkg: disallow using 'any' with other arches

On Sun, 24 Jun 2018 at 02:31, Allan McRae wrote: > > On 24/06/18 11:24, Morgan Adamiec wrote: > >> Please append a version of you patch in the subject line. e.g. > >> [PATCH 7/7 v3] > > > > Eli gave me a little walk through on the best practises for pa

Re: [pacman-dev] [PATCH 7/7] libmakepkg: disallow using 'any' with other arches

> Please append a version of you patch in the subject line. e.g. > [PATCH 7/7 v3] Eli gave me a little walk through on the best practises for patches, next patches will include this. > I'm still not happy with this patch. Why not just explicitly check that > "any" is specified on its own,

Re: [pacman-dev] [PATCH 1/7] libmakepkg: disallow empty arch

On Wed, 20 Jun 2018 at 00:52, Allan McRae wrote: > > On 20/06/18 05:54, Eli Schwartz wrote: > > On 06/19/2018 08:28 AM, Allan McRae wrote: > >> On 09/06/18 05:33, Eli Schwartz wrote: > >>> On 06/08/2018 02:18 PM, morganamilo wrote: > We already ensure arch is an array but if arch is never

Re: [pacman-dev] [PATCH 1/7] libmakepkg: disallow empty arch

On Tue, 19 Jun 2018 at 13:28, Allan McRae wrote: > > On 09/06/18 05:33, Eli Schwartz wrote: > > On 06/08/2018 02:18 PM, morganamilo wrote: > >> We already ensure arch is an array but if arch is never defined > >> this error never triggers. Add an explicit check for a missing arch. > > > > Good

Re: [pacman-dev] [PATCH 7/7] libmakepkg: disallow using 'any' with other arches

On Wed, 13 Jun 2018 at 02:31, Eli Schwartz wrote: > > On 06/11/2018 06:57 PM, Morgan Adamiec wrote: > > On Mon, 11 Jun 2018 at 22:27, Eli Schwartz wrote: > >> > >> On 06/11/2018 04:53 PM, morganamilo wrote: > >>> Error if the arch array contains any a

Re: [pacman-dev] [PATCH 7/7] libmakepkg: disallow using 'any' with other arches

On Mon, 11 Jun 2018 at 22:27, Eli Schwartz wrote: > > On 06/11/2018 04:53 PM, morganamilo wrote: > > Error if the arch array contains any and any other values. This also > > fixes a bug where the check for `$arch == 'any'` which only evaluated > > the first value in the array, meaning the rest of

Re: [pacman-dev] [PATCH 2/7] libmakepkg: stop printsrcinfo generating empty values

> Please don't change this to paper over bad PKGBUILDs. the thing is foo= is never declared in the pkgbuild A pkgbuild like this: pkgname=foo pkgver=1 pkgrel=1 arch=('any') package() { depends+=("bar") } Generates a srcinfo like this: pkgbase = foo pkgver = 1 pkgrel = 1 arch = any pkgname =

Re: [pacman-dev] [PATCH 7/7] libmakepkg: disallow using 'any' with other arches

On Fri, 8 Jun 2018 at 20:33, Eli Schwartz wrote: > > On 06/08/2018 02:18 PM, morganamilo wrote: > > Error if the arch array contains any and any other values. This also > > fixes a bug where the check for `$arch == 'any'` which only evaluated > > the first value in the array, meaning the rest of

Re: [pacman-dev] [PATCH 2/7] libmakepkg: stop printsrcinfo generating empty values

On Fri, 8 Jun 2018 at 20:33, Eli Schwartz wrote: > > On 06/08/2018 02:18 PM, morganamilo wrote: > > When a split package overriddes an array using += and the array does not > > exist globally, makepkg --printsrcinfo will print the field with an > > empty vlaue before printing the acual values. >

Re: [pacman-dev] [PATCH v2] makepkg: update help text to describe --packagelist's new behavior

On 29 May 2018 at 18:05, Eli Schwartz wrote: > In commit d8591dd3418d55c5736022ef003891fc03b953e0 when teaching > --packagelist to print the full filepath for built arches only, I forgot > to update the helptext at the same time as I updated the manpage. > > Signed-off-by: Eli Schwartz > --- > >

Re: [pacman-dev] [PATCH 1/1] makepkg: Handle dependencies that contain spaces

On 23 February 2018 at 02:38, Morgan Adamiec <morganam...@gmail.com> wrote: > On 23 February 2018 at 01:59, Eli Schwartz <eschwa...@archlinux.org> wrote: >> On 02/22/2018 07:45 PM, morganamilo wrote: >>> In {,opt,check,make}depends makepkg treats packages that cont

Re: [pacman-dev] [PATCH 1/1] makepkg: Handle dependencies that contain spaces

On 23 February 2018 at 01:59, Eli Schwartz wrote: > On 02/22/2018 07:45 PM, morganamilo wrote: >> In {,opt,check,make}depends makepkg treats packages that contain >> whitespace as separate packages. For example: >> depends=('foo bar') >> Would be treated as two