[gentoo-portage-dev] Re: [PATCH] portage.output: Replace darkblue colors with teal
Dale posted on Sat, 4 Dec 2021 10:01:00 -0600 as excerpted: > As a user, I like the new color. I to use a black background and the > dark blue is hard to see. I've also had to either copy and paste > elsewhere or change the default color of Konsole. I might add, every > console, the ctrl+alt+F1 console, that I have ever seen is also black. > > As a user, +1 for the change. If it is OK, +10. FWIW I've long had my own color.map here, needed on a standard VT but useful in a terminal as well. The new teal default seems a lot more sane to me. Tho unfortunately color.map can't solve the entire problem due to some output not being color-settable in color.map. See bug #759820. While I filed that during a now-fixed konsole bug that made things (much!) worse, the fact that not all colored portage output can be color-set in color.map remains. Hopefully that's being looked at as well, but that doesn't change the fact that an improved default color.map, as here, is useful too. =:^) -- 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: [PATCH] lib/_emerge/actions.py: warn on missing /run
Sam James posted on Thu, 7 Oct 2021 04:19:48 +0100 as excerpted: [space-munged for wrap] > + msg = "It seems that %s is not mounted. You have been warned." % path Maybe something less vaguely ominous than "You have been warned."? I'm supposing for /proc the repercussions are process priority and/or lifetime management, and for /run, locking. So maybe: "Portage locking and/or process lifetime and priority management may malfunction." Or simpler/briefer to still fit on a single line with the "It seems..." sentence: "Process management may malfunction." Omitting "that" after "It seems" to shorten further, the longer /proc case would result in: It seems /proc is not mounted. Process management may malfunction. Nicely under the target 70 chars. =:^) -- 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: [PATCH 2/2] lib/_emerge/resolver/output_helpers.py: explicitly state 'all satisfied'
Sam James posted on Sat, 2 Oct 2021 21:11:56 +0100 as excerpted: > This makes things a bit less confusing and tries to avoid users focusing > on (soft) blocks which aren't actually the problem they're hitting. I was pleasantly surprised by that "all satisfied" earlier today. Thanks. I could get my brain around the old format but this is /so/ much nicer! =:^) -- 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: Ebuild - portage variable names
Boris Vinogradov posted on Tue, 27 Nov 2018 21:13:35 +0300 as excerpted:
> I use gentoo about 8 year. I already try to write ebuild for my package
> but I think it's difficult to everyone who do it in the first time.
>
> Because ebuild have strange short name for common portage variable such
> as {P}, {PV}, {PN} etc. Another developers use these modified variables
> with name and preffix MY, for example {MY_P}, {MY_PV}. I think it isn't
> readable because everyone who read and write ebuilds sometime may be
> foget their means.
>
> I propouse to use human readble variable names for portage variables,
> such as {PATH} instead {P}, {PACKAGE_N}/{PACKAGE_NAME} instead {PN},
> etc... Human isn't a computer who knowns evething point of
> https://devmanual.gentoo.org/ebuild-writing/variables/index.html and
> other portage internals.
>
> I think it's major for everyone gentoo developer because ebuild is face
> of portage system and main component of gentoo unique feature.
It's worth noting that ebuilds conform to a gentoo common standard called
Package Management Specification (PMS), which defines ebuild-critical
variable names such as {P}, {PV}, etc, and that there are package
managers other than portage which along with portage depend on ebuilds
conforming to this standard or they will fail to function correctly.
Updates to this standard are usually done via defining new EAPIs, with
EAPI=7 being the current latest (tho note that while all officially
approved APIs have been sequential numeric, EAPIs are specifically not
required to be numeric, a historic experimental EAPI was named 5-hdepend,
for instance). Ideas for a new EAPI are proposed and discussed,
generally with a preliminary approval by the Gentoo council before
implementation in portage (as the defined PM reference implementation),
after which a final council approval is required before the new EAPI is
allowed to be used in the Gentoo tree.
So to propose human-readable standard var names you'd need to propose the
change as part of a new EAPI and get it approved as such, but of course
the existing EAPIs would remain in use for some time, so developers would
continue to need to know the existing EAPI vars until they are fully
deprecated and all ebuilds containing them are removed from the tree.
And honestly I must say I'm a bit skeptical, in part because in the
decade and a half I've been a gentooer (user not dev) myself, I've not
seen this sort of proposal before, so I suspect most devs must get
comfortable with the existing short vars pretty quickly, and would resent
the "churn for no good reason" and consequent relearning a wholesale
switch to "human readable" would mean for them. So I doubt its chances
at approval... tho I wouldn't really mind being proven wrong on this
point if you're up for the longer term drive to approval it'd take,
because...
As for me personally, as another user, when I'm working on modifying
ebuilds and don't remember the specifics of a standard var or function, I
open the ebuild (5) manpage in another VT or terminal window, and use it
for reference.
Another alternative is the app-doc/pms "Gentoo Package Manager
Specification" package, which contains the specific standards definitions
along with a nicely printable quick-reference card listing which EAPIs
define what. I have that installed too, as I suspect most devs and
advanced users doing ebuild work do, tho as I mentioned I personally tend
to find the ebuild (5) manpage easier for a quick lookup, and only tend
to use PMS when I'm checking details not in the ebuild (5) manpage or I
need the specific wording of the agreed PMS standard.
--
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] Improving Gentoo package format
Francesco Riosa posted on Sun, 11 Nov 2018 17:05:37 +0100 as excerpted:
> Il giorno dom 11 nov 2018 alle ore 09:29 Michał Górny
>
> ha scritto:
>
>> On Sat, 2018-11-10 at 09:37 -0500, Alec Warner wrote:
>>> On Sat, Nov 10, 2018 at 8:09 AM Michał Górny
>>> wrote:
>> [...]
>>>> My proposal ===
>>>>
>>>> Basic format
>>>> The base of the format is a regular compressed tarball.
>>>> There's no junk appended to it but the metadata is stored
>>>> inside it as /var/db/pkg/${PF}. The contents are as compatible
>>>> with the actual vdb format as possible.
>>>>
>>>>
>>> Just to clarify, you are suggesting we store the metadata inside
>>> the contents of the binary package itself (e.g. where the other
>>> files that get merged to the liveFS are?) What about collisions?
>>>
>>> E.g. I install 'machine-images/gentoo-disk-image-1.2.3' on a machine
>>> that already has 'machine-images/gentoo-disk-image-1.2.3' installed,
>>> won't it overwrite files in the VDB at qmerge time?
>>
>> Portage will obviously move the files out, and process them as
>> metadata.
>> The idea is to precisely use a directory that can't be normally part
>> of binary packages, so can't cause collisions with real files (even if
>> they're very unlikely to ever happen).
>>
>>>> This has the following advantages:
>>>>
>>>> + Binary package is still stored as a single file.
Breaking these down into RFC style MUST/SHOULD/MAY levels (as already
suggested elsewhere), for me, this is...
SHOULD/MAY
(Would be a MAY, nice to have, but the existing solution has it, thus
arguably raising the priority to SHOULD.)
>>>> + It uses a standard compressed .tar format, with minimal
>>>> customization.
MUST
(Losing the existing functionality here would be horrible. FWIW I
routinely use binpkgs as a reference, for "clean" config files, comparing
install trees of old and new versions, etc. Having tools that allow
browsing standard compressed tar archives as virtual extensions to the
filesystem makes that a breeze. =:^)
>>>> + The user can easily inspect and modify the packages with standard
>>>> tools (tar and the compressor).
MUST
(As pointed out, portage itself already does this when doing binpkg
moves, etc. Losing that would be horrible!)
>>>> + If we can maintain reasonable level of vdb compatibility, the
>>>> user can even emergency-install a package without causing too much
>>>> hassle (as it will be recorded in vdb); ideally Portage would
>>>> detect this vdb entry and support fixing the install afterwards.
>>>>
>>>>
>>> I'm not certain this is really desired.
SHOULD/MAY
(I'd say SHOULD, but while possible to emergency-install via untarring
now, portage doesn't do anything with it at all, so the detect and fix
functionality is a bonus, thus arguably lowering it to a MAY.)
>> Are you saying it's better that user emergency-installs a package
>> without recording it in vdb, and ends up with mess of collisions and
>> untracked files?
>>
>> Just because you don't like some use case doesn't mean it's not gonna
>> happen. Either you prepare for it and make the best of it, or you
>> pretend it's not gonna happen and cause extra pain to users.
I think I've had to do this twice in ~1.5 decades, plus once reaching
into the tarball to extract a single file that was broken in a newly
installed glibc, breaking portage (and much of the system, but bunzip
still worked!) so I couldn't undo it using portage.
The first time I didn't know enough to clean up manually, but the second
time (and the reach-in time) I did. It'd *definitely* be nice to have
portage be able to clean up automatically.
> Another option would be to install in a near but not overlapping
> directory,
> example:
> /var/db/pkg/${PF}-binpkg
>
> this way the user that know what to do with that data can play with it,
> also portage could be instructed to stat() that directory and take
> action (halt maybe?) if present.
Idea ++
Detect and fix has already been proposed, but detect and halt with an
error and a pointer to manual fix instructions is arguably already better
than current.
Which suggests an easy implementation split, delaying the "fix" step
until later, if it would complicate the initial implementation too much.
[Bikeshed] I was thinking binpkg-${PF} to emphasize the binpkg part and
group any emergency-installed packages together in an alphabetical
listing. But whichever's easiest for portage to work with, which
probably makes the -bin
[gentoo-portage-dev] Re: [PATCH] emerge: add --changed-deps-report option (bug 645780)
Zac Medico posted on Sun, 28 Jan 2018 22:21:48 -0800 as excerpted: > On 01/28/2018 09:49 PM, Zac Medico wrote: >>> 3) Show a NOTE telling users about --changed-deps=y >> >> This is in the HINT section, which is displayed if both --changed-deps >> and --dynamic-deps are disabled in PATCH v2. > > Actually, the whole report should be suppressed if either --changed-deps > or --dynamic-deps is enabled, so I'll send PATCH v4 for that. This is shaping up quite nicely and by (1) dramatically shortening the original "wall of text" report and (2) aborting the report if no affected packages are in the graph, it's vastly improved from the original. I definitely expect it to be rather helpful here, since I have both --dynamic-deps and --changed-deps off by default, and seeing that list could be /quite/ helpful. Looking forward to it! =:^) My remaining concern, and I'm not sure there's a solution, is that for routine 30-day-plus updaters, the warning could quickly become "routine noise", due to valid no-r-bump exceptions such as the llvm example mgorny provided, which very well /could/ happen often enough to trigger the warning nearly every time for 30-day-plus updaters. Then when it really counts and could help, people will likely be ignoring it. Maybe someone else has an idea, but as I said it's already vastly improved from the original, and I believe usable as-is, now, while I'd have found the original quite irritating by about the third time I saw it, even if also helpful. -- 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: Plan for initial integration of gemato with portage
Michał Górny posted on Wed, 24 Jan 2018 20:58:54 +0100 as excerpted: > W dniu śro, 24.01.2018 o godzinie 12∶54 -0500, użytkownik Alec Warner > napisał: >> >> I think its a bit trickier to control the hook's behavior. For >> instance: >> >> 1) I install portage[rsync-verify]. This installs the hook. >> 2) I end up not liking the hook, I install portage[-rsync-verify] >> 3) Does the hook get config-protected here? > > Keeping config-protected files applies only if the file were modified. > In this case it just gets unmerged. I've just verified that. That's controlled by FEATURES=config-protect-if-modified . Granted, that's enabled by default, but config-protecting unmodified files as well is definitely a user option that should be considered, even if that consideration is simply "users disabling the default get to keep the pieces". Meanwhile, if it's "you keep the pieces if you've messed with the default", that should at least be mentioned in the news item[1], so users can consider whether the risk is worth it if they've had that feature specifically disabled previously. --- [1] New item mention: or the more detailed instructions the news item points to if they get too long to be in the news item itself. -- 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: Is portage (/usr)/bin-merge safe?
Zac Medico posted on Thu, 07 Dec 2017 01:07:21 -0800 as excerpted: > On 12/07/2017 12:37 AM, Duncan wrote: >> Zac Medico posted on Fri, 31 May 2013 22:49:02 -0700 as excerpted: >> >>> On 05/31/2013 10:36 PM, Duncan wrote: >>>> As in subject, is portage bin/usr-bin merge safe? >>>> >>>> It appears most of my clashing files are /usr/bin/* -> /bin/* >>>> symlinks. >>> >>> I haven't tried it, but it should work just fine. Portage has always >>> supported directory symlinks like these. I haven't heard any recent >>> complaints regarding them. >> >> As the attribution says, I'm resurrecting a thread from 2013... >> >> I set up a merged /usr/bin -> /bin (and sbin -> bin, and /usr -> .) >> soon after that, with very few problems, usually ebuilds doing >> unconditional rms in postinst or the like, until recently... >> >> Something recently changed, as now I'm having many more problems, so >> far with four packages, glibc (!!), coreutils (!!), nano, and shadow, >> installing symlinks that ultimately point to themselves. >> > I think the sort order of your root directory changed for some reason. > The order that readdir returns filenames depends on the filesystem > implementation: > > http://man7.org/linux/man-pages/man3/readdir.3.html That's... strange. Back in 2013 might have still been on reiserfs, but I've been on btrfs for awhile now. I wonder what might make it change order? Tho I /did/ somewhat recently upgrade ssds, thus copying the /bin dir and /usr -> . symlink, among other root entries. Obviously back when I first setup the /usr -> . symlink it was the newest entry. Maybe if I delete and recreate it so it's definitely the newest entry again... I have no idea how long it might have been before I came up with the idea to try that on my own. Thanks! I'll (gingerly, I don't like major system breakage!) see if it makes a difference. -- 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: Is portage (/usr)/bin-merge safe?
Zac Medico posted on Fri, 31 May 2013 22:49:02 -0700 as excerpted: > On 05/31/2013 10:36 PM, Duncan wrote: >> As in subject, is portage bin/usr-bin merge safe? >> >> It appears most of my clashing files are /usr/bin/* -> /bin/* symlinks. >> (That's just bin, I've not looked at sbin.) > > I haven't tried it, but it should work just fine. Portage has always > supported directory symlinks like these. I haven't heard any recent > complaints regarding them. As the attribution says, I'm resurrecting a thread from 2013... I set up a merged /usr/bin -> /bin (and sbin -> bin, and /usr -> .) soon after that, with very few problems, usually ebuilds doing unconditional rms in postinst or the like, until recently... [I'll likely file this as a bug as well, but thought I'd post a followup to the old thread here, first. I'm kinda busy troubleshooting the unrelated bug that triggered the coreutils expression of this bug for me, ATM.] Something recently changed, as now I'm having many more problems, so far with four packages, glibc (!!), coreutils (!!), nano, and shadow, installing symlinks that ultimately point to themselves. The glibc one is of course critical as it breaks pretty much the entire system right away, the coreutils set is critical due to the number of frequently used binaries it breaks, and I'm lucky I discovered nano before needing it as a low-dep fallback editor. Being a single-user system I don't so often use passwd, but like nano, it's one of those things that when it's needed, it's REALLY needed. >From my current installmask file: # 2017.1112 glibc: libm-2.*.so due to /usr -> . symlink, # symlink overwrites the lib it points to! INSTALL_MASK=" $INSTALL_MASK /usr/lib64/libm-2.*.so " # 2017.1207 coreutils symlinks that overwrite their binaries INSTALL_MASK=" $INSTALL_MASK /usr/bin/basename /usr/bin/chroot /usr/bin/cut /usr/bin/dir /usr/bin/dirname /usr/bin/du /usr/bin/env /usr/bin/expr /usr/bin/head /usr/bin/mkfifo /usr/bin/mktemp /usr/bin/readlink /usr/bin/seq /usr/bin/sleep /usr/bin/sort /usr/bin/tail /usr/bin/touch /usr/bin/tr /usr/bin/tty /usr/bin/uname /usr/bin/vdir /usr/bin/wc /usr/bin/yes " # 2017.1207 shadow, nano symlinks INSTALL_MASK=" $INSTALL_MASK /usr/bin/nano /usr/bin/passwd " So what changed in portage that previously prevented the /usr/* symlinks from overwriting the non-usr binaries, but now allows the overwrites to go ahead, breaking the system? Note that I ran into the glibc library symlink issue first. I ran into the coreutils issue after a bad upgrade (unrelated, I think) broke X, forcing me back to a backup and I started upgrading a few packages at a time from binpkg, to see which one broke X again. When I got to coreutils, the qmerge phase broke half way thru as a binary was replaced by a symlink to itself. I'm not sure why it triggered in binpkg install but not when I had originally installed it on the system, but it may be due to the fact that I normally run parallel merges so the system is heavily loaded during normal merge, while with the binpkg merge it wasn't, thus implying a race condition of some sort. I discovered the nano and shadow/passwd issues, seeing their binaries were broken symlinks to themselves, when fixing the coreutils issue. I've no idea when they happened. -- 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: [PATCH] emerge: add --autounmask-keep-keywords option (bug 622480)
Zac Medico posted on Sun, 13 Aug 2017 19:27:53 -0700 as excerpted: > On 08/13/2017 07:00 PM, M. J. Everitt wrote: >> Interesting .. I'm sure I shied away from that option for some reason >> ... wonder if zmedico can shed some light on the difference between the >> new options and the old, apart from some added flexibility ... > > The --autounmask-keep-keywords option allows you to adjust the the way > that decisions are made during dependency resolution. > Changes in decision making behavior have a large impact on the resulting > dependency calculation. It can mean the difference between a successful > calculation, and one that produces useless results. > > The --autounmask-write=n option has no influence on the decisions made, > The --autounmask-keep-keywords option gives finer-grained control. This > finer-grained control is only useful in cases where --autounmask=n would > prevent useful configuration changes from being made. Thanks. Clear and succinct. That improved my own understanding as well, particularly the distinction between changing the decisions made, and not changing them, but simply preventing them being automatically written, allowing the user direct control over what's actually written and how. =:^) -- 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: [PATCH] emerge: add --autounmask-keep-keywords option (bug 622480)
M. J. Everitt posted on Mon, 14 Aug 2017 00:37:45 +0100 as excerpted: > My use-case consists of the scenario where I do not *ever* wish Portage > to modify my /etc/portage/package. files, preferring to do > this myself manually with a personal naming scheme which defines which > target packages are causing dependency issues. This would be a rather > cool feature-request for portage itself, but I don't see it being > implemented Any Time Soon™. > > This was why I have enforced --autounmask=n in my EMERGE_DEFAULT_OPTS as > often it causes more harm than good if 'random' entries in > /etc/portage/ starts to cause later issues with updated > library packages (read Perl, Python and any other dev-lang nasties > here). FWIW, my use-case is similar. I don't /ever/ want portage doing automated portage-config changes, because I have my own organization, and I comment every change so I know when, what, why, and there's no way an automated tool (well, perhaps some IBM or Google AI, but...) is going to be able to get that even close to correct enough for my satisfaction.[1] However, I've found the /suggestions/ portage makes with auto-unmask useful, as long as they remain just that, *suggestions*, that I can decide on and write up as I wish. And --autounmask-write=n gets me the best of both worlds. Portage doesn't write changes but still suggests them. If you've not tried it, I suggest you do. Works great for me! =:^) --- [1] Besides, doing it manually means I remember the details I did /not/ put down much more readily, once prompted by the ones I did. Even if an automated version could do it it'd need to write paragraphs in ordered to allow me to make sense of it a year or whatever later, compared to my single line when done manually. -- 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] OT: Screen bragging. Was: [PROPOSAL] Don't split user visible messages across multiple lines
Brian Dolbec posted on Thu, 16 Mar 2017 01:08:30 -0700 as excerpted: >> > We could also increase the max. line length to something like 120 or >> > 130. >> >> I think more people should chime in on that. I use vertical splits for >> the screen when coding, and 120 characters is too long for me, but if >> the preferred width ends up changing to 120 or 130 I can work with it. >> >> > You need to get some large 4K monitors... love them :D I treated myself > to two 28 inch ones during boxing week sales. > My aging eyes love them :) They are so much better than my old 24 inch > 1080p monitors. Those were getting tired/starting to loos clarity along > with my eyes working at them all week long. I now work with larger > fonts which are still physically smaller than my old monitors, but > so much clearer. My eyes don't get nearly so tired as they did with > my other monitors. > > ;) Posting resistance failing... Try a 65-inch 4K with a 48-inch 1080p (now the older monitor, often running youtube full-screen) off to the side. =:^) (They're actually TVs used as monitors via the HDMI input, no actual TV hooked up. Above about 32-inch, TVs tend to be cheaper than stand-alone monitors and of course they're the same 4K high or full-hd lower resolution these days.) Six 1280x1080 working windows three wide by two stacked on the 65" 4k, still set for 96 dpi standard, FreeMono Bold 9.0 in my konsole windows, yields: $ echo $COLUMNS x $LINES 179 x 78 And that's six of those on the 65" 4K, PLUS the full-screen 1080p youtube or whatever window on the 48". =:^) This is the first time I can honestly say I have enough screen space that most of the time I'm not actively using it all. =:^) -- 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: [PATCH v2] emerge: auto-enable --with-bdeps if --usepkg is not enabled (bug 598444)
Michael Orlitzky posted on Sun, 05 Mar 2017 14:44:58 -0500 as excerpted: > On 03/05/2017 02:12 PM, Zac Medico wrote: >> >> Incorrect. >> >> ... >> >> Incorrect. >> >> > I see my mistakes, but maintain that this is confusing =) For the record, I think it's /somewhat/ confusing too, and would prefer your two options... except for the backward compatibility thing, which throws a serious wrench into things if we end up keeping the existing -- with-bdeps option even for a deprecation period, and throws an entirely different wrench into things if we simply ignore backward compatibility and remove it without a deprecation period. Which leaves me at a loss as to which option would be better, killing backward compatibility for an arguably clearer pair of options, or staying with backward compatibility and Zac's confusing, but perhaps the best that can be done given the existing option and backward compatibility, pair of options. Tho for me personally, I've been --with-bdeps=y all the way, since original introduction, and Zac's changes would affect that at all, tho of course I'd have to adjust due to loss of backward compatibility if mjo's options were taken. And there's already portage precedent for "I don't want to have to care, just make it do the right thing unless I tell it otherwise", in other areas, so I think --with-bdeps-auto= seems to be most consistent with the existing pattern, which means, confusing tho it may be, it /does/ result in most people not needing to care, so in the end, even tho I agree it's definitely more complex than I'd wish, I'll have to lean Zac's way on this one. Which effectively surprises even me. I started this post expecting I was going to agree with mjo, but ended up talking myself out of it. -- 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: [PATCH] grabfile_package: support -* in profile "packages" files (bug 610670)
Brian Dolbec posted on Thu, 23 Feb 2017 07:52:15 -0800 as excerpted: > On Thu, 23 Feb 2017 11:53:15 + Joakim Tjernlund > <joakim.tjernl...@infinera.com> wrote: > >> On Thu, 2017-02-23 at 02:52 -0800, Zac Medico wrote: >> > Support -* in order to make it easier to create profiles for minimal >> > systems (especially those built entirely from binary packages). >> >> Would be nice, but I don't get what the "packages" file is? > > > That would be the 'packages' file (list of required packages)that are > required for that specific profile. This patch would allow to override > that packages file to build an image that only contained the minimum > runtime pkgs required to perform the tasks it is suppose to. The idea > being you would not need gcc, automake, ... or even portage or possibly > python. The built image could of course be considered more secure not > having a compiler, etc... not to mention smaller. > > > Zac, looks fine to me. If my understanding is correct, that this lets me get rid of the whole list of specific system-package negations in /etc/portage/profile/packages and replace it with a single -*, in ordered to eliminate @system entirely, I'm all for it! =:^) (I've been running both USE="-* ..." and an entirely negated and thus empty @system set, relying entirely on my own activated USE flags and world_sets list for years now, and this will make it easier both because I won't have that whole @system list to negate individual package atom by individual package atom, and because I won't have to worry any longer about default @system set package atoms changing, thus nullifying my negation and adding them back into my @system set without my knowledge and forcing me to trace down what changed and renegate that package with the new atom, as happened not long ago. Tho I'm not doing it to be particularly minimal, but rather, both to avoid @system's forced merge serialization, which at least used to break portage's parallelization features for a rather significant number of packages, and to be better informed and active in terms of what specific packages I do have on the system.) I'll be looking forward to seeing this in a release. =:^) -- 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: [PATCH] Add emerge --autounmask-continue option (bug 582624)
Zac Medico posted on Fri, 01 Jul 2016 08:35:26 -0700 as excerpted: >> But if you genuinely think this is a good idea, and someone else on the >> team does too, I won't oppose it. We should make sure that we strongly >> discourage its usage for regular users. Perhaps your suggested manpage >> addition already does -- I don't know. > > Yeah, I think the warning message that I've put in the man patch is > pretty good: > >> This option is intended to be used only with great caution, >> since it is possible for it to make nonsensical configuration changes >> which may lead to system breakage. Therefore, it is advisable to use >> ---ask together with this option. Perhaps rename the option so it makes perfectly clear the possible consequences? Something like --autounmask-breakme, or --auto-breakme ? Or alternatively, if there are other arguably dangerous options now or possible in the future, put them all under another option, --breakme, such that if that option isn't there, the otherwise dangerous options only print a warning and die. Then people can read the manpage if they really want to know what it does, but people who haven't, aren't as likely to blunder into it due to the stereotypical "rm -rf .*" type advice. -- 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: [PATCH v2] repoman: declare '-x', '--xmlparse' command line options obsolete
Alexander Berntsen posted on Mon, 23 May 2016 12:56:06 +0200 as excerpted:
> When submitting v2-patches, please submit them in-reply-to=the message
> ID of the original thread.
It isn't mandatory here and many ignore it, but many readers (like me)
and more importantly reviewers find a short, often one-line description
of what changed between versions useful as well. A multi-revision patch
will thus have a mini-changelog of what happened at each revision. While
not mandatory here, it is considered so on many lists including most linux
kernel related lists.
> The patch looks OK, but I don't recall us using the "OBSOLETE" phrase in
> any documentation. Does anybody know any phrase we should be using
> instead, and why we should be using that phrase instead?
>
> Maybe we should pick a term ("OBSOLETE" is fine by me), and make it
> "official" for these situations in the future.
No argument with obsolete here, but as long as the option is still
allowed (even if ignored) for backward compatibility, isn't "deprecated"
the usual term?
Then "obsolete" can be reserved for continued listing (for historical
reasons...) after the option is no longer allowed (whether it directly
triggers an error or simply isn't processed at all, thus likely
triggering an indirect error due to incorrect parsing of other options
and parameters on the command line).
--
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: [PATCH] repoman: declare '-x', '--xmlparse' command line options obsolete
Göktürk Yüksek posted on Thu, 19 May 2016 18:45:29 -0400 as excerpted: > Repoman pulls in lxml unconditionally now and performs metadata checks > by default. This behavior makes these command line options obsolete > since forcing the default makes little sense. Declare them obsolete > instead of removing them for backwards compatibility. I like the general idea, but not the implementation. =:^( Example... > -\fB-x\fR, \fB--xmlparse\fR > -Forces the metadata.xml parse check to be carried out > +\fB-x\fR, \fB--xmlparse\fR (OBSOLETE) Often I'll find some online resource that recommends some command, but I (arguably wisely!) prefer to check the manpage to see what a command and its recommended options actually do, as opposed to just running it. That way, in addition to protecting myself from rm -rf .* type advice as sometimes found online, I learn as I go and can then apply the new knowledge to similar situations, instead of being lost when an arbitrary command copied without understanding doesn't work. Or maybe I'm simply trying to fix an old, poorly documented script that just broke, and am trying to figure out what some command therein actually does. The problem is outdated options with no hint as to what they actually did before they were obsoleted and how to proceed with updating them for use with newer versions. Were they obsoleted by more flexible options so the old version isn't needed but I need to figure out what new option to use and its format? Is that behavior now the default? Was that functionality removed and thus is no longer available? So please, don't just declare it obsolete without saying what it actually did and if it applies, what the current equivalent might be. Doing so is if anything even more frustrating to someone trying to figure out what the option actually did, than removing it from the documentation entirely! So, perhaps (I'm not going to attempt formatting)... --xmlparse (Obsolete, formerly forced a metadata.xml parse check but that's now default behavior.) That way, anyone seeing the option somewhere in old code will still be able to lookup what it did, and know that they can simply mentally ignore that option when mentally tracing the old code in their head and delete it in their updated version, because it's now the default. -- 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: Adding sets to @world in custom profile?
Joakim Tjernlund posted on Tue, 24 Nov 2015 17:24:19 + as excerpted:
> I have created my own set, @cusfpv3, and now I want to include this set
> in @world using my custom profile.
> How can I do that?
>
> I can add it in overlay/sets.conf:
> [CUSFPv3 sets]
> class = portage.sets.files.StaticFileSet
> multiset = true
> directory =
> %(PORTAGE_CONFIGROOT)s${repository:tmv3-target-overlay}/sets/
>
> [world]
> class = portage.sets.base.DummyPackageSet
> packages = @cusfpv3 @profile @selected @system
>
> But then this set becomes active as soon as one add the overlay to a
> machine and I do not want that.
You don't need the set in sets.conf, only in the world_sets file,
/var/lib/portage/world_sets , with the set file itself then in
/etc/portage/sets .
FWIW, my world file (/var/lib/portage/world) is normally entirely empty.
Instead, I have everything that would normally be listed there, listed in
various sets in /etc/portage/sets/*. These are organized by functional
category.
So the world_sets file contains entries like:
@jed.admin
@jed.fonts
@jed.kde.kde-baseapps
@jed.media
...
(JED are my initials. Here, they're used so I can distinguish on sight
my own sets from others, for instance the kde-baseapps sets found in the
kde overlay.)
Then for example the /etc/portage/sets/jed.fonts file:
media-fonts/dejavu
media-fonts/freefont
media-fonts/font-adobe-100dpi
media-fonts/font-bh-100dpi
media-fonts/font-bh-lucidatypewriter-100dpi
media-fonts/font-bitstream-100dpi
media-fonts/font-ibm-type1
But I do occasionally use my world file as a sort of "package purgatory"
for packages I haven't decided for sure whether I want to keep or not,
but still want to protect them from depclean. If I decide to keep them,
they're moved to the appropriate sets file. If not, I simply delete the
entry in world and let depclean do its thing.
--
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: [PATCH] egencache: Delay updating Manifests until all other tasks complete
Alexander Berntsen posted on Fri, 13 Nov 2015 13:17:28 +0100 as excerpted: > On 12/11/15 16:00, Michał Górny wrote: >> their generation should be run as the lask task done by egencache, >> followed only by timestamp update. > Is "lask" supposed to be "last"? Also, "last except not last" is not > very good English. The word you seem to be looking for is "penultimate". > (Which would make the "only" redundant.) FWIW, while "penultimate" is unarguably correct, it's also in some regional dialects (US at least) rather rare and high-register, and is in fact a newish (within the year, and I'm nearing 50) addition to my own vocabulary. The more common wording I'm far more familiar with, to the point of defining penultimate in terms of it in "the dictionary in my head", is "next-to-last". [After checking...] Wictionary seems to agree, saying penultimate is British, in US it's considered formal/literary/scholarly, what I termed high register. It defines penultimate in terms of next to last (or more archaic, last but one, tho in the US that's now seen as a Britishism too, see usage notes) as well. (Meanwhile, I seriously can't picture /anyone/ using "propreantepenultimate" except as a joke!) -- 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: How to have several gentoo repos on one machine?
Joakim Tjernlund posted on Thu, 22 Oct 2015 06:48:06 + as excerpted: > On Thu, 2015-10-22 at 02:29 +0000, Duncan wrote: >> Joakim Tjernlund posted on Wed, 21 Oct 2015 11:08:02 + as >> excerpted: >> >> > I need to more than one gentoo repo in my computer. >> > this did not work as "portageq repositories_configuration /" >> > complains: >> > !!! Section 'tm-cusfpv3' in repos.conf has name different from >> > repository name 'gentoo' set inside repository >> > >> > I figured the name in repos.conf would just override >> > /usr/local/portage/tm-cusfpv3/profiles/repo_name ? >> >> While it's not quite clear to me either why you'd need two identical >> gentoo repos[...] > > I use one for my host and the other for cross building our products root > FS and they are not in sync. That rules out the aliases I guess? I think so, yes. However, as a user I'd really like to understand aliases, their purpose, and at high level how they work, and the current manpage doesn't help so much there. Without that I really don't know enough about aliases to say anything further. But meanwhile, I was sort of in your situation for awhile as I was building for my main amd64 system and in a 32-bit chroot for a 32-bit- only netbook, with a separate portage config for each, and while in my case they both pointed at the same gentoo repo and overlays using bind- mounts into the 32-bit chroot, without those bind-mounts it would have been two parallel and separate portage installations, one configured for 32-bit x86 in the chroot, one configured for amd64 outside the chroot. And that's what I'd use in your case, two separate portage installations, which could then of course have separate configs. That said, while I understand the principle of stability, and if it's private there shouldn't be legal issues, I still wonder at the idea. One of the reasons I could and did use bind-mounts and thus literally the same repos in my case, was that the gentoo repo is the gentoo repo, and other than the possibility of snapshotting it for archiving purposes (and of using one of those snapshots should it be needed, say because I left the netbook unupgraded for too long and it could no longer jump from the version on it to current), I considered the gentoo repo the gentoo repo, and a local copy that wasn't synced would no longer represent the present state of the gentoo repo. If I were to un-sync for other than very temporary recovery purposes, I'd thus want to call the repo something other than gentoo, since it would no longer represent the current state of the true gentoo repo. And if I made changes to that unsynced repo, say to stabilize it further (and if I wasn't doing so, what would be the purpose of keeping it unsynced for so long), that'd be even /more/ reason to call it something other than gentoo, because then it would no longer properly represent that state of the true gentoo repo at /any/ time. But having the git repo available changes the way that works dramatically, see below... > I don't plan on renaming anything in the repo_name file, it should just > be ignored and the name I have select in repos.conf should used. > > I don't see any value in repo_name file now that we have the new > repos.conf, possibly it could be a fallback only for PORTDIR users. The portage devs are welcome to contradict me if they like, but AFAIK, it still serves the useful purpose of double-checking that you don't for instance have two repos accidently syncing to the same place, and that the names used to refer to the repo stay consistent. (Again, part of the need for consistency would be due to the metadata and thus metadata cache being repo-specific, automatically invalidating the cache if the remote name and local name don't agree. Locally regenerating the metadata cache will go a long way to avoiding that problem, but it's an expensive operation that most users won't want to do, and keeping the names in sync helps avoid inadvertent cache invalidation.) >> I actually use gentoo's git-based usersync >> repo on github, now, and thus don't rsync any repos all any more, here, >> and git of course has its git-ignore feature/files, which I use now. >> But I used rsync's exclude as suggested above, for years. Worked fine. >> =:^) > > Nice, I am heading the same was, using git all the way but I not there > yet. > One problem is that using git is disk space I think. Files are just > ignored but still present in the repo so syncing to our embedded target > will take a lot more space. > Any thoughts on that? Well, at least once your trailing target (presumably the embedded repo) is safely past the git repo's epoc (the date imported from cvs, for our purposes), git flexibility will let you checkout older vers
[gentoo-portage-dev] Re: @sets and @profile does not work when ROOT=PORTAGE_CONFIGROOT=/my/new/root
Zac Medico posted on Thu, 22 Oct 2015 11:54:39 -0700 as excerpted: > On 10/22/2015 11:29 AM, Joakim Tjernlund wrote: >> On Thu, 2015-10-22 at 08:54 -0700, Zac Medico wrote: >>> For example, the default set configuration located at >>> /usr/share/portage/config/sets/portage.conf does something similar >>> with %(PORTAGE_CONFIGROOT)s. >> >> Nice! I am a bit puzzled over the trailing s in ..)s, is that a typo? >> if not what does it mean? > > The trailing s is required. It's python configparser interpolation > syntax: > > https://docs.python.org/3/library/configparser.html#interpolation-of-values Thanks. That's a pattern I now recognize and identify elsewhere. =:^) And that recognition/identification presumably answers a low-priority (thus never asked) question I've had for some time about layman.conf, and what/why it uses variable interpolation with the same trailing s, which I hadn't understood until now. For me, the answer is now essentially "the trailing 's' is an artifact of the python implementation and its use of the configparser lib, and yes, it's necessary, and doesn't mean the path now needs a literal trailing 's' as well." Again, thanks. Seeing similar trailing-s usage should be way less confusing now. =:^) -- 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: How to have several gentoo repos on one machine?
Joakim Tjernlund posted on Wed, 21 Oct 2015 11:08:02 + as excerpted: > I need to more than one gentoo repo in my computer. > > So I add to repos.conf: > [tm-cusfpv3] > auto-sync = yes > sync-type = rsync > sync-uri = rsync://devsrv.transmode.se/tm-cusfpv3 > location = /usr/local/portage/tm-cusfpv3 > > this did not work as "portageq repositories_configuration /" complains: > !!! Section 'tm-cusfpv3' in repos.conf has name different from > repository name 'gentoo' set inside repository > > I figured the name in repos.conf would just override > /usr/local/portage/tm-cusfpv3/profiles/repo_name ? While it's not quite clear to me either why you'd need two identical gentoo repos (and if they're not identical, why is the non-gentoo- official mirror still using the gentoo name?) or exactly what this config- line does, the aliases= attribute, along with force=aliases, in repos.conf, may be what you're looking for. See the portage (5) manpage, repos.conf section, attributes supported in sections of repositories subsection, under aliases and force. Unfortunately, the description for aliases is anything but clear, tho the usage (including comment) further down in the example subsection does help some. If that doesn't help, then while the portage devs may have some other suggestions, the workaround that occurs to me is to use rsync's exclude/ filter options, so rsync ignores that file and doesn't sync it. I do[1] that with a few custom files/dirs that I don't want synced, and rsync ignores them just as I told it to. =:^) See the rsync (1) manpage, --exclude, --exclude-from, --include, -- include-from and --filter=RULE options, as well as the filter rules, include/exclude pattern rules, and anchoring include/exclude patterns sections. However, be prepared to spend a bit of time studying, as these options are very powerful/flexible/configurable and thus take some time to figure out. Once you have rsync ignoring the repo_name file, you can rename it as you like. However, do be aware that (as the repos.conf force option docs mention) messing with this is very likely to invalidate the pre-generated metadata cache, and if you don't regenerate it (egencache), portage will take a *VERY* long time figuring stuff out, *MUCH* longer than usual, as it won't have the benefit of the metadata cache for that repo. Which again has me asking why you need two separate gentoo repos. Either they're identical and the one should suffice, or the unofficial one should be named something other than gentoo. In fact, at least in theory, in addition to all the headaches not using a different name is forcing on users, that's potentially trademark violation if it's publicly available, different from the official gentoo mirror, and yet still calling itself gentoo. --- [1] rsync exclude options: I actually use gentoo's git-based usersync repo on github, now, and thus don't rsync any repos all any more, here, and git of course has its git-ignore feature/files, which I use now. But I used rsync's exclude as suggested above, for years. Worked fine. =:^) -- 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: [PATCH] emerge(1): document --oneshot caveats (bug 563482)
Zac Medico posted on Wed, 21 Oct 2015 12:26:11 -0700 as excerpted: > Yeah, and if you run emerge --depclean regularly, then it will prevent > problems like these. Thanks, Zac. I should be covered then, since I both consistently run --deep, and consistently --depclean after updates. =:^) (And now I understand the interaction between not running --deep, and --oneshot, as well. =:^) -- 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: gentoolkit.git repository reorganized
Alexander Berntsen posted on Tue, 20 Oct 2015 10:34:36 +0200 as excerpted: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 15/10/15 19:42, Paul Varner wrote: >> Over the last couple of days, I have done the following: >> >> 1. Migrated the gentoolkit-dev branch to its own gentoolkit-dev.git >> repository 2. Moved the gentoolkit branch to master on the >> gentoolkit.git repository > Why did you not just make gentoolkit master, and leave gentoolkit-dev as > a branch? That's certainly the common way of using git. Because gentoolkit-dev is a different package with a different purpose, not a development/pre-release version of gentoolkit. gentoolkit-dev is a separate collection of gentoolkit-like scripts, but targeted at devs, where the original gentoolkit scripts are targeted at normal users. Putting the entirely separate package in an entirely separate repo does make sense, altho some devs do apparently prefer to keep multiple packages in the same repo (see udev with systemd, to mention one rather controversial example). -- 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: [PATCH] emerge(1): document --oneshot caveats (bug 563482)
Rob Wortman posted on Tue, 20 Oct 2015 17:37:37 -0700 as excerpted: > On 2015-10-20 at 21:44:58 +0200, berna...@gentoo.org wrote: >> (since it's describing somewhat complicated functionality) > > So, I'm curious what's actually going on there. If I emerge packages > with --oneshot, does that create the possibility of broken dependencies > for world-reachable packages, or does updating @world create the > possiblity of broken dependencies for oneshot'ed packages? AFAIK, the latter. @world's dep-calc doesn't take into account anything beyond what's in @world (which by definition includes @system and, where appropriate, @profile). So @world should be safe, but packages not in it or deps of what's in it aren't accounted for and both won't be updated, and could be unmerged if the depgraph that portage calculates for @world works most directly by doing so. They won't be unmerged unless they're simple-blockers to something, however; that's what depclean is for. It's just that portage doesn't account for them in the depgraph, either, and thus might "accidentally" unmerge them. Meanwhile, the suggestion that --update --deep avoids the problem is most interesting to me, since all my normally used update-everything scripts have included --deep for nigh on a decade, now, while my normally used named-merge scripts have included --oneshot, since back in the day I didn't want to inadvertently pollute my world file with manually merged deps, and these days I don't even have an @world file, only a world_sets file, which names the various sets I've grouped the contents of both my former @world file and my former @system set (which is nullified, no @system packages at all, here, with everything I decided I actually needed in @world). Plus, I reasonably commonly use merged but not assigned to a set packages as a sort of temporary package purgatory, for testing until I've decided I either like the package enough to keep, in which case I add it to the appropriate set as named in @world_sets, or I don't, in which case I simply run depclean and it cleans up both the package and any deps that only it pulled in, without cleaning up anything else, since I always run depclean in --ask mode after an update, simply to keep my system free of any detritus. But I'm not sure of the avoidance mechanism, since for all I knew, without @world pinning them in, portage's depgraph didn't include them and that was that, --deep or not. So the connection between --deep and --oneshot is new to me, and I'd love to know more about the implications. -- 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: [PATCH] man/ebuild.5: Update description of =* operator.
Brian Dolbec posted on Tue, 22 Sep 2015 08:09:06 -0700 as excerpted: > On Tue, 22 Sep 2015 16:45:38 +0200 Alexander Berntsen > <berna...@gentoo.org> wrote: > >> On 22/09/15 16:27, Brian Dolbec wrote: >> > But, I wonder if the change had a bug side effect...causing him the >> > grief >> It appears the "problem" is that he can't exploit an old bug. So it's >> actually the opposite. >> > hey, I'm still waking up ;) I went over the previous emails/patch. > Yeah, I see it clearly now. He was splitting the date suffix, which the > whole date is considered as one boundary zone. Second hand as I don't do IRC (tho the date string example was specifically mentioned on the big dev thread a couple times, and I was as a result surprised to see the "bug fix" here without so much as a mention that if the date string thing worked it was only by accident, as it was always exploiting a bug...) But as a workaround, has anyone suggested the obvious... 2015.0922 ? I find 2015.0922 visually easier to parse than 20150922, in any case, and in fact routinely do break it down into four-digit substrings here, as extensions for dated backups of various critical config files, etc. -- 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: Portage questions
Joakim Tjernlund posted on Wed, 16 Sep 2015 13:13:40 + as excerpted: > Is there a way to generate a snapshot of an installed portage VDB and > then later compare that snapshot against the current VDB and generate > a list of added/updated packages? That one is either relatively simple, or I'm not understanding your question. Portage's installed package database, vdb, is located at /var/db/pkg/. It's organized as a category/package-version tree, much like the normal gentoo packages tree, except that the package dir names have the version appended (and of course there's no profile/metadata/etc subdirs). Most files in the individual pkg-ver dirs are plain text, tho the environment file is compressed (bz2 here, tho it's possible that's configurable, IDK). So a snapshot of vdb should be as simple as tarballing /var/db/pkg. You should then be able to untar it somewhere and do a recursive diff or whatever, to compare the freshly unarchived version against the existing one and get your list of added/updated packages based on the diff. The other question I didn't (as a user not a dev) understand. I'd need a fuller explanation (it feels like I came in half way thru the story and missed something critical, which has me wondering if I'm missing something on the first one too, since it seemed so simple, thus the remark above to that effect), but it's possible a dev will understand better and be able to answer. -- 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: Up the email communication!
Alexander Berntsen posted on Mon, 01 Jun 2015 23:15:09 +0200 as excerpted: Friends, It would be advantageous [TLDR summary: Agree with the point but nearly deleted as spam.] At that point I was double-checking for spam: 1) Vague, spammy, subject. 2) Vague, almost too formally collegial Friends greeting. 3) It would be advantageous? In a non-spam mail? Don't see /that/ sort of formal distant wording very often... except in spam! But maybe my mailing circle is significantly different than yours. shrug On the counter-spam side, how many spammers would be (true or fake) gpg-signing? I've learned to ignore that for quick reads (tho could of course verify if I needed to and thus appreciate the value), but saw it once I was second-looking, and that was enough to convince me to read further, at which point I saw that the mail was legit. On topic, meanwhile, not that a non-dev opinion counts for too much, but FWIW, agreed with the point. I don't do IRC so seeing the acks, etc, on- list, would make it easier for me to follow too. =:^) -- 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
Mike Frysinger posted on Tue, 02 Jun 2015 10:47:59 -0400 as excerpted: On 12 Mar 2015 13:52, Duncan wrote: 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. i think splitting the content between two man pages is a pretty bad idea. would be kind of easy to get duplicate content, and even if there was a one line note at like the top, people would miss it. Thanks. FWIW I have parts of this thread marked to followup later, so comments can still be useful if I actually do so (no promises). -- 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: Dynamic USE dependencies
Brian Dolbec posted on Fri, 03 Apr 2015 06:31:27 -0700 as excerpted: On Fri, 3 Apr 2015 11:52:39 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: Brian Dolbec posted on Thu, 02 Apr 2015 23:59:06 -0700 as excerpted: enalyze is little known to users. I'd never heard of enalyze before Please consider writing up a tips-n-tricks section feature for enalyze in an upcoming gentoo news Been there, done that... ;) https://blogs.gentoo.org/news/2014/03/ brown paper bag I read that issue too. But I think I was running on about four hours sleep in three days (OK, maybe six hours, eight if you count dozing on the bus and lunch break... obviously not enough!) when I did... Given the evidence, I guess read isn't the appropriate word... I /slept/ /thru/ that issue??? I /sleep-read/ that issue??? Anyway, thanks. =:^) -- 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: Dynamic USE dependencies
Rich Freeman posted on Thu, 02 Apr 2015 22:26:03 -0400 as excerpted: If you stuck -* in your make.conf then this change would have no affect at all, since you've explicitly set the configuration of every use flag. That (and package.use still sticking) eases my mind considerably. The current configuration forces you to use config files to capture settings you care about, and also ones you don't actually care about, and unless you're careful you'll have trouble telling these settings apart later. It is like sticking every installed package in your world file. That comparison is quite persuasive, indeed. =:^) Thanks! I understand your idea much better, now, and (cautiously) agree. =:^) (Tho FWIW, I guess I'm a careful one. I use -* and put non-global USE flags in make.conf too if possible, and review USE flags for all new packages and changes, so everything there is cared about for one reason or another. Package.use thus contains only individual package exceptions, and I comment those with both a date and why they /are/ exceptions to the otherwise global policy, so if the only justification is because package X requires it, that's in the comment. Make.conf's USE= setting does still accumulate unannotated stale flags over time, but I just went thru and verified all USE flags were still used recently, deleting the ones that equery hasuse didn't raise a hit on, and justifying either by-name or by equery uses every remaining entry, so everything there is verified there for a reason now, too.) -- 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: Dynamic USE dependencies
Rich Freeman posted on Thu, 02 Apr 2015 12:32:41 -0400 as excerpted: Out of curiosity, what is keeping us from having USE flag dependencies handled dynamically, in the same way that package dependencies are? If portage can figure out that I need libxml2 installed even if I don't put it in /var/lib/portage/world, why can't it figure out that I need it built with USE=icu even if I don't put that in /etc/portage/package.use? Because USE flags are binary, with not-yes implying no, while world set listings are binary, with not-yes implying do it anyway if needed? OK, so the USE flag not-yes implied no /is/ a bit weak, packages omit the USE flag if they (or their maintainer) actually require the feature and simply hard-require what would otherwise be toggled by the USE flag, but by that same token, the very fact that the USE flag exists makes it an option for the admin that would toggle the flag, strengthening the USE flag's implied-no of the not-yes, and in any case, it's still *far* stronger than the do-it-anyway-if-needed of simply not listing a package in the world set. Meanwhile, there is of course a way to have no for a world listing, put it in package.mask. Similarly, there'a a way to enforce an explicit no for that implied by a USE not-yes, by setting USE=-* at the beginning, and users who eventually get tired of having to worry about profile changes meaning implied USE flag changes, etc, may well eventually set it, as I did. But that doesn't change the basic difference in what not- yes is implied to mean in the two cases. Changing the implied meaning of not-yes to match in both cases could certainly be done, but while I'm not opposed if the justification really is there, I think there's the potential here for a rather massive change in base assumptions, and if that is indeed what's involved, I believe it'd call for equally massive justifications. OTOH, maybe you're thinking something a bit more incremental, which would accordingly require lower justification. I'm just a bit worried... ... And I /still/ don't like that --ask, implies that I think it's OK for portage to write to my package.* files (even with config-protection), if I accidentally hit enter. When the danger was simply that a package merge that would take some time and thus could easily be aborted, that was IMO reasonable. The new situation is IMO far more borderline. I'd be a whole lot more comfortable if some EMERGE_DEFAULTs parameter could be set to turn off portage's writing to package.* entirely, while keeping the old --ask package-merging /and/ use-flag/mask/keywording SUGGESTION behavior. And I'm worried that the suggestion here is going further down that emerge writing its own config path, without (IMO) appropriate safeguards. -- 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: running ebuild in src tree
Joakim Tjernlund posted on Thu, 12 Mar 2015 17:26:59 + as excerpted: No, there can be no copy of sources for what I want. It just gets in the way having to do that. ?? Copying to tmpfs is copying to memory, and copying to memory in /some/ form must occur in ordered to operate on the files at all, that is, with any build at all, so I don't see the problem, at least if you're working on a machine with say 2+ gigs RAM. (There might be problems on a half-gig RAM machine, but that's not particularly appropriate as a developer machine in any case, these days, unless you're talking embedded, which you didn't mention.) But of course, gentoo/portage lets you do it your way too, as demonstrated by the hacks you posted. =:^) -- 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: running ebuild in src tree
Joakim Tjernlund posted on Fri, 13 Mar 2015 08:13:01 + as excerpted: When you are developing SW you do the edit/build cycle often and it is really annoying to copy a big src tree, rebuild everything (as timestamps, deps changes), move to another src to do any debugging etc. Try it on your own development by just copying you src tree every time you want to build, you get very tired of it real soon :) That's what ccache is for. For some time I was following live-kde (tho I'm not ATM as kf5 wasn't working for me yet, last I tried, and kde4 development is pretty much dead, now) and doing rebuilds several times a week, so I know what it's like. =:^) But I do get your point, now. Still, unless it's something like firefox, while I used to get irritated with the extra build time back when I was running a dual-core, a quad- core improved that, and with my current 6-core bulldozer-1 (fx6100), PORTAGE_TMPDIR on tmpfs, and the system and ccache on ssd, most of the time I just let it do the rebuild. It's really not worth the trouble worrying about it any more, particularly when I can be doing other stuff while it builds. But you're right, being able to build right in an existing git clone without the hassle of hacks such as you posted, and even configuring live- ebuilds to do just that with say a variable setting that could be set by a package.env pointer, would be nice indeed. Local hacking on such live- build packages would be quite a bit easier, that way. -- 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
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
[gentoo-portage-dev] Re: running ebuild in src tree
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. =:^) -- 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] RFC: emerge manpage options categorization
While looking up something in the emerge (1) manpage, I noticed again its proliferation of options, many of which are for esoteric cases that normal users don't need to worry about for normal usage and some of which (like --rage-clean) are ANTI-recommended, with many others which are arguably best set once in EMERGE_DEFAULT_OPTS and forgotten about. Perhaps it's time to consider further option categorization. Suggested categories: Common Runtime Options Common EMERGE_DEFAULT_OPTS Candidate Options Other Useful Options (optional) All Options The All Options category would be what's currently under Options, basically everything (including the common options) in alphabetical order, intended as an exhaustive options reference. Arguably, this could be split off into its own manpage, emerge-reference or emerge-advanced or some such, with a reference to it in the main manpage. The two common options categories would contain recommended or otherwise known to be commonly used options, that users really should know about, but NOT the more esoteric stuff with sane defaults like --backtrack=count, --misspell-suggestions, etc. Splitting these into common default-options and common runtime would let users find what they're looking for based on task (occasional default-option optimization or this-run tweaking) they're working on. Obviously, some options might end up in both. The other useful options category, if created, would be for less common options that can still be useful from time to time. Arguably, options such as --only-deps, --color and possibly --tree could go here. As such, it'd be a middle-ground between common options and the obscurity of those listed only in all options. I think breaking it down into runtime and default options would be a bit much, but of course (runtime) and (default-opts) notes could be added where appropriate, if considered useful. Arguably, this would let portage devs put portage-dev recommended but politically sensitive options such as --dynamic-deps=n and --changed- deps=y in the common defaults section, while effectively making corner- case and NOT recommended options like --rage-clean a bit harder to find for the ordinary user (particularly if the all-options reference is moved to its own manpage), while still keeping them documented for users that want to explore the portage flexibility they expose. In theory, the actions category could be split up as well, perhaps simply into common and other, but I'm less sure about this idea and consider it less urgent in any case. Comments? -- 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: [PATCH] man/emaint.1: Add entry about the merges module
Pavel Kazakov posted on Sat, 28 Feb 2015 07:50:16 -0800 as excerpted: [snip] While we're on the topic of the emaint manpage, the all (sub)command could use an update. Current: Perform all supported commands. But there's no hint at what commands are included. In particular, with portage's conversion to emaint sync, I was at first worried that all would sync as well, and it doesn't. Additionally, I have my own log rotation setup, and was worried it would trigger emaint's log rotation, but it doesn't. So enumerating what all actually includes could be quite useful. =:^) (I ended up using --check first, to see what it'd do, and found my worries were unfounded.) Similarly, --check and --fix need updated. In particular, --check doesn't appear to apply to all commands any longer as it says it does, and neither --check or --fix appear to apply to sync or log. IOW, the manpage reads like it's rather outdated, having been only barebones-updated for recent additions such that there's now missing and outdated bits. Which I guess is exactly the case... -- 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: [PATCH] emaint.1: Update man page for better clarity
Brian Dolbec posted on Sat, 28 Feb 2015 16:11:56 -0800 as excerpted: As recommended by Duncan on the gentoo-portage-dev list. Clarify the all command. Add OPTIONS to all commands, so a user can determine which modules may run when the 'all' command is used. Remove repetitive '(* command only)' text by adding it to the section header. Thanks. This looks much less confusing and (possibly) much more current. =:^) -- 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: [PATCH 1/2] Add FEATURES=binpkg-multi-instance (bug 150031)
Duncan posted on Wed, 18 Feb 2015 03:40:35 + as excerpted: Reading this gave me a distinct sense of deja vu reading this. ... =:^P Crossed in the mail. Already corrected in the new series. =:^) -- 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: [gentoo-dev] [PATCH] pym/portage/news.py: let slackers copy+paste the news read command
Zac Medico posted on Fri, 30 Jan 2015 00:37:30 -0800 as excerpted: On 01/30/2015 12:14 AM, Jason Zaman wrote: On Thu, Jan 29, 2015 at 11:00:21PM -0800, Zac Medico wrote: Also, when the work read appears twice on a short line like that, it gives a wordy/redundant feeling. Perhaps better would be 'eselect news read' to view new items? ie. view instead of the second read. Yeah, that's much better. View works, or I was going to suggest see, which I'm still partial to over view: 'eselect news read' to see news items. (And FWIW, select/paste vs. type, depends on my mood and the pointing device I'm using. I used to select/paste quite a bit with a trackball, depending on mood, but I'm using a touchpad without physical buttons as my primary pointing device now, and it's more trouble there, so I'd type it as long as the command is short or can be tab-completed, and only select/paste for long ones or those with arbitrary and hard to remember options, possibly even switching pointing devices to do it if I'm not running X and thus don't have the 20-gesture-button programmed flexibility of a well configured xf86-input-mtrack. An text-console evdev-based mtrack driver to parallel the X driver would sure be nice!) -- 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: [PATCH] man pages: note that make.conf can be a directory (463266)
Zac Medico posted on Fri, 26 Dec 2014 22:52:42 -0800 as excerpted: I believe that's why I chose to stick with a make.conf file that simply sourced a bunch of other files, instead of simply making it a directory and sticking all those other files in the dir, when I first read about the possibility. I have scripts myself that simply source make.conf, that I'd have to rewrite with a for loop to process a directory. It's not hard to do, but people haven't had to worry about it and so they haven't. If people aren't thinking about that when they up and make make.conf a directory, they might well wish they had! =8^0 Why don't you use 'portageq envvar'? Thanks for the hint. I will likely use it. =:^) Which hints at half the answer to your question; I didn't really know about it. The other half of the answer is simple. It was never needed before, as sourcing make.conf always just worked. Now that it's needed... Thanks again! =:^) -- 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: [PATCH] man pages: note that make.conf can be a directory (463266)
Zac Medico posted on Fri, 26 Dec 2014 14:01:47 -0800 as excerpted: Commit 86e75790954e766beba75443d967b2c25055c5b0 added support for make.conf to be a directory, but the feature was undocumented. Therefore, update the man pages, as suggested in bug #465164, comment #9. What about other apps that parse make.conf? A note that this might break compatibility with some of them, and/or with other scripts people sometimes post on the forums, lists, etc, could be worthwhile. I believe that's why I chose to stick with a make.conf file that simply sourced a bunch of other files, instead of simply making it a directory and sticking all those other files in the dir, when I first read about the possibility. I have scripts myself that simply source make.conf, that I'd have to rewrite with a for loop to process a directory. It's not hard to do, but people haven't had to worry about it and so they haven't. If people aren't thinking about that when they up and make make.conf a directory, they might well wish they had! =8^0 Most of the others I've made dirs, tho. It's much easier configuring portage that way, and as I said, my make.conf is already just a bunch of source directives, giving me pretty much the best of both worlds. =:^) (Until I add a new configuration file and forget to add a corresponding source line for it in make.conf, as I did recently. =:^( ) I'll eventually do make.conf as well, but it's not worth worrying about changing my scripts until all the packages that reference it are known to handle it. -- 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] New file layout for PKGDIR and binhosts
Zac Medico posted on Wed, 24 Dec 2014 00:13:57 -0800 as excerpted: If there were some way to get all the info for the binpkgs into one file (so it could be run on cron or something), this could mean that I'd only have to do one file request for all that metadata and would be much quicker than inspecting all those files. That's what $PKGDIR/Packages is. This is a good excuse to ask a question that has bothered me for some time, plus make a request for the new eclean-pkg replacement... Normally I like to keep several old binpkgs around for troubleshooting reference or quick-install, but the combined set of kde packages, for instance, can get pretty big, and with monthly iterations, they build up pretty fast. But eclean-pkg doesn't have an easy way to say clean up /just/ kde-base/ *, leaving the currently installed version and one previous version for reference, cleaning out all others. (Sure I could put /everything/ else on the exclude list, but what's really needed is an include list, plus a keep N more option.) So I often end up cleaning packages like that out manually by simply deleting them. My question is thus, does the remaining index/db/cache entry get cleaned properly (when?) or am I leaving uncleanable garbage behind when I do this? Which of course translates into a couple of feature requests for the new eclean-pkg: 1) Make it possible to clean only selected pkgs or categories. 2) Have an option to clean up and/or regenerate the cache/index/db/ whatever files, re-syncing them with what's actually there. Meanwhile, another possible usage for multiple binpkgs per ebuild: I commonly run live-builds (mostly kde, tho I'm not ATM), and would /love/ to be able to keep about three generations (current plus two back) around, ideally IDed by their git-commit or the like. Running live packages can mean even more risk than usual of something not working out, but currently, if the package builds, by the time you find that out, you've obliterated your previous * binpkg and even figuring out which git commit it was isn't easy, let alone doing a quick binpkg rollback, like you'd do with an ordinary version upgrade. Were multiple live- binpkg-versions kept around, IDed by the git-commit or at least with that info in the metadata somewhere, it'd make things /so/ much easier! =:^) But of course that does make having an automated cleaner that can keep just the last N package versions around while deleting the others, that much more important. -- 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] New file layout for PKGDIR and binhosts
Zac Medico posted on Thu, 25 Dec 2014 03:04:20 -0800 as excerpted: FWIW, you can use 'cp -rl $PKGDIR $PKGDIR.backup' to make a hardlink snapshot of $PKGDIR. Portage will break hardlinks whenever it needs to update tbz2 files, so you don't have to worry about updates in $PKGDIR affecting the files in $PKGDIR.backup. Thanks. Your portage knowledge, and more to the point your calm patience explaining its workings and fixing its bugs, always amaze me. =:^) I sure missed it while you were gone and sure am glad you're back, with more help now. =:^) I had overlooked emaint --fix binhost (a hazard for those who have been around long enough to have tools seriously evolve after the original learning period), and hadn't thought at all about hardlinks (or btrfs reflinks, since I'm using it for that partition). I expect I'll find this quite useful. =:^) -- 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: [PATCH] unprivileged mode: generate PORTAGE_DEPCACHEDIR
Zac Medico posted on Sun, 09 Nov 2014 15:24:40 -0800 as excerpted: [...] then automatically make PORTAGE_DEPCACHEDIR relative to the current target root (which should always be writable for unprivileged mode). Why? Why does emerge --pretend need a writable target root in the first place, or it dies a horrible death (traceback)? I keep root read-only by default, making it writable when I'm updating. When I'm simply doing an emerge --pretend, however, whether simply to satisfy my own curiosity or because I'm posting a reply to some other user where the output from emerge --pretend would be useful, why does emerge die a horrible death and traceback, when all I wanted was --pretend output that shouldn't be changing the target root at all and thus shouldn't /need/ a writable target root in the first place? https://bugs.gentoo.org/show_bug.cgi?id=490732 FWIW, $PORTAGE_TMPDIR is writable, as is /run/lock (and thus /var/run/lock). In both tracebacks in the bug, it's a *.portage_lockfile that's not writable. Why are those not in (possibly some subdir of) /run/lock in the first place, or in $PORTAGE_TMPDIR, given the temporary nature of the files? At least for --pretend. -- 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: [PATCH] unprivileged mode: generate PORTAGE_DEPCACHEDIR
Zac Medico posted on Sun, 09 Nov 2014 21:28:15 -0800 as excerpted: The unprivileged mode is similar to existing prefix support. The unprivileged mode is basically useless unless your target root is writable. Therefore, it's a sane assumption. It won't affect you unless you use the new unprivileged mode. If you do happen to use it, then you will probably appreciate this patch. I misinterpreted then, thinking unprivileged mode was simply running as a normal user. Thanks. (And good to see you back... with more help now. =:^) -- 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] Package description index file format for faster emerge search actions
Zac Medico posted on Tue, 14 Oct 2014 00:40:21 -0700 as excerpted: I suggest that we add support for a package description index file format. For example, the attached script will generate a suitable index formatted as series of lines like this: sys-apps/sandbox-1.6-r2,2.3-r1,2.4,2.5,2.6-r1: sandbox'd LD_PRELOAD hack What about homepage? An index for it too? (I found myself so frequently esearching for homepage that I hacked up a script that greps package names and homepages from the esearch results.) -- 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] Package description index file format for faster emerge search actions
Zac Medico posted on Tue, 14 Oct 2014 03:05:35 -0700 as excerpted: On 10/14/2014 02:53 AM, Duncan wrote: Zac Medico posted on Tue, 14 Oct 2014 00:40:21 -0700 as excerpted: I suggest that we add support for a package description index file format. What about homepage? An index for it too? The intent is to use the package name/version as a foreign key that links an entry in the description index to an entry in one of portage's other caches. Thanks. Makes sense now. =:^) -- 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: [PATCH] dblink.mergeme: implement bug #523684
Zac Medico posted on Thu, 25 Sep 2014 20:35:06 -0700 as excerpted: If a CONFIG_PROTECTed file was installed but no longer exists in the file system, then it may have been deleted or renamed by the admin. Therefore, force the file to be merged with a ._cfg name, so that the admin will be prompted for this update. X-Gentoo-Bug: 523684 X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=523684 I've experienced this very problem myself -- no way to config-protect an actual deletion of a file. Back on openrc, I ended up with several initscripts symlinked to a null script that was basically a comment reminding myself to delete the update. I'm on systemd now, and it has the concept of symlinking a unitfile to /dev/null to force-disable it, which helps, but I've seen the problem with a few other files as well over the years, so would love to have this functionality available. Thank you! =:^) -- 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: [PATCH 0/4] Autounmask changes
Alexander Berntsen posted on Wed, 13 Aug 2014 18:56:28 +0200 as excerpted: One thing that needs discussion is what to do with the current behaviour of --autounmask, i.e. printing the suggestions. One thing that was really weird in my original patches (the ones in this thread) is this: emerge foo # this will do what --autounmask does today emerge foo --autounmask # this will do what --autounmask-write does emerge foo -a # this will do what --ask --autounmask-write does emerge foo --autounmask=n # this will do what --autounmask=n does The problem here is that there is no way to do e.g. emerge foo --ask, and get suggestions any longer. You can either have it prompt to write stuff, or you can have it not do anything -- but you can't explicitly have it suggest stuff without prompting to write. This is bad design. So either I need to implement tri-state (--autounmask can be yes, no, suggest), or I need to do something more drastic. This remains my problem with the patches as they are now. * I don't want portage writing mask/use changes on its own under any circumstances, as I use directories and have my own idea of what files I want stuff in. * Never-the-less, I find the suggestions very helpful and indeed, often the easiest way to find out what I need to do. * I routinely use --ask. Currently, --ask assumes yes very easily, simply hit return, and I like that behavior for simple merges as it's convenient and easily enough undone. (With --oneshot by default as well, an errant enter is undone easily enough with a --depclean.) The patches as they are now would change that, giving me no way to still get the suggestions with --ask, without chancing the actual write of those changes. That's particularly bad as the currently convenient behavior of letting a simple enter indicate yes makes it all too easy to actually do those writes I don't want done under any circumstances. While I'm fine with --ask defaulting to (the current) --autounmask-write behavior by default, I need a way to get the current --ask --autounmask (without write) behavior too, even if I need to add --autounmask=suggest or some such to DEFAULTOPTS, because that's /my/ configuration's default behavior, and I want it to stay that way. =:^) So please do implement that tri-state --autounmask=suggest behavior. =:^) The only other /possible/ objection I see is the potential version- dependent confusion over --autounmask behavior. An argument could be made that it might be better to simply kill the --autounmask switch, hard- wiring that behavior, and keep the current --autounmask-write name, simply making it the default while still allowing people to explicitly set --autounmask-write=n. That way, while the remaining --autounmask-write parameter would arguably unnecessarily keep it's longer name, there could be no confusion over the changing --autounmask behavior, since that parameter would simply cease to exist. But I don't feel strongly about that. If people think the confusion over --autounmask changing meaning isn't as big a deal as saving those few extra characters necessary for the longer -write variant, fine with me. -- 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: Signing off patches
Alexander Berntsen posted on Thu, 16 Jan 2014 18:44:57 +0100 as excerpted: On 16/01/14 18:24, Jesus Rivero (Neurogeek) wrote: So, how would this work with emails to this list, exactly? An email should be sent any time one of those fields is changed? That's not necessary, in my opinion. We already send emails, looks OK to me and similar. And most patches don't really need more than one review and an ACK by the lead. Do you have a more detailed plan on how would this work? Not really. We're small enough to do this organically and on a per-case basis. But basically, if someone authors a non-trivial patch, that person should *never* push themselves. Whoever reviews it should push it, adding the Reviewed-by field. The reviewer should also get an ACK by the team lead (via IRC or whatever) and add that to the commit before pushing. On the btrfs list, comments on patches often have wording to the effect: After taking care of those issues, you can add my reviewed-by. Looks fine to me, reviewed-by (or acked-by if more appropriate). If it's a preliminary review/ack, meanwhile, those will be missing. Also, presumably (I don't do IRC) people can get acks (or reviews if there has been more detailed correspondence previously) on IRC. Obviously reported-by doesn't need explicit permission, and tested-by (from a reporter's angle) the same, if it is said to work with the patch. Tested-by done by folks running the regression tests, etc, obviously get explicit permission in the form of their reports on those tests. If there were issues and there's a v2, v3, etc, these include the various bylines as part of the revision. If the patch is considered ready to go as-is, they'll be added at the final commit, which can be made by the author if they have commit access, or a dev with access if not. And one final note: A signed-off-by is a useful indicator of a patch that an author considers ready to go, pending review, etc. Lack of that (from a seasoned submitter who is familiar with the process) can be an indication that the author believes the patch is or may be preliminary, and they're not yet ready for integration-tree inclusion or final review, tho they usually say as much in the patch description as well. -- 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: [PATCHES] Remove --autounmask, rename --autounmask-write to --autounmask
Alexander Berntsen posted on Thu, 21 Nov 2013 10:21:02 +0100 as excerpted: After talking to zmedico privately, and raising the issue and discussing it with people in bug #481578[0], I implemented the behaviour described in a comment[1] on said bug. I sent this to zmedico almost two months ago, but it doesn't look like he's coming back any time soon, so I'm sending it here and ask someone to review and commit it (a role zmedico has typically played for me, as well as being my mentor and guide and so on and so forth for Portage hacking). [0] https://bugs.gentoo.org/show_bug.cgi?id=481578 [1] https://bugs.gentoo.org/show_bug.cgi?id=481578#c10 I'm with zmedico in comment #11, and *STRONGLY* oppose this change as you're proposing. Current autounmask is **NOT** useless. FWIW, I have a very specific portage layout and there's no way dumb automation could put what I'd consider the appropriate write in what I'd consider the appropriate file, nor do I want it to try! (And even if it could do it perfectly, I want to /know/ what my config is, and the best way for me to /know/ my config is if the only way it changes is if I change it myself!) OTOH, current default autounmask (without write) behavior, having portage tell me what (it thinks) I need to unmask and/or what package.use flags it thinks I need is fine, and often quite helpful indeed, as long as it's not actually trying to actually WRITE it anywhere! If I read the above correctly, what you're proposing would kill that behavior entirely if --ask is used, defaulting to writing (fine if it can be turned off), with no way (at least no way with --ask instead of --pretend) to tell portage to make the suggestion it with --autounmask (which is the default now), with absolutely no chance it's going to attempt to actually rewrite my config on its own, period. OTOH, Zac's suggestion, to simply enable autounmask-write by default but allow the user to set --autounmask-write=n if they want, would be just fine, since I could put that in default options and be done with it. Tho even that's a sufficiently drastic change from current behavior that I'd expect a good changelog entry mentioning it, and preferably a news item, as it has the potential to screw up people's configs if they aren't paying attention when the default changes. -- 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: [PATCHES] Remove --autounmask, rename --autounmask-write to --autounmask
Alexander Berntsen posted on Thu, 21 Nov 2013 13:03:36 +0100 as excerpted: On 21/11/13 12:19, Duncan wrote: I'm with zmedico in comment #11, and *STRONGLY* oppose this change as you're proposing. Current autounmask is **NOT** useless. How is it not? Consider comment 6[0] and 10[1]. I read comment 10, and am objecting based on it, because there'd be no way to do what I'm doing currently and which my workflow depends on, which you call irrelevant (below). FWIW, I have a very specific portage layout and there's no way dumb automation could put what I'd consider the appropriate write in what I'd consider the appropriate file, nor do I want it to try! (And even if it could do it perfectly, I want to /know/ what my config is, and the best way for me to /know/ my config is if the only way it changes is if I change it myself!) Irrelevant. OTOH, current default autounmask (without write) behavior, having portage tell me what (it thinks) I need to unmask and/or what package.use flags it thinks I need is fine, and often quite helpful indeed, as long as it's not actually trying to actually WRITE it anywhere! Irrelevant. If I read the above correctly, what you're proposing would kill that behavior entirely if --ask is used, defaulting to writing (fine if it can be turned off), with no way (at least no way with --ask instead of --pretend) to tell portage to make the suggestion it with --autounmask (which is the default now), with absolutely no chance it's going to attempt to actually rewrite my config on its own, period. I don't understand this sentence, but I think you *don't* understand what I am saying. Please read comment 10[1], in which I present examples. 1) Because the dependency calculations take time, I normally use --ask so I don't have to have portage redo those calculations if I like what its telling me it's going to do. 2) Under no circumstances do I want portage rewriting masks, etc, on its own, not even with config-protect. 3) Despite that, I find the suggestions it makes saying what it /thinks/ it needs unmasked useful -- I just want to write them to the file I want, with the comment I want (sometimes with a bit different atom, too), which portage wouldn't do. 4) You're saying emerge --ask foo would write the config, and I don't see any way to turn that off without also turning off portage's suggestion generation as currently controlled by --autounmask (which is on by default), or without switching --ask to --pretend. Your proposal is broken behavior as far as I'm concerned, because I find portage's suggestions (current autounmask) useful, not the entirely useless you seem to think they are without automatically writing them, which I do NOT want portage to do under /any/ circumstances. 5) There needs to be a way to get portage's current emerge --ask --autounmask foo (without --autounmask-write) behavior, because that's /exactly/ what I use and find most useful. But I don't particularly care what the default is since I can configure it as needed, as long as this current behavior remains possible. OTOH, Zac's suggestion, to simply enable autounmask-write by default but allow the user to set --autounmask-write=n if they want, would be just fine, since I could put that in default options and be done with it. Enabling --autounmask-write by default is a terrible idea. It will result in a lot of spam. Furthermore, consider comment 13[2]. I'd tend to agree, but in that case, why are you wanting to do away with the ability to have portage spit out its opinion, without having portage actually do the write, while using --ask? [0] https://bugs.gentoo.org/show_bug.cgi?id=481578#c6 [1] https://bugs.gentoo.org/show_bug.cgi?id=481578#c10 [2] https://bugs.gentoo.org/show_bug.cgi?id=481578#c13 -- 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: [PATCHES] Remove --autounmask, rename --autounmask-write to --autounmask
Alexander Berntsen posted on Thu, 21 Nov 2013 15:23:50 +0100 as excerpted: 4) You're saying emerge --ask foo would write the config No. Please read comment 10[0]. Quoting one example from comment 10: emerge --ask foo would also do what is currently done by: emerge --ask --autounmask-write foo Which is exactly what I said, and what you're now saying it won't do, while pointing at comment 10 which says exactly the opposite. It's that change in behavior based on comment 10 that I'm most protesting, since I depend on being able to tell portage to go ahead with the merges if they look good (thus the --ask), but under *NO* circumstances do I want it writing its changes to the various use/mask files. 5) There needs to be a way to get portage's current emerge --ask --autounmask foo (without --autounmask-write) There is. This doesn't change in my patches. Please read the code or comment 10[0]. I'd tend to agree, but in that case, why are you wanting to do away with the ability to have portage spit out its opinion, without having portage actually do the write, while using --ask? Because it can be done without --ask. See comment 10[0]. The only way you propose to do that in comment 10 is with --pretend, which would be a seriously negative change in behavior for my use-case, since it would require having portage recalculate the dependencies it's just calculated with the --pretend, without it. --ask currently avoids that situation, since when I'm happy with the output, I can simply let it go ahead. [0] https://bugs.gentoo.org/show_bug.cgi?id=481578#c10 -- 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: Is portage (/usr)/bin-merge safe?
viv...@gmail.com posted on Sun, 02 Jun 2013 13:14:41 +0200 as excerpted:
While portage can be safe, for various reason (including the resultant
pkg) I do prefer to do the move in post_src_install() #1 All my tests
have been done against a manually converted filesystem
That's what mine would be...
#1 excerpt from bashrc, this code is rough but work in the gentoo
ebuilds tree domain
move_root_to_usr() {
Thanks. What I was thinking would actually reverse that (/bin being the
real dir, /sbin being a symlink to it), given my (traditional sysadmin)
pref for short paths, but I hadn't thought of a bashrc solution at all,
so that gives me yet another way of doing it. =:^)
My first thought is that I prefer standard layout packages, however,
easing interoperability should I decide to swap binpkgs with someone.
(Yes, I'm aware of the security issues if the parties don't trust each
other...)
But OTOH I think that solves issues such as path-based equery belongs,
for instance. Being amd64 for nearing a decade now (and no-multilib for
several years of it), I'm used to worrying about that with the symlinked
lib/lib64 thing, and that's the one thing I wasn't looking forward to
with unified bins. (I think I'll keep bin/sbin separate at first, see
how bin/usr-bin go first, then think about bin/sbin.)
But if your bashrc solution /does/ solve the equery belongs path thing I
might well use it on lib/lib64 as well... (Either that or since I
believe the libs are a profile thing and I'm already running a heavily
modified profile, no @system for instance, I could probably simply modify
that... Actually, that's probably a better solution in any case, since
it's just undoing mainline settings the same way mainline does them in
the first place.)
--
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] Is portage (/usr)/bin-merge safe?
As in subject, is portage bin/usr-bin merge safe? It appears most of my clashing files are /usr/bin/* - /bin/* symlinks. (That's just bin, I've not looked at sbin.) Does portage just do the right thing if the dirs are linked to each other? Meanwhile, a quick eyeball of the results says 50-60% of the hits are coreutils, so if portage doesn't handle it automatically, fixing it for just that one package, even just using a USE flag instead of trying to detect it automatically, would kill a majority of the birds with a single stone. (Since I don't have a separate /usr anyway, I've been thinking about it... If it's not easily doable anyway, that cuts short the internal debate.) -- 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] app-shells/gentoo-bashcomp needs some portage expert lovin'
Could a number of folks familiar with both portage AND bash completion help out the shell-tools herd (no specific maintainer specified in metadata) with app-shell/gentoo-bashcomp bugs? It seems to have accumulated quite a number (13) of portage-completion (and gentoolkit-completion) related bugs, including bug #424777 filed on July 4th by jer, mentioning that it it breaks with make.conf in /etc/ portage, which is kinda critical right about now. =:^( https://bugs.gentoo.org/show_bug.cgi?id=424777 And here's the list of all open bugs for it. As you can see if you look, all or nearly all of the currently 13 open bugs are portage or gentoolkit related, and it really looks like the package could use some help from those who know those tools. https://bugs.gentoo.org/buglist.cgi?quicksearch=app-shells%2Fgentoo-bashcomp (I said on the devlist thread I'd report bugs, but this one's been open for over two months and is directly related to the make.conf move, so it's a big one, simple fix proposed, but no actual fixes in-tree yet, plus seeing all those others related to portage and gentoolkit, thus the request here.) -- 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: tools-portage packages
Alec Warner posted on Wed, 18 Jul 2012 11:18:53 +0200 as excerpted: * app-portage/esearch [gentoo] None specified I used to maintain this; but I don't see a compelling reason to use it over eix, so I recommend removal. FWIW, I use esearch (heh, just looked up eix with it). I have it embedded in my update script as well, to update its database, and have a few front-ends for it (ehome being the most used), which return just the specified data. So switching to eix if esearch is treecleaned wouldn't be entirely painless, but it shouldn't be overly painful, either. -- 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: Is there any short syntax for REQUIRED_USE when a lot of USE flags need another one enabled?
Brian Harring posted on Sat, 17 Dec 2011 12:12:45 -0800 as excerpted: On Sat, Dec 17, 2011 at 11:24:37AM +0100, Pacho Ramos wrote: I am referring in this case to abiword, it has a plugins USE flag that enables some minimal set of plugins and, then, a lot of USE flags for building extra plugins (with extra dependencies). All of this extra plugins need plugins USE flag to be enabled. Is there any way to write a REQUIRED_USE flag variable without needing to list all USE flags depending on plugins to be set? I think the better question is why you have a plugin use flag if the vast majority of interesting flags require it. What's the gain of having plugin controllable, vs forced on by default (or force on by one of the flags you referenced being enabled)? Indeed, that /is/ a good question. =:^) What about adding USE=minimal to turn off plugins entirely, thus making the default if it's not turned on the basic plugins? That would kill the complicated dependencies for the individual plugin flags and with a package specific description for USE=minimal that says it builds without even the basic plugins, that functionality is preserved for those who really want/need it. -- 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: forcing a USE flag if another is on
Amit Dor-Shifer posted on Wed, 30 Dec 2009 16:45:40 +0200 as excerpted: Is there some method of specifing if USE flag X is enabled, enable USE flag y as-well? Something like a conditional use.force file in profiles/. Amit That should be doable globally using /etc/portage/bashrc or the like ( /etc/portage/profile/bashrc). For specific packages, it's doable using /etc/portage/env/cat-egory/pkgname files, altho that's not so well documented. In any of those cases, syntax is standard bash, so you get the full range of bash conditionals and scripting available to setup your environment as complicated as you wish. (However, it is my understanding that the /etc/portage/env files only get sourced for the bash/ebuild.sh side of portage, not for the python side, so stuff like depchecks and features that are dealt with on the python side, won't necessarily work as expected. Test it if in doubt... or put it in one of the bashrcs, with a conditional so it's only applied to the package in question.) -- 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: sets remove support replacement?
Zac Medico posted on Wed, 18 Nov 2009 23:36:28 -0800 as excerpted: There's no replacement for it yet, so yes, for now that seems like the best option if you need such fine-grained control. Thanks. Done. =:^) -- 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] sets remove support replacement?
I noticed that sets remove support wasn't working any longer, when depclean all of a sudden decided most of kde4 was no longer in world! A bug search reveals http://bugs.gentoo.org/show_bug.cgi?id=291414 which references http://bugs.gentoo.org/show_bug.cgi?id=253802#c7 which says that's deliberate. OK, both KDE and I knew it wasn't set in stone back when we began using it, but now I'm stuck looking for a workable replacement. Here's my usage scenario: I want to install /some/ of the packages from the sets in the kde-testing overlay, but not all of them. Furthermore, as upgrades come and go, I want to be notified of any /new/ additions to the sets, so I can choose whether I want them or not. What I was doing to now was using the sets in kde-testing as a base, with a second set configured as a remove set from the first. This way, I got the packages I wanted from the current configuration, and as new packages were added, they showed up as new (as opposed to upgrade), and I could grep the kde-testing sets to see where they were coming from, do an esearch or google on the package to see what it was, and decide whether to let it install, or add it to my remove set as appropriate. Now remove sets don't work. What are the options? The most direct is to simply create my own set listing everything I want, but that won't account for anything added to the sets as they appear upstream over time. What to do about that? I suppose I could create an update script that diffs the new kde-testing set against a copy I stashed somewhere, thus showing me the differences, and that I could then update my own set and the stashed copy of the upstream set accordingly. Is that the best option under the circumstances, or does portage provide some other replacement for the functionality I just lost in that regard, with the loss of remove set functionality? Anyway, looking forward to when the sets feature is in stable portage, as it's sure nice to have... even if it /was/ nicer before this feature disappeared... =:^s But it's on the way to better, I know that. =:^) -- 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: REVDEP-REBUILD and emerge default options
Arthur D. posted on Wed, 21 Oct 2009 09:30:16 +0300 as excerpted: To Duncan: FWIW, 12 days isn't so bad. I didn't say 12 days is bad or something similar. I opened public bug report after having no reply in 12 days. Did I something wrong? I misunderstood you, then. It read to me as if you had expected an answer in say two days, and thought he was slacking, so I replied based on that. If that wasn't the case, no problem, continue as you were. =:^) (Once in awhile we do get people who just expect things to move faster than they do, is all. Once it's explained and expectations better match reality, users are happier because they don't think they're being ignored, and devs are happier because they don't feel like they're being pushed around by ungrateful users. I thought this was one of those cases, but apparently thought wrong.) -- 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: REVDEP-REBUILD and emerge default options
Arthur D. posted on Tue, 20 Oct 2009 22:23:54 +0300 as excerpted: I suggested my help in developing the script. I asked him what options will break things... No answer. 12 days left. FWIW, 12 days isn't so bad. It's often two weeks before you get a first maintainer response on a bug (I'd call that normal, I don't even start to wonder until three have passed, yes, it IS hard to wait sometimes, when it's /your/ bug, but...), and I've had bugs with supplied patches sit for months before they get tested and implemented by the maintainer. Since Gentoo is all volunteers, and real life can and does take precedence a lot of the time, this is simply a fact of life. If someone doesn't like it, they can of course work to become a Gentoo dev and volunteer their own time to get things done faster, or perhaps if they have money, they can sponsor someone to work on it full time, or they can learn to live with it... or they can get tired of it and switch to one of the commercial distributions. So I'm not going to get involved in the merits of the specific argument here, but thought I'd reply just to let you know to have a bit of patience. 12 days does NOT mean the maintainer is ignoring you, or that he won't actually agree with you when he does get to it. Often, it just means he has real life (TM) to attend to, and perhaps a few more urgent bugs or bugs he was already in the middle of, and hasn't had time to give your mail the proper consideration it is due. =:^) Actually, that he didn't answer right away might be an encouraging sign. He didn't reject the idea out of hand, and maybe he IS seriously considering it. I know I'd far rather have a reply delayed a couple weeks (or 3 or 4 or 6) and have some thoughtful consideration given to it, than have the thing rejected out of hand! =:^) That said, the bug was the way to go, as mail can get lost or eaten by the spam filter or whatever. Gentoo uses the bug tracker for all sorts of stuff one wouldn't ordinarily think of as bugs, including tracking the progress of new devs and dev retirement when it's needed (on a private bug in some cases, of course). Put it in a bug and it's in the system and will get proper consideration given it. And if having filed it, you were told to bring it up here, that's good too. =:^) All I'm really saying is don't get too worried about a response time of a couple weeks or more. That's simply a fact of life one deals with. -- 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: layman attempts to read all overlay lists when synchronizing local overlay
Amit Dor-Shifer posted on Wed, 09 Sep 2009 10:54:50 +0300 as excerpted: I'm wondering: why should layman attempt to access overlay lists when synching? It can use overlays.xml, since the overlay is already installed locally. Umm, did you RTFM? Allow me to quote the friendly manpage =:^) : -f, --fetch Fetches the remote list of overlays. You will usually NOT need to explicitly specify this option. The fetch operation will be performed automatically once you run the sync, sync-all, or list action. You can prevent this automatic fetching using the --nofetch option. and... -n, --nofetch Prevents layman from automatically fetching the remote lists of overlays. The default behavior for layman is to update all remote lists if you run the sync, list or fetch operation. Overlay locations and descriptions may change from time to time, and by deliberate and documented design decision, layman defaults to syncing its configured lists whenever you list or sync overlays. As the manpage makes clear in two different places, the user does have the ability to change that behavior, if desired, by simply adding the appropriate option to his invocation. That said, if the behavior bothers you and you're not invoking layman updates from a script such that a single command updates both portage and layman (plus updates your esearch/eix/etc database), that you could therefore simply add the option to, I'd suggest filing a bug asking for a layman.cfg option, similar to the one already there for nocheck. -- 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: official way for setting per package CFLAGS and FEATURES?
Zac Medico zmed...@gentoo.org posted 4a638016.3040...@gentoo.org,
excerpted below, on Sun, 19 Jul 2009 13:20:38 -0700:
Pacho Ramos wrote:
Hello, I would want to always merge xorg-server, libdrm, and intel
driver (that likes to crash a lot) to be always compiled with debugging
symbols and FEATURES=${FEATURES} splitdebug
I use pre_pkg_setup hooks defined in /etc/portage/env.
Does /etc/portage/env work for the python part of portage yet, or just
the ebuild.sh layer?
Either way should work for the above (and I too use it regularly for
CFLAGS, etc), but if the python components don't see it, it won't work
for dependency checking, fetching, FEATURES used by emerge itself not the
ebuild.sh callout, etc. IIRC that used to be a limitation, but I'm not
sure it still applies.
(Also, as I've seen it explained, the reason it's not better documented
is deliberate, because there's no standard way to include env file
contents in reports such as emerge --info for bug reports and the like.
Without that, many devs are reluctant to have it widely known due to the
bug squashing problems its likely to cause, so it remains a semi-secret,
known mainly by the Gentoo power users, who hopefully know to report its
use when it applies. If you check bugs I've filed, for instance, say for
parallel make aka MAKEOPTS, you'll note that I often mention that I
verified that MAKEOPTS=-j1 works by setting it in the appropriate env
file.)
--
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: official way for setting per package CFLAGS and FEATURES?
Zac Medico zmed...@gentoo.org posted 4a64c19b.80...@gentoo.org, excerpted below, on Mon, 20 Jul 2009 12:12:27 -0700: Duncan wrote: Does /etc/portage/env work for the python part of portage yet, or just the ebuild.sh layer? It only works for ebuild.sh since it's implemented via $PORTDIR/profiles/base/profile.bashrc. Support for the python part hasn't been merged yet, but there's a good patch which I've commented on here: http://bugs.gentoo.org/show_bug.cgi?id=44796#c64 Thanks. I had known such a thing was possible but didn't realize there was a patch already available and (apparently) in active discussion and merge consideration. That's very cool and I'm certainly looking forward to it. =:^) It shouldn't have surprised me, tho. Portage is very flexible in regard to what a bit of hacking can make it do, and there's a lot of folks actively involved in bending it to their will for all sorts of unusual and even unique situations. So that a patch exists to bend it in this particular direction really shouldn't be surprising at all. But that it's being considered right now for mainline inclusion is nice. =:^) -- 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: euse creates broken /etc/make.conf when USE declaration starts with empty line:
Joseph Booker j...@neoturbine.net posted 20090624102731.67740...@fenrir, excerpted below, on Wed, 24 Jun 2009 10:27:31 -0500: btw, gentoo-portage-dev really isn't the place to discuss euse bugs, gentoo-dev, gentoo-user, the forums, or bugs.gentoo.org would be more appropriate. (gentoo-portage-dev is more about the internals of portage) FWIW, gentoo-dev wouldn't be either. But as here, pretty much all lists (and forums and IRC and...) should be at least polite enough to refer first time posters to the correct locations, and often to answer the question too. =:^) But Gentoo uses bugs for all sorts of stuff, including administrative stuff like tracking new and retiring devs, and other not ordinarily something you'd call a bug bugs, so that's a reasonable place (even if they do get marked invalid or notabug at times), and the various user forums/lists/IRC-channels work well if you want a second user opinion, or just some peer help, before bothering a dev. -- 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: Conflicting RDEPENDS
Alec Warner anta...@gentoo.org posted b41005390906070208t5d6b552aid928af4ef76f6...@mail.gmail.com, excerpted below, on Sun, 07 Jun 2009 02:08:30 -0700: I like sandwiches too, so perhaps we can have a --sudo_make_me_a_sandwich option to emerge? That'd make a great easter egg option (to go along with emerge moo)! =:^) The output could be OKAY, and a link to http://xkcd.com/149/, and a hint that the option works best with -v. The -v version could add an ascii sandwich. Then put it in the help output (only, no manpage mention), with no explanation, just the notation Try it! =:^) -- 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: Conflicting RDEPENDS
Marijn Schouten (hkBst) hk...@gentoo.org posted 4a22682a.1050...@gentoo.org, excerpted below, on Sun, 31 May 2009 13:21:14 +0200: Duncan wrote: For leaf packages [-1] serves as a sort of test install. Experimental installs and their deps typically sit in the --depclean list for anything from a few minutes to a few days, until I decide whether I want to keep or remove them. I think this is an interesting use-case. It would be very simple to handle it by introducing an additional file that the package manager would use to record the packages that are installed on trial-basis. Interesting idea. -1 is working well enough for me here I hadn't even thought of adding a proper trialware list. But I could see it being quite useful for those who don't know portage well enough to realize that -1 for a leaf package effectively does make it trialware. -- 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: Conflicting RDEPENDS
Alec Warner anta...@gentoo.org posted b41005390905312058p314e6e1bnda50488d56ba0...@mail.gmail.com, excerpted below, on Sun, 31 May 2009 20:58:27 -0700: On Sun, May 31, 2009 at 4:21 AM, Marijn Schouten (hkBst) hk...@gentoo.org wrote: I think [trialware install] is an interesting use-case. It would be very simple to handle it by introducing an additional file that the package manager would use to record the packages that are installed on trial-basis. This would make it possible to include these packages in dep-calculations, while still distinguishing them from packages that are in @world. Of course you can also fake it by creating a local virtual/trialware package (or possibly a @trialware group) of which you edit the deps, but this would be less convenient. For my personal workflow using -1 for trials is working well enough, atm. Why is a custom set less convenient? I read it as... [manually] creating a local virtual/trialware package (or possibly a @trialware group) of which you edit the deps, but this would be less convenient. The key word being the one I supplied, manually. IOW, individuals could manually create the functionality currently, but this would be less convenient than if portage shipped with the trialware group functionality, no matter how it was implemented. IOW, manual creation isn't as convenient as having it a normal part of portage would be. -- 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: Conflicting RDEPENDS
Patrick Börjesson psychoti...@lavabit.com posted 20090530115251.gc11...@nexon.nexus, excerpted below, on Sat, 30 May 2009 13:52:52 +0200: It's a weigh-off between having an easy time pruning your system and having emerge calculate a correct dependency graph for your entire system. As far as emerge is concerned, a leaf package installed with --oneshot isn't reachable through the dependency graph, thus its dependencies shouldn't be accounted for. Exactly. I've no argument with --complete-graph working how it works as that's entirely logical. I was simply answering the question, why would someone use --oneshot for a leaf package? Ideally there's only one or two sets of trial install packages at any one time anyway, they were all installed at the same time either together or after having run a --pretend with them together so there were no known conflicts at that time, and they're taken care of one way or the other by the time of the next emerge -uDN @world (which is seldom 5 days, here, and more often I've reconciled within a couple days, unless one of the leaf packages is being stubborn and won't build for some reason, because a not fully reconciled, revdep-rebuilt and --depcleaned system /bothers/ me!) so it has no chance of messing them up because they're either part of it or unmerged. FWIW, FEATURES=buildpkg /does/ make life easier, too, because if there's a trialware leaf package that won't build, I can simply unmerge the dependencies temporarily, thus getting back to a fully reconciled system, and come back to it when I have more time to trace the bug down, or when there's movement on the bug if I'm depending on that. So yes there's reason to sometimes not have a dependency branch covered with an @world leaf, but there's no reason that should affect normal or even complete @world deps calculations, and indeed, I'm happy that it doesn't, as that would only throw in additional complications I don't want or need. But I'm wondering, is there possibly some method of doing the same complete-graph thing for the @installed set? I can't imagine ever using it or for that matter @installed in any form here as it just doesn't fit my admin style (as should be self-evident from the above), but since that's effectively what we're talking about... -- 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: Conflicting RDEPENDS
Patrick Börjesson psychoti...@lavabit.com posted 20090529201741.gb11...@nexon.nexus, excerpted below, on Fri, 29 May 2009 22:17:41 +0200: Why exactly would you want to use --oneshot for a leaf package that is not depended on by any other package in the world set? If spam IS depended on by any other package (recursively) in the world set, it will be pulled in by --complete-graph, but that's not the case here if i understand it correctly, thus it's a package that you explicitly wanted installed, thus it belongs in the world set, and you should thus not use --oneshot for it. I use -1 by default, here (via scriptlet), mainly so I don't have to worry about cluttering up my world file while emerging individual packages, just as I always use -NuD with my @system and @world runs. But for leaf packages, it serves as a sort of test install as well. Since I always do revdep-rebuild -p and emerge --depclean -p after every update (typically 2-3 times a week), then rebuild and clean as I need to, keeping the trial merges on the depclean list for a few days keeps me aware of them. If I know it's something I want to keep, I run a different scriptlet without the -1, but that's not often once a system is up and running with the normal working set merged. Meanwhile, I ultimately either emerge -C (or let depclean handle it) the trialware, or emerge --noreplace, thus adding it to world. But experimental installs and their deps typically sit in the --depclean list for anything from a few minutes to a few days, until I decide whether I want to keep or remove them. If he was testing how the switches under discussion here worked and has a similar policy, I could easily see him using -1 by habit, even if he didn't explicitly reason that it was a test and therefore something he didn't want in @world. -- 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: Recommendation about faster (not smaller) filesystem and blocksize combination for portage tree
Pacho Ramos pa...@condmat1.ciencias.uniovi.es posted 1239914420.18698.0.ca...@localhost, excerpted below, on Thu, 16 Apr 2009 22:40:20 +0200: Thanks, finally seems that, in my case, reiserfs with nolog,noatime works really fast and with a smaller size (thanks to tail) :-D =:^) -- 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: Recommendation about faster (not smaller) filesystem and blocksize combination for portage tree
Pacho Ramos pa...@condmat1.ciencias.uniovi.es posted 1238412618.18113.15.ca...@localhost, excerpted below, on Mon, 30 Mar 2009 13:30:18 +0200: I am trying to know what filesystem+blocksize combination could be better for the kind of files stored in portage tree. In the past, I have been using reiserfs for my / partition and I had /usr/portage under it. Later, I moved /usr/portage to a different partition (distfiles go to a different directory) and switched it to ext2 (as, in theory, ext2 should be faster as has no journaling) and 2048 as blocksize (that, of course, shrinks portage tree sizes but I am unsure about its effects from a performance point of view) You are aware of the various reiserfs mount options, including notail and nolog, right? See the mount manpage. reiserfs was tuned for small files, but these may speed it up even further. Other than that, much as I could suggest all sorts of stuff (like PORTAGE_TMPDIR as tmpfs, will probably make more of a difference if you have a decent amount of memory), I'll point you to the user forums and list as more appropriate. This list is really for discussion of portage and portage related development, not so much user portage speed tips, but ask in the user list and forums and you'll surely get all sorts of info! =:^) -- 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] %n in writable segment detected ??
What's the below %n in writable segment detected bit all about? Should I worry about it? I saw it once before but have no clue whether it's portage/emerge itself outputting it (I would guess yes, QA warning??), or one of the build processes. I'm guessing it's a warning from portage's newer parallel jobs processing that you guys may be interested in (a bug to trace down? file it?? any other info beyond the below that would be useful? how to duplicate? etc.) but don't know and obviously haven't the foggiest how serious it is. But it didn't cause anything to barf, so I figured it couldn't be too bad. But it's still worrying not knowing what it is, when it's obviously important enough to break the parallel jobs enforced backgrounding. ~amd64/2008.0/no-multilib, portage-2.2_rc25 (now, previously with a different _rc) Would you like to merge these packages? [Yes/No] Verifying ebuild manifests Starting parallel fetch Emerging (1 of 5) sys-devel/gnuconfig-20090203 Emerging (2 of 5) sys-apps/sandbox-1.6 Installing sys-devel/gnuconfig-20090203 Installing sys-apps/sandbox-1.6 Emerging (3 of 5) sys-fs/udev-140 Emerging (4 of 5) sys-apps/coreutils-7.1 Jobs: 2 of 5 complete, 1 runningLoad avg: 4.81, 3.95, 2.11*** %n in writable segment detected *** Thanks! -- 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: %n in writable segment detected ??
Duncan 1i5t5.dun...@cox.net posted pan.2009.03.14.16.53...@cox.net, excerpted below, on Sat, 14 Mar 2009 16:53:52 +: What's the below %n in writable segment detected bit all about? Here's some more strange output, from the last line above but here shown as it was when portage finished. These sort of make sense, but AFAIK should be in the individual emerge logs and spit out at the end with them, not jumbled into the parallel jobs stuff. That's enough to file a bug on, but I don't know whether it's the same one as above or unrelated, so thought I'd throw it in here first and ask since I have the thread open already. Jobs: 2 of 5 complete, 1 runningLoad avg: 4.81, 3.95, 2.11*** %n in writable segment detected *** Installing sys-fs/udev-140 Installing sys-apps/coreutils-7.1 Emerging (5 of 5) sys-libs/glibc-2.9_p20081201-r2 Jobs: 4 of 5 complete, 1 runningLoad avg: 1.98, 4.24, 3.34QA: Static ELF: /tmp/portage/sys-libs/glibc-2.9_p20081201-r2/work/ build-amd64-x86_64-pc-linux-gnu-nptl/elf/ld-linux-x86-64.so.2: /tmp/ portage/sys-libs/glibc-2.9_p20081201-r2/work/build-amd64-x86_64-pc-linux- gnu-nptl/elf/ld-linux-x86-64.so.2 --library-path /tmp/portage/sys-libs/ glibc-2.9_p20081201-r2/work/build-amd64-x86_64-pc-linux-gnu-nptl:/tmp/ portage/sys-libs/glibc-2.9_p20081201-r2/work/build-amd64-x86_64-pc-linux- gnu-nptl/math:/tmp/portage/sys-libs/glibc-2.9_p20081201-r2/work/build- amd64-x86_64-pc-linux-gnu-nptl/elf:/tmp/portage/sys-libs/ glibc-2.9_p20081201-r2/work/build-amd64-x86_64-pc-linux-gnu-nptl/dlfcn:/ tmp/portage/sys-libs/glibc-2.9_p20081201-r2/work/build-amd64-x86_64-pc- linux-gnu-nptl/nss:/tmp/portage/sys-libs/glibc-2.9_p20081201-r2/work/ build-amd64-x86_64-pc-linux-gnu-nptl/nis:/tmp/portage/sys-libs/ glibc-2.9_p20081201-r2/work/build-amd64-x86_64-pc-linux-gnu-nptl/rt:/tmp/ portage/sys-libs/glibc-2.9_p20081201-r2/work/build-amd64-x86_64-pc-linux- gnu-nptl/resolv:/tmp/portage/sys-libs/glibc-2.9_p20081201-r2/work/build- amd64-x86_64-pc-linux-gnu-nptl/crypt:/tmp/portage/sys-libs/ glibc-2.9_p20081201-r2/work/build-amd64-x86_64-pc-linux-gnu-nptl/nptl / tmp/portage/sys-libs/glibc-2.9_p20081201-r2/work/build-amd64-x86_64-pc- linux-gnu-nptl/posix/getconf _POSIX_V6_WIDTH_RESTRICTED_ENVS Jobs: 4 of 5 complete, 1 runningLoad avg: 1.87, 3.90, 3.26QA: Static ELF: /tmp/portage/sys-libs/glibc-2.9_p20081201-r2/work/ build-amd64-x86_64-pc-linux-gnu-nptl/elf/ldconfig: /tmp/portage/sys-libs/ glibc-2.9_p20081201-r2/work/build-amd64-x86_64-pc-linux-gnu-nptl/elf/ ldconfig -r /tmp/portage/sys-libs/glibc-2.9_p20081201-r2/image/ /lib64 / usr/lib64 Installing sys-libs/glibc-2.9_p20081201-r2 Jobs: 5 of 5 complete Load avg: 1.52, 3.62, 3.19 -- 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] portage-2.1.6 release plans
Zac Medico [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Fri, 07 Nov 2008 15:38:48 -0800: Since portage-2.2 isn't quite ready yet due to ongoing work in package sets and preserve-libs, and I don't want ongoing work to hold back other features that are stable, I'm planning to split a 2.1.6 branch from trunk. This branch will have package sets and preserve-libs support disabled. This branch will be named 2.1.6 in order to preserve continuity such that the final portage-2.2 release will have all of the features that have existed in previous portage-2.2 releases. In order to get testing on the new 2.1.6 branch, I plan to put portage-2.2 back in package.mask until portage-2.1.6 has been marked stable. The idea is (or would be) good, but with kde4 being one of the biggest and highest profile users of the new features including sets and with it already ~arch, I'm not sure how practical putting 2.2 or set support back in package mask really is. Do we really want to deal with the PR and other implications of putting kde4 back in package mask? OTOH, maybe you've discussed it with the KDE project already and they said do what you need to do. Maybe after all that work on and delay for sets, they've decided they can do without, for the time being? IOW, preserve-libs I think you could get away with, but I just don't think it's practical to even consider killing ~arch portage with set support. But I'm not a dev, and maybe it's just me. shrug -- 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: portage-2.2-rc3 parallel merges quit being parallel
René 'Necoro' Neumann [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Sun, 27 Jul 2008 22:31:55 +0200: Duncan schrieb: Also, a little monitoring utility that could be run in another terminal and just list and update all the currently merging packages, and any that had failed to merge, so I could take a look at them while the system is still working on the rest, would be quite useful. A very basic thingy: watch qlop -cC qlop is part of portage-utils. And it seems to only work correctly here, when run as root :) Thanks! =8^) -- 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: portage-2.2-rc3 parallel merges quit being parallel
Marius Mauch [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Sun, 27 Jul 2008 03:32:10 +0200: I did some benchmarking a while ago with different combinations of -j and -l in MAKEOPTS, using the kernel as testcase, and IIRC the fastest builds were around -l6.0 (on a dual-core system) and high (or unlimited) values for -j FWIW... My experience suggests that there's some sort of race condition with the job count. I was getting occasional very irritating errors to the effect of Job count is 17, should be 16 (or possibly the reverse), that would terminate the build. Rerunning it wouldn't trigger the problem again. By setting unlimited jobs (-j with no appended number), I avoided whatever it was, or at least haven't seen it since. I don't know enough about make's parallel job processing (OK, I simply know that it normally works, which makes it irritating when it doesn't) to have the foggiest what that was all about, except to assume it had to be some sort of race condition on the job counter. Has anyone else seen similar? Anyway, that's why I ultimately ended up with -j -lX, using the -lX part to do the limiting. With the previous simple job-at-a-time emerging, the few cases where -lX wasn't honored and therefore wasn't limiting wasn't a problem. Of course, there's some adjusting to be done now. =8^) But it's for a good reason! =8^) (I've already decided that --jobs=10 is going to need changed, I'm intuiting it needs to go up, but it's possible I need to lower it. More experimentation is necessary! =8^) -- 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] portage-2.2-rc3 parallel merges quit being parallel
So I'm running the 2.2-rcs and have been seeing blogs about the new parallel merge capacities... Having a dual-dual-core Opteron and having run multiple merges manually for some time, this is VERY welcome news. =8^) So after upgrading to -rc3 I set EMERGE_DEFAULT_OPTS to include --jobs=10 --keep-going --load-average=15 and tried a few small merges (the rest of the world update). It worked nicely. So then, as I had adjusted LDFLAGS recently and hadn't yet done a full world remerge, I decided to try the BIG test, emerge --emptytree --world, with some 674 packages. For the first 100 or so packages, it worked quite well. However, about there, maybe package 120 or so, so about 20% of the way thru, it reverted to doing them one-at-a-time again. I'm now on package #279 and it's still doing them only one at a time, and this has included stuff like the xorg-docs (IIRC) package, that really shouldn't be pre-deps for stuff that has come since, so /something/ else should have been trying to merge, as long as load-average stays low, as it has much of the time (I have MAKEOPTS=-j -l20 so it's not going to be low all the time). Is this a known issue still being worked on, perhaps due to the limits of the package dependency and scheduling resolution such that it can't handle a full world remerge and defaults back to one-at-a-time after it reaches the extent of its mapping, or is this a new bug? Also, a little monitoring utility that could be run in another terminal and just list and update all the currently merging packages, and any that had failed to merge, so I could take a look at them while the system is still working on the rest, would be quite useful. I tried watch ls -d $PORTAGE_TMPDIR/*/* and it starts to work, but of course starts to error in a few seconds when the first package completes since the *s are resolved initially. With a bit of work I'm sure can get something simple working, but it'd be nice if there were a pre-made utility to do it. Maybe there is and I just don't know about it yet? =8^) Finally... I was rather confused the first time at just one job an install took a bit, as that's apparently not counted as running, so it appeared nothing was going on for a bit. Maybe an installing count as well would be useful... and prevent that confusion. Thanks, guys. It's already fun playing with! =8^) -- 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: portage-2.2-rc3 parallel merges quit being parallel
Andrew Gaffney [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Sat, 26 Jul 2008 16:56:20 -0500: Duncan wrote: --jobs=10 --keep-going --load-average=15 For a dual-dual-core setup, a load average of 4.0 is fully loaded. Anything higher than that and you're just causing jobs to queue up unnecessarily and your system to thrash. Not really. The highest system load-average possible is the one-minute load-average, right? From my experience there are times when it just sits there doing nothing. No I/O, CPU graphs low, but load average still high so it won't start any more jobs. I see gains at times up to ~4 jobs per core (tho it's arguably possible they're counteracted above say, 3/core, by extra shuffling, I won't argue that and haven't checked that closely, I just don't like to see blank spots in the CPU utilization that aren't accounted for by I/O). I just boosted it to five so I could do the below have MAKEOPTS=-j -l20 so it's not going to be low all the time). Same thing here. Also, why would you specify different --load-average values in these two places? The idea here is to create a differential, so it doesn't start new builds when a single build can adequately parallelize. I'm building in tmpfs, which is (limited quantity, 8 gigs, but...) memory, and if a single emerge is keeping the system sufficiently busy, no reason to add a new one to the pile. However, when a single merge isn't keeping the system busy, /then/ add more. The differential at least in theory should favour single packages when they can provide sufficient parallelization. -- 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: use* cleanup
Mike Frysinger [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Thu, 01 Nov 2007 14:06:13 -0400: On Thursday 01 November 2007, Marijn Schouten (hkBst) wrote: Zlin found yet another bug. Since echo will output a newline my current proposed implementation of useq won't be quiet. sounds like we should have a testsuite in portage to make sure the misc variants are operating as expected While such a test suit would be good for portage, the other package managers could probably use it as well. It'd therefore be useful to make it an independent package, probably in cooperation with the EAPI definition project. -- 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 -- [EMAIL PROTECTED] mailing list
[gentoo-portage-dev] Re: New preserve-libs feature
Carsten Lohrke [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Fri, 23 Feb 2007 14:22:05 +0100: I consider the preserve-libs functionality one of the biggest security threats for Gentoo users. You may dismiss this, saying the problem sits in front of the keyboard, but I'm telling you this is careless and that we can do better: echo /path/to/preserved.so /var/lib/portage/preserved_libs stores the libraries, and Portage can each time emerge is run look up, if the file lists libraries, check, if those exist, if not remove the lines or otherwise warn the user about the possibly vulnerable libraries and tell him what to do. +1 here! During my own sysadmin-ings, I've wondered why there wasn't such a list on several occasions. It would make things /so/ much simpler, at least from the sysadmin perspective. (Of course, I realize that's /not/ the same thing as simpler from a portage perspective, but anyway, that's what's being discussed here. =8^) If this is added, I think it's big enough to have it mentioned in the handbook as well. Having that handy list all nicely centralized to one location would be a /big/ boon to security conscious Gentoo sysadmins everywhere, so it's easily worth mentioning in the handbook as one of the valuable tools portage provides. -- 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@gentoo.org mailing list
[gentoo-portage-dev] Re: QA Notice: ECLASS 'foo' inherited illegally
Brian Harring [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Mon, 24 Apr 2006 03:38:51 -0700: When it's (typically) not a valid bug in the ebuild- 1) binpkg merging, setup phase. 2) (pre|post)(inst|rm) 3) config phase. 4) When you've gone and screwed with PORTAGE_TMPDIR location, or wiped the env file when walking through the phases. Basically, portage doesn't always reuse the saved env properly- since the check relies on a proper env, it gets false positives. Fixing up the env handling is problematic- basically, that env _needs_ to be reused (both the relevant portage snippets of it, and eclass). Old post I know but I'm just getting back to it... It looks like most of what I see isn't valid, then, as I have PORTAGE_TMPDIR=/tmp which is your point 4. Thanks for the bug reference and commentary on env handling. It's particularly illuminating in light of the paludis discussion I had followed on gentoo-dev. -- 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@gentoo.org mailing list
[gentoo-portage-dev] Re: 2.1-rc3-r5 extraneous but (I think) harmless message?
Alec Warner [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Fri, 02 Jun 2006 20:21:35 -0400: Looking at the code I'd guess you'd never noticed, I don't see any commits in treewalk lately, it should occur for all packages. Thanks. At least if one considers it a bug, it's an old one, and as I said, appears harmless other than the misleading display. Therefore, better to let sleeping dogs sleep, for 2.1 anyway. -- 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@gentoo.org mailing list
[gentoo-portage-dev] Does 2.1 retain eclass info in binpkgs?
I'm doing some testing of the latest eselect-compiler for eradicator, involving merging and unmerging gcc. He has made some recent changes to toolchain.eclass that are supposed to help it work with eselect-compiler, and that's what I'm trying to test. Obviously, gcc is a rather huge package to go thru the entire merge every time just to test a bit of the post-merge compiler selection script, and AFAIK, while the ebuild is stored with the binpkg, and both the ebuild and dependent classes are stored in the merged package database, merging a binpkg still uses the current in-tree eclasses. That's what I'm hoping, anyway. Is that a true summation or does portage 2.1 now retain build-time eclasses in the binpkg, rather than using those in the tree, when merging the binpkg? -- 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@gentoo.org mailing list
[gentoo-portage-dev] Re: backend support for FEATURES=debug-build (again)
Mike Frysinger [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Sat, 13 May 2006 02:07:45 -0400: On Tuesday 09 May 2006 22:43, Mike Frysinger wrote: no one responded last time about this patch so lets try one more time :P backend support for FEATURES=debug-build ... no hooks/hacks/etc... included here to handle a user interface `emerge --debug-build` so do we have anyone against this ? if not i'll merge it later this weekend Maybe this has been discussed on IRC and I'm the one out of the loop, but there's a thread saying trunk is frozen for 2.1 stabilization. I'd consider this a new feature and therefore not a candidate for merging until 2.1 is branched. If you wish to make the case that it should go in, perhaps it may, but I'd certainly be careful about merging it without a definite go-ahead to do so, while trunk is supposed to be frozen save for bugfixes. -- 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@gentoo.org mailing list
[gentoo-portage-dev] QA Notice: ECLASS 'foo' inherited illegally
I continue to see way more of these than I'm comfortable with.
Illegally implies the functionality will eventually go away, and stuff
will quit working. That what's making me uncomfortable.
Some time ago this came up on the dev list and I asked about bugging them
at that time. The reply was effectively not yet. Are the notices now
to be considered bugs and filed as such, or is there perhaps something
portage doesn't like in my layout?
I'm running current ~amd64, portage-2.1-pre9-r4 at this moment. I make
heavy use of the source command in make.conf to modularize my settings.
Here's the filesystem settings (BTW, with 8 gig of memory, /tmp/ is a
tmpfs that seldom sees swap):
$cat /etc/portage/make.conf/fs
PORTDIR=/p
PORTDIR_OVERLAY=/l/p
PORT_LOGDIR=/log/portage
DISTDIR=${PORTDIR}/src
PKGDIR=/pkg
# scratch dirs
PKG_TMPDIR=/tmp
PORTAGE_TMPDIR=/tmp
PORTAGE_TMPFS=/dev/shm
# portage tools paths
CCACHE_DIR=/str/ccache
CCACHE_SIZE=2G
#UNSERMAKE=/usr/kde/unsermake/unsermake
Also of interest:
$cat /etc/portage/make.conf/features
# normal
FEATURES=buildpkg candy confcache ccache -metadata-transfer multilib-strict
parallel-fetch sandbox userfetch
# minus multilib-strict
#FEATURES=buildpkg candy confcache ccache -metadata-transfer parallel-fetch
sandbox userfetch
# minus ccache confcache
#FEATURES=buildpkg candy -confcache -ccache -metadata-transfer multilib-strict
parallel-fetch sandbox userfetch
# s/sandbox/userpriv/
#FEATURES=buildpkg candy confcache ccache -metadata-transfer multilib-strict
parallel-fetch userpriv userfetch
# with metadata-transfer
#FEATURES=buildpkg candy confcache ccache multilib-strict parallel-fetch
sandbox userfetch
Here's the latest warning, the one prompting this post, from the esearch
ebuild, which one would /think/ would be fairly portage aware, given the
author's necessary knowledge of portage internals. ([...] of course
indicates snip... a dev in one case didn't catch that and thought it was
part of the output and was /really/ confused! =8^)
[...]
app-portage/esearch
selected: 0.7.1
protected: 0.7.1-r2
omitted: none
'Selected' packages are slated for removal.
'Protected' and 'omitted' packages will not be removed.
Waiting 2 seconds before starting...
(Control-C to abort)...
Unmerging in: 2 1
Unmerging app-portage/esearch-0.7.1...
No package files given... Grabbing a set.
QA Notice: ECLASS 'portability' inherited illegally in app-portage/esearch-0.7.1
--- !mtime obj /usr/share/man/man1/eupdatedb.1.gz
[...]
--- !empty dir /usr
QA Notice: ECLASS 'portability' inherited illegally in app-portage/esearch-0.7.1
Regenerating /etc/ld.so.cache...
[...]
I've notices that these warnings occur almost entirely (if not entirely)
during the unmerge phase. Some stray comment I saw somewhere lead me to
believe they may be the result of FEATURES=buildpkg, or perhaps that
combined with the non-default filesystem layout (configuration above). If
that's the case, then it's either not a bug, or most likely a bug with
portage, not the various ebuilds.
So... if it's a bug, do I file it on portage or the ebuilds displaying the
warning? If it's not a bug, may at least I ask for a brief explanation of
what the warning means so I can stop worrying about it... and feeling
guilty for ignoring the warning and not filing the bugs! =8^)
Or... is it still not yet a bug to file about? In that case, the brief
explanation would still be very much appreciated. =8^)
--
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 in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html
--
gentoo-portage-dev@gentoo.org mailing list
[gentoo-portage-dev] Re: Re: 2.1 release candidate soon?
Philipp Riegger posted [EMAIL PROTECTED], excerpted below, on Sat, 15 Apr 2006 13:12:09 +0200: But i really think this is not about helping but about confusion. If i post my emerge --info you don't know if i really use confcache even if i have FEATURES=confcache, because emerge --info does not say if i have emerged confcache and, if i have emerged it, which version it is. I think this should also be listed in emerge --info. Very good point. -- 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 in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-portage-dev@gentoo.org mailing list
[gentoo-portage-dev] Re: should we add userpriv and usersandox to make.globals FEATURES?
Zac Medico posted [EMAIL PROTECTED], excerpted below, on Mon, 10 Apr 2006 02:24:49 -0700: What do people think about adding userpriv and usersandox to make.globals FEATURES? I've been using these for a long time and haven't had any trouble with them. Are there any arguments against making them default? I've had very occasional problems, but no more than with the default sandbox on its own. I'd say go for it, as I appreciate the slightly better security, and it shouldn't cause many issues beyond what's already there. For the few it may, better to catch and fix them anyway! -- 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 in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-portage-dev@gentoo.org mailing list
