Re: [gentoo-portage-dev] custom profiles?
On 03/14/2015 11:41 AM, Joakim Tjernlund wrote:
On Sat, 2015-03-14 at 11:08 -0700, Zac Medico wrote:
On 03/14/2015 09:12 AM, Joakim Tjernlund wrote:
On Wed, 2015-03-11 at 13:43 -0700, Zac Medico wrote:
On 03/11/2015 01:16 PM, Joakim Tjernlund wrote:
On Wed, 2015-03-11 at 10:56 -0700, Zac Medico wrote:
On 03/11/2015 08:48 AM, Joakim Tjernlund wrote:
On Sun, 2015-03-08 at 11:58 -0700, Zac Medico wrote:
On 03/08/2015 10:01 AM, Joakim Tjernlund wrote:
On Sun, 2015-03-08 at 15:47 +, Joakim Tjernlund wrote:
package.use/package.use.force is a bit different though:
cat /etc/portage/package.use/qemu
app-emulation/qemu vde -alsa -pulseaudio -bluetooth -opengl
qemu_user_targets_x86_64 xattr
virtfs
static-
user
#Needed by static-user
sys-libs/zlib static-libs
dev-libs/glib static-libs
sys-apps/attr static-libs
Moving this to package.use/package.use.force does not respect -alsa,
-pulseaudio, -opengl
all
flags which has a - on them, emerge wants to turn them on again.
Am I missing something?
Using portage 2.2.18
Appears one have to use package.use.mask for that.
cat package.use.mask
app-emulation/qemu alsa pulseaudio bluetooth opengl
It would be handy if one could use the same syntax as in
/etc/portage/package.use/qemu(-alsa -
opengl
etc.)
Jocke
Yes, the inverted use.mask logic can be confusing if you are not
familiar with it. The negative
flags
have a
special meaning within the context of of portage's incremental
stacking behavior, so they can
still
be
useful, though not in the same way that you you attempted to use them.
Just noticed that USE flags in profiles/package.use.mask override
everything so this
USE=thin emerge -av sys-fs/lvm2
will not turn on thin if thin is in profiles/package.use.mask
How can just change the default so a user can easily turn it on ?
Generally, setting the USE environment variable like that is poor practice,
because the setting will not
persist the next time that you rebuild the package. So, you should set the
flag in
I know, this was just an example to illustrate that it did not work.
/etc/portage/package.use. You can unmask the flag for lvm2 like this:
echo sys-fs/lvm2 -thin /etc/portage/profile/package.use.mask
You misunderstand, I have sys-fs/lvm2 thin in
/etc/portage/profile/package.use.mask
and I want a user to able to override this setting, using USE=.. or adding
it
to their local /etc/portage/package.use file/dir
There's no other way to negate a use mask than to use
/etc/portage/profile/{use.mask,package.use.mask} as I have described. I
don't think that it makes much sense to negate a use mask for a single
emerge invocation. If you want to do that, then why is the use flag
masked anyway?
--
Thanks,
Zac
Re: [gentoo-portage-dev] custom profiles?
On Sat, 2015-03-14 at 11:57 -0700, Zac Medico wrote:
On 03/14/2015 11:41 AM, Joakim Tjernlund wrote:
On Sat, 2015-03-14 at 11:08 -0700, Zac Medico wrote:
On 03/14/2015 09:12 AM, Joakim Tjernlund wrote:
On Wed, 2015-03-11 at 13:43 -0700, Zac Medico wrote:
On 03/11/2015 01:16 PM, Joakim Tjernlund wrote:
On Wed, 2015-03-11 at 10:56 -0700, Zac Medico wrote:
On 03/11/2015 08:48 AM, Joakim Tjernlund wrote:
On Sun, 2015-03-08 at 11:58 -0700, Zac Medico wrote:
On 03/08/2015 10:01 AM, Joakim Tjernlund wrote:
On Sun, 2015-03-08 at 15:47 +, Joakim Tjernlund wrote:
package.use/package.use.force is a bit different though:
cat /etc/portage/package.use/qemu
app-emulation/qemu vde -alsa -pulseaudio -bluetooth
-opengl qemu_user_targets_x86_64
xattr
virtfs
static-
user
#Needed by static-user
sys-libs/zlib static-libs
dev-libs/glib static-libs
sys-apps/attr static-libs
Moving this to package.use/package.use.force does not
respect -alsa, -pulseaudio, -
opengl
all
flags which has a - on them, emerge wants to turn them on
again.
Am I missing something?
Using portage 2.2.18
Appears one have to use package.use.mask for that.
cat package.use.mask
app-emulation/qemu alsa pulseaudio bluetooth opengl
It would be handy if one could use the same syntax as in
/etc/portage/package.use/qemu(-
alsa -
opengl
etc.)
Jocke
Yes, the inverted use.mask logic can be confusing if you are
not familiar with it. The
negative
flags
have a
special meaning within the context of of portage's
incremental stacking behavior, so they
can
still
be
useful, though not in the same way that you you attempted to
use them.
Just noticed that USE flags in profiles/package.use.mask override
everything so this
USE=thin emerge -av sys-fs/lvm2
will not turn on thin if thin is in profiles/package.use.mask
How can just change the default so a user can easily turn it on ?
Generally, setting the USE environment variable like that is poor
practice, because the setting will
not
persist the next time that you rebuild the package. So, you should set
the flag in
I know, this was just an example to illustrate that it did not work.
/etc/portage/package.use. You can unmask the flag for lvm2 like this:
echo sys-fs/lvm2 -thin /etc/portage/profile/package.use.mask
You misunderstand, I have sys-fs/lvm2 thin in
/etc/portage/profile/package.use.mask
and I want a user to able to override this setting, using USE=.. or
adding it
to their local /etc/portage/package.use file/dir
There's no other way to negate a use mask than to use
/etc/portage/profile/{use.mask,package.use.mask} as I
have described. I don't think that it makes much sense to negate a use mask
for a single emerge invocation.
If you want to do that, then why is the use flag masked anyway?
I am putting tougher a profile for my company where I want to specify default
USE flags for different apps/libs. Then a user who knows what he/she is doing
should be able to override these defaults. It is not possible as far
as I can tell to override negative USE flags or is there?
Jocke
Re: [gentoo-dev] find -delete safe to use?
On Sat, 14 Mar 2015 23:14:57 + James Le Cuirot ch...@gentoo.org wrote: On the one hand, it should always be present now, given what I said about @system above but on the other hand, if it gets installed as gfind then there's no point in pulling it in if you're only going to call find. Just realised my other hand was actually the same hand! It's still going to get pulled in either way. I should go to bed. ;) Still would like some clarification on this though. -- James Le Cuirot (chewi) Gentoo Linux Developer pgp3bSZOmRC3N.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Naming of repositories: gento-x86 edition, bike shedding wanted
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 14.03.2015 23:37, Rich Freeman wrote: On Sat, Mar 14, 2015 at 6:25 PM, Robin H. Johnson robb...@gentoo.org wrote: 0. What names for the tree/repository. Suggestions: gentoo-repo gentoo-repository gentoo-main gentoo-repo-main gentoo-repository-main 1. We have some namespaces in Git: proj, dev, priv, data, sites, exp; should the tree be in one of those namespaces, a new namespace, or be without a namespace? git://anongit.gentoo.org/NEW-NAME.git. I'd suggest creating a repository(-ies) namespace (or maybe call it repo(s)), since conceivably we might have more than one at some point, overlays might end up in there at some point, etc. iirc most deb and rpm based distributions use main for their central repository, so +1 for gentoo-main. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0 iQJ8BAEBCgBmBQJVBMSUXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4MDA1RERERkM0ODM2QkE4MEY3NzY0N0M1 OEZCQTM2QzhEOUQ2MzVDAAoJEFj7o2yNnWNcIW4P/RLzP0OhM6SpFbCPvXRNbIqJ ggL/BXHY7G6xOO++CHxIvNx00cLtoK0lq0MANBbjNffQ5Wv/LHxhrF2oX4CwO91a AYwZEkmtaauLkx8xrVmhFvuq/liPD4So1JMZ/HMomMa1yb2VevPMjSXW2YwimnM4 wADziajFGcdJR+yXkv3agl/mLC+vugGRlkMTDBXbwVG9qyhI+8Lmgup7UNerikKB Rz+oOzGuAxm35B/WqEHN1okME2WLce7sK1iCUfHscgPAuyz3tbB7B3VuDMLtyisL lDo3IOroI5Xug1u0+dABmuGgEeWb1GsZH059E05dmRMoEicyimFmwAw0YTfmqP0k /e4QhMiEX4xB8GnASByWSAMPR5cDd5FzS1nImcE6Vm/3PfPhWwdFhAWk5irna3iw dzQ4SGt0HH6G5EQKPSFtCkNYOfDDzXNCWFPwDzyppkr0NdpR0vmLOK8ZNW/RiSMJ Rqmsghbecp/ISx+Df1fEnOrOtZY+8NwnyWbe2kVDJnUaxRXnqmm7Jydn1kL0v1dC b9g87wBdMzxR1Wa1qA0elhbR5V8x89XTflrJAzSO+Q7NTEDfnsUTQnbKEMMNIEwT halUzQ3ztbVErZ/pedP4a3zY0VgIMPECFo9aFcJz6zYZUtD+QImNQMyRu3Llibc6 erviQ5ymtEymKsoOSVn0 =Ju4K -END PGP SIGNATURE-
Re: [gentoo-dev] Naming of repositories: gento-x86 edition, bike shedding wanted
Andreas K. Huettel wrote: 0. What names for the tree/repository. gentoo IMO this is the only really accurate name. (it's also the repo_name) There you go. It already has the name gentoo. :) portage doesn't make sense, everything else is too long or potentially confusing... Yes indeed. Rich Freeman wrote: 0. What names for the tree/repository. Suggestions: gentoo-repo gentoo-repository gentoo-main gentoo-repo-main gentoo-repository-main These are all terribly long and fairly redundant. 1. We have some namespaces in Git: proj, dev, priv, data, sites, exp; should the tree be in one of those namespaces, a new namespace, or be without a namespace? git://anongit.gentoo.org/NEW-NAME.git. I'd suggest creating a repository(-ies) namespace (or maybe call it repo(s)), since conceivably we might have more than one at some point, overlays might end up in there at some point, etc. This is a good point. repos/gentoo.git or maybe ebuilds/gentoo.git Kent Fredric wrote: Similarly in the solve confusion as to purpose for newbies: Please be careful to avoid creating simple names for things which are actually more complicated than a simple name can express accurately. That only creates even more confusion. Names need to be accurate and short. It's very difficult to find the right ones and it is an important matter. gentoo-packages No way, packages in Gentoo are .tbz2 files, not .ebuild files. Other distributions already confuse the naming of their packages with the files used to create the packages. Gentoo does not need to be that stupid. gentoo-ebuilds An ebuilds namespace may not be such a bad idea, especially if later on there will be more ebuild repos next to the gentoo one. Manuel Rüger wrote: iirc most deb and rpm based distributions use main for their central repository, so +1 for gentoo-main. Gentoo is significantly different from simple binary distributions - let's not create unneccessary problems by copying their sillyness. Thanks //Peter
Re: [gentoo-dev] find -delete safe to use?
On 14 Mar 2015 23:14, James Le Cuirot wrote: I've long considered the -delete argument to find to be widely supported enough that using it in ebuilds should not be a problem. Indeed, a grep of the tree shows that it is frequently used, even in eclasses. I've just noticed that the man page states that it is not present in the BSD version. findutils is now included in @system, even on BSD, but the ebuild looks as though it gets installed as gfind rather than find. ebuilds may assume GNU findutils On a related note, should I ever include findutils in DEPEND? I've seen some instances of this, occasionally conditional on userland_GNU. On the one hand, it should always be present now, given what I said about @system above but on the other hand, if it gets installed as gfind then there's no point in pulling it in if you're only going to call find. no -mike signature.asc Description: Digital signature
Re: [gentoo-portage-dev] custom profiles?
On 03/14/2015 12:30 PM, Joakim Tjernlund wrote:
On Sat, 2015-03-14 at 11:57 -0700, Zac Medico wrote:
On 03/14/2015 11:41 AM, Joakim Tjernlund wrote:
On Sat, 2015-03-14 at 11:08 -0700, Zac Medico wrote:
On 03/14/2015 09:12 AM, Joakim Tjernlund wrote:
On Wed, 2015-03-11 at 13:43 -0700, Zac Medico wrote:
On 03/11/2015 01:16 PM, Joakim Tjernlund wrote:
On Wed, 2015-03-11 at 10:56 -0700, Zac Medico wrote:
On 03/11/2015 08:48 AM, Joakim Tjernlund wrote:
On Sun, 2015-03-08 at 11:58 -0700, Zac Medico wrote:
On 03/08/2015 10:01 AM, Joakim Tjernlund wrote:
On Sun, 2015-03-08 at 15:47 +, Joakim Tjernlund wrote:
package.use/package.use.force is a bit different though:
cat /etc/portage/package.use/qemu
app-emulation/qemu vde -alsa -pulseaudio -bluetooth -opengl
qemu_user_targets_x86_64
xattr
virtfs
static-
user
#Needed by static-user
sys-libs/zlib static-libs
dev-libs/glib static-libs
sys-apps/attr static-libs
Moving this to package.use/package.use.force does not respect
-alsa, -pulseaudio, -
opengl
all
flags which has a - on them, emerge wants to turn them on again.
Am I missing something?
Using portage 2.2.18
Appears one have to use package.use.mask for that.
cat package.use.mask
app-emulation/qemu alsa pulseaudio bluetooth opengl
It would be handy if one could use the same syntax as in
/etc/portage/package.use/qemu(-
alsa -
opengl
etc.)
Jocke
Yes, the inverted use.mask logic can be confusing if you are not
familiar with it. The
negative
flags
have a
special meaning within the context of of portage's incremental
stacking behavior, so they
can
still
be
useful, though not in the same way that you you attempted to use
them.
Just noticed that USE flags in profiles/package.use.mask override
everything so this
USE=thin emerge -av sys-fs/lvm2
will not turn on thin if thin is in profiles/package.use.mask
How can just change the default so a user can easily turn it on ?
Generally, setting the USE environment variable like that is poor
practice, because the setting will
not
persist the next time that you rebuild the package. So, you should set the
flag in
I know, this was just an example to illustrate that it did not work.
/etc/portage/package.use. You can unmask the flag for lvm2 like this:
echo sys-fs/lvm2 -thin /etc/portage/profile/package.use.mask
You misunderstand, I have sys-fs/lvm2 thin in
/etc/portage/profile/package.use.mask
and I want a user to able to override this setting, using USE=.. or
adding it
to their local /etc/portage/package.use file/dir
There's no other way to negate a use mask than to use
/etc/portage/profile/{use.mask,package.use.mask} as I
have described. I don't think that it makes much sense to negate a use mask
for a single emerge invocation.
If you want to do that, then why is the use flag masked anyway?
I am putting tougher a profile for my company where I want to specify default
USE flags for different apps/libs. Then a user who knows what he/she is doing
should be able to override these defaults. It is not possible as far
as I can tell to override negative USE flags or is there?
You can set default USE flags in the profile, and then the users can
override those settings locally (both positively and negatively). You
should not be using use.mask at all here. The profile can set
USE=-flag in make.defaults, or in packages.use, and the user can
override that without having to mess with use.mask.
--
Thanks,
Zac
[gentoo-dev] Naming of repositories: gento-x86 edition, bike shedding wanted
This is a mostly inconsequential issue, but the Git migration provides us a chance to make a clean break... The repository of our ebuilds and the name of the CVS module have been called gentoo-x86 since the start of Gentoo, because it originally was only for x86. Here's the very first ebuild added to CVS [1], Portage v1.1 is also early on [2]. On the rsync side, it was originally called gentoo-x86-portage, and then between the 1.2 and 1.4 release (early 2003), the stages switched to using the name 'gentoo-portage'; as recently as 2010, various mirrors were STILL fetching from the name of gentoo-x86-portage, when we reminded them that they should have switched years ago. All of these names have caused some confusion. Trying to explain to a new user that the Portage tree refers to the collection of ebuilds used by a PMS-compliant package manager (eg Portage) is problematic. To that end, I'd like us to brainstorm names for the new bikeshed^R^R^R^R^R^R^R^R repository, to go live at the time of the Git migration. It will be the single tree that contains what you find today in the gentoo-x86 CVS module; and on rsync as gentoo-x86-portage and gentoo-portage. Ideally, it should be something that works as a relatively unique identifier (Portage is bad as it refers to both the package manager and the tree), and fits easily into discussions, both in-person and online. Questions: 0. What names for the tree/repository. 1. We have some namespaces in Git: proj, dev, priv, data, sites, exp; should the tree be in one of those namespaces, a new namespace, or be without a namespace? git://anongit.gentoo.org/NEW-NAME.git. [1] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-mail/mutt/mutt-1.2.5-1.ebuild?hideattic=0revision=1.1view=markupsortby=date [2] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-apps/portage/files/ebuild?hideattic=0revision=1.1view=markupsortby=date#l1051 -- Robin Hugh Johnson Gentoo Linux: Developer, Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 signature.asc Description: Digital signature
Re: [gentoo-dev] Naming of repositories: gento-x86 edition, bike shedding wanted
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 proj/gentoo would be fine for me (with the same logic as in the wiki that Gentoo is the main project) Personally I would find this a bit confusing so I'd prefer a separate namespace or no namespace, if going for a separate namespace it might allow for sub-trees down the road, etc... Correct, sorry, I completely over-read that. No namespace, top level would really be best. We only have one main tree!!! - -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0 iQJ8BAEBCgBmBQJVBLmaXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwNzlCRDk4QzA4RENBRkYzQUEwRjQzMDlF QkU2QTMzNkJFMTkwMzlDAAoJEOvmoza+GQOcsZsQAN1X/2rwh/C5g6Hgisza9p0K 79AnaAW5mqunO6LWUtlzowBXvzneiXy3Hp8i7g7H09qRTuWMBnLTiUMErkE6pPxt dCSMogiLyAx5NaWmB6BBbrZqrCz529/3jQD5lUL/SIBOXJzSBBLsbJ8NBMrLYHl5 +jre5FYgje/rEpyZUNU3tlmmB6BCSNXEFPHWYMHkvWmwE+Z2lAMLUAAYUT24SJ3X HyAxznn+NHL7N/RbW8rbhw4pjlis+DZFoHSfAtavdsxY0jleRWA9AHq/xDG9Chez tK6ilISITfQU6bTpan/ogX9cRSzrn1KTagEV2JiBSF8214IB3z/v8FMUPadDaPzk XvYacw34yfot2lsO8W6zjXdnunknJ5VZInuzF336D50jH7ihHVdDPm4vM/Ku6t3B WOP7aLZT6+6o4AuobrvQopoiNj5EZW957pRpnmlDeSEqBNLYlUk1uZJvhHzQXmDP 61vkKO1PRINu8THwSEwiFQpRmvV8ZTCpjgMIfIzqsZQzuzY5t9d2VPXVBSghxCE/ 9xZg6ahpkcBgxGp5JhB4hdVZi3CYXxNXDeq5yJEe3HTICAqg2CPLBVfWEOurJxHJ lNw9BV8mFQvEqm1KkPLiWnjyHz5+9rXPrkk9Vb2+GrgMJIBsU3/tyl27BYMKhGbT lPcW5oGlb7D6k1e3UP0P =ypEe -END PGP SIGNATURE-
Re: [gentoo-dev] Naming of repositories: gento-x86 edition, bike shedding wanted
On 15 March 2015 at 06:34, Andreas K. Huettel dilfri...@gentoo.org wrote:
imho,
Questions:
0. What names for the tree/repository.
gentoo
(it's also the repo_name)
Our repo is already named gentoo, so this makes the most sense.
But I wouldn't mind gentoo-main either. But then we should also
change the repo_name.
While we are at it, can we change the default location from
/usr/portage to something like /var/repos/${repo_name} then?
--
Cheers,
Ben | yngwin
Gentoo developer
Re: [gentoo-dev] Naming of repositories: gento-x86 edition, bike shedding wanted
Jason A. Donenfeld wrote: Calling it gentoo makes sense, because the entire tree is what makes gentoo. Exactly. And the repo already has this name set in repo_name. But since it's namespaced in ebuilds/ and because ebuilds/ might have other gentoo-official repos too, then perhaps gentoo-main makes more sense. If ebuilds/ only has gentoo-official repos then leading gentoo- is repetitive and redundant, and unlike gentoo simply main is a horrible name. //Peter
Re: [gentoo-dev] Naming of repositories: gento-x86 edition, bike shedding wanted
On 15 March 2015 at 11:37, Rich Freeman ri...@gentoo.org wrote: Suggestions: gentoo-repo gentoo-repository gentoo-main gentoo-repo-main gentoo-repository-main Similarly in the solve confusion as to purpose for newbies: gentoo-packages gentoo-ebuilds The names would be possibly be incorrect under some interpretations, but they'd be clearer to newbies what its for. You could consider a repository to be A collection of packages, and all files that are not packages to be metadata. -- Kent *KENTNL* - https://metacpan.org/author/KENTNL
Re: [gentoo-portage-dev] Portage and Update Security
On Tue, Mar 10, 2015 at 2:15 PM, Vladimir Diaz vladimir.v.d...@gmail.com wrote: Hi, I am a developer in the Secure Systems Lab at NYU. Our lab has collaborated with popular software update systems in the open-source community, including APT, yum, and YaST, to address security problems. More recently, we have been working on a flexible security framework co-developed with the Tor project that can be easily added to software updaters to transparently solve many of the known security flaws we have uncovered in software updaters. We would like to work with The Portage Development Project to better secure the Portage distribution system. I'm not familiar with your work on APT, do you have a link? TUF https://github.com/theupdateframework/tuf#a-framework-for-securing-software-update-systems (The Update Framework) is a library that can be added to an existing software update system and is designed to update files in a more secure manner. Many software updaters verify software updates with cryptographic signatures and hash functions, but they typically fail to protect against malicious attacks that target the metadata and update files presented to clients. A rollback attack is one such example, where an attacker tricks a client into installing older files than those the client has already seen (these older files may be vulnerable versions that have since been fixed). A full list of attacks and weaknesses the framework is designed to address is provided here https://github.com/theupdateframework/tuf/blob/develop/SECURITY.md#security . Our website http://theupdateframework.com/index.html includes more information about TUF, including: papers https://github.com/theupdateframework/tuf/tree/develop/docs/papers and a specification https://github.com/theupdateframework/tuf/blob/develop/docs/tuf-spec.txt. If you want to see how an existing project integrates TUF, there is a standards track proposal https://github.com/pypa/interoperability-peps/blob/master/pep-0458-tuf-online-keys.rst#abstract to the Python community that you can review. A more rigorous proposal that requires more administrative work on the repository, but provides more security protections, is also available https://www.python.org/dev/peps/pep-0480/. We were thinking of submitting a pull request that shows how such an integration would work. So there hopefully won't be much leg work on your end apart from deciding how the system should be configured (key storage, roles, etc.). Would a pull request be of interest? Is there anything you'd like us to say more about? I guess I am less concerned with adding support to portage (which as you note, is likely fairly straightforward) vs actually generating, publishing, and signing the metadata; which you would have convince the infrastructure team to do. Thanks, Vlad P.S. There are Informational http://wiki.gentoo.org/wiki/GLEP:57 and Standards Track http://wiki.gentoo.org/wiki/GLEP:58 GLEPs that reference our work and the security issues that our project addresses, but there hasn't been much recent activity on these proposals. FWIW, I would rather adopt the standard than continue with a gentoo specific thing; but I'm not the guy who is going to implement it. I would recommend talking to the GLEP author (robb...@gentoo.org) -A -- vladimir.v.d...@gmail.com PGP fingerprint = ACCF 9DCA 73B9 862F 93C5 6608 63F8 90AA 1D25 3935 --
Re: [gentoo-portage-dev] Re: running ebuild in src tree
On Thu, Mar 12, 2015 at 10:26 AM, Joakim Tjernlund
joakim.tjernl...@transmode.se wrote:
On Thu, 2015-03-12 at 01:27 +, Duncan wrote:
Zac Medico posted on Wed, 11 Mar 2015 12:03:10 -0700 as excerpted:
On 03/11/2015 11:56 AM, Joakim Tjernlund wrote:
On Wed, 2015-03-11 at 11:34 -0700, Zac Medico wrote:
On 03/11/2015 09:03 AM, Joakim Tjernlund wrote:
When developing code it would be really nice if one could run
your ebuild on that src tree as is(no
fetch, unpack etc.)
The existing convention is to create an ebuild with version
and use one of the live vcs eclasses
such as git-r3 to pull the live sources in the src_unpack
function. In a future EAPI, we plan to add
some features related to this [1].
I think you misunderstand, [1] is not what I want to do(I think):
Got my src working copy and made a few modds, not commitet yet. Now
I just want build/test etc. before
committing and to do that I just run
mytree/overlay/dev-util/myapp/myapp.ebuild compile and voila, my
code is built which I already have in mytree.
Well, you can create a - ebuild that copies your sources from
$directory to $WORKDIR. Maybe use an
environment to configure whether it pulls from a local directory or a
vcs repository.
@ Joakim T:
FWIW, a commonly recommended user-level portage optimization is to point
$PORTAGE_TMPDIR at a tmpfs mount. As long as you have sufficient memory,
that lets all building take place in the tmpfs and thus in memory,
eliminating many read-accesses and
most/all write accesses to permanent storage during the build and
(fake-)install phases.
In addition to speeding up emerge itself, this reduces build-time I/O,
which often becomes the bottleneck
on which other processes may be waiting as well, thus allowing other
processes more efficient access to
permanent storage while emerge is ongoing. Between this and setting
PORTAGE_NICENESS=20, emerge is /much/
better behaved during builds, interrupting other processes much less
and thus letting you carry on with
other things while emerge is doing its thing, with far less interruption.
=:^)
For instance, here I have /tmp as a tmpfs mount (with /var/tmp being a
bind-mount of the same tmpfs), and
in make.conf, have the line:
PORTAGE_TMPDIR=/tmp
Emerge then creates /tmp/portage, and within it, creates the usual cat/
pkg/ build trees, etc, as it
emerges various packages.
Obviously, your sources in permanent storage are going to be cache-copied
into memory as you do the build anyway, and pointing PORTAGE_TMPDIR at
tmpfs then becomes a copy to
(tmpfs) memory only. While that doesn't technically eliminate the
copies (since the read into tmpfs will
cache and you'll have the tmpfs copy as well), it DOES mean most of the
work beyond the initial read into
memory will be memory-only, so you DO eliminate the permanent-storage
copies.
Is that sufficiently close to what you were looking to do? Beyond that,
as Zac suggests, just have the ebuild grab the sources from wherever you
put them as your src_unpack, as at that point it'll be a copy to tmpfs,
and thus take essentially the same
time (or even less since it'll avoid the build-time writes to permanent
storage) as doing the in-place
build directly. Plus, creating a tmpfs mount if necessary, and
setting PORTAGE_TMPDIR, is easy, and
you'll dramatically speed-up normal builds as well. =:^)
No, there can be no copy of sources for what I want. It just gets in the
way having to do that.
Hacks like this seems to work:
I wouldn't really call it a hack either, but whichever ;)
post_src_compile() {
# make it compile every time
rm -f ${PORTAGE_BUILDDIR}/.compiled
}
post_src_install() {
# make it install every time
rm -f ${PORTAGE_BUILDDIR}/.installed
}
#hmm, doesn't seem to be an post_package function
#post_package() {
# rm -f ${PORTAGE_BUILDDIR}/.packaged
#}
src_unpack() {
#dir need to exist
mkdir -p ${S} || die
}
src_compile() {
EBUILDDIR=$(dirname ${FILESDIR})
MYTRUNK=${EBUILDDIR}/../../..
# add sandbox exceptions
addwrite ${MYTRUNK}
cd ${MYTRUNK} || die
cd ${PN}
.
}
I'm a bit curious what sort of workflow you are trying to achieve here is.
Which build artifacts are you looking for; the actual built binaries or the
built package that is merged into the livefs?
If the artifacts are packages, then I think this approach makes some
sense...but otherwise I'd just go into trunk and run the build process
(what does the ebuild gain you here?)
-A
Re: [gentoo-dev] Naming of repositories: gento-x86 edition, bike shedding wanted
ebuilds/gentoo.git or ebuilds/gentoo-main.git Namespacing things in ebuilds/ might be convenient in the future if we pursue other types of official ebuild repositories. Calling it gentoo makes sense, because the entire tree is what makes gentoo. But since it's namespaced in ebuilds/ and because ebuilds/ might have other gentoo-official repos too, then perhaps gentoo-main makes more sense.
Re: [gentoo-dev] Naming of repositories: gento-x86 edition, bike shedding wanted
On Sat, Mar 14, 2015 at 9:44 PM, Jason A. Donenfeld zx...@gentoo.org wrote: Calling it gentoo makes sense, because the entire tree is what makes gentoo. But since it's namespaced in ebuilds/ and because ebuilds/ might have other gentoo-official repos too, then perhaps gentoo-main makes more sense. The thing is, Gentoo is more than a bunch of ebuilds. Certainly they're a HUGE part of Gentoo, but they alone aren't Gentoo. In some sense you could have ebuilds/gentoo.git but then what happens when you clone ebuilds/gentoo.git, website/gentoo.git, and so on? Namespaces are useful to prevent accidental collisions, and for organization, but without getting too crazy with the names I think it is best off when the final name stands on its own reasonably well. It doesn't have to be gentoo-main, but I would prefer to see it not just be Gentoo. -- Rich
Re: [gentoo-dev] Naming of repositories: gento-x86 edition, bike shedding wanted
On Sat, Mar 14, 2015 at 6:25 PM, Robin H. Johnson robb...@gentoo.org wrote: 0. What names for the tree/repository. Suggestions: gentoo-repo gentoo-repository gentoo-main gentoo-repo-main gentoo-repository-main 1. We have some namespaces in Git: proj, dev, priv, data, sites, exp; should the tree be in one of those namespaces, a new namespace, or be without a namespace? git://anongit.gentoo.org/NEW-NAME.git. I'd suggest creating a repository(-ies) namespace (or maybe call it repo(s)), since conceivably we might have more than one at some point, overlays might end up in there at some point, etc. -- Rich
[gentoo-dev] find -delete safe to use?
Hello all, I've long considered the -delete argument to find to be widely supported enough that using it in ebuilds should not be a problem. Indeed, a grep of the tree shows that it is frequently used, even in eclasses. I've just noticed that the man page states that it is not present in the BSD version. findutils is now included in @system, even on BSD, but the ebuild looks as though it gets installed as gfind rather than find. On a related note, should I ever include findutils in DEPEND? I've seen some instances of this, occasionally conditional on userland_GNU. On the one hand, it should always be present now, given what I said about @system above but on the other hand, if it gets installed as gfind then there's no point in pulling it in if you're only going to call find. Can someone please put my mind at rest? :) -- James Le Cuirot (chewi) Gentoo Linux Developer pgpvqUTBQR04i.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Naming of repositories: gento-x86 edition, bike shedding wanted
Rich Freeman wrote: Calling it gentoo makes sense The thing is, Gentoo is more than a bunch of ebuilds. Sure, but the gentoo ebuild repo is just a bunch of ebuilds. Gentoo as name can and should be used elsewhere too of course. Certainly they're a HUGE part of Gentoo, but they alone aren't Gentoo. In some sense you could have ebuilds/gentoo.git but then what happens when you clone ebuilds/gentoo.git, website/gentoo.git, and so on? Keep them in different subdirectories, to reflect the central namespace? Namespaces are useful to prevent accidental collisions, and for organization, but without getting too crazy with the names I think it is best off when the final name stands on its own reasonably well. Always optimize for the common case. What changes more often, ebuilds/ or website/ ? That repo gets to use the pretty name, the other repo gets an uglier one, maybe website/website.git. :) //Peter
Re: [gentoo-dev] Naming of repositories: gento-x86 edition, bike shedding wanted
* Andreas K. Huettel schrieb am 14.03.15 um 23:34 Uhr: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 imho, Questions: 0. What names for the tree/repository. gentoo (it's also the repo_name) +1 My furst idea, too. -- 0x35A64134 - 8AAC 5F46 83B4 DB70 8317 3723 296C 6CCA 35A6 4134 signature.asc Description: Digital signature
[gentoo-dev] Packages up for grabs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Feel free to take over and drop me from metadata.xml, if you're interested: * app-editors/diakonos Description: A Linux editor for the masses * net-wireless/mfoc Description: Mifare Classic Offline Cracker * sys-apps/fwts Description: Firmware Test Suite * sys-apps/fxload Description: USB firmware uploader Cheers, Manuel -BEGIN PGP SIGNATURE- Version: GnuPG v2.0 iQJ8BAEBCgBmBQJVBJ1RXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4MDA1RERERkM0ODM2QkE4MEY3NzY0N0M1 OEZCQTM2QzhEOUQ2MzVDAAoJEFj7o2yNnWNcygIQAKmK3VO4lldVCMvNhW8NpETR /v2FqqRYSLQTDOhx8Qqgv0lLR9zKOd9BrAv/Q7HDKs1iRNJUGYll1eyh+LqaQKjl x0Kv3X9bH9Gz7+PQauYY6v8vrPyAEKDaqekjx6Zr+E19m6sC6wZI6d9sPaXyGB5h GTXDoQj2NlkDcdGwu/H04SuHOq2PNjrfeuI5PnfvH1AVlcmmS3RP/mXcDasAmBX/ Yj4kxS4lvp9rNXlulhtH071cRPRfFeKP8L7slPNDY1tqLJTr5VUatpiupxCcTrGU bgnvedOVLM5JvCcDZ8oEE9JPfpI6s2bpDxbIhuoBqn76L5qdptVDj8AlkIPx6RnG BRGUNPdhiDCoznQy0PVuKt4OHMO3i0aEf+qSe37dTa6UkvV1+ekN0vFDDdTMCVkn u4CWa0EAYRnQRUS8Js1MpoplDHWgeauRHY28mnqdI60ne1WTFADdodWQyvthi5tx IRcTPj/oltckOQe+u9XLG0HNFtVPn16YNQy6AT3E5SnrYNQ9KSWgqjmqa/sia6j6 PVdFXEH8fmg6S4w7RKOisTJExCPh1wv1q2QdwmOqRSO/ghbBuTgMRC62uJoAOTAr o00n7yt8sb3EryfSIWg0brOQ8YoCfzf2w/zyB95DujFRvPfehj/c3lCZ2g0FikSN EUxmqXLfmFkXOOMm7TBX =IqkG -END PGP SIGNATURE-
Re: [gentoo-dev] Naming of repositories: gento-x86 edition, bike shedding wanted
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 imho, Questions: 0. What names for the tree/repository. gentoo (it's also the repo_name) portage doesn't make sense, everything else is too long or potentially confusing... 1. We have some namespaces in Git: proj, dev, priv, data, sites, exp; should the tree be in one of those namespaces, a new namespace, or be without a namespace? git://anongit.gentoo.org/NEW-NAME.git. proj/gentoo would be fine for me (with the same logic as in the wiki that Gentoo is the main project) alternatively a separate namespace, but how to name it? cheers, andreas - -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0 iQJ8BAEBCgBmBQJVBLdhXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwNzlCRDk4QzA4RENBRkYzQUEwRjQzMDlF QkU2QTMzNkJFMTkwMzlDAAoJEOvmoza+GQOch0EP/2HxIk0+k0/7G63BplNZLVvt Rm9sH/q/RRL6IWLlPNGnw+aMtmN1hL2kLJDGnzn6vrimpRqnlWD64dadVSD0IEOY 91JHN5y0XJpeS6UDKl9ibyjDQ/DYPDNGPjbi7r1TLtT1nc6z4prADfwedNizKYax 4rLck9G+VzhO++zrdPPN/3vNKnAet6WLUmzt1HDYeYIRsekWTXtnYFbtaEPmytPi 43V3j/qGKw5FAJIBpG2QwppM8+iGWxUwXNOCCjPJ2wE1W+vcYVaw0We9hKWdqbCP x80MsYb8z3cEQhxscdQiNhWDUSQ1wB43pQHsTTCkdaNbUWDqIsE87G/7b0BjTAzf WqSHWTeGTHAG24xyTOoTngwoSNhsdiLQ13cGPxtNSCUMzgvSb0/W5dhmoMX9/mEy 8vHuhXiBuYxahkxEXhWn0NI13s2IW4RsO1rS452tSWm4a0llX1cT+Cl304eoi8eS wGsuqvjsNXEB1BBf3oAga8nnGbtsvmyzRiclHF2mpb6jy2KKDOEt1PhaVvJG8g7p OoKq1wUDpWJ5BfnI08zy8Lj/48Gf3/TDedTerAWWJo7cYmDUDctRI7YgxIOF8Boh bZFmyy7MaSzdFNnvtNDtilPW09v54RWRn3Okb6luXMuP5k1brc7lgWO77I7wZB1T QZJcU6xdr8BFCJdCd0nD =zyaw -END PGP SIGNATURE-
Re: [gentoo-dev] Naming of repositories: gento-x86 edition, bike shedding wanted
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 03/14/2015 11:34 PM, Andreas K. Huettel wrote: imho, Questions: 0. What names for the tree/repository. gentoo (it's also the repo_name) portage doesn't make sense, everything else is too long or potentially confusing... 1. We have some namespaces in Git: proj, dev, priv, data, sites, exp; should the tree be in one of those namespaces, a new namespace, or be without a namespace? git://anongit.gentoo.org/NEW-NAME.git. proj/gentoo would be fine for me (with the same logic as in the wiki that Gentoo is the main project) Personally I would find this a bit confusing so I'd prefer a separate namespace or no namespace, if going for a separate namespace it might allow for sub-trees down the road, etc... alternatively a separate namespace, but how to name it? maybe repos or tree? - -- Kristian Fiskerstrand Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJVBLhoAAoJEP7VAChXwav6afUH/Ao6oxTeZuKN4x5xYlBOTwOL gWhnHW7yhQ41toi13EAQn8WtKSJdtJIuz81MxXL0AnUFfdspjOZBRfExgkoIUrto EsOAEcrmucPJmO4S2k8WQmg1aFwd9EXzG+Raw8x5x5jQONmufCxI/g6H2RgULqfm F3XKtc2+a3lHWtfmqcmEq7nsS5QBD7HXdN2CBaHkk3J6p0pJ1B6qSkVT8FdBhuJT Q4WHlvvHxg69Ungc9RIGDWp9dDQFpo68zG/A8jXCw4bUgX3zLlE/QOVNAFSsEYOT Gdxr5kEarOedZdIeLfF0OAQIbaeYSkclarO4F4E3BXFgHfA+bm5KwDnhgaFUqQ0= =TRCu -END PGP SIGNATURE-
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles/base: package.use.mask
mr_bones_15/03/09 18:15:22 Modified: package.use.mask Log: hide the qt5 stuff for yabause for now [...] +# Michael Sterrett mr_bones_@g.o (09 Mar 2015) +# Mask qt5 support until qt5 is stable so as to not +# hold up making yabause stable. +games-emulation/yabause qt5 This is not necessary since qt5 is in base/use.stable.mask -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Naming of repositories: gento-x86 edition, bike shedding wanted
On Sat, Mar 14, 2015 at 5:56 PM, Peter Stuge pe...@stuge.se wrote: Andreas K. Huettel wrote: 0. What names for the tree/repository. gentoo IMO this is the only really accurate name. I completely agree (with everything else in this email as well).
Re: [gentoo-portage-dev] custom profiles?
On Fri, 2015-03-13 at 10:51 -0700, Zac Medico wrote: On 03/13/2015 05:08 AM, Joakim Tjernlund wrote: On Thu, 2015-03-12 at 17:51 -0700, Zac Medico wrote: On 03/12/2015 02:43 PM, Joakim Tjernlund wrote: Why is --dynamic-deps=y default? This feels like lying about your true deps, I am probably missing something here, an example would be great:) It's a legacy behavior, since portage has always behaved this way, and ebuild developers have relied upon it (resulting in broken dependency calculations without it). Here is odd difference: emerge --dynamic-deps=n changed-deps=y -a1 vanilla-sources ... Nothing to merge That's normal, because --changed-deps implies --selective (a number of options do this). If you add -- selective=n to the above command, you'll get the same result regardless of the --changed-deps option. I just did a sync and emerge -aNDu --dynamic-deps=n --changed-deps=y --selective=n world and again portage wanted to rebuild 150 pkgs. --selective=n seems to be the culprit, should I expect this from --selective=n ? Yes --selective=n is the opposite of --noreplace, so for the above command, it will rebuild everything in /var/lib/portage/world. hmm, this kind of a bummer --dynamic-deps=n implies --changed-deps=y which implies --selective=n and this makes the whole world to rebuild. Using just --dynamic-deps=n was not really safe if I understood corretly? Jocke
Re: [gentoo-portage-dev] custom profiles?
On Wed, 2015-03-11 at 13:43 -0700, Zac Medico wrote: On 03/11/2015 01:16 PM, Joakim Tjernlund wrote: On Wed, 2015-03-11 at 10:56 -0700, Zac Medico wrote: On 03/11/2015 08:48 AM, Joakim Tjernlund wrote: On Sun, 2015-03-08 at 11:58 -0700, Zac Medico wrote: On 03/08/2015 10:01 AM, Joakim Tjernlund wrote: On Sun, 2015-03-08 at 15:47 +, Joakim Tjernlund wrote: package.use/package.use.force is a bit different though: cat /etc/portage/package.use/qemu app-emulation/qemu vde -alsa -pulseaudio -bluetooth -opengl qemu_user_targets_x86_64 xattr virtfs static- user #Needed by static-user sys-libs/zlib static-libs dev-libs/glib static-libs sys-apps/attr static-libs Moving this to package.use/package.use.force does not respect -alsa, -pulseaudio, -opengl all flags which has a - on them, emerge wants to turn them on again. Am I missing something? Using portage 2.2.18 Appears one have to use package.use.mask for that. cat package.use.mask app-emulation/qemu alsa pulseaudio bluetooth opengl It would be handy if one could use the same syntax as in /etc/portage/package.use/qemu(-alsa - opengl etc.) Jocke Yes, the inverted use.mask logic can be confusing if you are not familiar with it. The negative flags have a special meaning within the context of of portage's incremental stacking behavior, so they can still be useful, though not in the same way that you you attempted to use them. Just noticed that USE flags in profiles/package.use.mask override everything so this USE=thin emerge -av sys-fs/lvm2 will not turn on thin if thin is in profiles/package.use.mask How can just change the default so a user can easily turn it on ? jcoke
Re: [gentoo-portage-dev] custom profiles?
On 03/14/2015 05:55 AM, Joakim Tjernlund wrote: On Fri, 2015-03-13 at 10:51 -0700, Zac Medico wrote: On 03/13/2015 05:08 AM, Joakim Tjernlund wrote: On Thu, 2015-03-12 at 17:51 -0700, Zac Medico wrote: On 03/12/2015 02:43 PM, Joakim Tjernlund wrote: Why is --dynamic-deps=y default? This feels like lying about your true deps, I am probably missing something here, an example would be great:) It's a legacy behavior, since portage has always behaved this way, and ebuild developers have relied upon it (resulting in broken dependency calculations without it). Here is odd difference: emerge --dynamic-deps=n changed-deps=y -a1 vanilla-sources ... Nothing to merge That's normal, because --changed-deps implies --selective (a number of options do this). If you add -- selective=n to the above command, you'll get the same result regardless of the --changed-deps option. I just did a sync and emerge -aNDu --dynamic-deps=n --changed-deps=y --selective=n world and again portage wanted to rebuild 150 pkgs. --selective=n seems to be the culprit, should I expect this from --selective=n ? Yes --selective=n is the opposite of --noreplace, so for the above command, it will rebuild everything in /var/lib/portage/world. hmm, this kind of a bummer I don't understand your motivation for using --selective=n with that command. Isn't the command useful without it? --dynamic-deps=n implies --changed-deps=y which implies --selective=n and this makes the whole world to rebuild. No, don't use --selective=n. I only mentioned it in order to explain the behavior that you observed. Using just --dynamic-deps=n was not really safe if I understood corretly? It's safe, but you may need --changed-deps in order for your dependency calculations to work (depends on how the dependencies of your installed packages have changed). -- Thanks, Zac
Re: [gentoo-portage-dev] custom profiles?
On 03/14/2015 09:12 AM, Joakim Tjernlund wrote: On Wed, 2015-03-11 at 13:43 -0700, Zac Medico wrote: On 03/11/2015 01:16 PM, Joakim Tjernlund wrote: On Wed, 2015-03-11 at 10:56 -0700, Zac Medico wrote: On 03/11/2015 08:48 AM, Joakim Tjernlund wrote: On Sun, 2015-03-08 at 11:58 -0700, Zac Medico wrote: On 03/08/2015 10:01 AM, Joakim Tjernlund wrote: On Sun, 2015-03-08 at 15:47 +, Joakim Tjernlund wrote: package.use/package.use.force is a bit different though: cat /etc/portage/package.use/qemu app-emulation/qemu vde -alsa -pulseaudio -bluetooth -opengl qemu_user_targets_x86_64 xattr virtfs static- user #Needed by static-user sys-libs/zlib static-libs dev-libs/glib static-libs sys-apps/attr static-libs Moving this to package.use/package.use.force does not respect -alsa, -pulseaudio, -opengl all flags which has a - on them, emerge wants to turn them on again. Am I missing something? Using portage 2.2.18 Appears one have to use package.use.mask for that. cat package.use.mask app-emulation/qemu alsa pulseaudio bluetooth opengl It would be handy if one could use the same syntax as in /etc/portage/package.use/qemu(-alsa - opengl etc.) Jocke Yes, the inverted use.mask logic can be confusing if you are not familiar with it. The negative flags have a special meaning within the context of of portage's incremental stacking behavior, so they can still be useful, though not in the same way that you you attempted to use them. Just noticed that USE flags in profiles/package.use.mask override everything so this USE=thin emerge -av sys-fs/lvm2 will not turn on thin if thin is in profiles/package.use.mask How can just change the default so a user can easily turn it on ? Generally, setting the USE environment variable like that is poor practice, because the setting will not persist the next time that you rebuild the package. So, you should set the flag in /etc/portage/package.use. You can unmask the flag for lvm2 like this: echo sys-fs/lvm2 -thin /etc/portage/profile/package.use.mask Or umask it globally like this: echo -thin /etc/portage/profile/use.mask -- Thanks, Zac
Re: [gentoo-portage-dev] custom profiles?
On Sat, 2015-03-14 at 10:58 -0700, Zac Medico wrote: On 03/14/2015 05:55 AM, Joakim Tjernlund wrote: On Fri, 2015-03-13 at 10:51 -0700, Zac Medico wrote: On 03/13/2015 05:08 AM, Joakim Tjernlund wrote: On Thu, 2015-03-12 at 17:51 -0700, Zac Medico wrote: On 03/12/2015 02:43 PM, Joakim Tjernlund wrote: Why is --dynamic-deps=y default? This feels like lying about your true deps, I am probably missing something here, an example would be great:) It's a legacy behavior, since portage has always behaved this way, and ebuild developers have relied upon it (resulting in broken dependency calculations without it). Here is odd difference: emerge --dynamic-deps=n changed-deps=y -a1 vanilla-sources ... Nothing to merge That's normal, because --changed-deps implies --selective (a number of options do this). If you add -- selective=n to the above command, you'll get the same result regardless of the --changed-deps option. I just did a sync and emerge -aNDu --dynamic-deps=n --changed-deps=y --selective=n world and again portage wanted to rebuild 150 pkgs. --selective=n seems to be the culprit, should I expect this from --selective=n ? Yes --selective=n is the opposite of --noreplace, so for the above command, it will rebuild everything in /var/lib/portage/world. hmm, this kind of a bummer I don't understand your motivation for using --selective=n with that command. Isn't the command useful without it? I have it my default emerge options --dynamic-deps=n implies --changed-deps=y which implies --selective=n and this makes the whole world to rebuild. No, don't use --selective=n. I only mentioned it in order to explain the behavior that you observed. Using just --dynamic-deps=n was not really safe if I understood corretly? It's safe, but you may need --changed-deps in order for your dependency calculations to work (depends on how the dependencies of your installed packages have changed). I am trying to find out what to put in emerge default options and this may need does relay compute in terms of default options. Does --dynamic-deps=n only work reliable with emerge -NDu world ? Jocke
Re: [gentoo-portage-dev] custom profiles?
On Sat, 2015-03-14 at 11:08 -0700, Zac Medico wrote: On 03/14/2015 09:12 AM, Joakim Tjernlund wrote: On Wed, 2015-03-11 at 13:43 -0700, Zac Medico wrote: On 03/11/2015 01:16 PM, Joakim Tjernlund wrote: On Wed, 2015-03-11 at 10:56 -0700, Zac Medico wrote: On 03/11/2015 08:48 AM, Joakim Tjernlund wrote: On Sun, 2015-03-08 at 11:58 -0700, Zac Medico wrote: On 03/08/2015 10:01 AM, Joakim Tjernlund wrote: On Sun, 2015-03-08 at 15:47 +, Joakim Tjernlund wrote: package.use/package.use.force is a bit different though: cat /etc/portage/package.use/qemu app-emulation/qemu vde -alsa -pulseaudio -bluetooth -opengl qemu_user_targets_x86_64 xattr virtfs static- user #Needed by static-user sys-libs/zlib static-libs dev-libs/glib static-libs sys-apps/attr static-libs Moving this to package.use/package.use.force does not respect -alsa, -pulseaudio, -opengl all flags which has a - on them, emerge wants to turn them on again. Am I missing something? Using portage 2.2.18 Appears one have to use package.use.mask for that. cat package.use.mask app-emulation/qemu alsa pulseaudio bluetooth opengl It would be handy if one could use the same syntax as in /etc/portage/package.use/qemu(-alsa - opengl etc.) Jocke Yes, the inverted use.mask logic can be confusing if you are not familiar with it. The negative flags have a special meaning within the context of of portage's incremental stacking behavior, so they can still be useful, though not in the same way that you you attempted to use them. Just noticed that USE flags in profiles/package.use.mask override everything so this USE=thin emerge -av sys-fs/lvm2 will not turn on thin if thin is in profiles/package.use.mask How can just change the default so a user can easily turn it on ? Generally, setting the USE environment variable like that is poor practice, because the setting will not persist the next time that you rebuild the package. So, you should set the flag in I know, this was just an example to illustrate that it did not work. /etc/portage/package.use. You can unmask the flag for lvm2 like this: echo sys-fs/lvm2 -thin /etc/portage/profile/package.use.mask You misunderstand, I have sys-fs/lvm2 thin in /etc/portage/profile/package.use.mask and I want a user to able to override this setting, using USE=.. or adding it to their local /etc/portage/package.use file/dir Or umask it globally like this: echo -thin /etc/portage/profile/use.mask
Re: [gentoo-portage-dev] custom profiles?
On 03/14/2015 11:35 AM, Joakim Tjernlund wrote: On Sat, 2015-03-14 at 10:58 -0700, Zac Medico wrote: On 03/14/2015 05:55 AM, Joakim Tjernlund wrote: On Fri, 2015-03-13 at 10:51 -0700, Zac Medico wrote: On 03/13/2015 05:08 AM, Joakim Tjernlund wrote: On Thu, 2015-03-12 at 17:51 -0700, Zac Medico wrote: On 03/12/2015 02:43 PM, Joakim Tjernlund wrote: Why is --dynamic-deps=y default? This feels like lying about your true deps, I am probably missing something here, an example would be great:) It's a legacy behavior, since portage has always behaved this way, and ebuild developers have relied upon it (resulting in broken dependency calculations without it). Here is odd difference: emerge --dynamic-deps=n changed-deps=y -a1 vanilla-sources ... Nothing to merge That's normal, because --changed-deps implies --selective (a number of options do this). If you add -- selective=n to the above command, you'll get the same result regardless of the --changed-deps option. I just did a sync and emerge -aNDu --dynamic-deps=n --changed-deps=y --selective=n world and again portage wanted to rebuild 150 pkgs. --selective=n seems to be the culprit, should I expect this from --selective=n ? Yes --selective=n is the opposite of --noreplace, so for the above command, it will rebuild everything in /var/lib/portage/world. hmm, this kind of a bummer I don't understand your motivation for using --selective=n with that command. Isn't the command useful without it? I have it my default emerge options --dynamic-deps=n implies --changed-deps=y which implies --selective=n and this makes the whole world to rebuild. No, don't use --selective=n. I only mentioned it in order to explain the behavior that you observed. Using just --dynamic-deps=n was not really safe if I understood corretly? It's safe, but you may need --changed-deps in order for your dependency calculations to work (depends on how the dependencies of your installed packages have changed). I am trying to find out what to put in emerge default options and this may need does relay compute in terms of default options. Right, options that imply --selective are not well suited for EMERGE_DEFAULT_OPTS unless you also put --selective=n in EMERGE_DEFAULT_OPTS, and then use --selective just for the commands that require it. As an alternative, we can add support for command-specific default options, as discussed here: https://bugs.gentoo.org/show_bug.cgi?id=540250#c1 Does --dynamic-deps=n only work reliable with emerge -NDu world ? No, it's well suited for EMERGE_DEFAULT_OPTS. It's just that you may find that you encounter dependency conflicts for some calculations unless you use --changed-deps. I use --changed-deps for all of my world updates. -- Thanks, Zac
