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

Message

zxy · Post by **zxy** » Sat Dec 02, 2006 11:40 pm

Does this apply to the situation when for example a test fails.

ciaranm · Post by **ciaranm** » Sat Dec 02, 2006 11:47 pm

zxy wrote:Does this apply to the situation when for example a test fails.

No. The VDB isn't modified until Paludis starts merging to the live filesystem. If the VDB isn't modified, the cache doesn't need updating.

zxy · Post by **zxy** » Sun Dec 03, 2006 12:21 am

This cache stuff is great!!!!

The timed example equals emerge -ep mozilla-firefox (you probably know the huge timings for operation like that)

Code: Select all

# time paludis -i mozilla-firefox --dl-reinstall always -p
...
...
Total: 198 packages (1 new, 197 rebuilds)

 * You have 1 unread news items

real    0m1.557s
user    0m1.311s
sys     0m0.211s

ciaranm · Post by **ciaranm** » Sun Dec 03, 2006 12:57 am

The gain is considerably less for huge operations. The cache is most effective for operations like "paludis -q foo", where foo isn't virtual. Most dep list calculations will require a fairly large tree load and a full vdb load anyway.

The graphs show it fairly well...

Conan · Post by **Conan** » Sun Dec 03, 2006 4:48 am

Just installed paludis, been playing with it some..

One question: is there an equivelent to emerges --tree? I'm trying to figure out why paludis wants to downgrade qt and portage doesn't.

zxy · Post by **zxy** » Sun Dec 03, 2006 5:05 am

maybe

Code: Select all

paludis -i qt -p  --show-install-reasons  full

check /etc/paludis/keywords.conf and package_mask.conf if everything is as you want.

Beinii · Post by **Beinii** » Sun Dec 03, 2006 5:16 pm

paludis -pi world

Code: Select all

  ... When performing install action from command line:
  ... When executing install task:
  ... When adding PackageDepAtom 'virtual/baselayout':
  ... When loading entries for virtuals repository:
  ... When loading names for virtuals repository:
  ... When loading virtual packages for repository 'x-xeffects'
  ... When loading category names for x-xeffects:
  ... No categories file for repository at '/usr/local/overlays/xeffects', faking it

Query error:
  * In program paludis -pi world:
  * When performing install action from command line:
  * When executing install task:
  * When adding PackageDepAtom 'x11-base/xgl':
  * No versions of 'x11-base/xgl' are available]

paludis -q xgl

Code: Select all

* x11-base/xgl
    installed:             0.0.1_pre20061108* {:0}
    Homepage:              http://xorg.freedesktop.org/
    Description:           XGL X server
    License:               ( X11 )
    Installed time:        Thu Nov 30 23:45:15 2006
    Use flags:              (-debug) (ipv6) (xinerama)

Why Paludis can't find it?

EDIT: Figured it out...

Paludis used http://svn.gentoo-xeffects.org/xeffects/ instead of http://svn.gentoo-xeffects.org/xeffects/trunk.

zxy · Post by **zxy** » Sun Dec 03, 2006 5:21 pm

You must add the names of the overlay's subfolders that you want to use to the

Code: Select all

/usr/local/overlays/xeffects/categories

for example

Code: Select all

x11-base
x11-wm
x11-libs
...

Folders that are not named in the categories file are excluded.

ciaranm · Post by **ciaranm** » Sun Dec 03, 2006 6:13 pm

zxy wrote:You must add the names of the overlay's subfolders that you want to use to the
Code: Select all
/usr/local/overlays/xeffects/categories

Or you can just not have that file at all. You get a warning for it, but it'll still work.

I'm open to being persuaded that lack of categories should be ll_qa rather than ll_warning, especially if most users use --log-level warning.

zxy · Post by **zxy** » Sun Dec 03, 2006 6:24 pm

Sorry for a partial missinfo.

ciaranm · Post by **ciaranm** » Sun Dec 03, 2006 6:29 pm

zxy wrote:Sorry for a partial missinfo.

You were right until a few releases back. We used to require categories. Now to be more overlay-style-repository friendly, we can just pretend that it exists.

StifflerStealth · Post by **StifflerStealth** » Sun Dec 03, 2006 6:51 pm

Okay, I am trying to install this package:
http://packages.gentoo.org/search/?sstring=xnview

When I do:
~ # paludis -ip xnview
Building target list...
Query error:
* In program paludis -ip xnview:
* When performing install action from command line:
* When adding install target 'xnview':
* When disambiguating package name 'xnview':
* No such package 'xnview'

However, when I do:
~ # paludis -ip x11-misc/xnview
Building target list...
Building dependency list... done

These packages will be installed:

* sys-apps/portage-2.1.2_rc2-r4 [U 2.1.2_rc2-r3] -build -doc -epydoc (-selinux) linguas: -pl
* x11-libs/libXfont-1.2.5 [U 1.2.3] -debug -ipv6
* media-fonts/font-bh-lucidatypewriter-100dpi-1.0.0 [N] X nls
* media-fonts/font-bh-lucidatypewriter-75dpi-1.0.0 [N] X nls
* x11-misc/xnview-1.70-r2 [N]

Total: 5 packages (3 new, 2 upgrades)

Must we now enter the category? I am using the new names cache and I read the webpage and did the cache update command and even did a sync and that updated the cache as well. Or did I miss something?

Cheers.

ciaranm · Post by **ciaranm** » Sun Dec 03, 2006 6:58 pm

StifflerStealth wrote:Must we now enter the category? I am using the new names cache and I read the webpage and did the cache update command and even did a sync and that updated the cache as well. Or did I miss something?

You probably didn't sync the installable cache. Try:

Code: Select all

paludis --regenerate-installable-cache

If that still doesn't work, have a look in the names cache directory for that repository and see what you find.

Conan · Post by **Conan** » Sun Dec 03, 2006 7:33 pm

Another oddity...

It appears paludis doesn't write to the world file all the time? I ran a paludis --uninstall-unused -p last night, and saw some stuff I wanted to keep (I got rid of kdebase-meta a while ago because it had stuff I didn't use and am still working on installing all the actual packages that I use). I ran paludis -i list of packages last night, got through about 8 of them, then ^C'd to shut my computer off for a while. This morning when I ran paludis --uninstall-unused, all the packages that were installed properly last night were still going to be uninstalled... How can I fix this?

ciaranm · Post by **ciaranm** » Sun Dec 03, 2006 8:00 pm

Conan wrote:Another oddity...

It appears paludis doesn't write to the world file all the time? I ran a paludis --uninstall-unused -p last night, and saw some stuff I wanted to keep (I got rid of kdebase-meta a while ago because it had stuff I didn't use and am still working on installing all the actual packages that I use). I ran paludis -i list of packages last night, got through about 8 of them, then ^C'd to shut my computer off for a while. This morning when I ran paludis --uninstall-unused, all the packages that were installed properly last night were still going to be uninstalled... How can I fix this?

For installs, Paludis doesn't update world until the entire transaction is done. This is intentional.

lnxz · Post by **lnxz** » Sun Dec 03, 2006 8:29 pm

I've discovered that when installing certain haskell packages (cabal, f.ex), paludis seems to mix up 'merge' from /usr/libexec/paludis/utils with /usr/bin/merge (from app-text/rcs), which leads to failure, for obvious reasons.
My guess would be that this happens due to some funky things in the haskell eclass or something, because it doesn't happen with non-haskell packages.
Adding explicit path to the correct 'merge' in builtin_merge.bash fixes this issue, but it's obviously a horrible soloution.
Is there is a good/proper way of avoiding this, or is it just a question of fixing the eclass (if that's really the reason this happens)?
Also, is it to be expected that a package that fails during merge should be recorded as installed?

Conan · Post by **Conan** » Sun Dec 03, 2006 8:31 pm

Hmm,

Thats annoying

I realize that listing a large number of packages on the commandline probably doesn't occur all that often, but when someone does list a bunch of things to install, it seems like each one could be treated as a separate transaction to not prevent too much overcompiling.

Dunno

ciaranm · Post by **ciaranm** » Sun Dec 03, 2006 9:02 pm

lnxz wrote:I've discovered that when installing certain haskell packages (cabal, f.ex), paludis seems to mix up 'merge' from /usr/libexec/paludis/utils with /usr/bin/merge (from app-text/rcs), which leads to failure, for obvious reasons.
My guess would be that this happens due to some funky things in the haskell eclass or something, because it doesn't happen with non-haskell packages.
Adding explicit path to the correct 'merge' in builtin_merge.bash fixes this issue, but it's obviously a horrible soloution.

It's horrible, but probably the way to go for now (until merge is internalised, anyway). I'm guessing these eclasses shove /usr/bin into PATH.

StifflerStealth · Post by **StifflerStealth** » Sun Dec 03, 2006 9:39 pm

ciaranm wrote:
StifflerStealth wrote:Must we now enter the category? I am using the new names cache and I read the webpage and did the cache update command and even did a sync and that updated the cache as well. Or did I miss something?
You probably didn't sync the installable cache. Try:
Code: Select all
paludis --regenerate-installable-cache
If that still doesn't work, have a look in the names cache directory for that repository and see what you find.

I got it to work. Apparently there was a typo in my config line. If it is not ${location}/.cache/... exactly it fails.

I had /var/tmp/paludis/....

ciaranm · Post by **ciaranm** » Sun Dec 03, 2006 9:42 pm

StifflerStealth wrote:
ciaranm wrote:
StifflerStealth wrote:Must we now enter the category? I am using the new names cache and I read the webpage and did the cache update command and even did a sync and that updated the cache as well. Or did I miss something?
You probably didn't sync the installable cache. Try:
Code: Select all
paludis --regenerate-installable-cache
If that still doesn't work, have a look in the names cache directory for that repository and see what you find.
I got it to work. Apparently there was a typo in my config line. If it is not ${location}/.cache/... exactly it fails. I had /var/tmp/paludis/....

It can go in other places. However, you can't have two repositories' caches in exactly the same location.

Conan · Post by **Conan** » Sun Dec 03, 2006 9:48 pm

Something else I'm noticing.

Paludis does not clean up when receiving a ^C. Another example of this is if ^C'ing halfway through the distfile, paludis does not delete the partial download, causing manual intervention to be required on a resume.

ciaranm · Post by **ciaranm** » Sun Dec 03, 2006 9:55 pm

Conan wrote:Something else I'm noticing.

Paludis does not clean up when receiving a ^C. Another example of this is if ^C'ing halfway through the distfile, paludis does not delete the partial download, causing manual intervention to be required on a resume.

Correct. That's because Paludis doesn't know what you want to happen when you have a half fetched distfile, so it just leaves it for you to sort out.

revenger · Post by **revenger** » Sun Dec 03, 2006 10:28 pm

is there a paludis equivalent for portage's package.provided?

ciaranm · Post by **ciaranm** » Sun Dec 03, 2006 10:31 pm

revenger wrote:is there a paludis equivalent for portage's package.provided?

No. Nor will there be -- package.provided breaks features like use and slot dependencies.

zxy · Post by **zxy** » Mon Dec 04, 2006 6:51 am

I was installing kdebase-kioslaves and test failed because it couldnt connect to X server.
OK, I started fluxbox (loged in as user, and startx). Still the same. Anybody came past this?

(I know I can disable test in bashrc, but I would like to pass as many tests as possible)