Re: [gentoo-dev] RFC: migration from uclibc to uclibc-ng

[waltdnes]

On Sat, Jul 16, 2016 at 01:02:42PM -0400, Anthony G. Basile wrote

> I welcome comment on any of the above.

  I don't know if this is on topic.  Is it possible to backport 64-bit
date/time to uclibc-ng in 32-bit mode?  32-bit date runs between late
1901 and early 2038.  2038 is not that far away.  E.g. in a 32-bit VM...

[g32gst1][waltdnes][~] date --date='@-2147483649'
date: invalid date '@-2147483649'
[g32gst1][waltdnes][~] date --date='@-2147483648'
Fri Dec 13 15:45:52 EST 1901
[g32gst1][waltdnes][~] date --date='@2147483647'
Mon Jan 18 22:14:07 EST 2038
[g32gst1][waltdnes][~] date --date='@2147483648'
date: invalid date '@2147483648'

  64-bit date covers beyond the heat death of the universe each way...

[i3][waltdnes][~] date --date='@-2147483649'
Fri Dec 13 15:45:51 EST 1901
[i3][waltdnes][~] date --date='@-2147483648'
Fri Dec 13 15:45:52 EST 1901
[i3][waltdnes][~] date --date='@2147483647'
Mon Jan 18 22:14:07 EST 2038
[i3][waltdnes][~] date --date='@2147483648'
Mon Jan 18 22:14:08 EST 2038

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

[gentoo-dev] RFC: migration from uclibc to uclibc-ng

[Anthony G. Basile]

Hi everyone,

Most of you know that uclibc upstream is pretty much dead.  There hasn't
been a official release since 2012 and there hasn't been a commit to
their master branch for over a year.  The situation has become
impossible since important fixes really can't be backported without
layers of intermediated fixes being backported first.  This has lead to
a fork at http://uclibc-ng.org/ which is actively maintained and has all
of the fixes we need in the latest release.

Since I don't want to just give up on Gentoo + uclibc, I'm going to
migrate to uclibc-ng.  (Parenthetically let me add that I think the real
future of embedded will be musl, but still I don't want to just give up
on uclibc.)

After migrating, I will pretty much abandon uclibc itself and continue
exclusively with uclibc-ng.  The supported arches are and will continue
to be amd64, armv7a (hard/soft float), mips32r2 (big endian), mipsel3
(little endian), ppc and i686.  The process will be as follows:

1. Build experimental stage3's with customize /etc/portage.  This is
just for testing since the final stage3's should not have anything in
/etc/portage.  This must be completed for all arches before the next step.

2. Migrate the customized /etc/portage to profiles/default/linux/uclibc
for all arches, and switch the priority in virtual/libc/libc-0.ebuild.
Currently it reads:

elibc_uclibc? ( || ( sys-libs/uclibc sys-libs/uclibc-ng ) )


3. Update https://wiki.gentoo.org/wiki/Project:Hardened_uClibc with
instructions on how to upgrade.

4. Start pushing out uclibc-ng base stages
https://www.gentoo.org/downloads/ for amd64 and i686.

I'm at step 1 for amd64 and i686.

I welcome comment on any of the above.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] Signed push & clock drift rejection

[Andrew Savchenko]

Hi,

On Fri, 15 Jul 2016 18:03:30 + Robin H. Johnson wrote:
> Hi all,
> 
> In tracing down problems with the git->rsync path, it has been noticed
> that some developers have significant clock drift on their local systems
> (up to one case of 14 days wrong), and it's potentially contributing to
> problems in generating the rsync tree.
> 
> I have implemented a check as part of the hook that validates Git push
> certificates (require-signed-push). It looks for clock drift or an
> overly long push, and aborts if needed.
> 
> The tolerances are presently set to:
> - 5 seconds of clock drift.

Why such tight requirement? Why not a minute, which will not hurt
git, but will help with system _temporarily_ out-of-sync.

Some hardware clocks are real mess and can drift more that for 5
seconds in a few days (e.g. when system was shut down). And for NTP
it will take time to correct system clock _properly_. While stuff
like running ntpdate before ntp server if system is out of sync is
possible, but it is not recommended nor possible on some workloads.
So IRL NTP may take several hours to sync system properly.

Set it for a minute or two. This will protect from commits from
really out-of-sync systems (like 14 days mentioned above) and will
keep usablity hight for others.

> - 'git push' must be completed in 60 seconds.

Why?! What is wrong if push will take 120 seconds? I often commit
from quite an old box and git push takes 20-40 seconds, while this
is within your limits, the margin is not safe.

What if someone needs to commit via 2G GPRS or similar slow network
link? Afaik we have developers on quite slow and unstable links.

Just set this limit to 5 minutes to make it a sane protection of a
stale push.

Best regards,
Andrew Savchenko


pgpfpQXlwFk3S.pgp
Description: PGP signature