Paludis support thread (current v. 0.14.3) - Part 1

[zxy]

Is there a variable in which the name of the temporary folder is stored? Something like PALUDIS_TMP_DIR ?

[Lloeki]

paludis --uninstall sys-apps/portage will work

because I'm just crazy, and because it prevents me from doing 'emerge foo', I did that.
question is, equery d portage yields an impressive amount of packages.

Code: Select all

 # equery d sys-app/portage
[ Searching for packages depending on portage... ]
sys-libs/db-4.2.52_p4-r2
app-portage/gentoolkit-0.2.2
dev-util/ccache-2.3
dev-util/subversion-1.3.2-r3
app-admin/logrotate-3.7.1-r2
app-admin/syslog-ng-1.6.9
sys-process/vixie-cron-4.1-r9
dev-java/blackdown-jdk-1.4.2.03-r12
dev-java/sun-jdk-1.5.0.08
media-sound/aumix-2.8-r4
sys-apps/shadow-4.0.18.1
sys-apps/attr-2.4.28-r1
sys-apps/baselayout-1.12.6
net-misc/rsync-2.6.8-r2

of course, I believe none of theme really depend on portage. I bet that's just to have portage emerged first. is there something to do for those packages not to pull portage in when I do, e.g 'paludis -ip rsync' ? I mean, something less hacky than a fake sys-apps/portage ebuild. ideally I guess they should depend on a virtual/portage, and paludis providing that virtual ...

[truc]

zxy, paludis --info:

PORTAGE_TMPDIR ?

[ciaranm]

of course, I believe none of theme really depend on portage. I bet that's just to have portage emerged first. is there something to do for those packages not to pull portage in when I do, e.g 'paludis -ip rsync' ? I mean, something less hacky than a fake sys-apps/portage ebuild. ideally I guess they should depend on a virtual/portage, and paludis providing that virtual ...

A few of them (gentoolkit) are genuine deps. Most of them are depping upon Portage because they require some feature that wasn't in certain Portage versions.

spb was going to go through the tree and turn them into || or virtual deps at some point. You might want to pester him about that.

[Lepaca Kliffoth]

No time, so I just re-emerged it. No it works. Peace.

[zxy]

Mounting /var/tmp/paludis on tmpfs

/usr/share/paludis/hooks/install_pre/mount-tmp.bash

Code: Select all

#!/bin/bash

source ${PALUDIS_EBUILD_DIR}/echo_functions.bash

PALUDIS_TMP_DIR="/var/tmp/paludis"
N="0"
MOUNTED="$(cat /proc/mounts | grep tmpfs | grep -c ${PALUDIS_TMP_DIR} )"

if [ $MOUNTED = $N ] 
then
        einfo "Mounting ${PALUDIS_TMP_DIR} to tmpfs..."
        mount -t tmpfs tmpfs -o size=1500M,nr_inodes=1M ${PALUDIS_TMP_DIR}
else
        einfo "${PALUDIS_TMP_DIR} already mounted on tmpfs..."
fi
true

/usr/share/paludis/hooks/install_post/umount-tmp.bash

Code: Select all

#!/bin/bash

source ${PALUDIS_EBUILD_DIR}/echo_functions.bash

PALUDIS_TMP_DIR="/var/tmp/paludis"
N="0"
MOUNTED="$(cat /proc/mounts | grep tmpfs | grep -c ${PALUDIS_TMP_DIR} )"

if [ $MOUNTED != $N ]
then
        umount ${PALUDIS_TMP_DIR}
        einfo "Unmounting ${PALUDIS_TMP_DIR} from tmpfs..."
fi
true

tmp folder is hardcoded in the scripts for now and unmounting happens even if tmpfs was not mounted due to existing tmpfs mount. I tried to export a variable when mounting to check it for unmounting, but it gets lost because a script is nested, I guess.

I don't know how to do this. If anybody knows better .....

If you want to set size for tmp folder, just change it in the mount command.
It can be larger than your RAM as long as you have enough swap. Swap is faster than filesystem working with a lot of small files. I have 1G RAM and 4.5G swap. No problems, except for Oenoffice and Wine. This two need more than 1.5G.

Anyway, paludis with tmpfs rules.

[floffe]

zxy: you can set a build dir for each repo with buildroot in the repo config file. I'm not sure how that is read and set in the build phase though...

[zxy]

I know that. But it didn't help me until now.(Thank you for setting my mind into working mode). It is probably better, to mount tmpfs at boot with fstab (as I did until now), and have special folder on disk for special cases like OpenOffice. And with buildroot I can set those special cases to compile on disk.

I think this is much simpler.

[zxy]

Paludis 0.10.1 is out.

Paludis 0.10.1 has been released. Changes since 0.10.0 incude:

• Package origins and install times can now be queried.
• Packages with version 9999, or with names ending in "-cvs" or "-svn", are now considered to be SCM packages for reinstall purposes.
• Paludis will now compile with g++-3.4 again.
• A new --report action, which displays warnings about installed packages that are insecure, masked or no longer available, has been added to the paludis client.

The report is rather nice as a sync_all_post hook.

[zxy]

Http-replicator
Only thing that has to be done is

Code: Select all

export http_proxy="http://192.168.1.1:8080"

for example of default http-replicator usage. This tells wget that it has to use a proxy. Simple.

[Lloeki]

A new --report action, which displays warnings about installed packages that are insecure, masked or no longer available, has been added to the paludis client

could that be broken into --report insecure|masked|unavailable|all ?
and could there also be a --report stable, which would report all installed testing packages that now have a higher stable version available?

e.g:
foo/bar-1.0 x86
foo/bar-1.1 ~x86 <- installed
foo/bar-1.2 x86 <- becomes available later on
foo/bar-1.3 ~x86 <- available too

this is useful because that way, you just put foo/bar ~x86 in your keywords punctually. thus if you do a sync then an update, you will not jump to 1.3, but remove ~x86 and go stable. this situation happens rarely if you sync once a day, but if you sync once a month or less, this is really useful.

[Lepaca Kliffoth]

I have looked into the problem of paludis segfaulting [almost] properly. I still can't figure out exactly what's wrong, though.

If I ignore the tests, paludis build both with emerge and paludis. However, emerge gives me a functioning paludis. Paludis doesn't. That is, paludis -i paludis produces a pludis that segfaults while calculating the dependencies; emerge paludis doesn't. Here are the full logs of "emerge paludis" and "paludis -i paludis":

Emerge log, gzipped
Paludis log, gzipped

More information on request.
Can anyone figure out what's wrong?

edit: Maybe this can be important, just found out: emerge compiles with -O3, paludis with -Os. I wanted to switch from 3 to s but I forgot to change make.conf and only changed paludis

[ciaranm]

edit: Maybe this can be important, just found out: emerge compiles with -O3, paludis with -Os. I wanted to switch from 3 to s but I forgot to change make.conf and only changed paludis

-Os on amd64 with g++-4.1 is known to produce broken code for Paludis.

[yoshi314]

i have a question about dep calculation in paludis.

when i try to install glibc into an empty separate system paludis wants to pull in lots of dependencies:

paludis -pi glibc --dl-circular discard --show-install-reasons summary

Code: Select all

* sys-devel/gcc-config-1.3.14::gentoo [N] <sys-devel/gcc-4.1.1-r3::gentoo, sys-libs/glibc-2.5::gentoo>
* dev-libs/gmp-4.2.1::gentoo [N] -doc -nocxx <dev-libs/mpfr-2.2.0_p16::gentoo, sys-devel/gcc-4.1.1-r3::gentoo>
* sys-libs/db-4.3.29-r2::gentoo {:4.3} [N] -bootstrap -doc -java -nocxx -tcl -test <dev-lang/perl-5.8.8-r2::gentoo, sys-devel/libperl-5.8.8-r1::gentoo, 1 more>
* sys-libs/gdbm-1.8.3-r2::gentoo [N] berkdb <dev-lang/perl-5.8.8-r2::gentoo, sys-devel/libperl-5.8.8-r1::gentoo>
* sys-libs/gpm-1.20.1-r5::gentoo [N] (-selinux) <sys-libs/ncurses-5.5-r3::gentoo>
* sys-libs/ncurses-5.5-r3::gentoo {:5} [N] -bootstrap -build -debug -doc gpm -minimal -nocxx -trace unicode <app-shells/bash-3.2_p5::gentoo, sys-apps/texinfo-4.8-r5::gentoo, 2 more>
* sys-apps/texinfo-4.8-r5::gentoo [N] -build nls -static <sys-apps/groff-1.19.2-r1::gentoo, sys-devel/autoconf-2.61::gentoo, 2 more>
* sys-apps/groff-1.19.2-r1::gentoo [N] X <sys-devel/libperl-5.8.8-r1::gentoo>
* sys-devel/libperl-5.8.8-r1::gentoo {:1} [N] berkdb -debug gdbm -ithreads <dev-lang/perl-5.8.8-r2::gentoo>
* dev-lang/perl-5.8.8-r2::gentoo [N] berkdb -build -debug -doc gdbm -ithreads -perlsuid <app-admin/perl-cleaner-1.04.3::gentoo, dev-perl/Locale-gettext-1.05::gentoo, 7 more>
* app-shells/bash-3.2_p5::gentoo [N] -afs -bashlogger nls -vanilla <app-admin/perl-cleaner-1.04.3::gentoo>
* app-admin/perl-cleaner-1.04.3::gentoo [N] <dev-lang/perl-5.8.8-r2::gentoo>
* perl-core/PodParser-1.35::gentoo [N] <dev-lang/perl-5.8.8-r2::gentoo>
* perl-core/Test-Harness-2.64::gentoo [N] <dev-lang/perl-5.8.8-r2::gentoo>
* sys-devel/automake-wrapper-3-r1::gentoo [N] <sys-devel/automake-1.10::gentoo>
* sys-devel/m4-1.4.8::gentoo [N] nls <sys-devel/autoconf-2.61::gentoo, sys-devel/bison-2.3::gentoo>
* sys-devel/autoconf-wrapper-4-r3::gentoo [N] <sys-devel/autoconf-2.61::gentoo>
* sys-devel/autoconf-2.61::gentoo {:2.5} [N] -emacs <dev-libs/mpfr-2.2.0_p16::gentoo, sys-devel/automake-1.10::gentoo, 1 more>
* perl-core/Test-Simple-0.65::gentoo [N] <virtual/perl-Test-Simple-0.65::gentoo>
* virtual/perl-Test-Simple-0.65::gentoo [N] <dev-perl/Locale-gettext-1.05::gentoo>
* dev-perl/Locale-gettext-1.05::gentoo [N] <sys-apps/help2man-1.36.4::gentoo>
* sys-apps/help2man-1.36.4::gentoo [N] nls <sys-devel/automake-1.10::gentoo, sys-devel/libtool-1.5.22::gentoo>
* sys-devel/automake-1.10::gentoo {:1.10} [N] <dev-libs/mpfr-2.2.0_p16::gentoo, sys-devel/libtool-1.5.22::gentoo>
* sys-devel/libtool-1.5.22::gentoo {:1.5} [N] <dev-libs/mpfr-2.2.0_p16::gentoo>
* dev-libs/mpfr-2.2.0_p16::gentoo [N] <sys-devel/gcc-4.1.1-r3::gentoo>
* sys-devel/bison-2.3::gentoo [N] nls -static <sys-devel/gcc-4.1.1-r3::gentoo>
* sys-apps/sed-4.1.5::gentoo [N] nls -static <sys-devel/gcc-4.1.1-r3::gentoo>
* sys-devel/gcc-4.1.1-r3::gentoo {:4.1} [N] (-altivec) -bootstrap -build -doc fortran -gcj gtk (-hardened) -ip28 -ip32r10k -mudflap (-multilib) -multislot (-n32) (-n64) nls -nocxx -objc -objc++ -objc-gc -test -vanilla <sys-libs/glibc-2.5::gentoo>
* sys-kernel/linux-headers-2.6.17-r1::gentoo [N] -gcc64 <sys-libs/glibc-2.5::gentoo>
* app-misc/pax-utils-0.1.14::gentoo [N] -caps <sys-libs/glibc-2.5::gentoo>
* sys-libs/timezone-data-2006p::gentoo [N] nls <sys-libs/glibc-2.5::gentoo>
* sys-libs/glibc-2.5::gentoo {:2.2} [N] -build -glibc-compat20 -glibc-omitfp -hardened (-multilib) nls nptl nptlonly -profile (-selinux) <sys-devel/gcc-4.1.1-r3::gentoo>

is there a workaround for this issue? i tried tinkering with --dl-installed-deps-pre and --dl-installed-deps-runtime options, but they didn't change a bit.

portage installs only timezone-data as a dependency for glibc. as far as i remember.

does paludis see the difference between runtime and build deps?

[ciaranm]

is there a workaround for this issue? i tried tinkering with --dl-installed-deps-pre and --dl-installed-deps-runtime options, but they didn't change a bit.

You want uninstalled, not installed.

does paludis see the difference between runtime and build deps?

Yes. It also doesn't default to Portage's broken (long story, but basically a couple of Gentoo embedded people with far too much influence subverted the whole depend/rdepend distinction for their own purposes that don't coincide with how the tree uses them or how they were designed) behaviour for rooted installs.

[StifflerStealth]

I have a fairly strange setup. I have always thought that the portage tree did not belong in /usr, and I also felt that the distdir, cvs, ... and various other download directores did not belong in /usr/portage/distfiles, since I have a lot of overlays and it never made since to me to have all those overlays and the files were downloaded to a directory that synced up with the Gentoo servers, so I changed all that. I have a 10 gig partition just for the tree and overlays and the new structure looks like this in my make.conf file:

PORTDIR="/portage/gentoo"
DISTDIR="/portage/distfiles"
PKGDIR="${DISTDIR}/packages"
RPMDIR="${DISTDIR}/rpm"
PORTDIR_OVERLAY="/portage/main-overlay /portage/nx-overlay /portage/pertty-overlay /portage/kernel-overlay /portage/toolchain-overlay"
PORT_LOGDIR="/var/log/portage"

So, will that bash script to automate the process find this and set up everything correctly. or does it need these particular directories in a specific location, especially the main portage tree? Also, will Paludis use a separate director for distdir stuff then? Or, will I need to do a manual install, if so, how what would I need to do to have Pauldis use all the above directories correctly?

Though, now I guess I need to change some of the names like /portage to /repositories and change overlay to something else. Though, I suggest having the tree on it's on partition because it is faster and the files change all the time on it, so it keeps the system from a lot of fragmentation.

Thanks.

Cheers.

[Lepaca Kliffoth]

edit: Maybe this can be important, just found out: emerge compiles with -O3, paludis with -Os. I wanted to switch from 3 to s but I forgot to change make.conf and only changed paludis

-Os on amd64 with g++-4.1 is known to produce broken code for Paludis.

Then why do the tests fail with emerge too, which compiles with -O3?

[Lloeki]

Then why do the tests fail with emerge too, which compiles with -O3?

maybe because it breaks things too?

Though, now I guess I need to change some of the names like /portage to /repositories and change overlay to something else.

well, that's exactly it. I did the same as you. portage2paludis script did the job fairly well at generating repos config. just be sure to manually create profiles/repo_name files in each overlay after that.

[zxy]

@Lepaca Kliffoth
After portage2paludis script I had to edit bashrc, keywords.conf, package_mask.conf, package_unmask.conf, use.conf because I've been using package.keyworde (and other portage files) as a folder with files.

For example:

package.keywords (folder with two files)

• conrad
• misc

The script did not recognize package.keywords was a folder and did not recurse into.
The othe thing were LDFLAGS. I had to copy them over, too.

But after initial configuring I don't think of going back.
With paludis it's much easier to maintain conf files, as all keywords stuff is in one file, all use stuff in one file, etc.

[yoshi314]

is there a workaround for this issue? i tried tinkering with --dl-installed-deps-pre and --dl-installed-deps-runtime options, but they didn't change a bit.

You want uninstalled, not installed.

this is very confusing, especially for non-native english user. does it really work that way (in english) ?

i always associated uninstall with removal, so i thought the options apply to a situation when i remove packages and not when i install packages.

i wonder if somebody else also fell for that.

btw is something like PORTAGE_NICENESS implemented for paludis?

[ciaranm]

So, will that bash script to automate the process find this and set up everything correctly

Yes

Also, will Paludis use a separate director for distdir stuff then?

Set distdir= in the repo .conf files, if the script doesn't do it for you.

edit: Maybe this can be important, just found out: emerge compiles with -O3, paludis with -Os. I wanted to switch from 3 to s but I forgot to change make.conf and only changed paludis

-Os on amd64 with g++-4.1 is known to produce broken code for Paludis.

Then why do the tests fail with emerge too, which compiles with -O3?

At this point I'm going to say... Because your system is screwed up.

is there a workaround for this issue? i tried tinkering with --dl-installed-deps-pre and --dl-installed-deps-runtime options, but they didn't change a bit.

You want uninstalled, not installed.

this is very confusing, especially for non-native english user. does it really work that way (in english) ?

--dl-uninstalled-* tells paludis what to do with packages that are currently uninstalled. --dl-installed-* tells paludis what to do with packages that are currently installed.

btw is something like PORTAGE_NICENESS implemented for paludis?

You really should read the Known Issues and Non-Issues doc:

Automatic Niceness Support
Non-Problem: There's no PORTAGE_NICENESS equivalent.

Rationale: Learn how to use nice. There's no GCC_NICENESS or VIM_NICENESS either.

[Lepaca Kliffoth]

edit: Maybe this can be important, just found out: emerge compiles with -O3, paludis with -Os. I wanted to switch from 3 to s but I forgot to change make.conf and only changed paludis

-Os on amd64 with g++-4.1 is known to produce broken code for Paludis.

Then why do the tests fail with emerge too, which compiles with -O3?

At this point I'm going to say... Because your system is screwed up.

I wonder how it happened Asking someone else to fix it for me is out of the question, I guess I'll test Paludis' ability to bootstrap a system

edit: no, I'm not going to bootstrap from the currently borked system :p

[StifflerStealth]

I wonder how it happened Asking someone else to fix it for me is out of the question, I guess I'll test Paludis' ability to bootstrap a system

edit: no, I'm not going to bootstrap from the currently borked system :p

If you wanted to, you could try to make a paludis only stage one tarball with the latest goodies from "Portage Tree", like updated GLibC and such. Even modify the bootstrap.sh to pull in paludis instead of portage and to modify a few other things like the profile to eliminate all traces of portage. I was thinking of trying to do that at one point when I know a bit more. Then, instead of emoerge system, you would use the equivalent and you wouldn't have the python dependencies.

Cheers.

[Janax]

I figured I'd try Paludis out since I wanted to reorganize my system anyway, but I'm having a problem with bootstrapping. When I try to build 'system' I get a failure inside the testing phase of the 'libtool' package:

Code: Select all

...
PASS: hardcode.test
FAIL: build-relink.test
PASS: noinst-link.test
PASS: demo-unst.test
...

I don't know what exactly caused this to fail and my quick Google searching didn't show much. I'm running ~amd64 2006.1 profile. I'd give more information here, but I don't know what to include (like emerge --info)... if I can post something that would help analyze this problem, I'll be glad to do so!

[ciaranm]

I figured I'd try Paludis out since I wanted to reorganize my system anyway, but I'm having a problem with bootstrapping. When I try to build 'system' I get a failure inside the testing phase of the 'libtool' package:

This is solved by reading the docs.