[gentoo-dev] Re: Last rites EAPI=6 packages: dev-php/*
Jaco Kroon posted on Wed, 11 Sep 2024 09:33:10 +0200 as excerpted: > I missed this announcement, looking specifically for composer again. > > If I make the effort of bumping to newest version, is this something > that would be re-added to the tree? > > I note there were active security vulnerabilities under very specific > conditions (composer.phar is exposed via http). > > Or should I rather just deploy this into a local overlay? [Tree or local overlay?] You seem to have missed the obvious middle option, deploying to a public overlay. If there's many related packages (another reply mentioned a bunch of deps; not being a PHP person I wouldn't know...) that might most appropriately be a dedicated overlay. For single packages, particularly if there's likely to be others interested, the guru overlay seems to be quite popular as a middle ground, allowing multiple people to help without the full bureaucracy of the main tree. -- 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-dev] What about phonon-vlc w/ qt5-only vlc? Was: Last-rites: media-libs/phonon-gstreamer
Andreas Sturmlechner posted on Wed, 04 Sep 2024 16:56:57 +0200 as excerpted: > # Andreas Sturmlechner (2024-09-04) > # Unmaintained upstream, latest media-libs/phonon release incompatible. > # Removal on 2024-10-04. > media-libs/phonon-gstreamer [I thought I already sent this reply/question but don't see it on-list so trying again...] I'll take this opportunity to ask... What's the plan for phonon, with phonon-vlc the only backend, and even vlc- being qt5-only, so apparently there's no qt6 vlc any time soon? -- 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-dev] Re: Notion of stable depgraph vs stable keywords (Re: Arch Status and Future Plans)
Sam James posted on Wed, 26 Jun 2024 01:06:12 +0100 as excerpted: > Arthur Zamarin writes: > >> As you all know, Gentoo supports many various arches, in various >> degrees (stable, dev, exp). Let me explain those 3 statuses fast: >> >> * stable arch - meaning we have stable profile for this arch, and >> stable keywords across base-system + varying degree of seriousness. We >> stable stuff after ~30 days in tree, and are mostly happy. For example >> the well known and common amd64 arch. > > This mixes the notion of keywords vs profiles. > > You can have a stable profile in profiles.desc without any stable > keywords at all. > > 'stable' in profiles.desc means we require CI to pass for its depgraph > consistency. 'dev' means we warn on it. 'exp' means it doesn't even show > up unless you opt-in with pkgcheck etc. While that may clear things up from a developer perspective, it's still confusing from a user perspective (even a long-time user like me who religiously follows this list, tho being on amd64 personally with no question on it staying stable it doesn't really affect me personally at this time... tho not /too/ long ago I was still running a 32-bit-only atom netbook (tho only upgraded perhaps every year or two... which always made it difficult but possible with some time and patience) so it /could/ still affect me and I'm concerned about others still affected). Taking the one most likely to affect the greatest number of users as an example, what practical effects would dropping x86 to dev (I'm assuming no one's suggesting dropping it straight to experimental) have on remaining x86 users? How would it differ if they're already running ~x86 vs stable x86 (keywording), assuming the same currently stable x86 profile? And (again from a user perspective) how does dropping x86 to dev differ from the mentioned apparently worse alternative, mass dekeywording? -- 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-dev] Re: [PATCH v4] greadme.eclass: new eclass
Arthur Zamarin posted on Sun, 16 Jun 2024 21:15:25 +0300 as excerpted: > On 16/06/2024 18.51, Florian Schmaus wrote: >> This new eclass includes various improvements over the existing >> readme.gentoo-r1.eclass. > > So, some weird question from me - why is it called greadme? I can > understand why you don't want to modify existing eclass, but why not > call it "readme.gentoo-r2.eclass"? This should make it a little less > confusing (cause I imagine folks asking - which to use. With -r2 we all > know which one is better). I had the same question but it was answered to my satisfaction in [PATCH v3 0/1]. Quoting from that: >>> [I]f anyone wants to have function names like >>> 'readme.gentoo-r2_pkg_postinst', then we can go with that. Convinced me! greadme's /just/ fine, thankyou! =:^) (Tho purely bikeshedding I'd prefer g2readme or gen2readme. Which FWIW would match my gentoo bug shortcut g2b/g2bug...) -- 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-dev] Re: Last rites: sec-keys/openpgp-keys-jiatan
Sam James posted on Wed, 29 May 2024 19:37:47 +0100 as excerpted: > # Sam James (2024-05-29) > # OpenPGP key of malicious xz co-maintainer. This key is no longer used > # by any ebuilds in tree. Removal on 2024-06-29. > # Bug #928134. > sec-keys/openpgp-keys-jiatan I'd suggest adding the xzutils GLSA and/or version mask and removal commit tags so people unfamiliar with the story coming across this in the git history say five years from now can easily see that Gentoo took the proper actions with appropriate timing. Also, might not hurt to make that "malicious xz upstream former co- maintainer" or some such, making even clearer that it wasn't gentoo-level package-maintainer, and that they *ARE* former. Finally, could we update security practices (maybe it's already in- process?) to ensure the bad key is masked and removed earlier, along with the bad packages/package-versions? I've no explanation how it could happen without a (n entirely theoretical, AFAIK) gentoo-level accomplice outing themselves, but it would sure look bad if some how, some way, something (even in an overlay) inexplicably started using such a key again while it was still in-tree. Maybe even provide an expedited security exception of some sort from normal tree-cleaning procedures for the sec- keys category? -- 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-dev] Re: Current unavoidable use of xz utils in Gentoo
Joonas Niilola posted on Thu, 11 Apr 2024 08:21:39 +0300 as excerpted: > I just want to point out you > may not have to edit ebuilds at all. If xz-utils is package.provided > portage should ignore the dependency without you removing the dep from > an ebuild. package.provided: YMMV, but here rather than doing package.provided I create a "null-ebuild" for the package in my overlay. Much like virtual/* packages from which I took the idea except of course that they're named as the category/package they're replacing instead of virtual/*, null-ebuilds install no files but allow detailed control of IUSE, slot, etc, in case some of the revdeps need that. For versioning, my convention is -999 or -n.999 to imply a virtual (tho I do have a real perl bigint package v 1.999.842 installed...), much like the -/-n. variants imply a live-package, with similar effect in terms of preferring it to any reasonable real version number as well. So for xz-utils it'd be app-arch/xz-utils-999 as it's not slotted, or app- arch/xz-utils-5.999 if it were or if something wants 5.x specifically. Or use five-nines or six-nines or ten nines... A null-pkg I actually use here? sys-fs/udisks-2.999:2 (slot 2 dep actually required by some of its rev-deps). udisks itself is a script so doesn't provide headers necessary to build other things and should be a runtime- only dep. As a script the installation itself would be too trivial to bother with, were it not for its absolutely wicked pulled-in deps for functionality I'm not going to use and don't have turned on for my kernel in any case. Luckily kde/solid/kio/etc degrade functionality gracefully if their attempted udisks calls return command-not-found, making it an ideal candidate for null-pkging. -- 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-dev] Re: Update on the 23.0 profiles
Andreas K. Huettel posted on Sun, 07 Apr 2024 15:07:01 +0200 as excerpted: > Am Sonntag, 7. April 2024, 14:51:55 CEST schrieb Michael Orlitzky: [USE="lzma zstd" in 23.0 profiles] >> [R]emarkably bad timing. How it looks: Gentoo's response to the xz >> incident is to have me rebuild my entire system with everything that >> could possibly be linked to liblzma, linked to liblzma. Even on the >> hardened profiles, and with no easy way to prevent it. Agreed. Timing is ... unfortunate, making for absolutely terrible appearances. Tho for better or worse Gentoo will likely avoid the bad press Arch or the the big guys would get for such a play as we're simply not mainline enough any longer (Arch having eclipsed us as "the techie distro" in the press years ago now). > Well, we're now working with the best-audited compression library ever, > I guess. Also agreed... >> tl;dr can we turn them back off in the profile? In any scenario where >> they are beneficial, there's a better place to put them. That's the core operational debate. Perhaps better to debate zstd and lzma separately due to timing and relative ease (see below). > Easily doable with lzma, if there is consensus for it. Given lzma's easy, I'd vote for the revert, if only due to the unfortunate timing. It can always be reconsidered later, even if for pragmatic reasons "later" ends up being the /next/ profile upgrade, presumably some years away. But with the 17 downgrade to exp (if not deprecated yet), if we're changing it (and not temporarily reverting the 17 exp) it should be ASAP! > Slightly more complex for zstd since this affects gcc and binutils. > Still doable though. For zstad I'd keep as-is because it's both more difficult and lacks the direct timing issues. TLDR stop! FWIW, no effect either way here/personally, because I configured portage to ignore profile USE flags (as well as IUSE-defaults) years ago, in large part precisely /because/ of the undesired USE-flag churn. And in general it has made me a /much/ happier gentooer, because USE-flag no longer blindly toggle without my having to go unduly out of my way to find out why. (I already review the git log when a USE flag suddenly (dis)? appears, unless it's blindingly obvious why without checking the log.) The one thing I wish I had was an indication of IUSE-defaults for changes on upgrades and for new packages. Sure I can (and do) grep for IUSE if I have reason to wonder (more frequently for new packages if I don't know whether I want something enabled or not), but I imagine I miss most of the on-upgrade ISUE-default-changes as unlike the flag entirely (dis)? appearing or (un)masking (which is still active from the profile) there's nothing alerting me to IUSE-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-dev] Re: Current unavoidable use of xz utils in Gentoo
Michael Orlitzky posted on Wed, 03 Apr 2024 12:40:26 -0400 as excerpted: > On Wed, 2024-04-03 at 16:30 +0100, Eddie Chapman wrote: >> It does involve a relatively small hack and functionality previously >> provided by xz-utils is replaced by app-arch/p7zip. > > I did the same thing with app-arch/unzip a long time ago. You caught a > lot of shit for your post, but I don't think it was out of line. > > Worst case? You spent a lot of time building a fragile solution to a > non-problem that everyone said you were crazy for wanting in the first > place. Hi, this is Gentoo, glad to have you. Gentoo as "meta-distro": Yes. I suspect many, perhaps most, Gentooers (individually or at the company level for corporate deployments) eventually end up doing their own thing to some degree or another. I haven't seen the term used much recently, but Gentoo can legitimately lay claim to "meta-distro", that is, a distro that makes it reasonably easy to do your own thing, creating a "mini-distro" for your own use. In fact it's reasonable to argue that (at least before the gentoo-mainstream binary packages became a thing) the relative costs of building it yourself likely ultimately lead most users who do /not/ need the meta-distro aspect to switch back to a more binary- inclined distro, perhaps arch if they still want a lot of flexibility, which means the ones that stick around on Gentoo for say a decade or longer tend to do so /because/ they ended up using that meta-distro aspect. In my own case my reverse-usrmerge ( /usr -> .) is certainly my biggest current meta-distro level divergence, tho historically, keeping USE=-semantic-desktop functionality alive locally during the period that the gentoo/kde project dropped it was an equally major divergence... but equally doable due to Gentoo's meta-distro aspect. Tho both would be rather harder were it not for git; I may not have done either one if git hadn't happened and svn was still king. -- 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-dev] Re: Current unavoidable use of xz utils in Gentoo
Kévin GASPARD DE RENEFORT posted on Wed, 3 Apr 2024 14:22:18 +0200 as excerpted: > Fork Gentoo, or any other distros, start a LFS… In fact, Gentoo has been forked in this way at least three times. The first time was over 20 years ago, before 2004 as I remember researching it before I switched to Gentoo myself. IDR what it was called but it had already by then pretty much fizzled out. #2 and #3 are I believe still around and there's still some healthy interaction between them and Gentoo. Funtoo is one, created by Gentoo's original founder. It still uses portage and some of portage's features are primarily used there. As a result, their contributions back to portage have continued to make it better for all users. The other IDR the name (maybe Herb...?, with paludis as the package-manager) but PMS, the package-management-specification, that defines a portage- and package-- manager independent spec and the EAPI that packages use, is one of the major efforts to come of it as they split off. And while most gentooers still use portage, pms is the reason other package managers can really work at all, and the thing much of the automated CI testing uses now, making it a BIG benefit to Gentoo. So forking is a legitimate and respected if not necessarily pleasant while it's happening route to go, and often, some contributions from the process continue to be useful to and benefit both forks for many years after the fork. While forks do generally mean duplication of effort in some areas and are often unpleasant to go through, the results aren't necessarily all bad, particularly when viewed with an appreciation that people often aren't paid for their work and could simply quite contributing entirely, which means the duplication of effort isn't all negative if it still means more contributions to the community than would happen if they just quit. So if Gentoo's not doing it for you, in addition to the option of creating your own fork being a not necessarily entirely bad option, there's two other existing forks you might wish to look into, in case they're a better fit for you than Gentoo. -- 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-dev] Re: Current unavoidable use of xz utils in Gentoo
y efforts to find these and add them to the security-help list now, because there's real-money products at stake! Yet another issue, once tarballs can be verified against release tags, is that a lot of distro maintainers don't actually verify the code changes. Some simply don't have the necesary skills. Others have the skills, but still don't verify, because the tooling isn't there to make it fast/simple enough for them and there's always more packages to bump then time to actually do it. Now, due to the xz-utils attack revealing the problem, there's already community efforts to improve the tooling to make it easier for distro maintainers to not only look at the commit logs, but go a bit deeper than that and better show the changed code. And many maintainers are redoubling their efforts to make routine at least minimal change-audits with the existing tooling in the mean time. Helping with any of these three would certainly be reasonable. But demanding a *LOT* of work to alternative-force an already attack-reverted package, when we actually KNOW about that one, it's reverted to pre-attack and there's likely to be no more mischief there /because/ everybody's looking at it now, when it could have been any of a number of packages, some of which might already be compromised and we just didn't happen to find it, IMO really doesn't make much sense. -- 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-dev] Re: Current unavoidable use of xz utils in Gentoo
Dale posted on Sat, 30 Mar 2024 02:06:26 -0500 as excerpted: > Gentoo has some awesome devs. Agreed with the whole thing and the above is a bit of an aside from the thread, but it's worth repeating! Thanks devs! (And security contributors, infra providers, testers, tinder-box runners, bug reporters and wranglers, docs/wiki/lists/forums/ chat contributors, and all of the above for our upstreams too... it takes a big community to make a full distro and we all have our part! =:^) -- 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-dev] Re: Profile 23.0 testing with stages and binhost (part 2 of 2)
Andreas K. Huettel posted on Fri, 15 Mar 2024 19:12:54 +0100 as excerpted:
> Note 3: amd64 now has CET turned on by default.
> https://docs.kernel.org/next/x86/shstk.html If you have already used the
> unannounced 23.0 profiles, you should wipe your package cache and emerge
> -ev world now.
There's not much about CET in any of the links. While the kernel.org link
describes what it does (in a line, "yese": yet another security
enhancement) a bit, it doesn't say how to actually find whether your
hardware supports it, and the gentoo wiki and bug links say even less --
in particular, unless I missed it, the changes and update instructions
links don't appear to mention CET or shadow-stacks AT ALL.
What I ended up doing here after some DDG googling, was emerging cpuid,
then doing:
$$ cpuid -1 | grep -i 'cet\|shadow'
CET_SS: CET shadow stack = false
CET_IBT: CET indirect branch tracking= false
CET_U user state = false
CET_S supervisor state = false
supervisor shadow stack = false
With all of those false it would seem CET can't work here in any case so
there's no point rebuilding again, which is what I already suspected but
wanted to /know/. (I've been on a 23.0 merged-usr profile[1] for some
time now as I already had much of what it does already enabled before the
new profiles were announced here, so it /would/ be "rebuilding again" to
get that, but as it seems it won't do anything useful anyway...)
Clearer instructions for finding that out (and preferably what actually
has to be true, I still don't know that for sure) so others don't have to
google it, could be useful.
---
[1] Already on a merged-usr profile: Of course including developing an
auto-applied-on-update patch to do s:[[ ! -h "${EROOT%/}/bin" ]]:false: to
the profile bashrc after that test was added, because I am indeed usr-
merged (on systemd) here but that test fails because the operating symlink
is /usr -> . instead, aka reverse-usrmerge. Tho making the canonical
path /realbin and doing /bin -> /realbin would appear to satisfy the test
too, and would allow me to avoid patching the profile bashrc, but at least
here, having /bin be the system's real bin location is part of the _point_
of a reverse-usrmerge.
--
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-dev] Re: RFC: banning "AI"-backed (LLM/GPT/whatever) contributions to Gentoo
Michał Górny posted on Sat, 09 Mar 2024 16:04:58 +0100 as excerpted: > On Fri, 2024-03-08 at 03:59 +0000, Duncan wrote: >> Robin H. Johnson posted on Tue, 5 Mar 2024 06:12:06 + as excerpted: >> >> > The energy waste argument is also one that needs to be made >> > carefully: >> >> Indeed. In a Gentoo context, condemning AI for the computative energy >> waste? Maybe someone could argue that effectively. That someone isn't >> Gentoo. Something about people living in glass houses throwing >> stones... > > Could you support that claim with actual numbers? Particularly, > on average energy use specifically due to use of Gentoo on machines vs. > energy use of dedicated data centers purely for training LLMs? I'm not > even talking of all the energy wasted as a result of these LLMs at work. Fair question. Actual numbers? No. But... I'm not saying don't use gentoo -- I'm a gentooer after all -- I'm saying gentoo simply isn't in a good position to condemn AI for its energy inefficiency. In fact, I'd claim that in the Gentoo case there are demonstrably more energy efficient practical alternatives (can anyone sanely argue otherwise?, there are binary distros after all), while in the AI case, for some usage AI is providing practical solutions where there simply /weren't/ practical solutions /at/ /all/ before. In others, availability and scale was practically and severely cost-limiting compared to the situation with AI. At least in those cases despite high energy usage, AI *is* the most efficient -- arguably including energy efficient -- practical alternative, being the _only_ practical alternative, at least at scale. Can Gentoo _ever_ be called the _only_ practical alternative, at scale or not? Over all, I'd suggest that Gentoo is in as bad or worse a situation in terms of most energy efficient practical alternative than AI, so it simply can't credibly make the energy efficiency argument against AI. Debian/ RedHat/etc, perhaps, a case could be reasonably made at least, Gentoo, no, not credibly. That isn't to say that Gentoo can't credibly take an anti-AI position based on the /other/ points discussed in-thread. But energy usage is just not an argument that can be persuasively made by Gentoo, thereby bringing down the credibility of the other arguments made with it that are otherwise viable. -- 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-dev] Re: RFC: banning "AI"-backed (LLM/GPT/whatever) contributions to Gentoo
Robin H. Johnson posted on Tue, 5 Mar 2024 06:12:06 + as excerpted: > The energy waste argument is also one that needs to be made carefully: Indeed. In a Gentoo context, condemning AI for the computative energy waste? Maybe someone could argue that effectively. That someone isn't Gentoo. Something about people living in glass houses throwing stones... (And overall, I just don't see the original proposal aging well; like a regulation that all drivers must carry a buggy-whip... =:^ Absolutely, tweak existing policies with some added AI context here or there as others have already suggested, but let's leave it at 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-dev] Re: 2024-02-26-debianutils-drops-installkernel-dep: add news item
Andrew Nowa Ammerlaan posted on Mon, 26 Feb 2024 18:13:32 +0100 as
excerpted:
> Removing sys-kernel/installkernel from your system WILL change the way
> kernels are installed by 'make install'! Instead of the versioned
> /boot/vmlinuz-x.y.z that you are used to, 'make install' will simply
> copy bzImage (or equivalent for you arch) into /boot. This image may not
> be picked up by your bootloader or its configuration tools.
I'm uncomfortable with that unconditional, "SHOUTED" even, "WILL".
That isn't the case here -- I've been getting versioned images without the
debianutils-based installkernel script for years.
I long ago (when installkernel was still part of debianutils according to
comments in my version, presumably the debianutils default-enabled USE was
set when it was split out to avoid just this sort of surprise at that
time) created my own version based on the debianutils version, but
bashified/comment-and-var-name-clarified and with a config file that
determines various behavior (along with behavior for my other kernel-
related build/patch/config/etc scripts).
Maybe "will likely", or "will, unless you've specifically configured other
behavior", or "will, unless you've previously setup your own solution"?
("Will" can then be SHOUTED or not, as desired, because the statement is
then sufficiently conditional regardless.)
--
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-dev] Re: Add Hooks to Eselect
Redjard posted on Fri, 18 Aug 2023 21:38:37 +0200 as excerpted:
> From: Redjard
>
> Add Hooks to Eselect
>
> For example for "eselect kernel list" the script
> /etc/eselect/hooks/kernel/list/pre is called before the eselect acts,
> and /etc/eselect/hooks/kernel/list/post afterwards.
Suggestion: A more flexible approach would make pre/post directories, such
that "any" file therein (exceptions for backups, etc) would be sourced.
In run_hook something like (as written assumes bashisms OK, didn't verify
if that's valid for eselect or not):
local action=$1
local subaction=$2
local hookscriptdir=$3
for $hookfile in
/etc/eselect/hooks/${action}/${subaction}/${hookscriptdir}/*
do [[
# maybe skip either the executable or README test?
# or perhaps only match *.sh filenames instead
# to reflect the in-shell sourcing?
-x $hookfile &&
$hookfile == ${hookfile#README} &&
$hookfile == ${hookfile#.} &&
$hookfile == ${hookfile%.bak} &&
$hookfile == ${hookfile%\~}
]] && source "$hookfile"
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-dev] Re: [RFC] News Item v3: Plasma Profile to enable PipeWire, Wayland support
Andreas Sturmlechner posted on Tue, 16 May 2023 19:55:04 +0200 as excerpted: > Title: Plasma Profile to enable PipeWire, Wayland support TLDR: Thanks! FWIW, I'm not a plasma profile user (no no-multilib variant) and had already encountered some of this with the (luckily) then-transient plasma- workspace pipewire deps as well as the (more permanent) spectacle pipewire dep (which without this guide, triggered an unmerge as less useful than the time it would take me to get upto speed with a maintainable-working/secure pipewire config). But while I am still alsa-based, no pipewire/pulse (yet?), I'm already wayland-migrated and in fact have no xorg on the system (xwayland is my only X), so that part's already done, here. And this NEWS-item/guide is very clear (definitely more so than my previous partial understanding), both in the choices to be made and implications thereof, and in the practical how-to of how-to-get-there-from-where-you-are configuration whatever one's choices are. While I still have to think about it, armed with this I feel far more confident in switching on pipewire, and with it installed anyway, perhaps even enabling it all the way, full pipewire sound/video-server and all. We'll see. So thanks, indeed. Just what I needed, despite not being a plasma profile user. And while I'm at it, thanks for all that work keeping gentoo/kde, especially the live-git packages and associated unmasking/sets/etc config in the overlay that I use, in such good shape as well. While it surely must help having many of the new deps caught and fixed well before release time, and I know a lot of the otherwise drudge work is now automated, kde's still awfully big to be dealing with all those live packages as I well know from the user side. And of course there's all the just coming 5->6 changes to deal with now too! So I surely appreciate the work you put in on the dev side to make my user-side possible. =:^) -- 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-dev] Re: [PATCH v2] 2023-05-08-openssh-configuration-changes: add item
Sam James posted on Mon, 08 May 2023 19:44:18 +0100 as excerpted: > James Cloos writes: > >>>>>>> "SJ" == Sam James writes: >> >> SJ> +Such admins will need to edit the new files in the new directories or >> SJ> +make overrides in their own files in the new directories using a higher >> SJ> +number in the filename. >> >> given that openssh uses first-wins rather than last-wins, should than >> not be 'smaller number'? > > Yes, I'll fix that up locally, thanks Are these "numbers" truly (suppressed-leading-zero-)numeric-order-parsed? Does 9-xxx come before or after 80-xxx ? Would it need to be 09-xxx (shell-order-parsing)? -- 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-dev] Re: [PATCH gentoo-news] 2023-04-01-python3-11: add news item
Michał Górny posted on Fri, 31 Mar 2023 19:15:36 +0200 as excerpted: > +You may wish to remove the target overrides after the defaults switch. > +Alternatively, you can keep them to block the next automatic upgrade > +to Python 3.11, and upgrade manually then. s/3.11/3.12/ ? (_This_ upgrade was to 3.11; the _next_ one would be 3.12.) > + > + > +Upgrade commands > +==== -- 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-dev] Re: Last rites: app-admin/gkrellm & plugins
Philip Webb posted on Fri, 27 Jan 2023 12:58:43 -0500 as excerpted: > 230127 Michał Górny wrote: >> # GKrellM and a variety of plugins. >> # Removal on 2023-02-26. Bug #892251. >> app-admin/gkrellm [and plugins, etc.] > Is there a recommended alternative ? app-admin/conky It's currently gtk3, but at least with lua-cairo enabled, X-only. However, upstream is alive and wayland-native support is apparently in the works (tho it has been some months since I last checked status), so doesn't appear to be death-bed either. I use it here, altho I wasn't satisfied with built-in only so learned lua (designed for embedding, exactly what conky uses it for) and wrote my own conky lua themes. Seems extensibility is mandatory for flexibility (handling decent detail at readable size without going fullscreen) for this sort of app, and I've learned the extensibility language of more than one such app (RIP superkaramba!) as they've gone dead over the years, but with conky alive and working on wayland-native support, hopefully it'll stick around for awhile. Meanwhile, email me privately if you're interested in a lua-based conky theme that can handle for example per-thread user/nice/system/freq (extensible to steal... if you're doing VMs) at "readble but not entire screen" sizes with AMD's 64-core/128-thread threadripper in mind (tho I'm still on an old 6-thread ATM so expanding that big likely has bugs to work out), or just for general conky discussion/questions, if you want. -- 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-dev] Re: Current portage will now truncate your repo's git history to 1
Florian Schmaus posted on Thu, 15 Dec 2022 21:40:19 +0100 as excerpted: > On 15/12/2022 21.10, Toralf Förster wrote: >> On 12/15/22 20:22, Florian Schmaus wrote: >>> o use PORTDIR_OVERLAY and multiple repositories on their system: a >>> system-wide, managed by portage, and a dev repository (in your HOME), >>> scoped in via PORTDIR_OVERLAY. >> >> Isn't this covered by /etc/portage/repos.conf/* > > Absolutely, but this requires a manual intervention from the user. And, > of course, you can totally opt-out from portage managing (syncing) the > repository, but then you have to take care of syncing yourself. > > The point is that with the new portage release, portage's behavior > changes. And I would argue that portage should not, in its effort to > become more user friendly, disregard ebuild-developer friendliness. > Assuming it is achievable with a reasonable amount of additional code > complexity. This bit me too, and making things worse, the truncate killed the git history that presumably had the answer I needed to fix it up. =:^( Fortunately I had a bit of a clue due to preemptively following the portage changelog where I had seen a hint, so I was able to dig it up again without the git log help that's definitely now my first instinct. Long story short and for the record, manual intervention indeed and I wish it had at least come with a news item, but here's the magic that fixed it for me. I had one of these previously, IIRC clone depth, but both are now needed. I put these in the [DEFAULT] section here because I run several overlays and I "want" access to proper git logs and history by default. (FWIW "want" is the polite, cooled down, version; the situation was considerably more sweary when I lost that history and instinctively I tried to look in the git history for why, but of course it was GONE!) repos.conf, [DEFAULT] (or [gentoo]) section: clone-depth = 0 sync-depth = 0 -- 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-dev] Re: [PATCH] flag-o-matic.eclass: add append-time64-flags
Sam James posted on Wed, 9 Nov 2022 06:25:38 + as excerpted: >> On 31 Oct 2022, at 10:37, Mickaël Bucas wrote: >> >> Le dim. 30 oct. 2022 à 16:48, Sam James a écrit : >>> >>> Signed-off-by: Sam James >>> --- >>> eclass/flag-o-matic.eclass | 13 + >>> 1 file changed, 13 insertions(+) >> >>> +# @FUNCTION: append-time64-flags >>> +# @DESCRIPTION: >>> +# Add flags that enable 64-bit time_t. Implies Large File Support >>> +# (calls append-lfs-flags) automatically. > >> As a simple user And as another user... > Plans and notes are at > https://wiki.gentoo.org/wiki/Project:Toolchain/time64_migration if > interested! ... just in case anyone (else) needed to be sure, quoting from the above link: >>>> For 32-bit arches >>>> Obviously 64-bit arches are already 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-dev] Re: [PATCH v6 2/2] profiles/desc: add amdgpu_targets.desc for USE_EXPAND
Yiyang Wu posted on Thu, 1 Sep 2022 00:40:34 +0800 as excerpted: > +++ b/profiles/desc/amdgpu_targets.desc > @@ -0,0 +1,17 @@ > +# Copyright 1999-2022 Gentoo Authors. > +# Distributed under the terms of the GNU General Public License v2 > + > +# Referene： Non-ASCII unicode mangled "Reference:"?? Looks like "Referene here. kcharselect says U+ff1a is unicode category "punctuation, other", block "half-width and full-width forms", approximate equivalent U+003a, colon (presumably what you intended). Looks like the "c" is missing as well, but that could be my client's display indigestion on the unicode. -- 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-dev] Re: GLEP 83 [v3]: EAPI deprecation
Ulrich Mueller posted on Sun, 31 Jul 2022 23:26:13 +0200 as excerpted: > Update v3 One language thing and two possible clarifications. > --- > GLEP: 83 Title: EAPI deprecation > Author: Ulrich Müller > Type: Informational Status: Draft > Version: 1 > Created: 2022-06-30 > Last-Modified: 2022-07-31 > Post-History: 2022-07-11, 2022-07-31 > Content-Type: text/x-rst > --- > Specification = > > A *deprecated EAPI* is no longer required for the upgrade path of users' > systems. Its use is discouraged, and tools like pkgcheck will warn > about this [#COUNCIL-20130409]_. > > A *banned EAPI* must no longer be used, neither for new ebuilds, nor for > updating of existing ebuilds [#COUNCIL-20140311]_. > > The Gentoo Council will deprecate an EAPI when > > * two newer Council-approved EAPIs are supported by the stable version > of Portage, and > * one of them has been supported for 24 months. > > The Gentoo Council will ban a deprecated EAPI when > > * 24 months have passed since its deprecation, and * it is used by fewer > than 5 % of ebuilds in the Gentoo repository. The first possible clarification fits here (I think). Something like: This GLEP is intended as a policy reference guide for EAPI minimum effective times. Despite the statistical qualifications listed here no EAPI will be deprecated or banned without specific Gentoo Council action. (While this is implied by the "Gentoo Council will..." wording, making it explicit could prevent later confusion/controversy.) > EAPIs used in profiles are outside the scope of this GLEP. > > > Rationale = > > Timing of EAPI deprecation is a trade-off between different factors. > On the one hand, the total number of EAPIs in active use should be > limited; this will prevent the learning curve for new developers and > contributors from becoming too steep and will help to reduce code > complexity, e.g. in eclasses. The language point: Am I the only one for whom the omission of "from" makes the sentence read smoother? (Maybe it's a regional English thing?) ; this will prevent the learning curve [...] from becoming too steep... ; this will prevent the learning curve [...] becoming too steep... > On the other hand, an upgrade path to a stable system is guaranteed for > one year, plus limited support for systems that are outdated more than a > year [#COUNCIL-20091109]_. Therefore, previous EAPIs are still required > during that time. A period of 24 months before deprecation has been > chosen, which is more than the required minimum and will allow projects > to support a longer upgrade path. > > Requiring two newer EAPIs before deprecation will allow ebuilds that are > otherwise seldom updated to be bumped to the next but one EAPI > immediately. > A delay of 24 months between deprecation and ban will give ebuild > authors enough time to update. This is especially relevant for overlays > and downstream distributions. An additional requirement for banning an > EAPI is that fewer than 5 % of ebuilds are using the EAPI in question. > This requirement is defined to help keep the number of ebuild updates > (and bug reports requesting them) managable, as a banned EAPI is > sufficient reason for updating an ebuild. The second possible clarification seems to fit about here, but may require a bit of adjustment to the text above it. The two 24-month times are effectively additive, yielding a total 48 months minimum between addition of an EAPI and banning of the previous one. Given past EAPI history of at minimum a year between EAPI introductions that should yield a minimum three years of active EAPI life before deprecation, one year minimum as the newest EAPI plus two years before deprecation, plus two years of deprecation, for five years total EAPI life before ban. (This isn't entirely necessary but makes explicit the answer to one of my first questions reading the proposal. YMMV. I debated spec vs rational, but decided rational was a better fit.) -- 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-dev] Re: Qt 5.15.3 version bump with breaking changes incoming
Andreas Sturmlechner posted on Mon, 21 Mar 2022 12:18:43 +0100 as excerpted: > Please upgrade to Qt 5.15.3 which is in package.mask now and help > testing, especially if you maintain Qt5-based packages yourself. FWIW I did the upgrade yesterday, as it's now required (as you know) for the live-git kde-*/*- packages in the kde overlay. Timing happened to be a bit rough as I had been working through a bunch of upstream kde git-master breakage over the last couple weeks and still had a couple critical packages that I had /just/ figured out how to get to rebuild... when I had to do the 5.15.3 upgrade too, but after pulling an all-nighter last night, I had everything at least building again early this morning. But the freshly upgraded plasma-wayland wouldn't actually run, even after reboot, etc. Glad I have weston as a backup! =:^) After work (without sleep) today, I synced and did the normal @world deep- update, then smart-live-rebuilt todays updates, and luckily there weren't additional unfixed breaking updates in the last ten days, and I could FINALLY get back into a fully updated in-sync-with-upstream live-git- master kde, on top of the fresh qt 5.15.3, the first time I've been fully updated and operational since I was last in sync March 7. =:^) I still have some bug fallout to file, gentoo/kde-overlay or upstream, after I recover with a bit more sleep (and update my backups at my new known-working state), and I can't say the upgrade was at all smooth tho that's timing as much as anything, but I *CAN* report my normal plasma- wayland session and everything I've tested so far is working fine with qt 5.15.3 now! =:^) And of course if I didn't enjoy the challenge and edginess of a bit of breakage every now and again I'd not be running ~arch plus live-git of all of kde along with a few other misc packages... It sucks when it breaks but there's nothing like the high of FINALLY having a fully working fully in- sync system after struggling with it for a couple weeks. Thanks for both the new qt and all those live kde-*/*- ebuilds. =:^) -- 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-dev] Re: [PATCH 0/1] ecm.eclass: set KDE_DEBUG=1 for ecm_src_test
James Beddek posted on Wed, 20 Oct 2021 09:42:14 + as excerpted: >> > KDE provides a variable, KDE_DEBUG [1], which when set disables the >> > DrKonqi crash handler. Using this results in the tests segfaulting >> > and the test phase simply failing, rather than hanging. >> Do crashes of other (non-ecm) tests trigger DrKonqi too? What's the >> reason to add this variable only to ecm.eclass? >> > As far as I can tell only packages that use ecm.eclass trigger DrKonqi > upon a test segfault. However, this may just be to me not experiencing > crashes in other test suites. To the best of my knowledge it's purely > the KDE/ecm packages. DrKonqi is part of kde's plasma, in gentoo as kde-plasma/drkonqi . As such it depends on various kde-frameworks/* including kde-frameworks/ extra-cmake-modules, shortened in kde-dev lingo to ECM, thus ecm.eclass. And ECM is the way they handle kde-specific cmake detection so basically any app that cares about drkonqi is going to be using ecm.eclass as well. Tho the reverse doesn't necessarily hold -- ECM as a framework is far more basic than drkonqi as a plasma component, and while my kde/plasma installation is somewhat lite, nothing's actually pulling in drkonqi and it's not merged, while a quick equery d extra-cmake-modules | wc -l suggests 151 packages depend on extra-cmake-modules and a look at the list confirms they're all kde related, tho a few like media-libs/phonon are not kde-*. And without drkonqi I get segfaults. Which suggests another possible workaround, unmerging drkonki. If the only thing pulling it in is a set or metapackage the alternative would be either a local-overlay null- package, or commenting that entry in a local copy of the set/metapackage. -- 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-dev] Re: [PATCH] ant-tasks.eclass: use eapi7-ver
Marty E. Plummer posted on Mon, 21 May 2018 23:01:10 -0500 as excerpted:
>> > +[[ ${EAPI} == 7 ]] || inherit eapi7-ver
>>
>> Always check for old EAPIs, instead of expecting people to keep
>> updating this forever.
>>
> Would you prefer something like [[ ${EAPI} ~= [0-6] ]] && inherit
> eapi7-ver, then?
> The way I see it, every consumer of ant-tasks is eapi 5 right now, 5 and
> 6 if my pull request is accepted. Once every consumer is eapi 7 or
> greater,
> this line can be removed entirely and it won't be needing updates
> 'forever'.
Test defensively. We're not just talking EAPI=8, etc, here. What
happens if someone typos EAPI=56 or some such? Positively support what
you recognize. If it's unrecognized, it should always fall thru to an
error saying it's unsupported. Much easier to debug 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-dev] Re: [RFC] multiversion ebuilds
Mathy Vanvoorden posted on Tue, 15 May 2018 11:32:30 +0200 as excerpted: > 2018-05-12 14:20 GMT+02:00 Gerion Entrup : > > just an idea for now. But what you think about multiversion ebuilds? >> Technically this could be realized with the following line in the ebuild >> itself: >> ``` >> VERSIONS=( 3.0.11 3.0.12 3.1 ) >> ``` >> > > I like the idea of multiversion ebuilds but why would you complicate the > process by putting it in a variable? Why not just use symlinks and have the > following: > > foobar/foobar-1.x > foobar/foobar-1.1.ebuild -> foobar-1.x > foobar/foobar-1.2.ebuild -> foobar-1.x > foobar/foobar-2.x > foobar/foobar-2.1.ebuild -> foobar-2.x AFAIK symlinks aren't allowed in the gentoo tree, with the given reason being that some users, particularly those with limited net access and thus "sneakernetting" from where they /do/ have net access, may place the tree on or transfer it via no-symlink-support FAT32 or similar, perhaps downloading it from an MS machine or the like. Of course users may use symlinks on their own copies, but they're not allowed in the official tree. Tho perhaps that can be reevaluated. But while there's more connectivity now than over a decade ago when that policy was created, I expect there's still those paying by the meg or gig for net access locally, that won't enjoy having their sneakernet sync routine disrupted. -- 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-dev] Re: [PATCH v2] eapi7-ver.eclass: Support EAPIs 0 to 6.
Ulrich Müller posted on Tue, 08 May 2018 21:39:16 +0200 as excerpted:
> # @ECLASS: eapi7-ver.eclass
> @@ -58,12 +58,8 @@ # the version string, it is truncated silently.
>
> case ${EAPI:-0} in
> - 0|1|2|3|4|5)
> - die "${ECLASS}: EAPI=${EAPI:-0} not supported";;
> - 6)
> - ;;
> - *)
> - die "${ECLASS}: EAPI=${EAPI} includes all functions from this
> eclass";;
> + 0|1|2|3|4|5|6) ;;
> + *) die "${ECLASS}: EAPI=${EAPI} includes all functions from this
> eclass" ;;
> esac
>
You're simply continuing what was there before, but since you're working on
it already...
That generic *) case die claim is incorrectly specific for a generic catchall
case.
I'd suggest a 7) case with that specific claim, and an "EAPI Unknown" die
error for the generic *) catchall case. The error is then clearer if someone
typos EAPI=67 or the like.
+ 0|1|2|3|4|5|6) ;;
+ 7) die "${ECLASS}: EAPI=${EAPI} includes all functions from this
eclass" ;;
+ *) die "${ECLASS}: EAPI=${EAPI} Unknown" ;;
--
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-dev] Re: Monthly x11@ project status for April 2018
Matt Turner posted on Sun, 01 Apr 2018 20:08:35 -0700 as excerpted: > My list of to-do items consists of: > > == Fix x11-base/xorg-server suid/systemd situation == > https://bugs.gentoo.org/635102 > > Under some circumstances (kernel modesetting driver + systemd, I think) > Xorg should be able to run without root privileges. We were shipping a > USE=suid option without anyone knowing or understanding its purpose. FWIW I understood it, but also knew it broke X for me back when I first tried it. However... > For >=x11-base/xorg-server-1.20 I plan to ship the xserver in a way that > allows systemd/elogind users with kernel modesetting drivers to run Xorg > without root privileges. I expect to push version 1.19.99.902 (1.20 RC2) > into the tree soon with something working for systemd. I would very much > appreciate an ebuild patch from any elogind user as well as non-systemd > testing to make sure I haven't broken anything like I did with > 1.19.99.901. I noticed the recent no-superuser X changes here (on ~amd64), and decided to try it again... And now (after undoing an old hack I had to manually set SUID here) I have X running as my normal user. Thanks! =:^) FWIW, systemd with modesetting (amdgpu), as you suspected. startx (no *dm at all merged). X starts on top of the vt1 login. xorg- server-1.19.99.901-r1 > == Update packages to depend on x11-base/xorg-proto == > https://bugs.gentoo.org/651286 > > The new x11-base/xorg-proto package combines nearly all (28 in fact) of > the x11-proto/* packages into one, with a very fast Meson build system. > It installs on my laptop in less time than it takes to ./configure one > of the individual x11-proto/ packages. I've kept empty versions of the > x11-proto/ packages to ease the transition. I noticed that I didn't need many of the protos any longer here too, and figured it was a recombining. Thanks for the confirmation. =:^) And thanks for the roadmap to what's ahead re X. =:^) -- 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-dev] Re: New Portage fork: sys-apps/portage-mgorny
Vadim A. Misbakh-Soloviov posted on Sun, 25 Mar 2018 17:13:28 +0700 as
excerpted:
> Well, in *my* opinion, in turn, having possibility to {R,}DEPEND on
> package from exact repo is much and much more needed functionality.
>
> Say, I have pkg2 in my repo, that depends on pkg1, which is in my repo
> too. Then, I (or user) add other repo having pkg1 too. Or, say, gentoo
> maintainers bump pkg1 to a newer version (while I'm slacking a bit).
> And my pkg1 is a bit different from gentoo's (let it be patchset, or,
> say, lua.eclass support for lua overlay).
>
> So, that changes results in random unexpected behaviour as blocks,
> runtime breakage and so on.
> Currently, it is no way to say "only dep-pkg from that exact repo is
> 100% works as expected", so there is still the chance, that someday pkg4
> would fail to build because suddenly pkg3 was reinstalled from another
> "incompatible" repo...
> And, honestly, current ways to resolve that issue (adding
> dummy-useflags, copy_here&rename, and so on) looks as very dirty hacks.
[Note that while the following is written using second-person "you",
nothing personal or accusatory intended. I simply started with second
person and then realized half way thru that because it was written in
second person it could be taken as offensive, which wasn't my intent, but
didn't want to go back and adjust the whole thing to detached third-party
viewpoint just to keep the technical point I had already made, so I chose
the disclaimer method instead. And as a second disclaimer, please see
the last paragraph; maybe I'm missing the obvious...]
Actually, I'd argue that the problem as described is well within what USE
flags are designed for, and that using a USE flag in this case makes
/perfect/ sense. Consider the description above:
* pkg2 deps on pkg1, both of which are in your repo.
* But your pkg1 is different in some way, custom patch set, say, or lua
eclass support from its overlay.
* Your pkg2 deps on that difference.
Seems a perfect match for USE flag deps to me. Make your pkg2 dep on pkg1
conditional on a USE flag added to pkg1 when you changed it from what's
likely to appear in gentoo or another overlay, making that change in
behavior conditional on the USE flag and setting it up so flag-missing
behavior is -flag.
Problem solved.
That creates an optional change in behavior toggled by a USE flag, and
makes some other package dependent on that option by depending on that
USE flag. Isn't that exactly what USE flags and USE flag deps are
/supposed/ to do?
Of course that pre-supposes that you want to go to all the work of doing
it /correctly/ and making your change fully optional and togglable by
individual per-package USE flags and deps that fit the individual cases,
instead of taking the hacky shortcut of simply hard-coding your copy to
do it your way, but "dummy USE flags" that do nothing but control the
repo, because the behavior is hardcoded instead of setup via actually
togglable USE flag aren't any more hacky than that hard-coding that makes
them required in the first place. It's really just part of the same
hack, and if you're satisfied with the hacky hardcoded shortcut, it seems
you should be satisfied with the hacky USE flag to make it work because
you hardcoded the behavior as a shortcut instead of making it properly
togglable, as well.
But if you /do/ want to simply take the expedient route and do hacks such
as hardcoding choices (hey, I've taken the hardcoded behavior shortcut
myself a few times) etc, and you're doing it pretty much globally,
affecting many otherwise independent things thru the entire overlay, then
it would seem to me that the most efficient method would be to simply do
the fake-flag (call it overlayname-hardcoded or some such, obviously
replacing overlayname as appropriate) hack by policy, adding it to your
global USE flag settings in make.conf, and to every package as soon as
you add it to your overlay. Then you can depend on the flag as
necessary, without having to worry about what it does in an individual
package.
Tho even that's actually pretty comparable to how users work with global
USE flags. And if it's named overlayname-hardcoded or similar, you /are/
actually describing the USE flag, and how you're using it in the deps,
reasonably accurately, even if there's no actual option to turn it off in
the packages in your overlay.
... Tho it's quite possible there's holes in this argument that I'm
simply not seeing, thus making my posting as much or more about asking
others to point out the holes I can't see, so I /can/ see them, as it is
about attempting to convince anyone of the correctness of my viewpoint as
I'm posting it. Sure I could be wrong, but if I am, please point it out
so I can see it 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-dev] Re: Mailing list moderation and community openness
tial need will not find it worth their while to be toxic here once again, but with the capacity to reinstitute should they do so. (Yes, I know that unused tools fall into disrepair over time, but often, repair, or even redo if necessary, is easier the second time around. So hopefully the capacity would remain available or at least easier to implement again, if again needed.) (Points B and C omitted as infra specific, because I've nothing to add.) > d) Infra as a organization wields a lot of power in Gentoo and I think > its organizationally dangerous to wield that power in this way. [...] > e) In the past, infra *has* wielded its power in a fashion that had > negative impacts on the distribution (e.g. arbitrarily removing commit > rights for developers with no warning, process, or oversight). Having lived thru much of that, I 100% agree that it's not something gentoo should ever want to go back to. While individuals are certainly free to resign should they feel the need, having even infra subject to an _elected_ council is a _good_ thing! Meanwhile, I've already stated my position. I'm sad to see it come to this, and hope it to be eventually reversed, but the elected council has spoken, I understand the events that lead to their decision, and remain and abide is my chosen option. And as for the effect on my own posts as a non-dev, personally... * My posting intent on any list, including this one, is positive contribution. Should I ever believe my posts have ceased to be that, I'll immediately apologize if it was one-off/short-term, or stop posting if I don't believe my posts to be a positive contribution going forward. (I've often spent quite some time composing a post, only to ultimately close the window without sending, because on consideration before hitting send, I decided it wasn't unquestionably a positive contribution to the list/discussion in question. Sometimes just writing it for me was what I needed to do. Sometimes I simply thought better of it, period.) * I'm acutely mindful of the fact that this _is_ gentoo-*dev*, and that as a user, not a dev, I'm but a guest here. (And yes, that sometimes influences my "don't send it after all" decision.) * While there are complaints of my verbosity, I've never been /banned/ and I'm proud of that. * I've had personal offers to whitelist, for which I am grateful. (The given reason was that while I'm often too wordy, I often do have a valid point/question, that may not have been brought up by others. I do struggle with the wordiness, believe me, but I'm grateful that at least some devs consider my posts a positive enough contribution to extend the whitelisting offer.) * For the time being, I've thanked, but turned down that whitelisting offer. When I'd otherwise post, I'm going to take the opportunity to reconsider the positive contribution of my posts even more, try again to whittle down the wordiness further, and then, if I still consider it worth the effort, I'm going to forward the post to the person I'm replying to or possibly to someone else (like the person who offered the whitelisting), asking them to forward it... but *only* if they too consider it a positive contribution to the current discussion. Tho I may eventually request whitelisting, in the mean time I intend to learn what I can from the forward/rejection/rejection-with-feedback on those attempted contributions, to try to make future attempted contributions even better! =:^) That's keeping in mind that as a user not a dev, I /do/ consider myself a guest on this list, and arguably, posting to it has /always/ been a privilege, not a right. And given the coming whitelisting, devs, thru their elected council, have clearly expressed their desire to cut down the outside noise from "guests", ensuring that any such "guest posts" allowed thru are signal, not noise, or worse yet, negative signal. As one of those guests, abiding by that expressed intent to the best of my ability is my goal, and I intend to take the presented opportunity to try to improve my own attempts at contribution! -- 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-dev] Re: News Item v2: Portage rsync tree verification unstable
Zac Medico posted on Sun, 11 Mar 2018 19:57:31 -0700 as excerpted: > I really don't want to spend a lot of time making revisions, and I think > "unstable" communicates well enough in this case. Very well then. With robbat2's already accepted first paragraph changes it's acceptable as-is. Thanks. You put an awful lot of work into portage, and I'm sure I'm not the only one who's thankful there's a steady hand at the portage wheel, even if it doesn't always come thru. Your efforts certainly make the gentoo experience a better one! =:^) -- 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-dev] Re: How to deal with git sources?
Mike Auty posted on Sun, 11 Mar 2018 19:19:00 + as excerpted: > tldr; Github will tarball up specific commits (or master) for you to add > to SRC_URI. > > I ended up using the github API to pull down a tarball of the git repo, > rather than using git to pull it down. I suppose that offers the > ability to Manifest it and check for changes, but I now have to encode > the fixed commit into every version of the ebuild because the only > location it's recorded is in the submodule commit hash of the package's > repo. Please check... If I'm recalling correctly a warning posted on this list, repeated calls to the github tarballing API for the same commit will result in delivery of tarballs with differing checksums. How/why wasn't explained as I recall, possibly part of the reason I'm not sure I'm recalling things correctly as that would have internally flagged it as unreliable/needing- verification, but that was the warning as I remember it. If it's correct, you can pull the tarball from github to store on devspace and link it as the checksummed tarball, as that's static and won't change, but you can't link the github tarballing API directly, as that /will/ change and thus will fail sources checksum verification at least some of the time. But (assuming avoiding linking devspace is worth the trouble in the first place if possible) either verify it yourself or wait for verification/ negation from others, as I'm not entirely sure I'm recalling that warning post correctly. It might have been for other than github, or I might have misunderstood, or maybe they've fixed that problem by now, or... -- 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-dev] Re: News Item v2: Portage rsync tree verification unstable
Zac Medico posted on Sat, 10 Mar 2018 15:16:29 -0800 as excerpted: > Changes: > * First paragraph rewritten by Robin Johnson > * Fixes spelling of 'following' reported by Michael Everitt > > > Title: Portage rsync tree verification unstable > Author: Zac Medico > Posted: 2018-03-13 > Revision: 1 > News-Item-Format: 2.0 > Display-If-Installed: sys-apps/portage > > Portage rsync tree verification is being temporarily turned off by > default, starting with sys-apps/portage-2.3.24. This permits > stabilization of sys-apps/portage-2.3.24 while still working on bugs > relating to tree verification [1]: deadlocks [2] & key fetching [3]. > [...] With robbat2's first paragraph rewrite the effect isn't quite as bad as that of the first draft, but the title still refers to "unstable", which in addition to the intended package-stability meaning, has a number of more severe and thus unnecessarily alarming meanings not intended here. FWIW, being security minded and knowing verification related to security, my own first thought was an app instability due to a potentially exploitable buffer-overflow... in code dealing with verification and thus potentially remotely triggerable during verification itself, definitely more alarming than intended! Thankfully robbat2's rewrite clarifies in the body now, but I still think the title remains overly alarming. Maybe "... remains unstable" or "not yet stable", as in: Title: Portage rsync tree verification not yet stable Or better, refer to the FEATURE flag "rsync-verify" in the title, so it's clear it's not a portage/emerge-executable instability, and clarify that it's the stable keyword, something like this (but might be too long, do those news item short title limits still apply?): Title: Portage rsync-verify feature not yet stable-keyworded Perhaps omit the -keyworded if that's too long: Title: Portage rsync-verify feature not yet stable Feel free to revise further... -- 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-dev] Re: Make it easier to check upper bounds with repoman.
crocket posted on Thu, 01 Mar 2018 21:15:24 +0900 as excerpted: > https://github.com/gentoo-haskell/gentoo-haskell/issues/669 led me to > https://bugs.gentoo.org/555266 > > In other words, since repoman doesn't warn a repository manager about > upper bound violations, the manager often breaks dependencies. > It is often a problem with haskell overlay. > > Do developers oppose https://bugs.gentoo.org/555266 ? > What do you think of the issue? No apparent opposition, just not sufficient interest or need (at least since 2015, when the bug was filed) from those with the necessary coding skills to push it up in priority enough to get a patch for repoman. There has simply always been something else with a higher priority. Apparently haskell is most affected, but presumably nobody with the haskell team has either the repoman familiarity or the time to get it, prioritized high enough based on the severity of the problem to actually do something about it. So the problem remains... -- 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-dev] Re: newsitem: baselayout 2.5 changes
William Hubbs posted on Sat, 10 Feb 2018 12:15:43 -0600 as excerpted: >> # shouldn't appear on a desktop/workstation system, but bugs... >> /srv -> tmp > > Keep in mind that /tmp is wiped during a reboot, so /srv should be > separate from /tmp. FWIW that was deliberate. Indeed, /tmp is tmpfs here. =:^) TL;DR: Stop. The package in question (some indexer kde4 used for its handbooks, IIRC, I'm not even sure it's still needed for frameworks-5 based handbooks or whether it's still installed) is primarily used in web servers and the like, and installed something in /srv to facilitate that. But I didn't need it, was irritated by it, and decided to set things up both to make it temporary, and to create an extremely obvious failure if anything else should ever install anything to /srv that I might actually need more permanently, so with more information if it ever triggered, I could decide on appropriate measures. FWIW, nothing has ever triggered it, so if anything else is or has installed anything to /srv, it's obviously not anything I depend on after a reboot. Of course I could do something similar with a global INSTALL_MASK, but having it pointed at a tmpfs instead lets me examine what's actually installed, if necessary. -- 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-dev] Re: newsitem: baselayout 2.5 changes
William Hubbs posted on Sat, 10 Feb 2018 12:43:08 -0600 as excerpted:
> This is all very custom (Gentoo makes these things as directories when
> the stages are built, so it won't be an issue for a default
> installation).
Of course Gentoo is a rolling distro... no need to periodically reinstall.
While I'm almost certainly an extreme example, people /will/ have a "non-
default" install in one way or another after say a decade-ish of
rolling. After all, if they weren't interested in that sort of "power"
modifications, they'd likely be long gone well before the decade, off to
some "easier" distro as it wouldn't be worth their trouble.
FWIW I've been continuously rolling the same original install forward
thru hardware, software, and needs changes, for nearing a decade and half
now. I'd argue it'd be the rare Gentoo install indeed that remains
"default state" after that sort of time.
Which is why these news items are so critically important. Ideally, they
provide not only a "default install" recipe, but two additional pieces of
critical information as well:
1) What sort of non-default site/install mods are likely to be affected.
(These need not be too specific, just something like, in this case,
"People with symlinks to alternative directory locations or similar site-
specific solutions may need to take particular care here. ...")
2) Preferably some hint at what might be needed.
("... Refreshing your backups before the upgrade and checking site-
specific solutions after the upgrade before reboot, is recommended.")
Because it's a system-critical package this becomes even more important.
(And FWIW, getting a longer heads-up to such changes is a primary reason
I read this list.)
--
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-dev] Re: newsitem: baselayout 2.5 changes
William Hubbs posted on Thu, 08 Feb 2018 13:52:56 -0600 as excerpted: > here is a proposed newsitem for baselayout 2.5. > There are three significant changes in baselayout-2.5. > > The first change is that ROOTPATH is no longer set. This means all of > the *sbin directories will be added to the default path for all users > instead of just the root user. Makes sense and is important for users to know. > I know of no packages outside of > baselayout that used the ROOTPATH variable; however, if packages do use > it, they will need to be adjusted to use PATH instead. Omit that as dev, not user, focused? > The second change is that baselayout is taking ownership of most of the > directories it creates. This includes all directories in / and /usr > excluding /lib* and /usr/lib*. Once we drop support for SYMLINK_LIB, > baselayout will take ownership of /lib* and /usr/lib* as well. What's the effect if the "directory" is a symlink to elsewhere? Here, the following system "directories" are actually symlinks: # makes installing grub to multiple devices much easier /boot -> /bt # "reverse" usrmerge /usr -> . # would be /usr/games, but with reverse usrmerge... /game -> . # shorter path /home -> h # lib(64) merge (including /usr/lib(64) /lib -> lib64 # would be /usr/local, /l is so much shorter /local -> l # (s)bin merge (including /usr/(s)bin) /sbin -> bin # shouldn't appear on a desktop/workstation system, but bugs... /srv -> tmp # shorter log path (/lg as /l already taken by local) /var/log -> /lg > Third is the beginning of support for the /usr merge through the > addition of the usrmerge use flag. > DO NOT, DO NOT TURN THIS ON UNLESS YOU KNOW WHAT YOU ARE DOING AND CAN > HELP WITH TESTING. What about "reverse" usrmerge as above? Flag on or not? Maybe I just turn it on (obviously after updating my backups) to help test? -- 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-dev] Re: SAT-based dependency solver: request for test cases
Michael Lienhardt posted on Tue, 06 Feb 2018 23:53:05 +0100 as excerpted: > Il 06/02/2018 15:00, Roy Bamford ha scritto: >> Posting here to alert other potential helpers. >> Your script uses >> >> PACKAGE_KEYWORDS="/etc/portage/package.accept_keywords" >> >> but thats a recent name change. >> >> PACKAGE_KEYWORDS="/etc/portage/package.keywords" >> >> is the old name and my older systems still use that. >> You probably need to harvest both and process both as portage does. > > You are right, I was lazy (and hoped that everyone already made the > switch because, as I understand it, package.keywords and > package.accept_keywords do not have the same semantics). > I added the package.keywords file/folder in the script. AFAIK, (plain) etc-portage semantics are the same for both files -- that is, /etc/portage/package.keywords and the newer package.accept_keywords are identical. The reason for the new name and deprecation of the old one was that package.keywords also exists in the /profile/, where the semantics are different, which created confusion for devs and others attempting to edit the profile version as well as the more commonly user-edited (plain) /etc/portage version. (I add the parenthesized "(plain)" because there's also the deeper /etc/portage/profile path, which takes profile changes and therefore the profile format. Actually, I suspect it was someone editing that using the wrong format and then filing a bug when things didn't work as expected that likely prompted the new name and deprecation of the old one.) Meanwhile... I've a rather unusual portage config here: * /etc/portage/profile/packages contains a -* entry, negating the entire normal @system set. Many normally @system packages I really need are dependencies of something or other I already have in @world anyway, and I've added @world entries where necessary to keep the few exceptions installed. * My USE starts with a -* entry as well, negating profile and package USE defaults so I have direct control of all USE flag settings and don't have to worry about USE flag changes on profile updates or tracking down why a flag is changing when I didn't change anything, both previous problems I had to deal with until I set that initial -*, so the only flags set are the ones I deliberately chose, myself. * My world file (/var/lib/portage/world) is empty. I've categorized everything into individual sets found in /etc/portage/sets, with those in turn listed in the world_sets file (/var/lib/portage/world_sets). * Overlays... (Less unusual, but still not mainline...) I run nearly all the kde I have installed (frameworks/plasma/apps), as well as a few other packages, from the live-git *- packages found in the gentoo/kde overlay (and others). Package keywording/masking is adjusted accordingly. (Everything else is mainline ~amd64.) I expect one or more of these you won't have anticipated so they'll present a challenge for your current script, but because it /is/ a rather unusual setup, I'm not sure it's worth your trouble to bother with. OTOH, if you want unusual corner-cases to test... So bother sending the results in (you're ready for it already), or you want them, but wait until you've adjusted the script to deal with it, or don't bother, you're not going to try supporting anything that unusual 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-dev] Re: [News item review] Portage rsync tree verification (v4)
Michał Górny posted on Sun, 28 Jan 2018 09:58:37 +0100 as excerpted: > The new verification is intended for users who are syncing via rsync. > Verification mechanisms for other methods of sync will be provided in > the future. > > This does not affect users syncing using git and other methods. > Appropriate verification mechanisms for them will be provided in the > future. Sorry I didn't catch this sooner. Now we have a repeat. Maybe combine the two paragraphs like this: The new verification is intended for users who are syncing via rsync. Users syncing using git or other methods are not affected, and verification for them will be provided in the future. -- 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-dev] Re: [News item review] Portage rsync tree verification (v3)
Michał Górny posted on Sat, 27 Jan 2018 15:26:44 +0100 as excerpted: > The new verification is intended for users who syncing via rsync. > Verification mechanisms for other methods of sync will be provided in > future. s/in future/in the future/ Thanks for adding that paragraph. It perfectly addresses the question I had about the original. =:^) -- 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-dev] Re: Why are ebuilds licensed GPL v2 only (no later version)?
Luigi Mantellini posted on Fri, 26 Jan 2018 16:02:39 +0100 as excerpted: > can help? > > https://lwn.net/Articles/74055/ Thanks. I'd forgotten the (long) post I made there, but while it doesn't talk about the GPLv2-only stuff, it certainly reflects the zynot stuff in far more detail than I remembered or would write it again here. (I had more written but deleted it as OT.) -- 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-dev] Re: Why are ebuilds licensed GPL v2 only (no later version)?
Ulrich Mueller posted on Fri, 26 Jan 2018 10:36:49 +0100 as excerpted: > Apparently licensing of the Gentoo repository was changed from GPL-2+ > to GPL-2 (only) in 2002, see for example [1] and [2]. I cannot find any > announcement or discussion about this. > > Who was around in 2002 and still remembers what was the rationale? > > Ulrich > > [1] > https://gitweb.gentoo.org/repo/gentoo/historical.git/commit/skel.ebuild? id=e67af11c176e4dca33846e65c2649aa456de3099 > [2] > https://gitweb.gentoo.org/repo/gentoo/historical.git/commit/header.txt? id=dc4dfe8aa903fb467e648da80f8bc3178411a77a I wasn't around in 2002, but I was researching it by late 2003 and began installing in early 2004, by which point Gentoo was suffering the aftermath of the bitter split with Zynot and DRobbins was pretty much out after having set up the Gentoo Foundation and (what became the) Council. The Zynot side was focused on embedding and trying to take things commercial, while accusing DRobbins of trying to do effectively the same thing but with a(n IIRC) gaming focus. That war has long since been fought and history has played out with Gentoo still around and Zynot... not, so I'll try to avoid inserting opinion /too/ much (tho I'm sure more recent events played out how they did in part due to that history, people around then simply weren't interested in what must have sounded rather similar), but... The switch to GPLv2-only would have been made in the fight for its life that was the Gentoo/Zynot fork, and almost certainly had to do with trying to ensure that the gentoo/x86 tree could not be taken private without community recourse, in an era before GPLv3 existed and there was some uncertainty about what its legal terms were going to be, while those of the GPLv2 were known, it had broad community support, and was at least /somewhat/ legally tested. Of course as we know it's possible for an entity owning copyright on a GPLed work to also sell the rights to use it commercially, with the GPL preventing others from doing the same, and that's what both sides were accusing the other of trying to do, but as we've seen play out in other contexts, the one thing the GPL /does/ do is provide a guarantee that the code as-is will remain free, and community improvements to it without a CLA letting the entity trying to take it proprietary are then disallowed from being used to further that entity's plots. With the uncertainty surrounding the still coming GPLv3 at that point, I believe the intent was to ensure that continued. OTOH, those on the Zynot side would surely argue that the intent was to ensure that Zynot couldn't take it private, while Gentoo/DRobbins could, especially since at the time copyright was assigned to Gentoo. Of course now we have the advantage of looking back it it in history and can see how things turned out, but back then, it was far less clear how things would turn out. -- 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-dev] Re: [News item review] Portage rsync tree verification
Michał Górny posted on Thu, 25 Jan 2018 11:04:27 +0100 as excerpted: > Hi, > > This one would be committed once new sys-apps/portage release is wrapped > up and hits ~arch. > > --- > Title: Portage rsync tree verification Might want to put a paragraph in there saying git sync users can ignore, or how they can get gpg signature verification as well if its possible. (Sufficient to just link it if it's more involved than a single paragraph, since this is primarily for rsync users.) -- 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-dev] Re: version/slot locked dependencies in eclasses like autotools.eclass and vala.eclass
Michael Orlitzky posted on Mon, 22 Jan 2018 10:04:30 -0500 as excerpted: > On 01/22/2018 05:10 AM, Duncan wrote: >>>> >>>> If the dependencies are to remain in the eclasses, then the eclasses >>>> should get a new revision when those dependencies change. Afterwards, >>>> the consumers can be revbumped and stabilized normally to utilize the >>>> new eclass. >>> >>> Sounds good! >> >> How does that work with live-vcs ebuilds, aka - ebuilds? >> >> > It doesn't. As with upstream code changes, you have to figure out > yourself when it's time to re-emerge a live ebuild. Thanks for the confirmation. Hmm... I wonder if @smart-live-rebuild could (without /too/ much trouble) be made to detect upgraded deps, comparing the live repo version against what's in /var/db/pkg/, as it already does for upstream changes? If it already has the feature I've not seen any indication of it from the output. All the updates I've seen appear to be due to upstream repo updates. -- 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-dev] Re: version/slot locked dependencies in eclasses like autotools.eclass and vala.eclass
Zac Medico posted on Sun, 21 Jan 2018 22:20:21 -0800 as excerpted: > On 01/21/2018 08:57 PM, Michael Orlitzky wrote: >> On 01/21/2018 11:24 PM, Zac Medico wrote: >>> >>> Some eclasses like autotools.eclass and vala.eclass generate >>> version/slot locked dependencies that cause the dependencies of >>> inheriting ebuilds to change when the versions in the eclasses are >>> updated. If possible, it would be nice to avoid this version/slot >>> locking. If not possible, then what should be do? >>> >>> >> This changes the deps in stable ebuilds, and was already a no-no. >> >> If the dependencies are to remain in the eclasses, then the eclasses >> should get a new revision when those dependencies change. Afterwards, >> the consumers can be revbumped and stabilized normally to utilize the >> new eclass. > > Sounds good! How does that work with live-vcs ebuilds, aka - ebuilds? To date I've seen very few if any --rX ebuilds, I've assumed because they'll be rebuilt if the sources change anyway, and with @smart-live- rebuild upstream changes are detected and trigger rebuilds automatically. But now we're talking gentoo level dependency changes that either don't match a specific upstream change or that occur *after* the upstream change, so there may /be/ no timely upstream update to trigger a rebuild. Does this then mean we should be getting --rX revision bumps now, for gentoo level dependency changes? If so, gentoo/kde's overlay... and I since I run live-git of nearly everything kde here... are in for quite some hundreds-of-packages-at-once fun when those eclass dep-bumps occur... (Tho it can't be /that/ bad, since I've been running with --dynamic-deps=n for years now, and without --changed-deps for I'd guess a year or so now. And upstream does mass version and dep bumps regularly already, triggering the mass rebuilds even if that's the only commit, so I suppose another triggered rebuild when gentoo/kde revbumps after dep-bumping to reflect what upstream already did, won't be /that/ much different or /that/ much more work. Only now I guess I'll be seeing it in --rX revbumps, 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-dev] Re: Managing updates on many identical Gentoo systems
Anthony G. Basile posted on Thu, 18 Jan 2018 06:46:53 -0500 as excerpted: > I'm trying to design an update system for many identical Gentoo systems. > Using a binhost is obvious, but there are still problems with this > approach. > > Unless there's some magic I don't know about (and this is why I'm > sending this email) each machine still needs to have the portage tree > installed locally (1.5 GB) or somehow mounted by a network filesystem > (which is not practical if the machines are not on a local network). > Furthermore, each machine would have to run emerge locally to do the > calculation of what packages need updating. > > This procedure is redundant because each machine is housing the same > data and doing the same dependence-tree calculation. I had a gen-1.5 32-bit netbook for a number of years, that I updated using rsync from a 32-bit chroot on my main machine, no portage tree on the target netbook, tho I didn't worry about separating out build deps from run deps. That was a single machine config, but it should be even easier if you're running nearly identical machines and thus don't need the separate chroot build image. If you have temporary networking you can rsync directly machine to machine, as I did after I was fully setup, but at first I was sneaker- netting it, rsyncing to a thumb drive from the build machine, that I would then plug into the target and rsync thumb drive to target. The thumb drive was bootable, and I used it to do the first gentoo boots on the target as well, testing my config and updating as necessary as I went. When I got everything I initially wanted booting from the thumb drive, I booted the thumb drive, wiped the initial Pingus Linux on the netbook and setup the partitioning, etc, then rsynced selected bits into the appropriate place on the target. For multiple nearly identical machines you can exclude the non-identical bits from the primary rsync image, keeping the specific bits in individual images synced on top of the primary. Of course you can sync in reverse as well to keep the non-identical bits updated, giving you a nice backup of each one as well. =:^) Alternatives would include simply creating the thumb drive once and then cloning it enough times to give every machine a bootable thumb drive copy (using symlinking and/or mounts to handle the non-identical stuff, so simply toggling a symlink lets you switch machine layouts), or if the machines have enough memory, setting up a single thumb drive to boot and put everything in a tmpfs for the machine to run from, so you can use the same thumb drive to boot them all, effectively the sneakernet version of net-boot. -- 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-dev] Re: News Item: GnuCash 2.7+ Breaking Change
Kristian Fiskerstrand posted on Tue, 16 Jan 2018 15:58:11 +0100 as excerpted: > On 01/16/2018 03:45 PM, Aaron W. Swenson wrote: >> Given the situation, we have a choice: Remove GnuCash altogether, or >> press ahead with recommending a version upstream considers unstable. > > Or 3, discuss with upstream to see if they can release an updated > version as stable branch. This reminds me very much of the long-time stability situation with grub-0.9x vs. 1.9x. Upstream insisted 0.9x was unsupported, and indeed, had abandoned it, such that it was the distros carrying upstream- unapproved patches, but at the same time, pre-2.0 as 1.9x was still very much development-only and not ready for prime-time, according to upstream. Just what were distros and users /supposed/ to do? Both that and this gnucash thing are bad situations all around, but perhaps some lessons can be had. And agreed that surely the first must be to /just/ /ask/ upstream whether they can release something stable that's at least based on something still getting maintenance, security and otherwise. Then go from there. Maybe they'll refuse and we'll have to move ahead with the new version regardless of upstream's wishes, but we'll never know if we don't ask. (Of course it can go the other way too, upstream insisting the new version is stable even when it's still broken for normal users every which way to Sunday. The kde3/kde4 transition is a prime example of that. I honestly don't know which is worse, but the obvious ideal is a sane upstream that doesn't veer to either extreme, or lacking that, at least cooperates and provides support when a new at least /semi-/stable release is needed as the old is just outdated and broken, security or otherwise.) -- 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-dev] Re: Upcoming posting restrictions on the gentoo-dev mailing list
Andreas K. Huettel posted on Thu, 11 Jan 2018 02:12:47 +0100 as excerpted: > Am Mittwoch, 10. Januar 2018, 18:16:33 CET schrieb Vincent-Xavier JUMEL: >> Le 2018-01-10 10:53, Michał Górny a écrit : >> > Last I checked, Gentoo was a Linux distribution. However, some people >> > prefer to turn it into open discussion forum that has nothing to do >> > with making a distribution. >> >> No it has. Giving power to a subset of users, denying interaction with >> future contributors unless they enroll is the eaxct way to kill Gentoo >> as a community ! > > We wouldn't have needed to go this far if not for a few outside trolls > who > * keep pushing their personal agenda in endless threads, > * confuse their own inability to contribute with being a mistreated > underdog, > * and keep commenting opinionated on technical things they > plainly have no clue about (while whining when are told they sprout > bulls##t). > > We do not have a problem with "future contributors". I wager those will > rather increase in numbers once the list spam is gone. This has been my biggest concern about the whole thing: Are we going to be nipping future devs in the bud because there's now too many hoops to jump thru too early, and it's simply not worth the trouble when they can (and will) go elsewhere where it's easier, OR Are we going to be lowering the unwelcoming noise, confusion and name- calling threshold and making the community more welcoming for those who have a serious interest, clearing out some of the stuff that could otherwise discourage them. It's pretty clear that council believes it's the latter, at least to the degree that they're willing to try it for a time, effectively a wager of sorts, but I don't believe anyone can honestly say what the real effect one way or the other will be until it /is/ tried. Personally, my viewpoint is that while over the last year or so there were some 1-2 level frustrating posters on a 5-point scale, it's nothing compared to the level-4 (direct name calling, just short of physical threats that justify getting the law involved) stuff that I've seen on this list in the some-years-distant past. In my mind, unquestionably that level-4 stuff required action, and it was taken. The recent stuff seems so much milder in comparison that IMO it's hard to see what the hubbub is all about, but there's certainly an argument to be made that the previous experience simply desensitized our detection meters, and that were it not for that, the recent stuff would seem rather more shocking and horrible than it does, and that even if it's /less/ horrible, it's horrible /enough/ that it remains unacceptable in a civilized society, and if we /do/ accept it, we're effectively pushing others that won't, out. So I'm worried; I honestly don't know which way this will go, but I expect it /will/ have a noticeable impact one way or the other. Of course as others I do wish it never would have come to this, as well, but then again we live in a world where some people will always be pushing the borders, no matter where they are set, and where regardless of where the line is drawn, some people will be excluded, ether because of the abuse they refuse to tolerate so they go elsewhere, or because of the infringement of what they see as rightful liberty to heap that abuse on others, so they go elsewhere. But the council has made one of the hard calls they're elected to make, for which tho I may be worried I can't fault them, and now we get to see how it all plays out. But whether they, and gentoo as a whole, wins that effective wager, or loses it, the bet has now been placed, so nothing to do but wait and see the 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-dev] Re: Last-rites: media-video/2mandvd
Andreas Sturmlechner posted on Tue, 09 Jan 2018 02:49:27 +0100 as excerpted: > # Andreas Sturmlechner (09 Jan 2018) > # Dead upstream, depends on dead Qt4. > # Bug #643976. Masked for removal in 30 days. > media-video/2mandvd Is there a timetable for the "dead" qt4 removal yet? Where will it go when removed, kde-sunset, graveyard, or...? I'm asking because I still run the not in-tree any longer superkaramba, which wasn't ported to kde-frameworks5/qt5. That's the only package (beyond a handful of kde4 packages and use-flag-triggers on other packages supporting it) I have still depending on qt4, so a timetable as to qt4 removal giving me some idea how long I have to find, install and configure an alternative, and an idea where I'll be looking for it if I don't get that conversion done by then, would be very 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-dev] Re: Dropped EAPI 2/3 support in virtualx.eclass
Justin Lecher posted on Sat, 06 Jan 2018 13:23:12 + as excerpted: > As there are no consumers [1] of the virtualx.eclass using ancient EAPIs > I dropped support for EAPI=2/3 > > Best, > Justin > > 1) https://qa-reports.gentoo.org/output/eapi-per-eclass/virtualx.eclass/ > > > diff --git a/eclass/virtualx.eclass b/eclass/virtualx.eclass Dropped, past tense, the commit is already made to the tree, or will drop using that diff, assuming no strong objections here? Keep in mind that people may still be using it in the overlays even when it's out of the main tree. That isn't on its own a reason to avoid dropping it from the eclass in the tree, but part of the idea of posting such changes here is to at least warn people maintaining overlays that /might/ use it, so they can either port or grab a copy of the eclass for their overlay before the change. So that past-tense "dropped", if indeed that's what it was, looks a bit rude, not giving notice at all. But if it's "dropped in this patch, but this patch not yet applied, so will drop in the tree when it is", carry- on with the usual timing, then. =:^) (My non-scientific observation seems to indicate at least a week of notice appears to be the norm, if there's no substantial changes suggested or a wait requested. If there's a wait requested, for out-of- tree I'd say perhaps a month, max, no longer necessary for out-of-tree unless you simply want to be extra nice, because if nothing else they can just grab a copy before the change and if they can't even do /that/ in a month... . Beyond that and the old version can always be dug out of git if necessary.) Either way, thanks for the cleanup. =:^) -- 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-dev] Re: Deleting old news items
Michał Górny posted on Sat, 06 Jan 2018 00:55:58 +0100 as excerpted: > W dniu pią, 05.01.2018 o godzinie 23∶09 +0100, użytkownik Kristian > Fiskerstrand napisał: >> On 01/05/2018 10:28 PM, Aaron W. Swenson wrote: >>> On 2018-01-05 15:16, William Hubbs wrote: >>>> If we have a default expiration, it should be one year after the >>>> date posted to go along with our current policy of not supporting >>>> things that are older than a year. >>> >>> I thought it was three years. AFAIK, the one-year policy is on upgrades-from. If a user hasn't synced and updated in a year, updating is likely to be "problematic", and may require techniques such as digging old tree states a year or so apart out of git and using those to update a year's worth of updates at a time, and/ or updating the system in increments, the few packages that will update successfully first, then trying again to get the ones that can now update due to the improved base of the first set, and again... It helps if there's other systems you keep more current, so you've already dealt with most changes one or a few at a time. I know this from experience as while I keep my main system current (I'm antsy if it's more than a week between syncs), I used to have a 32-bit- only first-gen atom, that I built updates for in a chroot and synced over, that I'd sometimes go over a year between updates on. (Personal policy was nothing private on that machine, and it was normally not internet connected, so I wasn't horribly worried about security.) So over a year, while the above update method is normally still /possible/, the easier/recommended/supported method is simply using the old install to fetch a new stage-3 to a chroot, and install new to it, except that you can "cheat" by basing your new config including USE flags, etc, off the old one. The 3-year may well be for individual packages, but all I've ever seen for the entire tree and full system update is 1 year. >>> At any rate, I think a year is too short. >>> >>> How about 18 months? That seems a reasonable default... >> I might sound like a broken CD here, but why define the expiration as >> part of the news format instead of specifying it in the package manager >> as a user defined variable? Various use cases requires different >> treatment, so leaving it up to user seems more relevant to me, and we >> could allow information to be presented as part of stages to give a >> hint for what dates to look for? >> >> > To be honest, I kinda agree with Kristian here. I feel like this header > isn't going to work well. > > While the idea may initially sound good, I'm afraid we'll have the usual > developer split here: some developers will set very long times, some > will set very short times, some will not care and just copy some random > value (default, the value from some other news item). In the end, users > will end up seeing very old news items from dev X, while newer items > from dev Y will disappear. > > So yes, I think having a single predefined time is better, > for consistency at least. And allowing user to adjust that time based on > his own is certainly better than making it only dev-settable. $ equery b news.eselect app-admin/eselect-1.4.10 (/usr/share/eselect/modules/news.eselect) So in that case it's not the PM, but eselect. But a new eselect version that ships a default /etc/eselect/news/expiry that looks something like this: # Days after which unread news messages will no longer be shown # Default is 548, 18 months, (365*1.5 rounded up) expiry=548 ... and which then looks there for the value, seems reasonable to me. * Being in /etc the file would be subject to normal config-protection. * Can be accomplished with a bit of code and simple eselect package version bump, presumably with a post-install message mentioning the new config option. No need for all the bureaucracy of a GLEP update, etc. * Handbook and etc. documentation that I believe already mentions news and suggests eselect news as the default reader can be updated to mention this config option as well. * A news item announcing the new default expiry and config for it might be appropriate as well. * Should that general approach be agreed, all that would remain to debate would be whether 548 days (365*1.5 rounded up) is appropriate. The precise config file path, name and format would be up to the implementer and/or eselect news module maintainer. * Other news readers could of course set and ship their own default expiry, if desired. -- 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-dev] Re: RFC: News: systemd sysv-utils blocker resolution
Mike Gilbert posted on Sun, 24 Dec 2017 19:38:30 -0500 as excerpted: > There has been a bit of confusion over a change I made recently. I would > like to publish a news item before the relevant version of systemd is > marked stable. > > Any suggestions are welcome. > > -- > > Title: systemd sysv-utils blocker resolution +1 The news item reads very clearly to me. =:^) Thanks especially for explicitly including the list of symlinks and that sysvinit otherwise provides those files, as well as the explicitly suggested equery depends line for those who 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-dev] Re: The problem of unmaintained packages in Gentoo
Kent Fredric posted on Sat, 23 Dec 2017 10:25:51 +1300 as excerpted: > On Thu, 21 Dec 2017 12:25:11 -0600 William Hubbs > wrote: > >> I think there's some confusion here. I'm not trying to change the bar >> for ~arch, just trying to understand what that bar is supposed to be. > > The bar for ~arch is "end users should have reasonable expectations that > it mostly works for most purposes, especially those that can be > trivially checked for by its maintainer" > > ~arch will however be imperfect, and there will be issues from time to > time. > > However, the goal is that those issues are not the "easy to find and > obvious" kind, but the subtle and hard to stumble into. > > And I see that as why we have the time interval: Because it gives a good > opportunity for actual real world usage patterns to discover the sorts > of problems that you can't discover by actively looking for them, > the rumsfeldian "unknown unknowns". > > Because realistically speaking, ~arch is the stable of tomorrow. > > The goal is for it to be stable today. > > And when it proves itself ready to be the stable of today, it becomes > the stable of today. Very well said. =:^) I'd simply add a couple points, from a slightly different angle. They're arguably obvious (at least to devs), but equally arguably should be explicitly stated to avoid doubt, and certainly clarified things for me back in 2004 when I was a new gentooer trying to figure all this stuff out. * Because ~arch is intended to be (as the above says) "the stable of tomorrow", with few exceptions it should consist of packages upstream already considers stable releases. As such, the "testing" implied by ~arch is /Gentoo's/ testing, that is, testing of the ebuild and how it interacts with eclasses, profiles and the rest of the Gentoo tree in general, /not/ upstream testing. * The primary exception to the the general rule above is for packages where Gentoo /is/ upstream, such that the most obvious method of testing the stability of the release (by Gentoo devs functioning as upstream) is by releasing it to ~arch, which in this case /is/ upstream's testing. That isn't to say that where Gentoo is upstream ~arch should be alpha quality; the same "obvious bugs should have already been fixed" applies. It simply means the quality of ~arch for Gentoo-as-upstream packages may be experientially somewhat different, perhaps a bit lower, because in that case ~arch is functioning as upstream's testing as well as testing of the Gentoo packaging. This is actually a big reason why I ended up running live-git openrc back when I was running it. Gentoo effectively being upstream and ~arch thus being upstream testing, there were occasional breakages with ~arch openrc packages, and as a normal ~arch user I found it far easier to trace them down when I had full access to the git logs and commit history, as well as a finer grain "multiple pre-release snapshots (effectively a snapshot each time I upstated), less territory to bisect" testing strategy. For portage, by contrast, I didn't end up running live-git, because each release lists the bugs fixed and I can and do at least review their one- line summaries every time I update. Between that and following the patches as they're posted for review in portage-dev (so the release-time bug list is primarily review), I'm effectively following live-git plus reviews anyway, but with the releases as my chosen snapshot frequency. -- 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-dev] Re: [RFC] First (experimental) 17.1 profiles news item for review (v2)
Mike Gilbert posted on Thu, 21 Dec 2017 09:10:09 -0500 as excerpted: > On Thu, Dec 21, 2017 at 2:44 AM, Matthew Thode > wrote: >> On 17-12-21 08:34:31, Michał Górny wrote: >>> W dniu czw, 21.12.2017 o godzinie 05∶29 +0000, użytkownik Duncan >>> napisał: >>> > Michał Górny posted on Wed, 20 Dec 2017 14:40:27 +0100 as excerpted: >>> > >>> > In all this I don't see an answer to one question: >>> > >>> > Will this eventually be the only supported choice, or is the >>> > compatibility-symlinked version going to be supported going forward >>> > too? >>> > If it's to be only-supported, what's the timeline? >>> >>> The former. We'll make a timeline when the profiles are tested and >>> stable. >>> >>> >> What group are the ones making this decision? > > The decision was effectively made by vapier in 2014 (see bug 506276); > mgorny is the one doing most of the work in 2017. There's also a group > of us who have been following the bug and experimenting with our own > systems since then. > > If you disagree with this plan for some reason, please start a new > thread. Reading the bug (506276), it seems to me it's all about /supporting/ symlink=no, discussing migration scripts to make it possible to migrate existing installations, etc, not /mandating/ it. I don't see anything suggesting that vapier, or anyone else for that matter, decided it was going to be the _only_ choice, just that it would eventually be _a_ choice. Much like x32 didn't replace x86 or mulitlib, but became another choice for those who wanted it. Thus the only thing suggesting it'll be mandatory remains the direct answer to my direct question above, asking about it. Meanwhile, I don't really disagree at this point, certainly not if much like usrmerge and (s)bin merge a gentooer is free to decide on their own, regardless of official support for it, but I'm wondering whether that will continue to be the case, or if the test (discussed in the bug) to die if the symlink remains when people are on the new profiles will effectively enforce it against an admin's will, even if that's not the intent. -- 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-dev] Re: [RFC] First (experimental) 17.1 profiles news item for review (v2)
Michał Górny posted on Wed, 20 Dec 2017 14:40:27 +0100 as excerpted: > A new set of 17.1 amd64 profiles has been added to the Gentoo > repository. Those profiles switch to a more standard 'no SYMLINK_LIB' > multilib layout, > and require explicit migration as described below. They are considered > experimental at the moment, and have a fair risk of breaking your > system. We would therefore like to ask our users to test them on their > non-production ~amd64 systems. > > In those profiles, the lib->lib64 compatibility symlink is removed. > The 'lib' directory becomes a separate directory, that is used for > cross-arch and native non-library packages (gcc, clang) and 32-bit > libraries on the multilib profile (for better compatibility with > prebuilt x86 packages). In all this I don't see an answer to one question: Will this eventually be the only supported choice, or is the compatibility-symlinked version going to be supported going forward too? If it's to be only-supported, what's the timeline? Here's why I'm asking: I'm on nomultilib and already have usrmerge (tho reverse, with / being canonical and /usr -> .), and (s)bin merge, so I already have a single canonical /bin and a single canonical /lib64, with various symlinks making the other paths work as well. So there's no reason or benefit to me splitting /lib and /lib64 again, as that would go against the concept of the usr and sbin merges I've already done, and the long-time lib merges that gentoo has had on amd64 since before I switched to gentoo in 2004. I've found I quite /like/ having a single bin dir and a single lib dir for everything, and this would undo that, forcing me to mentally track separate lib locations once again. So I'll probably keep my merged lib here, managing it much like I do my merged bin and root/usr, but it'd be nice to know whether that's going to remain an official layout or not, and if not, what the timeframe for removing it is. -- 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-dev] Re: AMD64 Arch Testers needed urgently
ked into the sponsorship pipeline would take time. I don't have a solution (my reason for posting was to point out that it's not as simple as just dropping stable, not really to provide an answer I don't have), but can note that I believe there's two people now volunteered for it, and of course people have to be aware of it before they can realize their personal stake and thus interest in it, thus this thread... Even if not enough by itself, you gotta start somewhere, and there's at least the two interested, 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-dev] Re: [PATCH 2/2] glep-0042: Update and clarify naming rules.
Ulrich Müller posted on Mon, 27 Nov 2017 00:30:49 +0100 as excerpted: > diff --git a/glep-0042.rst b/glep-0042.rst > index 7726ea4..90ae0b2 100644 > --- a/glep-0042.rst > +++ b/glep-0042.rst > @@ -179,7 +179,9 @@ form ``-mm-dd-short-name``, where ```` is the > year (e.g. ``2005``), > ``mm`` is the month (``01`` through ``12``) and dd is the day of the month > (``01`` through ``31``). The ``short-name`` is a very short name describing > the > news item (e.g. ``yoursql-updates``), consisting only of the characters > ``a-z``, > -``0-9``, ``+`` (plus), ``-`` (hyphen) and ``_`` (underscore). > +``0-9``, ``+`` (plus), ``-`` (hyphen) and ``_`` (underscore). While there > +is no hard restriction for the length of ``short-name``, it is strongly > +recommended to limit it to at most 20 characters. Arguably bikeshedding but changing up the last sentence to read a bit smoother (I skipped formatting)... While there is no hard restriction on the length of short-name, limiting it to 20 characters is strongly recommended. (s/for/on/, reversing order of the limit and strongly recommended.) -- 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-dev] Re: [PATCH] git-r3.eclass: Support more flexible EGIT_OVERRIDE_* APIs for user
Michał Górny posted on Sat, 18 Nov 2017 10:22:34 +0100 as excerpted: > Introduce a new, more flexible override API in git-r3, in replacement of > the LIVE_* API that was pretty much a legacy of git-2. This means to > solve the two major limitations of the old API: > > 1. The variables were based on package names without categories. > Therefore, they weren't suitable whenever two packages had the same > category. This is quite common when dealing with various programming > language bindings/reimplementations, and we can't really rely on every > new programming language inventing its own VCS. I always used package.env in any case, and always wished for a non- package-unique env var name variant to make it easier to simply clone the file and stuff the commit var as appropriate, instead of having to setup the file and fix up BOTH the var name and its value, when I needed to bisect a package the first time. So a variant without the repo OR package name would be my wish, here. > 2. The overrides weren't suitable for packages checking out multiple > repositories (LLVM, wine, glibc). Valid point there! -- 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-dev] Re: Manifest2 hashes, take n+1-th
Hanno Böck posted on Sat, 21 Oct 2017 19:50:11 +0200 as excerpted: > On Sat, 21 Oct 2017 12:12:44 -0500 R0b0t1 wrote: > >> People are discussing collision resistance, but no one here appears to >> be trained in cryptography. > > For the record, I'd claim I am. ... And with a number of vuln discoveries to your credit, it's safe to say it's not just paper certs for you, too. =:^) (And FWIW I'd point to Robin H Johnson/robbat2 as someone I know has authority in this area as well. There may be others. FTR I'm not one of them, tho as any good admin I try to follow the security news especially where it touches machines I administer, so I'm following this thread with particular interest.) -- 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-dev] Re: Manifest2 hashes, take n+1-th
Michał Górny posted on Sat, 21 Oct 2017 01:39:55 +0200 as excerpted: > W dniu pią, 20.10.2017 o godzinie 18∶42 -0400, użytkownik Anton Molyboha > napisał: >> Would it make sense then to support several hashes but let the user >> optionally turn off the verification of some of them, depending on the >> user's security vs performance requirements? >> > I won't block anyone from implementing such an option but I won't spend > my time on it either. However, if you believe verifying two checksums > could be a problem, then I have serious doubts if you hardware is > capable of building anything. When does this verification happen? If it's during --sync or --pretend/ask, as I believe it is based on when I get errors if I edit and forget to manifest/digest, then arguably time matters rather more than it does if it's only after the user has OKed the merge and it's doing the build. Because the time before the PM tells me what it's going to do and asks my OK before doing it is time I'm generally actually waiting for it (tho I'm normally doing something else while waiting, but I /am/ waiting) to decide whether I want to go ahead, or perhaps I need to change something first, while the actual build time after I've OKed it, doesn't matter so much, because I'm not actually waiting on it, I'm doing other things, which can actually include turning in for the night or going to work, with the intent being that it'll be done when I get back to it. So the hash verification time really does matter, even if it's minutes compared to hours of actual build time, because that's time I'm actively waiting for it, vs. letting it do its thing in the background, with much less concern about how long (within reason) it might take. -- 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-dev] Re: pkg_rm_pretend?
Kent Fredric posted on Sun, 15 Oct 2017 06:36:34 +1300 as excerpted: > On Thu, 12 Oct 2017 07:50:38 + (UTC) > Duncan <1i5t5.dun...@cox.net> wrote: > >> Wow. How'd you ever get a backlog of 400 packages in your depclean >> list, >> including critical ones you know you want to keep? These days portage >> even strongly suggests running depclean after an --update @world, in >> part to avoid such huge and confusing backlogs when it is run. > > I maintain perl ... so ... that can happen within a week *easily*, > depending what I test-install. :) > > On my chroot, I had a 1900 package depclean the other day that took 2 > hours to run. > > And yes, this was actually due to me going "oh, right, this box is going > to need to upgrade Perl soon, I should depclean *before* I sync to make > my life easier". > > Welp. Perl maintainer... after seeing the number of new packages, often 2X due to virtuals as well, that the recent perl upgrade brought me... Understood, now. =8^0 Tho a 1900-package-depclean... let's just say I'm glad you're doing it, not me, because I'm not sure /what/ I'd do with that, only that I'd probably not want to /touch/ anything sysadmin related for probably a month, after that! I can also imagine doing something drastic like hourly depcleans, if that's what it too, too, after dealing with a 1900-pkg-depclean! Yikes! -- 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-dev] Re: RFC v2: news item for the 17.0 profiles
Andreas K. Huettel posted on Fri, 13 Oct 2017 00:51:23 +0200 as excerpted: > Am Mittwoch, 11. Oktober 2017, 06:24:44 CEST schrieb Alec Warner: >> >> "Please upgrade away from the 13.0 profiles in the next six weeks." >> >> > Good idea. Here's what I wrote: > > Please upgrade away from the 13.0 profiles within the six weeks after > GCC 6.4.0 has been stabilized on your architecture. The 13.0 profiles > will be deprecated then and removed in half a year. Looks good. =:^) > [I'd very much like to remove them faster, but am not sure about upgrade > paths and recommended deprecation times. It may become necessary to mask > more and more packages in the 13.0 tree over the half year since devs > will start to depend on c++11 only libraries...] Ouch. Good reason to ensure the upgrade is done, and a total of 7.5 months from the last arch upgrade does seem reasonable. Tho gentoo has historically tried to ensure at least a year's upgrade path, for those who have a year's military or volunteer service, during which they're away from their gentoo machines, for instance. Personally, I have occasionally upgraded (secondary, off-net) machines after even longer (to 2.5 years, IIRC), but that has been while keeping my main machine current, so I had a memory of how to fix breakage and the configuration of the updated machine to reference while bringing the secondary machine current, a few packages at a time. And my own position, based on that experience, is that if you've not been doing /any/ gentooing for anything close to a year, it's very likely that simply starting over with a new stage3, probably in a chroot so you can use the existing install until the new install is up and running, is going to be easier. So 7.5 months does seem reasonable, to me at least. =:^) -- 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-dev] Re: pkg_rm_pretend?
Kent Fredric posted on Thu, 12 Oct 2017 05:20:24 +1300 as excerpted: > This is especially annoying as: > > 1. Its very easy to overlook one package in a 400 package depclean > notice. Wow. How'd you ever get a backlog of 400 packages in your depclean list, including critical ones you know you want to keep? These days portage even strongly suggests running depclean after an --update @world, in part to avoid such huge and confusing backlogs when it is run. > Related: > > It would also be nice if pkg_pretend ( or something like it ) happened > *BEFORE* offering the [Y/N] prompt with `emerge -va `, not, as it > currently does, wait until after you press "y" to execute those checks. That has irritated me a few times as well, tho I know /why/ it works that way. As the name suggests, pkg_pretend is /supposed/ to be run at pretend time, thus before the --ask prompt, both as originally designed and as speced by PMS. The problem the portage implementors apparently ran into is that some of the pkg_pretend stuff ends up being a bit expensive to run just to get the initial listing, so the (controversial) decision was made to run it /after/ the go-ahead. If it's going to double the processing time just for a pretend... Which kind of defeats the purpose I think, but... Maybe what we need is a two-stage pretend/ask, a first stage that does the minimum dependency graphing, etc, and a second stage that does the pkg_pretend. Then an --expensive flag could be added to enhance --pretend and --ask, that would run the second stage too, before the prompt for --ask. Maybe --expensive could automatically double backtrack count as well, so people could run with a lower backtrack by default and choose whether to run --expensive or deal with it manually if the lower backtrack didn't propose a satisfactory solution. -- 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-dev] Re: RFC: news item for the 17.0 profiles
Duncan posted on Wed, 11 Oct 2017 03:31:55 + as excerpted: > Andreas K. Huettel posted on Tue, 10 Oct 2017 21:02:32 +0200 as > excerpted: > >> Switching the profile changes the settings for building gcc (it >> switches a use-flag from forced-off to forced-on). A gcc-6 built with >> the 17.0 profiles will produce PIE executables by default, a gcc-6 >> built with the 13.0 profiles will not. >> >> I've added this paragraph: >> # Switching the profile modifies the settings of GCC 6 to generate >> # PIE executables by default; thus, you need to do the rebuilds >> # even if you already used GCC 6 beforehand. > > Thanks. Much clearer now. =:^) > > (And I'll have some rebuilding to do.) Actually it seems not. I had forgotten this from my /etc/portage/profile/package.use.mask (along with the appropriate system- wide USE flag): # 2017.0513 Now that I have gcc-pie enabled, don't want # the new profile package.use.mask. See the # "[PATCH] profiles: update pie use-flag masks for sys-devel/gcc" # thread, OP on Thursday, 11 May 2017 # by Mathias Maier
[gentoo-dev] Re: RFC v2: news item for the 17.0 profiles
Alec Warner posted on Tue, 10 Oct 2017 15:28:41 -0400 as excerpted: >> Please consider switching from your current 13.0 profile to the >> corresponding 17.0 profile soon after GCC 6.4.0 has been stabilized on >> your architecture. The 13.0 profiles will be deprecated and removed in >> the near future. >> >> > Can you commit to a deadline on this? > > Its OK to be wrong (e.g. say 1 month but remove in 3); but "near future" > is not actionable by readers. Will the 13.0 profiles be removed all together, or per-arch? If they're removed all at the same time, then the time-limiting factor will certainly be how long it takes the last arch to stabilize gcc-6.4+, something that's likely not entirely predictable but that might take some time, given gentoo's known issues with straggling archs. If the existing profiles will be deprecated and removed per-arch, with some fixed time after gcc-6.4+ stabilizes on that arch as a goal, then the time for most popular and best maintained archs may be predicted now, but the time will differ for each one, so the best that could be done would be either a time range or a list of the known ones, with presently unknowns being added to the list in further revisions of the news item. The other alternative might be to word it something like (1 year can be 6 months or whatever instead, if that works better): "13.0 profiles are set to be removed one year after the last arch stabilizes gcc-6.4+, with the goal for the gcc stabilization being the end of 2017, meaning 13.0 profile removal is planned for the end of 2018 if all archs meet their gcc-6.4+ stabilization goal." -- 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-dev] Re: RFC: news item for the 17.0 profiles
Andreas K. Huettel posted on Tue, 10 Oct 2017 21:02:32 +0200 as excerpted: > Am Dienstag, 10. Oktober 2017, 04:10:13 CEST schrieb Duncan: > >> One thing isn't clear here. Is this sequence necessary due to the >> profile switch itself, because the /profile/ enables PIE by default, or >> is it gcc-6.4+ that enables PIE, and the profile simply forces the PIE >> default by forcing gcc-6.4+? > > Switching the profile changes the settings for building gcc (it switches > a use-flag from forced-off to forced-on). A gcc-6 built with the 17.0 > profiles will produce PIE executables by default, a gcc-6 built with > the 13.0 profiles will not. > > I've added this paragraph: > # Switching the profile modifies the settings of GCC 6 to generate > # PIE executables by default; thus, you need to do the rebuilds > # even if you already used GCC 6 beforehand. Thanks. Much clearer now. =:^) (And I'll have some rebuilding to do.) -- 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-dev] Re: RFC: news item for the 17.0 profiles
Andreas K. Huettel posted on Mon, 09 Oct 2017 22:58:22 +0200 as excerpted: > Please consider switching from your current 13.0 profile to the > corresponding 17.0 profile soon after GCC-6.4.0 has been stabilized on > your architecture. The 13.0 profiles will be deprecated and removed in > the near future. > > Switching involves the following steps: > If not already done, > * Use gcc-config to select gcc-6.4.0 or later as system compiler > * Re-source /etc/profile: > . /etc/profile > * Re-emerge libtool Then, > * Select the new profile with eselect > * Re-emerge, in this sequence, gcc, binutils, and glibc > emerge -1 sys-devel/gcc:6.4.0 > emerge -1 sys-devel/binutils > emerge -1 sys-libs/glibc > * Rebuild your entire system > emerge -e world > > If you do not follow these steps you may get spurious build failures > when the linker tries unsuccessfully to combine non-PIE and PIE code. One thing isn't clear here. Is this sequence necessary due to the profile switch itself, because the /profile/ enables PIE by default, or is it gcc-6.4+ that enables PIE, and the profile simply forces the PIE default by forcing gcc-6.4+? The answer makes a big difference to those already on gcc-6.4+ and who presumably already did an empty-tree rebuild of @world when upgrading to it, but not yet on the new profile. Do they have to do all that again when they switch profiles, or is that a bridge they've already crossed with the gcc upgrade? Either way, making the answer to that explicit should be useful, avoiding either an unnecessary full rebuild, or avoiding the problems because the news item wasn't clear and people already on gcc-6.4+ thought the procedure didn't apply to them. -- 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-dev] Re: Providing a `service` scripts that speaks OpenRC and systemd
Walter Dnes posted on Sat, 30 Sep 2017 00:20:31 -0400 as excerpted:
> But, how do we reliably detect the currently running init system? Are
> there running processes, or entries in /sys/ or /proc/ or /dev that are
> unique to to each init system?
In theory at least, that's easy enough, just check the kernel
commandline's (/proc/cmdline) init= if present, and fall back to matching
against the path (canonical, to take care of symlink-based init-
switching) of PID 1 if init= isn't present or points to the default
/sbin/init.
In practice I suspect one would need to arrange for each supported init
system to drop its own detection executable in place, making the script
something like this:
#!/bin/bash
initdetectpath=/lib/initdetect
if ${initdetectpath}/issystemd ; then
...
elif ${initdetectpath}/isopenrc ; then
...
But, once you're having the initsystems package their own detection
files, you might as well simply make them their own service scripts
designed to do the detection as well, returning a specified error code if
it's not that initsystem, making it as simple as:
#!/bin/bash
notme=
for $servicefile in /lib/initservicedir/* ; do
$servicefile "$@"
code=$?
[[ $code = $notme ]] || break
done
[[ $code = $notme ]] && /
echo "No supported initsystem claimed to be running" > /dev/stderr
exit $code
Then it's up to the initsys packagers whether they want to support the
scheme or not, what sort of detection they do if they support it, and how
they translate the passed parameters if necessary, and bugs in how they
do any of it become the bugs of that initsystem.
--
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-dev] Re: Providing a `service` scripts that speaks OpenRC and systemd
Harald Weiner posted on Fri, 29 Sep 2017 04:47:35 +0200 as excerpted: > Duncan posted on 09/29/17 2:08 AM as excerpted: > >> Or are we going to replace rm, and fdisk, and gdisk, and cfdisk, and >> cgdisk, and who knows how many other binaries, with "safe" >> alternatives, >> because some gentooer couldn't be bothered to think for a moment >> whether a command in some instructions they're following is actually >> appropriate to the situation and the environment they're working in? > > Well, I think I understand what you want to say but actually your > argument sounds a little bit strange. > Gentoo is about choice, right? So a Gentoo user has the ability to > choose between OpenRC or SystemD init systems (by the way, many thanks > to the Gentoo developers for making this possible). But some > developer(s) might provide a package with a wrapper tool so that instead > of manual "translation" to your init system, you can just use type $ > service start And some users might want to use this package. > So I do not see the problem, as long as nobody forces you to use the > service tool. Actually, it adds a new choice for users: Either they use > the service-tool or they invoke their init system commands as they have > always done. That's not far from what I said, I don't oppose a separate "service" package, I simply don't see the need. But a want isn't a need, which is where your "choice" argument comes in. =:^) As long as it doesn't get added to @system or become a hard dep (direct or indirect) of something in @system, and preferably doesn't become a hard dep of anything, tho a USE-controlled dep is fine. Because that would turn the choice argument on its head, which is what I'm afraid of. -- 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-dev] Re: Providing a `service` scripts that speaks OpenRC and systemd
Austin English posted on Thu, 28 Sep 2017 16:27:31 -0500 as excerpted: > (Note: serious discussion, please take systemd trolling elsewhere). > > While having the pleasure of working with some proprietary software > recently, I was asked to run `service foo restart`, and was surprised to > see: > foobar ~ # service foo restart > * service: service `foo' does not exist > > Since `systemctl restart foo` works, I had a workaround anyway. > > Talking with Whubbs about it, I found that our service script only > supports OpenRC, via rc-service. I looked around, and from what I can > tell, most distros ship a service tool for all supported init systems. > I.e., > Debian/Ubuntu: supports sysvinit and systemd via init-system-helpers > CentOS/Fedora: provides support for systemd via initscripts > OpenSUSE: has a working service binary for systemd (according to #suse) > > I'd like to propose moving `service` out of OpenRC and into a separate > package that OpenRC and systemd can both use. It's very possible that we > could simply package/use another distro's scripts (I haven't evaluated > that though). While I wouldn't oppose moving "service" into a separate package, I don't see the need. It's rather like instructions assuming you're running MS something or other. You simply translate them in your head to whatever's appropriate for your system-administrative environment and go on. If you're bothered enough about it, when you're done, you open a support ticket with whoever wrote the instructions and suggest that they don't assume what cannot be taken as a safe assumption. Otherwise, you just go on with your day. While I can see users of some distros needing hand-holding in that regard, Gentoo has always been about giving people the tools, documenting how to use them, and getting out of the way -- if they can't read the docs or choose to use the tools to bash their hand, or /accidentally/ bash their hand because they couldn't be bothered to read the docs and either ran the tool without asking for confirmation (emerge without --ask or --pretend, we don't make --ask the default and have a --justdoit option, do you suggest we switch that around too?), or answered the tool's prompt for confirmation with a go ahead, well, that's their problem, and gentoo doesn't normally stand in the way of them bashing their hand... or head or whatever else, if they wish to do so. So I don't see the problem. As a systemd user I know that services are handled via systemctl, and would automatically translate an instruction to run "service" accordingly, just as when I was an openrc user I was aware that openrc didn't always function quite like other initsystems, and would consider what I was doing before I blindly ran "service ". Or are we going to replace rm, and fdisk, and gdisk, and cfdisk, and cgdisk, and who knows how many other binaries, with "safe" alternatives, because some gentooer couldn't be bothered to think for a moment whether a command in some instructions they're following is actually appropriate to the situation and the environment they're working in? Meanwhile: $ equery b service * Searching for service ... $ But that's no problem, because as I said I'd automatically translate the instructions into something appropriate to my environment. (Indeed, were there a separate package providing "service" that was for some reason a dep, I'd strongly consider creating for myself an empty virtual to provide it, just as I've done for a number of other packages that aren't actually required to build or run the commands I /do/ want to run.) -- 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-dev] Re: glibc-2.26 and changes with SunRPC, libtirpc, ntirpc, libnsl (NIS and friends), ...
Andreas K. Huettel posted on Tue, 19 Sep 2017 14:53:20 +0200 as excerpted: > Am Dienstag, 19. September 2017, 07:06:24 CEST schrieb Duncan: >> Andreas K. Huettel posted on Mon, 18 Sep 2017 11:56:30 +0200 as >> excerpted: >> > It may not always be obvious where this is needed, since >> > net-libs/libnsl is already pulled in deep in the dependency tree (my >> > @system chroot has it). >> >> FWIW, while it may be deep in the @system dependency tree, I don't have >> libnsl installed here > > Do you run glibc-2.26 already? I hope not, because it's >>unkeyworded<< > and I'm still changing things without warning there... :) [*] > > With any other glibc, it's part of sys-libs/glibc. > > And you will need it, because part of dev-lang/python links to it (for > us) unconditionally. Thanks for the clarification. I'm still on glibc-2.25-r5 here (Having read the thread as it developed I seem to have forgotten the bit about it being included in 2.25 by the time I replied, so the clarification is very 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-dev] Re: glibc-2.26 and changes with SunRPC, libtirpc, ntirpc, libnsl (NIS and friends), ...
Andreas K. Huettel posted on Mon, 18 Sep 2017 11:56:30 +0200 as excerpted: > It may not always be obvious where this is needed, since net-libs/libnsl > is already pulled in deep in the dependency tree (my @system chroot has > it). FWIW, while it may be deep in the @system dependency tree, I don't have libnsl installed here, so if it's not in @system directly, it's apparently pulled into @system by USE deps of some sort, via USE flags that aren't required to be on, in at least some reasonably general purpose plasma desktop configurations. (I run with no @system, having long ago negated the entire thing, at the time via individual -pkg entries in /etc/portage/profile/packages, now via a single -* entry, from the inherited profile and listed deps I actually needed in sets pulled in by world_sets. And my global USE starts with -*, adding only the flags I actually want/need, so whatever USE is pulling it in obviously isn't something I wanted or found I needed due to required-deps or something, 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-dev] Re: [openrc] [systemd] make `service` common for both OpenRC and SystemD (like Debian/Ubuntu/whatever did)
Andrew Savchenko posted on Sun, 17 Sep 2017 18:44:11 +0300 as excerpted:
> On Sun, 17 Sep 2017 12:05:07 +0200 Michał Górny wrote:
>> W dniu nie, 17.09.2017 o godzinie 12∶12 +0300, użytkownik Andrew
>> Savchenko napisał:
>> > On Sun, 17 Sep 2017 02:56:08 +0700 Vadim A. Misbakh-Soloviov wrote:
>> > > Hi there!
>> > >
>> > > Every time I switch from mastering service on my work
>> > > (Ubuntu-powered) to my own server farm (Gentoo powered) I'm going a
>> > > bit frustrated: Ubuntu (with all my hate to many other things in
>> > > it) has nice user-friendly way of managing services: you can freely
>> > > call any of `service action` irrelevant to which
>> > > init-system is currently in use. Will it be systemd, or (whatever
>> > > there is alternative there). `service` wrapper will detect it
>> > > anyway and will do the proper things (forward it to either systemd
>> > > or another service manager).
>> > >
>> > > I'd like to suggest to remove `service` widget from openrc and make
>> > > it the part of (which package? baselayout?)? Here is a pseudocode
>> > > of how I see it:
>> > >
>> > > ```
>> > > servicename=${1}
>> > > action=${2}
>> > >
>> > > if in_systemd; then
>> > > systemctl "${action}" "${servicename}"
>> > > else
>> > > rc-service "${servicename}" "${action}"
>> > > fi ```
>> > >
>> > > Well, actually, there may be some more logic (for example, instance
>> > > units (`unit@instance` in `systemd` vs `unit.instance` in openrc),
>> > > "enable" action (forward it to `rc-update add` for `openrc`,
>> > > probably) and maybe some more. But anyway, the conception is
>> > > something like that.
>> > >
>> > >
>> > > What do you think about that?
>> >
>> > https://xkcd.com/927/
>> >
>> > We will create even more confusion for Gentoo users with one more
>> > tool to do the same stuff.
>> >
>> > Of course you are free to implement some separate wrapper package,
>> > but it must be completely optional, since some users will have no use
>> > for it including myself.
>> >
>> > Really, unifying distributions is futile. We will have either the
>> > same and only distribution (to rule them all) or an attempt will
>> > fail. The same way you can try to unify emerge and apt tools via some
>> > wrapper manager.
>>
>> Fun fact: systemd was created to unify distributions in one init
>> system.
>
> Exactly. This case is perfectly covered by https://xkcd.com/927/ :)
Well, I'd argue the case for "not 'perfectly'", because for better or for
worse, systemd has had rather more luck at cross-distro init-system
unification than that comic suggests. There's still special-cases like
small embedded where systemd simply won't fit, and there's still a rather
strident no-special-case opposition, but virtually all the "don't care as
long as it works" distros are systemd, now -- the middle ground simply
isn't there any more, it's all systemd.
That's rather more successful as a unifying standard than the comic
suggests, so while the comic does cover the general situation and perhaps
matches the first few years near perfectly, as the situation has evolved
by now, the punchline panel would have to be rather different to be a
"perfect" cover.
--
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-dev] Re: [PATCH v3] eclass/kernel-2.eclass: Remove use of tr in global scope
Floyd Anderson posted on Thu, 07 Sep 2017 03:13:45 +0200 as excerpted: >>+# To use, an ebuild could contain a line like: >>+# AMD64_URI=http//linktothearchspecificpatch > > Even it’s just a comment: > > # AMD64_URI="http://link-to-the-arch-specific-patch"; > > looks friendlier to my eyes. However at least the colon after the scheme > should be given. ... And please, even in examples, use https://, to encourage the at least somewhat better security than plain http. (While https may not be particularly resistant to state-level actors able to lean on CAs, it should hopefully at least resist the trivial stuff like insecure wifi and ISP content-insertion games.) -- 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-dev] Re: Categories for GUI stuff x11 and wayland
Kent Fredric posted on Tue, 05 Sep 2017 07:29:42 +1200 as excerpted: > On Mon, 4 Sep 2017 15:16:46 -0400 "William L. Thomson Jr." > wrote: > >> Maybe just UI but that maybe to generic. >> https://en.wikipedia.org/wiki/User_interface > > As a side question, what does "xui" mean in this world? > > I went googling and all I could find was "X User Interface" > > And all I could find there is that's "A user interface to the X Windows > System" > > Are we allowed to consider Wayland and X11 are both "X Windows Systems" > providing "X User Interfaces", despite the underlying protocols being > different? Warnock agree? (Tho posting makes it no longer warnock.) Thanks for the warnock reference[1], BTW. I knew of the problem but had no name for it, so you broadened my vocabulary in a very useful way. =:^) [1] https://en.wikipedia.org/wiki/Warnock%27s_dilemma -- 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-dev] Re: Categories for GUI stuff x11 and wayland
R0b0t1 posted on Mon, 04 Sep 2017 12:27:35 -0500 as excerpted: >> I actually really like the ux-* idea. So much so I wish I'd thought of >> it. =:^) It doesn't come across as nearly as "tired and worn out" as >> "gui-*" does, here (tho I already see a reply from someone else with >> the opposite reaction, favoring desktop-* over ux-*). >> > My apologies, sir, for making myself known; please understand it was > never my intention to be a nuisance. No need to apologize for differing views. =:^) FWIW, I too am simply a gentoo user (note the lack of gentoo address), tho I've been a gentooer for nearing a decade and a half now (well, since early 2004, so "nearing" true, but not quite there yet), and have been following the dev list since I first started, so have a rather longer and more mature perspective than some. Meanwhile, it's certainly nice to see messages with more respect than may sometimes be seen in this list. Thanks. But don't be afraid to post your user's opinion just because it differs from someone else's opinion. Your opinion is valuable too, even if it's mine it differs 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-dev] Re: Categories for GUI stuff x11 and wayland
Kent Fredric posted on Mon, 04 Sep 2017 17:48:40 +1200 as excerpted: > Right, there's going to be plenty of examples of things that aren't > portable, and will need to stay in perpetuity in x11-* . x11-drivers > are probably a good example. Though I'm in no hurry to deprecate X11, > wayland will take even longer than systemd for me to go "Ok, yes, now > we should switch everyone to this" Indeed. Even after the general gui-provider can be assumed to be wayland in much the same was as it has been X for decades now, rootless/nested X will be around for many years/decades, for much the same reason that I'm still using dosbox to effectively provide "nested DOS" for that single legacy/proprietary game[1] I still play somewhat frequently. Some things, in particular X-based proprietary apps such as but not limited to games, are unlikely to ever be ported, so those continuing to find a use for them will continue to have a use for X, almost certainly eventually in nested and ultimately emulated form, much as I do with that game and dosbox. > Yeah. At this point there's not much value in a switch. And I'm not > entirely happy with either "gui-" or "desktop-". "x11-" is, for all its > warts, more useful than either of those still. > > I'm tempted to suggest something like "ux-", which conceptually > encompasses GUI/UI/Display concerns, and having an "x" gives a nod to > its legacy as being "x" without it being part of the definition :) I actually really like the ux-* idea. So much so I wish I'd thought of it. =:^) It doesn't come across as nearly as "tired and worn out" as "gui-*" does, here (tho I already see a reply from someone else with the opposite reaction, favoring desktop-* over ux-*). --- [1] Dosbox game: Master of Orion, original, (c) 1993 updated copy. -- 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-dev] Re: Categories for GUI stuff x11 and wayland
Kent Fredric posted on Sun, 03 Sep 2017 18:44:00 +1200 as excerpted: > On Wed, 30 Aug 2017 14:01:08 -0400 > "William L. Thomson Jr." wrote: > >> Examples >> x11-libs/gtk+ >> x11-terms/terminology > > "desktop" came to mind for me for some reason. > > "desktop-apps/" > "desktop-libs/" > "desktop-terms/" > "desktop-themes/" > > All appeal more to me than > > "gui-apps/" > "gui-libs/" > "gui-terms/" > "gui-themes/" > > "Gui" just seems too vague and generic here, and also feels like > double-dipping. Vague/generic agreed in general. I'm not sure enough what you meant by double-dipping (tho I have a couple ideas) to say I agree there. But... > And it will be additionally confusing if any of those apps don't have > any GUI, like for instance: > > gui-apps/xset > > That just seems backwards to me. > >desktop-apps/xset > > Alright, I guess. > > Maybe a category for non-graphical desktop-related tools should exist > instead. > >desktop-tools/xset How many of these xorg-suite apps have-been/will-be actually ported to wayland? I was under the impression that most of them will not be ported, and it'll be the up to whatever compositor and accompanying toolkit you choose to provide that functionality, as they generally already do... to a point. Certainly the compositor (aka super-window-manager) is the only app allowed to control/delegate many of the functions xset, xrandr, etc, set for xorg in common, for security reasons, because wayland simply doesn't let one app mess with and spy on another app's input stream, for instance, as X does. If only the compositor and/or apps it specifically authenticates for the purpose are allowed to do such settings, it quickly becomes a toolkit/DE function, and generic versions don't make a lot of sense as they simply won't work. In which case, keeping the "legacy" x11-* names for such x-specific apps, the better to eventually deprecate, mask, and send off to the user-maintained "X-sunset" overlay, may make the most sense and will almost certainly be less trouble. And where there is a port, as presumably there is or will be for many of the x11-libs, does it make sense to keep separate x11-* and wayland-* categories where they differ, or throw them all together in a heap? Meanwhile, the objection to "desktop-*" is that it may well look about as relevant in a few years as "mainframe-*" would look today, due to mobile, wearables, and possibly ultimately injectibles. > IDK. > > I'm not committed to anything I've said here, just food for thought. Same here. My biggest concern is simply avoiding, if possible, setting up new categories now, only to have to redo them in 2-5 when hindsight makes them look stupid. It may not be possible, but to the extent it is... Other than that, I've no particular shed color preference, other than don't make it 50 characters long or something so exotic we have to refer to it as "the category formerly known as x11-*." =:^) -- 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-dev] Re: Categories for GUI stuff x11 and wayland
William L. Thomson Jr. posted on Wed, 30 Aug 2017 14:01:08 -0400 as excerpted: > This is more food for thought to start a discussion on new category > names. With Wayland becoming more of a reality every day. I think some > of the x11-* categories may need to change. Stuff in there may not be > bound to X and can run on Wayland or X. > > Examples x11-libs/gtk+ > x11-terms/terminology > > Not sure what better "universal" category names would be. But seems it > maybe time for a discussion on such and some new categories and package > moves. Given thus stuff can run under X or Wayland. Not sure x11 makes > sense anymore. > > I can do this on my own in my own overlay. But likely best for official > categories as this effects the tree not just others overlays etc. I do > not really have any ideas for better names. Just seems like a need. That could be a lot of package-move churn. It arguably might make sense to keep the current names "for legacy reasons". (Or not. Just speculating here.) FWIW, there was some related discussion awhile back on USE=X, proposing USE=gui instead, but I don't know what became of it. Perhaps gui-* category names if that's actually moving forward, in ordered to maintain a bit of consistency and for lack of a better idea? -- 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-dev] Re: Guidelines for dangerous USE flags
Kent Fredric posted on Tue, 29 Aug 2017 21:21:09 +1200 as excerpted: > On Thu, 24 Aug 2017 03:06:13 + (UTC) > Duncan <1i5t5.dun...@cox.net> wrote: > >> nrpe-command-args-SECURITY-HOLE or just nrpe-GAPING-SECURITY-HOLE > > That's probably excessive, if you set that USE flag globally, you > deserve what you get. > > And if you are responsible and you know what you're getting, then you > should be allowed to do that ( even though I struggle to understand why > ) Good point. (And the global-use "why" might conceivably be creating a deliberate multiple-vulnerability distro for people to test their exploit abilities and techniques on, like the one I remember reading about awhile back. Unfortunately IDR the name, but someone will likely reply with 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-dev] Re: Last rites: xfce-extra/xfce4-volumed
Michał Górny posted on Mon, 28 Aug 2017 20:25:54 +0200 as excerpted: > # Michał Górny (28 Aug 2017) > # Alike xfce4-mixer, relies on gstreamer:0.10 (gstreamer:1.0 removed > # mixer wrappers). Last commit upstream in 2014. PulseAudio users > # can switch to xfce-extra/xfce4-pulseaudio-plugin > # or xfce-extra/xfce4-volumed-pulse. > # Removal in 30 days. Bug #629212. > xfce-extra/xfce4-volumed OK, you singled out pulseaudio users when you mentioned an alternative. What about non-pulseaudio users? Seems to me that message could be made better for them regardless of whether there's a non-pulseaudio alternative or not. If so, listing it/them would of course be useful. If there's no non-pulseaudio alternative, I'd suggest explaining why, something like this, depending on the reason: # Xfce now requires pulseaudio so there's no non-pulseaudio alternative # other than switching away from xfce on upgrade. Sorry. Or: # No xfce/gtk-based non-pulseaudio alternative known. This masking # message may be updated with alternatives should any be suggested. Or: # No xfce-based non-pulseaudio alternative available. Suggested # non-xfce alternatives include Meanwhile, at a minimum, usage of alsamixer in a terminal window might be suggested. Something like: # In the absence of other alternatives the ncurses-based alsamixer # from media-sound/alsa-utils may be used in a terminal window. I'm on kde here, but sometimes use alsamixer if kmix isn't working (I'm on live-git-kde after all) or is "working" but I'm not getting the expected results or I simply want a different visual presentation. -- 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-dev] Re: Guidelines for dangerous USE flags
Sven Vermeulen posted on Tue, 22 Aug 2017 17:37:51 + as excerpted: > On Tue, Aug 22, 2017 at 01:22:51PM -0400, Michael Orlitzky wrote: >> The net-analyzer/nrpe package has a ./configure flag: >> >> --enable-command-args allows clients to specify command arguments. >> *** THIS IS A SECURITY RISK! *** >> Read the SECURITY file before >> using this option! >> >> Back in nrpe-2.x, it was available via USE=command-args, but I dropped >> it from nrpe-3.x, and a user just asked about it (bug 628596). There >> are at least two things we could do with a dangerous flag like that: >> >> 1) require EXTRA_ECONF to enable it. >> 2) hide it behind a masked USE flag. >> >> Both options require about the same amount of work from the user, >> namely editing something under /etc/portage. What do y'all think is the >> best way to proceed? Are there other examples in the tree I could >> follow? > > I like the masked USE flag approach. Using EXTRA_ECONF requires a bit > more work from the user (not much though) but is less visible afterwards > in my opinion. > > Perhaps a name that implies that there is a security risk could be > interesting, but that's a minor suggestion. IDR which package it was on, but I remember investigating a USE flag called GAPING_SECURITY_HOLE or some such, on some package at some point. Turned out it was pretty much just that, but someone needed the feature it controlled on their firewalled LAN, and this flag is what the maintainer came up with as a solution. > Is there a way we could somehow ensure that a USE flag is never set > globally, but only on a per-package basis? The only mechanism I'm aware of for that, a hack but arguably an effective one, is including the package name in the USE flag. Combining all three suggestions, masked USE flag including the name of the package and a warning such as GAPING_SECURITY_HOLE (the ALL CAPS helps distinguish it too, since most USE flags are lowercase) in the name, say as ... nrpe-command-args-SECURITY-HOLE or just nrpe-GAPING-SECURITY-HOLE ... seems to me the most effective. Anyone that would even *think* to enable something like that without doing some *serious* investigation first, arguably shouldn't be using gentoo 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-dev] Re: Help maintaining dev-erlang and ejabberd
R0b0t1 posted on Tue, 22 Aug 2017 21:46:09 -0500 as excerpted: > On Tue, Aug 22, 2017 at 3:50 PM, wrote: >> >> Some time ago I've made an effort to split ejabberd into proper >> dependencies handled by portage rather than repackaging bundle produced >> by rebar. While I've found that easier to maintain, my lack of >> knowledge about Erlang makes maintenanace quite difficult. I'd >> appreciate if someone who actually has some experience in Erlang helps >> maintaining it. > > I would like to see Erlang receive continued maintenance and may be > able to help (note I am not as experienced as some). However this > would be my first time working with portage at such a level. > > I apologize if my post is too forward for this list. Wonderful, and not too forward at all. =:^) The gentoo mechanism by which non-gentoo devs maintain or co-maintain packages is called proxy maintenance: https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers For packages such as this one that you'd be co-maintaining along-side the existing maintainer, you obviously work with them and have already initiated contact there. You also need to contact the proxy-maintainer project to initiate that angle. There's further details and additional resources on the linked page, above. -- 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-dev] Re: [PATCH v2 01/12] dev-util/shadowman: New package
Michał Górny posted on Sun, 20 Aug 2017 12:26:48 +0200 as excerpted: > --- /dev/null > +++ b/dev-util/shadowman/shadowman-.ebuild > @@ -0,0 +1,27 @@ [snip...] > +# note: only for testing > +KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 > ~s390 ~sh ~sparc ~x86" OK, I know you said this was only for testing, but a question I had the first time around and didn't ask... It seems to me just as easy... and less chance of potential problems should a tester accidentally commit it, to handle it the way gentoo/kde does with live and not-yet-ready ebuilds in their overlay: Blank keywords in the ebuild and add it to package.accept_keywords (or simply package.keywords if you prefer the old name) with a ** entry if you're testing. Example from my package.accept_keywords (this entry might be in the symlinkable files in the overlay now, but it wasn't when I created it): # 2017.0611 kirigami needed for kde systemsettings # might as well do it live- too =kde-frameworks/kirigami- ** Not that it matters particularly, but is there a reason you chose to put the keywords in the ebuild instead of having people do the ** thing as above? A blank keywords, thereby forcing people who actually want to test to do the ** thing, would seem less of an invitation to problems should someone accidentally commit it during testing (tho admittedly this is a new package so problems are less likely, but I'm just used to seeing it require the ** accept_keyword thing). So I'm just wondering what reason you might have had to do it this way instead. -- 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-dev] Re: New item for sys-kernel/hardened-sources removal
Michał Górny posted on Sun, 20 Aug 2017 09:53:54 +0200 as excerpted: > W dniu nie, 20.08.2017 o godzinie 00∶39 -0500, użytkownik R0b0t1 > napisał: >> >> The discussion is nice but no one has actually touched on the >> technical merits of removing the packages besides "they are old." >> So I ask again: On what basis are the hardened sources being removed >> from the tree? > > Old kernel versions are a natural vulnerability targets. Even if they > are not vulnerable at the moment, they surely will be soon enough. This. Hardened-sources isn't just some generic package, where perhaps masking it as vulnerable but leaving it in the tree for those wishing to use it for its primary purpose /despite/ vulns, might arguably be justified. In this case, that "primary purpose" *is* resistance to attack, and leaving old and now unsupported versions in the tree when they're guaranteed to be increasingly vulnerable to new attacks is simply irresponsible, with no logical argument that can be made otherwise, thus the removal. Were it any other package, with any other primary purpose... but it's not. -- 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-dev] Re: New item for sys-kernel/hardened-sources removal
Aaron W. Swenson posted on Sat, 19 Aug 2017 07:18:20 -0400 as excerpted: [Proposed news item excerpt] > We'd like to note that all the userspace hardening and MAC support for > SELinux provided by Gentoo Hardened will still remain in the packages > found in portage. s/portage/the main gentoo tree/ Portage is a package manager, the default certainly, but still one of three. "The portage tree" usage remains around for legacy reasons, but "the gentoo tree" or even "the main gentoo tree" (because overlays) is arguably more accurate modern usage. [Just my contribution to the shed color debate. =:^P ] -- 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-dev] Re: [PATCH 2/2] git-r3.eclass: Explicitly warn about unsecure protocols
Michał Górny posted on Sat, 19 Aug 2017 10:25:02 +0200 as excerpted:
> Explicitly warn about any URI that uses an unsecure protocol (git, http)
> even if it's a fallback URI. This is necessary because an attacker may
> block HTTPS connections, effectively forcing the fallback to
> the unsecure protocol.
Thanks for this pair of patches. One minor correction, below.
> eclass/git-r3.eclass | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/eclass/git-r3.eclass b/eclass/git-r3.eclass
> index 42b586811368..1eb0baedc67f 100644
> --- a/eclass/git-r3.eclass
> +++ b/eclass/git-r3.eclass
> @@ -570,6 +570,15 @@ git-r3_fetch() {
>
> [[ ${repos[@]} ]] || die "No URI provided and EGIT_REPO_URI unset"
>
> + local r
> + for r in "${repos[@]}"; do
> + if [[ ${r} == git:* || ${r} == http:* ]]; then
> + ewarn "git-r3: ${r%%:*} protocol in unsafe and may be
> subject to MITM attacks"
s/in unsafe/is unsafe/
(Tho I can imagine a point at which "unsafe" becomes a list/array, defined
at the top of the function along with the other defines, or in a new
git-r3_check_unsafe
function, at which point "in unsafe" could make sense. But that's not the
structure here.)
> + ewarn "(even if used only as fallback). Please use
> https instead."
> + ewarn "[URI: ${r}]"
> + fi
> + done
> +
> local -x GIT_DIR
> _git-r3_set_gitdir "${repos[0]}"
>
> @@ -582,7 +591,7 @@ git-r3_fetch() {
> fi
>
> # try to fetch from the remote
> - local r success saved_umask
> + local success saved_umask
> if [[ ${EVCS_UMASK} ]]; then
> saved_umask=$(umask)
> umask "${EVCS_UMASK}" || die "Bad options to umask:
> ${EVCS_UMASK}"
--
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-dev] Re: Revisions for USE flag changes
Duncan posted on Sun, 13 Aug 2017 02:52:58 + as excerpted: > Michael Orlitzky posted on Sat, 12 Aug 2017 05:58:41 -0400 as excerpted: > >> On 08/12/2017 04:39 AM, Paweł Hajdan, Jr. wrote: >> >>> There are use-cases for --changed-use / --newuse other than changed >>> IUSE. >>> >>> I find it useful to easily rebuild affected packages when changing USE >>> flags in make.conf. If the flags were removed, would we have a good >>> alternative? >>> >> I simply overlooked the global USE change in make.conf because IMO it's >> a nonsense operation > > ?? > > How so? Are you arguing that deciding to system-wide switch to/from > pulseaudio, systemd, or gstreamer is nonsense? > > If so, I suspect many gentooers including myself strongly disagree. If > not, I'd be interested in what you propose as an alternative to changing > the appropriate USE flag systemwide, for what is after all a systemwide > change. After thinking about it for a few days, I see some logic to the point... in specific use-cases at least. Not setting global USE flags works reasonably well, provided (overlapping): * You have exactly one profile that makes sense for you, or you effectively create your own. By definition, this means you either agree with or don't care about other defaults, likely including openrc instead of systemd (because otherwise you won't be able to choose any other profile instead), and either use a minor arch (including x86), or use 16-bit only apps, or simply don't care about the additional work and build-time that multilib brings. Without addins, any time you want elements of multiple profiles, say plasma, no-multilib, systemd, etc (as here), you need to start setting many global flags for the ones you can't choose, either by setting them in make.conf, or by creating your own profile to set them. * You're just fine with the global defaults for anything not in your profile, either because you simply don't care, or because you want them the default off. * Any non-profile/non-IUSE-default USE flags you /do/ care about, you care about specific packages only. In the above scenario it does make some sense not to have any USE flags set in make.conf. Of course that's rather the opposite of my policy, which needs multiple profiles so must set the non-profile flags in make.conf, which considers an unset flag as much a chosen global default as a set flag, and which doesn't like profile or IUSE-defaults changing out from under it, so uses -* as a USE= prefix in make.conf. But my case isn't every case, and there's certainly a use-case where it does make sense, now that I've thought about it. Thanks for the prod. =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] New item for sys-kernel/hardened-sources removal
Francisco Blas Izquierdo Riera (klondike) posted on Wed, 16 Aug 2017 12:09:57 +0200 as excerpted: > s you may know the core of sys-kernel/hardened-sources have been the > grsecuirty patches. New typo: s/grsecuirty/grsecurity/ -- 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-dev] Re: Revisions for USE flag changes
Michael Orlitzky posted on Tue, 15 Aug 2017 23:22:54 -0400 as excerpted: > On 08/14/2017 08:01 AM, Jason Zaman wrote: >> >> I'll give an example where revbumps are significantly inferior to >> --changed-use. >> >> ... With --changed-use, only the people who need it (ie selinux users) >> will rebuild and everyone is happy (selinux users because the program >> now works and non-selinux users because they did not rebuild for no >> reason). > > But this benefit exists only for Portage users, and can only be obtained > by throwing the others under the bus. But even if that's the case (I wouldn't know), it's the case due to a deliberate decision of those going "under the bus", because portage is the default, and by choosing to use some other PM, they've deliberately chosen its (non-PMS) features over those of portage. Just as I, by choosing --newuse instead, have chosen to do rebuilds in such cases, even with portage. (Tho TBH I've never noticed that particular case, probably because it's lost in the noise compared to --changed-deps (enabled when static-deps were newer and I wanted to be sure, likely unneeded these days) and smart- live-rebuild of my (live) kde packages.) -- 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-dev] Re: [FRC] News item: Changing USE flags for >=app-backup/bacula
tomjbe posted on Tue, 15 Aug 2017 19:49:33 +0200 as excerpted: > think we can find a proper formulation for the use flag description in > metadata.xml, e.g.: > > director - Installs the backup director additional to the default file > daemon. > storage-daemon - Installs the storage daemon additional to the default > file daemon FWIW, "additional to" is understandable, but AFAIK nonstandard (sounds like ESL/English-as-a-second-language, using grammar from the first). The phrase "in addition to" works much better to my eye/ear. Or just use "plus", if "in addition to" makes it too long... -- 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-dev] Re: Revisions for USE flag changes
M. J. Everitt posted on Sun, 13 Aug 2017 11:18:09 +0100 as excerpted: > On 13/08/17 11:11, Michael Orlitzky wrote: >> On 08/12/2017 10:52 PM, Duncan wrote: >>> How so? Are you arguing that deciding to system-wide switch to/from >>> pulseaudio, systemd, or gstreamer is nonsense? >>> >> The meaning of any one USE flag varies widely across packages. I could >> never say "I want to enable USE=gstreamer" for every package in the >> tree, because I have no idea what it does for most of them. Setting >> USE=whatever globally essentially means "make random changes to my >> system" -- hence my wording. >> >> The meaning of a USE flag is per-package, so per-package is the only >> meaningful way to set them. >> > Which is why we have GLOBAL use flags and LOCAL use flags, right?! > > I'm not sure I'm actually reading this discussion right now?! and I'm > *not* a dev ... Even then... given the descriptions of most flags, regardless of global or local, without reading the sources (assuming one /can/ read them) it's generally a WAG what a flag actually does on an individual package. The information simply isn't there, except in the sources, and few people care enough about what a flag does to actually go the work of reading /all/ affected sources. [TL;DR stop here] FWIW, here I set USE="-* ..." in make.conf[1], so I can't /not/ have a global policy. If the flag's in make.conf, global policy says it's on. If it's not, global policy says it's off. There's no longer an "on if someone else defaults it that way, subject to change without pre- notification" state. After a few years chasing down reasons for changes to see if I agreed or not, I simply found it simpler to ensure I was the only one toggling USE flags, in which case I'd know exactly why I did it. And it works surprisingly well, too, particularly when package.use is multiple files, each named after a flag, "0-flag" for negating exceptions to an on global policy, simply "flag" for "posating" exceptions to an off global policy. With dates and comments for each exception and all the exceptions in one place (it's easy to equery uses the settings for a package, not so easy to find all the exceptions to a global policy setting and why, unless the exceptions are all in one place organized by flag name), management is as simple as it's going to get. -- 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-dev] Re: Revisions for USE flag changes
Michael Orlitzky posted on Sat, 12 Aug 2017 05:58:41 -0400 as excerpted: > On 08/12/2017 04:39 AM, Paweł Hajdan, Jr. wrote: > >> There are use-cases for --changed-use / --newuse other than changed >> IUSE. >> >> I find it useful to easily rebuild affected packages when changing USE >> flags in make.conf. If the flags were removed, would we have a good >> alternative? >> > I simply overlooked the global USE change in make.conf because IMO it's > a nonsense operation ?? How so? Are you arguing that deciding to system-wide switch to/from pulseaudio, systemd, or gstreamer is nonsense? If so, I suspect many gentooers including myself strongly disagree. If not, I'd be interested in what you propose as an alternative to changing the appropriate USE flag systemwide, for what is after all a systemwide change. Just seems to me an extremely surprising and unexpected argument, so I'd like to understand more of the reasoning behind it. I'll very likely learn something, as invariably the answer to questions I find myself compelled to ask due to what appears to me a transparently obvious different answer, reveal an angle I hadn't previously considered, sometimes changing my mind entirely. =:^) -- 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-dev] Re: Revisions for USE flag changes
Michael Orlitzky posted on Sat, 12 Aug 2017 10:14:18 -0400 as excerpted: > On 08/12/2017 06:29 AM, Rich Freeman wrote: >> >> My gut feeling is that the change you want is probably a good thing, >> but it will never happen if you can't provide a single example of >> something bad happening due to the lack of a revbump. > > There's an unfixed security vulnerability with USE=foo, so we drop the > flag temporarily. Users who had USE=foo enabled will keep the vulnerable > code installed until they update with --changed-use or --newuse. > > Even with the devmanual improvements, the advice we give is conflicting: > > * If you fix an important runtime issue, do a revbump. > > * If you drop a USE flag, don't do a revbump. > > What if you fix a runtime issue by dropping a flag? It's more confusing > than it has to be: the USE flag exception interacts weirdly with all the > other rules. Bad example as it's a security vuln, which requires masking/removing vulnerable versions, which will require a version bump in ordered to prevent downgrades if it was the latest visible for a (stable or ~arch) keyword. So the version bump is effectively mandatory due to security overrides in any case, and that it was fixed by a temporary USE flag drop doesn't change things at all. If that security-override isn't explicit in current documentation, that'd be the bug, not the fact that use-flag drops don't on their own require a version-bump. -- 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-dev] Re: [PATCH] toolchain-glibc.eclass: fix libm.so symlinking for live glibc
Sergei Trofimovich posted on Fri, 11 Aug 2017 09:14:42 +0100 as excerpted: > What is your point there? I'm afraid I lost you. Just saying interesting it's the same lib and apparently the same symlinking logic and line involved, and while it doesn't seem to be the same bug, it might be worth a bit of extra care while fixing the one to keep in mind the other so as not to further complicate fixing it, is all. (I'll be working on my bug either late today/Friday or Saturday.) -- 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-dev] Re: Prevent binary/non-compiled packages from binary package creation
William L. Thomson Jr. posted on Tue, 08 Aug 2017 12:37:42 -0400 as excerpted: > I make a lot of binaries for use on other systems, to expedite updates. > It does not make sense for some packages to ever be a binary package. > > Packages like -bin packages or gentoo-sources, which are just sources. > Having binary ebuilds of those is of no benefit. I can be the opposite > causing things to be much slower. Like in the case of large things > packages like android-studio. There's actually potentially significant differences and potential benefit. In addition to those already mentioned by others... * Binpkgs packages store the build environment as well. This includes eclass functions, etc, which are used from the binpkg, not from the existing tree, which may differ from that used at package creation. For example, some time ago I upgraded glibc (on ~arch) and had to roll back. Downgrading glibc is normally prohibited due to other dependencies that may have been built since that could now depend on the newer glibc, but fortunately I caught the problem quickly and only a handful of packages had been rebuilt after that, and the problem was bad enough that rebuilding the few if necessary was trivial compared to dealing with the broken glibc functionality. Fine, I thought, just emerge the old binpg. Not so easy because it refused to downgrade unless I_KNOW_WHAT_I_AM_DOING was set, and setting that was useless because it wasn't in the binpkg environment. So I ended up doing a full rebuild to get it in the binpkg environment. IIRC I had to do it from a backup, however, because glibc was broken enough I couldn't do it from the working copy, that being the reason I caught it so fast in the first place. Now I keep that variable set for glibc via package.environment, so it's always in my glibc binpkgs in case I need to downgrade and I won't have to do a full rebuild of the old version next time. Obviously glibc's not a pre-built binary, but the same thing could apply there. A variable could be set only on the pkghost, that would apply to all installs of that binpkg due to the saved environment, that wouldn't apply to a non-binpkg merge of the same ebuild. IOW, installing from a binpkg and from the existing tree ebuild could result in differences in the installed package, due only to the environment-saving. > Just seems odd to make a binary of a binary, or repackage gentoo-sources > into a gentoo ebuild binary/binpkg. There is not really any benefit > either way for such packages. While it does seem odd, there are certainly benefits in some cases... > It would be beneficial if ebuilds could have some internal variable that > prevents it from being a binary package. It should not prevent merge or > fail. Just never create a binary of this package, always use the ebuild > as normal. Even if someone is force installing using binary flag or > otherwise. Having an internal binary-prebuild variable set could indeed be useful, but agreed with the others, acting on it should be an option or perhaps an optional FEATURE, controllable by the sysadmin/user, not mandatory. FWIW, I'll almost certainly keep building binpkgs on here, regardless, because among other things I've found it just too useful to be able to go back and see what that older version I have archived looked like, both in terms of the files included, and the saved ebuild and eclass code. I can't count the times I've found it useful to have those old binpkgs for reference, and in fact, that's one of major benefits of using FEATURES=buildpkg in the first place, regardless of the package, in my book. Meanwhile, having buildpkg on virtual packages[1] is what amuses me. There, most of the benefits of binpkgs that arguably apply even to prebuilt binary and no-bin packages as long as they package and install /some/ file, arguably don't apply at all, tho I suppose there might be corner cases where they /could/. --- [1] Virtual packages: Including my own occasional null-pkg. Like sys-fs/udisks, for instance. It's a runtime-only dep of kde-frameworks/solid, used for functionality I don't want/need anyway, so I null-pkg it with an overlay version that has no deps and installs no files. -- 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-dev] Re: [PATCH] toolchain-glibc.eclass: fix libm.so symlinking for live glibc
Sergei Trofimovich posted on Tue, 08 Aug 2017 16:53:22 +0100 as excerpted:
> The failure happens when live glibc- ebuild is installed:
> * QA Notice: Missing gen_usr_ldscript for libm-2.26.90.so * ERROR:
> sys-libs/glibc-::gentoo failed:
> * add those ldscripts
>
> The problem here is how upstream glibc version is detected:
> dosym ../../$(get_libdir)/libm-${PV}.so
> $(alt_usrlibdir)/libm-${PV}.so
>
> Change to use 'version.h' to pick upstream version.
Interesting that it's libm. See bug #627378
https://bugs.gentoo.org/627378
... where ~arch glibc-2.25-r2 (apparently) allows the symlink creation
line above to clobber the original library binary, in usr merge (/lib64
and /usr/lib64 are the same dir) cases, or at least when /usr -> . (aka
"reverse" usr merge).
Comment #4 says it's not new code, thus the "(apparently)" above, but
perhaps it's acting differently now due to the recent migration away from
eblits? What I know for sure is that the upgrade broke my system until I
manually copied the libm binary from the binpkg back into 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-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?
Rich Freeman posted on Mon, 31 Jul 2017 20:55:05 -0400 as excerpted: > On Mon, Jul 31, 2017 at 8:24 PM, Duncan <1i5t5.dun...@cox.net> wrote: >> Rich Freeman posted on Mon, 31 Jul 2017 11:11:24 -0400 as excerpted: >> >>> On Mon, Jul 31, 2017 at 10:52 AM, Alec Warner >>> wrote: >>>> >>>> [T]he conclusion I was hoping to draw is that one >>>> has 2 repos instead of 1. >>>> >>>> 1) Rolling. >>>> 2) Stable. >>>> >>> This seems like it would be fairly painful to maintain. >> >> FWIW, the gentoo/kde team effectively do this right now >> > The difficulty isn't in moving the ebuilds around. > > The difficulty is in knowing WHICH ebuilds to move around. > > In the case of KDE it is the maintainers doing the maintaining, Very good point. 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
