[gentoo-dev] Re: Qt 5.15.3 version bump with breaking changes incoming

2022-03-23 Thread Duncan
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-portage-dev] Re: [PATCH] portage.output: Replace darkblue colors with teal

2021-12-06 Thread Duncan
Dale posted on Sat, 4 Dec 2021 10:01:00 -0600 as excerpted:

> As a user, I like the new color.  I to use a black background and the
> dark blue is hard to see.  I've also had to either copy and paste
> elsewhere or change the default color of Konsole.  I might add, every
> console, the ctrl+alt+F1 console, that I have ever seen is also black.
> 
> As a user, +1 for the change.  If it is OK, +10.

FWIW I've long had my own color.map here, needed on a standard VT but 
useful in a terminal as well.  The new teal default seems a lot more sane 
to me.

Tho unfortunately color.map can't solve the entire problem due to some 
output not being color-settable in color.map.  See bug #759820.  While I 
filed that during a now-fixed konsole bug that made things (much!) worse, 
the fact that not all colored portage output can be color-set in 
color.map remains.  Hopefully that's being looked at as well, but that 
doesn't change the fact that an improved default color.map, as here, is 
useful too. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman




[gentoo-dev] Re: [PATCH 0/1] ecm.eclass: set KDE_DEBUG=1 for ecm_src_test

2021-10-23 Thread Duncan
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-portage-dev] Re: [PATCH] lib/_emerge/actions.py: warn on missing /run

2021-10-07 Thread Duncan
Sam James posted on Thu,  7 Oct 2021 04:19:48 +0100 as excerpted:

[space-munged for wrap]
> + msg = "It seems that %s is not mounted. You have been warned." % path

Maybe something less vaguely ominous than "You have been warned."?

I'm supposing for /proc the repercussions are process priority and/or 
lifetime management, and for /run, locking.  So maybe:

"Portage locking and/or process lifetime and priority management may 
malfunction."

Or simpler/briefer to still fit on a single line with the "It seems..." 
sentence:

"Process management may malfunction."

Omitting "that" after "It seems" to shorten further, the longer /proc 
case would result in:

It seems /proc is not mounted. Process management may malfunction.

Nicely under the target 70 chars. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman




[gentoo-portage-dev] Re: [PATCH 2/2] lib/_emerge/resolver/output_helpers.py: explicitly state 'all satisfied'

2021-10-06 Thread Duncan
Sam James posted on Sat,  2 Oct 2021 21:11:56 +0100 as excerpted:

> This makes things a bit less confusing and tries to avoid users focusing
> on (soft) blocks which aren't actually the problem they're hitting.

I was pleasantly surprised by that "all satisfied" earlier today.  
Thanks.  I could get my brain around the old format but this is /so/ much 
nicer! =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman




[gentoo-portage-dev] Re: Ebuild - portage variable names

2018-11-28 Thread Duncan
Boris Vinogradov posted on Tue, 27 Nov 2018 21:13:35 +0300 as excerpted:

> I use gentoo about 8 year. I already try to write ebuild for my package
> but I think it's difficult to everyone who do it in the first time.
> 
> Because ebuild have strange short name for common portage variable such
> as {P}, {PV}, {PN} etc. Another developers use these modified variables
> with name and preffix MY, for example {MY_P}, {MY_PV}. I think it isn't
> readable because everyone who read and write ebuilds sometime may be
> foget their means.
> 
> I propouse to use human readble variable names for portage variables,
> such as {PATH} instead {P}, {PACKAGE_N}/{PACKAGE_NAME} instead {PN},
> etc... Human isn't a computer who knowns evething point of
> https://devmanual.gentoo.org/ebuild-writing/variables/index.html and
> other portage internals.
> 
> I think it's major for everyone gentoo developer because ebuild is face
> of portage system and main component of gentoo unique feature.

It's worth noting that ebuilds conform to a gentoo common standard called 
Package Management Specification (PMS), which defines ebuild-critical 
variable names such as {P}, {PV}, etc, and that there are package 
managers other than portage which along with portage depend on ebuilds 
conforming to this standard or they will fail to function correctly.

Updates to this standard are usually done via defining new EAPIs, with 
EAPI=7 being the current latest (tho note that while all officially 
approved APIs have been sequential numeric, EAPIs are specifically not 
required to be numeric, a historic experimental EAPI was named 5-hdepend, 
for instance).  Ideas for a new EAPI are proposed and discussed, 
generally with a preliminary approval by the Gentoo council before 
implementation in portage (as the defined PM reference implementation), 
after which a final council approval is required before the new EAPI is 
allowed to be used in the Gentoo tree.

So to propose human-readable standard var names you'd need to propose the 
change as part of a new EAPI and get it approved as such, but of course 
the existing EAPIs would remain in use for some time, so developers would 
continue to need to know the existing EAPI vars until they are fully 
deprecated and all ebuilds containing them are removed from the tree.

And honestly I must say I'm a bit skeptical, in part because in the 
decade and a half I've been a gentooer (user not dev) myself, I've not 
seen this sort of proposal before, so I suspect most devs must get 
comfortable with the existing short vars pretty quickly, and would resent 
the "churn for no good reason" and consequent relearning a wholesale 
switch to "human readable" would mean for them.  So I doubt its chances 
at approval... tho I wouldn't really mind being proven wrong on this 
point if you're up for the longer term drive to approval it'd take, 
because...

As for me personally, as another user, when I'm working on modifying 
ebuilds and don't remember the specifics of a standard var or function, I 
open the ebuild (5) manpage in another VT or terminal window, and use it 
for reference.

Another alternative is the app-doc/pms "Gentoo Package Manager 
Specification" package, which contains the specific standards definitions 
along with a nicely printable quick-reference card listing which EAPIs 
define what.  I have that installed too, as I suspect most devs and 
advanced users doing ebuild work do, tho as I mentioned I personally tend 
to find the ebuild (5) manpage easier for a quick lookup, and only tend 
to use PMS when I'm checking details not in the ebuild (5) manpage or I 
need the specific wording of the agreed PMS standard.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman




[gentoo-portage-dev] Re: [RFC] Improving Gentoo package format

2018-11-11 Thread Duncan
Francesco Riosa posted on Sun, 11 Nov 2018 17:05:37 +0100 as excerpted:

> Il giorno dom 11 nov 2018 alle ore 09:29 Michał Górny
> 
> ha scritto:
> 
>> On Sat, 2018-11-10 at 09:37 -0500, Alec Warner wrote:
>>> On Sat, Nov 10, 2018 at 8:09 AM Michał Górny 
>>> wrote:
>> [...]
>>>> My proposal ===
>>>>
>>>> Basic format 
>>>> The base of the format is a regular compressed tarball.
>>>> There's no junk appended to it but the metadata is stored
>>>> inside it as /var/db/pkg/${PF}.  The contents are as compatible
>>>> with the actual vdb format as possible.
>>>>
>>>>
>>> Just to clarify, you are suggesting we store the metadata inside
>>> the contents of the binary package itself (e.g. where the other
>>> files that get merged to the liveFS are?) What about collisions?
>>>
>>> E.g. I install 'machine-images/gentoo-disk-image-1.2.3' on a machine
>>> that already has 'machine-images/gentoo-disk-image-1.2.3' installed,
>>> won't it overwrite files in the VDB at qmerge time?
>>
>> Portage will obviously move the files out, and process them as
>> metadata.

>> The idea is to precisely use a directory that can't be normally part
>> of binary packages, so can't cause collisions with real files (even if
>> they're very unlikely to ever happen).
>>
>>>> This has the following advantages:
>>>>
>>>> + Binary package is still stored as a single file.

Breaking these down into RFC style MUST/SHOULD/MAY levels (as already 
suggested elsewhere), for me, this is...

SHOULD/MAY

(Would be a MAY, nice to have, but the existing solution has it, thus 
arguably raising the priority to SHOULD.)

>>>> + It uses a standard compressed .tar format, with minimal
>>>> customization.

MUST

(Losing the existing functionality here would be horrible.  FWIW I 
routinely use binpkgs as a reference, for "clean" config files, comparing 
install trees of old and new versions, etc.  Having tools that allow 
browsing standard compressed tar archives as virtual extensions to the 
filesystem makes that a breeze. =:^)

>>>> + The user can easily inspect and modify the packages with standard
>>>> tools (tar and the compressor).

MUST

(As pointed out, portage itself already does this when doing binpkg 
moves, etc.  Losing that would be horrible!)

>>>> + If we can maintain reasonable level of vdb compatibility, the
>>>> user can even emergency-install a package without causing too much
>>>> hassle (as it will be recorded in vdb); ideally Portage would
>>>> detect this vdb entry and support fixing the install afterwards.
>>>>
>>>>
>>> I'm not certain this is really desired.

SHOULD/MAY

(I'd say SHOULD, but while possible to emergency-install via untarring 
now, portage doesn't do anything with it at all, so the detect and fix 
functionality is a bonus, thus arguably lowering it to a MAY.)

>> Are you saying it's better that user emergency-installs a package
>> without recording it in vdb, and ends up with mess of collisions and
>> untracked files?
>>
>> Just because you don't like some use case doesn't mean it's not gonna
>> happen.  Either you prepare for it and make the best of it, or you
>> pretend it's not gonna happen and cause extra pain to users.

I think I've had to do this twice in ~1.5 decades, plus once reaching 
into the tarball to extract a single file that was broken in a newly 
installed glibc, breaking portage (and much of the system, but bunzip 
still worked!) so I couldn't undo it using portage.

The first time I didn't know enough to clean up manually, but the second 
time (and the reach-in time) I did.  It'd *definitely* be nice to have 
portage be able to clean up automatically.

> Another option would be to install in a near but not overlapping
> directory,
> example:
> /var/db/pkg/${PF}-binpkg
> 
> this way the user that know what to do with that data can play with it,
> also portage could be instructed to stat() that directory and take
> action (halt maybe?) if present.

Idea ++

Detect and fix has already been proposed, but detect and halt with an 
error and a pointer to manual fix instructions is arguably already better 
than current.

Which suggests an easy implementation split, delaying the "fix" step 
until later, if it would complicate the initial implementation too much.

[Bikeshed]  I was thinking binpkg-${PF} to emphasize the binpkg part and 
group any emergency-installed packages together in an alphabetical 
listing.  But whichever's easiest for portage to work with, which 
probably makes the -bin

[gentoo-dev] Re: [PATCH] ant-tasks.eclass: use eapi7-ver

2018-05-22 Thread Duncan
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

2018-05-15 Thread Duncan
Mathy Vanvoorden posted on Tue, 15 May 2018 11:32:30 +0200 as excerpted:

> 2018-05-12 14:20 GMT+02:00 Gerion Entrup <gerion.ent...@flump.de>:
> 
> 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.

2018-05-08 Thread Duncan
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

2018-04-01 Thread Duncan
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

2018-03-27 Thread Duncan
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, 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

2018-03-21 Thread Duncan
 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

2018-03-11 Thread Duncan
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?

2018-03-11 Thread Duncan
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

2018-03-10 Thread Duncan
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 <zmed...@gentoo.org>
> 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.

2018-03-02 Thread Duncan
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

2018-02-11 Thread Duncan
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

2018-02-11 Thread Duncan
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

2018-02-10 Thread Duncan
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

2018-02-06 Thread Duncan
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-portage-dev] Re: [PATCH] emerge: add --changed-deps-report option (bug 645780)

2018-01-29 Thread Duncan
Zac Medico posted on Sun, 28 Jan 2018 22:21:48 -0800 as excerpted:

> On 01/28/2018 09:49 PM, Zac Medico wrote:
>>> 3) Show a NOTE telling users about --changed-deps=y
>> 
>> This is in the HINT section, which is displayed if both --changed-deps
>> and --dynamic-deps are disabled in PATCH v2.
> 
> Actually, the whole report should be suppressed if either --changed-deps
> or --dynamic-deps is enabled, so I'll send PATCH v4 for that.

This is shaping up quite nicely and by (1) dramatically shortening the 
original "wall of text" report and (2) aborting the report if no affected 
packages are in the graph, it's vastly improved from the original.

I definitely expect it to be rather helpful here, since I have both 
--dynamic-deps and --changed-deps off by default, and seeing that list 
could be /quite/ helpful.  Looking forward to it! =:^)

My remaining concern, and I'm not sure there's a solution, is that for 
routine 30-day-plus updaters, the warning could quickly become "routine 
noise", due to valid no-r-bump exceptions such as the llvm example mgorny 
provided, which very well /could/ happen often enough to trigger the 
warning nearly every time for 30-day-plus updaters.  Then when it really 
counts and could help, people will likely be ignoring it.

Maybe someone else has an idea, but as I said it's already vastly 
improved from the original, and I believe usable as-is, now, while I'd 
have found the original quite irritating by about the third time I saw 
it, even if also helpful.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman




[gentoo-dev] Re: [News item review] Portage rsync tree verification (v4)

2018-01-28 Thread Duncan
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)

2018-01-27 Thread Duncan
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)?

2018-01-26 Thread Duncan
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)?

2018-01-26 Thread Duncan
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

2018-01-25 Thread Duncan
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-portage-dev] Re: Plan for initial integration of gemato with portage

2018-01-24 Thread Duncan
Michał Górny posted on Wed, 24 Jan 2018 20:58:54 +0100 as excerpted:

> W dniu śro, 24.01.2018 o godzinie 12∶54 -0500, użytkownik Alec Warner
> napisał:
>> 
>> I think its a bit trickier to control the hook's behavior. For
>> instance:
>> 
>> 1) I install portage[rsync-verify]. This installs the hook.
>> 2) I end up not liking the hook, I install portage[-rsync-verify]
>> 3) Does the hook get config-protected here?
> 
> Keeping config-protected files applies only if the file were modified.
> In this case it just gets unmerged. I've just verified that.

That's controlled by FEATURES=config-protect-if-modified .  Granted, 
that's enabled by default, but config-protecting unmodified files as well 
is definitely a user option that should be considered, even if that 
consideration is simply "users disabling the default get to keep the 
pieces".

Meanwhile, if it's "you keep the pieces if you've messed with the 
default", that should at least be mentioned in the news item[1], so users 
can consider whether the risk is worth it if they've had that feature 
specifically disabled previously.

---
[1] New item mention: or the more detailed instructions the news item 
points to if they get too long to be in the news item itself.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman




[gentoo-dev] Re: version/slot locked dependencies in eclasses like autotools.eclass and vala.eclass

2018-01-22 Thread Duncan
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

2018-01-22 Thread Duncan
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

2018-01-18 Thread Duncan
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

2018-01-16 Thread Duncan
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

2018-01-10 Thread Duncan
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: Dropped EAPI 2/3 support in virtualx.eclass

2018-01-06 Thread Duncan
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

2018-01-06 Thread Duncan
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

2017-12-24 Thread Duncan
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

2017-12-22 Thread Duncan
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 <willi...@gentoo.org>
> 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)

2017-12-21 Thread Duncan
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
> <prometheanf...@gentoo.org> wrote:
>> On 17-12-21 08:34:31, Michał Górny wrote:
>>> W dniu czw, 21.12.2017 o godzinie 05∶29 +, 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)

2017-12-20 Thread Duncan
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

2017-12-14 Thread Duncan
e 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-portage-dev] Re: Is portage (/usr)/bin-merge safe?

2017-12-07 Thread Duncan
Zac Medico posted on Thu, 07 Dec 2017 01:07:21 -0800 as excerpted:

> On 12/07/2017 12:37 AM, Duncan wrote:
>> Zac Medico posted on Fri, 31 May 2013 22:49:02 -0700 as excerpted:
>> 
>>> On 05/31/2013 10:36 PM, Duncan wrote:
>>>> As in subject, is portage bin/usr-bin merge safe?
>>>>
>>>> It appears most of my clashing files are /usr/bin/* -> /bin/*
>>>> symlinks.
>>>
>>> I haven't tried it, but it should work just fine. Portage has always
>>> supported directory symlinks like these. I haven't heard any recent
>>> complaints regarding them.
>> 
>> As the attribution says, I'm resurrecting a thread from 2013...
>> 
>> I set up a merged /usr/bin -> /bin (and sbin -> bin, and /usr -> .)
>> soon after that, with very few problems, usually ebuilds doing
>> unconditional rms in postinst or the like, until recently...
>> 
>> Something recently changed, as now I'm having many more problems, so
>> far with four packages, glibc (!!), coreutils (!!), nano, and shadow,
>> installing symlinks that ultimately point to themselves.
>> 
> I think the sort order of your root directory changed for some reason.
> The order that readdir returns filenames depends on the filesystem
> implementation:
> 
> http://man7.org/linux/man-pages/man3/readdir.3.html

That's... strange.  Back in 2013 might have still been on reiserfs, but 
I've been on btrfs for awhile now.  I wonder what might make it change 
order?

Tho I /did/ somewhat recently upgrade ssds, thus copying the /bin dir 
and /usr -> . symlink, among other root entries.  Obviously back when I 
first setup the /usr -> . symlink it was the newest entry.  Maybe if I 
delete and recreate it so it's definitely the newest entry again...

I have no idea how long it might have been before I came up with the idea 
to try that on my own.  Thanks!  I'll (gingerly, I don't like major 
system breakage!) see if it makes a difference.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman




[gentoo-portage-dev] Re: Is portage (/usr)/bin-merge safe?

2017-12-07 Thread Duncan
Zac Medico posted on Fri, 31 May 2013 22:49:02 -0700 as excerpted:

> On 05/31/2013 10:36 PM, Duncan wrote:
>> As in subject, is portage bin/usr-bin merge safe?
>>
>> It appears most of my clashing files are /usr/bin/* -> /bin/* symlinks.
>> (That's just bin, I've not looked at sbin.)
> 
> I haven't tried it, but it should work just fine. Portage has always
> supported directory symlinks like these. I haven't heard any recent
> complaints regarding them.

As the attribution says, I'm resurrecting a thread from 2013...

I set up a merged /usr/bin -> /bin (and sbin -> bin, and /usr -> .) soon 
after that, with very few problems, usually ebuilds doing unconditional 
rms in postinst or the like, until recently...

[I'll likely file this as a bug as well, but thought I'd post a followup 
to the old thread here, first.  I'm kinda busy troubleshooting the 
unrelated bug that triggered the coreutils expression of this bug for me, 
ATM.]

Something recently changed, as now I'm having many more problems, so far 
with four packages, glibc (!!), coreutils (!!), nano, and shadow, 
installing symlinks that ultimately point to themselves.  The glibc one 
is of course critical as it breaks pretty much the entire system right 
away, the coreutils set is critical due to the number of frequently used 
binaries it breaks, and I'm lucky I discovered nano before needing it as 
a low-dep fallback editor.  Being a single-user system I don't so often 
use passwd, but like nano, it's one of those things that when it's 
needed, it's REALLY needed.

>From my current installmask file:

# 2017.1112 glibc: libm-2.*.so due to /usr -> . symlink,
# symlink overwrites the lib it points to!
INSTALL_MASK="
$INSTALL_MASK
/usr/lib64/libm-2.*.so
"

# 2017.1207 coreutils symlinks that overwrite their binaries
INSTALL_MASK="
$INSTALL_MASK
/usr/bin/basename
/usr/bin/chroot
/usr/bin/cut
/usr/bin/dir
/usr/bin/dirname
/usr/bin/du
/usr/bin/env
/usr/bin/expr
/usr/bin/head
/usr/bin/mkfifo
/usr/bin/mktemp
/usr/bin/readlink
/usr/bin/seq
/usr/bin/sleep
/usr/bin/sort
/usr/bin/tail
/usr/bin/touch
/usr/bin/tr
/usr/bin/tty
/usr/bin/uname
/usr/bin/vdir
/usr/bin/wc
/usr/bin/yes
"
# 2017.1207 shadow, nano symlinks
INSTALL_MASK="
$INSTALL_MASK
/usr/bin/nano
/usr/bin/passwd
"

So what changed in portage that previously prevented the /usr/* symlinks 
from overwriting the non-usr binaries, but now allows the overwrites to 
go ahead, breaking the system?

Note that I ran into the glibc library symlink issue first.  I ran into 
the coreutils issue after a bad upgrade (unrelated, I think) broke X, 
forcing me back to a backup and I started upgrading a few packages at a 
time from binpkg, to see which one broke X again.  When I got to 
coreutils, the qmerge phase broke half way thru as a binary was replaced 
by a symlink to itself.  I'm not sure why it triggered in binpkg install 
but not when I had originally installed it on the system, but it may be 
due to the fact that I normally run parallel merges so the system is 
heavily loaded during normal merge, while with the binpkg merge it 
wasn't, thus implying a race condition of some sort.  I discovered the 
nano and shadow/passwd issues, seeing their binaries were broken symlinks 
to themselves, when fixing the coreutils issue. I've no idea when they 
happened.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman




[gentoo-dev] Re: [PATCH 2/2] glep-0042: Update and clarify naming rules.

2017-11-27 Thread Duncan
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

2017-11-18 Thread Duncan
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

2017-10-21 Thread Duncan
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 <r03...@gmail.com> 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

2017-10-20 Thread Duncan
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?

2017-10-14 Thread Duncan
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

2017-10-12 Thread Duncan
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?

2017-10-12 Thread Duncan
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

2017-10-12 Thread Duncan
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 <tam...@gentoo.org on gentoo-devel
sys-devel/gcc   -pie

I had turned it on already by the time of the mask, and unmasked to avoid 
turning it off and rebuilding again, once it was on system-wide and the 
mask was trying to turn it off again, which would have forced another 
system-wide rebuild then, and yet /another/ one now.

Of course that's a big part of why I as a responsible gentoo-based-system 
sysadmin follow this list, to see such changes coming down the pike and 
take appropriate measures before they hit me and the systems I administer 
(only my own, but that's no reason not to take the job seriously)
head-on. =:^)

So AFAICS my profile upgrade should be just a matter of flipping the 
symlink. I guess I'll find out in the next few days.  =:^)

-- 
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

2017-10-10 Thread Duncan
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

2017-10-10 Thread Duncan
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

2017-10-09 Thread Duncan
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

2017-09-30 Thread Duncan
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

2017-09-29 Thread Duncan
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

2017-09-28 Thread Duncan
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), ...

2017-09-20 Thread Duncan
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), ...

2017-09-18 Thread 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, 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)

2017-09-17 Thread Duncan
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

2017-09-07 Thread Duncan
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

2017-09-04 Thread Duncan
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."
> <wlt...@o-sinc.com> 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

2017-09-04 Thread Duncan
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

2017-09-04 Thread Duncan
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

2017-09-03 Thread Duncan
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." <wlt...@o-sinc.com> 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

2017-08-30 Thread Duncan
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

2017-08-29 Thread Duncan
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

2017-08-28 Thread Duncan
Michał Górny posted on Mon, 28 Aug 2017 20:25:54 +0200 as excerpted:

> # Michał Górny <mgo...@gentoo.org> (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

2017-08-23 Thread Duncan
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

2017-08-23 Thread Duncan
R0b0t1 posted on Tue, 22 Aug 2017 21:46:09 -0500 as excerpted:

> On Tue, Aug 22, 2017 at 3:50 PM,  <aide...@gentoo.org> 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

2017-08-20 Thread Duncan
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

2017-08-20 Thread Duncan
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

2017-08-19 Thread Duncan
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

2017-08-19 Thread Duncan
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

2017-08-18 Thread Duncan
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

2017-08-16 Thread Duncan
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

2017-08-16 Thread Duncan
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

2017-08-15 Thread Duncan
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-portage-dev] Re: [PATCH] emerge: add --autounmask-keep-keywords option (bug 622480)

2017-08-14 Thread Duncan
Zac Medico posted on Sun, 13 Aug 2017 19:27:53 -0700 as excerpted:

> On 08/13/2017 07:00 PM, M. J. Everitt wrote:
>> Interesting .. I'm sure I shied away from that option for some reason
>> ... wonder if zmedico can shed some light on the difference between the
>> new options and the old, apart from some added flexibility ...
> 
> The --autounmask-keep-keywords option allows you to adjust the the way
> that decisions are made during dependency resolution.

> Changes in decision making behavior have a large impact on the resulting
> dependency calculation. It can mean the difference between a successful
> calculation, and one that produces useless results.
> 
> The --autounmask-write=n option has no influence on the decisions made,

> The --autounmask-keep-keywords option gives finer-grained control. This
> finer-grained control is only useful in cases where --autounmask=n would
> prevent useful configuration changes from being made.

Thanks.  Clear and succinct.

That improved my own understanding as well, particularly the distinction 
between changing the decisions made, and not changing them, but simply 
preventing them being automatically written, allowing the user direct 
control over what's actually written and how. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman




[gentoo-portage-dev] Re: [PATCH] emerge: add --autounmask-keep-keywords option (bug 622480)

2017-08-13 Thread Duncan
M. J. Everitt posted on Mon, 14 Aug 2017 00:37:45 +0100 as excerpted:

> My use-case consists of the scenario where I do not *ever* wish Portage
> to modify my /etc/portage/package. files, preferring to do
> this myself manually with a personal naming scheme which defines which
> target packages are causing dependency issues. This would be a rather
> cool feature-request for portage itself, but I don't see it being
> implemented Any Time Soon™.
> 
> This was why I have enforced --autounmask=n in my EMERGE_DEFAULT_OPTS as
> often it causes more harm than good if 'random' entries in
> /etc/portage/ starts to cause later issues with updated
> library packages (read Perl, Python and any other dev-lang nasties
> here).

FWIW, my use-case is similar.  I don't /ever/ want portage doing 
automated portage-config changes, because I have my own organization, and 
I comment every change so I know when, what, why, and there's no way an 
automated tool (well, perhaps some IBM or Google AI, but...) is going to 
be able to get that even close to correct enough for my satisfaction.[1]

However, I've found the /suggestions/ portage makes with auto-unmask 
useful, as long as they remain just that, *suggestions*, that I can 
decide on and write up as I wish.

And --autounmask-write=n gets me the best of both worlds.  Portage 
doesn't write changes but still suggests them.

If you've not tried it, I suggest you do.  Works great for me! =:^)

---
[1]  Besides, doing it manually means I remember the details I did /not/ 
put down much more readily, once prompted by the ones I did.  Even if an 
automated version could do it it'd need to write paragraphs in ordered to 
allow me to make sense of it a year or whatever later, compared to my 
single line when done manually.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman




[gentoo-dev] Re: Revisions for USE flag changes

2017-08-12 Thread Duncan
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

2017-08-12 Thread Duncan
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

2017-08-11 Thread Duncan
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

2017-08-10 Thread Duncan
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

2017-08-10 Thread Duncan
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?

2017-07-31 Thread Duncan
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 <anta...@gentoo.org>
>>> 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




[gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

2017-07-31 Thread Duncan
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 <anta...@gentoo.org>
> wrote:
>>
>>
>> Sorry, to be clear the conclusion I was hoping to draw is that one has
>> 2 repos instead of 1.
>>
>> 1) Rolling.
>> 2) Stable.
>>
>> Rolling is typical ~arch Gentoo. People in rolling can do whatever they
>> want; they can't affect stable at all.
>>
>> Stable is an entirely separate repo, a fork, where CPVs are pulled from
>> Rolling into Stable. If Stable wants to keep a gnarly old version of
>> some package around; great! But the rolling people don't have to care.
>>
>>
> This seems like it would be fairly painful to maintain.  You'd need to
> constantly pull in new packages, and prune out old ones.  It would
> duplicate many of the functions maintainers already do.  I doubt anybody
> would go to the trouble to make this happen.

FWIW, the gentoo/kde team effectively do this right now, tho only with kde 
packages and some of their deps, and it's live/prerelease/release-staging 
vs ~arch/stable, not ~arch vs stable.  But the amount of work is surely 
similar, and they've been doing it now for a number of years and over a 
major kde version bump, an upstream svn/git upgrade and general upstream 
remodularization.

They seem to have the method and routine /down/, and I'm sure many of the 
lessons they've learned could be used were such a main repo split to be 
undertaken, but I honestly have no idea whether they'd consider the 
effort huge or "painful to maintain", only that they do it -- pretty  
effectively if I might add from my own consumption of both the main tree 
and kde overlay.

And to address the concern over users with mixed ~arch/stable usage, as a 
user effectively doing it but with mixed ~arch-main/live-kde usage, the 
trouble of having to pull and update from both trees, managing masks, 
etc, isn't actually that bad at all, particularly given the fact that the 
main mask/unmask sets are maintained (automatically via project script) 
in the kde repo so all I have to do is symlink appropriately and add an 
occasionally temporarily overlooked one to my local exception file.


For gentoo/kde it would seem to have been worth it, but you'd have to ask 
them if it's "painful" for them.

So it's certainly doable, maintainable over years and major changes, and 
consumable, as gentoo/kde devs and their users have been and continues to 
demonstrate. =:^)  The /big/ question then is only whether that model's 
actually a good fit for the wider gentoo culture, and I still have my 
doubts on that 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: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

2017-07-28 Thread Duncan
William L. Thomson Jr. posted on Fri, 28 Jul 2017 16:10:42 -0400 as
excerpted:

> It seems odd that upstream will release a package. Just for downstream
> to consider it not stable. Did it get messed up during packaging? Did it
> get messed up by the distro? The whole lag thing does not make sense for
> Gentoo. Sooner released and tested on Gentoo. Sooner bugs can be
> founded, reported back to upstream, etc. Speeds up development. That is
> Gentoo's role in FOSS IMHO.

Not so odd.  Gentoo's arch-stable has a different meaning than upstream's 
stable.  As a long time gentooer I'm surprised you weren't aware of this 
already.

In general (individual packages may differ somewhat on a case-by-case 
basis, one variant being packages where gentoo /is/ upstream and ~arch is 
thus used for upstream unstable testing to some degree)...

Gentoo's stable doesn't really relate to upstream stable except that 
upstream betas and the like (well, short-term ones, not the ones that 
last years without a non-beta release...) aren't normally considered 
stable candidates because they're not released by upstream as such.  
Instead, gentoo's stable means that the packaging -- the ebuild script, 
the eclasses it calls, and the eapi as encoded in pms and deployed by the 
pm -- is considered tested and stable on a particular arch.  Gentoo-
stable also includes proper integration, making sure the header files, 
libs, configuration, documentation, etc, all end up in the place gentooers 
expect them to be, that they build with our particular toolset, etc.

Similarly, upstream-unstable isn't supposed to be a candidate for ~arch 
either, because ~arch is supposed to be upstream stable that simply 
hasn't yet had enough testing of its gentoo packaging and integration in 
ordered for that particular package to be declared stable.

That's one reason why ~arch normally works so well for those prepared to 
manually deal with the occasional packaging or integration hiccup, missed 
or incorrect dependency, failed merge due to conflict with existing files 
because upstream moved something and the package hasn't yet adapted to 
it, etc -- it's releases that upstream has already declared reasonably 
stable, that simply aren't yet sufficiently tested in terms of the gentoo 
packaging and integration, and if a user's willing to deal with the 
occasional hiccup there it should otherwise be as stable as the upstream 
declaration.

Which is why people like me find ~arch quite stable -- it /should/ be for 
us, as it's upstream stable, and we're prepared to deal with the minor 
dependency and integration issues, etc, that the process of gentoo 
stabilization is intended to fix.

The problem this thread is seeking to at least incrementally tweak toward 
the better is that the above only works for people on stable, when people 
actually declare a package stable when there's no serious bugs left after 
the testing period.  Sometimes they forget, packages drop thru the 
cracks, etc, and stable users get further behind than they would be if 
policies were actually being followed.

And perhaps more to the point, on the minor archs which tend to be the 
bottleneck, sometimes there's simply not the resources, either 
sufficiently interested people with the time (who are volunteers after 
all, so interest and time can't be commanded) or arch hardware or both, 
available to do those stabilizations.  The proposal here hopes to 
automate much of the process as well as standardize it, hopefully 
alleviating that bottleneck.

Tho as I've said before, as one who /is/ prepared to deal with the 
occasional packaging or integration issue and thus finds ~arch perfectly 
usable, I'd personally have no problem with dropping stable, it's just 
that I know it to be a practical impossibility, because were we to do so, 
instead of freeing that time to work on what's now ~arch, we'd simply 
lose most of the volunteers who have a major interest in stable.

-- 
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 pre-GLEP] Gentoo Git Workflow

2017-07-27 Thread Duncan
Michał Górny posted on Tue, 25 Jul 2017 10:05:06 +0200 as excerpted:

> ==Backwards Compatibility==
> Most of the new policy will apply to the commits following its approval.
> Backwards compatibility is not relevant there.

s/Backwards/Backward/ (both header and body)

"Backwards" is a regionalism I too have problems with (as a native
USian with time in the former Crown colony Kenya and exposure to various
European and Asian as well as widely dispersed USian usage.  According
to the wictionary entry, "backward" is strictly speaking the adjective in
British English, "backwards" the adverb, while in the US, the usage is
more flexible/regional and may be reversed.

But (when I catch myself) I always try to use "backward", because the
addition of the terminating "s" adds no meaning and has come to sound
like "hick-speak" to my ear.

Regardless, in this instance "backward" is used as an adjective, so the
stricter "backward" should sound find to the British ear, while being at
least flexibly tolerated to the American ear even if their particular
region reverses it.

(Besides, "backwards compatibility" sounds... like something my car
lacked when I was trying to teach someone to drive, after they jammed the
transmission in reverse while going forward.  Hmm... Maybe I favor the
-s form as adverb more than I thought. =:^)

> One particular point that affects commits retroactively is the OpenPGP
> signing. However, it has been an obligatory requirement enforced by the
> infrastructure since the git switch. Therefore, all the git history
> conforms to 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: [RFC pre-GLEP] Gentoo Git Workflow

2017-07-27 Thread Duncan
Michał Górny posted on Tue, 25 Jul 2017 10:05:06 +0200 as excerpted:

> ===Commit messages===

[...]

> Historically, Gentoo has been using a few tags starting with X-
> . However, this practice was abandoned once it has been pointed
> out that git does not enforce any standard set of tags, and therefore
> indicating non-standard tags is meaningless.

Thanks for this historical note.  I hadn't noticed, but if I had, I might
have found the usage and then abandonment confusing, and this clears it
up. =:^)

> Gentoo developers are still frequently using Gentoo-Bug tag,

s/developers are still frequently using/developers still frequently use/

The (past and continuing) tense that you're (apparently) trying to use,
while common in other languages, isn't one English treats separately.

> sometimes followed by Gentoo-Bug-URL. Using both
> simultaneously is meaningless (they are redundant), and using the former
> has no advantages over using the classic #nn form in the
> summary or the body.

-- 
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 pre-GLEP] Gentoo Git Workflow

2017-07-27 Thread Duncan
Michał Górny posted on Tue, 25 Jul 2017 10:05:06 +0200 as excerpted:

> ===Splitting commits===
> Git commits are lightweight, and the developers are encouraged to split
> their commits to improve readability and the ability of reverting
> specific sub-changes. When choosing how to split the commits, the
> developers should consider the following three rules:
> # Use atomic commits — one commit per logical change.
> # Split commits at logical unit (package, eclass, profile…) boundaries.
> # Avoid creating commits that are 'broken' — e.g. are incomplete, have
> uninstallable packages.

(Without commenting on the technical specifics, particularly in the
examples, only nitpicking grammar here...)

Two instances of "the developers":  Should be "the developer" (singular),
or "developers" (plural, no "the"), your choice.  Note that in the first
usage, if the singular "the developer" is chosen, the following "are" and
"their" will need changed to singular as well.

(Of course then there's the question of his/her or a controversial usage
of singular "their" to remain gender neutral, so plural "developers" may
be best there, nicely avoiding the secondary controversy.  FWIW, the
appropriateness of singular they/their to avoid gender specificity is a
current topic of debate in linguistic circles, but is "languagelog approved"
at least, citing usage by respected authors going back over a century, and
seems to be on the way toward wider acceptance.  YMMV, but it's easy enough
to avoid the entire question here, with consistent plural usage.)

> It is technically impossible to always respect all of the three rules,

s/all of the three rules,/all three rules/
(Note omission of the comma too.)

> so developers have to balance between them at their own discretion. Side
> changes that are implied by other change (e.g. revbump due to some
> change) should be included in the first commit requiring them. Commits
> should be ordered to avoid breakage, and follow logical ordering
> whenever possible.
> 
> Examples:
> * When doing a version bump, it is usually not reasonable to split every
> necessary logical change into separate commit since the interim commits

s/into separate commit/into separate commits/

... but that's still slightly uncomfortable due to ambiguous plurality
agreement.  Maybe...

"into its own commit"

> would correspond to a broken package. However, if the package has a live
> ebuild, it ''might'' be reasonable to perform split logical changes on
> the live ebuild, then create a release as another logical step.
> * When doing one or more changes that require a revision bump, bump the
> revision in the commit including the first change. Split the changes
> into multiple logical commits without further revision bumps — since
> they are going to be pushed in a single push, the user will not be
> exposed to interim state.
> * When adding a new version of a package that should be masked, you can
> include the {{Path|package.mask}} edit in the commit adding it.
> Alternatively, you can add the mask in a split commit ''preceding'' the
> bump.
> * When doing a minor change to a large number of packages, it is
> reasonable to do so in a single commit. However, when doing a major
> change (e.g. a version bump), it is better to split commits on package
> boundaries.

-- 
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 pre-GLEP] Gentoo Git Workflow

2017-07-27 Thread Duncan
Michał Górny posted on Tue, 25 Jul 2017 10:05:06 +0200 as excerpted:

> ==Specification==
> ===Branching model===
> The main branch of the Gentoo repository is the master
> branch. All Gentoo developers push their work straight to the master
> branch, provided that the commits meet the minimal quality standards.
> The master branch is also used straight for continous user repository
> deployment.

s/continous/continuous/

> Since multiple developers work on master concurrently, they may be
> required to rebase multiple times before being able to push. Developers
> are requested not to use workflows that could prevent others from
> pushing, e.g. pushing single commits frequently instead of staging them
> and using a single push.

This is unclear as to which of the two behaviors is encouraged
vs. discouraged.  Maybe just add an an explicit "(encouraged)" and
"(discouraged)" by each as appropriate?

> Developers can use additional branches to facilitate review and testing
> of long-term projects of larger scale. However, since git fetches all
> branches by default, they should be used scarcely. For smaller projects,
> local branches or repository forks are preferred.

Nit-picking/quibble:

"Can" vs. "may":  While "can" is perfectly appropriate as used here in
informal settings, "may" is more formal (with "can" reserved for whether
it's technically possible, not at issue here or it wouldn't need mentioned,
while "may" indicates it's approved/recommended, there's a child's game,
"Mother may I", that I recall reinforcing this when I was young).

Since this is intended as a GLEP it's arguably quite formal and "may"
/may/ be more appropriate, thus my mention of the issue altho either
should be well understood and "can" would be entirely appropriate if the
context isn't considered quite that formal.

Entirely a judgment call.

> Unless stated otherwise, the rules set by this specification apply to
> the master branch only. The development branches can use relaxed rules.

Can/may... There may be other uses I won't mention but if you decide
it's worth changing at all, a search and evaluate usage may be worth it.

> Rewriting history (i.e. force pushes) of the master branch is forbidden.

-- 
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 pre-GLEP] Gentoo Git Workflow

2017-07-27 Thread Duncan
Michał Górny posted on Tue, 25 Jul 2017 10:05:06 +0200 as excerpted:

> ==Motivation==
> Although the main Gentoo repository is using git for two years already,
> developers still lack official documentation on how to use git
> consistently. Most of the developers learn spoken standards from others
> and follow them. This eventually brings consistency to some extent but
> is suboptimal. Furthermore, it results in users having to learn things
> the hard way instead of having proper documentation to follow.

Just a couple grammar fixes:

First sentence: s/repository is using git/repository has been using git/

Second: s/Most of the developers/Most developers/

-- 
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?

2017-07-24 Thread Duncan
Rich Freeman posted on Mon, 24 Jul 2017 19:52:40 -0400 as excerpted:

> On Mon, Jul 24, 2017 at 7:22 PM, Peter Stuge <pe...@stuge.se> wrote:
>>
>> I hold a perhaps radical view: I would like to simply remove stable.
>>
>> I continue to feel that maintaining two worlds (stable+unstable)
>> carries with it an unneccessary cost.
>>
>>
> The question is whether devs would start being more conservative with
> ~arch if it essentially turned into the new stable?
> 
> If ~arch doesn't break then we're probably delaying updates too much.
> If it does start breaking and we don't have any alternative, we'll
> probably start losing users who just can't deal with their systems
> breaking.
> 
> Personally I'd rather see stable stick around.  If it isn't updated
> often that isn't a big deal (to me at least).

Indeed, while along with Peter I have little personal use for stable 
(~arch is my stable, live-git my unstable, and stale arch, well, stale), 
I've come to realize over the years that there's enough gentooers, both 
users and devs, that do stable, that killing it isn't going to be the 
boon people only looking at all that "wasted" effort might believe it to 
be.

Instead, were gentoo to lose stable, it'd ultimately shrink as both users 
and devs that previously found gentoo stable the most effective 'scratch' 
to their 'configurable stability itch', were forced to look elsewhere to 
scratch that itch.  While there's a small chance it'd be an incremental 
gain for gentoo ~arch, there's a far larger chance it'd be the beginning 
of the end as without stable, the gentoo community could easily shrink 
into unsustainability -- too few people ever considering being users to 
produce enough incoming developers to maintain gentoo ~arch at anything 
close to the level we have now.


OTOH, there may be a case to be made for the implications of Rich's 
suggestion... and mine above.  Arguably just lose the pretense and simply 
rename stable -> stale, and let people that want/need it continue to deal 
with it on those terms.  At least that way gentoo security advisories, 
etc could then be for "gentoo stale", and as such wouldn't look so dated 
when they come out half a year after the upstream public vulnerability 
and patch and/or unaffected release announcements, because that's what it 
took to stabilize the patched version on some platform or other that was 
holding up the glsa.

Automating stabilization and automated keyword dropping on timeouts seems 
the only other practical choice, as unfortunately, "stale" is what we 
have today in practice, if not in name.

So yes, I support the initiative. =:^)

-- 
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: lua upgrade plan

2017-07-02 Thread Duncan
William Hubbs posted on Sun, 02 Jul 2017 10:30:12 -0500 as excerpted:

> On Sun, Jul 02, 2017 at 03:55:54AM +0000, Duncan wrote:
>> William Hubbs posted on Sat, 01 Jul 2017 11:53:59 -0500 as excerpted:
>> 
>> > See this article for why using liblua as a shared library is not
>> > recommended.
>> > 
>> > http://article.gmane.org/gmane.comp.lang.lua.general/18519
>> 
>> PMFJI, but...
>> 
>> That reply is from 2005 and is apparently specific to (32-bit) x86's
>> extreme shortage of general purpose registers.  Back then it made sense
>> as 32-bit x86 was the dominant arch, both for gentoo, and (apparently)
>> for that lua discussion (which was in the debian context). [...]

>> So... got any equivalent links to posts with more modern figures?
>  
> That link actually came from our current lua ebuilds. The shared library
> is offered, but the comments in the ebuild basically say the same thing
> and cite that link.

Thanks. =:^)

> Also, x86 is still a stable supported arch in Gentoo.

Two points:

1) x86 is indeed still a stable supported arch, as are, I think, a few 
others.  But we're not discussing _breaking_ lua on x86, simply accepting 
that default-dynamic-linking lua wouldn't be as efficient on x86 as it 
would be on less register-short archs, including the now dominant amd64.

Seems a reasonable tradeoff to be made, particularly given it's the 
choice other distros as well were choosing even when x86 /was/ the 
majority arch.

Especially when given that on gentoo, those that believe they have reason 
to can choose to statically link in any case.  It's just that gentoo 
normally defaults to dynamic linking if people haven't specifically 
chosen static linking.  (Or would static linking not be a user-side 
option in this case if the dynamic-link route were chosen?)

2) Just to be explicitly in case the (quote I've now omitted) bit below 
that didn't make it clear: I still support killing the shared lib if 
maintainer-desired, even if the only /technical/ reason is that upstream 
doesn't support it (for reasons apparently no longer valid on modern 
archs, but...), due to the extra work then required.

I simply believe it's important to be honest about it, if that is indeed 
the case, and am wondering if 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: lua upgrade plan

2017-07-01 Thread Duncan
William Hubbs posted on Sat, 01 Jul 2017 11:53:59 -0500 as excerpted:

> See this article for why using liblua as a shared library is not
> recommended.
> 
> http://article.gmane.org/gmane.comp.lang.lua.general/18519
> 
> Yes, it talks about the interpretor, but it goes further and really
> discourages even making a shared library available.

PMFJI, but...

That reply is from 2005 and is apparently specific to (32-bit) x86's 
extreme shortage of general purpose registers.  Back then it made sense 
as 32-bit x86 was the dominant arch, both for gentoo, and (apparently) 
for that lua discussion (which was in the debian context).

That x86 general lack of registers was one of the big pressures behind 
the switch to amd64, before system memory sizes increased to 4GB+, and 
applies far less to today's dominant amd64, with x86 now legacy/embedded.

Now it may well be that lua performance remains register sensitive even 
with the increased number of registers available in amd64 and other 
modern archs, but quoting an 11+-year-old email written in the extremely 
register-restricted 32-bit x86 context does little to argue that point.

So... got any equivalent links to posts with more modern figures?


All that said, in FLOSS, he who volunteers, makes the rules, and 
particularly given the upstream opposition meaning more gentoo-level work 
required, if there's nobody willing to support lua in gentoo with dynamic 
linking...

... people unable or unwilling to volunteer to support their preferred 
alternative get to live with one they don't like, whether that be 
accepting what their existing distro provides even if it's not optimal, 
switching to another, or supporting their own patches or builds apart 
from gentoo.

At least gentoo makes the latter case relatively easy compared to some 
distros.  I did it with kde twice, when gentoo/kde wasn't supporting 
builds without semantic-desktop. =:^)

And in this case it appears there's even someone already doing it and 
making their work public via the lua overlay. =:^)

-- 
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] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

2017-05-31 Thread Duncan
Alexis Ballier posted on Wed, 31 May 2017 09:32:57 +0200 as excerpted:

>> For example:
>> 
>>   foo? ( bar )
>> 
>> would mean 'if you have USE=foo, then USE=bar is enabled as well'. Not
>> 'find some random solution which satisfies this'. In other words, here
>> changing USE=foo into USE=-foo is not an acceptable solution.
> 
> 
> What if I specifically set USE=-bar in make.conf ? Do we really want PM
> to override that without telling me ?

Yes, override (tho the telling me bit would be up to the PM 
implementation and could be as indirect as simply showing the new pulled-
in package in ask/pretend) because USE flags always control options and 
don't disable mandatory requirements, which is what this scenario is 
ultimately describing, even if it's /conditional/ mandatory.

If a user cares enough about not wanting whatever USE=bar pulls in, 
they'll notice the pull-in in ask/pretend and abort the merge, 
investigating and changing config or deciding they don't need that 
package after all, just as they do with mandatory pull-ins now.

As for more direct indications, portage could and I'd expect would 
indicate the USE override the same as it does for profile-masked and new-
version-deleted USE flags now, putting them in parentheses so the user 
knows they no longer apply.  I'm not familiar enough with other PMs to 
know if/how they indicate such things, but I'd imagine they could 
similarly treat it to the way they do masked flags today.  After all, 
it's simply another method of masking, only in this case it's dynamic, by 
the PM at solve time.

-- 
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: Dropping ia64/ppc/sparc profiles to dev/exp

2017-05-14 Thread Duncan
Michael Weber posted on Sun, 14 May 2017 13:17:36 +0200 as excerpted:

> On 05/14/2017 01:05 PM, Michał Górny wrote:
>> On nie, 2017-05-14 at 12:52 +0200, Michael Weber wrote:
>>> On 05/14/2017 12:44 PM, David Seifert wrote:
>>>> On Sun, 2017-05-14 at 12:38 +0200, Michael Weber wrote:
>>>>> On 05/08/2017 09:13 PM, David Seifert wrote:

>>>>>> If all of this ends in one big bikeshedding fest again, I will
>>>>>> start dekeywording packages. Fortunately for me, I won't get any
>>>>>> complaints (because the arch teams are dead).
>>>>>
>>>>> formal complaint, powerpc team is alive, and I'm lead.
>>>>
>>>> https://bugs.gentoo.org/show_bug.cgi?id=546082
>>>>
>>>> You call that alive?
>>>>
>>>>
>>> Well, I'm working on stabilization for some months and started
>>> keywordings just recently.
>>>
>>> FTR, nobody saw the need to migrated this bug Component:Keywording
>>> (was [old] ...) and it didn't show up on my radar, nor on x86s.
>>>
>>>
>> Why would you expect to developers spend their effort on moving bugs to
>> new keywording workflow *after* the arch teams have been neglecting
>> them for 1.5 years?
>> 
> Because we (or some subset) agreed on the "new keywording workflow" and
> we all obliged to play by the rules?

Sure, for new bugs.

I don't believe it applies to still open old bugs, especially those filed 
and with no new activity for a year before the new workflow came to be.  
If they've not been touched in the then-current workflow in a year (and 
I'd argue something shorter, say 90 days, which just emphasizes how old 
those bugs really are), where's the justification to bother migrating 
them to the new workflow?  They should have been acted upon well before 
the new workflow came to be, and if people are bothering to migrate, I'd 
not blame that at all for migrating them to RESOLVED/WONTFIX (aka 
dekeywording as the older keyworded versions are removed), as to all 
indications that's the reality.

So maybe it's better for PPC they're /not/ migrated?

-- 
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] profiles: update pie use-flag masks for sys-devel/gcc

2017-05-11 Thread Duncan
Jonathan Callen posted on Thu, 11 May 2017 23:25:24 -0400 as excerpted:

> In this case, you would add a line like:
> 
> >=sys-devel/gcc-6.3.0 -pie
> 
> to the /etc/portage/profile/package.use.mask file (creating the
> file/parent directory as needed).  If a flag is masked/forced for all
> packages in use.{mask,force}, then you would add a line like "-foo" to
> the use.{mask,force} file in /etc/portage/profile/.

Thanks.  As I said I doubt I'm the only one who will find this 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: [PATCH] profiles: update pie use-flag masks for sys-devel/gcc

2017-05-11 Thread Duncan
Matthias Maier posted on Thu, 11 May 2017 19:17:51 -0500 as excerpted:

> In light of the recent discussion, I will restore the status quo for the
> pie use-flag: masked on non-hardened profiles, unmasked and forced on
> hardened profiles.
> 
> The next step will be to switch the pie use-flag on default profiles
> from masked to unmasked/forced with a profile update.

For those of us who already have a default-pie system and now that we do, 
don't want to go back, what's the prescribed override?  I've never felt 
the need to override a masked flag like that, before.

(I'm sure I could find the general documentation and handle it myself, 
but I'm equally sure that there's likely to be others in my situation by 
now, and we shouldn't /all/ need to figure it out on our own.)

(As some may remember, yes, I do have USE="-* ..." set, so didn't get pie 
with the initial gcc6 emerge and @world rebuild, but I was persuaded by 
the discussion here to try it, second global rebuild, and so far it 
works.  So both because it's supposed to be safer and because I don't 
want to do now a /third/ global rebuild, I strongly prefer to keep it, 
now that I have it, and no issues so far.)

-- 
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: Reverse use of Python/Ruby versions

2017-04-10 Thread Duncan
I'm subscribed here, to get a heads-up on many of the major system 
changes that are likely to affect me before I'm trying to figure them out 
from emerge -vp errors.  Of course it's also because I actively chose 
gentoo as my distro and what happens in the gentoo community is something 
I care about, not just because it affects my system, but because I'm a 
part of that community and care what happens in it.

So I'm about the /last/ user to accuse of "not caring" about what's on my 
system, yet apparently because I don't have PYTHON_TARGETS wildcarded and 
didn't have to hack it to only have the two versions on the system, 
you're claiming I /don't/ care.

Of course if I wanted the 3.x version to be 3.5, I'd have a bit more 
hacking to do, but that just comes with the territory -- it's the same 
sort of grabbing patches from bugzie, etc, that I had to do when I wanted 
to run the still masked because not all packages had integrated the 
required patches yet gcc.  In fact, that's effectively what python:3.5 
*is* on my system, via package.mask, for much the same reason, not all 
packages I have merged have tested support for it yet.


Meanwhile, what you're proposing would turn that upside down.  I *would* 
have to hack things to get and keep them working then, package-masking 
the new python for versions that didn't work with it yet that hadn't been 
masked in the upstream gentoo and overlay repos, and/or googling gentoo 
bugzie and the net for patches so they would work, etc, much as I had to 
do with new gccs to get them to work, because you will have broken the 
previously working PYTHON_TARGETS system that was keeping things sane by 
only updating a package's PYTHON_TARGETS for a new python once it had 
actually been tested to work 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




  1   2   3   4   5   6   7   8   9   10   >