Re: [gentoo-dev] [RFC] Dealing with global /usr/bin/libtool use vs CC/CXX etc.

2021-01-10 Thread Joshua Kinard
On 1/10/2021 09:47, Michał Górny wrote:
> On Sun, 2021-01-10 at 14:54 +0100, Fabian Groffen wrote:
>> On 10-01-2021 14:34:13 +0100, Michał Górny wrote:
>>> The vast majority of libtool-based programs use configure script to
>>> generate libtool.  However, a few non-autoconf packages also use libtool
>>> by calling system-installed /usr/bin/libtool.  The problem is that this
>>> libtool hardcodes the values of CC/CXX at its' build time, so unless it
>>> is rebuilt frequently, packages end up using the stale values.
>>> The problem is known since 2005 [1] and hasn't been resolved yet.
>>>
>>> I can think of two ways of solving it:
>>>
>>> 1. We could patch system-installed libtool to respect environment
>>> variables such as CC, CXX, etc.  This will probably require carrying
>>> a (possibly non-trivial) patch forever.  On the bright side, libtool is
>>> not exactly a package seeing frequent releases.  I mean, the current
>>> version is from 2015.
>>>
>>> 2. We could regenerate libtool and force local instance of libtool
>>> in the packages needing it.  The main advantage of this is that it's
>>> a no-brainer.  I could make a quick eclass that does configure a local
>>> instance and prepends it into PATH.
>>>
>>> WDYT?
>>
>> I would prefer option 2, also because on some systems usr/bin/libtool is
>> some entirely different tool than GNU libtool.
>>
>> I remember this being much more of a problem ~15 years ago, so I wonder
>> do we have an easy way of crafting a list of affected packages, such
>> that we can see how big the problem actually is nowadays?  I'm thinking
>> perhaps tinderbox logs or something can reveal /usr/bin/libtool usage
>> somehow.
> 
> I think it might be possible to do something akin USE=-native-symlinks
> that makes libtool not install /usr/bin/libtool, and see what breaks. 
> However, I'm not sure if this executable isn't required for some obscure
> reason anyway.

Second option seems better, and basically just enforces what's been a
standard habit anyways (I at least try to manually rebuild libtool when
changing gcc major versions, but not so much for minor versions).

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] Last-rites: sys-power/pm-utils, sys-power/pm-quirks, app-admin/cgmanager and sys-libs/libnih

2021-01-09 Thread Joshua Kinard
On 1/8/2021 08:39, Andreas Sturmlechner wrote:
> On Freitag, 8. Januar 2021 08:10:05 CET Jaco Kroon wrote:
>> Would it be possible to point at alternatives?  pm-utils worked well for
>> me until now, and I'm fairly certain this won't be abandoned unless
>> there are other (better?) alternatives available.
>>
> 
> It is replaced by elogind or systemd builtin functions.
> 
> Regards

sys-power/suspend seems to work for me on my system.  Calling s2ram puts the
machine into S3 state, and it resumes without issue thus far.

pm-suspend --> s2ram
pm-hibernate --> s2disk
pm-suspend-hybrid --> s2both

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] RFC: dropping support for uclibc-ng

2021-01-05 Thread Joshua Kinard
On 1/6/2021 01:08, Thomas Mueller wrote:
>> I was using uclibc-ng builds for MIPS to build netboot images between 2017
>> and 2019 to refine my build processes.  uclibc-ng still produces smaller
>> overall binaries and libs for the netboot than musl does (usually ~1MB
>> smaller, which is actually significant, especially on SGI IP22 systems).
> 
>> Unfortunately for uclibc-ng, it stopped working for me in ~2019.  I have no
>> clue why, either.  The March 2019 uclibc-ng MIPS stage3 I built internally
>> works perfectly fine when you unpack it and leave it alone, but as soon as
>> you compile *anything* more recent with the compiler that's when the
>> breaking begins.
> 
>> Rebuilding ncurses in this stage3 will break Python, which breaks emerge.
>> Never figured it out.  I can trace the failure using GDB to a point in
>> Python, but not much farther beyond that.  I assume the true cause is
>> something in uclibc-ng itself.  Upstream seems to like to borrow chunks of
>> glibc for things, and I wonder if that may be partly to blame.
> 
>> I eventually gave up and went to musl for MIPS/o32.  musl quite literally
>> JustWorks().  It's great.  Even with that tiny bit of bloat in the netboot
>> build (workable, cause I needed to make NFS Root an option anyways).
> 
>> So long story short, I won't shed any tears if uclibc-ng goes away.
> 
>> Joshua Kinard
> 
> I wonder if uclibc-ng people fixed the bugs since your ill fortune, or if 
> uclibc-ng development has fallen off.
> 
> Since musl works so much better for you, you will probably not want to go 
> back.
> 
> How did you build your March 2019 stage3, or where would I go on Gentoo 
> website?
> 
> I would naturally seek something more current, glibc or musl probably 
> preferable to uclibc-ng.
>  
> Tom

I tried a more recent uclibc-ng earlier in 2020 and it still broke as soon
as it compiled ncurses.  I'm sure there's probably a compile path where if
the right libraries are rebuilt in the right order, I can get it working
again, but it's not worth the time spent.  The machine I am working on is
not a hyper-fast x86/x64 system, but rather a ~15-year old MIPS-based SGI
Octane.  gcc-10.2.0 takes ~15hrs to compile, among other things.

If I cared enough, I could probably try starting a new root image from
scratch by piecing packages together from crossdev, or find another base to
morph into a Gentoo image.  Maybe one day.

The stage3 I refer to isn't available publicly.  It was a test build I did
and never released.  Current mips stages are available on the mirrors in the
'experimental' folder.  They're primarily targeted at older big-endian
MIPS-III and MIPS-IV platforms.  As for how I built it, that's done through
our 'catalyst' tool for stage-building.  You can check the Wiki for more
info on how that works.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] RFC: dropping support for uclibc-ng

2021-01-05 Thread Joshua Kinard
On 1/5/2021 16:05, Anthony G. Basile wrote:
> On 1/5/21 8:43 AM, Jaco Kroon wrote:
>> Hi Thomas,
>>
>> On 2021/01/05 13:08, Thomas Mueller wrote:
>>>> I'd like feedback from people about the possibility of dropping support
>>>> for uclibc-ng.  If you are unfamiliar, its the successor to uclibc as a
>>>> C Standard Library for embedded systems, ie a replacement for glibc
>>>> bloat.  However, it is inferior to musl which serves the same purpose
>>>> and which has now well supported in Gentoo.
>>>> I know people want musl support, but does anyone even care about
>>>> uclibc-ng?  If not, I can work towards deprecating it and putting what
>>>> little time I have towards musl.
>>>> Anthony G. Basile, Ph.D.
>>>> Gentoo Linux Developer [Hardened]
>>> Are you the only Gentoo developer working on musl and uclibc-ng?
> 
> I'm the only one working on uclibc-ng.  There are some people helping
> with musl, especially the overlay.
> 
>>>
>>> One thing I might try with a Gentoo uclibc-ng system is convert to musl or 
>>> glibc using crossdev.
>>>
>>> From what I see on the internet, there is more support for musl than 
>>> uclibc-ng, and more people working with musl than with uclibc-ng.
> 
> It does seem that musl is winning the embedded libc race.
> 
>>>
>>> There is a musl-cross-make cross-toolchain that can be built from non-musl 
>>> or even non-Linux.
>>>
>>> https://github.com/richfelker/musl-cross-make
>>
>> I've used crossdev in the past.  It was a nasty experience, but I
>> believe crossdev in Gentoo is getting better and better, and it supports
>> many more targets.
> 
> Yes it is, which is why I'm preparing pre-build stage3's on several
> arches so you don't have to x-compile.  I've done the nasty part for you.
> 
>>
>>> From what I have seen, musl looks more promising than uclibc-ng, and more 
>>> user- and developer-friendly.
>>>
>>> Unless somebody wants to take over uclibc-ng for Gentoo, I say better for 
>>> you, with your limited time, to drop uclibc-ng in favor of musl.
> 
> 
> Correct, if I had the time, I'd continue to support both.  But my time
> is limited, so I need to concentrate.  I'm just looking for anyone to
> scream if I'm destroying their world by dropping uclibc-ng.  If no one
> does, then I'll begin the process of removing it from the tree.
> 
>>
>> Not doing embedded work at the moment, but just out of hand as of right
>> now if I had to make a choice I'd definitely look at MUSL as first
>> choice.  So +1 for that suggestion.
>>
>> Kind Regards,
>> Jaco

I was using uclibc-ng builds for MIPS to build netboot images between 2017
and 2019 to refine my build processes.  uclibc-ng still produces smaller
overall binaries and libs for the netboot than musl does (usually ~1MB
smaller, which is actually significant, especially on SGI IP22 systems).

Unfortunately for uclibc-ng, it stopped working for me in ~2019.  I have no
clue why, either.  The March 2019 uclibc-ng MIPS stage3 I built internally
works perfectly fine when you unpack it and leave it alone, but as soon as
you compile *anything* more recent with the compiler that's when the
breaking begins.

Rebuilding ncurses in this stage3 will break Python, which breaks emerge.
Never figured it out.  I can trace the failure using GDB to a point in
Python, but not much farther beyond that.  I assume the true cause is
something in uclibc-ng itself.  Upstream seems to like to borrow chunks of
glibc for things, and I wonder if that may be partly to blame.

I eventually gave up and went to musl for MIPS/o32.  musl quite literally
JustWorks().  It's great.  Even with that tiny bit of bloat in the netboot
build (workable, cause I needed to make NFS Root an option anyways).

So long story short, I won't shed any tears if uclibc-ng goes away.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] Pushing to distfiles?

2020-11-11 Thread Joshua Kinard
On 11/11/2020 19:38, Rich Freeman wrote:
> On Wed, Nov 11, 2020 at 7:23 PM Joshua Kinard  wrote:
>>
>> Forgive me for being a dunce, but what is the current procedure to push
>> files to distfiles for distribution to the mirrors?  The devmanual is blank
>> on this topic, and GLEP75 just talks about the motivations behind the change
>> away from the flat directory format.  I am not easily finding anything that
>> details how to get new distfiles onto the mirrors.
>>
> 
> I thought that the whole mirror:// thing was discouraged.  For
> anything else you just stick SRC_URI in the ebuild and the mirrors
> should fetch it when they see it in the repo.
> 
> I just host stuff like that on my dev webspace, or better yet on
> github or something else that will auto-tarball stuff.
> 

And I found it.  It is in the devmanual after all, just under different
wording.  I was searching for "distfiles", when I should have been looking
at the "Mirrors" section.  Looks like we do have some behind-the-scenes
magic that copies SRC_URI files from devspace straight to the mirrors.  Just
way too used to the /space/distfiles-local thing.

RESOLVED::PEBKAC

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



[gentoo-dev] Pushing to distfiles?

2020-11-11 Thread Joshua Kinard
Forgive me for being a dunce, but what is the current procedure to push
files to distfiles for distribution to the mirrors?  The devmanual is blank
on this topic, and GLEP75 just talks about the motivations behind the change
away from the flat directory format.  I am not easily finding anything that
details how to get new distfiles onto the mirrors.

Thanks,

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev

2020-08-10 Thread Joshua Kinard
On 8/10/2020 22:08, Rich Freeman wrote:
> On Mon, Aug 10, 2020 at 9:55 PM Joshua Kinard  wrote:
>>
>> On 8/10/2020 11:22, William Hubbs wrote:
>>> On Mon, Aug 10, 2020 at 12:00:44AM -0400, Joshua Kinard wrote:
>>>>
>>>> If eudev is not broken, then why your proposed fix?
>>>
>>> bitrot and bus factor.
>>
>> Examples?
> 
> The sole maintainer of eudev is going to suddenly disappear before
> getting a chance to tell anybody about the horrible security issue
> they discovered earlier that day.
> 
>> You meant to say "has yet to come true".
>> 
>> Elsewise, as long as that door remains open, then future tense is
>> the correct tense.
> 
> Note that the disappearance of the sole maintainer of eudev has yet to
> happen, but we absolutely need to be taking steps today because
> everybody knows it will happen.  After all, it COULD happen, and so as
> long as that door remains open the future tense is the correct tense.
> :)

I don't disagree completely with your logic, but I *do* disagree that
changing the default udev provider to sys-fs/udev is the best option, or the
only option.


> I find it amusing that everybody is still trembling in fear that
> Lennart is going to take their shell scripts away from them in the
> middle of the night.  But it isn't like anybody needs to touch that
> cruft if they don't want to just because they're working on Gentoo, so
> whatever rocks your boat.

I don't tremble in fear.  I am past that stage at this point, and have just
accepted the fact that at some point, the Linux I used to know and love will
be something I can't work with anymore, and I'll just need to pack my
proverbial bags and move on to greener pastures.  The day when Linux and
systemd become inseparable will happen.  But it won't be like going to sleep
the night before and waking up in an alien world.  The change will be slow
and gradual, just like it has been for the past eight-plus years.  The
question is more, what is my tolerance?  At what point do I give up and move
on?  Haven't found that answer yet, so here I still am, arguing.


> Really though I'd just stick with "ain't broke don't fix it" as there
> really is no reason to get into paranoid FUD.

"Ain't broke don't fix it" doesn't apply here.  My read of recent messages
on this thread suggest to me the change is going to happen, regardless what
a number of us think about it.  See last few sentences of the prior
paragraph above.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev

2020-08-10 Thread Joshua Kinard
On 8/10/2020 11:22, William Hubbs wrote:
> On Mon, Aug 10, 2020 at 12:00:44AM -0400, Joshua Kinard wrote:
>> On 8/8/2020 14:51, William Hubbs wrote:
>>> All,
>>>
>>> I would like to propose that we switch the default udev provider on new
>>> systems from eudev to udev.
>>>
>>> This is not a lastrites, and it will not affect current systems since
>>> they have to migrate manually. Also, this change can be overridden at
>>> the profile level if some profile needs eudev (the last time I checked,
>>> this applies to non-glibc configurations).
>>>
>>> What do people think?
>>>
>>> Thanks,
>>>
>>> William
>>
>> Is eudev broken in some way?  If so, has a bug been filed?  If not, why not?
>>
>> If eudev is not broken, then why your proposed fix?
> 
> bitrot and bus factor.

Examples?  I don't necessarily stay abreast of what new gizmos upstream udev
may or may not be adding that eudev may or may not be missing.  Is there
something critical that you have observed going into upstream udev that
eudev is missing that would be super-awesome or which otherwise improves the
lives of aspiring Gentoo users everywhere?  Or is it related to unpatched
security issues, perhaps?  Is there a list of unmitigated CVE's that
upstream udev has patched that the eudev team has not?

Have you tried reaching out to the eudev developer(s) to see if they're
responsive and to maybe raise your concerns about aforementioned "bitrot"?


>> It works fine for new installs, having just done one myself.  Seems like we
>> aught to keep it that way.  I count six open bugs against eudev right now,
>> and none of them look to be critical, so I vote "no" on your proposal unless
>> there is some verifiable reason why eudev is no longer suitable to be the
>> default udev provider.
> 
> The thing is, udev was never unsuitable. AS I said the original change
> was not because of the lack of suitability, but because of fear of what
> the udev devs might do. That fear never came true.

You meant to say "has yet to come true".  Show me something from the
upstream udev developers where they permanently close the door to making
udev a symbiotic element to systemd and then I'll accept your use of past
tense.  Elsewise, as long as that door remains open, then future tense is
the correct tense.

> 
> Not that it matters much, but I'll go there since you did, I count 26
> open issues against eudev and some of them have been open since 2012.

My search was based on the string "sys-fs/eudev", which is the standard
nomenclature for naming bugs.  If there are other bugs open for eudev that
are missing that, then they need their titles updated.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev

2020-08-09 Thread Joshua Kinard
On 8/8/2020 14:51, William Hubbs wrote:
> All,
> 
> I would like to propose that we switch the default udev provider on new
> systems from eudev to udev.
> 
> This is not a lastrites, and it will not affect current systems since
> they have to migrate manually. Also, this change can be overridden at
> the profile level if some profile needs eudev (the last time I checked,
> this applies to non-glibc configurations).
> 
> What do people think?
> 
> Thanks,
> 
> William

Is eudev broken in some way?  If so, has a bug been filed?  If not, why not?

If eudev is not broken, then why your proposed fix?

It works fine for new installs, having just done one myself.  Seems like we
aught to keep it that way.  I count six open bugs against eudev right now,
and none of them look to be critical, so I vote "no" on your proposal unless
there is some verifiable reason why eudev is no longer suitable to be the
default udev provider.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



[gentoo-dev] Bug #733802, USE 'scp' now defaults to off in net-misc/openssh

2020-07-25 Thread Joshua Kinard
So I stumbled into Bug #733802, which now defaults the 'scp' USE flag to off
in net-misc/openssh.  This seems like something that needs a news entry, or
at least a "heads up" on the mailing list?  Potential for some scripts to
break if scp suddenly goes missing after an openssh update.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] Cleaning up the installation handbook (Legacy boot / MBR / ...)

2020-05-03 Thread Joshua Kinard
On 5/2/2020 16:30, Andreas K. Hüttel wrote:
> Hey all, 
> 
> our installation handbook is right now something of a mess (in particular 
> regarding partitioning, bootloader, gpt/uefi, ...)
> 
> I'm hereby volunteering to clean things up. But - I'll go the brutal way:
> 
> * Legacy boot and MBR will get kicked out. *
> 
> This is your chance to protest or support.
> 
> Cheers,
> Andreas

Keep it.  There are still systems sold that boot classic BIOS instead of
UEFI, and thus might need this info.  If anything, legacy stuff like this
can be put into its own section below the more modern approach, with
appropriate disclaimers that it is legacy.  But odds are likely, it will
need to be retained for quite a few more years.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



[gentoo-dev] Last rites: net-fs/ncpfs, net-misc/ipx-utils

2020-03-28 Thread Joshua Kinard
# Joshua Kinard  (2020-03-28)
# In Linux ~4.18, IPX (Internetwork Packet eXchange) protocol and
# NCPFS (NetWare Core Protocol Filesystem) support was removed due
# to lack of maintenance.  Due to both being dead from a technology
# standpoint and lack of any upstream activity, mask the below
# packages and remove in 75 days.
# Bug #681820
net-fs/ncpfs
net-misc/ipx-utils




signature.asc
Description: OpenPGP digital signature


[gentoo-dev] [PATCH] flag-o-matic.eclass: add some missing MIPS CPU errata options to ALLOWED_FLAGS

2020-03-28 Thread Joshua Kinard
Noticed during a glibc build for MIPS-III ISA that the -mfix-r4000
and -mfix-r4400 gcc flags got stripped off.  These are needed to work
around known CPU errata in R4000 and R4400 CPUs.  In addition, also
add the -mfix-rm7000 option (and it's -mno form) to fix errata in the
PMC RM7000 CPU, and the -mr10k-cache-barrier to control the generation
of cache barriers to work around the side-effects of R1's
speculative execution capabilities.

Signed-off-by: Joshua Kinard 
---
 eclass/flag-o-matic.eclass | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/eclass/flag-o-matic.eclass b/eclass/flag-o-matic.eclass
index e76eef293e..0c67ec9f7a 100644
--- a/eclass/flag-o-matic.eclass
+++ b/eclass/flag-o-matic.eclass
@@ -56,7 +56,9 @@ setup-allowed-flags() {
-mno-faster-structs -mfaster-structs -m32 -m64 -mx32 -mabi
-mlittle-endian -mbig-endian -EL -EB -fPIC -mlive-g0 -mcmodel
-mstack-bias -mno-stack-bias -msecure-plt '-m*-toc' -mfloat-abi
-   -mfix-r1 -mno-fix-r1 -mthumb -marm
+   -mfix-r4000 -mno-fix-r4000 -mfix-r4400 -mno-fix-r4400
+   -mfix-rm7000 -mno-fix-rm7000 -mfix-r1 -mno-fix-r1
+   -mr10k-cache-barrier -mthumb -marm
 
# gcc 4.5
-mno-fma4 -mno-movbe -mno-xop -mno-lwp




Re: [gentoo-dev] musl doesn't provide execinfo.h

2020-03-26 Thread Joshua Kinard
On 3/23/2020 04:21, Jaco Kroon wrote:
> Hi,
> 
> https://bugs.gentoo.org/713668 relates.
> 
>  * Searching for /usr/include/execinfo.h ...
> sys-libs/glibc-2.29-r7 (/usr/include/execinfo.h)
> 
> As I see I can either add an explicit depend on glibc which I'd prefer
> not to.  Or someone from the musl team could possibly assist on how to
> get the backtrace() set of calls on musl please?
> 
> Alternatively I need to add a test and simply path debug.c to only
> provide stub function for print_backtrace(FILE *fp) that just does
> fprintf(fp, "No backtrace() available to print a backtrace.\n");
> 
> Suggestions?
> 
> Kind Regards,
> Jaco

Some quick searching on google, it looks like the cleanest fix for that bug
is dahdi-tools needs to be patched to only include execinfo.h or only use
backtrace() on glibc-based systems, and that patch then sent to the
dahdi-tools upstream developers for inclusion in a future release.  That
way, we're not dragging that patch around forever in the tree or in the musl
overlay.

It also doesn't look like musl itself will ever implement execinfo.h or
backtrace(), per this message in 2015 from the lead musl developer:
https://www.openwall.com/lists/musl/2015/04/09/3

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] unsanctioned python 2.7 crusade

2020-01-13 Thread Joshua Kinard
On 1/13/2020 01:52, Michał Górny wrote:
> On Sun, 2020-01-12 at 17:07 -0500, Joshua Kinard wrote:

[snip]

> Joshua,
> 
> I understand that you don't do much Python ebuild work, or probably
> Python development in general.  I understand that you may feel like you
> need more time with Python 2.  But before sending such mails, please try
> to put yourself in our skin.

Actually, I've done a lot of general Python development over the last few
years outside of Gentoo on work-related stuff.  And I've had to convert
those projects from Py2 to Py3, as well.  In fact when faced with the
decision of maintaining Py2 support alongside Py3, I cut my losses and ran,
and dropped Py2 support in a new version.  Wasn't worth the effort to
maintain both with the limited development time I had.

So I'm not walking into this conversation a happy idiot just saying random
things to see what kind of fun I can cause.  There are things I will
absolutely miss in Python2 (goodbye, ASCII strings).  But there are also
things that I like about Python 3 (hello, lru_cache).  So I've been there,
in the proverbial trenches, and know of the pain fellow pythonistas have
gone through over the last few years.

That said, strictly on the ebuild-side of things, yes, I have not dabbled in
that too much.  But I do have some understanding of what you are going through.


> Now imagine someone who doesn't really know much about maintaining
> Python in Gentoo and problems related to Python 2 sunrising, grabs one
> site about Python releases and tells me what to do without knowing
> the wider context.  Wouldn't you feel angry?  Demotivated?  Depressed
> even?

Actually, I wouldn't feel any of those at all.  I'd probably laugh at it, in
fact.  Why laugh?  Because in that context, I would have knowledge and
understanding of the wider issue, while the poor sod who just proposed that
crazy idea would not.  And my laughter would be more at myself, because
knowing the terrible truth kindles in me a desire to return to that time
when I, too, was ignorant and happy and free.  But the chains of knowledge
bind me to a much more grim fate.


> I mean, forgive my expression but we're deep in shit.  As you've noticed
> yourself, emerge spews few pages of 'I can't upgrade setuptools' because
> of humongous number of packages that still need Python 2-capable
> version.  Sure, we could put some effort into making it still work with
> Python 2, then start collecting more and more patches to various
> packages just to keep things working.  But then, 3-6-12 months from now
> it will no longer be feasible, the cesspool will overflow and we'll be
> even deeper in shit that we're today.
> 
> If people started removing Python 2 from Gentoo years ago, like upstream
> suggested, today things would be much better.  But we waited till last
> minute.  And now you're telling us to wait more because there will be
> a new release of the *interpreter*?

FWIW, I was just making a suggestion, not directing an inviolable course of
action.  So calm down, calm down.  If anything, perhaps we should at least
put out an eselect news release that reads like an "under construction"
notice to let users (and other devs) know that there's going to be some
rough spots ahead while Py2 support is excised from the tree.  If there's a
tracker bug, then directing them to that as well so there's a way for people
to follow the process of the removal and even help chase down loose ends.

Again, that's just a suggestion, so please put the pitchforks down if ya'll
don't like it.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] unsanctioned python 2.7 crusade

2020-01-12 Thread Joshua Kinard
On 1/12/2020 19:21, William Hubbs wrote:
> On Mon, Jan 13, 2020 at 12:17:36AM +0100, David Seifert wrote:
>> On Sun, 2020-01-12 at 17:55 -0500, Joshua Kinard wrote:
>>> On 1/12/2020 17:46, David Seifert wrote:
>>>> On Sun, 2020-01-12 at 17:43 -0500, Joshua Kinard wrote:
>>>>> On 1/12/2020 17:32, Andreas Sturmlechner wrote:
>>>>>> On Sonntag, 12. Januar 2020 23:07:24 CET Joshua Kinard wrote:
>>>>>>> It might be worthwhile to treat the removal of Python-2.7
>>>>>>> from
>>>>>>> the tree in
>>>>>>> the same manner as an EAPI deprecation and removal, given how
>>>>>>> ingrained it
>>>>>>> is due to its longevity.  That will minimize the whiplash-
>>>>>>> effect
>>>>>>> of emerge
>>>>>>> complaining about slot conflicts and dependency
>>>>>>> conflicts.  Like
>>>>>>> I just ran
>>>>>>> into w/ setuptools-45.0.0.0's release.
>>>>>>
>>>>>> So, no packaging of >=setuptools-45.0.0 until the end of 2020?
>>>>>> Do
>>>>>> you want to 
>>>>>> freeze all python libs that upstreams are dropping py27 support
>>>>>> from?
>>>>>>
>>>>>
>>>>> Not saying not to package it.  Right now, the issue seems to be
>>>>> it
>>>>> causes
>>>>> dependency conflicts in emerge's depgraph parsing when
>>>>> PYTHON_TARGETS
>>>>> includes python2_7 support.  Remove that and stick with python3_*
>>>>> only, then
>>>>> other packages that need python2_7 will whine.
>>>>>
>>>>> Did setuptools-45.0.0 remove all python2 support?  I looked at
>>>>> the
>>>>> commit
>>>>> log, and it's only the title that any meaningful hint that it may
>>>>> have,
>>>>> "dev-python/setuptools: Bump to 45.0.0 (py3 only)".  If it did,
>>>>> then
>>>>> that
>>>>> change is the right change, but anyone with a userland that has a
>>>>> mix
>>>>> of
>>>>> python2 and python3 is going to have difficulty getting that
>>>>> update
>>>>> to merge
>>>>> in, so I really can't go higher than setuptools-44.0.0 for the
>>>>> time
>>>>> being.
>>>>>
>>>>
>>>> https://setuptools.readthedocs.io/en/latest/history.html#v45-0-0
>>>
>>> At least you didn't squirrel that behind a lmgtfy link 
>>>
>>> In any event, it's clear the tree does not seem set up real well to
>>> handle
>>> the random removal or deprecation of python2 support.  And
>>> considering
>>> python2.7 isn't dead //yet//, I have to question the wisdom of
>>> removing
>>> packages that still support 2.7, and also wonder if there's a way to
>>> be more
>>> graceful in handling updates to packages whose upstream decides to
>>> remove
>>> python2 support.
>>>
>>> Or we can just continue down the current Mad Max methodology and
>>> leave it to
>>> every developer for themselves.
>>>
>>
>> Or - you know - you could help? Talk is cheap, gracefully removing py2
>> from the tree is the hard part. A quick grep tells me we have 4388
>> ebuilds in the tree with python_targets_python2_7 in IUSE. Have fun
>> devising a plan (and then doing the actual work). Pro-tip: "Don't
>> remove py2" is not an actual plan when many important core dependencies
>> have started removing py2 already.
> 
> Joshua and all, I am not on the python team either, but I want to drop
> this link here for reference in case you haven't seen it.
> 
> https://python3statement.org
> 
> tl;dr: python 2.7 was actually deprecated in 2015 with support extended
> to 2020-01-01 so folks would have time to transition off of it. All of
> the upstreams on that list will be dropping support for python 2.7 this
> year if they haven't already done so.
> 
> Given that, I think it is going to be extremely difficult to keep py 2.7
> in the main tree.
> 
> William

That as it may be, I'm generally of the opinion that as long as there are
still new releases, we should support it.  Once the upstream releases stop,
then remove it.  For a normal package, this would be a complete non-issue,
but Python is hardly a normal package.  That said, if we don't have the
manpower or the desire to maintain it, then I don't see a problem with
removing it.

I just wish emerge was better at handling the resulting slot/dependency
conflicts that are arising as some packages get pulled and others updated
with py3-only support.  I am working now to remove the remaining py2
packages from my systems and then rebuild the python packages to only handle
py3.  The MIPS box is going to take its sweet time on that, though, but cest
la vie...

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] unsanctioned python 2.7 crusade

2020-01-12 Thread Joshua Kinard
On 1/12/2020 17:46, David Seifert wrote:
> On Sun, 2020-01-12 at 17:43 -0500, Joshua Kinard wrote:
>> On 1/12/2020 17:32, Andreas Sturmlechner wrote:
>>> On Sonntag, 12. Januar 2020 23:07:24 CET Joshua Kinard wrote:
>>>> It might be worthwhile to treat the removal of Python-2.7 from
>>>> the tree in
>>>> the same manner as an EAPI deprecation and removal, given how
>>>> ingrained it
>>>> is due to its longevity.  That will minimize the whiplash-effect
>>>> of emerge
>>>> complaining about slot conflicts and dependency conflicts.  Like
>>>> I just ran
>>>> into w/ setuptools-45.0.0.0's release.
>>>
>>> So, no packaging of >=setuptools-45.0.0 until the end of 2020? Do
>>> you want to 
>>> freeze all python libs that upstreams are dropping py27 support
>>> from?
>>>
>>
>> Not saying not to package it.  Right now, the issue seems to be it
>> causes
>> dependency conflicts in emerge's depgraph parsing when PYTHON_TARGETS
>> includes python2_7 support.  Remove that and stick with python3_*
>> only, then
>> other packages that need python2_7 will whine.
>>
>> Did setuptools-45.0.0 remove all python2 support?  I looked at the
>> commit
>> log, and it's only the title that any meaningful hint that it may
>> have,
>> "dev-python/setuptools: Bump to 45.0.0 (py3 only)".  If it did, then
>> that
>> change is the right change, but anyone with a userland that has a mix
>> of
>> python2 and python3 is going to have difficulty getting that update
>> to merge
>> in, so I really can't go higher than setuptools-44.0.0 for the time
>> being.
>>
> 
> https://setuptools.readthedocs.io/en/latest/history.html#v45-0-0

At least you didn't squirrel that behind a lmgtfy link 

In any event, it's clear the tree does not seem set up real well to handle
the random removal or deprecation of python2 support.  And considering
python2.7 isn't dead //yet//, I have to question the wisdom of removing
packages that still support 2.7, and also wonder if there's a way to be more
graceful in handling updates to packages whose upstream decides to remove
python2 support.

Or we can just continue down the current Mad Max methodology and leave it to
every developer for themselves.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] unsanctioned python 2.7 crusade

2020-01-12 Thread Joshua Kinard
On 1/12/2020 17:32, Andreas Sturmlechner wrote:
> On Sonntag, 12. Januar 2020 23:07:24 CET Joshua Kinard wrote:
>> It might be worthwhile to treat the removal of Python-2.7 from the tree in
>> the same manner as an EAPI deprecation and removal, given how ingrained it
>> is due to its longevity.  That will minimize the whiplash-effect of emerge
>> complaining about slot conflicts and dependency conflicts.  Like I just ran
>> into w/ setuptools-45.0.0.0's release.
> 
> So, no packaging of >=setuptools-45.0.0 until the end of 2020? Do you want to 
> freeze all python libs that upstreams are dropping py27 support from?
> 

Not saying not to package it.  Right now, the issue seems to be it causes
dependency conflicts in emerge's depgraph parsing when PYTHON_TARGETS
includes python2_7 support.  Remove that and stick with python3_* only, then
other packages that need python2_7 will whine.

Did setuptools-45.0.0 remove all python2 support?  I looked at the commit
log, and it's only the title that any meaningful hint that it may have,
"dev-python/setuptools: Bump to 45.0.0 (py3 only)".  If it did, then that
change is the right change, but anyone with a userland that has a mix of
python2 and python3 is going to have difficulty getting that update to merge
in, so I really can't go higher than setuptools-44.0.0 for the time being.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] unsanctioned python 2.7 crusade

2020-01-12 Thread Joshua Kinard
On 1/12/2020 17:17, David Seifert wrote:
> On Sun, 2020-01-12 at 17:07 -0500, Joshua Kinard wrote:
>> On 12/5/2019 09:24, Rich Freeman wrote:
>>> On Thu, Dec 5, 2019 at 8:59 AM Jason A. Donenfeld >>> wrote:
>>>> It's quite another to mask random packages that have USE flags to
>>>> optionally support whatever python 2.7 library. If you're going
>>>> to
>>>> last rites these, talk with the maintainer first, and only then,
>>>> send
>>>> emails one at a time. Doing that en masse isn't appropriate.
>>>
>>> ++ - I have no idea if that happened.  For anything USE-controlled
>>> it
>>> would make more sense to file a bug or mask the package-flag combo
>>> itself.
>>>
>>>> On another topic, I'd prefer for python 2.7 not to be removed
>>>> from
>>>> gentoo. Tons of code still uses it.
>>>>
>>>
>>> I'm sure a million people would share that preference.  I'm not
>>> sure
>>> what the upstream/security status is of 2.7.  Obviously to keep it
>>> around it would need to be reasonably secure, and somebody within
>>> Gentoo would have to want to maintain it.  That's basically the
>>> criteria for keeping anything like this around.  If somebody
>>> stepped
>>> up and said "I'm maintaining 2.7 and here is why it will remain
>>> secure..." I doubt they'd get a lot of resistance.
>>>
>>
>> I'm late to the party as usual.  Seems upstream plans a final 2.7.18
>> security update in April of 2020, then they will consider the 2.7
>> branch
>> EOL.  They say most of these updates were done in 2019, and so are
>> still
>> technically sticking to their mantra of no more updates after
>> 01/01/2020.
>>
>> PEP 373 covers this:
>> https://www.python.org/dev/peps/pep-0373/#release-schedule
>>
>> """
>> Planned future release dates:
>>
>> 2.7.18 code freeze January, 2020
>> 2.7.18 release candidate early April, 2020
>> 2.7.18 mid-April, 2020
>> """
>>
>> IMHO, I think we should retain 2.7.x compatibility for 1 year AFTER
>> the
>> release of 2.7.18.  This provides some time for people to transition
>> systems
>> off of 2.7-dependent packages.
>>
>> It might be worthwhile to treat the removal of Python-2.7 from the
>> tree in
>> the same manner as an EAPI deprecation and removal, given how
>> ingrained it
>> is due to its longevity.  That will minimize the whiplash-effect of
>> emerge
>> complaining about slot conflicts and dependency conflicts.  Like I
>> just ran
>> into w/ setuptools-45.0.0.0's release.
>>
> 
> Thanks for volunteering to help us manage the ton of packages that have
> dropped py2 in the mean time. I wasn't aware you were part of the
> python team, but I must have been mistaken!

I'm not, heh.  But I have noticed the increasing difficulty of getting
emerge to do clean updates recently because of these removals, especially
when you go several weeks between --sync updates on a machine.  The status
of py2 removal does not seem to have been communicated really well, nor any
kind of plan agreed upon, like we've done w/ the EAPI removal.

If I had more time outside of work, I'd love to help.  But it's a struggle
enough right now to keep my systems ~arch updated, especially since my MIPS
boxes aren't exactly speed demons.  Right now, I'm just suggesting that
maybe we should apply the brakes a little bit and try to coordinate how to
remove py2 completely, rather than the way it's being done now.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] unsanctioned python 2.7 crusade

2020-01-12 Thread Joshua Kinard
On 12/5/2019 09:24, Rich Freeman wrote:
> On Thu, Dec 5, 2019 at 8:59 AM Jason A. Donenfeld  wrote:
>>
>> It's quite another to mask random packages that have USE flags to
>> optionally support whatever python 2.7 library. If you're going to
>> last rites these, talk with the maintainer first, and only then, send
>> emails one at a time. Doing that en masse isn't appropriate.
> 
> ++ - I have no idea if that happened.  For anything USE-controlled it
> would make more sense to file a bug or mask the package-flag combo
> itself.
> 
>>
>> On another topic, I'd prefer for python 2.7 not to be removed from
>> gentoo. Tons of code still uses it.
>>
> 
> I'm sure a million people would share that preference.  I'm not sure
> what the upstream/security status is of 2.7.  Obviously to keep it
> around it would need to be reasonably secure, and somebody within
> Gentoo would have to want to maintain it.  That's basically the
> criteria for keeping anything like this around.  If somebody stepped
> up and said "I'm maintaining 2.7 and here is why it will remain
> secure..." I doubt they'd get a lot of resistance.
> 

I'm late to the party as usual.  Seems upstream plans a final 2.7.18
security update in April of 2020, then they will consider the 2.7 branch
EOL.  They say most of these updates were done in 2019, and so are still
technically sticking to their mantra of no more updates after 01/01/2020.

PEP 373 covers this:
https://www.python.org/dev/peps/pep-0373/#release-schedule

"""
Planned future release dates:

2.7.18 code freeze January, 2020
2.7.18 release candidate early April, 2020
2.7.18 mid-April, 2020
"""

IMHO, I think we should retain 2.7.x compatibility for 1 year AFTER the
release of 2.7.18.  This provides some time for people to transition systems
off of 2.7-dependent packages.

It might be worthwhile to treat the removal of Python-2.7 from the tree in
the same manner as an EAPI deprecation and removal, given how ingrained it
is due to its longevity.  That will minimize the whiplash-effect of emerge
complaining about slot conflicts and dependency conflicts.  Like I just ran
into w/ setuptools-45.0.0.0's release.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] separate /usr without initramfs

2019-10-27 Thread Joshua Kinard
On 10/27/2019 12:12, Matt Turner wrote:
> On Sun, Oct 27, 2019 at 3:06 AM James Le Cuirot  wrote:
>>
>> On Sun, 27 Oct 2019 05:38:48 -0400
>> Joshua Kinard  wrote:
>>
>>> Why do I not like an initramfs, though?  Well, for one, it complicates the
>>> kernel compiles (and it makes them bigger, something which is an issue on
>>> the old SGI systems at times).  Two, it's another layer that I have to
>>> maintain.  Three, it violates, in my mind, the simplicity of keeping the
>>> kernel and userland separated (e.g., kernel does kernel-y things, userland
>>> does userland-y things).
>>
>> You make it sound like the initramfs has to be built into the kernel
>> image. It can be but it usually isn't. I suspect you know that though?
>> Admittedly that does depend on support from your bootloader. While GRUB
>> and U-Boot have supported this for years, I forget what oddball
>> bootloaders your hardware may be using.
> 
> Though he's likely not using it, GRUB2 supports all the platforms he
> mentioned (x86, amd64, sparc64, [sgi] mips).

Nope, never took to GRUB.  Never bought into the selling point of "you don't
have to edit a config file for every kernel update".  Also don't have a
working sparc64 box anymore, as the Blade 100 died quite a long time ago.  I
still have a SunFire v240, but it's got a PROM release that can't netboot,
and the updated version that can was released 3 days after Oracle bought Sun
and locked SunSolve up (thanks, Oracle).  Plus the thing is as loud as a jet
engine.

As far as GRUB working on SGI systems, that's news to me.  ARCS is pretty
unique on each SGI system, so it's not like one can write a tiny bit of code
to cover them all.  I'll have to investigate GRUB's documentation to see if
can deal w/ machines running ARCS, and whether it can handle IP27, IP30, and
even IP35.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] separate /usr without initramfs

2019-10-27 Thread Joshua Kinard
On 10/27/2019 06:06, James Le Cuirot wrote:
> On Sun, 27 Oct 2019 05:38:48 -0400
> Joshua Kinard  wrote:
> 
>> Why do I not like an initramfs, though?  Well, for one, it complicates the
>> kernel compiles (and it makes them bigger, something which is an issue on
>> the old SGI systems at times).  Two, it's another layer that I have to
>> maintain.  Three, it violates, in my mind, the simplicity of keeping the
>> kernel and userland separated (e.g., kernel does kernel-y things, userland
>> does userland-y things).
> 
> You make it sound like the initramfs has to be built into the kernel
> image. It can be but it usually isn't. I suspect you know that though?
> Admittedly that does depend on support from your bootloader. While GRUB
> and U-Boot have supported this for years, I forget what oddball
> bootloaders your hardware may be using.

As mentioned (and later pointed out in the thread), I use LILO.  Considering
upstream is dead now, how much longer that will persist is an open question.
 I am a creature very wedded to habit, and LILO, for whatever its ills and
warts are, has always just worked for me, so I have stuck with it.  Having
to edit a config file before each kernel update is the trivialest of tasks,
especially since I tend to only update the kernel once every few months.

The SGI systems all boot using netboot because I compile their kernels on my
dev box and then host them over TFTP.  It's just a lot easier that way,
especially since ARCS (the SGI version of a BIOS) has had network booting
built in since pretty much 1990 (and earlier, I think).  It's really the SGI
Indy (IP22) that refuses to netboot if the kernel's size is >11MB.  All of
those kernels are monolithic, since the hardware in such systems is pretty
much fixed for all time.  Granted, my Indy gave up the ghost some time ago
(probably the infamous RTC battery issue), so I am really just left with an
O2 (which refuses to netboot anything >41MB), Octane, and two IP27-class
systems, which don't have size limits (that I've found yet) for what they'll
boot.

For actual disk booting on those systems, well, there's really just the
super-old ArcLoad project.  Written by the mastermind behind Octane's Linux
port, he aimed to make it very GRUB-like, so it has some of GRUB's
filesystem code in it for direct booting, or it can boot kernels stored in a
special area of the disk called the volume header (on disks w/ SGI's
partition layout).  Except that imported GRUB code is beyond ancient (11+
years old?), so it probably won't load a kernel off of ext4 or even XFSv5
partitions now.  Thus you really just have the volume header approach, and
that has its own limits.

That all said, it doesn't really matter if the initramfs is built into the
kernel or loaded somewhere into memory by the bootloader.  It's still a
wholly-separate userland layer that needs its own libc and whatever small
amount of tools to help mount required partitions and/or flash CPU microcode
before the kernel tries invoking /sbin/init.  That's just a terrible design.
 I mean, you can put lipstick on a pig, but it's still a bloody pig.


>> Maybe I'm just a old codger who refuses to accept change.  I'm fine with
>> that description.  I like things to remain somewhat simple, and my view of
>> Linux, both kernel and userland, over the last few years is one of growing
>> dismay due to the constant introduction of subsystem layer atop subsystem
>> layer for very little gain.  How much longer until we need a kernel to boot
>> the kernel to mount the userland that mounts the userland (yo dawg)?
> 
> Isn't that what the BIOS and bootloader do? On the plus side, you can
> now boot straight from UEFI to kernel without a bootloader but on the
> other hand, UEFI is horrifically over-complex.

Yeah, UEFI is one of those Eldritch horrors spoken of in the Necronomicon.
It's really just there so gamerz bois can have their uber-fancy gaming
system fully specced out.  Ironically, SGI's ARCS was capable of doing most
of what UEFI does 20 years ago, including pretty GFX and even playing music
when the system boots up (e.g., Indy's infamous "ass trumpet").

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] separate /usr without initramfs

2019-10-27 Thread Joshua Kinard
 obstinance.

---

That all said, I've fallen madly in love with ZFS.  I've got two network
appliances and an old laptop running FreeBSD 12.0-RELEASE with ZFS, and the
things I can do with ZFS eliminate the need to have multiple physical
partitions on the disks in those systems (outside of FreeBSD's needed boot
and swap partitions).  I get separate datasets mounted at /usr, /var, /tmp,
and quite a few others, and each can have its own mount properties set that
also achieve the security aims I cherish.  I can even replicate VM-like
snapshot capabilities where I can break part of the install with some dumb
idea (like testing 12.1-RC2 out last weekend), then switch boot environments
back to the working one and the system comes back up as if nothing happened.

So lately, I've been messing around w/ ZFS On Linux using a crappy old ~2012
2.5" 5400rpm drive in my dev box, attached to the LSI 9750.  And with ZFS,
that little drive *screams*.  It's virtually faster than the RAID5 array on
the other three 9750 ports running XFS.  If that drive was a heavy metal
singer, it'd take over Bruce Dickinson's day job.

As such, I am contemplating switching to ZFS Root soon on that machine, once
I work out some minor details (like can I still use LILO, because GRUB is
meh).  If that happens, well, that's one machine that won't ever have to
worry about the /usr-on-a-sep-partition mess again (even though the juvenile
logic behind the no-separate-/usr movement is completely wrong, but I
digress in a troll-like fashion).

Of course, this leaves my poor SGI systems in a questionable state.  ZFS is
completely reliant on checksums, and ARC needs gobs upon gobs of RAM.  So
that right there means ZFS might not be viable on those old systems (at
least w/ SHA checksumming -- fletcher4 might be fine).  And that's assuming
ZFS even compiles for a mips64 target and runs without turning a disk into a
large pool of entropic bit slop.

Well, we'll just cross that bridge when we get there...

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] New distfile mirror layout

2019-10-22 Thread Joshua Kinard
On 10/21/2019 19:36, Matt Turner wrote:
> On Mon, Oct 21, 2019 at 9:42 AM Richard Yao  wrote:
>> Also, another idea is to use a cheap hash function (e.g. fletcher) and just 
>> have the mirrors do the hashing behind the scenes. Then we would have the 
>> best of both worlds.
> 
> It probably would have been better to make these suggestions when the
> GLEP was discussed close to two years ago.
> 
> I'm glad that we have ideas for improvements but I worry that we're
> just backseat driving at this point given that the GLEP's now
> implemented.

Agreed, although, I don't even remember this coming up two years ago.  But,
I was tied up with a lot of work-related stress and tasks, so probably just
my memory storage backend not having enough cycles to commit it to...neurons.

IMHO, perhaps future GLEPs should have a defined window to implement them
following discussion.  Having the discussion, then waiting a few years
before implementing them leads to discussions like this where we're arguing
about the color of the boat after the boat has sailed off into the distance.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] New distfile mirror layout

2019-10-22 Thread Joshua Kinard
On 10/21/2019 06:13, Kent Fredric wrote:
> On Sun, 20 Oct 2019 16:57:54 -0400
> Joshua Kinard  wrote:
> 
>> I know we've got a ton of Perl packages for the core set of Perl modules,
>> but doesn't the CPAN eclass also have the capability to auto-generate an
>> ebuild package for virtually any Perl package distributed via CPAN?  Can
>> that logic be used with the CTAN system in its own eclass and then we remove
>> the 16k+ texlive modules off of our mirrors completely?  Or at the worst, we
>> might just have to generate ebuilds for texlive modules and treat them as
>> discrete, installed packages.
> 
> - Perl packages never have more than 1:1 source archives per ebuild
> - Perl upstream naming doesn't habitually use "perl-" as an archive prefix
> - Everything that is packaged for Perl in Gentoo is mirrored to the
>   Gentoo distfiles mirror, and this causes no issues.
> 
> So I don't think any comparison here makes sense.

I have to disagree on the "doesn't make sense" bit.  Regardless of what it
is that TexLive is packaging, the problem that I feel exists is storing
these macro packages on our mirrors is what is responsible for 20% of *all*
distfiles that we store.  That's lopsided that a small collection of
ebuilds, due to the way their build logic is architected, has that many
distfiles on the mirrors.

It's scenarios like that which led to Michał developing the GLEP the way he
did.  His approach is more broad, seeking to future-proof the mirroring
issue regardless of package mirroring decisions, whereas I'm more curious
why texlive needs all of those packages on our mirrors when it appears to
have a fairly comprehensive mirroring system of its own.  Why reinvent the
wheel?

Since CTAN exists as a worldwide mirroring system, I think at a minimum, we
should try to fetch from that directly instead of mirroring them on our own
systems and partner mirrors.  Or we could go the other way and become an
official CTAN mirror ourselves.  After all, if we're going to reinvent the
wheel, do all four instead of just one.

And for Perl or Python, I think we should be making an effort to leverage
their respective mirroring systems first before putting their distfiles onto
our mirrors.  Perl's got CPAN, and Python has pypi.  For things that don't
exist on those systems, then we use our mirrors.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] New distfile mirror layout

2019-10-20 Thread Joshua Kinard
On 10/20/2019 16:57, Joshua Kinard wrote:> On 10/20/2019 05:44, Michal Górny 
wrote:
>> On Sun, 2019-10-20 at 05:21 -0400, Joshua Kinard wrote:
>>> On 10/20/2019 04:32, Michal Górny wrote:
[snip]
>> You believe it to be a problem.  Don't expect others to bother upstream
>> with your preferences.
> 
> Hah.  So you consider texlive having 16k+ distfiles to be completely within
> operating norms then?
> 
> I did a quick look, and it looks like the TeX project has a fairly
> comprehensive mirroring system distributed around the world.  In fact, it
> looks like they emulate Perl's CPAN system with "CTAN":
> 
> https://ctan.org/
> 
> I don't know the history of the texlive and other associated tex packages in
> Gentoo, but my guess is instead of doing what our Perl packages do, someone
> just decided to mirror the CTAN archive directly on the Gentoo distfiles
> system.  It seems to me that what should actually happen is that we leverage
> CTAN itself, much like CPAN, and use their mirroring system instead of
> burdening our infrastructure as an unofficial CTAN archive.
> 
> I know we've got a ton of Perl packages for the core set of Perl modules,
> but doesn't the CPAN eclass also have the capability to auto-generate an
> ebuild package for virtually any Perl package distributed via CPAN?  Can
> that logic be used with the CTAN system in its own eclass and then we remove
> the 16k+ texlive modules off of our mirrors completely?  Or at the worst, we
> might just have to generate ebuilds for texlive modules and treat them as
> discrete, installed packages.

So looking at texlive-latexextra-2019-r2.ebuild, it defines three variables:

  - TEXLIVE_MODULE_CONTENTS, with 1,241 space-delimited module names
  - TEXLIVE_MODULE_DOC_CONTENTS, with 1,227 space-delimited doc names
  - TEXLIVE_MODULE_SRC_CONTENTS, with 745 space-delimited src names

Then, in texlive-module.eclass, there's these loops:

for i in ${TEXLIVE_MODULE_CONTENTS}; do
SRC_URI="${SRC_URI} mirror://gentoo/texlive-module-${i}-${PV}.${PKGEXT}"
done

# Forge doc SRC_URI
[ -n "${TEXLIVE_MODULE_DOC_CONTENTS}" ] && SRC_URI="${SRC_URI} doc? ("
for i in ${TEXLIVE_MODULE_DOC_CONTENTS}; do
SRC_URI="${SRC_URI} mirror://gentoo/texlive-module-${i}-${PV}.${PKGEXT}"
done
[ -n "${TEXLIVE_MODULE_DOC_CONTENTS}" ] && SRC_URI="${SRC_URI} )"

# Forge source SRC_URI
if [ -n "${TEXLIVE_MODULE_SRC_CONTENTS}" ] ; then
SRC_URI="${SRC_URI} source? ("
for i in ${TEXLIVE_MODULE_SRC_CONTENTS}; do
SRC_URI="${SRC_URI} 
mirror://gentoo/texlive-module-${i}-${PV}.${PKGEXT}"
done
SRC_URI="${SRC_URI} )"
fi

I think this is definitely an issue with how this package is laying out its
needed distfiles.  It really should be leveraging CTAN system at a minimum
to fetch all of the needed distfiles so we can get them off of our
distfiles mirror.  Then it would be interesting to re-run the math on
the distfiles distribution using the different schemes highlighted in the
GLEP-75 paper.

Longer-term, I think this entire approach should be revisited by the TeX
team to make it behave more like Perl or Python packages by having discrete
ebuilds for these modules.  That's not exactly a small undertaking, but
this current approach feels very kludgy in its design and is probably
asking for trouble.  I looked at several of the modules on CTAN, and they
each have their own version and even have different licenses.

E.g.,

  - altfont is licensed under "GNU General Public License" (version ??)
  - achemso is licensed under "The LaTeX Project Public License 1.3c"
  - arraysort is licensed under "The LaTeX Project Public License 1.2"
  - amsfonts is licensed under "The SIL Open Font License"
  - a0poster is licensed under "The LaTeX Project Public License" (ver ??)
  - arydshln is licensed under "The LaTeX Project Public License 1"
  - aurl is licensed under "Public Domain Software"

That's just a random selection from the 'a' category.  Do we have copies
of those licenses in the tree?  Do they allow redistribution of the
distfiles?  For the users that want "free" software, do any of the licenses
in any of the TeX modules put up any disagreeable restrictions?

Etc...

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] New distfile mirror layout

2019-10-20 Thread Joshua Kinard
On 10/20/2019 05:44, Michał Górny wrote:
> On Sun, 2019-10-20 at 05:21 -0400, Joshua Kinard wrote:
>> On 10/20/2019 04:32, Michał Górny wrote:
>>> On Sun, 2019-10-20 at 04:25 -0400, Joshua Kinard wrote:
>>>> Why is having a max ~24k files in a directory a bad idea?  Modern
>>>> filesystems are more than capable of handling that.
>>>>
>>>>   - ext4: unlimited files in a directory
>>>>   - xfs: virtually unlimited (hard limit of 2^64-1 total files per volume)
>>>>   - ntfs: 4,294,967,295
>>>>
>>>> And 24k is a bit more than 1/3rd of all distfiles that we currently have.
>>>
>>> For the same reason having ~60k files in a directory was a problem. 
>>> There is really no point in changing anything if you change BIG_NUMBER
>>> to SMALLER_BIG_NUMBER.
>>
>> That doesn't answer my question.  Why is it a problem?  What criteria are
>> you using to decide that 24k is a "smaller big number"?  Is there some issue
>> highlighted by the mirror admins where having 24k files in a single
>> directory offers no significant relief versus the current 60k files?
> 
> IIRC Robin set the goal as:
> 
> | the number of files in a single directory should not exceed 1000, [1]
> 
> I don't recall how that number was chosen but it's probably pretty
> arbitrary.  In any case, I can notice the difference between working
> with a listing of 1k files and 24k files, on the hardware running
> masterdist.

I think it would be prudent then to get some data to help underpin why that
number was chosen and add that to the GLEP, possibly as one of the
references at the bottom.  Your personal observations of a system
(masterdist) that few of us have access to is not good enough, especially
for future developers who may revisit this topic long after you or I are gone.


> 
>>>> Under which scenario do you wind up with 24k files in a single directory?  
>>>> I
>>>> consider the tex package an outlier in this case (one package should not be
>>>> the sole dictator of policy).
>>>
>>> Three versions of TeXLive living simultaneously.  If one package falls
>>> completely out of bounds, no problem is solved by the change, so what's
>>> the point of making it?
>>
>> The problem in this case is with texlive, not our current, or future,
>> distfiles methodology.
> 
> Is it?  Are you suggesting we should ban upstream from using multiple
> distfiles with similar prefix?  What about other potential packages that
> may suffer from the same problem in the future?  Go packages have a good
> potential, given that majority of them starts with 'github.com'.

Please highlight which of my words imply in any way that I want to ban
something.  I simply said texlive's significant number of distfiles is a
problem.  That doesn't mean that I want to resolve the problem by banning
it, or future packages that employ that method.

My concern is that out of the tens of thousands of packages we have, we're
allowing ONE package to dictate how we shape a major piece of Gentoo
infrastructure, and I don't feel that the proposed solution seeks to address
it.  Rather, it seeks to band-aid it by wrapping the entire distro up like a
mummy.


>> Has anyone looked at how other distros deal with texlive?
> 
> Other distros don't mirror original distfiles.

Has thought be given to doing the same?  This is arguably a better approach
than mirroring original distfiles in devspace.  This would significantly
reduce the infrastructure burden on the project.


>>   Has anyone complained or filed a bug to texlive developers
>> upstream about their excessive amount of distfiles and the burden it places
>> on distro maintainers?
> 
> You believe it to be a problem.  Don't expect others to bother upstream
> with your preferences.

Hah.  So you consider texlive having 16k+ distfiles to be completely within
operating norms then?

I did a quick look, and it looks like the TeX project has a fairly
comprehensive mirroring system distributed around the world.  In fact, it
looks like they emulate Perl's CPAN system with "CTAN":

https://ctan.org/

I don't know the history of the texlive and other associated tex packages in
Gentoo, but my guess is instead of doing what our Perl packages do, someone
just decided to mirror the CTAN archive directly on the Gentoo distfiles
system.  It seems to me that what should actually happen is that we leverage
CTAN itself, much like CPAN, and use their mirroring system instead of
burdening our infrastructure as an unofficial CTAN archive.

I know we've got a ton of Perl packages for the core set of Perl modules,
but doesn't the CPAN eclass also have the capability to auto-generate an

Re: [gentoo-dev] New distfile mirror layout

2019-10-20 Thread Joshua Kinard
On 10/20/2019 04:32, Michał Górny wrote:
> On Sun, 2019-10-20 at 04:25 -0400, Joshua Kinard wrote:
>> On 10/20/2019 02:51, Michał Górny wrote:
>>> On Sat, 2019-10-19 at 19:24 -0400, Joshua Kinard wrote:
>>>> On 10/18/2019 09:41, Michał Górny wrote:
>>>>> Hi, everybody.
>>>>>
>>>>> It is my pleasure to announce that yesterday (EU) evening we've switched
>>>>> to a new distfile mirror layout.  Users will be switching to the new
>>>>> layout either as they upgrade Portage to 2.3.77 or -- if they upgraded
>>>>> already -- as their caches expire (24hrs).
>>>>>
>>>>> The new layout is mostly a bow towards mirror admins, for some of whom
>>>>> having a 6+ files in a single directory have been a problem. 
>>>>> However, I suppose some of you also found e.g. the directory index
>>>>> hardly usable due to its size.
>>>>>
>>>>> Throughout a transitional period (whose exact length hasn't been decided
>>>>> yet), both layouts will be available.  Afterwards, the old layout will
>>>>> be removed from mirrors.  This has a few implications:
>>>>>
>>>>> 1. Users who don't upgrade their package managers in time will lose
>>>>> the ability of fetching from Gentoo mirrors.  This shouldn't be that
>>>>> much of a problem given that the core software needed to upgrade Portage
>>>>> should all have reliable upstream SRC_URIs.
>>>>>
>>>>> 2. mirror://gentoo/file URIs will stop working.  While technically you
>>>>> could use mirror://gentoo/XX/file, I'd rather recommend finally
>>>>> discarding its usage and moving distfiles to devspace.
>>>>>
>>>>> 3. Directly fetching files from distfiles.gentoo.org will become
>>>>> a little harder.  To fetch a distfile named 'foo-1.tar.gz', you'd have
>>>>> to use something like:
>>>>>
>>>>> $ printf '%s' foo-1.tar.gz | b2sum | cut -c1-2
>>>>> 1b
>>>>> $ wget http://distfiles.gentoo.org/distfiles/1b/foo-1.tar.gz
>>>>> ...
>>>>>
>>>>>
>>>>> Alternatively, you can:
>>>>>
>>>>> $ wget http://distfiles.gentoo.org/distfiles/INDEX
>>>>>
>>>>> and grep for the right path there.  This INDEX is also a more
>>>>> lightweight alternative to HTML indexes generated by the servers.
>>>>>
>>>>>
>>>>> If you're interested in more background details and some plots, see [1].
>>>>>
>>>>> [1] 
>>>>> https://dev.gentoo.org/~mgorny/articles/improving-distfile-mirror-structure.html
>>>>>
>>>>
>>>> So the answer I didn't really see directly stated here is, where do new
>>>> distfiles need to go //now//?  E.g., if on woodpecker, I currently cp a
>>>> distfile to /space/distfiles-local.  What is the new directory I need to
>>>> use?  And if mirror://gentoo/${FOO} is going away, for the new distfiles
>>>> target, what would be the applicable prefix to use?
>>>>
>>>> Directly using devspace seems like a bad idea, IMHO.  Once long ago, we all
>>>> got chastised for doing exactly that.  Too much possibility of 
>>>> fragmentation
>>>> as devs retire or package maintainership changes hands.
>>>
>>> Today you get chastised for using /space/distfiles-local and not
>>> following policy changes.  The devmanual states that it's deprecated
>>> since at least 2011, and talks of using d.g.o [1].
>>
>> I don't recall this change being added as far back as 2011.  Maybe my memory
>> is bad, but if it was done that long ago, it was done quietly, and it was
>> not enforced.  I checked my local mailing list archives for gentoo-dev and
>> don't see any mention of distfiles-local being deprecated back then.  Why
>> has it taken 8 years for this to get addressed?
> 
> Don't ask me.  I think I was already taught to use d.g.o back when I was
> recruited.
> 
>> In any event, I still think using devspace is a bad idea.  A centralized
>> distfiles repo is what most other distros use, and it's what we should use.
> 
> Talking doesn't make things happen.  Coming up with good proposals that
> address all the problems (e.g. those listed in devmanual) does.

Proposing changes when a direction has already been decided, the rudder
position changed, and engines put to fu

Re: [gentoo-dev] New distfile mirror layout

2019-10-20 Thread Joshua Kinard
On 10/20/2019 02:51, Michał Górny wrote:
> On Sat, 2019-10-19 at 19:24 -0400, Joshua Kinard wrote:
>> On 10/18/2019 09:41, Michał Górny wrote:
>>> Hi, everybody.
>>>
>>> It is my pleasure to announce that yesterday (EU) evening we've switched
>>> to a new distfile mirror layout.  Users will be switching to the new
>>> layout either as they upgrade Portage to 2.3.77 or -- if they upgraded
>>> already -- as their caches expire (24hrs).
>>>
>>> The new layout is mostly a bow towards mirror admins, for some of whom
>>> having a 6+ files in a single directory have been a problem. 
>>> However, I suppose some of you also found e.g. the directory index
>>> hardly usable due to its size.
>>>
>>> Throughout a transitional period (whose exact length hasn't been decided
>>> yet), both layouts will be available.  Afterwards, the old layout will
>>> be removed from mirrors.  This has a few implications:
>>>
>>> 1. Users who don't upgrade their package managers in time will lose
>>> the ability of fetching from Gentoo mirrors.  This shouldn't be that
>>> much of a problem given that the core software needed to upgrade Portage
>>> should all have reliable upstream SRC_URIs.
>>>
>>> 2. mirror://gentoo/file URIs will stop working.  While technically you
>>> could use mirror://gentoo/XX/file, I'd rather recommend finally
>>> discarding its usage and moving distfiles to devspace.
>>>
>>> 3. Directly fetching files from distfiles.gentoo.org will become
>>> a little harder.  To fetch a distfile named 'foo-1.tar.gz', you'd have
>>> to use something like:
>>>
>>> $ printf '%s' foo-1.tar.gz | b2sum | cut -c1-2
>>> 1b
>>> $ wget http://distfiles.gentoo.org/distfiles/1b/foo-1.tar.gz
>>> ...
>>>
>>>
>>> Alternatively, you can:
>>>
>>> $ wget http://distfiles.gentoo.org/distfiles/INDEX
>>>
>>> and grep for the right path there.  This INDEX is also a more
>>> lightweight alternative to HTML indexes generated by the servers.
>>>
>>>
>>> If you're interested in more background details and some plots, see [1].
>>>
>>> [1] 
>>> https://dev.gentoo.org/~mgorny/articles/improving-distfile-mirror-structure.html
>>>
>>
>> So the answer I didn't really see directly stated here is, where do new
>> distfiles need to go //now//?  E.g., if on woodpecker, I currently cp a
>> distfile to /space/distfiles-local.  What is the new directory I need to
>> use?  And if mirror://gentoo/${FOO} is going away, for the new distfiles
>> target, what would be the applicable prefix to use?
>>
>> Directly using devspace seems like a bad idea, IMHO.  Once long ago, we all
>> got chastised for doing exactly that.  Too much possibility of fragmentation
>> as devs retire or package maintainership changes hands.
> 
> Today you get chastised for using /space/distfiles-local and not
> following policy changes.  The devmanual states that it's deprecated
> since at least 2011, and talks of using d.g.o [1].

I don't recall this change being added as far back as 2011.  Maybe my memory
is bad, but if it was done that long ago, it was done quietly, and it was
not enforced.  I checked my local mailing list archives for gentoo-dev and
don't see any mention of distfiles-local being deprecated back then.  Why
has it taken 8 years for this to get addressed?

In any event, I still think using devspace is a bad idea.  A centralized
distfiles repo is what most other distros use, and it's what we should use.


>> I looked at the whitepaper'ish-like writeup, and I kinda don't like using a
>> hash-based naming scheme on the new distfiles layout.  I really kind prefer
>> breaking the directories up based on the first letter of the distfiles in
>> question, factoring case-sensitivity in (so you'd have 52 top-level
>> directories for A-Z and a-z, plus 10 more for 0-9).  Under each of those
>> directories, additional subdirectories for the next few letters (say,
>> letters 2-3).  Yes, this leads to some orphan cases where a distfile might
>> live on its own, but from a direct navigation standpoint, it's easy to find
>> for someone browsing the distfiles server and easy to predict where a
>> distfile is at.
>>
>> No math, statistical analysis, or deep-rooted knowledge of filesystems
>> behind that paragraph.  Just a plain old unfiltered opinion.  Sometimes, I
>> need to go get a distfile off the Gentoo mirrors, and being able to quickly
>> find it in the mirror root is great.  Having to do 

Re: [gentoo-dev] New distfile mirror layout

2019-10-19 Thread Joshua Kinard
On 10/19/2019 19:57, Alec Warner wrote:
> On Sat, Oct 19, 2019 at 4:24 PM Joshua Kinard  wrote:
> 
>> On 10/18/2019 09:41, Michał Górny wrote:
>>> Hi, everybody.
>>>
>>> It is my pleasure to announce that yesterday (EU) evening we've switched
>>> to a new distfile mirror layout.  Users will be switching to the new
>>> layout either as they upgrade Portage to 2.3.77 or -- if they upgraded
>>> already -- as their caches expire (24hrs).
>>>
>>> The new layout is mostly a bow towards mirror admins, for some of whom
>>> having a 6+ files in a single directory have been a problem.
>>> However, I suppose some of you also found e.g. the directory index
>>> hardly usable due to its size.
>>>
>>> Throughout a transitional period (whose exact length hasn't been decided
>>> yet), both layouts will be available.  Afterwards, the old layout will
>>> be removed from mirrors.  This has a few implications:
>>>
>>> 1. Users who don't upgrade their package managers in time will lose
>>> the ability of fetching from Gentoo mirrors.  This shouldn't be that
>>> much of a problem given that the core software needed to upgrade Portage
>>> should all have reliable upstream SRC_URIs.
>>>
>>> 2. mirror://gentoo/file URIs will stop working.  While technically you
>>> could use mirror://gentoo/XX/file, I'd rather recommend finally
>>> discarding its usage and moving distfiles to devspace.
>>>
>>> 3. Directly fetching files from distfiles.gentoo.org will become
>>> a little harder.  To fetch a distfile named 'foo-1.tar.gz', you'd have
>>> to use something like:
>>>
>>> $ printf '%s' foo-1.tar.gz | b2sum | cut -c1-2
>>> 1b
>>> $ wget http://distfiles.gentoo.org/distfiles/1b/foo-1.tar.gz
>>> ...
>>>
>>>
>>> Alternatively, you can:
>>>
>>> $ wget http://distfiles.gentoo.org/distfiles/INDEX
>>>
>>> and grep for the right path there.  This INDEX is also a more
>>> lightweight alternative to HTML indexes generated by the servers.
>>>
>>>
>>> If you're interested in more background details and some plots, see [1].
>>>
>>> [1]
>> https://dev.gentoo.org/~mgorny/articles/improving-distfile-mirror-structure.html
>>>
>>
>> So the answer I didn't really see directly stated here is, where do new
>> distfiles need to go //now//?  E.g., if on woodpecker, I currently cp a
>> distfile to /space/distfiles-local.  What is the new directory I need to
>> use?  And if mirror://gentoo/${FOO} is going away, for the new distfiles
>> target, what would be the applicable prefix to use?
>>
> 
> 
> 
> 
>>
>> Directly using devspace seems like a bad idea, IMHO.  Once long ago, we all
>> got chastised for doing exactly that.  Too much possibility of
>> fragmentation
>> as devs retire or package maintainership changes hands.
>>
>> I looked at the whitepaper'ish-like writeup, and I kinda don't like using a
>> hash-based naming scheme on the new distfiles layout.  I really kind prefer
>> breaking the directories up based on the first letter of the distfiles in
>> question, factoring case-sensitivity in (so you'd have 52 top-level
>> directories for A-Z and a-z, plus 10 more for 0-9).  Under each of those
>> directories, additional subdirectories for the next few letters (say,
>> letters 2-3).  Yes, this leads to some orphan cases where a distfile might
>> live on its own, but from a direct navigation standpoint, it's easy to find
>> for someone browsing the distfiles server and easy to predict where a
>> distfile is at.
>>
>> No math, statistical analysis, or deep-rooted knowledge of filesystems
>> behind that paragraph.  Just a plain old unfiltered opinion.  Sometimes, I
>> need to go get a distfile off the Gentoo mirrors, and being able to quickly
>> find it in the mirror root is great.  Having to do hash calculations to
>> work
>> out the file path will be *really* annoying.
>>
> 
> So if you want a tool that "downloads a distfile off of the mirrors" we
> should be able to build such a utility.
> 
> I'm not really sure why that tool needs to be:
> *copy DISTFILENAME*
> wget distilfes.gentoo.org/$PASTE
> 
> It could just `ebuild portageq download $DISTFILENAME or similar.`
> 
> -A

Sometimes, I'm not on a Gentoo system, or even a Linux/Unix platform, when I
go to fetch a distfile.  Could (and have) fetched as such off of Debian's
mirrors before, but Gentoo is what I know and fetching a distfile off of
those mirrors manually was generally very straight forward.

Not a common case, and certainly not a blocker.  I was just pointing out
that hashed-based naming is decidedly a lot less human-friendly.  But,
that's been the general trend for all-things technology these last few years.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] [PATCH] use.desc: add global USE flag 'split-sbin'

2019-10-19 Thread Joshua Kinard
On 10/16/2019 14:19, William Hubbs wrote:
> On Wed, Oct 16, 2019 at 07:17:09PM +0200, Ulrich Mueller wrote:
>>>>>>> On Wed, 16 Oct 2019, William Hubbs wrote:
>>
>>> Back in the day, the s in /sbin and /usr/sbin meant static, not super
>>> user. All binaries in those directories were statically linked.
>>

[snip]

> 
> Please read the links I posted before --specifically the comments
> from Rob.
> 
> Also, there is this.
> 
> https://news.ycombinator.com/item?id=3519952
> 
> Tl;dr the bin sbin separation is a historical separation that doesn't
> make sense any longer.

This is just your opinion.  Why does it not make sense?  Please back that
up.  Especially the "historical separation" bit.  Why is is historical?
Whom is the authority on that?  Is this strictly a Gentoo thing?  Is RedHat
doing this?  Is someone else?  Etc...

FWIW, my opinion is I //like// the separation of /sbin and /bin.  In fact,
I'm that old codger who //still// likes keeping /usr/bin and /usr/sbin
separate (yes, on separate partitions).  Maybe it's because I'm really poor
at organizing (and staying organized), so dumping everything into one spot
-- which is something I do at home WAY too much -- just strikes me as a bad
idea.  Binning stuff into different buckets offers SOME degree of
organization.  It also means 'ls -l /bin' is still somewhat readable on a
system with a full desktop installed.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] New distfile mirror layout

2019-10-19 Thread Joshua Kinard
On 10/18/2019 09:41, Michał Górny wrote:
> Hi, everybody.
> 
> It is my pleasure to announce that yesterday (EU) evening we've switched
> to a new distfile mirror layout.  Users will be switching to the new
> layout either as they upgrade Portage to 2.3.77 or -- if they upgraded
> already -- as their caches expire (24hrs).
> 
> The new layout is mostly a bow towards mirror admins, for some of whom
> having a 6+ files in a single directory have been a problem. 
> However, I suppose some of you also found e.g. the directory index
> hardly usable due to its size.
> 
> Throughout a transitional period (whose exact length hasn't been decided
> yet), both layouts will be available.  Afterwards, the old layout will
> be removed from mirrors.  This has a few implications:
> 
> 1. Users who don't upgrade their package managers in time will lose
> the ability of fetching from Gentoo mirrors.  This shouldn't be that
> much of a problem given that the core software needed to upgrade Portage
> should all have reliable upstream SRC_URIs.
> 
> 2. mirror://gentoo/file URIs will stop working.  While technically you
> could use mirror://gentoo/XX/file, I'd rather recommend finally
> discarding its usage and moving distfiles to devspace.
> 
> 3. Directly fetching files from distfiles.gentoo.org will become
> a little harder.  To fetch a distfile named 'foo-1.tar.gz', you'd have
> to use something like:
> 
> $ printf '%s' foo-1.tar.gz | b2sum | cut -c1-2
> 1b
> $ wget http://distfiles.gentoo.org/distfiles/1b/foo-1.tar.gz
> ...
> 
> 
> Alternatively, you can:
> 
> $ wget http://distfiles.gentoo.org/distfiles/INDEX
> 
> and grep for the right path there.  This INDEX is also a more
> lightweight alternative to HTML indexes generated by the servers.
> 
> 
> If you're interested in more background details and some plots, see [1].
> 
> [1] 
> https://dev.gentoo.org/~mgorny/articles/improving-distfile-mirror-structure.html
> 

So the answer I didn't really see directly stated here is, where do new
distfiles need to go //now//?  E.g., if on woodpecker, I currently cp a
distfile to /space/distfiles-local.  What is the new directory I need to
use?  And if mirror://gentoo/${FOO} is going away, for the new distfiles
target, what would be the applicable prefix to use?

Directly using devspace seems like a bad idea, IMHO.  Once long ago, we all
got chastised for doing exactly that.  Too much possibility of fragmentation
as devs retire or package maintainership changes hands.

I looked at the whitepaper'ish-like writeup, and I kinda don't like using a
hash-based naming scheme on the new distfiles layout.  I really kind prefer
breaking the directories up based on the first letter of the distfiles in
question, factoring case-sensitivity in (so you'd have 52 top-level
directories for A-Z and a-z, plus 10 more for 0-9).  Under each of those
directories, additional subdirectories for the next few letters (say,
letters 2-3).  Yes, this leads to some orphan cases where a distfile might
live on its own, but from a direct navigation standpoint, it's easy to find
for someone browsing the distfiles server and easy to predict where a
distfile is at.

No math, statistical analysis, or deep-rooted knowledge of filesystems
behind that paragraph.  Just a plain old unfiltered opinion.  Sometimes, I
need to go get a distfile off the Gentoo mirrors, and being able to quickly
find it in the mirror root is great.  Having to do hash calculations to work
out the file path will be *really* annoying.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] [PATCH] use.desc: add global USE flag 'split-sbin'

2019-10-15 Thread Joshua Kinard
On 10/15/2019 13:34, David Seifert wrote:
> On Tue, 2019-10-15 at 12:04 -0400, Mike Gilbert wrote:
>> On Tue, Oct 15, 2019 at 12:02 PM Mike Gilbert 
>> wrote:
>>> On Tue, Oct 15, 2019 at 8:00 AM David Seifert 
>>> wrote:
>>>> On Sun, 2019-10-13 at 12:33 -0400, Mike Gilbert wrote:
>>>>> On Sat, Oct 12, 2019 at 1:52 PM David Seifert 
>>>>> wrote:
>>>>>> On Sat, 2019-10-12 at 19:01 +0200, Dennis Schridde wrote:
>>>>>>> On Samstag, 12. Oktober 2019 18:02:28 CEST William Hubbs
>>>>>>> wrote:
>>>>>>>> On Sat, Oct 12, 2019 at 01:11:49PM +0200, Michał Górny
>>>>>>>> wrote:
>>>>>>>>> On Sat, 2019-10-12 at 13:00 +0200, David Seifert wrote:
>>>>>>>>>> * Some distros have not just merged / and /usr, they
>>>>>>>>>>
>>>>>>>>>>   have also merged /usr/bin and /usr/sbin. By giving
>>>>>>>>>>   users the choice of merging */bin and */sbin,
>>>>>>>>>>   Gentoo follows suit.
>>>>>>>>>
>>>>>>>>> What about the scenario when /bin has been merged with
>>>>>>>>> /usr/sbin
>>>>>>>>> and /sbin with /usr/bin?  ;-P
>>>>>>>>
>>>>>>>> I also don't see the need for something like this. The
>>>>>>>> idea of
>>>>>>>> the
>>>>>>>> /usr
>>>>>>>> merge is to have all binaries available in one place, and
>>>>>>>> there
>>>>>>>> really
>>>>>>>> is not a good justification for separating bin from sbin.
>>>>>>>
>>>>>>> Do I read this correctly?  USE=-split-usr currently means
>>>>>>> that
>>>>>>> /bin,
>>>>>>> /sbin, /
>>>>>>> usr/bin and /usr/sbin point to the same directory?
>>>>>>>
>>>>>>> If that is not the case, then I agree that users should
>>>>>>> have the
>>>>>>> possibility
>>>>>>> to set it up like this and USE=-split-sbin should be
>>>>>>> supported.
>>>>>>>
>>>>>>> --Dennis
>>>>>>
>>>>>> I agree, I wasn't aware that USE=-split-usr implies the
>>>>>> complete 2-
>>>>>> level (/usr and *sbin) merge. In that case, all of this is
>>>>>> obsolete.
>>>>>
>>>>> That was NOT my intention when I introduced the split-usr USE
>>>>> flag.
>>>>>
>>>>> For bin/sbin, I would prefer to drop any conflicting links
>>>>> unconditionally. Do you have examples of scenarios where this
>>>>> is not
>>>>> possible?
>>>>>
>>>>
>>>> William has confirmed on IRC that USE=-split-usr performs the
>>>> complete
>>>> Fedora-esque /usr merge (which makes sense IMO).
>>>
>>> William's opinion is not the only one that matters.
>>
>> Sorry, I guess you are referring to the behavior baselayout? That
>> doesn't necessarily align with the global usage.
>>
> 
> https://gitweb.gentoo.org/proj/baselayout.git/tree/Makefile#n93
> 
> Clearly the usr-merge in baselayout intends to merge all these 4
> directories. There is currently no option to merge /usr and / but keep
> /bin and /sbin separate, so the most parsimonious solution here is to
> assume that usr-merge semantics in Gentoo is about merging all 4
> directories.

What is the source or origin point of the desire to merge /sbin into /bin?
I know Fedora/RedHat championed the /usr/[s]bin into /[s]bin bit, but this
is the first I've heard of trying to put all executables in one spot.  I
have my doubts about such an idea, but want to see what the rationale is
this time before writing the idea off to the funny farm.

My understanding for the separation was system binaries that only the
superuser needs to touch go into /sbin and everything else into /bin.  This
allowed for unpriv user PATHs to exclude /sbin (and in times antiquity, also
exclude /usr/sbin).

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



[gentoo-dev] Re: toolchain.eclass musl changes

2019-05-21 Thread Joshua Kinard
On 5/20/2019 17:41, Jory A. Pratt wrote:
> Please review the proposed changes for musl support. We would like to
> get this landed on the tree ASAP so we can drop the eclass from the musl
> overlay. This is one of the first steps to getting things moved to tree
> so we can depreciate the overlay.
> 
> Thanks,
> Jory

Slightly off-topic, but I am actually trying to manually build a musl
MIPS-III o32 seed stage (big-endian) using OpenADK as a base.  Haven't
gotten to gcc yet (the OpenADK base has 8.3.0), but any documentation or
other useful bits of info stored someplace that I oughta know about?

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] Keeping net-fs/ncpfs and net-misc/ipx-utils around?

2019-03-26 Thread Joshua Kinard
On 3/26/2019 10:22, Michał Górny wrote:
> On Mon, 2019-03-25 at 15:19 -0400, Joshua Kinard wrote:
>> Throwing a question out there on whether to keep both the net-fs/ncpfs and
>> net-misc/ipx-utils packages around any longer.  Kernel upstream removed both
>> the IPX (Internetwork Packet eXchange) protocol and NCPFS (NetWare Core
>> Protocol Filesystem) support back in ~4.18 due to lack of maintenance.  I
>> know the code in both generally worked fine back then, as I have a few
>> NetWare VMs that I was able to mount filesystems from in Linux, even on my
>> MIPS hardware.
>>
>> However, it is effectively a dead protocol and dead filesystem for a dead
>> operating system (NetWare).  I don't see anyone resurrecting IPX/NCPFS and
>> updating to get it re-included it in the kernel, either.  I was tempted once
>> to try, but I just don't have the time anymore.
>>
>> I think we're one of the last distros to even keep IPX/NCPFS-related
>> packages around long-term.  With no viable upstream for ncpfs anymore, and
>> with no kernel support in Linux (or even FreeBSD; they deprecated IPX in
>> ~10.0-RELEASE), I think it's time to remove this package and any related
>> packages.
>>
>> One catch is, sys-kernel/gentoo-sources still keeps 4.4, 4.9, and 4.14
>> stable kernel series around.  These can still technically use IPX/NCPFS, and
>> therefore, there might be users using it.
>>
>> A quick poll of the portage tree suggests these changes are needed:
>>
>> Delete USE flag reference:
>> net-analyzer/hydra
>> profiles/use.local.desc (remove hydra's local 'ncp' entry)
>>
>> Remove ebuilds:
>> net-fs/ncpfs
>> net-misc/ipx-utils
>>
>> Remove filesystem reference?:
>> sys-apps/mlocate/files/updatedb.conf
>>
>> Remove reference to 'ipx-utils':
>> profiles/license_groups
>>
>>
>> Thoughts?
>>
> 
> Last rite them with 60 day period.  If someone actually uses them,
> you'll learn about it and get some data to decide how to proceed
> afterwards.  Plus, users who actually might still use them would get
> a fair warning they're going to be dropped in the future.
> 

Thanks, good advice.  I've created a bug for myself (#681820) and opted for
75 days, as 60 days is too close to a major US holiday period where I might
be preoccupied.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



[gentoo-dev] Keeping net-fs/ncpfs and net-misc/ipx-utils around?

2019-03-25 Thread Joshua Kinard
Throwing a question out there on whether to keep both the net-fs/ncpfs and
net-misc/ipx-utils packages around any longer.  Kernel upstream removed both
the IPX (Internetwork Packet eXchange) protocol and NCPFS (NetWare Core
Protocol Filesystem) support back in ~4.18 due to lack of maintenance.  I
know the code in both generally worked fine back then, as I have a few
NetWare VMs that I was able to mount filesystems from in Linux, even on my
MIPS hardware.

However, it is effectively a dead protocol and dead filesystem for a dead
operating system (NetWare).  I don't see anyone resurrecting IPX/NCPFS and
updating to get it re-included it in the kernel, either.  I was tempted once
to try, but I just don't have the time anymore.

I think we're one of the last distros to even keep IPX/NCPFS-related
packages around long-term.  With no viable upstream for ncpfs anymore, and
with no kernel support in Linux (or even FreeBSD; they deprecated IPX in
~10.0-RELEASE), I think it's time to remove this package and any related
packages.

One catch is, sys-kernel/gentoo-sources still keeps 4.4, 4.9, and 4.14
stable kernel series around.  These can still technically use IPX/NCPFS, and
therefore, there might be users using it.

A quick poll of the portage tree suggests these changes are needed:

Delete USE flag reference:
net-analyzer/hydra
profiles/use.local.desc (remove hydra's local 'ncp' entry)

Remove ebuilds:
net-fs/ncpfs
net-misc/ipx-utils

Remove filesystem reference?:
sys-apps/mlocate/files/updatedb.conf

Remove reference to 'ipx-utils':
profiles/license_groups


Thoughts?

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] Last rites: some old X11 packages

2019-03-03 Thread Joshua Kinard
On 3/3/2019 14:15, Matt Turner wrote:
> On Sun, Mar 3, 2019 at 1:09 AM Joshua Kinard  wrote:
>>
>> On 3/2/2019 13:46, Matt Turner wrote:
>>> # Matt Turner  (02 Mar 2019)
>>> # Old, unused drivers.
>>> # Masked for removal in 30 days. Bug #679256
>>
>>> x11-drivers/xf86-video-newport
>>
>> This is for the SGI Indy's newport graphics board.  Does it not build with
>> modern Xorg or anything, or not maintained upstream?  My Indy is dead due to
>> a bad RTC, so I can't test it for the foreseeable future.
> 
> Yes, it no longer builds and it requires packed 24-bit color support
> which has been removed from the xserver.

Fair enough.  Could that bit be documented in the package.mask entry for the
record, should anyone want to tackle trying to resurrect it, they'll know
why it was masked and removed?


> We would have to package an old xserver for -newport to be useful
> (which is something I'd be interested to do with sufficient time).

Long down on my TODO list is to figure out how to replace the RTC and
resurrect the Indy.  Wesolows gave it to me years ago, and it was pretty
chipper for a 150MHz box.  But the disk drive died and I never got around to
replacing it.  Maybe one day...


-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] util-linux build time increase?

2019-03-03 Thread Joshua Kinard
On 3/1/2019 10:01, Mart Raudsepp wrote:
> Ühel kenal päeval, N, 28.02.2019 kell 04:13, kirjutas Joshua Kinard:
>> On 2/25/2019 05:18, Alexander Tsoy wrote:
>>> В Пн, 25/02/2019 в 13:07 +0300, Alexander Tsoy пишет:
>>>> В Чт, 21/02/2019 в 04:36 -0500, Joshua Kinard пишет:
>>>>> Does anyone have an idea why util-linux's build time would go
>>>>> up
>>>>> significantly from 2.32.x to 2.33.x?  It may be a MIPS thing,
>>>>> as my
>>>>> x86_64
>>>>> box shows no discernible change in build times between the same
>>>>> versions.
>>>>> Can any other archs check w/ genlop to see if they see a large
>>>>> jump
>>>>> in build
>>>>> time?
>>>>>
>>>>> 'genlop -t util-linux' output on my SGI system (some entries
>>>>> removed
>>>>> for
>>>>> brevity):
>>>>>
>>>>>  Thu Feb  1 11:26:33 2018 >>> sys-apps/util-linux-2.31.1
>>>>>merge time: 27 minutes and 48 seconds.
>>>>>
>>>>>  Sat Mar 31 08:07:20 2018 >>> sys-apps/util-linux-2.32
>>>>>merge time: 28 minutes and 44 seconds.
>>>>>
>>>>>  Mon Aug 27 06:21:30 2018 >>> sys-apps/util-linux-2.32.1
>>>>>merge time: 32 minutes and 58 seconds.
>>>>>
>>>>>  Tue Nov 13 10:03:58 2018 >>> sys-apps/util-linux-2.33
>>>>>merge time: 1 hour, 19 minutes and 49 seconds.
>>>>>
>>>>>  Fri Jan 11 09:20:21 2019 >>> sys-apps/util-linux-2.33.1
>>>>>merge time: 1 hour, 23 minutes and 37 seconds.
>>>>>
>>>>>  Thu Feb 21 04:14:33 2019 >>> sys-apps/util-linux-2.33.1
>>>>>merge time: 1 hour, 25 minutes and 15 seconds.
>>>>>
>>>>
>>>> 2.33 was changed to use python-r1 eclass instead of python-
>>>> single-r1
>>>> eclass. And the increase of build time seems caused by an out-of-
>>>> source 
>>>> build for each python implementation. Some libraries are built
>>>> several
>>>> times (for native abi + for each python implementation).
>>>
>>> And there is additional configure run for each python
>>> implementation.
>>
>> Hmm, this might explain things, somewhat.  I think there's possibly
>> some
>> truth to the getcwd bit discussed earlier, but that may be limited to
>> glibc
>> only.
> 
> Right, util-linux doesn't conduct that test. coreutils and tar do,
> maybe some more.
> That doesn't mean running with sandbox doesn't have a slowdown effect -
> it most certainly does, just hopefully not so drastic as that
> particular case - it involves glibc own generic getcwd being slow with
> long paths, and sandbox calling it three times for its access checks
> even for mkdir call, just to error with ENAMETOOLONG, in addition to
> many getcwd calls the configure check itself does. So it's slow even
> without sandbox, but with sandbox that slowness is doubled or more.
> That has made me wonder if maybe by having some more ENAMETOOLONGs
> earlier, the test would finish earlier, instead of slowly spinning
> through paths that are in length between PATH_MAX and PATH_MAX*2, when
> it's slow..
> But not sure why these m4 macros seems to be calling getcwd after each
> mkdir+chdirm etc just to get a boolean configure check result. Didn't
> look into the specific case, I only debugged the test case that just
> loops mkdir+chdir.
> Someone should maybe convert these project to meson and do that check
> smarter :D
> 
>> util-linux-2.33.1 on my uclibc-ng chroot took about ~25mins.  Have to
>> re-time the glibc build to see if it's something w/ the libc
>> implementation.
>>
>> Temp workaround I guess is to cut down on the PYTHON_TARGETS before
>> my next
>> catalyst attempt.  2.7 + 3.7 should be enough...
> 
> Personally I seem to get by with just USE=-python on util-linux (it's
> actually not globally enabled on my systems, it seems). Otherwise,
> sure, if the slowness is in configure.
> 
> 
> Mart

Yeah, I forgot I had a global 'python' USE set on the Octane.  It's not been
fun trying to disentangle the mess after removing it.  But...

Before:
 Thu Feb 21 04:14:33 2019 >>> sys-apps/util-linux-2.33.1
   merge time: 1 hour, 25 minutes and 15 seconds.

After:
 Sun Mar  3 03:22:26 2019 >>> sys-apps/util-linux-2.33.1
   merge time: 18 minutes and 35 seconds.


The above is also with sandbox disabled for now until the getcwd issue is
fixed.  If I'd known that sandbox slowed stuff down that much, I'd have
stopped using it a long time ago.  This machine is top of its class, but
it's taking longer to build stuff as new versions come out due to new
features being added, compiler taking longer, etc.  I miss the days when
this thing could build gcc in 3-4 hours.  More like 14hrs now.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] Last rites: some old X11 packages

2019-03-03 Thread Joshua Kinard
On 3/2/2019 13:46, Matt Turner wrote:
> # Matt Turner  (02 Mar 2019)
> # Old, unused drivers.
> # Masked for removal in 30 days. Bug #679256

> x11-drivers/xf86-video-newport

This is for the SGI Indy's newport graphics board.  Does it not build with
modern Xorg or anything, or not maintained upstream?  My Indy is dead due to
a bad RTC, so I can't test it for the foreseeable future.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] util-linux build time increase?

2019-02-28 Thread Joshua Kinard
On 2/21/2019 16:18, Kristian Fiskerstrand wrote:
> On 2/21/19 1:29 PM, Guilherme Amadio wrote:
>> On Thu, Feb 21, 2019 at 04:36:24AM -0500, Joshua Kinard wrote:
>>> Does anyone have an idea why util-linux's build time would go up
>>> significantly from 2.32.x to 2.33.x?  It may be a MIPS thing, as my x86_64
>>> box shows no discernible change in build times between the same versions.
>>> Can any other archs check w/ genlop to see if they see a large jump in build
>>> time?
>>>
> 
> At least on a couple of my amd64 there isn't any noticeable slowdown.
> similar to your own observations. E.g this laptop (Linux ares
> 4.9.155-gentoo-kf0 #1 SMP Sun Feb 10 17:01:51 CET 2019 x86_64 Intel(R)
> Xeon(R) CPU E3-1535M v5 @ 2.90GHz GenuineIntel GNU/Linux) says
> 
> # /usr/local/bin/emerge_time.sh sys-apps/util-linux
> util-linux-2.28.2: Thu Feb  9 18:52:32 2017: 1 minute, 9 seconds
> util-linux-2.28.2: Thu Feb  9 19:56:31 2017: 1 minute, 37 seconds
> util-linux-2.28.2: Fri Apr 21 20:05:52 2017: 35 seconds
> util-linux-2.30.2: Thu Nov 23 18:59:23 2017: 55 seconds
> util-linux-2.30.2: Mon Dec  4 22:08:07 2017: 38 seconds
> util-linux-2.30.2: Wed Jan 10 20:44:39 2018: 44 seconds
> util-linux-2.30.2-r1: Mon Mar 12 19:20:06 2018: 46 seconds
> util-linux-2.32-r4: Sun Jul 15 15:51:21 2018: 50 seconds
> util-linux-2.33-r1: Sun Jan  6 20:53:29 2019: 46 seconds
> util-linux-2.33-r1: Thu Feb 21 22:16:25 2019: 53 seconds

Is /usr/local/bin/emerge_time.sh a custom script of yours, or is it
available somewhere else?  I usually use genlop to measure merge times, but
that package has a lengthy set of perl dependencies that I don't want to
pull into the catalyst seed chroots I am building/updating.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] util-linux build time increase?

2019-02-28 Thread Joshua Kinard
On 2/25/2019 05:18, Alexander Tsoy wrote:
> В Пн, 25/02/2019 в 13:07 +0300, Alexander Tsoy пишет:
>> В Чт, 21/02/2019 в 04:36 -0500, Joshua Kinard пишет:
>>> Does anyone have an idea why util-linux's build time would go up
>>> significantly from 2.32.x to 2.33.x?  It may be a MIPS thing, as my
>>> x86_64
>>> box shows no discernible change in build times between the same
>>> versions.
>>> Can any other archs check w/ genlop to see if they see a large jump
>>> in build
>>> time?
>>>
>>> 'genlop -t util-linux' output on my SGI system (some entries
>>> removed
>>> for
>>> brevity):
>>>
>>>  Thu Feb  1 11:26:33 2018 >>> sys-apps/util-linux-2.31.1
>>>merge time: 27 minutes and 48 seconds.
>>>
>>>  Sat Mar 31 08:07:20 2018 >>> sys-apps/util-linux-2.32
>>>merge time: 28 minutes and 44 seconds.
>>>
>>>  Mon Aug 27 06:21:30 2018 >>> sys-apps/util-linux-2.32.1
>>>merge time: 32 minutes and 58 seconds.
>>>
>>>  Tue Nov 13 10:03:58 2018 >>> sys-apps/util-linux-2.33
>>>merge time: 1 hour, 19 minutes and 49 seconds.
>>>
>>>  Fri Jan 11 09:20:21 2019 >>> sys-apps/util-linux-2.33.1
>>>merge time: 1 hour, 23 minutes and 37 seconds.
>>>
>>>  Thu Feb 21 04:14:33 2019 >>> sys-apps/util-linux-2.33.1
>>>merge time: 1 hour, 25 minutes and 15 seconds.
>>>
>>
>> 2.33 was changed to use python-r1 eclass instead of python-single-r1
>> eclass. And the increase of build time seems caused by an out-of-
>> source 
>> build for each python implementation. Some libraries are built
>> several
>> times (for native abi + for each python implementation).
> 
> And there is additional configure run for each python implementation.

Hmm, this might explain things, somewhat.  I think there's possibly some
truth to the getcwd bit discussed earlier, but that may be limited to glibc
only.  util-linux-2.33.1 on my uclibc-ng chroot took about ~25mins.  Have to
re-time the glibc build to see if it's something w/ the libc implementation.

Temp workaround I guess is to cut down on the PYTHON_TARGETS before my next
catalyst attempt.  2.7 + 3.7 should be enough...

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



[gentoo-dev] util-linux build time increase?

2019-02-21 Thread Joshua Kinard
Does anyone have an idea why util-linux's build time would go up
significantly from 2.32.x to 2.33.x?  It may be a MIPS thing, as my x86_64
box shows no discernible change in build times between the same versions.
Can any other archs check w/ genlop to see if they see a large jump in build
time?

'genlop -t util-linux' output on my SGI system (some entries removed for
brevity):

 Thu Feb  1 11:26:33 2018 >>> sys-apps/util-linux-2.31.1
   merge time: 27 minutes and 48 seconds.

 Sat Mar 31 08:07:20 2018 >>> sys-apps/util-linux-2.32
   merge time: 28 minutes and 44 seconds.

 Mon Aug 27 06:21:30 2018 >>> sys-apps/util-linux-2.32.1
   merge time: 32 minutes and 58 seconds.

 Tue Nov 13 10:03:58 2018 >>> sys-apps/util-linux-2.33
   merge time: 1 hour, 19 minutes and 49 seconds.

 Fri Jan 11 09:20:21 2019 >>> sys-apps/util-linux-2.33.1
   merge time: 1 hour, 23 minutes and 37 seconds.

 Thu Feb 21 04:14:33 2019 >>> sys-apps/util-linux-2.33.1
   merge time: 1 hour, 25 minutes and 15 seconds.


-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] Deprecation and removal of 13.0 profiles is imminent

2019-02-20 Thread Joshua Kinard
On 2/19/2019 17:52, Sergei Trofimovich wrote:

>>> Tl;DR: 13.0 profiles will be removed some time soon unless there are
>>> enough reports broken on 13.0->17.0 switch.
>>>
>>> 13.0 profiles been a while in Gentoo tree and are already deprecated
>>> on some arches but not everywhere.
>>>

[snip]

> 
> hardened/linux/mips/mipsel/multilib/n32
> hardened/linux/mips/mipsel/multilib/n64
> hardened/linux/mips/mipsel/n32
> hardened/linux/mips/mipsel/n64
> hardened/linux/mips/multilib/n32
> hardened/linux/mips/multilib/n64
> hardened/linux/mips/n32
> hardened/linux/mips/n64
> 

[snip]

> 
> +hardened@ (and +arm@, +mips@, +ppc@, +ppc64) ,
> is it fine to redirect these to vanilla 17.0 profiles?

Speaking for mips, I can't think of any issues for the hardened/13.0
profiles.  The default 13.0 profiles should be left alone a bit longer,
though.  Transition shouldn't be a problem with those, as I last did a
catalyst run from Sept 18 to Nov 18 that had no issues, but end of year
obligations sidetracked me, so I need to eventually start over again with a
more recent catalyst run to make 17.0 stages available.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] [PATCH v5 03/16] glep-0063: 'Gentoo subkey' → 'Signing subkey'

2018-07-25 Thread Joshua Kinard
On 7/25/2018 1:38 AM, Michał Górny wrote:
> W dniu śro, 25.07.2018 o godzinie 01∶28 -0400, użytkownik Joshua Kinard
> napisał:
>> On 7/8/2018 2:38 PM, Michał Górny wrote:
>>> Replace the 'Gentoo subkey' term that might wrongly suggest that
>>> the developers are expected to create an additional, dedicated subkey
>>> for Gentoo.
>>>
>>> Suggested-by: Kristian Fiskerstrand 
>>> ---
>>>  glep-0063.rst | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/glep-0063.rst b/glep-0063.rst
>>> index 0773e3b..f02537d 100644
>>> --- a/glep-0063.rst
>>> +++ b/glep-0063.rst
>>> @@ -116,7 +116,7 @@ Recommendations
>>>  
>>> a. Root key: 3 years maximum, expiry date renewed annually.
>>>  
>>> -   b. Gentoo subkey: 1 year maximum, expiry date renewed every 6 months.
>>> +   b. Signing subkey: 1 year maximum, expiry date renewed every 6 months.
>>>  
>>>  5. Create a revocation certificate & store it hardcopy offsite securely
>>> (it's about ~300 bytes).
>>>
>>
>> I lost track of this due to other priorities, but picking through some of the
>> follow-up messages about the lead time on renewals and all, I don't have a
>> problem with that.  But why is the maximum of one year on subkey/signing key
>> expiration still here?
> 
> Because I've started with small changes, and the thing you're asking
> about is changed in a followup patch.  Please read the final text
> instead of wrongly assuming something from irrelevant change.

Yep, you're right.  Sorry about that!  I am fine with the specified timeframe
in the current iteration.


>>
>> I'm not seeing a lot of additional follow-up on that, but that is still too
>> short.  Two years is perfectly fine in this case.  I'd prefer three years
>> myself, but am willing to compromise for two.  I am not doing one year unless
>> someone drops some really convincing logic on me.  And no, scrawling "logic" 
>> on
>> the side of an anvil doesn't count.
>>
>> Does anyone know what the other projects require for their keys?  Without a
>> proper explanation of //why// one year needs to be the maximum, looking to 
>> what
>> other projects use seems sensible for guidance.
>>
>> I can't seem to find any specific guidance from Debian, but FreeBSD appears 
>> to
>> be fine with three years on their committer keys:
>>
>> """
>> A three year key lifespan is short enough to obsolete keys weakened by
>> advancing computer power, but long enough to reduce key management problems.
>> """
>>
>> https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/article.html#pgpkeys
>>

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] [PATCH v5 03/16] glep-0063: 'Gentoo subkey' → 'Signing subkey'

2018-07-24 Thread Joshua Kinard
On 7/8/2018 2:38 PM, Michał Górny wrote:
> Replace the 'Gentoo subkey' term that might wrongly suggest that
> the developers are expected to create an additional, dedicated subkey
> for Gentoo.
> 
> Suggested-by: Kristian Fiskerstrand 
> ---
>  glep-0063.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/glep-0063.rst b/glep-0063.rst
> index 0773e3b..f02537d 100644
> --- a/glep-0063.rst
> +++ b/glep-0063.rst
> @@ -116,7 +116,7 @@ Recommendations
>  
> a. Root key: 3 years maximum, expiry date renewed annually.
>  
> -   b. Gentoo subkey: 1 year maximum, expiry date renewed every 6 months.
> +   b. Signing subkey: 1 year maximum, expiry date renewed every 6 months.
>  
>  5. Create a revocation certificate & store it hardcopy offsite securely
> (it's about ~300 bytes).
> 

I lost track of this due to other priorities, but picking through some of the
follow-up messages about the lead time on renewals and all, I don't have a
problem with that.  But why is the maximum of one year on subkey/signing key
expiration still here?

I'm not seeing a lot of additional follow-up on that, but that is still too
short.  Two years is perfectly fine in this case.  I'd prefer three years
myself, but am willing to compromise for two.  I am not doing one year unless
someone drops some really convincing logic on me.  And no, scrawling "logic" on
the side of an anvil doesn't count.

Does anyone know what the other projects require for their keys?  Without a
proper explanation of //why// one year needs to be the maximum, looking to what
other projects use seems sensible for guidance.

I can't seem to find any specific guidance from Debian, but FreeBSD appears to
be fine with three years on their committer keys:

"""
A three year key lifespan is short enough to obsolete keys weakened by
advancing computer power, but long enough to reduce key management problems.
"""

https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/article.html#pgpkeys

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] [PATCH v2 07/11] glep-0063: Allow ECC, curve 25519 keys

2018-07-04 Thread Joshua Kinard
On 7/4/2018 7:22 PM, Kristian Fiskerstrand wrote:
> On 07/05/2018 01:07 AM, Joshua Kinard wrote:
>>> @@ -64,6 +66,8 @@ not be used to commit.
>>>  
>>> b. RSA, >=2048 bits (OpenPGP v4 key format or later only)
>>>  
>>> +   c. ECC, curve 25519
>>> +
>>>  3. Key expiry: 5 years maximum
>>>  
>>>  4. Upload your key to the SKS keyserver rotation before usage!
>>>
>> Add a minimum key size here for ECC.  They have different bit sizes than
>> classic DSA/RSA keys.  A quick read indicates that a 224-bit ECC key is 
>> roughly
>> equivalent to a 112-bit symmetric key, which is what a 2048-bit RSA key is
>> equivalent to, so the logical minimum for ECC looks like 'nistp256'.  The
>> maximum is 521-bits on ECC (nistp521).
>>
>> Also move the mention of Ed25519 keys to their own bullet and clarify that 
>> they
>> don't allow for a key length, as I think that's hardcoded in some capacity.
> 
> following the comma-style of the rest of the document, the ECC part
> should likely be read as curve25519 being the only acceptable curve,
> which is 256 bits (roughtly 128 bit shannon entropy equivalent)
> 
> that said, I'm not aware of any curves defined with a lower security
> margin than this for OpenPGP in general. The known curves in the
> ecosystem are
> 
> let oid_to_psize oid =
>let psize = match oid with
>  | "\x2b\x81\x04\x00\x23" -> 521  (* nistp521 *)
>  | "\x2b\x81\x04\x00\x22" -> 384  (* nistp384 *)
>  | "\x2a\x86\x48\xce\x3d\x03\x01\x07" -> 256  (* nistp256 *)
>  | "\x2b\x24\x03\x03\x02\x08\x01\x01\x07" -> 256  (* brainpoolP256r1 *)
>  | "\x2b\x24\x03\x03\x02\x08\x01\x01\x0b" -> 384  (* brainpoolP384r1 *)
>  | "\x2b\x24\x03\x03\x02\x08\x01\x01\x0d" -> 512  (* brainpoolP512r1 *)
>  | "\x2b\x81\x04\x00\x0a" -> 256  (* secp256k1 *)
>  | "\x2b\x06\x01\x04\x01\xda\x47\x0f\x01" -> 256  (* Ed25519 *)
>  | _ -> failwith "Unknown OID"
> 

By "only acceptable curve", do you mean we shouldn't allow the nistp* key
types, only Ed25519?

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] [PATCH v2 07/11] glep-0063: Allow ECC, curve 25519 keys

2018-07-04 Thread Joshua Kinard
On 7/4/2018 6:23 AM, Michał Górny wrote:
> Optionally allow using ECC, curve 25519 keys.  We already have
> developers using those keys, and given that they are supported
> by GnuPG 2.2, there's probably no reason to ban them.  However, they're
> not recommended due to interoperability issues.
> ---
>  glep-0063.rst | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/glep-0063.rst b/glep-0063.rst
> index 6dc4ce5..ab7cb79 100644
> --- a/glep-0063.rst
> +++ b/glep-0063.rst
> @@ -33,6 +33,8 @@ v1.1
>The larger recommendation was unjustified and resulted in people
>unnecessarily replacing their RSA-2048 keys.
>  
> +  Minimal specification has been amended to allow for ECC keys.
> +
>  Motivation
>  ==
>  
> @@ -64,6 +66,8 @@ not be used to commit.
>  
> b. RSA, >=2048 bits (OpenPGP v4 key format or later only)
>  
> +   c. ECC, curve 25519
> +
>  3. Key expiry: 5 years maximum
>  
>  4. Upload your key to the SKS keyserver rotation before usage!
> 

Add a minimum key size here for ECC.  They have different bit sizes than
classic DSA/RSA keys.  A quick read indicates that a 224-bit ECC key is roughly
equivalent to a 112-bit symmetric key, which is what a 2048-bit RSA key is
equivalent to, so the logical minimum for ECC looks like 'nistp256'.  The
maximum is 521-bits on ECC (nistp521).

Also move the mention of Ed25519 keys to their own bullet and clarify that they
don't allow for a key length, as I think that's hardcoded in some capacity.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] [PATCH v2 09/11] glep-0063: Make recommended expiration terms mandatory

2018-07-04 Thread Joshua Kinard
On 7/4/2018 5:24 PM, Michał Górny wrote:
> W dniu śro, 04.07.2018 o godzinie 23∶05 +0200, użytkownik Ulrich Mueller
> napisał:
>>>>>>> On Wed, 4 Jul 2018, Michał Górny wrote:
>>> -3. Key expiry: 5 years maximum
>>> +3. Key expiration:
>>> +
>>> +   a. Primary key: 3 years maximum
>>> +
>>> +   b. Gentoo subkey: 1 year maximum
>>
>> What problem are you trying to solve here?
>>
> 
> The problem of having unjustified double standards.

IMHO, one year for a signing subkey is too short.  I see no problem with three
years like the primary key.  Especially since people will typically just change
the expiration and advance it the minimum number of years, lather, rinse, and
repeat.  It's a solution looking for a problem.

NAK on this.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] Monthly mips@ project status for April 2018

2018-04-02 Thread Joshua Kinard
On 4/2/2018 4:32 PM, Michał Górny wrote:
> W dniu pon, 02.04.2018 o godzinie 13∶27 -0400, użytkownik Joshua Kinard
> napisał:
>> On 4/2/2018 5:41 AM, Michał Górny wrote:
>>> W dniu nie, 01.04.2018 o godzinie 20∶40 -0700, użytkownik Matt Turner
>>> napisał:
>>>
>>>> My plan is to add stable 17.0 mips profiles when the keywording is
>>>> sorted out and kill two birds with one stone.
>>>
>>> Does it involve fixing the CHOST inconsistency so that we can finally
>>> get LLVM keyworded?
>>
>> Bug #515694, right?  Based on a very quick re-read, there are two
>> issues/blockers here:
>>
>> 1) Current Gentoo/MIPS support was originally based on gcc, thus, we've used
>> CHOST tuples that are recognized by gcc.
> 
> As far as I'm aware GCC doesn't really care about which triplet is used.
> It's all controlled by --with-abi= option (I may have mistyped its
> name).

gcc might not, but odds are incredibly likely other software will.  I want to
say memory reminds me that glibc may be a culprit here, and may explain the
reason why someone redesigned the triplets/tuples in the first place.  E.g., I
*think* (but can't corroborate) that the "mips64-unknown-linux-gnuabin32" tuple
derived from glibc wanting to determine n32 support from the CHOST.  Again,
though, there are no known equivalents of this for uclibc-ng or musl targets
that I know of.


>> 2) clang lacks a CHOST tuple that defaults to n32.  n32 is the "ideal" ABI 
>> for
>> a 64-bit platform that doesn't need full 64bit (n64) binary support.
>>
>> As far as I can tell, we need to fix #2 before we can do anything about #1.
>> Once clang has a discrete CHOST tuple for n32, that'll put it on parity with
>> gcc, which itself appears to have a batch of more specific tuples to select
>> different ABIs.  You might want to just push upstream any patches you have 
>> that
>> adds this support first.
> 
> It's chicken-egg problem. Before I can submit a patch upstream, I need
> someone with MIPS hardware and a proper profile (using disjoint,
> consistent triplets) to test it. Not to mention Gentoo needs to decide
> on the triplet in the first place.

Is there an option to cross-compile clang/llvm using a CHOST added by your
patch?  That should at least validate that the CHOST logic works out.  Any one
of us could then test out a statically-linked binary generated from such a
toolchain, assuming the target output matches one of our machines.

As far as Gentoo "deciding", I have to argue that it's not an "our fault" thing
or such.  Back when the port was started in ~2003, there was no such thing as
clang/llvm, so we used what CHOSTs gcc was happy with.  Life continued on from
there, with a few hiccups along the way.

I know of no authority that sets/decides what CHOSTs are valid and what aren't.
 That'd probably be a nice thing to have, TBH, as my irritation with FreeBSD's
versioned CHOSTs makes updating a Gentoo/FreeBSD userland mildly annoying.
That said, I don't have much of a problem adopting the Debian versions[1].  We
would just need a way to migrate existing installs, preferably w/o having to
recompile everything...

1. https://wiki.debian.org/Multiarch/Tuples

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] Monthly mips@ project status for April 2018

2018-04-02 Thread Joshua Kinard
On 4/2/2018 5:41 AM, Michał Górny wrote:
> W dniu nie, 01.04.2018 o godzinie 20∶40 -0700, użytkownik Matt Turner
> napisał:
>
>> My plan is to add stable 17.0 mips profiles when the keywording is
>> sorted out and kill two birds with one stone.
> 
> Does it involve fixing the CHOST inconsistency so that we can finally
> get LLVM keyworded?

Bug #515694, right?  Based on a very quick re-read, there are two
issues/blockers here:

1) Current Gentoo/MIPS support was originally based on gcc, thus, we've used
CHOST tuples that are recognized by gcc.

2) clang lacks a CHOST tuple that defaults to n32.  n32 is the "ideal" ABI for
a 64-bit platform that doesn't need full 64bit (n64) binary support.

As far as I can tell, we need to fix #2 before we can do anything about #1.
Once clang has a discrete CHOST tuple for n32, that'll put it on parity with
gcc, which itself appears to have a batch of more specific tuples to select
different ABIs.  You might want to just push upstream any patches you have that
adds this support first.

---

Having been around in the Very Beginning, I can tell you that one doesn't
change CHOSTs lightly on MIPS.  There are a LOT of upstream projects that don't
use newer autotools and thus won't recognize the more specific CHOSTs.  And
there are a few projects, like Perl, that use their own custom build system and
might need special fixes on top to use the more-specific tuples.

That said, none of this addresses the issue of the multiple C library options
available.  As far as I know, using different ABIs with uclibc-ng or musl
requires setting either a build or config option, or passing -mabi=xxx, along
with a gcc-like CHOST tuple.  E.g., for my uclibc-ng chroot on my Octane, I am
sticking w/ o32 and thus use a CHOST of mips-unknown-linux-uclibc.  If
clang/llvm can co-exist with C libraries other than glibc, this is likely an
additional complexity to consider.

Also, last I checked, clang/llvm didn't have full support for the "old" MIPS
ISAs, namely mips3 and only part of mips4.  It also has no knowledge of
scheduling for the old CPU families, like R10K.  I helped write the current
R10K scheduling code for gcc a few years ago, so maybe could do something for
clang/llvm, though I have no idea how they implement CPU scheduling logic.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



[gentoo-dev] Re: [gentoo-mips] Monthly mips@ project status for April 2018

2018-04-02 Thread Joshua Kinard
On 4/2/2018 3:37 AM, Joshua Kinard wrote:
> On 4/1/2018 11:40 PM, Matt Turner wrote:
>> I'd like to start giving ~monthly updates on the status of mips@ in
>> Gentoo.
>>
>> Recently I received a Loongson 3A system (quad-core 1.35GHz, 16GB RAM,
>> AMD graphics) which is significantly faster and more stable than any
>> other mips system I have.
> 
> Big or little endian?  If little,

Helps to finish my sentences.  Except I don't remember where I was going to go
with this bit.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



[gentoo-dev] Re: [gentoo-mips] Monthly mips@ project status for April 2018

2018-04-02 Thread Joshua Kinard
ible (all the tools are still in the tree), but
we really need netboot images first.  Any future boot CD will be command line
only.  The X11 world has moved so far ahead, that even if Octane's X11 Impact
driver got fixed, I doubt the experience would be anything but "fun".

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] Manifest2 hashes, take n+1-th: 3 hashes for the tie-breaker case

2017-11-12 Thread Joshua Kinard
On 11/12/2017 22:48, Gordon Pettey wrote:
> On Sun, Nov 12, 2017 at 8:22 PM, Joshua Kinard <ku...@gentoo.org> wrote:
> 
>> Minor clarification, old single core //and// uni-processor.  Some older
>> machines have multiple physical CPUs that are single-core.  Threading
>> should be
>> okay on these, as long as the thread count stays under NR_CPUS.
>>
>> I also have a really old single-CPU system, MIPS (obviously).  Not the
>> fastest
>> on the block compared to the other equipment I've got, but does anyone
>> know of
>> any simple timing scripts/programs available that can benchmark some of
>> these
>> proposed digest hashes?  If they turn out to be reasonably quick on my old
>> machine, I doubt then that speed will be too much of an issue.
>>
> 
> Even on your "old single-CPU MIPS" system, what percentage of time is
> spent verifying manifest hashes compared to actually building/installing?
> The whole "slow and/or multiple hashes will cause problems" argument
> seems specious.

It appears that you have misread my inquiry quite severely.  I am not terribly
interested in the whole argument of "multiple hashes" or "slow hashes".  It's
just my curiosity wanting to know if there's a reliable way to benchmark, on
the command line, several common/known digest hashing algorithms.  For my MIPS
systems, the type of CPU and system architecture is very different between each
machine.  Being able to compare between each of them might have uses down the 
road.

But also having a rough idea of how the actual hashes perform might also be of
use to the discussion.  Only to enlighten, not to push a particular side.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] Manifest2 hashes, take n+1-th: 3 hashes for the tie-breaker case

2017-11-12 Thread Joshua Kinard
On 10/24/2017 00:11, Michał Górny wrote:
> W dniu wto, 24.10.2017 o godzinie 06∶04 +0200, użytkownik Michał Górny
> napisał:

[snip]

>>> [BOBO06] is relevant research here, I cited it in the work that went into
>>> GLEP59, the last time we updated the hashes. The less-technical explanation 
>>> of it is:
>>> "If you can express the output of H1(x)H2(x) in LESS bits than the combined
>>> output size of H1,H2, then the attacks get a little bit easier"
>>>
>>> Some important pieces from it:
>>> [J04] "showed that the concatenation of two Merkle-Damgard functions is not
>>> much more secure than the individual functions.", but this holds ONLY if
>>> the hash functions chosen are of the same construction (MD).
>>> Choosing hashes with different constructions (Merkle-Damgard, HAIFA,
>>> Sponge) is important, and given a black box environment, 
>>>
>>> The original mail reached the same approximate decision, just to look
>>> for diverse hashes, but decided that 2 was enough.
>>>
>>> Q: What are the odds of a simultaneous successful attack against two 
>>> hashes? 
>>> A: IDK, but if the hash functions are truly independent, it must be provably
>>>lower than the odds of an attack against a single hash.
>>
>> We're talking about really huge (→∞) numbers here. It's not a 'random'
>> attack against one hash. It's an attack that allows to sneak a malicious
>> code with unchanged file size (since we store that too), and no apparent
>> side effects (what's the point of spending up that much resources
>> if the user is going to notice?).
>>
>>> Q: What's the big difference between a bug and a successful attack in a 
>>> hash?
>>> A: Bugs are more likely initially, and attacks come later.
>>
>> Sounds like an entirely abstract point in time ;-).
>>
>>> All of that said, is there really a significant long-term gain in
>>> multiple hashes? (setting aside the short-term advantage in a transition
>>> period for changing hashes)
>>
>> No, and that's my point. One hash is perfectly fine.
>>
>> Two hashes are useful for transition purposes. If we take two fast
>> hashes (e.g. proposed SHA512 + BLAKE2B which have similar speed),
>> we can use 2 threads to prevent the speed loss (except for old single-
>> core machines).

Minor clarification, old single core //and// uni-processor.  Some older
machines have multiple physical CPUs that are single-core.  Threading should be
okay on these, as long as the thread count stays under NR_CPUS.

I also have a really old single-CPU system, MIPS (obviously).  Not the fastest
on the block compared to the other equipment I've got, but does anyone know of
any simple timing scripts/programs available that can benchmark some of these
proposed digest hashes?  If they turn out to be reasonably quick on my old
machine, I doubt then that speed will be too much of an issue.

Also, for whatever hashes we ultimately go with, what are considerations for
the userland support for them on non-glibc systems?  E.g., are they provided by
third-party libraries or do they need implementations in
uclibc/uclibc-ng/musl/*?  And what about the Alt/BSD side of things?  I assume
FreeBSD implements this already, but worth verifying with all of the
combinations of arches/libc's/kernels and whatnot.  I mean, there still might
be a lonely m68k install out there...

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] keywording ~sys-libs/glibc-2.26

2017-11-12 Thread Joshua Kinard
On 11/11/2017 11:49, Andreas K. Huettel wrote:
> Hi all, 
> 
> in the next days I'll likely re-add keywords to glibc-2.26. So, if you 
> haven't 
> fixed your package for build failures yet, now would be the time. 
> 
> The tracker is https://bugs.gentoo.org/show_bug.cgi?id=glibc-2.26 with 
> appropriate subtrackers.
> 
> 1) Your package needs RPC (and already now fails to build with sys-libs/
> glibc[-rpc]). 
> 
> See https://wiki.gentoo.org/wiki/Project:Toolchain/RPC_implementation for a 
> detailed guide.
> 
> 2) Your package uses NIS/YP functionality, and builds against / links to 
> libnsl. 
> 
> Add a dependeny (DEPEND and RDEPEND):
>   net-libs/libnsl:0=
> 
> You can already safely do this now ( =net-libs/libnsl-0 is a dummy, stable on 
> all arches, installs no files, depends on  additional bonus will get the subslot rebuild automagically once libnsl is 
> updated. 
> 
> (The unbundled libnsl has increased soversion, libnsl.so.2. glibc will keep 
> installing libnsl.so.1 as compatibility library for binary packages, but 
> without headers etc.)
> 
> 3) Your package needs internal data structures and fails with undefined types.
> 
> Ping me. Most likely problem and fix are already known.
> 

I take it Python was fixed to handle this?  I have my main MIPS machine tied up
on catalyst for the next few days, so I can't verify right now.  Initial
catalyst runs ~2 weeks ago indicated glibc-2.26 caused Python to fail its build
because either the RPC or NIS module failed to build (I forget which).

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



[gentoo-dev] [PATCH] toolchain.eclass: Remove kludge that blocks gcc-6+ on sys-libs/uclibc-ng systems

2017-07-29 Thread Joshua Kinard
The following kludge is present in toolchain.eclass, in 
toolchain_pkg_pretend():

[[ -z ${UCLIBC_VER} ]] && [[ ${CTARGET} == *-uclibc* ]] && \
die "Sorry, this version does not support uClibc"

The below patch removes this.  I've been running a gcc-6-built,
sys-libs/uclibc-ng in chroot for some time now, have completed several
catalyst runs, and am at the tail end of a fresh install of a
sys-libs/uclibc-ng userland on actual MIPS hardware.

Signed-off-by: Joshua Kinard <ku...@gentoo.org>
---
 eclass/toolchain.eclass |3 ---
 1 file changed, 3 deletions(-)

--- a/eclass/toolchain.eclass.orig  2017-07-29 19:06:30.894211203 -0400
+++ b/eclass/toolchain.eclass   2017-07-29 19:06:40.514211133 -0400
@@ -375,9 +375,6 @@ toolchain_pkg_pretend() {
"in your make.conf if you want to use this version."
fi
 
-   [[ -z ${UCLIBC_VER} ]] && [[ ${CTARGET} == *-uclibc* ]] && \
-   die "Sorry, this version does not support uClibc"
-
if ! use_if_iuse cxx ; then
use_if_iuse go && ewarn 'Go requires a C++ compiler, disabled 
due to USE="-cxx"'
use_if_iuse objc++ && ewarn 'Obj-C++ requires a C++ compiler, 
disabled due to USE="-cxx"'




Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

2017-07-25 Thread Joshua Kinard
On 07/25/2017 04:05, Michał Górny wrote:
> Hi, everyone.
> 
> There have been multiple attempts at grasping this but none so far
> resulted in something official and indisputable. At the same time, we
> end having to point our users at semi-official guides which change
> in unpredictable ways.
> 
> Here's the current draft:
> https://wiki.gentoo.org/wiki/User:MGorny/GLEP:Git
> 
> The basic idea is that the GLEP provides basic guidelines for using git,
> and then we write a proper manual on top of it (right now, all the pages
> about it end up as a mix of requirements and a partial git manual).
> 
> What do you think about it? Is there anything else that needs being
> covered?
> 
> Copy of the markup for inline comments follows.

I haven't seen it mentioned yet, but will this GLEP update or replace this
existing Wiki article on using git w/ Gentoo?:

https://wiki.gentoo.org/wiki/Gentoo_git_workflow

Some of the step-by-step bits in the above Wiki page look like good candidates
to be integrated into the GLEP.  It also contains guidelines on writing commit
messages, such as limiting the first line to ~50 characters, an optional body
wrapped at 75 chars/line, and including the usual git tags for sign-off and
such.  Though, I like the explicitness of the GLEP's text on a few things more.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] can't gpg sign with repoman, but can with git

2017-07-19 Thread Joshua Kinard
On 07/19/2017 15:43, Andrew Savchenko wrote:
> On Wed, 19 Jul 2017 21:24:49 +0200 Paweł Hajdan, Jr. wrote:
>> Hey folks,
>>
>> This is mysterious, and likely some issue with my setup, although it
>> used to work.
>>
>> Trying tocommit with repoman commit (app-portage/repoman version 2.3.1)
>> results in the following:
>>
>> * 4 files being committed...
>> error: gpg failed to sign the data
>> fatal: failed to write commit object
>> !!! Exiting on git (shell) error code: 128
>>

[snip]
> 
[snip]

> Make sure that GPG_TTY is set in your shell.

^^^--- This is likely the issue.

Add:
export GPG_TTY=`tty`

To your ~/.bash_profile (or wherever you put your PORTAGE_GPG_KEY value), and
that should solve the issue.  I got bit by this once, and spent a while
convincing Google that I'm not a robot to get that answer.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] Profile-enforced big-endian USE flag

2017-06-29 Thread Joshua Kinard
On 06/28/2017 18:29, James Le Cuirot wrote:
> On Wed, 28 Jun 2017 17:52:26 -0400
> Mike Gilbert <flop...@gentoo.org> wrote:
> 
>> On Tue, Jun 27, 2017 at 6:44 PM, James Le Cuirot <ch...@gentoo.org> wrote:
>>> I am therefore proposing a new global big-endian flag. This could be
>>> masked by default and unmasked + forced in the relevant profiles under
>>> arch. I will apply this according to the mapping defined in tc-endian of
>>> toolchain-funcs.eclass.  
> 
> I've just been putting the patch together. I made it slightly simpler
> by masking *and* forcing it by default so that it only needs to be
> unmasked were necessary.
> 
>> A possible alternative would be to create a new USE_EXPAND variable
>> for this. That would allow for easier expansion in case we ever
>> support something other than big/little endian machines.
> 
> That way madness lies? Wikipedia talks about middle-endian as being the
> catch all for other random orderings that have appeared over the years
> but I don't think any of them were used on a system-wide basis. I can't
> imagine Linux ever supporting such a thing. Unless you're talking about
> dealing with soft vs hard float here too?

As far as I know, Linux only supports big-endian and little-endian systems,
along with supporting a fairly-wide variety of platforms and architectures,
beaten really only by NetBSD.  If NetBSD lacks anything for middle-endian, then
it's probably safe to ignore it.

That said, Wikipedia doesn't offer much on the nature of middle-endian (which
is called "PDP-endian"), except to state that "The ARM architecture can also
produce this format when writing a 32-bit word to an address 2 bytes from a
32-bit word alignment."
https://en.wikipedia.org/wiki/Endianness#Middle

And this resource:
http://unixpapa.com/incnote/byteorder.html

Recommends to ignore middle-endian, as it believes no processor was ever
implemented that stored integers in middle-endian format.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] The status of grsecurity upstream and hardened-sources downstream

2017-06-26 Thread Joshua Kinard
On 06/26/2017 09:15, Luis Ressel wrote:
> On Sun, 25 Jun 2017 23:47:48 -0400
> Joshua Kinard <ku...@gentoo.org> wrote:
> 
>> Safe for now to just switch to gentoo-sources while retaining hardened
>> toolchain?  Or would there be a few additional steps needed?  I only
>> use PaX for mprotect() and the ALSR capabilities, though I suspect
>> those might be in the standard sauce by now.  As such, I haven't had
>> to deal with userland issues and PaX too much over the years.
> 
> A full rebuild shouldn't be neccessary after a switch to gentoo-sources
> or vanilla-sources. At least, I can't think of any reason why it would,
> and I haven't encountered any problems after switching on my own hosts.
> 
> Just keep in mind that vanilla-sources doesn't support the PaX xattrs
> properly (AFAIR), so if you ever want to switch *back* from vanilla to
> hardened, some pax markings will be missing. This shouldn't be an issue
> for gentoo-sources, though.
> 
> Cheers,
> Luis Ressel
> 

The machine needs a full rebuild just to "freshen" it up.  Current install is
going on 6-7+ years, at least three different motherboard/CPU cycles, and the
SATA drives are pushing 8+ years old at this point in that machine.  The same
drives were previously in my desktop machine between ~2006-2008, so they've had
a *great* run for spinning rust.  I've got new'ish replacement drives and a new
drive bay recently arrived, so the grsecurity mess was the straw that broke the
proverbial camel's back.

Just a matter of getting the needed downtime to move data off,
rebuild/reinstall everything, move stuff back, and check for broken bits.
Until then, I wasn't sure if switching to gentoo-sources would have any
side-effects with the hardened userland to get to a newer kernel.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] The status of grsecurity upstream and hardened-sources downstream

2017-06-25 Thread Joshua Kinard
On 06/23/2017 12:28, Anthony G. Basile wrote:
> Hi everyone,
> 
> Since late April, grsecurity upstream has stop making their patches
> available publicly.  Without going into details, the reason for their
> decision revolves around disputes about how their patches were being
> (ab)used.
> 
> Since the grsecurity patch formed the main core of our hardened-sources
> kernel, their decision has serious repercussions for the Hardened Gentoo
> project.  I will no longer be able to support hardened-sources and will
> have to eventually mask and remove it from the tree.
> 
> Hardened Gentoo has two sides to it, kernel hardening (done via
> hardened-sources) and toolchain/executable hardening.  The two are
> interrelated but independent enough that toolchain hardening can
> continue on its own.  The hardened kernel, however, provided PaX
> protection for executables and this will be lost.  We did a lot of work
> to properly maintain PaX markings in our package management system and
> there was no part of Gentoo that wasn't touched by issues stemming from
> PaX support.
> 
> I waited two months before saying anything because the reasons were more
> of a political nature than some technical issue.  At this point, I think
> its time to let the community know about the state of affairs with
> hardened-sources.
> 
> I can no longer get into the #grsecurity/OFTC channel (nothing personal,
> they kicked everyone), and so I have not spoken to spengler or pipacs.
> I don't know if they will ever release grsecurity patches again.
> 
> My plan then is as follows.  I'll wait one more month and then send out
> a news item and later mask hardened-sources for removal.  I don't
> recommend we remove any of the machinery from Gentoo that deals with PaX
> markings.
> 
> I welcome feedback.
> 

So short-term, what's the next step one can do to hop off the hardened-sources
train before it runs out of track without a full rebuild?  I'm planning on a
full rebuild/re-install eventually for my dev box, but it has been stuck on
kernel 4.9.x since this shindig went down and I'd like to get ahead to 4.11 or
4.12 instead of using my SGI machines to discover new surprises.

Safe for now to just switch to gentoo-sources while retaining hardened
toolchain?  Or would there be a few additional steps needed?  I only use PaX
for mprotect() and the ALSR capabilities, though I suspect those might be in
the standard sauce by now.  As such, I haven't had to deal with userland issues
and PaX too much over the years.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-portage-dev] [PROPOSAL] Don't split user visible messages across multiple lines

2017-03-21 Thread Joshua Kinard
On 03/16/2017 04:08, Brian Dolbec wrote:
> On Thu, 16 Mar 2017 09:43:08 +0200
> Alexandru Elisei <alexandru.eli...@gmail.com> wrote:
> 
>> On Thu, Mar 16, 2017 at 12:32 AM, Brian Dolbec <dol...@gentoo.org>
>> wrote:
>>> That could be pretty hard to do for all messages.
>>> Especially messages with embedded data
>>>
>>>   eg:  "%s is missing %s required use flag..." % ('sys-apps/foo',
>>> 'bar')  
>>
>> For that case we could use:
>>
>> "%s is missing %s required use flag..." % \
>> % ('sys-apps/foo', 'bar')
> 
> Yes, but that is not what I meant.  When you are searching the code for
> a message.
> 
>   the message in your terminal would read 
> "sys-apps/foo is missing bar required use flag..."
> 
> It may not be obvious to people to break up the text to search into 2
> strings.  "is missing" and "required use flag..."  trying one, failing
> that try the other to find the code location.  Then there is the
> problem of translations moving/re-arranging the text to suit the
> language (minor I know, but still a factor to consider).
> 
> 
>>> I know I don't always enforce the line length for a few characters,
>>> also when clarity is more important than line length.  
>>
>> I totally agree with that.
>>
>>> We could also increase the max. line length to something like 120
>>> or 130.  
>>
>> I think more people should chime in on that. I use vertical splits for
>> the screen when coding, and 120 characters is too long for me, but if
>> the preferred width ends up changing to 120 or 130 I can work with it.
>>
> 
> You need to get some large 4K monitors... love them :D
> I treated myself to two 28 inch ones during boxing week sales.
> My aging eyes love them :)  They are so much better than my old 24 inch
> 1080p monitors.  Those were getting tired/starting to loos clarity along
> with my eyes working at them all week long.  I now work with larger
> fonts which are still physically smaller than my old monitors, but
> so much clearer.  My eyes don't get nearly so tired as they did
> with my other monitors.
> 
>  ;)
> 
> 
>  My work has a 130 col limit.  With an editor at that,
> plus a wide, open files pane on the left of the editor window, I still
> have another large terminal window open to it's right with some bare
> screen real-estate patches and borders... ;)  Not to mention nearly 100
> lines of code view-able in the editor.

Not breaking the error messages across lines is now a checkpatch.pl warning in
the kernel, for the specific reason of making it easy to grep for error
messages.  You're only required to drop to the next line if, after closing the
string, there are any printk() variables needed.

So, IMHO, if the kernel does it this way now, I don't see a problem with us
doing it this way.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

2017-03-21 Thread Joshua Kinard
On 03/21/2017 04:43, Kristian Fiskerstrand wrote:
> On 03/21/2017 09:28 AM, Joshua Kinard wrote:
>> In general, the concept of code-sharing common blocks of logic between 
>> multiple
>> ebuilds in a specific package directory that is not a top-level eclass is not
>> entirely without merit.  But the only way this idea can be realized in a
>> suitable manner and be used by far more consumers than today's eblits are, is
>> to either find and finish the old elibs GLEP or start one over from scratch,
>> submit whatever needs submitting via patches to at least PMS and Portage, 
>> work
>> through whatever processes are required for approval, and then deploy it in 
>> the
>> next EAPI.
>>
>> If anyone is game for working something up or discussing further, let me 
>> know.
> 
> I personally fail to see good reasons to have a separate approach for
> this instead of putting it in the eclass framework. However this might
> simply mean I'm missing something in the discussion.
> 
> Before restarting such a GLEP process; maybe a simple pros and cons list
> of comparison of the future eblit use and existing eclass structure
> could be helpful? (along with more description of the differences)

Well, maybe it's a sign of my age and tenure, but I always thought one should
be conservative in the definition of new eclasses.  I may be wrong, but back in
the old days, to define a new toplevel eclass, I believe one had to demonstrate
that a number of different packages all had common ebuild logic that could all
merged into a single eclass.  Kinda like what we do now with new global USE
flags.  So throwing package-specific eclasses into the toplevel eclass
directory seems to run against this.  Additionally, repoman does not validate
the logic in eclasses currently (a long-time issue), which can lead to code rot
of such package-specific common code.

That said, I'm not wedded to the current implementation of eblits as they
exist, and IMHO, I do agree in principle with QA that any such feature like
that needs to be defined in PMS and employed by the package manager in some
capacity.  It is certainly doable right now with an eclass (I even have an
example eblit.eclass that demos this), but it would be better to leverage
existing loading and sourcing logic within the package managers for such a
capability, which means changing them and updating PMS, which effectively means
a new EAPI.

How we go about implementing this idea, or whether we even bother to do so, is
what needs to be discussed.  I certainly have some ideas, but I've largely
isolated myself to the MIPS world the last few years and my ideas might not be
the best when applied elsewhere in the tree.  As such, starting a GLEP is
probably the best approach, elsewise, this idea will just die on the mailing
lists yet again.  I'm just not sure when I'll have some free time to educate
myself on GLEPs and throw a draft together.  I've lately been trying to chase a
really obscure kernel bug down on one of my SGI systems in addition to other
life responsibilities, so a GLEP is somewhat low priority right now.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

2017-03-21 Thread Joshua Kinard
On 03/20/2017 15:25, Ulrich Mueller wrote:
>>>>>> On Mon, 20 Mar 2017, Alexis Ballier wrote:
> 
>> What makes me wonder more are the proposed solutions: So far the
>> only proposals I've seen are either inlining *all* the code or
>> moving *all* the code into an eclass. Having a quick look at
>> autoconf, it seems to me an intermediate solution would work
>> perfectly fine for the above goals/rules: Put main.eblit into an
>> eclass. The loading code then would access $FILESDIR only in src_*
>> phases. This would likely work better for all parties and would
>> allow to focus on better specifying this gray area of PMS instead.
> 
> But is it desirable as a goal, that all packages in the tree use
> regular eclasses, but two packages (autoconf and glibc) use something
> else that is a "grey area"?
> 
> Also, can somebody please point me to the discussion that preceded the
> introduction of eblits. AFAICS they appeared sometime in 2007, but I
> cannot find anything in our mailing list archives.
> 
> Ulrich

I believe the other working name this idea of ebuild code-reuse went under was
"elibs".  There was a partial GLEP written, enough that it was granted a
number, but I forget that number off the top of my head.

That said, I think a key problem here is the use of the word "eblit" has become
poisoned for various reasons, and this makes the continued use of the term and
its current implementation untenable.

In general, the concept of code-sharing common blocks of logic between multiple
ebuilds in a specific package directory that is not a top-level eclass is not
entirely without merit.  But the only way this idea can be realized in a
suitable manner and be used by far more consumers than today's eblits are, is
to either find and finish the old elibs GLEP or start one over from scratch,
submit whatever needs submitting via patches to at least PMS and Portage, work
through whatever processes are required for approval, and then deploy it in the
next EAPI.

If anyone is game for working something up or discussing further, let me know.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



[gentoo-dev] Re: [PATCH] sys-libs/glibc: Convert from eblits to eclass, #586422

2017-03-16 Thread Joshua Kinard
On 03/16/2017 09:49, Michał Górny wrote:
> //
> note: i'm in process of testing [building binpkgs] of all glibc versions
> to confirm i didn't accidentally break anything. - fails in compile
> phase both before and after the change.
> 
> ---
[snip]

You need to make a catalyst run as well, especially a stage2 run which will
invoke /usr/portage/scripts/bootstrap.sh, to cover all corner cases.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build

2017-01-31 Thread Joshua Kinard
On 01/30/2017 15:04, William Hubbs wrote:
> All,
> 
> I have been looking at the meson build system [1] [2], and I like what I
> see.
> 
> I have opened an issue on OpenRC's github wrt migrating OpenRC to the
> meson build system [3].
> 
> As I said on the bug, the downside is the addition of py3 and ninja as
> build time dependencies, but I think the upside (a build system where
> we don't have to worry about parallel make issues or portability)
> outweighs that.
> 
> What do folks think here?
> 
> Thanks,
> 
> William
> 
> [1] https://mesonbuild.com
> [2] https://www.youtube.com/watch?v=ae9_rNuFaQM
> [3] https://github.com/OpenRC/openrc/issues/116

dev-util/ninja is hosed at the moment on a hardened/amd64 system built using
gcc-6.x.  See Bug #604198.  This one package is holding up my dev box from
updating clang/llvm and several other dependent packages.  I've given up trying
to debug it, too.  It's something gcc-6.x is doing, code-generation-wise, that
is beyond my ability to troubleshoot.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] Unused profiles

2017-01-22 Thread Joshua Kinard
On 01/22/2017 13:49, Anthony G. Basile wrote:
> On 1/19/17 8:25 PM, Anthony G. Basile wrote:
>> Michal,
> 
> I had a chance to look over this carefully and here's what I got:
> 
[snip]
>>> default/linux/mips/13.0/mipsel/multilib
[snip]
>>> default/linux/mips/13.0/multilib
[snip]
> 
> These can all go. Do you want to drop a deprecated notice in them?  Or
> shall I?

Keep the multilib profiles.  I actually just completed a fresh set of gcc-6.3
stages for the big-endian multilib profile set.  Got more stages being built
for other ISA/ABI combos right now, so it'll be awhile before I put stuff on
the mirrors.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] newsitem: important fstab update

2016-10-26 Thread Joshua Kinard
On 10/25/2016 13:15, William Hubbs wrote:
> On Tue, Oct 25, 2016 at 01:10:06PM -0400, Mike Gilbert wrote:
>> On Tue, Oct 25, 2016 at 1:01 PM, William Hubbs <willi...@gentoo.org> wrote:
>>> If you are not using /dev/disk/by-* paths in fstab, you do not need to
>> take any action for this news item.
>>>
>>> If you are, it is very critical that you update fstab AS SOON AS
>> POSSIBLE. Your system will become unbootable in the future if you do
>> not  do so.
>>
>> Err, what is changing that will make systems unbootable?
>>
>> I am fairly certain systems running systemd will continue to work
>> properly with either syntax.
>  
>  They probably will.
> 
>> If this is about the udev-settle issue for OpenRC, I would urge you to
>> reconsider that.
>  
>  There isn't anything to reconsider afaik. The problem is that
>  /dev/disk/by-* are only created by udev/eudev, but the other syntax
>  works regardless of which device manager  you use, so this is the safer
>  route.
> 
>  William
> 

I take it us museum relics still using jurassic-era device names like
/dev/sd* or /dev/md* aren't affected by this?  Cthulhu-forbid Linux device
naming gets any more complicated than using UUID's.  What's next, saving the
serial numbers of discovered disks in an overly-complicated key/value-based
non-SQL database format?

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] recommended way to get gcc-6 for testing packages

2016-09-07 Thread Joshua Kinard
On 09/06/2016 06:56, Paweł Hajdan, Jr. wrote:
> On 05/09/16 13:07, Joshua Kinard wrote:
>> On 08/31/2016 17:28, Paweł Hajdan, Jr. wrote:
>>> gcc-6 doesn't seem to be in portage.
>> It's in the hardened-development overlay.  You can use layman to install the
>> overlay, then test out gcc-6.2.x.  Already found a bug related to mips 
>> myself, heh.
> 
> Okay. I'll probably take a look.
> 
> Why not add it to portage, unkeyworded or something?
> 
> Paweł

Mike's generally been the guy handling the main toolchain updates, but I'm not
sure if he's just been tied up lately or something.  We're behind on glibc
(2.24 is out), binutils (2.27) and gcc (6.2.0).

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] [PATCH 0/4] New no-lib-symlink profile for developers

2016-09-05 Thread Joshua Kinard
On 07/09/2016 17:01, Michał Górny wrote:
> Hello, everyone.
> 
> I've finally gotten around to wrapping up my multilib setup
> in a profile, and providing necessary patches to system packages
> to make it possible to use it without having to hack their mistaken
> logic around.
> 
> The profile is called 'no-lib-symlink', and is provided as an alternate
> amd64 variant. Unlike the common profiles, it is based on three lib*
> directories: lib32 for 32-bit binaries, lib64 for 64-bit binaries
> and lib as a directory for software packages only (the new-style
> libexec).

[snip]

Responding late to this.  This change won't, in the future, affect mips
multilib, will it?  Remember, we've got three ABIs to juggle, and this proposed
change looks like it might clobber one of those ABIs.

o32 - old 32-bit, goes into /lib or /usr/lib.
n32 - hybrid 32-bit/64-bit (like x32), goes into /lib32 or /usr/lib32.
n64 - full 64-bit, goes into /lib64 or /usr/lib64

This basically follows the layout that old IRIX used to use when you had
binaries/libs from all three ABIs mixed into the same root.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] recommended way to get gcc-6 for testing packages

2016-09-05 Thread Joshua Kinard
On 08/31/2016 17:28, Paweł Hajdan, Jr. wrote:
> I was looking at <https://bugs.gentoo.org/show_bug.cgi?id=588596> .
> 
> gcc-6 doesn't seem to be in portage.
> 
> Is there recommended way to get it installed?
> 
> I'm also wondering what are the plans for adding it to portage. Why not
> just add it hard masked or unkeyworded?
> 
> Paweł

It's in the hardened-development overlay.  You can use layman to install the
overlay, then test out gcc-6.2.x.  Already found a bug related to mips myself, 
heh.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



[gentoo-dev] net-misc/iputils, why is the latest p'masked?

2016-09-05 Thread Joshua Kinard

So I am trying to make a stage3 run with catalyst for a MIPS-II/BE setup using
sys-libs/uclibc-ng.  Ran into a bit of a blocker with
net-misc/iputils-20151218, which is the latest version that isn't masked.
Specifically, the 'ping' utility will not build against uclibc-ng because of an
undefined reference to `__finite'.  This issue has been fixed in
iputils-20160308, by making 'ping' link with libm.  However, iputils-20160308
is p'masked with this vague reason:

# Lars Wendler <polynomia...@gentoo.org> (20 Aug 2015)
# Releases are not from original upstream but from a fork.
# Masked as requested by vapier.
~net-misc/iputils-20160308

So this raises a couple of options, and I'm not sure of what the best
resolution is:

- Unmask iputils-20160308?  What's specifically wrong with this forked variant?

- Finish removing 'ping' from @system, per Bug #563148 (blocked by #393445)?

The first option is arguably the cleanest, because the build issue will likely
be encountered again if one rebuilds @world.  But there seems to be a bit of a
conflict because 20160308 is from a forked upstream, and the "activeness" of
the original upstream appears to be in question.

Second option gets around the issue from a catalyst standpoint, but anyone
compiling iputils-20151218 in this specific stage against uclibc-ng will
probably encounter the build issue.

There is a patch for the issue, but it does not apply cleanly to
iputils-20151218.  However, it is simple enough to backport.  But I'd prefer
the easier option of unmasking 20160308.

Thoughts on how to proceed?

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] base-system needs developers who care

2016-08-29 Thread Joshua Kinard
On 08/24/2016 10:08, Pacho Ramos wrote:
> El mié, 24-08-2016 a las 16:05 +0200, Lars Wendler escribió:
>>
> [...]
>> Oh, and to all new team members:
>> Please keep in mind to *not* use EAPI-6 for base-system packages yet,
>> so
>> we can retain a somewhat stable upgrade path even for very old
>> systems.
>>
>>
>> Kind regards
>> Lars
> 
> This reminds me a question I have for some time: is it documented in
> some place what are the steps to follow for updating old systems? I
> remember posts like:
> http://blog.siphos.be/2013/12/upgrading-old-gentoo-installations/
> 
> but I don't know if that is "official" or a workaround or... :/
> 
> Thanks a lot for the info!

When I got SGI Octane booting Linux again in 2014, I had a dormant ~2009-era
system still installed on that machine.  Upgrading was...interesting.  Entirely
doable -- I think I hand-jammed a modern Portage into it to get started, then
incrementally step-upgraded the thing over a period of 2-3 weeks until the
system packages were fully working.

Then I got torched by gcc's PR61538, where someone's upstream change tripped up
an atomic fault on the R1 CPUs these things use, which left me stuck at
gcc-4.8.x.  That went on for 8 months until someone else upstream accidentally
fixed it.  Now, I've just got to figure out this irritating 2GB memory DMA 
bug...

But still, depending on the age of the install, it's a task that only the
dedicated and OCD should try to tackle.  Everyone else is better off salvaging
config files by mounting the disks in another system, then nuking the old
install from orbit.

I'll let you guys now how the next attempt works out, whenever I get my Indigo2
R1 to boot again.  I think the Gentoo install on that machine hasn't seen
the light of the Kernel since ~2006.  Probably earlier.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] is this newsitem worthy?

2016-08-21 Thread Joshua Kinard
On 08/21/2016 15:31, William Hubbs wrote:
> All,
> 
> take a look at the discussion on
> https://bugs.gentoo.org/show_bug.cgi?id=591414, in particular the last
> few comments.
> 
> My question is, is the emerge action newsitem worthy as Mark suggests?
> 
> Thanks,
> 
> William

I think it is.  I was scratching my head over some of these warnings, wondering
why no one has fixed some of them yet.  For the less-used packages, such as
sys-apps/timer_entropyd, without a revbump, I'd not have thought that simply
re-merging the package on all of my systems would update the init script and
make the warning go away.

IMHO, such a change *should* have been a revbump, and, if that was the only
change to that package, that revbump should have gone straight to stable since
it doesn't really represent a significant change (and issues regarding such a
change should have already been worked out).  OTOH, if there were other things
that could be fixed in a package, then pack this change into the rest and
follow the normal stabilization process.

As for the "--quiet --quiet" bit...that's a bit obtuse.  The message being
output is only using an "ewarn", so it's not a critical error and should have
been squelched with the first --quiet.  I'd either update the message to an
"eerror" to get attention or add a note about the double-quiets somewhere (or
add a new switch, --stfu, to do the job ).

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] [PATCH] kernel-2.eclass: introduce K_FROM_GIT for sources that derive from git repos

2016-08-20 Thread Joshua Kinard
On 08/20/2016 20:22, Daniel Campbell wrote:
> On 08/20/2016 05:13 AM, Joshua Kinard wrote:
>> All,
>>
>> It looks like that sometime around Linux 3.15, some kind of a quirk was
>> introduced where a patch that contains the removal of a symlink followed by 
>> the
>> addition of a file with the same name as the symlink causes patch's --dry-run
>> phase to fail, which kills 'epatch'.  See Bug #507656.
>>
>> A workaround was added to kernel-2.eclass, around line 1093, that hardcodes a
>> check for sys-kernel/git-sources, to avoid this issue.  Well,
>> sys-kernel/mips-sources is also affected by the same issue.  I'm close to
>> releasing a newer mips-sources, having spent the last few months
>> re-writing/refactoring chunks of old SGI IP27/BRIDGE code, and rather than 
>> add
>> another hardcode to kernel-2, I instead created a new variable, K_FROM_GIT,
>> that will replace the hardcode.
>>
>> When set to a value, it triggers the workaround, which still affects current
>> kernels.  This results in a cleaner implementation instead of a hardcoded
>> ebuild, should future kernel packages sourced from a git repo get added.
>>
>> Patch is attached for review.
>>
>> Thanks!
>>
> 
> lgtm, but I'm curious over the targeting of -rc releases. Are the only
> releases after 15 in the 3.x series -rc? If not, you're going to run
> into problems where a kernel is >=3.15 but not an rc.
> 
> Otherwise it seems better than hardcoding it imo.

This bug smells more like a corner-case problem with patch itself, but I am not
certain yet if it's been reported upstream to the GNU folks.  Seems to affect
sources built on top of, or pulled from, git repos.  mips-sources is derived
from periodic checkouts I do from the linux-mips.org git repo (ralf/linux.git),
with custom patches stacked on top.  Without this workaround, applying the base
patches (either patch-x.y from kernel.org or the mipsgit-x.y.z-mmdd* patch
I diff myself) will fail, on both -rc or stable releases.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



[gentoo-dev] Georgia Tech Rsync mirror issues

2016-08-20 Thread Joshua Kinard
If any mirror admins are lurking around, can someone poke whomever runs the
Georgia Tech (in the US) rsync mirror admin to see why their rsync server is
really slow?  I filed a bug about it back in June:

https://bugs.gentoo.org/show_bug.cgi?id=585524

But no action has happened yet.  It seems like their mirror is running at
around a plaid-inducing speed of ~2.3K/sec.  For anyone that remembers the
28.8kbps days...

Thanks!

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



[gentoo-dev] [PATCH] kernel-2.eclass: introduce K_FROM_GIT for sources that derive from git repos

2016-08-20 Thread Joshua Kinard
All,

It looks like that sometime around Linux 3.15, some kind of a quirk was
introduced where a patch that contains the removal of a symlink followed by the
addition of a file with the same name as the symlink causes patch's --dry-run
phase to fail, which kills 'epatch'.  See Bug #507656.

A workaround was added to kernel-2.eclass, around line 1093, that hardcodes a
check for sys-kernel/git-sources, to avoid this issue.  Well,
sys-kernel/mips-sources is also affected by the same issue.  I'm close to
releasing a newer mips-sources, having spent the last few months
re-writing/refactoring chunks of old SGI IP27/BRIDGE code, and rather than add
another hardcode to kernel-2, I instead created a new variable, K_FROM_GIT,
that will replace the hardcode.

When set to a value, it triggers the workaround, which still affects current
kernels.  This results in a cleaner implementation instead of a hardcoded
ebuild, should future kernel packages sourced from a git repo get added.

Patch is attached for review.

Thanks!

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic
--- /usr/portage/eclass/kernel-2.eclass.orig	2016-08-19 07:44:46.149376480 -0400
+++ /usr/portage/eclass/kernel-2.eclass	2016-08-19 08:29:50.729377972 -0400
@@ -49,6 +49,9 @@
 # 		  as a result the user cannot choose to apply those patches.
 # K_EXP_GENPATCHES_LIST	- A list of patches to pick from "experimental" to apply when
 # 		  the USE flag is unset and K_EXP_GENPATCHES_PULL is set.
+# K_FROM_GIT - If set, this variable signals that the kernel sources derives from a git tree and special
+#	handling will be applied so that any patches that are applied will actually apply.
+#
 # K_GENPATCHES_VER		- The version of the genpatches tarball(s) to apply.
 #		  A value of "5" would apply genpatches-2.6.12-5 to
 #		  my-sources-2.6.12.ebuild
@@ -1090,7 +1093,7 @@ unipatch() {
 			#  #
 			# https://bugs.gentoo.org/show_bug.cgi?id=507656   #
 			
-			if [[ ${PN} == "git-sources" ]] ; then
+			if [[ -n ${K_FROM_GIT} ]] ; then
 if [[ ${KV_MAJOR} -gt 3 || ( ${KV_MAJOR} -eq 3 && ${KV_PATCH} -gt 15 ) &&
 	${RELEASETYPE} == -rc ]] ; then
 	ebegin "Applying ${i/*\//} (-p1)"


Re: [gentoo-dev] [RFC] bugs.g.o: Merging UNCONFIRMED & CONFIRMED into NEW

2016-06-16 Thread Joshua Kinard
On 06/16/2016 09:22, Andrew Savchenko wrote:
> On Thu, 16 Jun 2016 14:26:47 +0200 Michał Górny wrote:
>> Hello, everyone.
>>
>> Here's my second RFC wrt bugs.gentoo.org redesign.
>>
>> Right now we have separate UNCONFIRMED and CONFIRMED states for bugs.
>> However, we use the two scarcely. I believe it would be beneficial to
>> replace the two with a single NEW state.
>>
>> Rationale:
>>
>> 1. Most of developers don't care about the two states, and which one
>> bugs are in.
>>
>> 2. All bugs need to be handled the same, whether they were marked as
>> confirmed or not.
>>
>> 3. We stage bugs through bug-wranglers@ which kinda has a similar
>> purpose to the UNCONFIRMED state in other Bugzillas.
>>
>> 4. Some people who actually care about the two states change them,
>> causing unnecessary bugspam.
>>
>> 5. Some users who think that the state matters get furious about bugs
>> staying in UNCONFIRMED for long.
>>
>> Your thoughts?
>  
> CONFIRMED state is useful, it means that dev or powerful user
> confirmed this bug and gives it more value. I'd like to keep it.
> 
> Best regards,
> Andrew Savchenko

+1 here, too.  UNCONFIRMED should be the default for new bugs, because
sometimes, issues can get reported that are really obscure and, for example,
tied to a particular hardware configuration, thus cannot be easily and
independently confirmed.  It'd be nice if, when replying in a comment, a flag
could be made available to automatically to state that "I've encountered this
issue, too", and once 2, 3, or 4 of those are logged, Bugzilla automatically
changes the state to CONFIRMED, but doesn't bugspam on this specific state 
change.

Also, +1 to changing UNRESOLVED to OPEN.

Don't suppose we can get a RESOLVED::RTFM, can we? :)

(I'm kidding)

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] [RFC] 'Gentoo Linux' bugzilla component reorganization

2016-06-16 Thread Joshua Kinard
On 06/16/2016 08:04, Michał Górny wrote:
> On Wed, 15 Jun 2016 21:11:30 +0200
> Michał Górny <mgo...@gentoo.org> wrote:
> 
>> Right now we have the following components:
>>
>> - Applications,
>> - baselayout,
>> - Core system,
>> - Development,
>> - Eclasses and Profiles,
>> - Games,
>> - GCC Porting,
>> - GNOME,
>> - Hardened,
>> - Java,
>> - KDE,
>> - Keywording & Stabilization,
>> - Library,
>> - New packages ('New ebuilds' previously),
>> - Printing,
>> - SELinux,
>> - Server,
>> - Unspecified.
> 
> Revision two:
> 
> - Current packages [bug-wranglers@],
> - Eclasses [bug-wranglers@],
> - Hardened [hardened@],
> - New packages [bug-wranglers@],
> - Overlays [overlays@],
> - Profiles [bug-wranglers@],
> - SELinux [selinux@].
> 
> Major changes:
> 
> 1. collapsed all category-like components into a single 'Current
> packages' that is the default component for pretty much every bug
> related to 'standard' configurations of Gentoo Linux -- making it easy
> to choose the correct one and ensuring everything goes through
> bug-wranglers;
> 
> 2. split 'eclasses & profiles' into two separate categories -- mainly
> intended for developer use;
> 
> 3. left 'Hardened' and 'SELinux' (also the whole separate Gentoo/Alt
> product) as the non-standard system configurations that desire staging
> the bugs through respective teams,
> 
> 4. left 'New packages' as-is, as category for requesting addition
> of packages not yet in Gentoo,
> 
> 5. added 'Overlays' component for bugs filed against packages
> in third-party repositories (right now some of them got filed pretty
> randomly, and having them in Infra->Overlays is kinda wrong),
> 
> 6. removed 'Keywording & stabilization'. As pointed out, those can be
> handled via keywords and we already do stabilizations in other places
> (e.g. security bugs).
> 
> Your thoughts about this one?

I'd add at least an entry for "Toolchain" and route it to the toolchain@g.o
address by default.  Most users know to assign a majority of gcc-related or
binutils-related bugs to toolchain anyways.  Not sure if gcc-porting should be
broken out, though.  That is a separate alias that's targeted at working out
issues on newer gcc releases and/or new capabilities.

I could think of others, like one for Gentoo/Alt, for the FreeBSD and other
ports that kinda do their own thing.  Linux alt-archs can get sorted out by
bug-wranglers.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] What are eblits?

2016-05-29 Thread Joshua Kinard
On 05/29/2016 04:25, Ulrich Mueller wrote:
>>>>>> On Sun, 29 May 2016, Rich Freeman wrote:
> 
>> What I would love to see is this be standardized. An eclass or a
>> GLEP seems like the logical approach.
> 
> I am strongly opposed against this. Ebuilds should not source
> executable code from random locations. This is also a huge QA
> violation, since PMS neither guarantees FILESDIR to be available in
> global scope (so especially, not during metadata generation), nor in
> any of the pkg_* phases (like pkg_setup, where mips-sources sources
> its eblits).

I believe this was addressed already back in 2010, for mips-sources at least.
Can't speak for the other eblit consumers.  See Bug #300370.

Eblits used to be loaded in global scope, which is what caused the $FILESDIR
issue, so the change was to move them into a function, then call that function
from pkg_setup.  This also makes sure the eblit code gets packed into the tbz2
so it's available when $FILESDIR isn't.

As for sourcing from random locations...point, because the standard path isn't
set in stone in an eclass or GLEP.  $FILESDIR/eblits is the path used by at
least glibc and mips-sources eblits.  I haven't looked at Perl or PHP's.
Totally open to addressing that in a sane manner.


> If there really is a need for such a feature, we should rather follow
> an approach like the per-package eclasses previously suggested by mabi
> and antarus [1], and support a pkg-inherit function in the next EAPI.
> (Though I wouldn't add a new function, but add an option to inherit,
> like "inherit -p".)

That seems like an attempt to revive the elibs idea, which is what eblits were
eventually supposed to morph into at some point.  I have no idea why elibs died
off.  Probably lack of interest or need back in 2005, when Gentoo was far, far
smaller in size and scope.

IMHO, to avoid that happening again, any such solution (regardless of name)
should probably look at implementing the bare minimum needed to replace all
existing consumers of eblits with the least amount of upheaval.  Then new
functionality can be added down the road.  Try to do everything at once, and
it'll just die off again.


> We could even think about per-category eclasses ("inherit -c"),
> although it is not obvious where one would store them.

Easy...under eclass/, in per-category sub-folders :)

(yay for more directory bureaucracy!)


> Ulrich
> 
> [1] 
> https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/users/antarus/projects/gleps/glep-XX.txt?view=markup
> 


-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] please remove me off your mailing list

2016-05-28 Thread Joshua Kinard
On 05/23/2016 17:37, Kent Fredric wrote:
> On 24 May 2016 at 09:22, Kristian Fiskerstrand <k...@gentoo.org> wrote:
>> give a man a fish and he has food for a day, teach a man to fish and he
>> has food for a lifetime
> 
> 
> But if you feed a man while you teach him, he's better equipped to learn. :p
> 
> Hence, the suggestion includes both.
> 
> - Solve the immediate issue.
> - Include information to solving the issue in future.

The other, less popular option, is to just feed the man to the fish.  That also
solves the problem :)

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] What are eblits?

2016-05-28 Thread Joshua Kinard
On 05/26/2016 21:28, Kent Fredric wrote:
> On 27 May 2016 at 10:28, rindeal <dev.rind...@gmail.com> wrote:
>>
>> 1) what are they?
>> 2) why are they used?
> 
> 
> My best explanation is its a way to re-use very large amounts of code
> between 2 ebuilds, without resorting to:
> 
> a) Copying the whole ebuild and hoping you find the relevant part in diffs
> b) Not needing reams of version-specific conditional code to make
> copying ebuilds between versions easier.
> c) Not needing confusing eclasses that exist to serve a single
> package, loaded with lots of weird conditional logic.
> 
> My understanding is you could effectively roll the eblits back into
> the ebuild statically, just doing so would make keeping the changes
> consistent harder.
> 
> Its clearly designed for a system where you have ~10 different
> versions of Perl available or ~10 different versions of glibc
> available, but you don't want to pay the price of duplicating that
> logic wholesale for every minor concurrent revision, and only want to
> update essential differences when you need to, not because you have
> to.
> 
> That said, its a very confusing system to get your head around,
> because its *basically* yet another "mixin" system like "inherit", but
> done in bash, which itself is a rather strange language to be doing
> something as complicated as mixins.

An accurate explanation, but probably better to say they're more like "local
eclasses".  If you think of the existing eclasses in ${PORTDIR}/eclass as
"global", that is, they contain common code utilized by multiple unrelated
ebuild packages, then eblits were originally envisioned as localized versions
of eclasses to share package-specific code between multiple ebuilds of
differing versions.

Whether the idea is useful in the present day and age, eh, who knows.  For the
mips-sources ebuilds, eblits let me centralize the per-machine notes and
unpacking logic, which reduced each ebuild's size from ~18KB a few years ago
down to ~4.9KB today.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] What are eblits?

2016-05-28 Thread Joshua Kinard
On 05/26/2016 18:28, rindeal wrote:
> I've noticed that ebuilds for at least dev-lang/perl and
> sys-libs/glibc are using some concept of "eblits", which seems like
> parts of ebuilds scattered across $FILESDIR with ebuilds containing
> some logic (involving eval) which includes and runs them.
> 
> I haven't found any documentation related to them so I'm asking here:
> 
> 1) what are they?
> 2) why are they used?

I'm the other user of eblits in sys-kernel/mips-sources.  There's a lot of
common code in that package that doesn't need to be duplicated between multiple
ebuilds, so years ago, I converted to using versioned eblits.  It's a touch
manual, in that I have to manually check that all consumers of a specific eblit
version are removed from the tree before I remove the deprecated version, but
it avoids the nasty problem of changing an eblit for a newer ebuild that breaks
an older ebuild.

I started on an "eblits.eclass" a few months ago, but sidetracked and didn't
get back to it.  Attached, if anyone wants to play with it.  It includes the
core eblit loading functions used in mips-sources, which might be more
updated/robust than the ones in glibc (last I checked the logic, but vapier can
clarify if true or not).  The last comment block is incomplete.  I sidetracked
in finishing item #2 when pondering how to define a global "check" variable in
the eclass itself to control when the eblit core functions were loaded and all
eblits parsed (see latest mips-sources ebuild, $MIPS_SOURCES_EBLITS_LOADED).

Also handles the case of when installing from binary packages and $FILESDIR
isn't available.  The eblit source for the pkg_* phases are packed onto the end
of the bzip2 tarball so they're available to Portage & friends.

The core eblit loading functions are the only duplicated code in the
mips-sources ebuilds, as well as glibc and other eblit users (perl?).  I don't
remember what the argument for or against eblits might have been back in the
day, but for ebuilds whose only real changes are datestamps and/or version
numbers, eblits are a nice way to encapsulate and share common code that is too
specific for a global eclass.  Centralizing the eblit code will allow
mips-sources and glibc ebuilds to shrink their overall filesize a little-bit
more (~1.5KB per mips-sources ebuild, so 3.4KB per ebuild instead of the
current 4.9KB).

And yes, for anyone wondering, I have new mips-sources ebuilds.  Just took a
month to partially rewrite the SGI Origin/IP27 kernel code and then hunt down a
hardware bug on my SGI Octane, so, been distracted...

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic
# Copyright 1999-2016 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Id$

# Description: eblit.eclass contains the core functions for creating "eblits".
#  eblits are a place to store common code shared among multiple
#  ebuilds for a specific package.
#
# Original Eblit Author: Mike Frysinger <vap...@gentoo.org>
# Original Eclass Author: Joshua Kinard <ku...@gentoo.org>
# Maintainer: base-sys...@gentoo.org

# Implementation Note: Since code in an eblit is used by multiple ebuilds,
# PLEASE revbump the eblit files when changes are made.  Then update each
# ebuild to use the new eblit version.  Remove old eblit versions when there
# are no more consumers.  This makes it a lot easier to debug problems with
# the shared code within an eblit, as well as the affected ebuilds.

# To create an eblit:
#  1. Create an "eblits" subdirectory under ${FILESDIR}, if one does not
# already exist.
#  2. Create a new file name using the following formula:
# [a-z0-9_]-v[0-9]+.eblit
#  3. Add the shared code, save, and close the file.
#
# Try to keep eblits specific to the functions they implement.  E.g., if a
# number of ebuilds have a large, but common src_unpack() function, and it
# is not already provided by an eclass, then add that code to an eblit named
# "src_unpack-vX.eblit".

# To load and use eblits:
#  1. Inherit the "eblit" eclass (this class).
#  2. Define a new function called "load_eblit_funcs" in the ebuild immediately
# after the global ebuild variables


# eblit-core
# Usage:  [version]
# Main eblit engine
eblit-core() {
local e v func=$1 ver=$2
for v in ${ver:+-}${ver} -${PVR} -${PV} "" ; do
e="${FILESDIR}/eblits/${func}${v}.eblit"
if [[ -e ${e} ]] ; then
. "${e}"
[[ ${func} == pkg_* ]] && eval "${func}() { eblit-run 
${func

Re: [gentoo-portage-dev] dead emerge processes and/or lockfiles

2016-04-24 Thread Joshua Kinard
On 04/24/2016 20:21, Joshua Kinard wrote:
> On 04/24/2016 20:09, Zac Medico wrote:
>> On 04/24/2016 04:50 PM, Joshua Kinard wrote:
>>> On 01/18/2016 07:37, Joshua Kinard wrote:
>>>> On 01/17/2016 15:01, Zac Medico wrote:
>>>>> On 01/17/2016 09:06 AM, Brian Dolbec wrote:
>>>>>>
>>>>>> I've read in several forum posts lately about emerge not running and
>>>>>> the problem comes down to dead emerge processes and remaining lockfiles.
>>>>>>
>>>>>> Perhaps we should make an emaint module to search for and fix these.
>>>>>> It should be easy enough.
>>>>>
>>>>> It would be nicer if we fixed whatever issue(s) cause the emerge
>>>>> processes to hang up. How would the emaint module distinguish a "good"
>>>>> emerge process from a "bad" one? I suppose you could strace it to see if
>>>>> it has any activity.
>>>>>
>>>>
>>>> I've been playing around with Gentoo/FreeBSD and have been noticing that 
>>>> emerge
>>>> is leaving orphaned processes behind on that platform.  Seems to be
>>>> ecompressdir getting hung up.  emerge itself just moves on, but after I
>>>> accumulated ~5 of those stuck ecompressdir processes in a single run, I 
>>>> kill
>>>> -9'ed them all.  Didn't see side-effects similar to what's described in the
>>>> original post, but the way to detect this issue might be to look for 
>>>> orphaned
>>>> children processes lacking a parent PID, then reap them.
>>>
>>>
>>> Updating my FreeBSD VM again, I captured one of the error messages that's
>>> leading to these orphaned ecompressdir processes:
>>>
>>> /usr/lib/portage/python3.5/ebuild-helpers/ecompressdir: cannot make pipe for
>>> process substitution: File exists
>>> /usr/lib/portage/python3.5/ebuild-helpers/ecompressdir: line 72:
>>> /ramfs/portage/sys-freebsd/boot0-10.3/temp/sh-np-1865519000: ambiguous 
>>> redirect
>>> ecompressdir: bzip2 -9 /usr/share/man
>>>  * The ebuild phase 'install' with pid 32075 appears to have left an orphan
>>>  * process running in the background.
>>>
>>>
>>> And a second one:
>>> /ramfs/portage/._portage_reinstall_.pesqhjhn/bin/ebuild-helpers/ecompressdir:
>>> cannot make pipe for process substitution: File exists
>>> /ramfs/portage/._portage_reinstall_.pesqhjhn/bin/ebuild-helpers/ecompressdir:
>>> line 72: /ramfs/portage/sys-apps/grep-2.25/temp/sh-np-474708936: ambiguous 
>>> redirect
>>> ecompressdir: bzip2 -9 /usr/share/man
>>> ecompressdir: bzip2 -9 /usr/share/info
>>> ecompressdir: bzip2 -9 /usr/share/doc
>>>  * The ebuild phase 'install' with pid 60185 appears to have left an orphan
>>>  * process running in the background.
>>>
>>> Not sure the exact cause.  Any additional info I can provide?
>>>
>>> --J
>>
>> Looks like a problem with bash. Make sure your bash has the fix for this
>> issue:
>>
>> https://bugs.gentoo.org/show_bug.cgi?id=447810
>>
>> What version of bash is it? Maybe try some other versions.
> 
> Latest version in ~arch, bash-4.3_p42-r2.
> 
> Doesn't appear to be completely tied to FreeBSD, either, as there's this
> unanswered topic on the forums from Nov 2015:
> https://forums-lb.gentoo.org/viewtopic-t-1032574.html?sid=5d7566d09a49ba06124032598d3ad362
> 
> Just looks like FreeBSD trips it up far more often, as I've only seen it 
> there.
> 
> --J

Took some more digging, but here's our bug for it.  Does appear to be mostly
FreeBSD-related:
https://bugs.gentoo.org/show_bug.cgi?id=574426

Doesn't answer the question of how it happened in that one Linux case, but w/o
additional information, sounds like it's a remote corner case on Linux and hard
to reproduce.

--J




Re: [gentoo-portage-dev] dead emerge processes and/or lockfiles

2016-04-24 Thread Joshua Kinard
On 04/24/2016 20:09, Zac Medico wrote:
> On 04/24/2016 04:50 PM, Joshua Kinard wrote:
>> On 01/18/2016 07:37, Joshua Kinard wrote:
>>> On 01/17/2016 15:01, Zac Medico wrote:
>>>> On 01/17/2016 09:06 AM, Brian Dolbec wrote:
>>>>>
>>>>> I've read in several forum posts lately about emerge not running and
>>>>> the problem comes down to dead emerge processes and remaining lockfiles.
>>>>>
>>>>> Perhaps we should make an emaint module to search for and fix these.
>>>>> It should be easy enough.
>>>>
>>>> It would be nicer if we fixed whatever issue(s) cause the emerge
>>>> processes to hang up. How would the emaint module distinguish a "good"
>>>> emerge process from a "bad" one? I suppose you could strace it to see if
>>>> it has any activity.
>>>>
>>>
>>> I've been playing around with Gentoo/FreeBSD and have been noticing that 
>>> emerge
>>> is leaving orphaned processes behind on that platform.  Seems to be
>>> ecompressdir getting hung up.  emerge itself just moves on, but after I
>>> accumulated ~5 of those stuck ecompressdir processes in a single run, I kill
>>> -9'ed them all.  Didn't see side-effects similar to what's described in the
>>> original post, but the way to detect this issue might be to look for 
>>> orphaned
>>> children processes lacking a parent PID, then reap them.
>>
>>
>> Updating my FreeBSD VM again, I captured one of the error messages that's
>> leading to these orphaned ecompressdir processes:
>>
>> /usr/lib/portage/python3.5/ebuild-helpers/ecompressdir: cannot make pipe for
>> process substitution: File exists
>> /usr/lib/portage/python3.5/ebuild-helpers/ecompressdir: line 72:
>> /ramfs/portage/sys-freebsd/boot0-10.3/temp/sh-np-1865519000: ambiguous 
>> redirect
>> ecompressdir: bzip2 -9 /usr/share/man
>>  * The ebuild phase 'install' with pid 32075 appears to have left an orphan
>>  * process running in the background.
>>
>>
>> And a second one:
>> /ramfs/portage/._portage_reinstall_.pesqhjhn/bin/ebuild-helpers/ecompressdir:
>> cannot make pipe for process substitution: File exists
>> /ramfs/portage/._portage_reinstall_.pesqhjhn/bin/ebuild-helpers/ecompressdir:
>> line 72: /ramfs/portage/sys-apps/grep-2.25/temp/sh-np-474708936: ambiguous 
>> redirect
>> ecompressdir: bzip2 -9 /usr/share/man
>> ecompressdir: bzip2 -9 /usr/share/info
>> ecompressdir: bzip2 -9 /usr/share/doc
>>  * The ebuild phase 'install' with pid 60185 appears to have left an orphan
>>  * process running in the background.
>>
>> Not sure the exact cause.  Any additional info I can provide?
>>
>> --J
> 
> Looks like a problem with bash. Make sure your bash has the fix for this
> issue:
> 
> https://bugs.gentoo.org/show_bug.cgi?id=447810
> 
> What version of bash is it? Maybe try some other versions.

Latest version in ~arch, bash-4.3_p42-r2.

Doesn't appear to be completely tied to FreeBSD, either, as there's this
unanswered topic on the forums from Nov 2015:
https://forums-lb.gentoo.org/viewtopic-t-1032574.html?sid=5d7566d09a49ba06124032598d3ad362

Just looks like FreeBSD trips it up far more often, as I've only seen it there.

--J



Re: [gentoo-portage-dev] dead emerge processes and/or lockfiles

2016-04-24 Thread Joshua Kinard
On 01/18/2016 07:37, Joshua Kinard wrote:
> On 01/17/2016 15:01, Zac Medico wrote:
>> On 01/17/2016 09:06 AM, Brian Dolbec wrote:
>>>
>>> I've read in several forum posts lately about emerge not running and
>>> the problem comes down to dead emerge processes and remaining lockfiles.
>>>
>>> Perhaps we should make an emaint module to search for and fix these.
>>> It should be easy enough.
>>
>> It would be nicer if we fixed whatever issue(s) cause the emerge
>> processes to hang up. How would the emaint module distinguish a "good"
>> emerge process from a "bad" one? I suppose you could strace it to see if
>> it has any activity.
>>
> 
> I've been playing around with Gentoo/FreeBSD and have been noticing that 
> emerge
> is leaving orphaned processes behind on that platform.  Seems to be
> ecompressdir getting hung up.  emerge itself just moves on, but after I
> accumulated ~5 of those stuck ecompressdir processes in a single run, I kill
> -9'ed them all.  Didn't see side-effects similar to what's described in the
> original post, but the way to detect this issue might be to look for orphaned
> children processes lacking a parent PID, then reap them.


Updating my FreeBSD VM again, I captured one of the error messages that's
leading to these orphaned ecompressdir processes:

/usr/lib/portage/python3.5/ebuild-helpers/ecompressdir: cannot make pipe for
process substitution: File exists
/usr/lib/portage/python3.5/ebuild-helpers/ecompressdir: line 72:
/ramfs/portage/sys-freebsd/boot0-10.3/temp/sh-np-1865519000: ambiguous redirect
ecompressdir: bzip2 -9 /usr/share/man
 * The ebuild phase 'install' with pid 32075 appears to have left an orphan
 * process running in the background.


And a second one:
/ramfs/portage/._portage_reinstall_.pesqhjhn/bin/ebuild-helpers/ecompressdir:
cannot make pipe for process substitution: File exists
/ramfs/portage/._portage_reinstall_.pesqhjhn/bin/ebuild-helpers/ecompressdir:
line 72: /ramfs/portage/sys-apps/grep-2.25/temp/sh-np-474708936: ambiguous 
redirect
ecompressdir: bzip2 -9 /usr/share/man
ecompressdir: bzip2 -9 /usr/share/info
ecompressdir: bzip2 -9 /usr/share/doc
 * The ebuild phase 'install' with pid 60185 appears to have left an orphan
 * process running in the background.

Not sure the exact cause.  Any additional info I can provide?

--J




Re: [gentoo-dev] usr merge

2016-04-10 Thread Joshua Kinard
On 04/10/2016 08:14, Rich Freeman wrote:
> On Sun, Apr 10, 2016 at 7:55 AM, Joshua Kinard <ku...@gentoo.org> wrote:
>>
>> Create like, a table on the Wiki or some kind of metadata property 
>> per-package
>> that can contain a boolean or tri-state flag indicating whether it works or
>> doesn't work (or kinda works) on split-usr.  Or a tracker on Bugzie.  
>> Something.
>>
> 
> I'm sure there will be a tracker for packages that don't work on a
> merged /usr.  (We are already on a split /usr.)
> 
> Honestly, I'm still not quite sure why we're even having this
> discussion.  I don't think anybody actually intends to make any
> changes at all.  If they do, they should issue some kind of plan and
> indicate what they're looking for from everybody else.

Agreed.  A plan is most definitely needed if we ever choose to pursue a policy
of only supporting non-split-/usr installs, especially if we want to handle
cases like mine where we try to make migration of existing installs possible or
not.


[snip]

> It seems to me that we're just having a general discussion about the
> pros/cons of a /usr merge.  That is nice, but people are getting
> worked up because they think that somehow whoever "loses" this
> "discussion" will get something shoved down their throats or won't be
> able to have something nice.

"General discussion" -- hah!  Maybe it's the way Thunderbird is displaying it,
but I have five distinct, top-level threads in my gentoo-dev folder for this
discussion.  I think we left "general" back there after we broke through the
plaid barrier.

That said, I don't really think there are any pros or cons of split or merged.
 Largely, what's being discussed is the after-effects of what once was a common
approach to filesystem layout.  Myself, I only went the split-usr route because
of habit, itself which started because when I set up my first Gentoo system.  I
studied both the then-Gentoo Security and Debian Security manuals, which
indicated a split-/usr layout had certain advantages in that you could limit
capabilities via mount options.  Mainly, /usr didn't need devices, so "nodev"
was common there.  Along with /var having "noexec" and "nodev".

I've pretty much stuck to that layout approach since then out of habit.
Certainly, I've got a few VMs where I have just /, /boot, and /tmp as my only
partitions, and there's no real noticeable difference except what's in 
/etc/fstab.

---

I think where the problem ultimately arises is a subtle conflict between
filesystem semantics and system-design philosophy against the Linux kernel's
device architecture and management.  It's long regarded that /bin and /sbin
contain system-level binaries, and /usr/bin and /usr/sbin being for almost
everything else.  A.k.a., a two-level binary installation hierarchy (and the
BSD's extend this with a third level under /usr/local).

>From the kernel angle, you have a monolithic kernel design where device drivers
run in kernel space most of the time.  This worked okay with traditional,
static devices that didn't change a whole lot and whose resources could be
determined at boot-time, before userspace is brought up.  But once the Linux
ecosystem needed devices that can come online from userspace or need their
resource determination to be dynamic (e.g., for hotplugging), we went to the
approach that the kernel needs to get out of managing devices altogether, and
thus came up with udev for device management from userspace.

Since udev is supposed to run from userspace, but kinda needs to interface with
the kernel a lot, the split between what's system-specific and what's not
clashes with the two-level file system layout.  This wasn't anything new...this
conflict has existed elsewhere for a long time (namely in X11), but it came to
a head when udev maintainers (and later, systemd maintainers) questioned the
approach, and largely decided it wasn't worth it, and a merged filesystem, with
/usr not separate, was simpler and more elegant.

---

But really, does it matter where the binaries all live?  It's just a design
decision.  Every OS had a different approach, such as NetWare running virtually
everything out of SYS:SYSTEM, and Windows out of C:\WINDOWS.  Heck, for the
longest time, you could *not* install Windows on anything other than the first
partition of the first drive, because software literally hardcoded filespec
strings as "C:\WINDOWS\...".  And even why C:, the third letter of the
alphabet, for the first fixed disk?  Because A: and B: were reserved for
systems that needed two floppy drives.  Yay MS-DOS!

If it were possible to give every binary and file out there a unique name, you
wouldn't even need directories.  You could have a totally-flat namespace with
all files of any kind under /, and let security models handle who sees/accesses
what.  But in that se

Re: [gentoo-dev] usr merge

2016-04-10 Thread Joshua Kinard
On 04/04/2016 21:19, William Hubbs wrote:
> All,
> 
> I thought that since the usr merge is coming up again, and since I lost
> track of the message where it was brought up, I would open a
> new thread to discuss it.
> 
> When it came up before, some were saying that the /usr merge violates
> the fhs. I don't remember the specifics of what the claim was at the
> time, (I'm sure someone will point it out if it is still a concern).
> 
> I don't think creating usr merged stages would be that difficult. I
> think it would just be a matter of creating a new version of baselayout
> that puts these symlinks in place:
> 
> /bin->usr/bin
> /lib->usr/lib
> /lib32->usr/lib32
> /lib64->usr/lib64
> /sbin->usr/bin
> /usr/sbin->bin
> 
> Once that is in place in a new baselayout, I think portage's colission
> detection would be able to catch files that had the same names and were
> originally in different paths when building the new stages.
> 
> I put some thought also in how to nigrate live systems, and I'm not sure
> what the best way to do that is. I wrote a script, which would do it in
> theory, but I haven't tested because I only have one system and if
> it breaks it the only way back would be to reinstall.
> 
> The script is attached.
> 
> 
> Thoughts on any of this?
> 
> William

I looked at Thunderbird, at my folder labeled "gentoo-dev", and it had "666"
unread messages.  I should've done the smart thing and closed my mail program.
 But n, I had to look inside the folder.  I am now regretting this decision.

*sigh*, I can see the thread has gone clongie 'round the blonger, so all I'll
have to say is we should still try to maintain the choice for users.  But, in
order to evaluate what amount of effort is needed to maintain that choice, we
need to know what packages break on such a setup, what the level of effort
needed to fix them is, and do those fixes impact the non-split crowd.

Create like, a table on the Wiki or some kind of metadata property per-package
that can contain a boolean or tri-state flag indicating whether it works or
doesn't work (or kinda works) on split-usr.  Or a tracker on Bugzie.  Something.

Once we know this, then we can work out what's the minimum system that can be
successfully run on split-usr.  Then, knowing *that*, we can see if that system
can be supported by our @system target or some minimal subset of @world.  As
new package versions come out of upstream, we update this metadata with changes
to the split-usr status, and this then provides a history of the more or less
amount of difficulty needed to maintain support for split-usr, and *then*, we
can make an objective decision to continue supporting or not supporting the
capability.

As for me, I am flat out ruling out a full-reinstall of all my systems.  I have
fixed disk partition layouts on all of them that cannot be re-arranged unless I
tar up each filesystem and temporarily move it off, then rebuild the MD-RAID
and reformat the filesystems.  I am simply not going to do that on my many SGI
systems, and whatever facet of upstream, whether it's some core GNU package or
RH itself, can go pound sand for all I care.  I'll go back to a static /dev and
I'll manually mknod any missing devices if I have to.

You know it's getting ridiculous when you can maintain a Windows/NTFS partition
layout easier than a Linux one.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] Re: Changing order of default virtual/udev provider

2016-02-13 Thread Joshua Kinard
On 02/10/2016 20:15, Ian Stakenvicius wrote:
> On 10/02/16 12:09 PM, Brian Dolbec wrote:
>> On Wed, 10 Feb 2016 10:26:12 -0600 William Hubbs
>> <willi...@gentoo.org> wrote:
> 
> 
>>>> Often the decision to procrastinate is a decision that is
>>>> rewarded. That should be considered carefully.
>>>
>>> + 1.
>>>
>>> I also saw another issue that made me shudder. If we change
>>> the default to eudev, people who are running separate /usr are
>>> going to think they can kill their initramfs's, because people
>>> in gentoo conflated the separate /usr and initramfs issue with
>>> udev [1].
>>>
>>> William
>>>
>>> [1] https://bugs.gentoo.org/show_bug.cgi?id=573760#C4
> 

[snip]

> 
> Yeah I second this -- it was decided officially by council (what, 2
> years ago now?) that separate-/usr-without-initramfs doesn't need to
> be officially supported anymore, and so if things break that it is
> up to end-users to ensure they pick up the pieces.
> 
> Although it is likely that eudev *will* keep installation onto / and
> out of /usr to help with this not-officially-supported situation in
> Gentoo, that doesn't mean the other projects have to stay out of
> /usr, and "it worked before the upgrade but doesn't now" certainly
> doesn't mean it's a valid bug.  If a user or sysadmin drops their
> initramfs when they have a separate-/usr system, any resulting
> breakage is on them.
> 

FWIW, I have separate /usr on several systems, and haven't needed an initramfs
thus far.  I thought we had some trick active in busybox or even eudev that
handles separate /usr for *simple* filesystem configurations (i.e., just basic
partitions, no LVM, evms, encryption, etc).

So I don't there would be immediate breakage in this scenario.  It's going to
depend on how a given system was configured.  Simple setups appear to
JustWork(), AFAICT.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] Re: Herd likely up for grabs: kernel-misc

2016-01-22 Thread Joshua Kinard
On 01/20/2016 14:48, Duncan wrote:
> Mike Frysinger posted on Wed, 20 Jan 2016 13:40:04 -0500 as excerpted:
> 
>> if base-system@ isn't going to maintain it, we'll punt it from the herd
>> -mike
> 
> Umm, you mean project, right?  Because the whole discussion here is part 
> of getting rid of herds.  =:^)
> 

Somewhere in my archives, I have the e-mail proposing the creation of herds.

...

I feel old now.


--J



Re: [gentoo-portage-dev] dead emerge processes and/or lockfiles

2016-01-18 Thread Joshua Kinard
On 01/17/2016 15:01, Zac Medico wrote:
> On 01/17/2016 09:06 AM, Brian Dolbec wrote:
>>
>> I've read in several forum posts lately about emerge not running and
>> the problem comes down to dead emerge processes and remaining lockfiles.
>>
>> Perhaps we should make an emaint module to search for and fix these.
>> It should be easy enough.
> 
> It would be nicer if we fixed whatever issue(s) cause the emerge
> processes to hang up. How would the emaint module distinguish a "good"
> emerge process from a "bad" one? I suppose you could strace it to see if
> it has any activity.
> 

I've been playing around with Gentoo/FreeBSD and have been noticing that emerge
is leaving orphaned processes behind on that platform.  Seems to be
ecompressdir getting hung up.  emerge itself just moves on, but after I
accumulated ~5 of those stuck ecompressdir processes in a single run, I kill
-9'ed them all.  Didn't see side-effects similar to what's described in the
original post, but the way to detect this issue might be to look for orphaned
children processes lacking a parent PID, then reap them.

--J



Re: [gentoo-dev] Herd likely up for grabs: net-fs

2016-01-17 Thread Joshua Kinard
On 01/17/2016 15:03, Michał Górny wrote:
> Hello, everyone.
> 
> The current maintainer of net-fs herd so far hasn't replied to our
> queries. If we don't get any reply in a week, we will be disbanding it
> and looking for new maintainers for its packages.
> 
> Is anyone interested in keeping the herd as a whole and maintaining all
> of its packages? If nobody replies till 2016-01-24, the herd will be
> automatically disbanded and I will be sending a complete list of
> packages needing maintainers.
> 
> Packages currently in herd along with their other maintainers:
> 

[snip]

> net-fs/ncpfs : 

I'll claim this one.  I actually have several old NetWare VMs (3.x, 4.2) that I
can test this with from time-to-time, both TCP/IP and old IPX.


> net-fs/nfs4-acl-tools: 
> net-fs/nfs-utils : 
> net-nds/rpcbind  :
> net-libs/libnfsidmap :

base-system has portmap already, and given some run nfs as a root filesystem, I
wonder if base-system shouldn't cover these as well?

--J




Re: [gentoo-dev] Herd likely up for grabs: kernel-misc

2016-01-17 Thread Joshua Kinard
On 01/17/2016 14:57, Michał Górny wrote:
> Hello, everyone.
> 
> The current maintainers of kernel-misc herd so far haven't replied to
> our queries. If we don't get any reply in a week, we will be disbanding
> it and looking for new maintainers for its packages.
> 
> Is anyone interested in keeping the herd as a whole and maintaining all
> of its packages? If nobody replies till 2016-01-24, the herd will be
> automatically disbanded and I will be sending a complete list of
> packages needing maintainers.
> 
> Packages currently in herd along with their other maintainers:
> 

[snip]

> sys-apps/kexec-tools : 

Better suited for base-system, maybe?

[snip]

> sys-fs/jfsutils  : 

Definitely base-system, as xfsprogs is already maintained by them.

--J



Re: [gentoo-dev] Herd up for grabs: net-dialup

2016-01-16 Thread Joshua Kinard
On 01/16/2016 12:30, Michał Górny wrote:
> Hello, everyone.
> 
> The current maintainer(s) of net-dialup herd has decided that he's
> (they're) not interested in keeping it and would like the packages
> to be dropped to maintainer-needed.
> 
> Is anyone interested in keeping the herd as-is and maintaining all
> packages in it? If I get no reply till 2016-01-24, I will effectively
> remove the herd and announce the packages that landed in maintainer-
> -needed as a result.
> 
> Packages currently in herd, along with their other maintainers:
> 
> net-dialup/accel-ppp : pinkbyte@
> net-dialup/capi4k-utils  : 
> net-dialup/capidivert: 
> net-dialup/capifwd   : 
> net-dialup/capisuite : 
> net-dialup/cistronradius : 
> net-dialup/cutecom   : 
> net-dialup/dial  : 
> net-dialup/diald : 
> net-dialup/drdsl : 
> net-dialup/dtrace: sbriesen@
> net-dialup/dwun  : 
> net-dialup/fbgetty   : 
> net-dialup/fcpci : 
> net-dialup/freeradius: 
> net-dialup/freeradius-client : 
> net-dialup/globespan-adsl: 
> net-dialup/gnuradius : 
> net-dialup/gtkterm   : 
> net-dialup/hcfpcimodem   : 
> net-dialup/isdn-firmware : 
> net-dialup/itund : 
> net-dialup/kpnadsl4linux : 
> net-dialup/linux-atm : 
> net-dialup/lrzsz : 
> net-dialup/mgetty: 
> net-dialup/mingetty  : 
> net-dialup/minicom   : 
> net-dialup/mwavem: 
> net-dialup/picocom   : flameeyes@
> net-dialup/ppp   : 
> net-dialup/pppconfig : 
> net-dialup/ppp-scripts   : 
> net-dialup/pptpclient: 
> net-dialup/pptpd : 
> net-dialup/qtwvdialer: 
> net-dialup/radiusclient  : 
> net-dialup/radiusclient-ng   : 
> net-dialup/rp-l2tp   : 
> net-dialup/rp-pppoe  : 
> net-dialup/sendpage  : 
> net-dialup/sercd : 
> net-dialup/speedtouch-usb: 
> net-dialup/tkvoice   : 
> net-dialup/ueagle4-atm   : 
> net-dialup/ueagle-atm: 
> net-dialup/wvdial: 
> net-dialup/xc: 
> net-dialup/xl2tpd: floppym@
> net-dns/pdnsd: polynomial-c@
> net-libs/libcapi : 
> net-libs/wvstreams   : 
> net-misc/capiisdnmon : 
> net-misc/hylafaxplus : mattm@
> net-misc/iaxmodem: 
> net-misc/termpkg : 
> www-apps/freeradius-dialupadmin : 
> 

I can look at taking over net-dialup/xc.  It rarely gets updates anyways, as
upstream never intended it to be used on Linux (Xenix and SCO OpenServer were
the intended targets).  Somehow, it works, but has quite a few QA issues
(namely cavalier sprintf() usage with no buffer overflow checks).  It's been on
my TODO list to fix up one of these days, as well as adding the hard-to-find
5.x release.

I've also played with hylafax and iaxmodem before, but no longer have setups to
test those with.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] hasufell's extended leave and libressl

2016-01-16 Thread Joshua Kinard
On 01/16/2016 19:41, Anthony G. Basile wrote:
> Hi everyone,
> 
> I emailed Julian earlier today and asked him to come back.  He state in
> no uncertain terms that he does not intend on coming back.
> 
> Julian and I were working on the libressl project together.  He was
> doing the lion share and I contributed here and there for packages that
> I was interested in.
> 
> I just don't have time to push that project through on my own.  Mostly
> what needs to be done is the migration to the tree as described on the
> following page:
> 
> https://github.com/gentoo/libressl/wiki/Transition-plan
> 
> I'd like to solicit help in pushing this through.  Any takers?

Is the plan to just make packages in the tree compatible with libressl so that
users can choose either one, or to migrate off of openssl entirely?

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



[gentoo-dev] ncurses-5.9 -> ncurses-6.0 step-by-step?

2015-12-13 Thread Joshua Kinard
I might've missed it, but do we have a step-by-step procedure to take a rootfs
that uses ncurses-5.9 and upgrade it to ncurses-6.0 WITHOUT breaking anything?
 I, like others, ran into the problem of emerge yanking libncurses.so.5 libs
out when upgrading to ncurses-6.0, which broke bash and a few other packages.
Took some kludging but I got that fixed on my primary systems.

However I have a few chroots that need to be refreshed for catalyst runs, and I
would like to just automate the ncurses upgrade for them somehow.  I know
there's a few nucrses metapackages in the tree that facilitate this, but the
-rX numbers make it confusing as to which packages need to be merged in which
order (without causing blocks) so that the libncurses.so.[56] libs stay in
place until an 'emerge @preserved-libs' run can rebuild the packages that still
link against the old libncurses.so.5.

Thanks!,

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



[gentoo-dev] .git folder getting mirrored to rsync mirrors

2015-11-29 Thread Joshua Kinard
objects/b3/
.git/objects/b4/
.git/objects/b5/
.git/objects/b6/
.git/objects/b7/
.git/objects/b9/
.git/objects/ba/
.git/objects/bb/
.git/objects/bc/
.git/objects/bd/
.git/objects/be/
.git/objects/bf/
.git/objects/c0/
.git/objects/c1/
.git/objects/c2/
.git/objects/c3/
.git/objects/c4/
.git/objects/c5/
.git/objects/c6/
.git/objects/c8/
.git/objects/c9/
.git/objects/ca/
.git/objects/cb/
.git/objects/cc/
.git/objects/cd/
.git/objects/ce/
.git/objects/cf/
.git/objects/d0/
.git/objects/d1/
.git/objects/d2/
.git/objects/d4/
.git/objects/d5/
.git/objects/d6/
.git/objects/d7/
.git/objects/d8/
.git/objects/d9/
.git/objects/da/
.git/objects/db/
.git/objects/dc/
.git/objects/dd/
.git/objects/df/
.git/objects/e0/
.git/objects/e1/
.git/objects/e2/
.git/objects/e3/
.git/objects/e4/
.git/objects/e5/
.git/objects/e6/
.git/objects/e7/
.git/objects/e8/
.git/objects/e9/
.git/objects/ea/
.git/objects/eb/
.git/objects/ec/
.git/objects/ed/
.git/objects/ee/
.git/objects/ef/
.git/objects/f0/
.git/objects/f1/
.git/objects/f2/
.git/objects/f3/
.git/objects/f4/
.git/objects/f5/
.git/objects/f6/
.git/objects/f7/
.git/objects/f8/
.git/objects/f9/
.git/objects/fa/
.git/objects/fb/
.git/objects/fc/
.git/objects/fd/
.git/objects/fe/
.git/objects/ff/
.git/objects/info/
.git/objects/pack/
.git/refs/
.git/refs/heads/
.git/refs/remotes/
.git/refs/remotes/origin/
.git/refs/remotes/origin/dev/
.git/refs/remotes/origin/project/
.git/refs/tags/
metadata/timestamp.chk

Number of files: 205,340 (reg: 177,942, dir: 27,398)
Number of created files: 264 (dir: 264)
Number of regular files transferred: 1
Total file size: 391.32M bytes
Total transferred file size: 32 bytes
Literal data: 32 bytes
Matched data: 0 bytes
File list size: 4.20M
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 28.29K
Total bytes received: 4.83M

sent 28.29K bytes  received 4.83M bytes  277.33K bytes/sec
total size is 391.32M  speedup is 80.63
=== Sync completed for gentoo


-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] Re: tcltk herd empty

2015-10-04 Thread Joshua Kinard
On 10/04/2015 03:08, Duncan wrote:
> Dale posted on Sun, 04 Oct 2015 01:06:43 -0500 as excerpted:
> 
>> P. S.  I'm getting a error message on your OpenPGP.  I get this:
>> "Error - No valid armored OpenPGP data block found".
>> If that is caused by something on your end, may want to look into it.
> 
> That bit's easily explained -- the PGP trigger token (begin pgp 
> signed..., not duplicating it exactly here to prevent a similar problem) 
> remained in the material quoted (several levels deep, in fact) from an 
> earlier post.  Your client obviously triggered on it even embedded in the 
> quote, however, understandably rather confusing you.
> 
> You might consider filing that as a bug with SeaMonkey upstream, since 
> trying to PGP-verify within a quote is fraught with so many problems, 
> including attribution confusion if by some miracle the quoted material 
> can be correctly detected and separated from the quote markers and hasn't 
> been rewrapped or otherwise damaged, so that it actually does verify, 
> that it's not a good idea.  The problem of course is knowing that it's a 
> quote and thus not to trigger, but being a part of a multi-line block of 
> text with initial ">" markers is reasonable enough indication of it being 
> in a quote, I'd say, even if other styles of quoting aren't so accurately 
> detectable.

Probably more Enigmail upstream.  Or does Mozilla Seamonkey include PGP/GPG
functionality?  I only use the browser component of that.  Been using
Thunderbird+Enigmail for quite a long time for PGP/GPG.  enigmail is picking up
on the embedded PGP marker as well and displaying a blue bar for me on some of
the messages in this thread.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] tcltk herd empty

2015-10-03 Thread Joshua Kinard
On 10/02/2015 08:44, Dale wrote:
> Michał Górny wrote:
>> Dnia 2015-10-02, o godz. 03:38:16
>> Daniel Campbell <z...@gentoo.org> napisał(a):
>>
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA256
>>>
>>> On 09/30/2015 06:02 AM, Justin (jlec) wrote:
>>>> Hi,
>>>>
>>>> is no active maintainer for tcltk in Gentoo anymore.
>>>>
>>>> Please stand up or try to remove tcltk support from your packages.
>>>>
>>>> Justin
>>>>
>>> I know next to nothing about tcl/tk but it's been an idle curiosity of
>>> mine. Are there any particularly important packages that run on them?
>> dev-tcltk/expect is sometimes used for modem chats.
>>
>> net-im/tkabber used to be pretty good but I haven't looked at it in ages.
>>
> 
> 
> I have these that use tcl or tk:
> 
> 
> root@fireball / # equery h tk
>  * Searching for USE flag tk ...
> [IP-] [  ] app-office/scribus-1.4.4-r1:0
> [IP-] [  ] dev-lang/R-3.2.2:0
> [IP-] [  ] dev-lang/python-2.7.10:2.7
> [IP-] [  ] dev-lang/python-3.4.3:3.4
> [IP-] [  ] dev-python/pillow-2.8.1:0
> [IP-] [  ] dev-python/pyopengl-3.0.2-r1:0
> [IP-] [  ] dev-vcs/git-2.4.9:0
> [IP-] [  ] net-im/pidgin-2.10.11:0
> [IP-] [  ] sci-electronics/pcb-20140316:0
> [IP-] [  ] virtual/python-imaging-2:0
> root@fireball / # equery h tcl
>  * Searching for USE flag tcl ...
> [IP-] [  ] dev-db/sqlite-3.8.10.2:3
> [IP-] [  ] media-gfx/graphviz-2.26.3-r4:0
> [IP-] [  ] net-analyzer/rrdtool-1.5.4:0
> [IP-] [  ] net-im/pidgin-2.10.11:0
> [IP-] [  ] sys-libs/db-4.8.30-r2:4.8
> root@fireball / # 

tcl/tk support should remain if at all possible, especially in Python.  TCL is
the base language, and well-entrenched in some really niche areas, like eggdrop
bot scripting and the like.  IIRC, everything in TCL is effectively a string,
and it's very much an event-driven language via the use of "binds".

Tk is for creating cross-platform GUIs using TCL, and Python people have likely
encountered Tk as "Tkinter", Python's wrapper around Tk for creating
cross-platform Python GUIs (like gitk).

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



[gentoo-dev] Excessive rsync time after git migration

2015-08-15 Thread Joshua Kinard
This might already be covered in one of the other e-mail threads, but I've been
super-busy as of late and just recently ran 'emerge --sync' on my main dev box
for the first time after the git migration.  I just synced my main dev box
again, ~10 hours after the last sync, but it looks like the 'Manifest' files
for *every* package in the tree are getting downloaded with each sync.

I compared two Manifest files from a given package that shouldn't have changed
in the last 10 hours (sys-kernel/mips-sources), and there is nothing different
timestamp wise or content wise between then.  So I'm not sure what's causing
'emerge --sync' to re-fetch the whole file.

Has anyone else noticed this and/or have a workaround?  It's causing some
excessive disk thrashing, and what used to be a few seconds to sync is now
taking 5-10mins or more (depending on which machine I'm syncing).

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between.

--Emperor Turhan, Centauri Republic



  1   2   3   >