ff-by: Connor Behan
---
lib/libalpm/alpm.h| 1 +
lib/libalpm/handle.c | 7 +++
lib/libalpm/handle.h | 1 +
lib/libalpm/package.c | 8 +++-
src/pacman/conf.c | 1 +
5 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/lib/libalpm/alpm.h b/lib/libalpm/alpm.h
index cc
ff-by: Connor Behan
---
src/pacman/conf.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/pacman/conf.c b/src/pacman/conf.c
index 3f1b1c3..c982df5 100644
--- a/src/pacman/conf.c
+++ b/src/pacman/conf.c
@@ -1010,6 +1010,13 @@ int parseconfig(const char *file)
if((ret = _parsec
On 13/03/13 11:04 PM, Allan McRae wrote:
> On 14/03/13 15:51, Connor Behan wrote:
>> Calling pacman -Sp is guaranteed not to install a package. So the user's
>> IgnorePkg pref is still respected regardless of whether or not we print
>> the mirror location. Therefore we m
n the case of -Sup as this would mislead the user into
thinking that the upgrade is bigger than it really is. This fixes an
edge case with devtools.
Signed-off-by: Connor Behan
---
src/pacman/conf.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/pacman/conf.c b/src/pacman/conf.c
On 14/03/13 12:37 AM, Allan McRae wrote:
> On 14/03/13 16:37, Connor Behan wrote:
>> Calling pacman -Sp and pacman -Sup are guaranteed not to install a
>> package. So the user's IgnorePkg pref is respected regardless of whether
>> or not we print the mirror location. Ther
On Thu, Mar 14, 2013 at 10:02 AM, Andrew Gregory wrote:
> On 03/15/13 at 02:40am, Allan McRae wrote:
> > On 15/03/13 00:30, Dave Reisner wrote:
> > > On Wed, Mar 13, 2013 at 11:37:10PM -0700, Connor Behan wrote:
> > >> Calling pacman -Sp and pacman -Sup a
On 14/03/13 03:25 PM, Andrew Gregory wrote:
> On 03/14/13 at 12:40pm, Connor Behan wrote:
>> On Thu, Mar 14, 2013 at 10:02 AM, Andrew Gregory >> wrote:
>>> On 03/15/13 at 02:40am, Allan McRae wrote:
>>>> On 15/03/13 00:30, Dave Reisner wrote:
>>>>&g
On 15/03/13 04:49 PM, Andrew Gregory wrote:
> On 03/14/13 at 06:32pm, Connor Behan wrote:
>> On 14/03/13 03:25 PM, Andrew Gregory wrote:
>>> On 03/14/13 at 12:40pm, Connor Behan wrote:
>>>> I could modify the patch so that it limits ignorepkg to packages beside
>
On 16/03/13 06:58 AM, Andrew Gregory wrote:
> --print already implies --noconfirm, no need to do anything there.
> You'll still have to check for --print somewhere in the callback
> process to avoid showing the questions. It just needs to be more
> selective so that only the output is skipped, not
man default is 1 and this is dead code
so there is no libalpm default. We return 1 on print.
Signed-off-by: Connor Behan
---
src/pacman/callback.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/src/pacman/callback.c b/src/pacman/callback.c
index 71d9d04..d46cdbd 100
man default is 1 and this is dead code
so there is no libalpm default. We return 1 on print.
Signed-off-by: Connor Behan
---
src/pacman/callback.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/src/pacman/callback.c b/src/pacman/callback.c
index 71d9d04..66721f5 100644
--- a/src/pacman/
On 14/04/13 07:33 PM, Anatol Pomozov wrote:
> ---
> NEWS | 2 +-
> lib/libalpm/add.c | 2 +-
> lib/libalpm/be_package.c | 4 ++--
> lib/libalpm/deps.c | 2 +-
> lib/libalpm/signing.c | 2 +-
> lib/libalpm/util.c | 6 +++-
default is 1 and the libalpm
default is 0. We return 0 on print even though print should not encounter this.
Signed-off-by: Connor Behan
---
src/pacman/callback.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/pacman/callback.c b/src/pacman/callback.c
index 71d9d04..711d116 100
rinting of ignored packages since the defaults differ for
"ALPM_QUESTION_INSTALL_IGNOREPKG". Adjust the response of this case when
using --print so pacman acts consistently.
Signed-off-by: Connor Behan
---
src/pacman/callback.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/pac
On 16/04/13 09:55 PM, Allan McRae wrote:
> You provide details for many things that are not changed at all by the
> patch. Just detail what is changed (ALPM_QUESTION_INSTALL_IGNOREPKG).
I wouldn't've written all that if I were just setting *response = 1 in
that case and returning. But I am settin
It seems this question has not been used since the 3.0 days.
Signed-off-by: Connor Behan
---
lib/libalpm/alpm.h| 7 +++
src/pacman/callback.c | 9 -
2 files changed, 3 insertions(+), 13 deletions(-)
diff --git a/lib/libalpm/alpm.h b/lib/libalpm/alpm.h
index ccbdd1c..2277a69
On 17/04/13 07:58 PM, Aaron DeVore wrote:
> On Thu, Apr 11, 2013 at 11:11 PM, Allan McRae wrote:
>
>> - Remove of support for PKGBUILDs with only a build() function
>>
> Any chance of delaying that change further? There's a staggeringly large
> number of packages in the AUR that rely on build() ha
Remove a question that hasn't been used since the 3.0 days. To prevent
us from having an ugly enum of questions that is missing a bitmask, this
changes the API of the hidden --ask option.
Signed-off-by: Connor Behan
---
lib/libalpm/alpm.h | 7 +++
src/pacman/callb
Users trying to keep a lightweight system often scan the list of targets
for red flags. This just makes it easier for them.
Signed-off-by: Connor Behan
---
src/pacman/util.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/pacman/util.c b/src/pacman/util.c
On 15/07/13 09:01 PM, Allan McRae wrote:
> On 16/07/13 13:59, Allan McRae wrote:
>> On 16/07/13 13:41, Connor Behan wrote:
>>> Users trying to keep a lightweight system often scan the list of targets
>>> for red flags. This just makes it easier for them.
>>
On 30/09/13 08:30 PM, Allan McRae wrote:
> On 29/09/13 03:01, Lukas Jirkovsky wrote:
>> Accidentally sent this to a wrong address... I hope forwarding this
>> won't break the patch.
>>
>> ---
>> Hi,
>> This patch adds incremental build support for the packages with VCS sources.
>> It is not complet
On 30/09/13 09:01 PM, Allan McRae wrote:
> On 01/10/13 13:55, Connor Behan wrote:
>> On 30/09/13 08:30 PM, Allan McRae wrote:
>>> On 29/09/13 03:01, Lukas Jirkovsky wrote:
>>>> Accidentally sent this to a wrong address... I hope forwarding this
>>>> wo
On 10/04/14 04:59 PM, Andrew Gregory wrote:
> Because this is a rather minimal implementation, my primary concern at this
> point is making sure that no essential features are missing and that I don't
> commit us to anything that would make implementing the remaining features more
> difficult later
On 12/05/14 10:25 PM, lolilolicon wrote:
> On Tue, May 13, 2014 at 1:18 PM, lolilolicon
> wrote:
>> Anyway, maybe we can ask bash to pre-formalize the PKGBUILD a little
>> bit so be can parse it more confidently com, by using abination of
>> `set -x` and `typeset`.
> don't know how it got messed u
24 matches
Mail list logo
