zaufi / paludis-hooks Goto Github PK

View Code? Open in Web Editor NEW

11.0 5.0 4.0 185 KB

This repository has moved to other hosting

Home Page: https://gitlab.exherbo.org/living-in-exherbo/paludis-hooks

License: Other

CMake 18.79% Shell 47.52% XSLT 30.57% Python 3.11%

paludis gentoo

paludis-hooks's Introduction

What is this?

Here is a set of my hooks (plugins) for paludis I wrote and use few years already.

Briefly this package consists of:

Autopatch hook -- an easy way to apply patches (here is my set of patches)
Filesystem Manager hook -- a better way to avoid installation of some files than INSTALL_MASK + some other interesting usage practices w/o direct analogues in the portage
A smart way to build packages in a RAM disk with workdir-tmpfs hook
A bunch of helper functions usable in a daily work w/ Paludis
A hook to organize compiler/linker options into various sets and apply to packages

Configuration details

Autopatch

The only one option in /etc/paludis/hooks/configs/auto-patch.conf is location of patches tree (default: /var/paludis/autopatches). .patch files should be placed under this directory with such hierarchy:

autopatches
├── hook_name1
│   └── cate-gory
│       └── package_name
│           └── fix_some_crap.patch
├── hook_name2
│   ├── cate-gory
│   │   └── package-ver
│   │       └── version-specific.patch
│   ├── cate-gory
│   │   └── package-ver_r1
│   │       └── some-cve-hotfix.patch
│   └── cate-gory
│       └── any_spec:SLOT
│           └── slot-specific.patch

and so on.

Supported hooks for autopatch are: ebuild_install_pre, install_all_post, ebuild_configure_post, ebuild_compile_post, ebuild_configure_pre, ebuild_compile_pre, ebuild_unpack_post.

This hook is also controlled by this variables in paludis' bashrc:

PALUDIS_AUTOPATCH_HOOK_DO_NOTHING="yes" disables all actions of this hook.
PALUDIS_AUTOPATCH_HOOK_NO_WARNING="yes" mutes annoying warnings about altered packages.

Filesystem Manager

/etc/paludis/hooks/configs/filesystem-manager.conf is a set of rules in XML which format is explained by the comments in it or in more details here.

This hook is also controlled by this variables in paludis' bashrc:

PALUDIS_HOOK_DEBUG="yes" dumps enviroment variables to file /tmp/paludis-fsm-hook-env.log.
PALUDIS_FILESYSTEM_HOOK_DO_NOTHING="yes" disables all actions of this hook.
PALUDIS_FILESYSTEM_HOOK_NO_WARNING="yes" mutes annoying warnings about altered packages.

package.env

For using this hook add to Paludis' bashrc line:

[ -e /usr/libexec/paludis-hooks/setup_pkg_env.bash ] && source /usr/libexec/paludis-hooks/setup_pkg_env.bash

and to /etc/paludis/package_env.conf:

category/some_package some_env another_env ...

So, at build time of category/some_package, all lines from the mentioned env files (/etc/paludis/env.conf.d/some_env.conf and /etc/paludis/env.conf.d/another_env.conf) will be sourced at init ebuild phase. Hence, changing compiler/linker flags or setting another compiler would affect the build process only for given package.

Workdir-tmpfs

Most important boolean parameter in /etc/paludis/hooks/configs/workdir-tmpfs.conf is IN_MEMORY_BUILD_ENABLED.

paludis-hooks's People

Contributors

Stargazers

Watchers

Forkers

hasufell peperunas albel727 hardentoo

paludis-hooks's Issues

/dev/shm is mounted with noexec

Many of ebuilds fails with workdir-tmpfs because they trying to run something as ./build.sh or checking [[ -x ./configure ]] when /dev/shm is mounted with noexec (default option in most distros).
I agree with this recommended option, so question is: how to have advantages of this beatiful hook without reducing security?

package_env not applied in world update

I've created a env configuration to compile in another directory and applied it to app-office/libreoffice.
It seems that paludis checks for it in the first --pretend phase but discards it when it actually starts to compile the package.

Log:

These are the actions I will take, in order:

u   app-office/libreoffice:0::gentoo 5.0.2.2 to ::installed replacing 5.0.1.2 [cycle 1]
    (-aqua) -bluetooth* branding -coinmp -collada cups dbus -debug eds (-firebird) -gltf gnome gstreamer gtk -gtk3 -java -jemalloc -kde -mysql -odk -postgres (-telepathy) -vlc (-test) LIBREOFFICE_EXTENSIONS: -nlpsolver -scripting-beanshell -scripting-javascript -wiki-publisher PYTHON_SINGLE_TARGET: python2_7 -python3_3 -python3_4 PYTHON_TARGETS: python2_7 -python3_3 python3_4 build_options: symbols=strip -dwarf_compress -optional_tests -trace work=remove
    Reasons: target (world::environment)
    In dependency cycle with existing packages: app-office/libreoffice:0, media-sound/pulseaudio:0, dev-libs/folks:0, sys-apps/sandbox:0, gnome-base/gnome-control-center:2, gnome-base/gnome-shell:0, net-misc/networkmanager:0, gnome-extra/nm-applet:0, media-tv/kodi:0
[snip...]

Total: 12 reinstalls, 8 upgrades, 32 uninstalls

Executing pretend actions: 1 of 20 pretend app-office/libreoffice-5.0.2.2:0::gentoo�

Here's the first correct check, where paludis correctly loads the no_ram_compiling.conf env mod:

libreoffice-5.0.2.2> Loaded custom configuration: enable_ccache
libreoffice-5.0.2.2> Loaded custom configuration: no_ram_compiling
libreoffice-5.0.2.2>  Checking for at least 512 MiB RAM ...
libreoffice-5.0.2.2>  �Checking for at least 6 GiB disk space at "/var/tmp/notmpfs" ...
[snip...]

Further output:

Output from installing app-office/libreoffice-5.0.2.2:0::gentoo to ::installed replacing 5.0.1.2:0::installed:

Running ebuild phase killold as root:root...
�Starting builtin_killold
 Done builtin_killold
 Completed ebuild phase killold
 Running ebuild phases init saveenv as paludisbuild:paludisbuild...
 Starting builtin_init

Output from installing app-office/libreoffice-5.0.2.2:0::gentoo to ::installed replacing 5.0.1.2:0::installed:

Done builtin_init
Starting builtin_saveenv
Done builtin_saveenv
Completed ebuild phases init saveenv
Running ebuild phases loadenv setup saveenv as root:root...
Starting builtin_loadenv
Done builtin_loadenv
Starting pkg_setup

Here's the actual check before compiling it:

Checking for at least 512 MiB RAM ...
Checking for at least 6 GiB disk space at "/var/tmp/paludis/app-office-libreoffice-5.0.2.2/temp/" ...
�There is NOT at least 6 GiB disk space at "/var/tmp/paludis/app-office-libreoffice-5.0.2.2/temp/"
�Space constraints set in the ebuild were not met!
�The build will most probably fail, you should enhance the space
�as per failed tests.

Final output:

Done pkg_setup
Starting builtin_saveenv
Done builtin_saveenv
Completed ebuild phases loadenv setup saveenv
Running ebuild phases loadenv unpack saveenv as paludisbuild:paludisbuild...
Starting builtin_loadenv
Done builtin_loadenv
Starting src_unpack
Done src_unpack
Starting builtin_saveenv
Done builtin_saveenv
Completed ebuild phases loadenv unpack saveenv
Running ebuild phases loadenv prepare saveenv as paludisbuild:paludisbuild...
Starting builtin_loadenv
Done builtin_loadenv
Starting src_prepare
Applying libreoffice-4.4-system-pyuno.patch ...
Running eautoreconf in '/var/tmp/paludis/app-office-libreoffice-5.0.2.2/work/libreoffice-5.0.2.2' ...
Running aclocal -I m4 ...
Running autoconf -I m4 --force ...
Running autoheader -I m4 ...
Running elibtoolize in: libreoffice-5.0.2.2/
Done src_prepare
Starting builtin_saveenv
Done builtin_saveenv
Completed ebuild phases loadenv prepare saveenv
Running ebuild phases loadenv configure saveenv as paludisbuild:paludisbuild...
Starting builtin_loadenv
Done builtin_loadenv
Starting src_configure
Running ebuild phases loadenv tidyup as root:root...
Starting builtin_loadenv
Done builtin_loadenv
Starting builtin_tidyup
Done builtin_tidyup
Completed ebuild phases loadenv tidyup


Checking whether the GNU info directory needs updating...
No updates needed
Failed install to / for app-office/libreoffice-5.0.2.2:0::gentoo replacing 5.0.1.2:0::installed

print-ebuild-path installation seems broken

 * Installing hooks into paludis configuration dir...
find: '/var/tmp/paludis/app-paludis-paludis-hooks-scm/image//usr/libexec/cave/commands/print-ebuild-path':
 No such file or directory

paludis.scm will not build with clang

GCC-5.3 has a bug which breaks cave fix-linkage. Building with clang works around the bug. paludis::gentoo build with clang but paludis.scm in this overlay does not.

Misleading env protection setting

My /etc/env.d/90cave overwritten and all chages lost.

You set CONFIG_PROTECT='/etc/env.d/90cave' but /etc.d already in `CONFIG_PROTECT_MASK' by Gentoo profile that makes it useless as any directory which is listed in CONFIG_PROTECT (and any subdirectories thereof), except for any which are listed in CONFIG_PROTECT_MASK (and subdirectories) are automatically 'protected' by Portage when copying an image from DESTDIR to ROOT -- https://devmanual.gentoo.org/general-concepts/config-protect/index.html (it seems correct for Paludis also).

Am I wrong? How do you protect env options from automatic merge?

cave resolve --ask

Just wanted your opinion on this bash function/alias. I think it is a common "wtf" moment for people who switch to paludis when they don't find the --ask switch.

Specifying a resume file and resuming manually are two commands (even if you have aliases for both) while with --ask it is just one step and probably more intuitive for most users.

I currently see two problems with this script:

it does not check if it overwrites a previous resume file and I'm not sure it even should
it doesn't allow to pass parameters to cave resume

setup_pkg_env.bash might print to standard output

https://github.com/zaufi/paludis-hooks/blob/master/package.env/setup_pkg_env.bash.in#L57

I don't know about the possible side effects of this, but the bashrc docs say:

This file must not be used to output anything to standard output.

improve spec matching

The problem I am facing right now is that I need special flags for qtgui:5, but not for qtgui:4. Sure, we could add SLOT matching, but then we want ~ matching too and so on.

https://github.com/zaufi/paludis-hooks/blob/master/package.env/setup_pkg_env.bash.in#L52

This is currently a very limited way to match... I wonder if there shouldn't be a way to use the full spec-matching power of paludis, similar to what is done for keywords.conf and so on. I asked ciaran on IRC, but I got not much useful answers (as usual).

There is cave match, which does something similar, but its very slow and I am not sure if it's supposed to be used like that.

FSH: <include> rules

that would be neat to have an ability to <include> common rules into various contexts...

Autopatch hungs at patches with bad filenames

Use case:
One accidentaly put autopatch with incorrect filename and trying to resolve -x ebuild which will use this patch.

Result:
Paludis hangs on this line (with quiet = true in output.conf):

*** Applying /usr/portage/local/autopatches/ebuild_unpack_post/app-vim/locateopen/mlocate-support.patch ...

With quiet = false additionaly (but it's no matter):

File to patch: tar jxf /usr/portage/distfiles/locateopen-1.3.tar.bz2 --no-same-owner

We can proceed with pressing enter 2-3 times and die with error.

After this we see:

can't find file to patch at input line 3
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
|--- locateopen.vim     2016-01-30 22:41:27.567804708 +0300
|+++ locateopen.vim     2016-02-01 03:11:37.815735679 +0300
File to patch: Skip this patch? [y] Skipping patch.

I.e. patch is waiting for filename but non-interactive cave provides nothing.

Expected behavior:
Error message when file for patching not found.
Dunno that you can fix this because it is patch ignores -s option in case of non-existing files. But maybe you can come up with workaround (eg parsing patch output or setting timeout).