Re: [gentoo-portage-dev] custom profiles?
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. So now I got to binary pkgs and profiles, the profile is typically part of ebuild src tree/overlay and a system using only binary pkgs does not need ebuild sources. How does one manage profiles is this case? Just sync an empty /usr/portage tree(sans profile) or is the a better way? Jocke PS. emerge --depclean refuses to clean a system which is lagging behind, would it be possible for --depclean to go ahead anyway somehow? --dynamic-deps=n comes to mind.
[gentoo-portage-dev] Re: RFC: emerge manpage options categorization
Kent Fredric posted on Thu, 12 Mar 2015 15:23:59 +1300 as excerpted: On 12 March 2015 at 15:19, Duncan 1i5t5.dun...@cox.net wrote: Comments? A less radical change would be some sort of tagging notation on each feature to indicate their usage. That way, it doesn't impede the current audience who expects to be able to browse the list alphabetically. ( I suggest this, because restructuring it radically will have potential bikeshed drama of people not liking the new layout, so tag-style metadata makes the levels visible without requiring a restructure ) Tags would be less radical, indeed, and an improvement from current, agreed. But as envisioned, the alphabetic order of all options (including those listed in the other sections, as I mentioned in the original proposal) would be maintained in the all options section, precisely because it remains useful to have an alphabetically ordered full-reference section. Tho as proposed, that all-options section may /optionally/ be moved into its own manpage, with an explicit note to that effect in the main manpage. Among other things that would avoid an already long manpage made longer by repeated option descriptions. But I don't feel strongly enough about such a split to make it a big deal if others don't like the idea, the the optional qualifier. IOW, people that didn't like the new layout could simply refer to the all- options section or separate manpage for the old alphabetically-ordered full reference layout, which should hopefully reduce resistance dramatically. =:^) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
[gentoo-portage-dev] Re: RFC: emerge manpage options categorization
Alexander Berntsen posted on Thu, 12 Mar 2015 12:25:31 +0100 as excerpted: On 12/03/15 03:19, Duncan wrote: Comments? Sure. Patches welcome. LOL. I was expecting that[1]. =:^) While I don't know the (presumably) roff markup I've seen in the manpage patches, it'd definitely be useful to learn (and it seems a more realistic goal than say learning C), and I'm not opposed to doing so and then doing the work myself. However, particularly since I /would/ have to learn the markup before actually coming up with the patches, it's still worth an RFC before-hand, to see if it's worth the trouble. If people are wedded to the current layout... Presumably if it is judged to be worth pursuing, the debate on what precise sections to use, and whether the all-options section should be split to its own manpage, can continue while I work on learning the markup. --- [1] ... and privately speculating on how long it'd take to get that response. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-portage-dev] Re: running ebuild in src tree
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:
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}
.
}
[gentoo-portage-dev] ROOT=/usr/src/initramfs emerge -ave busybox cause host rebuilds
ROOT=/usr/src/initramfs emerge -ave busybox givs [ebuild R ] app-arch/xz-utils-5.0.8 USE=nls threads -static-libs [ebuild R ] sys-libs/zlib-1.2.8-r1 USE=-minizip -static-libs [ebuild R ] virtual/libintl-0-r1 [ebuild R ] sys-libs/ncurses-5.9-r3 USE=cxx unicode -ada -debug -doc -gpm -minimal -profile -static-libs -tinfo -trace [ebuild R ] sys-devel/gnuconfig-20140728 [ebuild R ] app-arch/bzip2-1.0.6-r6 USE=-static -static-libs [ebuild R ] virtual/libiconv-0-r2 [ebuild R ] sys-libs/timezone-data-2014j USE=nls -right_timezone [ebuild R ] sys-devel/binutils-config-3-r3 [ebuild R ] sys-libs/zlib-1.2.8-r1 to /usr/src/initramfs/ USE=-minizip -static-libs [ebuild U ] sys-libs/timezone-data-2014j [2014g] to /usr/src/initramfs/ USE=nls -right_timezone [ebuild R ] sys-devel/gcc-config-1.7.3 Notice how emerge wants to rebuild stuff in host(ROOT=/) This does not sit right with me, ROOT=/ is completely up to date and the is no USE flags that ha changed. Jocke
Re: [gentoo-portage-dev] ROOT=/usr/src/initramfs emerge -ave busybox cause host rebuilds
On 03/12/2015 10:39 AM, Joakim Tjernlund wrote: ROOT=/usr/src/initramfs emerge -ave busybox givs [ebuild R ] app-arch/xz-utils-5.0.8 USE=nls threads -static-libs [ebuild R ] sys-libs/zlib-1.2.8-r1 USE=-minizip -static-libs [ebuild R ] virtual/libintl-0-r1 [ebuild R ] sys-libs/ncurses-5.9-r3 USE=cxx unicode -ada -debug -doc -gpm -minimal -profile -static-libs -tinfo -trace [ebuild R ] sys-devel/gnuconfig-20140728 [ebuild R ] app-arch/bzip2-1.0.6-r6 USE=-static -static-libs [ebuild R ] virtual/libiconv-0-r2 [ebuild R ] sys-libs/timezone-data-2014j USE=nls -right_timezone [ebuild R ] sys-devel/binutils-config-3-r3 [ebuild R ] sys-libs/zlib-1.2.8-r1 to /usr/src/initramfs/ USE=-minizip -static-libs [ebuild U ] sys-libs/timezone-data-2014j [2014g] to /usr/src/initramfs/ USE=nls -right_timezone [ebuild R ] sys-devel/gcc-config-1.7.3 Notice how emerge wants to rebuild stuff in host(ROOT=/) This does not sit right with me, ROOT=/ is completely up to date and the is no USE flags that ha changed. Jocke Yes, this has already been reported: https://bugs.gentoo.org/show_bug.cgi?id=239114 -- Thanks, Zac
Re: [gentoo-portage-dev] custom profiles?
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. -- Thanks, Zac
Re: [gentoo-portage-dev] custom profiles?
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
Re: [gentoo-portage-dev] RFC: emerge manpage options categorization
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/03/15 03:19, Duncan wrote: Comments? Sure. Patches welcome. - -- Alexander berna...@gentoo.org https://secure.plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlUBd6kACgkQRtClrXBQc7WWiQD9H2aUo2mkl1e8NxZ5LFM4xPXq AyfDA3D1MpevRTXGQ7EA/RRSfUQXncb+vQAYYtEBFAEOhYFapj4PHJSt9bFZsgE+ =MONi -END PGP SIGNATURE-
[gentoo-portage-dev] [PATCH] dispatch-conf.conf: less-opts --quit-if-one-screen for bug 501886
From: Marc Schiffbauer msch...@gentoo.org Use --quit-if-one-screen instead of --QUIT-AT-EOF, so that less doesn't quit automatically when the user has scrolled to the bottom. X-Gentoo-Bug: 501886 X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=501886 Signed-off-by: Zac Medico zmed...@gentoo.org --- cnf/dispatch-conf.conf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cnf/dispatch-conf.conf b/cnf/dispatch-conf.conf index 125b7cc..7efce8a 100644 --- a/cnf/dispatch-conf.conf +++ b/cnf/dispatch-conf.conf @@ -31,7 +31,7 @@ diff=diff -Nu '%s' '%s' pager= # Default options used if less is the pager -less-opts=--no-init --QUIT-AT-EOF +less-opts=--no-init --quit-if-one-screen # Diff for interactive merges. # %s output file -- 2.3.0
