Re: [pacman-dev] [PATCH] Fix segfault during install when a package update adds a new file to 'backup'

2016-04-01 Thread Allan McRae
On 02/04/16 00:52, Will Miles wrote:
> When a new package release adds a new entry to the backup list, no hash exists
> for that file in the previously installed package version.  Fix two places
> where that nonexistent hash may be dereferenced.
> 
> Signed-off-by: Will Miles 
> ---

Just as a query, where are you seeing these non-existent backup hashes?
 Corrupt local databases?

>  lib/libalpm/add.c  | 2 +-
>  lib/libalpm/be_local.c | 4 +++-
>  2 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/libalpm/add.c b/lib/libalpm/add.c
> index f5c9a95..ff0b81d 100644
> --- a/lib/libalpm/add.c
> +++ b/lib/libalpm/add.c
> @@ -341,7 +341,7 @@ static int extract_single_file(alpm_handle_t *handle, 
> struct archive *archive,
>   _alpm_log(handle, ALPM_LOG_DEBUG, "checking hashes for %s\n", 
> origfile);
>   _alpm_log(handle, ALPM_LOG_DEBUG, "current:  %s\n", hash_local);
>   _alpm_log(handle, ALPM_LOG_DEBUG, "new:  %s\n", hash_pkg);
> - _alpm_log(handle, ALPM_LOG_DEBUG, "original: %s\n", hash_orig);
> + _alpm_log(handle, ALPM_LOG_DEBUG, "original: %s\n", (hash_orig 
> ? hash_orig : "NULL") );
>  

Fine - I guess this is needed for non-glibc systems.

>   if(hash_local && hash_pkg && strcmp(hash_local, hash_pkg) == 0) 
> {
>   /* local and new files are the same, updating anyway to 
> get
> diff --git a/lib/libalpm/be_local.c b/lib/libalpm/be_local.c
> index f817822..5e39199 100644
> --- a/lib/libalpm/be_local.c
> +++ b/lib/libalpm/be_local.c
> @@ -1037,7 +1037,9 @@ int _alpm_local_db_write(alpm_db_t *db, alpm_pkg_t 
> *info, alpm_dbinfrq_t inforeq
>   fputs("%BACKUP%\n", fp);
>   for(lp = info->backup; lp; lp = lp->next) {
>   const alpm_backup_t *backup = lp->data;
> - fprintf(fp, "%s\t%s\n", backup->name, 
> backup->hash);
> + if (backup->hash) {
> + fprintf(fp, "%s\t%s\n", backup->name, 
> backup->hash);
> + }

How can this ever happen?

>   }
>   fputc('\n', fp);
>   }
> 


[pacman-dev] [PATCH v2] Handle provides with -Q

2016-04-01 Thread Allan McRae
It is useful to be able to use "pacman -Qi" on any dependency, even if that
dependency is a provide.  For example, on Arch Linux systems, "sh" is provided
by the "bash" package, and many packages depend on "sh". Querying the
package that provides the "sh" dependency currently requires first searching
for "sh".

This patch allows the use of "pacman -Qi" on a provide.

Fixes FS#20650.

Signed-off-by: Allan McRae 
---
 src/pacman/query.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/pacman/query.c b/src/pacman/query.c
index 1d102a9..34d7fcb 100644
--- a/src/pacman/query.c
+++ b/src/pacman/query.c
@@ -468,6 +468,9 @@ int pacman_query(alpm_list_t *targets)
}
} else {
pkg = alpm_db_get_pkg(db_local, strname);
+   if(pkg == NULL) {
+   pkg = 
alpm_find_satisfier(alpm_db_get_pkgcache(db_local), strname);
+   }
 
if(pkg == NULL) {
pm_printf(ALPM_LOG_ERROR,
-- 
2.7.4


[pacman-dev] [PATCH] pacman_query: move error messages into relevant if statements

2016-04-01 Thread Allan McRae
This ensures any additions to these test do not have to rely on the correct
error condition being set by libalpm.

Signed-off-by: Allan McRae 
---
 src/pacman/query.c | 32 
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/src/pacman/query.c b/src/pacman/query.c
index 0cc12e6..1d102a9 100644
--- a/src/pacman/query.c
+++ b/src/pacman/query.c
@@ -460,27 +460,27 @@ int pacman_query(alpm_list_t *targets)
 
if(config->op_q_isfile) {
alpm_pkg_load(config->handle, strname, 1, 0, &pkg);
+
+   if(pkg == NULL) {
+   pm_printf(ALPM_LOG_ERROR,
+   _("could not load package '%s': 
%s\n"), strname,
+   
alpm_strerror(alpm_errno(config->handle)));
+   }
} else {
pkg = alpm_db_get_pkg(db_local, strname);
+
+   if(pkg == NULL) {
+   pm_printf(ALPM_LOG_ERROR,
+   _("package '%s' was not 
found\n"), strname);
+   if(!config->op_q_isfile && access(strname, 
R_OK) == 0) {
+   pm_printf(ALPM_LOG_WARNING,
+   _("'%s' is a file, you 
might want to use %s.\n"),
+   strname, "-p/--file");
+   }
+   }
}
 
if(pkg == NULL) {
-   switch(alpm_errno(config->handle)) {
-   case ALPM_ERR_PKG_NOT_FOUND:
-   pm_printf(ALPM_LOG_ERROR,
-   _("package '%s' was not 
found\n"), strname);
-   if(!config->op_q_isfile && 
access(strname, R_OK) == 0) {
-   pm_printf(ALPM_LOG_WARNING,
-   _("'%s' is a 
file, you might want to use %s.\n"),
-   strname, 
"-p/--file");
-   }
-   break;
-   default:
-   pm_printf(ALPM_LOG_ERROR,
-   _("could not load 
package '%s': %s\n"), strname,
-   
alpm_strerror(alpm_errno(config->handle)));
-   break;
-   }
ret = 1;
continue;
}
-- 
2.7.4


Re: [pacman-dev] Open up a place for BUILDENV extensions

2016-04-01 Thread Que Quotion

>Allan
Thank you for your consideration; it is encouraging.

I don't mean to be pushy, and I don't mind who gets the thing done or 
when--I really just want to see the idea implemented one way or another.


>Reisner
My reply to you went off thread again; I'm trying to get the hang of it.


Re: [pacman-dev] Open up a place for BUILDENV extensions

2016-04-01 Thread Que Quotion
>You don't see the problem? I suppose you might not because your mail 
client is completely shit and you've again dropped the thread.


You're just going to have to believe me that I really am trying to get 
this right. And no, I didn't see the problem; looked over it and over 
it. Somehow just could not process that an "r" was missing there...


Is the "declare" line unnecessary? I know the scripts themselves will 
create the bash variable "extra_buildopts" but I put in this line 
mirroring tidy.sh--is it unnecessary there too?


>Repeatedly using the excuse "but that's what tidy.sh does" isn't 
endearing, nor convincing me that you care about your work.
I only mean to point out that you are asking me to propose code that 
would be of a higher standard than what is in the repository. I get it, 
that's a good thing, but don't act like these problems were entirely my 
creation--I've imitated the work of the pacman devs in an earnest 
attempt to have this code integrated.


Re: [pacman-dev] Open up a place for BUILDENV extensions

2016-04-01 Thread Allan McRae
On 02/04/16 09:14, Que Quotion wrote:
> That could be fixed very easily, but again: copy pasta from tidy.sh. If
> you have a problem with this code--you should have a problem with that
> code too. Furthermore, as I have suggested in the forum (and posted a
> patch for), the first thing I would do with this if it were up to me is
> move ccache and distcc out of makepkg and ship them as builenv_ext
> scripts. Then you'd be shipping something that makes this unsafe code
> work just the way the same unsafe code works in tidy.sh.

The tidy and {package,pkgbuild}_lint passes, all started by moving as
much as possible out of makepkg itself and into libmakepkg.  Once that
was done, then the ability to extend those passes was added.

That is the order things need to be done for the buildenv setup too.  I
have not commented on your patch because I require the time to look into
whether moving all that outside of makepkg is even plausible.  And if I
spend that much time looking into whether it can be done, I might as
well do it...

Until that time, there is no need to bump your patch.  It is not lost
(we have a patchwork instance tracking all submitted patches), and the
next release is a long time away.

Allan


[pacman-dev] [PATCH v3 2/2] ccache and distcc as buildenv_ext scripts

2016-04-01 Thread quequotion
From: Que Quotion 

I really only mean these as an example, but it does allow for a little more 
simplification to makepkg.
I like the idea that the only built-in build_options would be 'buildflags' and 
'makeflags'.

---
 scripts/libmakepkg/buildenv_ext/ccache.sh.in | 46 
 scripts/libmakepkg/buildenv_ext/distcc.sh.in | 45 
 scripts/makepkg.sh.in| 36 +-
 3 files changed, 92 insertions(+), 35 deletions(-)
 create mode 100644 scripts/libmakepkg/buildenv_ext/ccache.sh.in
 create mode 100644 scripts/libmakepkg/buildenv_ext/distcc.sh.in

diff --git a/scripts/libmakepkg/buildenv_ext/ccache.sh.in 
b/scripts/libmakepkg/buildenv_ext/ccache.sh.in
new file mode 100644
index 000..8d9e0b5
--- /dev/null
+++ b/scripts/libmakepkg/buildenv_ext/ccache.sh.in
@@ -0,0 +1,46 @@
+#!/usr/bin/bash
+#
+#   ccache.sh - Cache compiliations and recycle them to save time on 
repititions
+#
+#   Copyright (c) 2008-2016 Pacman Development Team 
+#
+#   This program is free software; you can redistribute it and/or modify
+#   it under the terms of the GNU General Public License as published by
+#   the Free Software Foundation; either version 2 of the License, or
+#   (at your option) any later version.
+#
+#   This program is distributed in the hope that it will be useful,
+#   but WITHOUT ANY WARRANTY; without even the implied warranty of
+#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+#   GNU General Public License for more details.
+#
+#   You should have received a copy of the GNU General Public License
+#   along with this program.  If not, see .
+#
+
+[[ -n "$LIBMAKEPKG_CCACHE_SH" ]] && return
+LIBMAKEPKG_CCACHE_SH=1
+
+LIBRARY=${LIBRARY:-'@libmakepkgdir@'}
+
+source "$LIBRARY/util/message.sh"
+source "$LIBRARY/util/option.sh"
+
+extra_buildopts+=('ccache')
+
+local ccache=0
+
+ccache() {
+
+   # use ccache if it is requested (check buildenv and PKGBUILD opts)
+   if check_buildoption "ccache" "y"; then
+   if ! type -p ccache >/dev/null; then
+   error "$(gettext "Cannot find the %s binary required 
for compiler cache usage.")" "ccache"
+   return 1
+   fi
+   if [ -d /usr/lib/ccache/bin ]; then
+   export PATH="/usr/lib/ccache/bin:$PATH"
+   ccache=1
+   fi
+   fi
+}
diff --git a/scripts/libmakepkg/buildenv_ext/distcc.sh.in 
b/scripts/libmakepkg/buildenv_ext/distcc.sh.in
new file mode 100644
index 000..248445a
--- /dev/null
+++ b/scripts/libmakepkg/buildenv_ext/distcc.sh.in
@@ -0,0 +1,45 @@
+#!/usr/bin/bash
+#
+#   distcc.sh - Distribute compliation to reduce compilation time
+#
+#   Copyright (c) 2008-2016 Pacman Development Team 
+#
+#   This program is free software; you can redistribute it and/or modify
+#   it under the terms of the GNU General Public License as published by
+#   the Free Software Foundation; either version 2 of the License, or
+#   (at your option) any later version.
+#
+#   This program is distributed in the hope that it will be useful,
+#   but WITHOUT ANY WARRANTY; without even the implied warranty of
+#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+#   GNU General Public License for more details.
+#
+#   You should have received a copy of the GNU General Public License
+#   along with this program.  If not, see .
+#
+
+[[ -n "$LIBMAKEPKG_CCACHE_SH" ]] && return
+LIBMAKEPKG_CCACHE_SH=1
+
+LIBRARY=${LIBRARY:-'@libmakepkgdir@'}
+
+source "$LIBRARY/util/message.sh"
+source "$LIBRARY/util/option.sh"
+
+extra_buildopts+=('distcc')
+
+distcc() {
+   if check_buildoption "distcc" "y"; then
+   if ! type -p distcc >/dev/null; then
+   error "$(gettext "Cannot find the %s binary required 
for distributed compilation.")" "distcc"
+   return 1
+   fi
+   if (( ccache )); then
+   export CCACHE_PREFIX="${CCACHE_PREFIX:+$CCACHE_PREFIX 
}distcc"
+   export CCACHE_BASEDIR="$srcdir"
+   elif [[ -d /usr/lib/distcc/bin ]]; then
+   export PATH="/usr/lib/distcc/bin:$PATH"
+   fi
+   export DISTCC_HOSTS
+   fi
+}
diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in
index aafec5d..e5f2028 100644
--- a/scripts/makepkg.sh.in
+++ b/scripts/makepkg.sh.in
@@ -48,7 +48,7 @@ declare -r startdir="$PWD"
 
 LIBRARY=${LIBRARY:-'@libmakepkgdir@'}
 
-build_options=('ccache' 'distcc' 'buildflags' 'makeflags')
+build_options=('buildflags' 'makeflags')
 splitpkg_overrides=('pkgdesc' 'arch' 'url' 'license' 'groups' 'depends'
 'optdepends' 'provides' 'conflicts' 'replaces' 'backup'
 'options' 'install' 'changelog')
@@ -847,24 +847,6 @@ run_prepare() {
 }
 
 run_build() {
-   l

[pacman-dev] [PATCH v3 1/2] Open up a place for BUILDENV extensions

2016-04-01 Thread quequotion
From: Que Quotion 

Attempting to address certain concerns.

---
 scripts/libmakepkg/buildenv_ext.sh.in | 46 +++
 scripts/Makefile.am   |  2 ++
 scripts/makepkg.sh.in |  3 +++
 3 files changed, 51 insertions(+)
 create mode 100644 scripts/libmakepkg/buildenv_ext.sh.in

diff --git a/scripts/libmakepkg/buildenv_ext.sh.in 
b/scripts/libmakepkg/buildenv_ext.sh.in
new file mode 100644
index 000..a877b87
--- /dev/null
+++ b/scripts/libmakepkg/buildenv_ext.sh.in
@@ -0,0 +1,46 @@
+#!/usr/bin/bash
+#
+#   buildenv_ext.sh - addional functions for altering the build environment
+#   before compiliation
+#
+#   Copyright (c) 2015-2016 Pacman Development Team 
+#
+#   This program is free software; you can redistribute it and/or modify
+#   it under the terms of the GNU General Public License as published by
+#   the Free Software Foundation; either version 2 of the License, or
+#   (at your option) any later version.
+#
+#   This program is distributed in the hope that it will be useful,
+#   but WITHOUT ANY WARRANTY; without even the implied warranty of
+#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+#   GNU General Public License for more details.
+#
+#   You should have received a copy of the GNU General Public License
+#   along with this program.  If not, see .
+#
+
+[[ -n "$LIBMAKEPKG_BUILDENV_EXT_SH" ]] && return
+LIBMAKEPKG_BUILDENV_EXT_SH=1
+
+LIBRARY=${LIBRARY:-'@libmakepkgdir@'}
+
+declare -a extra_buildopts
+
+shopt -s nullglob #in case of no buildenv_ext scripts
+
+for lib in "$LIBRARY/buildenv_ext/"*.sh; do
+   source "$lib"
+done
+
+shopt -u nullglob #put this back where we found it
+
+readonly -a extra_buildopts
+
+buildenv_ext() {
+
+   # options that alter compilation parameters
+   for func in "${extra_buildopts[@]}"; do
+   "$func"
+   done
+
+}
diff --git a/scripts/Makefile.am b/scripts/Makefile.am
index 6f9abb8..a633827 100644
--- a/scripts/Makefile.am
+++ b/scripts/Makefile.am
@@ -45,6 +45,7 @@ LIBMAKEPKGDIRS = \
lint_pkgbuild \
source \
tidy \
+   buildenv_ext \
util
 
 LIBMAKEPKG = \
@@ -82,6 +83,7 @@ LIBMAKEPKG_IN = \
libmakepkg/source/local.sh \
libmakepkg/source/svn.sh \
libmakepkg/tidy.sh \
+   libmakepkg/buildenv_ext.sh \
libmakepkg/tidy/docs.sh \
libmakepkg/tidy/emptydirs.sh \
libmakepkg/tidy/libtool.sh \
-- 
2.7.4
diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in
index 2efcc98..aafec5d 100644
--- a/scripts/makepkg.sh.in
+++ b/scripts/makepkg.sh.in
@@ -866,6 +866,9 @@ run_build() {
export DISTCC_HOSTS
fi
 
+   # Check for BUILDENV extensions, use any that are requested (check 
buildenv and PKGBUILD opts)
+   buildenv_ext
+
run_function_safe "build"
 }
 
-- 
2.7.4


Re: [pacman-dev] Open up a place for BUILDENV extensions

2016-04-01 Thread Dave Reisner
On Sat, Apr 02, 2016 at 08:14:16AM +0900, Que Quotion wrote:
> Sorry to double-post. This will be my second attempt to get this right, with
> yet another email client (gmail can't; geary failed; thunderbird?).
> 
> >How exactly is this related to BUILDENV? This seems to be allowing
> arbitrary code to run before executing the build() function.
> 
> You can use the word "arbitrary" to make it sound like a bad idea if
> you like, but it very simply does for BUILDENV exactly what tidy.sh
> does for OPTIONS: allow for supplemental scripts to add to makepkg's
> functionality at this stage.
> 
> In fact, it does it in exactly the same way--because nearly all of this
> code was copied and pasted from tidy.sh.
> 
> Just as tidy.sh allows any kind of anything to be run, it could allow
> any bash script to be run here--but the intention is for scripts that
> serve build-environment altering functions to be run here (as the
> intention for tidy.sh is to run cleanup and compression scripts).
> 
> Your concern about cleanup seems misplaced. It will be up to the
> authors of supplemental scripts to make sure they work properly, and
> users who trust them to install and enable those features. This
> patch--in and of itself--will not cause the problems you are worried
> about.
> 
>  >This line does nothing, even if correctly spelled.
> 
> What is misspelled? This is intended to serve the same purpose as the
> same line serves in tidy.sh:

You don't see the problem? I suppose you might not because your mail
client is completely shit and you've again dropped the thread.

Consider:

  declare -a exta_buildopts

vs.

  readonly -a extra_buildopts

and:

  for func in ${extra_buildopts[@]}; do

Do I really need to point out "exta" vs "extra" ?

> declare -a packaging_options tidy_remove tidy_modify
> 
> The tidy scripts have names like upx.sh, the buildenv_ext scripts will
> have names like pgo.sh; these variables store the names of those
> options as they will be known in makepkg(-optimize).conf (upx, pgo).
> 
>  >Since nullglob isn't set, an empty directory will cause this to throw
> an error about a missing file (as the glob will turn into a literal). As
> there's no "buildenv_ext" files provided by makepkg, this means we error
> by default.
> 
> That could be fixed very easily, but again: copy pasta from tidy.sh. If
> you have a problem with this code--you should have a problem with that
> code too. Furthermore, as I have suggested in the forum (and posted a
> patch for), the first thing I would do with this if it were up to me is
> move ccache and distcc out of makepkg and ship them as builenv_ext
> scripts. Then you'd be shipping something that makes this unsafe code
> work just the way the same unsafe code works in tidy.sh.

Repeatedly using the excuse "but that's what tidy.sh does" isn't
endearing, nor convincing me that you care about your work.

>  >quoting
> 
> Sure, no problem. That also needs to be fixed in tidy.sh


Re: [pacman-dev] Open up a place for BUILDENV extensions

2016-04-01 Thread Que Quotion
Sorry to double-post. This will be my second attempt to get this right, 
with yet another email client (gmail can't; geary failed; thunderbird?).


>How exactly is this related to BUILDENV? This seems to be allowing
arbitrary code to run before executing the build() function.

You can use the word "arbitrary" to make it sound like a bad idea if
you like, but it very simply does for BUILDENV exactly what tidy.sh
does for OPTIONS: allow for supplemental scripts to add to makepkg's
functionality at this stage.

In fact, it does it in exactly the same way--because nearly all of this
code was copied and pasted from tidy.sh.

Just as tidy.sh allows any kind of anything to be run, it could allow
any bash script to be run here--but the intention is for scripts that
serve build-environment altering functions to be run here (as the
intention for tidy.sh is to run cleanup and compression scripts).

Your concern about cleanup seems misplaced. It will be up to the
authors of supplemental scripts to make sure they work properly, and
users who trust them to install and enable those features. This
patch--in and of itself--will not cause the problems you are worried
about.

 >This line does nothing, even if correctly spelled.

What is misspelled? This is intended to serve the same purpose as the
same line serves in tidy.sh:

declare -a packaging_options tidy_remove tidy_modify

The tidy scripts have names like upx.sh, the buildenv_ext scripts will
have names like pgo.sh; these variables store the names of those
options as they will be known in makepkg(-optimize).conf (upx, pgo).

 >Since nullglob isn't set, an empty directory will cause this to throw
an error about a missing file (as the glob will turn into a literal). As
there's no "buildenv_ext" files provided by makepkg, this means we error
by default.

That could be fixed very easily, but again: copy pasta from tidy.sh. If
you have a problem with this code--you should have a problem with that
code too. Furthermore, as I have suggested in the forum (and posted a
patch for), the first thing I would do with this if it were up to me is
move ccache and distcc out of makepkg and ship them as builenv_ext
scripts. Then you'd be shipping something that makes this unsafe code
work just the way the same unsafe code works in tidy.sh.

 >quoting

Sure, no problem. That also needs to be fixed in tidy.sh


[pacman-dev] Open up a place for BUILDENV extensions

2016-04-01 Thread Que Quotion
>How exactly is this related to BUILDENV? This seems to be allowing 
arbitrary code to run before executing the build() function.


You can use the word "arbitrary" to make it sound like a bad idea if 
you like, but it very simply does for BUILDENV exactly what tidy.sh 
does for OPTIONS: allow for supplemental scripts to add to makepkg's 
functionality at this stage.


In fact, it does it in exactly the same way--because nearly all of this 
code was copied and pasted from tidy.sh.


Just as tidy.sh allows any kind of anything to be run, it could allow 
any bash script to be run here--but the intention is for scripts that 
serve build-environment altering functions to be run here (as the 
intention for tidy.sh is to run cleanup and compression scripts).


Your concern about cleanup seems misplaced. It will be up to the 
authors of supplemental scripts to make sure they work properly, and 
users who trust them to install and enable those features. This 
patch--in and of itself--will not cause the problems you are worried 
about.


>This line does nothing, even if correctly spelled.

What is misspelled? This is intended to serve the same purpose as the 
same line serves in tidy.sh:


declare -a packaging_options tidy_remove tidy_modify

The tidy scripts have names like upx.sh, the buildenv_ext scripts will 
have names like svgo.sh; these variables store the names of those 
options as they will be known in makepkg(-optimize).conf.


>Since nullglob isn't set, an empty directory will cause this to throw
an error about a missing file (as the glob will turn into a literal). As
there's no "buildenv_ext" files provided by makepkg, this means we error
by default.

That could be fixed very easily, but again: copy pasta from tidy.sh. If 
you have a problem with this code--you should have a problem with that 
code too. Furthermore, as I have suggested in the forum (and posted a 
patch for), the first thing I would do with this if it were up to me is 
move ccache and distcc out of makepkg and ship them as builenv_ext 
scripts. Then you'd be shipping something that makes this unsafe code 
work just the way the same unsafe code works in tidy.sh.


>quoting

Sure, no problem. That also needs to be fixed in tidy.sh.


Re: [pacman-dev] Fwd: Re: [PATCH] libmakepkg: extension for additional BUILDENV options

2016-04-01 Thread Dave Reisner
On Fri, Apr 01, 2016 at 09:31:51PM +0200, Alad Wenter wrote:
> https://www.archlinux.org/pacman/submitting-patches.html
> 
> And please, click "Reply list" next time.
> 
> 
>  Forwarded Message 
> Subject:  Re: [PATCH] libmakepkg: extension for additional BUILDENV 
> options
> Date: Sat, 2 Apr 2016 04:14:58 +0900
> From: Que Quotion 
> To:   a...@archlinux.info
> 
> 
> 
> >Talking of unncessery email, can you please just follow convention instead 
> >of spamming our mailboxes with semantics?
> 
> I have an even better idea: have your conventions documented somewhere. If 
> they already are, send people who obviously weren't born knowing them to that 
> place and exercise a little understanding.
> 
> 
> 

https://www.archlinux.org/pacman/submitting-patches.html

And this is in the repo, too:

https://projects.archlinux.org/pacman.git/tree/doc/submitting-patches.txt


Re: [pacman-dev] [PATCH v2 1/1] Open up a place for BUILDENV extensions

2016-04-01 Thread Dave Reisner
On Sat, Apr 02, 2016 at 03:52:07AM +0900, quequot...@gmail.com wrote:
> From: Que Quotion 
> 
> ---

How exactly is this related to BUILDENV? This seems to be allowing
arbitrary code to run before executing the build() function. What about
allowing for cleanup after build()? Otherwise, you leak side effects
into check() and package() as well.

>  scripts/libmakepkg/buildenv_ext.sh.in | 42 
> +++
>  scripts/Makefile.am   |  2 ++
>  scripts/makepkg.sh.in |  3 +++
>  3 files changed, 47 insertions(+)
>  create mode 100644 scripts/libmakepkg/buildenv_ext.sh.in
> 
> diff --git a/scripts/libmakepkg/buildenv_ext.sh.in 
> b/scripts/libmakepkg/buildenv_ext.sh.in
> new file mode 100644
> index 000..a877b87
> --- /dev/null
> +++ b/scripts/libmakepkg/buildenv_ext.sh.in
> @@ -0,0 +1,42 @@
> +#!/usr/bin/bash
> +#
> +#   buildenv_ext.sh - addional functions for altering the build environment
> +#   before compiliation
> +#
> +#   Copyright (c) 2015-2016 Pacman Development Team 
> 
> +#
> +#   This program is free software; you can redistribute it and/or modify
> +#   it under the terms of the GNU General Public License as published by
> +#   the Free Software Foundation; either version 2 of the License, or
> +#   (at your option) any later version.
> +#
> +#   This program is distributed in the hope that it will be useful,
> +#   but WITHOUT ANY WARRANTY; without even the implied warranty of
> +#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +#   GNU General Public License for more details.
> +#
> +#   You should have received a copy of the GNU General Public License
> +#   along with this program.  If not, see .
> +#
> +
> +[[ -n "$LIBMAKEPKG_BUILDENV_EXT_SH" ]] && return
> +LIBMAKEPKG_BUILDENV_EXT_SH=1
> +
> +LIBRARY=${LIBRARY:-'@libmakepkgdir@'}
> +
> +declare -a exta_buildopts

This line does nothing, even if correctly spelled.

> +
> +for lib in "$LIBRARY/buildenv_ext/"*.sh; do

Since nullglob isn't set, an empty directory will cause this to throw
an error about a missing file (as the glob will turn into a literal). As
there's no "buildenv_ext" files provided by makepkg, this means we error
by default.

> + source "$lib"
> +done
> +
> +readonly -a extra_buildopts
> +
> +buildenv_ext() {
> +
> + # options that alter compilation parameters
> + for func in ${extra_buildopts[@]}; do
> + $func

quoting...

  for func in "${extra_buildopts[@]}"; do
"$func"
  done

> + done
> +
> +}
> diff --git a/scripts/Makefile.am b/scripts/Makefile.am
> index 6f9abb8..a633827 100644
> --- a/scripts/Makefile.am
> +++ b/scripts/Makefile.am
> @@ -45,6 +45,7 @@ LIBMAKEPKGDIRS = \
>   lint_pkgbuild \
>   source \
>   tidy \
> + buildenv_ext \
>   util
>  
>  LIBMAKEPKG = \
> @@ -82,6 +83,7 @@ LIBMAKEPKG_IN = \
>   libmakepkg/source/local.sh \
>   libmakepkg/source/svn.sh \
>   libmakepkg/tidy.sh \
> + libmakepkg/buildenv_ext.sh \
>   libmakepkg/tidy/docs.sh \
>   libmakepkg/tidy/emptydirs.sh \
>   libmakepkg/tidy/libtool.sh \
> -- 
> 2.7.4
> diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in
> index 2efcc98..aafec5d 100644
> --- a/scripts/makepkg.sh.in
> +++ b/scripts/makepkg.sh.in
> @@ -866,6 +866,9 @@ run_build() {
>   export DISTCC_HOSTS
>   fi
>  
> + # Check for BUILDENV extensions, use any that are requested (check 
> buildenv and PKGBUILD opts)
> + buildenv_ext
> +
>   run_function_safe "build"
>  }
>  
> -- 
> 2.7.4


[pacman-dev] Fwd: Re: [PATCH] libmakepkg: extension for additional BUILDENV options

2016-04-01 Thread Alad Wenter

https://www.archlinux.org/pacman/submitting-patches.html

And please, click "Reply list" next time.


 Forwarded Message 
Subject:Re: [PATCH] libmakepkg: extension for additional BUILDENV 
options
Date:   Sat, 2 Apr 2016 04:14:58 +0900
From:   Que Quotion 
To: a...@archlinux.info




Talking of unncessery email, can you please just follow convention instead of 
spamming our mailboxes with semantics?


I have an even better idea: have your conventions documented somewhere. If they 
already are, send people who obviously weren't born knowing them to that place 
and exercise a little understanding.





[pacman-dev] [PATCH v2 1/1] Open up a place for BUILDENV extensions

2016-04-01 Thread quequotion
From: Que Quotion 

---
 scripts/libmakepkg/buildenv_ext.sh.in | 42 +++
 scripts/Makefile.am   |  2 ++
 scripts/makepkg.sh.in |  3 +++
 3 files changed, 47 insertions(+)
 create mode 100644 scripts/libmakepkg/buildenv_ext.sh.in

diff --git a/scripts/libmakepkg/buildenv_ext.sh.in 
b/scripts/libmakepkg/buildenv_ext.sh.in
new file mode 100644
index 000..a877b87
--- /dev/null
+++ b/scripts/libmakepkg/buildenv_ext.sh.in
@@ -0,0 +1,42 @@
+#!/usr/bin/bash
+#
+#   buildenv_ext.sh - addional functions for altering the build environment
+#   before compiliation
+#
+#   Copyright (c) 2015-2016 Pacman Development Team 
+#
+#   This program is free software; you can redistribute it and/or modify
+#   it under the terms of the GNU General Public License as published by
+#   the Free Software Foundation; either version 2 of the License, or
+#   (at your option) any later version.
+#
+#   This program is distributed in the hope that it will be useful,
+#   but WITHOUT ANY WARRANTY; without even the implied warranty of
+#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+#   GNU General Public License for more details.
+#
+#   You should have received a copy of the GNU General Public License
+#   along with this program.  If not, see .
+#
+
+[[ -n "$LIBMAKEPKG_BUILDENV_EXT_SH" ]] && return
+LIBMAKEPKG_BUILDENV_EXT_SH=1
+
+LIBRARY=${LIBRARY:-'@libmakepkgdir@'}
+
+declare -a exta_buildopts
+
+for lib in "$LIBRARY/buildenv_ext/"*.sh; do
+   source "$lib"
+done
+
+readonly -a extra_buildopts
+
+buildenv_ext() {
+
+   # options that alter compilation parameters
+   for func in ${extra_buildopts[@]}; do
+   $func
+   done
+
+}
diff --git a/scripts/Makefile.am b/scripts/Makefile.am
index 6f9abb8..a633827 100644
--- a/scripts/Makefile.am
+++ b/scripts/Makefile.am
@@ -45,6 +45,7 @@ LIBMAKEPKGDIRS = \
lint_pkgbuild \
source \
tidy \
+   buildenv_ext \
util
 
 LIBMAKEPKG = \
@@ -82,6 +83,7 @@ LIBMAKEPKG_IN = \
libmakepkg/source/local.sh \
libmakepkg/source/svn.sh \
libmakepkg/tidy.sh \
+   libmakepkg/buildenv_ext.sh \
libmakepkg/tidy/docs.sh \
libmakepkg/tidy/emptydirs.sh \
libmakepkg/tidy/libtool.sh \
-- 
2.7.4
diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in
index 2efcc98..aafec5d 100644
--- a/scripts/makepkg.sh.in
+++ b/scripts/makepkg.sh.in
@@ -866,6 +866,9 @@ run_build() {
export DISTCC_HOSTS
fi
 
+   # Check for BUILDENV extensions, use any that are requested (check 
buildenv and PKGBUILD opts)
+   buildenv_ext
+
run_function_safe "build"
 }
 
-- 
2.7.4


[pacman-dev] [PATCH v2 0/1] libmakepkg: extension for additional BUILDENV options

2016-04-01 Thread quequotion
From: Que Quotion 

Resubmitting as requested, in the format requested, by the means requested.

buildenv_ext.sh does for BUILDENV what tidy.sh does for OPTIONS

---
 scripts/Makefile.am   |  2 ++
 scripts/libmakepkg/buildenv_ext.sh.in | 42 +++
 scripts/makepkg.sh.in |  3 +++
 3 files changed, 47 insertions(+)
 create mode 100644 scripts/libmakepkg/buildenv_ext.sh.in

-- 
2.7.4


Re: [pacman-dev] [PATCH] libmakepkg: extension for additional BUILDENV options

2016-04-01 Thread Alad Wenter

On 01.04.2016 20:31, Que Quotion wrote:

apg

Until a very few moments ago, I was not subscribed to this mailing list. I
do not intend to be subscribed after this is resolved. There is no other
issue on the mailing list for which it is necessary for me to subscribe and
I care very much when unnecessary email comes to my inbox.

There's no way to get header information without being a subscriber, so I'm
never going to get the Message-ID for any past messages. As a result, I'm
left with no choice but to post my patches (with all the appropriate
git-format bells and whistles) as either a new thread or a reply to this
one.

I'm going with new thread, since it is apparently standard practice to
indicate patch version numbers in the subject line and--last week--I did
bump the patch to v2.
Talking of unncessery email, can you please just follow convention 
instead of spamming our mailboxes with semantics?


Alad


Re: [pacman-dev] [PATCH] libmakepkg: extension for additional BUILDENV options

2016-04-01 Thread Que Quotion
>>apg

Until a very few moments ago, I was not subscribed to this mailing list. I
do not intend to be subscribed after this is resolved. There is no other
issue on the mailing list for which it is necessary for me to subscribe and
I care very much when unnecessary email comes to my inbox.

There's no way to get header information without being a subscriber, so I'm
never going to get the Message-ID for any past messages. As a result, I'm
left with no choice but to post my patches (with all the appropriate
git-format bells and whistles) as either a new thread or a reply to this
one.

I'm going with new thread, since it is apparently standard practice to
indicate patch version numbers in the subject line and--last week--I did
bump the patch to v2.


Re: [pacman-dev] [PATCH] libmakepkg: extension for additional BUILDENV options

2016-04-01 Thread Andrew Gregory
On 04/02/16 at 02:16am, Que Quotion wrote:
> On Sat, Apr 2, 2016 at 1:31 AM, Que Quotion  wrote:
> 
> > >>apg
> >
> > I was not aware that there is any such patch submission procedure.
> > I will resubmit the patch shortly.
> >
> >
> > Actually, this has proven to be exceedingly difficult. The pacman-dev
> archive does not offer header information, so it will not be possible for
> me to reply to any specific Message-ID (the best I can do, even with git
> send-email, is "Re: this discussion subject line").

Why are you looking at the archive?  Get the Message-ID from your mail
client.  And, again, please fix your mail client so that your replies
don't break the existing thread.  It is very difficult to follow the
conversation when all of your replies start a new thread.

> In fact, I did submit a properly formatted patch over a week ago but
> it has been ignored long enough to be in last month's discussion
> archive.
>
> Please look at my properly formatted patch under the same heading in last
> month's (last week's) discussion. Resubmitting this patch would be
> redundant.

You have not submitted a properly formatted patch.  Every patch you
have submitted was broken.  Your patch needs to be inline and properly
formatted to be applied with `git am`.  Using `git send-email` is the
easiest way to accomplish that.

apg


Re: [pacman-dev] [PATCH] libmakepkg: extension for additional BUILDENV options

2016-04-01 Thread Que Quotion
On Sat, Apr 2, 2016 at 1:31 AM, Que Quotion  wrote:

> >>apg
>
> I was not aware that there is any such patch submission procedure. I will 
> resubmit the patch shortly.
>
>
> Actually, this has proven to be exceedingly difficult. The pacman-dev
archive does not offer header information, so it will not be possible for
me to reply to any specific Message-ID (the best I can do, even with git
send-email, is "Re: this discussion subject line"). In fact, I did submit a
properly formatted patch over a week ago but it has been ignored long
enough to be in last month's discussion archive.

Please look at my properly formatted patch under the same heading in last
month's (last week's) discussion. Resubmitting this patch would be
redundant.


Re: [pacman-dev] [PATCH] libmakepkg: extension for additional BUILDENV options

2016-04-01 Thread Que Quotion
>>apg

I was not aware that there is any such patch submission procedure. I
will resubmit the patch shortly.


[pacman-dev] [PATCH] Fix segfault during install when a package update adds a new file to 'backup'

2016-04-01 Thread Will Miles
When a new package release adds a new entry to the backup list, no hash exists
for that file in the previously installed package version.  Fix two places
where that nonexistent hash may be dereferenced.

Signed-off-by: Will Miles 
---
 lib/libalpm/add.c  | 2 +-
 lib/libalpm/be_local.c | 4 +++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/lib/libalpm/add.c b/lib/libalpm/add.c
index f5c9a95..ff0b81d 100644
--- a/lib/libalpm/add.c
+++ b/lib/libalpm/add.c
@@ -341,7 +341,7 @@ static int extract_single_file(alpm_handle_t *handle, 
struct archive *archive,
_alpm_log(handle, ALPM_LOG_DEBUG, "checking hashes for %s\n", 
origfile);
_alpm_log(handle, ALPM_LOG_DEBUG, "current:  %s\n", hash_local);
_alpm_log(handle, ALPM_LOG_DEBUG, "new:  %s\n", hash_pkg);
-   _alpm_log(handle, ALPM_LOG_DEBUG, "original: %s\n", hash_orig);
+   _alpm_log(handle, ALPM_LOG_DEBUG, "original: %s\n", (hash_orig 
? hash_orig : "NULL") );
 
if(hash_local && hash_pkg && strcmp(hash_local, hash_pkg) == 0) 
{
/* local and new files are the same, updating anyway to 
get
diff --git a/lib/libalpm/be_local.c b/lib/libalpm/be_local.c
index f817822..5e39199 100644
--- a/lib/libalpm/be_local.c
+++ b/lib/libalpm/be_local.c
@@ -1037,7 +1037,9 @@ int _alpm_local_db_write(alpm_db_t *db, alpm_pkg_t *info, 
alpm_dbinfrq_t inforeq
fputs("%BACKUP%\n", fp);
for(lp = info->backup; lp; lp = lp->next) {
const alpm_backup_t *backup = lp->data;
-   fprintf(fp, "%s\t%s\n", backup->name, 
backup->hash);
+   if (backup->hash) {
+   fprintf(fp, "%s\t%s\n", backup->name, 
backup->hash);
+   }
}
fputc('\n', fp);
}
-- 
2.6.3


Re: [pacman-dev] [PATCH] Remove notification of system upgrade when only printing URLs

2016-04-01 Thread Andrew Gregory
On 03/29/16 at 08:22pm, Allan McRae wrote:
> Signed-off-by: Allan McRae 
> ---
>  src/pacman/sync.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)

ACK.


Re: [pacman-dev] [PATCH] Report local file URL for -Sp operations if package is in cache

2016-04-01 Thread Andrew Gregory
On 03/29/16 at 10:03pm, Allan McRae wrote:
> When using "pacman -Sp" operation to get URLs of packages to download, it is
> useful to know which packages are already in the file cache and do not need
> downloaded.  Print packages in the cache with a file:// prefix.
> 
> e.g
> $ pacman -Sp glibc
> file:///var/cache/pacman/glibc-2.23-1-x86_64.pkg.tar.xz
> 
> Fixes FS#15868
> 
> Signed-off-by: Allan McRae 
> ---
>  src/pacman/util.c | 26 +-
>  1 file changed, 21 insertions(+), 5 deletions(-)
> 
> diff --git a/src/pacman/util.c b/src/pacman/util.c
> index d924bf3..5a5c0da 100644
> --- a/src/pacman/util.c
> +++ b/src/pacman/util.c
> @@ -1027,11 +1027,27 @@ static char *pkg_get_location(alpm_pkg_t *pkg)
>   char *string = NULL;
>   switch(config->op) {
>   case PM_OP_SYNC:
> - servers = alpm_db_get_servers(alpm_pkg_get_db(pkg));
> - if(servers) {
> - pm_asprintf(&string, "%s/%s", (char 
> *)(servers->data),
> - alpm_pkg_get_filename(pkg));
> - return string;
> + if(alpm_pkg_download_size(pkg) == 0) {
> + /* file is already in the package cache */
> + alpm_list_t *i;
> + const char *pkgfile = 
> alpm_pkg_get_filename(pkg);
> + char path[PATH_MAX];
> + struct stat buf;
> +
> + for(i = 
> alpm_option_get_cachedirs(config->handle); i; i = i->next) {
> + snprintf(path, PATH_MAX, "%s%s", (char 
> *)i->data, pkgfile);
> + if(stat(path, &buf) == 0 && 
> S_ISREG(buf.st_mode)) {
> + pm_asprintf(&string, 
> "file://%s", path);
> + return string;
> + }

We occasionally run into a problem with the fully downloaded package
still having the .part extension in the cache (FS#35789), in which
case this won't actually find the file and just the package filename
will be printed.  If the servers check is moved up out of the else
block, we can fall back to printing the url, which I think is the
correct action in that case.

> + }
> + } else {
> + servers = 
> alpm_db_get_servers(alpm_pkg_get_db(pkg));
> + if(servers) {
> + pm_asprintf(&string, "%s/%s", (char 
> *)(servers->data),
> + 
> alpm_pkg_get_filename(pkg));
> + return string;
> + }
>   }
>   case PM_OP_UPGRADE:
>   return strdup(alpm_pkg_get_filename(pkg));
> -- 
> 2.7.4

-- 
apg


Re: [pacman-dev] [PATCH] Handle provides with -Q

2016-04-01 Thread Allan McRae
On 01/04/16 22:26, Andrew Gregory wrote:
> On 04/01/16 at 02:23pm, Allan McRae wrote:
>> It is useful to be able to use "pacman -Qi" on any dependency, even if that
>> dependency is a provide.  For example, on Arch Linux systems, "sh" is 
>> provided
>> by the "bash" package, and many packages depend on "sh". Querying the what
>> package the "sh" dependency, currently first requires searching for "sh".
> 
> s/Querying the what package/Querying the package that provides/?
> 
>> This patch allows the use of "pacman -Qi" on a provide.
>>
>> Fixes FS#20650.
>>
>> Signed-off-by: Allan McRae 
>> ---
>>  src/pacman/query.c | 30 ++
>>  1 file changed, 30 insertions(+)
>>




> Any reason not to just use alpm_find_satisfier here?
> 

No...   That would make this patch much more simple!

A


Re: [pacman-dev] [PATCH] libmakepkg: extension for additional BUILDENV options

2016-04-01 Thread Andrew Gregory
On 04/01/16 at 03:13pm, Que Quotion wrote:
> Any response is welcome.
> 
> I recently proved this works even with makechrootpkg:
> https://bbs.archlinux.org/viewtopic.php?pid=1616677

It would be very helpful if you would send a properly formatted patch
using `git send-email` and stop breaking the email threads with your
replies.  Right now, it is difficult to review your work or follow the
conversation.

apg


Re: [pacman-dev] [PATCH] Handle provides with -Q

2016-04-01 Thread Andrew Gregory
On 04/01/16 at 02:23pm, Allan McRae wrote:
> It is useful to be able to use "pacman -Qi" on any dependency, even if that
> dependency is a provide.  For example, on Arch Linux systems, "sh" is provided
> by the "bash" package, and many packages depend on "sh". Querying the what
> package the "sh" dependency, currently first requires searching for "sh".

s/Querying the what package/Querying the package that provides/?

> This patch allows the use of "pacman -Qi" on a provide.
> 
> Fixes FS#20650.
> 
> Signed-off-by: Allan McRae 
> ---
>  src/pacman/query.c | 30 ++
>  1 file changed, 30 insertions(+)
> 
> diff --git a/src/pacman/query.c b/src/pacman/query.c
> index 0cc12e6..19e4b3f 100644
> --- a/src/pacman/query.c
> +++ b/src/pacman/query.c
> @@ -80,6 +80,32 @@ static int search_path(char **filename, struct stat 
> *bufptr)
>   return -1;
>  }
>  
> +static alpm_pkg_t *find_provider(alpm_db_t *db_local, const char *name)
> +{
> + alpm_list_t *packages, *i;
> + alpm_pkg_t *pkg = NULL;
> + int found = 0;
> +
> + packages = alpm_db_get_pkgcache(db_local);
> +
> + for(i = packages; i && !found; i = alpm_list_next(i)) {
> + alpm_list_t *provides, *p;
> +
> + pkg = i->data;
> + provides = alpm_pkg_get_provides(pkg);
> +
> + for(p = provides; p; p = alpm_list_next(p)) {
> + alpm_depend_t *d = p->data;
> + if(strcmp(name, d->name) == 0) {
> + found = 1;
> + break;
> + }
> + }
> + }
> +
> + return pkg;
> +}

The package can be returned immediately, so there's no need for the
found/break.  More importantly, because pkg is used to refer to the
package currently being checked, if no provider is found it will just
return the last package in the list:

 pacman -Qi not-a-real-package-name # prints zziplib

> +
>  static void print_query_fileowner(const char *filename, alpm_pkg_t *info)
>  {
>   if(!config->quiet) {
> @@ -462,6 +488,10 @@ int pacman_query(alpm_list_t *targets)
>   alpm_pkg_load(config->handle, strname, 1, 0, &pkg);
>   } else {
>   pkg = alpm_db_get_pkg(db_local, strname);
> + /* if pkg is not found, return the first package that 
> provides it */
> + if(pkg == NULL) {
> + pkg = find_provider(db_local, strname);

Any reason not to just use alpm_find_satisfier here?

> + }
>   }
>  
>   if(pkg == NULL) {
> -- 
> 2.7.4