Re: [pacman-dev] Alternatives system brainstorm
On November 4, 2019 6:06:04 PM GMT+01:00, Daan van Rossum wrote: >* on Wednesday, 2019-10-23 22:05 +1000, Allan McRae > wrote: > >> On 23/10/19 9:35 pm, Daan van Rossum wrote: > >> > [*] IMHO it is one of Arch's strengths to follow upstream as much >as possible and settle on a single current version of e.g. Python. >Older versions can be installed but the '/usr/bin/python' is always >what upstream deems 'current'. >> >> Upstream python specifically states that /usr/bin/python should >always >> point to /usr/bin/python2. So Arch does not follow upstream in that >> regard. Just some idiot decided it was time to point to python3 >about >> 10 years before upstream will... > >Given the alternatives system you, Allan, suggest. What if a user runs > > # pacman -S lua > >, will you print a list of alternatives for a user to choose from? > >Suppose you do that, and present the options > > 1. lua53 > 2. lua52 > 3. lua51 > >and the user choose lua53, now what happens when lua54 is released >upstream? I was happy with pacman giving me the latest upstream and in >peace with it following upstream. > >One concern I would like to share is that introducing alternatives for >managing parallel "versions" of the same tool may impact how KISS >Arch/pacman is going to be. > What exactly forbids people to still name the non pin-versioned variant lua as it today is the case in Arch?
Re: [pacman-dev] Alternatives system brainstorm
On October 20, 2019 2:10:44 AM GMT+02:00, Andrew Gregory wrote: > >So the features I think would be useful are: >1) the ability to select alternatives per-file >2) the ability to select alternatives per-package >3) the ability to group alternatives, potentially spanning multiple > packages, and select them per-group > Just a tiny side note, but it would be awesome to support paths instead of only pure files as providers. This would allow to make the Java system default jvm directory to be managed by pacman as well instead of relying on custom archlinux-java script. Cheers
Re: [pacman-dev] [pacman] [PATCH] makepkg: remove makedepends before installing built package
On 9/12/19 8:30 PM, Erich Eckner wrote: > On Thu, 12 Sep 2019, Levente Polyak wrote: > >> This makes --install imply --rmdeps. I think the minimum would be to >> document this behavior in the CLI help and manpage. > > No, it would not do that: remove_deps bails out early if RMDEPS == 0. > This is also used in the current program flow: remove_deps is called > unconditionally at the end of the cleanup trap. > I see, so its an effect of `makepkg -ir` invocation and not just `-i` as hinted in the commit message :) cheers, Levente signature.asc Description: OpenPGP digital signature
Re: [pacman-dev] [pacman] [PATCH] makepkg: remove makedepends before installing built package
On 9/12/19 3:22 PM, a...@eckner.net wrote:
> From: Erich Eckner
>
> When running `makepkg -i` it may be necessary to first remove make- and
> checkdepends before installing the built package - for example if they
> conflict each other. This is the case for wireguard-arch which
> makedepends and conflicts wireguard-dkms.
>
> Signed-off-by: Erich Eckner
> ---
> scripts/makepkg.sh.in | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in
> index 43484db3..25d97287 100644
> --- a/scripts/makepkg.sh.in
> +++ b/scripts/makepkg.sh.in
> @@ -821,6 +821,9 @@ create_srcpackage() {
> install_package() {
> (( ! INSTALL )) && return 0
>
> + remove_deps || return $?
> + RMDEPS=0
> +
> if (( ! SPLITPKG )); then
> msg "$(gettext "Installing package %s with %s...")" "$pkgname"
> "$PACMAN -U"
> else
>
This makes --install imply --rmdeps. I think the minimum would be to
document this behavior in the CLI help and manpage.
cheers
Levente
signature.asc
Description: OpenPGP digital signature
Re: [pacman-dev] [PATCH] Set "secure" $HOME
On August 12, 2019 6:45:40 PM GMT+02:00, Jonathon Fernyhough wrote: >By default, $HOME is that of the build user. This is usually not a >problem in ephemeral build containers/chroots but can allow some files >to escape into the filesystem where `makepkg` is run outside of a >chroot. > >There can also be instances of generated files (e.g. cache, precompiled >bytecode) being placed into these locations and which are then relied >upon by other parts of the software. > >As a concrete example, Perl6 and nim have a precompilation cache >(though >well-behaved in how it is used). > >`export HOME=/nonexistent` is already used by Debian in their build >tooling and so does not represent a divergence from established >practice. It also allows for badly-behaved build processes to be more >easily spotted and an issue filed upstream where appropriate. > >Signed-off-by: Jonathon Fernyhough >--- > scripts/makepkg.sh.in | 2 ++ > 1 file changed, 2 insertions(+) > >diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in >index 43484db3..04edc38a 100644 >--- a/scripts/makepkg.sh.in >+++ b/scripts/makepkg.sh.in >@@ -40,6 +40,8 @@ export COMMAND_MODE='legacy' > unset CDPATH > # Ensure GREP_OPTIONS doesn't screw with our grep calls > unset GREP_OPTIONS >+# Prevent build-user-specific files "escaping" into the filesystem >+export HOME=/nonexistent > > declare -r makepkg_version='@PACKAGE_VERSION@' > declare -r confdir='@sysconfdir@' Just a side note but Debian has a macro based system that sets vars and options as needed and doesn't require every pkgbuild to handle them case by case. No judgment here, but its not always borken package upstream but this will also have effect on maven, gradle and other generic build systems that will be affected and would be a breaking change that downstream must then incooperate.
Re: [pacman-dev] [PATCH] makepkg: respect $SOURCE_DATE_EPOCH to activate reproducible builds
On 07/28/2017 04:36 AM, Allan McRae wrote: > On 07/07/17 03:26, Eli Schwartz wrote: >> If SOURCE_DATE_EPOCH is set, `touch` all source files before running >> build() to fix the modification times. This works around build systems >> and compilers that embed the file modification times into the file >> contents of release artifacts. >> > > I think this is a reasonable compromise. > > @Levente: are you happy with this approach? > The conditional REPRODUCIBLE touch block should be outside of run_build as former would imply that a build() function is mandatory inside every PKGBUILD to make this work. Its quite common (f.e. for python) to not have a build() function and I believe it should generally work without enforcing to have such function. Therefor I would recommend we move that block between run_build and run_prepare, f.e. a place where this works is line 1696 in commit bcc9c417. A tested/verified adjustment doing the above would be: https://github.com/anthraxx/pacman/commit/520acf93d83774c4b74ec8c19c1ba31fddbdb8da Technically this approach will work, but personally i believe this is a bit too much hidden requirement to make it work. So for clarity I would either recommend we add a section describing this behaviour inside the manpage (as manually defining SOURCE_DATE_EPOCH will be mandatory to make it work) or we use makepkg flags plus config (which will also make it more transparent). I don't have any strong favorites, Eli implementation will do its job, the only difference will be that manually setting SOURCE_DATE_EPOCH is mandatory for the first initial invocation as well. cheers, Levente PS: thanks :P signature.asc Description: OpenPGP digital signature
[pacman-dev] [PATCH 1/5] makepkg: remove build date from .PKGINFO header
From: Allan McRae <al...@archlinux.org>
This information is duplicated (in less friendly format) in the "builddate"
entry and removing it improves reproducible packaging.
Signed-off-by: Allan McRae <al...@archlinux.org>
Signed-off-by: Levente Polyak <anthr...@archlinux.org>
---
scripts/makepkg.sh.in | 1 -
1 file changed, 1 deletion(-)
diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in
index 0218e13b..86abb177 100644
--- a/scripts/makepkg.sh.in
+++ b/scripts/makepkg.sh.in
@@ -635,7 +635,6 @@ write_pkginfo() {
msg2 "$(gettext "Generating %s file...")" ".PKGINFO"
printf "# Generated by makepkg %s\n" "$makepkg_version"
printf "# using %s\n" "$(fakeroot -v)"
- printf "# %s\n" "$(LC_ALL=C date -u)"
write_kv_pair "pkgname" "$pkgname"
if (( SPLITPKG )) || [[ "$pkgbase" != "$pkgname" ]]; then
--
2.12.2
[pacman-dev] [PATCH 3/5] makepkg: extract parts of the write_pkginfo for use elsewhere
Signed-off-by: Allan McRae <al...@archlinux.org>
Signed-off-by: Levente Polyak <anthr...@archlinux.org>
---
scripts/makepkg.sh.in | 42 ++
1 file changed, 26 insertions(+), 16 deletions(-)
diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in
index c302c4ad..7bdf72b9 100644
--- a/scripts/makepkg.sh.in
+++ b/scripts/makepkg.sh.in
@@ -608,6 +608,15 @@ find_libprovides() {
(( ${#libprovides[@]} )) && printf '%s\n' "${libprovides[@]}"
}
+get_packager() {
+ if [[ -n $PACKAGER ]]; then
+ local packager="$PACKAGER"
+ else
+ local packager="Unknown Packager"
+ fi
+ printf "%s\n" "$packager"
+}
+
write_kv_pair() {
local key="$1"
shift
@@ -621,13 +630,22 @@ write_kv_pair() {
done
}
-write_pkginfo() {
- if [[ -n $PACKAGER ]]; then
- local packager="$PACKAGER"
- else
- local packager="Unknown Packager"
+write_kv_pkgname() {
+ write_kv_pair "pkgname" "$pkgname"
+ if (( SPLITPKG )) || [[ "$pkgbase" != "$pkgname" ]]; then
+ write_kv_pair "pkgbase" "$pkgbase"
+ fi
+}
+
+write_kv_pkgver() {
+ local fullver=$(get_full_version)
+ write_kv_pair "pkgver" "$fullver"
+ if [[ "$fullver" != "$basever" ]]; then
+ write_kv_pair "basever" "$basever"
fi
+}
+write_pkginfo() {
local size="$(@DUPATH@ @DUFLAGS@)"
size="$(( ${size%%[^0-9]*} * 1024 ))"
@@ -637,16 +655,8 @@ write_pkginfo() {
printf "# Generated by makepkg %s\n" "$makepkg_version"
printf "# using %s\n" "$(fakeroot -v)"
- write_kv_pair "pkgname" "$pkgname"
- if (( SPLITPKG )) || [[ "$pkgbase" != "$pkgname" ]]; then
- write_kv_pair "pkgbase" "$pkgbase"
- fi
-
- local fullver=$(get_full_version)
- write_kv_pair "pkgver" "$fullver"
- if [[ "$fullver" != "$basever" ]]; then
- write_kv_pair "basever" "$basever"
- fi
+ write_kv_pkgname
+ write_kv_pkgver
# TODO: all fields should have this treatment
local spd="${pkgdesc//+([[:space:]])/ }"
@@ -656,7 +666,7 @@ write_pkginfo() {
write_kv_pair "pkgdesc" "$spd"
write_kv_pair "url" "$url"
write_kv_pair "builddate" "$SOURCE_DATE_EPOCH"
- write_kv_pair "packager" "$packager"
+ write_kv_pair "packager" "$(get_packager)"
write_kv_pair "size" "$size"
write_kv_pair "arch" "$pkgarch"
--
2.12.2
[pacman-dev] [PATCH 5/5] makepkg: unify source file times for improved build reproducibility
Signed-off-by: Levente Polyak <anthr...@archlinux.org>
---
scripts/makepkg.sh.in | 3 +++
1 file changed, 3 insertions(+)
diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in
index bd92c526..83c80fa7 100644
--- a/scripts/makepkg.sh.in
+++ b/scripts/makepkg.sh.in
@@ -1731,6 +1731,9 @@ if (( !REPKG )); then
if (( PREPAREFUNC )); then
run_prepare
fi
+
+ # unify source times before building for reproducibility
+ find "$srcdir" -exec touch -h -d "@${SOURCE_DATE_EPOCH}" {} +
fi
if (( PKGVERFUNC )); then
--
2.12.2
[pacman-dev] [PATCH 4/5] makepkg: add more information to .BUILDINFO
The .BUILDINFO file should retain all the information needed to reproducibly
build a package. Add some extra information to the file and also provide a
version number to keep track of future changes.
Signed-off-by: Allan McRae <al...@archlinux.org>
Signed-off-by: Levente Polyak <anthr...@archlinux.org>
---
scripts/makepkg.sh.in | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in
index 7bdf72b9..bd92c526 100644
--- a/scripts/makepkg.sh.in
+++ b/scripts/makepkg.sh.in
@@ -688,13 +688,17 @@ write_pkginfo() {
write_buildinfo() {
msg2 "$(gettext "Generating %s file...")" ".BUILDINFO"
- write_kv_pair "builddir" "${BUILDDIR}"
+ write_kv_pair "format" "1"
+ write_kv_pkgname
+ write_kv_pkgver
local sum="$(sha256sum "${BUILDFILE}")"
sum=${sum%% *}
-
write_kv_pair "pkgbuild_sha256sum" $sum
+ write_kv_pair "packager" "$(get_packager)"
+ write_kv_pair "builddate" "${SOURCE_DATE_EPOCH}"
+ write_kv_pair "builddir" "${BUILDDIR}"
write_kv_pair "buildenv" "${BUILDENV[@]}"
write_kv_pair "options" "${OPTIONS[@]}"
--
2.12.2
[pacman-dev] [PATCH 2/5] makepkg: introduce SOURCE_DATE_EPOCH
From: Allan McRae <al...@archlinux.org>
This patch introduces the SOURCE_DATE_EPOCH environmental variable. All files
in a package are adjusted to have their modification dates set to the value
of SOURCE_DATE_EPOCH, which defaults to "date +%s".
Setting this variable allows a package that is built twice in the same
environment to be (potentially) reproducible in that the checksum of the
generated package file will be the same.
Signed-off-by: Levente Polyak <anthr...@archlinux.org>
---
scripts/makepkg.sh.in | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in
index 86abb177..c302c4ad 100644
--- a/scripts/makepkg.sh.in
+++ b/scripts/makepkg.sh.in
@@ -87,6 +87,8 @@ SPLITPKG=0
SOURCEONLY=0
VERIFYSOURCE=0
+export SOURCE_DATE_EPOCH=${SOURCE_DATE_EPOCH:-$(date +%s)}
+
PACMAN_OPTS=()
shopt -s extglob
@@ -620,7 +622,6 @@ write_kv_pair() {
}
write_pkginfo() {
- local builddate=$(date -u "+%s")
if [[ -n $PACKAGER ]]; then
local packager="$PACKAGER"
else
@@ -654,7 +655,7 @@ write_pkginfo() {
write_kv_pair "pkgdesc" "$spd"
write_kv_pair "url" "$url"
- write_kv_pair "builddate" "$builddate"
+ write_kv_pair "builddate" "$SOURCE_DATE_EPOCH"
write_kv_pair "packager" "$packager"
write_kv_pair "size" "$size"
write_kv_pair "arch" "$pkgarch"
@@ -738,10 +739,14 @@ create_package() {
[[ -f $pkg_file ]] && rm -f "$pkg_file"
[[ -f $pkg_file.sig ]] && rm -f "$pkg_file.sig"
+ # ensure all elements of the package have the same mtime
+ find . -exec touch -h -d @$SOURCE_DATE_EPOCH {} +
+
msg2 "$(gettext "Generating .MTREE file...")"
- list_package_files | LANG=C bsdtar -cnzf .MTREE --format=mtree \
+ list_package_files | LANG=C bsdtar -cnf - --format=mtree \
--options='!all,use-set,type,uid,gid,mode,time,size,md5,sha256,link' \
- --null --files-from - --exclude .MTREE
+ --null --files-from - --exclude .MTREE | gzip -c -f -n > .MTREE
+ touch -d @$SOURCE_DATE_EPOCH .MTREE
msg2 "$(gettext "Compressing package...")"
# TODO: Maybe this can be set globally for robustness
--
2.12.2
Re: [pacman-dev] [PATCH 3/4] makepkg: unify source file times for improved build reproducibility
On 05/02/2017 10:09 PM, Andrew Gregory wrote: > On 05/02/17 at 09:30pm, Levente Polyak wrote: >> On 04/21/2017 07:08 AM, Allan McRae wrote: >>> On 21/04/17 13:36, Eli Schwartz wrote: >>>> On 04/20/2017 11:01 PM, Allan McRae wrote: >>>>> I am probably moving this to after source extraction/prepare() running, >>>>> so it can be skipped with --noextract. >>>> >>>> But --noextract depends on your having at some point previously run >>>> --nobuild, in order to pull updated sources, re-patch any patches, etc. >>>> which I still don't want to do manually outside of makepkg... I don't >>>> see why makepkg should start breaking things for me. >>>> >>>> How about instead we guard it with >>>> BUILDENV+=(fix_everyone_elses_SOURCE_DATE_EPOCH_stuff) >>>> >>>> Or better yet, just file bugs against whatever upstream build >>>> system/programming language/source code is determined to sneakily embed >>>> source code modification times into generated files, and call it a day? >>>> >>> >>> Adding list back - any further off-list replies will be completely ignored. >>> >>> The reproducible builds people will provide details, but it appears >>> pyo/pyc do this. >>> >>> A >> >> Unfortunately it won't be possible to fully avoid such uniform >> modifications times of input files to get reproducible builds. The most >> known dominator there is indeed python and its way to determine the >> produced artifacts state compared to the source code. Make does use the >> same information by setting the modification time of the produced >> artifacts to compare them. >> I agree make is in that detail a nicer way as that info in contained >> outside of the content of the produced artifacts itself, however there >> are external design decisions that we need to accept that they exist and >> won't change. >> >> So as both use cases (reproducible and incremental builds) seem to be >> valid and wanted features, let's be cooperative and see how we can make >> both separately work to make all of us happy. :) >> >> As I don't really see how both can work at the same time: one way that >> could do its job is an option like --incremental that would not do any >> timestamp unification. This could be used in the case of a incremental >> build of a VCS package in a non cleaned environment. I think that is not >> too much of a hassle to do in case someone wants to build an VCS package >> incrementally with previous object files? > > Why is setting the modification timestamp necessary? makepkg should > be preserving the modification timestamps of files when it extracts > them from archives. So two builds using the same source tarballs > should already have files with the same timestamps. When is this not > sufficient? > > apg > Reproducibility is not something that should be exclusive to archives providing such anyway. There is an increasing interest in builds from repository checkout. On top, prepare() modifies such so those should be adjusted too before the build starts. cheers, Levente
Re: [pacman-dev] [PATCH 3/4] makepkg: unify source file times for improved build reproducibility
On 04/21/2017 07:08 AM, Allan McRae wrote: > On 21/04/17 13:36, Eli Schwartz wrote: >> On 04/20/2017 11:01 PM, Allan McRae wrote: >>> I am probably moving this to after source extraction/prepare() running, >>> so it can be skipped with --noextract. >> >> But --noextract depends on your having at some point previously run >> --nobuild, in order to pull updated sources, re-patch any patches, etc. >> which I still don't want to do manually outside of makepkg... I don't >> see why makepkg should start breaking things for me. >> >> How about instead we guard it with >> BUILDENV+=(fix_everyone_elses_SOURCE_DATE_EPOCH_stuff) >> >> Or better yet, just file bugs against whatever upstream build >> system/programming language/source code is determined to sneakily embed >> source code modification times into generated files, and call it a day? >> > > Adding list back - any further off-list replies will be completely ignored. > > The reproducible builds people will provide details, but it appears > pyo/pyc do this. > > A > Unfortunately it won't be possible to fully avoid such uniform modifications times of input files to get reproducible builds. The most known dominator there is indeed python and its way to determine the produced artifacts state compared to the source code. Make does use the same information by setting the modification time of the produced artifacts to compare them. I agree make is in that detail a nicer way as that info in contained outside of the content of the produced artifacts itself, however there are external design decisions that we need to accept that they exist and won't change. So as both use cases (reproducible and incremental builds) seem to be valid and wanted features, let's be cooperative and see how we can make both separately work to make all of us happy. :) As I don't really see how both can work at the same time: one way that could do its job is an option like --incremental that would not do any timestamp unification. This could be used in the case of a incremental build of a VCS package in a non cleaned environment. I think that is not too much of a hassle to do in case someone wants to build an VCS package incrementally with previous object files? cheers, Levente
Re: [pacman-dev] [PATCH] makepkg: introduce SOURCE_DATE_EPOCH
On 04/17/2017 08:42 PM, Andrew Gregory wrote:
> I have no problem with making makepkg's own output more controllable
> (e.g. allowing builddate to be set rather than using the current
> time). But, a lot of the time, reproducing an identical package is
> going to require a very precise environment, especially for compiled
> software. The environmental factors that influence the built software
> vary from project to project and can get their values from a variety
> of locations. I think that trying to manage all of that from makepkg
> would be a mistake if it would even be possible. Some things, like
> building in a chroot for software that embeds the build directory,
> would almost certainly be easier from a script that wraps makepkg.
> I would prefer to see effort be put toward such a script rather than
> have it go into makepkg only to have to be moved to a separate script
> later.
>
> apg
>
I fully agree with your points... actually exactly that is the plan and
the reason the .BUILDINFO file exists -- to be able to recreate the very
precise environment that was used to build a package. This is of cause
needed, as you mentioned, for things like some binary software (gcc
version)... but we actually include the .BUILDINFO file into the package
itself. This has IMO a lot of advantages but that already declares the
requirement to have an exact identical environment to be reproducible.
The current set of adjustments are needed for makepkg itself. I'm sure
nobody intends to go lot further and include environment recreation
things or explicit software dependent stuff (like PERL_BUILD_DATE).
makechrootpkg and things like that are project (like Arch) specific.
Surely there will be the need of a wrapper around it to recreate an
identical environment from the .BUILDINFO file to be able to reproduce a
package beyond invoking it twice (something like makerepropkg).
On top of that, there will always be some need to add some things to
PKGBUILD files that are software dependent. An example would be to
define PERL_BUILD_DATE="${SOURCE_DATE_EPOCH}" and i agree that something
like PERL_BUILD_DATE is not to be included in makepkg itself.
I hope i could settle some of your concerns :)
cheers,
Levente
signature.asc
Description: OpenPGP digital signature
Re: [pacman-dev] [PATCH] Remove contrib
On 10/10/2016 03:20 PM, Allan McRae wrote: > On 10/10/16 23:09, Levente Polyak wrote: >> On 10/01/2016 09:38 AM, Allan McRae wrote: >>> delete mode 100644 contrib/bash_completion.in >>> delete mode 100644 contrib/zsh_completion.in >>> >> >> Moving out all the contrib stuff make sense to focus on the main >> project, however in my very personal opinion it would still be useful to >> maintain the common zsh and bash completions within the repository itself. >> They are very closely tied to the project as they provide completion for >> the core itself without "just" adding additional stuff. >> I believe any downstream who wants to use/package pacman would also like >> to distribute completion for it in the very same package? > > > https://lists.archlinux.org/pipermail/pacman-dev/2016-October/021566.html > Oh.. I'm very sorry. I read every single mail/patch that comes in on this list but somehow I forgot or missed that specific one. My bad, I feel deeply guilty to have created noise. cheers, Levente PS: thx @ eworm for the additional links. signature.asc Description: OpenPGP digital signature
Re: [pacman-dev] [PATCH] Remove contrib
On 10/01/2016 09:38 AM, Allan McRae wrote: > delete mode 100644 contrib/bash_completion.in > delete mode 100644 contrib/zsh_completion.in > Moving out all the contrib stuff make sense to focus on the main project, however in my very personal opinion it would still be useful to maintain the common zsh and bash completions within the repository itself. They are very closely tied to the project as they provide completion for the core itself without "just" adding additional stuff. I believe any downstream who wants to use/package pacman would also like to distribute completion for it in the very same package? My 2 cents, Levente signature.asc Description: OpenPGP digital signature
[pacman-dev] [PATCH] fix --printsrcinfo unify arch and non-arch specific variables
This fixes the issue with --printsrcinfo that all arch specific variants
of a variable get merged into their non arch specific variant.
The .SRCINFO file ends up having $depends containing $depends_x86_64
and omitting the latter.
---
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 7b2ce51..82c9367 100644
--- a/scripts/makepkg.sh.in
+++ b/scripts/makepkg.sh.in
@@ -1476,7 +1476,7 @@ pkgbase=${pkgbase:-${pkgname[0]}}
# check the PKGBUILD for some basic requirements
lint_pkgbuild || exit 1
-if (( !SOURCEONLY )); then
+if (( !SOURCEONLY && !PRINTSRCINFO )); then
merge_arch_attrs
fi
--
2.10.0
Re: [pacman-dev] [PATCH] makepkg: optionally attach minimal debuginfo to binaries
==> 0x00: Summary
I think this looks kind of useful, minidebug enabled binaries could help
debugging and understanding certain type of crashes without the need of
rebuilding and install full debug symbols.
Overall the size increase seems to be round about 3% per binary and
slightly higher per tarball (mainly depending on the amount of binaries
it contains).
The mplayer testcase had some strange effects that may need some deeper
investigation before considering to make this a default option.
Binaries with minidebug option and a corresponding .gnu_debugdata
section do not seem to affect reproducibility.
==> 0x01: Patch adjustments
There are some small adjustments required to this patch, I would
recommend the following changes:
1) scripts/libmakepkg/tidy/strip.sh.in
The new minidebug option is required to be added to the
packaging_options array to make it available in the PKGBUILD's options
array:
packaging_options+=('strip' 'debug' 'minidebug')
2) etc/makepkg.conf.in
The new option should to be added to the OPTIONS array in the
configuration file. Its default value should also to be added in the
comment above that option, including a description text between both.
==> 0x02: Backtrace example
Following backtrace example was taken from zsh with default and
minidebug options.
(gdb) bt
#0 0x771a0150 in __read_nocancel () from /usr/lib/libc.so.6
#1 0x0041c3a7 in bin_read ()
#2 0x0041d926 in execbuiltin ()
#3 0x0042b59a in ?? ()
#4 0x0042bf4e in ?? ()
#5 0x0042c311 in ?? ()
#6 0x0042db6c in execlist ()
#7 0x0045168b in execif ()
#8 0x0042a581 in ?? ()
#9 0x0042bf4e in ?? ()
#10 0x0042c311 in ?? ()
(gdb) bt
#0 0x771a0150 in __read_nocancel () from /usr/lib/libc.so.6
#1 0x0041c3a7 in bin_read ()
#2 0x0041d926 in execbuiltin ()
#3 0x0042b59a in execcmd ()
#4 0x0042bf4e in execpline2 ()
#5 0x0042c311 in execpline ()
#6 0x0042db6c in execlist ()
#7 0x0045168b in execif ()
#8 0x0042a581 in execcmd ()
#9 0x0042bf4e in execpline2 ()
#10 0x0042c311 in execpline ()
==> 0x03: File size influence
The file size list below roughly matches the expected size increase and
ends up with around 3% bigger binaries. The percentage size increase per
package is obviously higher compared to a single binaries because the
debug sections are already compress.
1) package -> util-linux8.70%
1.7M 1738096
1.9M 1889416
binary -> hexdump3.71%
47K 47968
49K 49752
binary -> lsblk 3.26%
76K 77296
78K 79816
binary -> fdisk 2.74%
108K 109640
110K 112640
2) package -> bash 1.14%
1.3M 1271836
1.3M 1286376
binary -> bash 1.86%
773K 791320
788K 806080
3) package -> ncmpcpp 13.75%
610K 624140
694K 710592
binary -> ncmpcpp3.41%
2.4M 2447816
2.5M 2531440
4) package -> zsh 2.81%
1.8M 1883400
1.9M 1936428
binary -> zsh1.47%
758K 775592
769K 786968
5) package -> wireshark-gtk 4.49%
641K 655976
670K 685452
binary -> wireshark-gtk 1.48%
2.0M 2068552
2.1M 2099256
6) package -> wireshark-qt 3.25%
2.9M 2983856
3.0M 3080928
binary -> wireshark 1.52%
6.1M 6375200
6.2M 6472216
==> 0x04: Strange observations
Besides the package firefox, where the minidebug option had no effect at
all, there was some strange effect while testing the mplayer package.
The mplayer and memcoder binaries significantly increase in size while
having missing .gnu_debugdata sections. As there may be more cases
affected by this issue, it should maybe be investigated before
considering to enable this by default.
1) mplayer 26.95%
17M 1704
21M 22005264
2) mencoder25.96%
16M 16105880
20M 20286256
cheers,
Levente
signature.asc
Description: OpenPGP digital signature
[pacman-dev] [PATCH] ensure matching database and package version
While loading each package ensure that the internal version matches the
expected database version to avoid the possibility to circumvent the
version check.
This issue can be used by an attacker to trick the software into
installing an older version. The behavior can be exploited by a
man-in-the-middle attack through specially crafted database tarball
containing a higher version, yet actually delivering an older and
vulnerable version, which was previously shipped.
Signed-off-by: Levente Polyak anthr...@archlinux.org
Signed-off-by: Remi Gacogne rgaco...@archlinux.org
---
lib/libalpm/sync.c | 16
1 file changed, 16 insertions(+)
diff --git a/lib/libalpm/sync.c b/lib/libalpm/sync.c
index 888ae15..8504e02 100644
--- a/lib/libalpm/sync.c
+++ b/lib/libalpm/sync.c
@@ -1212,6 +1212,7 @@ static int load_packages(alpm_handle_t *handle,
alpm_list_t **data,
EVENT(handle, event);
for(i = handle-trans-add; i; i = i-next, current++) {
+ int error = 0;
alpm_pkg_t *spkg = i-data;
char *filepath;
int percent = (int)(((double)current_bytes / total_bytes) *
100);
@@ -1232,6 +1233,21 @@ static int load_packages(alpm_handle_t *handle,
alpm_list_t **data,
spkg-name);
alpm_pkg_t *pkgfile =_alpm_pkg_load_internal(handle, filepath,
1);
if(!pkgfile) {
+ _alpm_log(handle, ALPM_LOG_DEBUG, failed to load
pkgfile internal\n);
+ error = 1;
+ } else {
+ if(strcmp(spkg-name, pkgfile-name) != 0) {
+ _alpm_log(handle, ALPM_LOG_DEBUG, internal
package name missmatch, expected: '%s', actual: '%s'\n,
+ spkg-name, pkgfile-name);
+ error = 1;
+ }
+ if(alpm_pkg_vercmp(spkg-version, pkgfile-version) !=
0) {
+ _alpm_log(handle, ALPM_LOG_DEBUG, internal
package version missmatch, expected: '%s', actual: '%s'\n,
+ spkg-version,
pkgfile-version);
+ error = 1;
+ }
+ }
+ if(error != 0) {
errors++;
*data = alpm_list_add(*data, strdup(spkg-filename));
free(filepath);
--
2.4.6
[pacman-dev] [PATCH v2] ensure matching database and package version
While loading each package ensure that the internal version matches the
expected database version to avoid the possibility to circumvent the
version check.
This issue can be used by an attacker to trick the software into
installing an older version. The behavior can be exploited by a
man-in-the-middle attack through specially crafted database tarball
containing a higher version, yet actually delivering an older and
vulnerable version, which was previously shipped.
Signed-off-by: Levente Polyak anthr...@archlinux.org
Signed-off-by: Remi Gacogne rgaco...@archlinux.org
---
lib/libalpm/sync.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/lib/libalpm/sync.c b/lib/libalpm/sync.c
index 888ae15..e843b07 100644
--- a/lib/libalpm/sync.c
+++ b/lib/libalpm/sync.c
@@ -1212,6 +1212,7 @@ static int load_packages(alpm_handle_t *handle,
alpm_list_t **data,
EVENT(handle, event);
for(i = handle-trans-add; i; i = i-next, current++) {
+ int error = 0;
alpm_pkg_t *spkg = i-data;
char *filepath;
int percent = (int)(((double)current_bytes / total_bytes) *
100);
@@ -1232,6 +1233,23 @@ static int load_packages(alpm_handle_t *handle,
alpm_list_t **data,
spkg-name);
alpm_pkg_t *pkgfile =_alpm_pkg_load_internal(handle, filepath,
1);
if(!pkgfile) {
+ _alpm_log(handle, ALPM_LOG_DEBUG, failed to load
pkgfile internal\n);
+ error = 1;
+ } else {
+ if(strcmp(spkg-name, pkgfile-name) != 0) {
+ _alpm_log(handle, ALPM_LOG_DEBUG,
+ internal package name
mismatch, expected: '%s', actual: '%s'\n,
+ spkg-name, pkgfile-name);
+ error = 1;
+ }
+ if(strcmp(spkg-version, pkgfile-version) != 0) {
+ _alpm_log(handle, ALPM_LOG_DEBUG,
+ internal package version
mismatch, expected: '%s', actual: '%s'\n,
+ spkg-version,
pkgfile-version);
+ error = 1;
+ }
+ }
+ if(error != 0) {
errors++;
*data = alpm_list_add(*data, strdup(spkg-filename));
free(filepath);
--
2.4.6
