[PALUDIS] Support thread (current v. 0.24.6) - Part 3

[slycordinator]

Can't seem to find a way to stop Paludis trying to install opal and ekiga (which don't build with gcc 4.20 and I have no use for anyway). In the old days I could do this with package.provided, what's the paludis way of telling it I don't want them? thanks

Code: Select all

for x in net-libs/opal net-im/ekiga ; do echo $x >> /etc/paludis/package_mask.conf

And I have no idea why you would use package.provided to avoid installing a package. package.provided was supposed to be your way of telling portage that you really had something installed (that portage didn't know about) that provided the stuff that the package in question provided. If you just didn't want the package to be installed you would've done the same script as above put change the file to /etc/portage/package.mask

[nikaya]

In the old days I could do this with package.provided, what's the paludis way of telling it I don't want them?

https://forums.gentoo.org/viewtopic-p-4 ... ml#4134372

[lucapost]

Are there any updates of http://forums.gentoo.org/viewtopic-p-37 ... ml#3749504?

[Mcklaren]

Hello, i'm another new user of paludis , and i've a small question, when i'd like install any package with paludis i get this message:
... Directory '/usr/portage/distfiles' owned by group 'portage', not 'paludisbuild', so cannot enable userpriv, then i'd like know how i can fix this of the correct method. More info of the message:

Code: Select all

paludis@1187826871: [WARNING] In program paludis -i amule:
  ... When performing install action from command line:
  ... When executing install task:
  ... When installing 'sys-apps/man-pages-2.63':
  ... When checking permissions on '/usr/portage/distfiles' for userpriv:
  ... Directory '/usr/portage/distfiles' owned by group 'portage', not 'paludisbuild', so cannot enable userpriv
>>> Running ebuild phase fetch as root:root...
>>> Starting builtin_fetch
>>> Need to fetch man-pages-2.63.tar.bz2

Thank you.

[slycordinator]

Hello, i'm another new user of paludis , and i've a small question, when i'd like install any package with paludis i get this message:
... Directory '/usr/portage/distfiles' owned by group 'portage', not 'paludisbuild', so cannot enable userpriv, then i'd like know how i can fix this of the correct method. More info of the message:

Code: Select all

paludis@1187826871: [WARNING] In program paludis -i amule:
  ... When performing install action from command line:
  ... When executing install task:
  ... When installing 'sys-apps/man-pages-2.63':
  ... When checking permissions on '/usr/portage/distfiles' for userpriv:
  ... Directory '/usr/portage/distfiles' owned by group 'portage', not 'paludisbuild', so cannot enable userpriv
>>> Running ebuild phase fetch as root:root...
>>> Starting builtin_fetch
>>> Need to fetch man-pages-2.63.tar.bz2

Thank you.

Code: Select all

chown -R paludisbuild:paludisbuild /usr/portage/distfiles

[jkoerner]

Howdy folks,
everything runs smoothly with paludis. No hassles, no problems, big thanks for this piece of software.

Has anybody removed portage on a productive box? Any experience with that, any hassles?
I use paludis since

Code: Select all

1177865871: Started emerge on: Apr 29, 2007 18:57:51
1177865871:  *** emerge --alphabetical paludis
1177865896:  >>> emerge (1 of 1) sys-apps/paludis-0.22.2 to /

and no problems(the real ones) ever since.

[peterbye]

I tried just moving the emerge script aside. First problem I hit was python-updater, had to put emerge back, run python-updater with --pretend then use paludis manually to rebuild the listed packages.

[zxy]

@lucapost: well I just mount /var/tmp/paludis as tmpfs in my fstab
otherwise iirc there is no progress.

[pussi]

I tried just moving the emerge script aside. First problem I hit was python-updater, had to put emerge back, run python-updater with --pretend then use paludis manually to rebuild the listed packages.

did you try python-updater -P paludis or didn't that work either?

[peterbye]

I tried just moving the emerge script aside. First problem I hit was python-updater, had to put emerge back, run python-updater with --pretend then use paludis manually to rebuild the listed packages.

did you try python-updater -P paludis or didn't that work either?

Nope, afraid I missed that option, but now I know for next time, thanks

[fldc2]

Paludis seems to have stopped working with the latest upgrade of bash, any hint on how to fix this?

[iamben]

the broken bash version has been masked, downgrade to the latest unmasked and all is well. you'll probably need to use portage.

[vegaman]

Code: Select all

emerge -av bash

These are the packages that would be merged, in order:

!!! All ebuilds that could satisfy "bash" have been masked.
!!! One of the following masked packages is required to complete your request:
- app-shells/bash-3.2_p17 (masked by: corruption)
- app-shells/bash-3.2_p17-r1 (masked by: corruption)
- app-shells/bash-2.05b-r11 (masked by: corruption)
- app-shells/bash-3.0-r12 (masked by: corruption)
- app-shells/bash-3.1_p17 (masked by: corruption)
- app-shells/bash-3.0-r14 (masked by: corruption)
- app-shells/bash-3.0-r13 (masked by: corruption)
- app-shells/bash-3.2_p25 (masked by: package.mask)

For more information, see MASKED PACKAGES section in the emerge man page or 
refer to the Gentoo Handbook.

Help?
Paludis won't install anything now either.

EDIT: It seems I have no bash...

Code: Select all

which bash
which: no bash in (/sbin:/bin:/usr/sbin:/usr/bin)

Time to get a stage3 tarball I guess

[slycordinator]

You don't need to use a stage3 tarball.

You're probably getting corruption because paludis and portage don't work together. You'll likely have to remove the ".cache" directory inside your portage tree then do an "emerge --metadata" then you should be all set to re-install and older version of bash via emerge.

And remember that the version you masked needs to be added to /etc/portage/package.mask since obviously portage doesn't read paludis directories.

[vegaman]

Hmm, don't think that would have worked, because I made a mistake.
eix reported both bash-3.2_p17-r1 and bash-3.2_p25 as being installed, so without thinking too much I unmerged bash-3.2_p25... no more bash

So I got bash and sh from the stage3 tarball to get enough functionality to rebuild bash... not sure of the right way to do it, but that seems to have worked.

[CheshireCat]

I'm running paludis on four computers, and they're all pretty much updated at the same time. One of them has started giving me trouble. Paludis fails after "Starting builtin_loadenv", without giving any clear indication what went wrong, no matter what I try to install. I tried reinstalling paludis from portage (and then rebuilding the installed cache), and I was able to do that succesfully, but it didn't fix the problem. Does anybody have any idea what might be going on here, or how to get more info about error? I've tried the debug log level, and other than dumping all of the environment variables, it doesn't add anything that clarifies the cause of the problem.

Code: Select all

/usr/libexec/paludis/ebuild.bash@1188092342: [DEBUG.EBUILD] Loading bashrc file /etc/paludis/bashrc (from ?)
>>> Running ebuild phases loadenv setup saveenv as root:root...
/usr/libexec/paludis/ebuild.bash@1188092342: [DEBUG.EBUILD] Starting hook 'ebuild_loadenv_pre' (from /nfs4/portage/sys-apps/paludis/paludis-0.24.6.ebuild)
>>> Starting builtin_loadenv
paludis@1188092342: [DEBUG] Starting hook 'install_fail'

Install error:
  * In program paludis -i --log-level debug --dl-deps-default discard paludis:
  * When performing install action from command line:
  * When executing install task:
  * When installing 'sys-apps/paludis-0.24.6':
  * Install error: Install failed for 'sys-apps/paludis-0.24.6::gentoo'

Urgh, now i'm seeing it on my laptop. So far, one amd64 system can still build, two x86 can't. :/.

[slycordinator]

Hmm, don't think that would have worked, because I made a mistake.

I'm pretty sure it would've worked perfectly. Even if you were currently running a bash shell and uninstalled bash your currently running shell would run fine (though if you ran any scripts that had "#!/bin/bash" they'd obviously fail).

So I got bash and sh from the stage3 tarball to get enough functionality to rebuild bash... not sure of the right way to do it, but that seems to have worked.

I assumed you meant you were gonna unpack the whole stage3 tarball which would've overwritten a lot of stuff that was newer. But your method would work fine.

Plus, it was probably quicker than my suggestion.

[vegaman]

I'm pretty sure it would've worked perfectly. Even if you were currently running a bash shell and uninstalled bash your currently running shell would run fine (though if you ran any scripts that had "#!/bin/bash" they'd obviously fail).

Thanks for the suggestions, yeah, that was the problem I was having. It was trying to run a script and there was no /bin/sh to run it with, and if there had been there would've been no /bin/bash either.
But bash is rebuilt and paludis is updating my system again

Only problem I've had is that it insisted on getting pax-utils-0.1.16.tar.bz2 from my default mirror, and not running any checksums on it as there was no digest, but the ebuild refers to http://wh0rd.org/pax-utils-0.1.16.tar.bz2. Which works, but the mirrored version was different or corrupt, and wouldn't build.

[slycordinator]

Only problem I've had is that it insisted on getting pax-utils-0.1.16.tar.bz2 from my default mirror, and not running any checksums on it as there was no digest, but the ebuild refers to http://wh0rd.org/pax-utils-0.1.16.tar.bz2. Which works, but the mirrored version was different or corrupt, and wouldn't build.

That's because your default mirror is ALWAYS used first. That's by design.

The problem isn't paludis (portage would have the same problem btw); the problem is that you have a borked default mirror.

The only difference is that portage will try to redownload the file and not simply fail, but in the case of having a bad default mirror it'll redownload that file non-stop (and each time download the bad file then try again).

[vegaman]

That's because your default mirror is ALWAYS used first. That's by design.

The problem isn't paludis (portage would have the same problem btw); the problem is that you have a borked default mirror.

The only difference is that portage will try to redownload the file and not simply fail, but in the case of having a bad default mirror it'll redownload that file non-stop (and each time download the bad file then try again).

But when I tried emerging it with portage, it fetched the right file for me, without trying my default mirror first. That's how I found what was going wrong. Though yes, my default mirror must have borked that file.

[omp]

Just a note...

I've written a log parser for Paludis, similar to genlop or qlop for Portage log files. The only dependencies are Paludis and Ruby, and it seems to be pretty fast too. There is currently no ebuild, as it's just a single Ruby script, but if there is interest in one, I can make it and maybe even commit it to the tree. Feel free to send any feature requests or bug reports my way.

Ruby script: http://dev.gentoo.org/~omp/paludis/pint.rb
Source in HTML: http://dev.gentoo.org/~omp/paludis/pint.rb.html
Outdated screenshot: http://dev.gentoo.org/~omp/paludis/pint.png

Thank you and sorry for adding noise to the support thread.

[CrimsonKing]

I'm running paludis on four computers, and they're all pretty much updated at the same time. One of them has started giving me trouble. Paludis fails after "Starting builtin_loadenv", without giving any clear indication what went wrong, no matter what I try to install. I tried reinstalling paludis from portage (and then rebuilding the installed cache), and I was able to do that succesfully, but it didn't fix the problem. Does anybody have any idea what might be going on here, or how to get more info about error? I've tried the debug log level, and other than dumping all of the environment variables, it doesn't add anything that clarifies the cause of the problem.

Code: Select all

/usr/libexec/paludis/ebuild.bash@1188092342: [DEBUG.EBUILD] Loading bashrc file /etc/paludis/bashrc (from ?)
>>> Running ebuild phases loadenv setup saveenv as root:root...
/usr/libexec/paludis/ebuild.bash@1188092342: [DEBUG.EBUILD] Starting hook 'ebuild_loadenv_pre' (from /nfs4/portage/sys-apps/paludis/paludis-0.24.6.ebuild)
>>> Starting builtin_loadenv
paludis@1188092342: [DEBUG] Starting hook 'install_fail'

Install error:
  * In program paludis -i --log-level debug --dl-deps-default discard paludis:
  * When performing install action from command line:
  * When executing install task:
  * When installing 'sys-apps/paludis-0.24.6':
  * Install error: Install failed for 'sys-apps/paludis-0.24.6::gentoo'

Urgh, now i'm seeing it on my laptop. So far, one amd64 system can still build, two x86 can't. :/.

I'm experiencing this same problem, any luck fixing it Cheshire?

[slycordinator]

That's because your default mirror is ALWAYS used first. That's by design.

The problem isn't paludis (portage would have the same problem btw); the problem is that you have a borked default mirror.

The only difference is that portage will try to redownload the file and not simply fail, but in the case of having a bad default mirror it'll redownload that file non-stop (and each time download the bad file then try again).

But when I tried emerging it with portage, it fetched the right file for me, without trying my default mirror first. That's how I found what was going wrong. Though yes, my default mirror must have borked that file.

My guess is that /etc/make.conf, /etc/portage/mirrors, or both specify a different default mirror than you have in /etc/paludis/mirrors.conf

[KejPi]

Is there some altarnative to "quickpkg" working with paludis? Or can I use quickpkg?

My problem is following. I am using compiz-fusion from xeffects overlay and before updating I want to backup my current compiz-fusion installation just in case. If somethig is not working after compiz update I am downgrading to backup.

How to do this with paludis?

Thanks!

[nikaya]

Currently not.But maybe some day.