[SOLVED] ebuild failing to handle redirects

[pingtoo]

First apologize if this post appear in wrong place. This is my first time try to post.

Back to the subject, I notice you tried two different methods for the process.
First you run "ebuild sc-im-0.8.2.ebuild manifest", this lead to a problem, "No write access to /var/cache/distfiles". So it appear the userID used for the command does not have write permission to /var/cache/distfiles directory.
Second time you ran "sudo ebuild sc-im-0.8.2.ebuild manifest". This time the error is about no permission to crate the manifest file as "root" (because you use sudo) in /home/ari/coding/resources_/dinolay/app-office/sc-im/ directory

So it may appear to be permission problem but it is two different permission, first one is your own userID not able to write to a directory (/var/cache/distfiles) usually own by UID/GID "portage/portage". This can be fix by place your ID in to "portage" group. Second one you use "sudo", however "root" does not have permission to write in to your project dir(/home/ari/Ari/coding/resources_/dinolay/app-office/sc-im), this can be fix by chmod 777 to /home/ari/Ari/coding/resources_/dinolay/app-office/sc-im.

So bottom line, you used two different methods to perform same process, however due to effect UID, you have two different problems, Although both problems have same permission errors, those are two different problems.

[Tony0945]

Sorry. Got old eyes, they miss details.
Here is another guess.
1. Install pkgcheck if you haven't already.
2. Go to the directory where the ebuild is.
3. Run "pkgcheck scan"

If you don't see any obvious errors post the results.
Some of the errors may be nitpicking, some may be problems. pkgcheck is used by the dev's on the official tree. It is like "repoman scan" but even more picky.
IIRC, it is color coded. red errors are bad. orange are warnings. maybe bad. Maybe not.

EDIT:
Even if this shows nothing, pkgcheck is a handy tool to have.

[cboldt]

The problem isn't the ebuild, per se. The ebuild works.

The problem is a some factor of location of the ebuild and permission train for portage to get there, and permisisons or similar for the distfiles directory.

I put the ebuild starting from the /var/db/repos/local space, ownership root.root, chmod 755

The /etc/portage/repos.conf/repos.conf file has a suitable entry for this repository.

distfilles are saved in /var/cache/distfiles, directory owned by root.portage, chmod 775

I've never tried to set up a repository starting from my user home directory, so I'm no help on that front, other than portage needs to be able to write to the directory where the ebuild is (to write the Manifest).

[Hu]

First you run "ebuild sc-im-0.8.2.ebuild manifest", this lead to a problem, "No write access to /var/cache/distfiles". So it appear the userID used for the command does not have write permission to /var/cache/distfiles directory.

Correct. Normal users should not have write access here.

So it may appear to be permission problem but it is two different permission, first one is your own userID not able to write to a directory (/var/cache/distfiles) usually own by UID/GID "portage/portage". This can be fix by place your ID in to "portage" group.

This is the wrong solution.

Second one you use "sudo", however "root" does not have permission to write in to your project dir(/home/ari/Ari/coding/resources_/dinolay/app-office/sc-im), this can be fix by chmod 777 to /home/ari/Ari/coding/resources_/dinolay/app-office/sc-im.

Changing permissions to mode 777 is almost always the wrong solution. Please do not recommend this without an explanation of why it is appropriate.

[Tony0945]

Changing permissions to mode 777 is almost always the wrong solution. Please do not recommend this without an explanation of why it is appropriate.

Yes. That might be a quick fix, but plastering over the problem.

Pardon me if it appears above, but what is the result of:

Code: Select all

stat /home/ari/Ari/coding/resources_/dinolay/app-office/sc-im
ls -al stat /home/ari/Ari/coding/resources_/dinolay/app-office/sc-im
groups ari
ls -al /var/cache/distfiles

EDIT:
For reference, here is a similar listing for one of my local ebuilds:

Code: Select all

 # stat `pwd`
  File: /usr/local/mybuilds/www-client/palemoon
  Size: 4096      	Blocks: 8          IO Block: 4096   directory
Device: 802h/2050d	Inode: 8655849     Links: 3
Access: (0755/drwxr-xr-x)  Uid: (  250/ portage)   Gid: (  250/ portage)
Access: 2021-08-23 19:26:20.000000000 -0500
Modify: 2021-08-23 19:26:20.000000000 -0500
Change: 2021-08-23 19:26:38.087050250 -0500
 Birth: 2018-08-14 14:39:16.302261219 -0500
 # ls -al `pwd`
total 92
drwxr-xr-x 3 portage portage 4096 Aug 23 19:26 .
 # groups tony
wheel audio users portage tony
## ls -al /var/cache/ |grep distfiles
drwxr-xr-x 11 portage portage 585728 Sep 11 17:34 distfiles

Notice I changed that last command, otherwise it scrolls off the screen and I'm only interested in the directory.

[Hu]

Notice I changed that last command, otherwise it scrolls off the screen and I'm only interested in the directory.

You can use -d for this purpose:

Code: Select all

ls -ld /var/cache/distfiles

[Ari_archer]

First apologize if this post appear in wrong place. This is my first time try to post.

Back to the subject, I notice you tried two different methods for the process.
First you run "ebuild sc-im-0.8.2.ebuild manifest", this lead to a problem, "No write access to /var/cache/distfiles". So it appear the userID used for the command does not have write permission to /var/cache/distfiles directory.
Second time you ran "sudo ebuild sc-im-0.8.2.ebuild manifest". This time the error is about no permission to crate the manifest file as "root" (because you use sudo) in /home/ari/coding/resources_/dinolay/app-office/sc-im/ directory

So it may appear to be permission problem but it is two different permission, first one is your own userID not able to write to a directory (/var/cache/distfiles) usually own by UID/GID "portage/portage". This can be fix by place your ID in to "portage" group. Second one you use "sudo", however "root" does not have permission to write in to your project dir(/home/ari/Ari/coding/resources_/dinolay/app-office/sc-im), this can be fix by chmod 777 to /home/ari/Ari/coding/resources_/dinolay/app-office/sc-im.

So bottom line, you used two different methods to perform same process, however due to effect UID, you have two different problems, Although both problems have same permission errors, those are two different problems.

Thank you! adding myself to the portage group fixed it!

[Ari_archer]

It's finally solved! all it took is for me to add myself to the portage group....

Sorry for this much hassle. but now it works flawlessly.

I will make this post as [SOLVED] now, thank you

[pjp]

It's finally solved! all it took is for me to add myself to the portage group....

Sorry for this much hassle. but now it works flawlessly.

I will make this post as [SOLVED] now, thank you

I'd like to add a caution to Future User who finds this "SOLVED" thread while looking for a solution.

So it may appear to be permission problem but it is two different permission, first one is your own userID not able to write to a directory (/var/cache/distfiles) usually own by UID/GID "portage/portage". This can be fix by place your ID in to "portage" group.

This is the wrong solution.

More detail:

I consider it discouraged based on a warning I once saw that putting your user in the Linux group portage gives all your processes the ability to manipulate some files that are written/trusted by emerge. In the extreme case, a badly behaved process (whether malicious or just malfunctioning) could impact some aspects of Portage configuration, causing surprising or unwanted results the next time root uses emerge to manage the system. The output shown in this thread is one example: anyone in the Portage group can rewrite that list, which could mislead Portage into preserving a library it should not, or not preserving a library it should. If you trust everything you run, adding your user to the group portage should be fine.

That thread contains another related post, but the above should be sufficient to reference in this thread.



pingtoo requested clarification on why his suggestions were considered incorrect. That thread is here:
[split] why is my suggestions were consider incorrect.