View previous topic :: View next topic |
Author |
Message |
AgBr Apprentice
Joined: 06 Nov 2010 Posts: 195
|
Posted: Wed Aug 21, 2013 2:03 pm Post subject: [SOLVED] ebuilds from local overlay don't build anymore |
|
|
Since yesterday ebuilds from my local overlay dont't build anmore. Emerge claims no permission.
Code: |
/usr/lib/portage/bin/ebuild.sh: Zeile 545: /tmp/overlay.kgAUc2/bbs1-meta/base/base-0-r201305030508.ebuild: Keine Berechtigung
* ERROR: bbs1-meta/base-0-r201305030508::bbs1 failed (depend phase):
* error sourcing ebuild
*
* Call stack:
* ebuild.sh, line 545: Called die
* The specific snippet of code:
* source "$EBUILD" || die "error sourcing ebuild"
*
* If you need support, post the output of `emerge --info '=bbs1-meta/base-0-r201305030508::bbs1'`,
* the complete build log and the output of `emerge -pqv '=bbs1-meta/base-0-r201305030508::bbs1'`.
* Working directory: '/usr/lib/portage/pym'
* S: '/var/tmp/portage/bbs1-meta/base-0-r201305030508/work/base-0'
|
The german term "Zeile" means "line" in english. The term "keine Berechtigung" means "no permission"
Does anyone know what to look for? The last update had just been about a week ago. The update yesterday failed. May be there had been some change in portage I have missed.
Last edited by AgBr on Fri Dec 13, 2013 8:08 am; edited 1 time in total |
|
Back to top |
|
|
Genone Retired Dev
Joined: 14 Mar 2003 Posts: 9532 Location: beyond the rim
|
Posted: Wed Aug 21, 2013 2:58 pm Post subject: |
|
|
The path in the first line looks fishy, unless you keep your overlays in /tmp with random names. |
|
Back to top |
|
|
AgBr Apprentice
Joined: 06 Nov 2010 Posts: 195
|
Posted: Wed Aug 21, 2013 3:25 pm Post subject: |
|
|
Genone wrote: | The path in the first line looks fishy, unless you keep your overlays in /tmp with random names. |
It's a bit difficult to explain but with every update run the overlay gets created by a script according to a set of ebuilds residing in /usr/local/portage. Don't ask me why it needs to be done this way. I didn't write the build script. I am just maintainig it to the best of my ability. The set of scripts I run create something like a binary gentoo distribution which gets distributed to some hundred clients. All I can say is, that it did work just fine until last week. |
|
Back to top |
|
|
Genone Retired Dev
Joined: 14 Mar 2003 Posts: 9532 Location: beyond the rim
|
Posted: Thu Aug 22, 2013 6:35 am Post subject: |
|
|
Well, /tmp often uses a separate filesystem with a number of restrictions, that would be the first thing to check: `mount | grep /tmp`. |
|
Back to top |
|
|
AgBr Apprentice
Joined: 06 Nov 2010 Posts: 195
|
Posted: Thu Aug 22, 2013 2:24 pm Post subject: |
|
|
Genone wrote: | Well, /tmp often uses a separate filesystem with a number of restrictions, that would be the first thing to check: `mount | grep /tmp`. |
I just found out that there was some change in make.global They changed default directory permission from 755 to 700. This doesn't work for some reason with my overlay created on the fly from a script. Explicitly changing permission for /tmp/overlay* to 755 solved the problem. Got other issues on the client side , I am working on at pressent though. |
|
Back to top |
|
|
Genone Retired Dev
Joined: 14 Mar 2003 Posts: 9532 Location: beyond the rim
|
Posted: Thu Aug 22, 2013 2:47 pm Post subject: |
|
|
If you're referring to PORTAGE_WORKDIR_MODE="0700", that variable had this value since it was introduced in 2006. And anyway it shouldn't affect the permissions of your overlay. More likely that the recently added FEATURES=usersync default, the sticky bit on /tmp and whatever your script does cause some weird (and unsupported) setup. |
|
Back to top |
|
|
AgBr Apprentice
Joined: 06 Nov 2010 Posts: 195
|
Posted: Thu Aug 22, 2013 4:26 pm Post subject: |
|
|
Genone wrote: | If you're referring to PORTAGE_WORKDIR_MODE="0700", that variable had this value since it was introduced in 2006. And anyway it shouldn't affect the permissions of your overlay. More likely that the recently added FEATURES=usersync default, the sticky bit on /tmp and whatever your script does cause some weird (and unsupported) setup. |
Good to know. Thank you for the hint. |
|
Back to top |
|
|
dol-sen Retired Dev
Joined: 30 Jun 2002 Posts: 2805 Location: Richmond, BC, Canada
|
Posted: Thu Aug 22, 2013 4:39 pm Post subject: |
|
|
It was probably the recent change that enabled FEATURES=userpriv to default ON.
Try FEATURES='-userpriv' your-script. if that is the case, then disable it in make.conf. _________________ Brian
Porthole, the Portage GUI frontend irc@freenode: #gentoo-guis, #porthole, Blog
layman, gentoolkit, CoreBuilder, esearch... |
|
Back to top |
|
|
xp-vit n00b
Joined: 22 Sep 2012 Posts: 37
|
Posted: Fri Dec 13, 2013 12:12 am Post subject: |
|
|
dol-sen, And how to resolve this inside ebuild? |
|
Back to top |
|
|
Hu Moderator
Joined: 06 Mar 2007 Posts: 21635
|
Posted: Fri Dec 13, 2013 12:57 am Post subject: |
|
|
xp-vit wrote: | dol-sen, And how to resolve this inside ebuild? | Do not resolve it in the ebuild. Fix the ebuild to work with restricted permissions. Although, in the case of the OP, the failure happened while attempting to read the ebuild, so there is no way the ebuild could resolve it. |
|
Back to top |
|
|
AgBr Apprentice
Joined: 06 Nov 2010 Posts: 195
|
Posted: Fri Dec 13, 2013 8:14 am Post subject: |
|
|
Sorry about causing you headaches about some old problem. I sometimes forget to add the [SOLVED] tag. My problem was caused by a change in some naming convention for identifying revision states of ebuilds, my script rely on. After altering my script all went well in this respect. As I had some other problems too for which I didn't know if these were related, I did let the thread open and later on forgot to close it. Again, sorry about causing you worries. |
|
Back to top |
|
|
|