Re: [gentoo-dev] New arches??

[Mike Frysinger]

On 26 Nov 2015 20:43, Andreas K. Huettel wrote:
> just curious, where did "riscv" come from
> 
> (and nios2, but that seem's to have been around for longer...)

people are testing/working on them, and adding them to the profile
makes things simpler.  whether they mature enough to start adding
to ebuilds has yet to be seen, but there's no overhead in being in
the profile.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] [RFC] ban use of base-4 casemods in ebuilds due to locale collation instability

[Mike Frysinger]

On 11 Nov 2015 08:37, Ulrich Mueller wrote:
> > On Wed, 11 Nov 2015, René Neumann wrote:
> 
> >> Shouldn't these be safe to use if the string consists purely of
> >> ASCII characters? I mean, A-Z and a-z should be uppercase and
> >> lowercase, respectively, in any locale?
> 
> > Unfortunately, no (have been bitten by this issue already some years
> > ago):
> 
> > $ echo $LC_ALL
> > tr_TR
> > $ f=i; echo ${f^^}
> > İ
> > $ f=I; echo ${f,}
> > ı
> 
> This is wrong on so many levels. :( It starts with the fact that the
> dot over the lowercase latin i historically never was a diacritical
> mark [1].
> 
> Maybe we should advise users in our documentaion that they should
> avoid such broken locales for ebuilds?

i'm not sure telling people their native language is wrong is a smart
move.  it also would seem to cut against the purpose of the PMS.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] [RFC] ban use of base-4 casemods in ebuilds due to locale collation instability

[Mike Frysinger]

On 11 Nov 2015 05:16, Ulrich Mueller wrote:
> >>>>> On Tue, 10 Nov 2015, Mike Frysinger wrote:
> 
> > Arfrever highlights these are not even safe to use.  bash is locale aware,
> > so it'll apply LC_COLLATE rules when processing the ^/, casemods.  while
> > you can fix this with external programs ala:
> > LC_COLLATE=C tr ...
> 
> > you can't do it with inline code like:
> > LC_COLLATE=C SRC_URI=".../${PN^^}/..."
> 
> >>>>> On Tue, 10 Nov 2015, Mike Frysinger wrote:
> 
> > sorry, i meant char classification here (LC_CTYPE), not collation.
> 
> Shouldn't these be safe to use if the string consists purely of ASCII
> characters? I mean, A-Z and a-z should be uppercase and lowercase,
> respectively, in any locale?

nope.  it depends on the order of the chars in the locale and assumes
the first is A and the last is Z.  which not all do.
$ echo {a..z} | LC_ALL=et_EE.UTF-8 sed 's:[a-z]::g'
   t u v w x y 

we could do something like the classic:
tolower() { tr 'abcdefghijklmnopqrstuvwxyz' 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' 
<<<"$*"; }

but that would still would not help with the bash builtins.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] [RFC] ban use of base-4 casemods in ebuilds due to locale collation instability

[Mike Frysinger]

sorry, i meant char classification here (LC_CTYPE), not collation.
i've been dealing with sorting bugs lately ;).
-mike


signature.asc
Description: Digital signature

[gentoo-dev] [RFC] ban use of base-4 casemods in ebuilds due to locale collation instability

[Mike Frysinger]

On 10 Nov 2015 18:53, Mike Frysinger wrote:
> i randomly stumbled across an ebuild that was using ^^ to make a variable
> uppercase.  this is new to bash-4.0 and thus invalid for EAPI=[0-5].  only
> the fresh EAPI=6 permits it since we bumped the min ver to bash-4.2.

Arfrever highlights these are not even safe to use.  bash is locale aware,
so it'll apply LC_COLLATE rules when processing the ^/, casemods.  while
you can fix this with external programs ala:
LC_COLLATE=C tr ...

you can't do it with inline code like:
LC_COLLATE=C SRC_URI=".../${PN^^}/..."

you can if you do something like:
SRC_URI=".../$(LC_COLLATE=C; echo "${PN^^}")/..."

but at this point, you lose most (all?) advantage to using these in the first
place: nice & tight code.  not running tr in global scope is nice too, but it's
better all around to just hardcode something like:
MY_PN="APINGER"
and be done with it.

thoughts ?  we could add a repoman check to detect & reject usage of it, and
for the cases where the value isn't a constant, we could add a safe helper to
eutils like:
tolower() { LC_COLLATE=C tr '[:upper:]' '[:lower:]'; }
toupper() { LC_COLLATE=C tr '[:lower:]' '[:upper:]'; }

yes, i'm aware that this runs the risk of mojibake when given some UTF-8
strings, but we already have that problem, and i don't think the uses so
far will hit it (as people generally feed USE flags and PN values).  it
would require the C.UTF-8 locale to address.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] reminder: you cannot use bash-4.x features (e.g. ${var^^}) in EAPI=[0-5]

[Mike Frysinger]

On 10 Nov 2015 18:53, Mike Frysinger wrote:
> i randomly stumbled across an ebuild that was using ^^ to make a variable
> uppercase.  this is new to bash-4.0 and thus invalid for EAPI=[0-5].  only
> the fresh EAPI=6 permits it since we bumped the min ver to bash-4.2.

fixed the ones `git grep` turned up, albeit lightly tested

 app-admin/yaala/yaala-0.7.3-r1.ebuild| 21 -
 app-office/calligra/calligra-2.9.6.ebuild|  5 -
 app-office/calligra/calligra-2.9.7.ebuild|  5 -
 app-office/calligra/calligra-.ebuild |  5 -
 app-text/searchmonkey/searchmonkey-2.0.0.ebuild  |  5 +++--
 dev-db/SchemaSync/SchemaSync-0.9.2.ebuild|  6 --
 dev-java/groovy/groovy-2.4.5.ebuild  |  4 +++-
 dev-python/SchemaObject/SchemaObject-0.5.3.ebuild|  6 --
 dev-python/cvxopt/cvxopt-1.1.6-r2.ebuild |  8 ++--
 dev-scheme/gauche-gl/gauche-gl-0.5.1.ebuild  |  5 +++--
 dev-scheme/gauche-gl/gauche-gl-0.6.ebuild|  5 +++--
 dev-scheme/gauche/gauche-0.9.3.3.ebuild  |  5 +++--
 dev-scheme/gauche/gauche-0.9.4-r1.ebuild |  3 ++-
 dev-vcs/cssc/cssc-1.4.0.ebuild   | 11 ---
 eclass/cvs.eclass|  4 ++--
 games-board/gambit/gambit-1.0.1.ebuild   | 12 
 games-board/gambit/gambit-1.0.3.ebuild   | 12 
 games-fps/xonotic/xonotic-0.8.0.ebuild   |  3 ++-
 games-fps/xonotic/xonotic-0.8.1.ebuild   |  5 +++--
 media-sound/clementine/clementine-1.2.2.ebuild   |  3 ++-
 media-sound/clementine/clementine-1.2.3.ebuild   |  3 ++-
 media-sound/clementine/clementine-.ebuild|  3 ++-
 net-analyzer/apinger/apinger-0.4.1.ebuild|  9 +++--
 net-dns/dnsmasq/dnsmasq-2.66.ebuild  |  6 --
 net-dns/dnsmasq/dnsmasq-2.72-r2.ebuild   |  4 +++-
 net-dns/dnsmasq/dnsmasq-2.75.ebuild  |  4 +++-
 sci-mathematics/sha1-polyml/sha1-polyml-5.5.0.ebuild | 10 ++
 sys-devel/byfl/byfl-1.4.ebuild   |  3 ++-
 sys-devel/byfl/byfl-.ebuild  |  3 ++-

http://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2347c6fe886c6b89d93ffac0faf375a613c372b1
-mike


signature.asc
Description: Digital signature

[gentoo-dev] reminder: you cannot use bash-4.x features (e.g. ${var^^}) in EAPI=[0-5]

[Mike Frysinger]

i randomly stumbled across an ebuild that was using ^^ to make a variable
uppercase.  this is new to bash-4.0 and thus invalid for EAPI=[0-5].  only
the fresh EAPI=6 permits it since we bumped the min ver to bash-4.2.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Mike Frysinger]

On 31 Oct 2015 09:08, Michał Górny wrote:
> On Sat, 31 Oct 2015 03:06:21 -0400 Mike Frysinger wrote:
> > On 30 Oct 2015 18:20, Michał Górny wrote:
> > > On Fri, 30 Oct 2015 12:03:59 + (UTC) "Justin Lecher" wrote:  
> > > > --- a/eclass/distutils-r1.eclass
> > > > +++ b/eclass/distutils-r1.eclass
> > > > @@ -322,8 +322,7 @@ distutils-r1_python_prepare_all() {
> > > >  
> > > > _distutils-r1_disable_ez_setup
> > > >  
> > > > -   if [[ ${DISTUTILS_IN_SOURCE_BUILD} && ! 
> > > > ${DISTUTILS_SINGLE_IMPL} ]]
> > > > -   then
> > > > +   if [[ ${DISTUTILS_IN_SOURCE_BUILD} && ! 
> > > > ${DISTUTILS_SINGLE_IMPL} ]]; then  
> > > 
> > > This was intentionally wrapped to stay within 72-column line width. Not
> > > saying the eclass is perfect in keeping text width, especially with
> > > others committing random changes to it, but that's no reason to
> > > introduce further offenders.  
> > 
> > Gentoo has never had a hard 80-col rule let alone 72-cols.  forcing a wrap
> > here makes no sense and the new version is an improvement.
> 
> For years, Gentoo was unable to make *any* *sane* *global* rules. Which
> doesn't mean everything needs to be as crappy as the overall Gentoo
> 'quality'.

you forgot "imo".  we've had commonly accepted standards that people generally
kept to, some of which were more fuzzy than others.  but we've never had a hard
80 col rule and claiming that 72 col is an improvement is pretty hard to
swallow.  there's no reasonable argument for such minimal restrictions in
todays's world, and "it's always been that way" doesn't fly.

> So what's this improvement exactly? 'I like this style better, so it's
> an improvement'? As I see it, it's a pointless, changing-nothing-really
> commit that causes huge cache regen for no good reason except someone's
> fancy.

one thing that has been consistent is cuddling of the initial command.  we do
not write:
if foo
then
for x in 1 2 3
do
while true
do
we have always written:
if foo ; then
for x in 1 2 3 ; do
while true ; do

as for "why consistency", i think your e-mail is a bit confused here.  one on
hand you beoman lack of official hard style rules while on the other claiming
that none exist and being inconsistent is fine.

as for cache regen due to changed eclasses, meh, that happens every day, and for
eclasses more widely used than this.  it's a non-issue considering the caches
are generated on servers and distributed to users.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Mike Frysinger]

On 30 Oct 2015 18:20, Michał Górny wrote:
> On Fri, 30 Oct 2015 12:03:59 + (UTC) "Justin Lecher" wrote:
> > commit: df8e399c9bac2dc30d7cf69c2462a81729a3ae69
> > Author: Justin Lecher  gentoo  org>
> > AuthorDate: Fri Oct 30 10:18:05 2015 +
> > Commit: Justin Lecher  gentoo  org>
> > CommitDate: Fri Oct 30 12:03:49 2015 +
> > URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=df8e399c
> > 
> > eclass: Use consistent place for then in if clause
> 
> Excuse me but who are you exactly to take a random eclass and commit
> random style changes inside without even bothering to contact
> the author?

your attitude is wrong and is a great example of why people in the project
are hesitant to touch anything anymore

> > Signed-off-by: Justin Lecher  gentoo.org>
> > 
> >  eclass/distutils-r1.eclass | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> > 
> > diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
> > index 185dd4f..dbd27a7 100644
> > --- a/eclass/distutils-r1.eclass
> > +++ b/eclass/distutils-r1.eclass
> > @@ -322,8 +322,7 @@ distutils-r1_python_prepare_all() {
> >  
> > _distutils-r1_disable_ez_setup
> >  
> > -   if [[ ${DISTUTILS_IN_SOURCE_BUILD} && ! ${DISTUTILS_SINGLE_IMPL} ]]
> > -   then
> > +   if [[ ${DISTUTILS_IN_SOURCE_BUILD} && ! ${DISTUTILS_SINGLE_IMPL} ]]; 
> > then
> 
> This was intentionally wrapped to stay within 72-column line width. Not
> saying the eclass is perfect in keeping text width, especially with
> others committing random changes to it, but that's no reason to
> introduce further offenders.

Gentoo has never had a hard 80-col rule let alone 72-cols.  forcing a wrap
here makes no sense and the new version is an improvement.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] moving gcc-5.2 to unstable

[Mike Frysinger]

On 01 Oct 2015 09:49, Mike Frysinger wrote:
> what do people want to have in place before we move gcc-5.2 into ~arch ?

i want to fix these two bugs (or at least get a better handle on them).
they're related to graphite/ISL, so they don't impact most people.
https://bugs.gentoo.org/555684
https://bugs.gentoo.org/560904
hopefully i should get to them in the next week

any other 11th hour reports ?
-mike


signature.asc
Description: Digital signature

[gentoo-dev] Re: [PATCH] Recommend setting the bash compatibility level. (was: Re: utilizing BASH_COMPAT to smooth upgrades)

[Mike Frysinger]

On 22 Oct 2015 17:00, Ulrich Mueller wrote:
> >>>>> On Thu, 22 Oct 2015, Mike Frysinger wrote:
> > On 21 Oct 2015 09:34, Ulrich Mueller wrote:
> >> "The interpreter is assumed to be GNU bash, version as listed in
> >> table xyz, or any later version. If possible, the package manager
> >> should set the shell's compatibility level to the exact version
> >> specified. It must ensure that any such compatibility settings
> >> (e.g. the BASH_COMPAT variable) are not exported to external
> >> programs."
> 
> > why not include the shell script snippet too ?
> 
> I'd rather not. BASH_COMPAT doesn't work with  use compatXX there) and also we don't know if the method won't change
> again in future versions of bash.

Chet seemed pretty intent on BASH_COMPAT sticking around and being
the future while the compat options are being killed off

imo, we should have more code snippets in PMS like this to assist people
implementing PMs.  it would be noise though for people who just want the
spec reference (with a focus on ebuilds), so maybe we need a knob to output
these things ?  i've read specs where various snippets/asides/remarks are
inlined and it really helps to clarify thinking/intentions.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] gcc-5 news item wrt C++ ABI

[Mike Frysinger]

i've pushed the news item now since there hasn't been any actionable
feedback since.  it can always be refined based on user feedback.
-mike


signature.asc
Description: Digital signature

[gentoo-dev] Re: [PATCH] Recommend setting the bash compatibility level. (was: Re: utilizing BASH_COMPAT to smooth upgrades)

[Mike Frysinger]

On 21 Oct 2015 09:34, Ulrich Mueller wrote:
> >>>>> On Tue, 20 Oct 2015, Mike Frysinger wrote:
> > On 21 Oct 2015 00:03, Ulrich Mueller wrote:
> >> Therefore I'd make it a recommendation at most. Something along the
> >> lines of: "The interpreter is assumed to be GNU bash, version as
> >> listed in table xyz, or any later version. If possible, the package
> >> manager should set the shell's compatibility level to the exact
> >> version specified."
> 
> > and include the recommended snippet as well as add a warning about
> > not exporting the variable less it break external shell scripts.
> 
> "The interpreter is assumed to be GNU bash, version as listed in table
> xyz, or any later version. If possible, the package manager should set
> the shell's compatibility level to the exact version specified. It
> must ensure that any such compatibility settings (e.g. the BASH_COMPAT
> variable) are not exported to external programs."

why not include the shell script snippet too ?
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] utilizing BASH_COMPAT to smooth upgrades

[Mike Frysinger]

On 21 Oct 2015 00:03, Ulrich Mueller wrote:
> >>>>> On Tue, 20 Oct 2015, Mike Frysinger wrote:
> 
> >> EAPI 6: Bash version is 4.2.
> 
> > do we want to mandate the BASH_COMPAT aspect in PMS ?
> > or at least make into a recommendation ?
> 
> If I understand [1] correctly, coverage of BASH_COMPAT is incomplete:
> It only changes incompatible behaviour back to the old version, but it
> won't disallow using new features.

correct.  it would help when code changes behavior like when =~ changed quoting
behavior and we had to scramble to tweak its usage throughout the tree (although
it was more external programs than eclasses/ebuilds).  but if you're running
bash-4.3, setting BASH_COMPAT=4.2 would not keep code from using things like
${VAR^^}.

> Therefore I'd make it a recommendation at most. Something along the
> lines of: "The interpreter is assumed to be GNU bash, version as
> listed in table xyz, or any later version. If possible, the package
> manager should set the shell's compatibility level to the exact
> version specified."

and include the recommended snippet as well as add a warning about not exporting
the variable less it break external shell scripts.

> > https://bugs.gentoo.org/431340#c20
> >   local maj=4 min=2
> >   if ([[ ${BASH_VERSINFO[0]} -lt ${maj} ]] ||
> >   [[ ${BASH_VERSINFO[0]} -eq ${maj} && ${BASH_VERSINFO[1]} -lt ${min 
> > ]]) ; then
> 
> Why the subshell here?

it can be dropped.  was purely for grouping/line wrapping, but || gets you that.
-mike


signature.asc
Description: Digital signature

[gentoo-dev] utilizing BASH_COMPAT to smooth upgrades

[Mike Frysinger]

On 16 Oct 2015 20:42, Ulrich Mueller wrote:
>   EAPI 6: Bash version is 4.2.

do we want to mandate the BASH_COMPAT aspect in PMS ?
or at least make into a recommendation ?

https://bugs.gentoo.org/431340#c20
  local maj=4 min=2
  if ([[ ${BASH_VERSINFO[0]} -lt ${maj} ]] ||
  [[ ${BASH_VERSINFO[0]} -eq ${maj} && ${BASH_VERSINFO[1]} -lt ${min ]]) ; 
then
die ">=bash-${maj}.${min} is required"
  fi
  BASH_COMPAT="${maj}.${min}"
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] gcc-5 news item wrt C++ ABI

[Mike Frysinger]

On 03 Oct 2015 19:53, Anthony G. Basile wrote:
> On 10/3/15 7:16 PM, hasufell wrote:
> > On 10/03/2015 04:13 AM, Mike Frysinger wrote:
> >> Title: GCC 5 Defaults to the New C++11 ABI
> >> Author: Mike Frysinger 
> >> Content-Type: text/plain
> >> Posted: 2015-10-02
> >> Revision: 1
> >> News-Item-Format: 1.0
> >> Display-If-Installed: >=sys-devel/gcc-5
> >>
> >> GCC 5 uses the new C++ ABI by default.  When building new code, you might 
> >> run
> >> into link time errors like:
> >> ...: undefined reference to 
> >> '_ZNSt6chrono12steady_clock3nowEv@GLIBCXX_3.4.17'
> >> Or you might see linkage failures with "std::__cxx11::string" in the 
> >> output.
> >>
> >> These are signs that you need to rebuild packages using the new C++ ABI.
> >> You can quickly do so by using revdep-rebuild like so:
> >> # revdep-rebuild --library 'libstdc\+\+\.so\.6'
> >>
> > We shouldn't assume a particular PM/toolset in news items, IMO. Just
> > saying that people might have to rebuild packages linked against
> > libstdc++.so.6 should be enough.
> >
> > They can read the docs if they don't know how.
> 
> Nothing precludes adding "see  if you use paludis or clang." 
> However, I'd like to see the above in there.

what is the alternative suggestion for paludis ?

wrt clang, i thought we were using gcc's libstdc++ and not the libc++ project.
if people are using libc++ & clang, then this news entry does not change ...
you'd still need to rebuild anything using libstdc++.  that said, i'm not sure
libc++ & clang builds are common enough to warrant mentioning here.
-mike


signature.asc
Description: Digital signature

[gentoo-dev] glibc-2.22 now in ~arch

[Mike Frysinger]

the masked testing has been pretty stable, so i've bumped 2.22-r1 into ~arch
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] ironing out release tarballs

[Mike Frysinger]

On 15 Oct 2015 12:15, Zac Medico wrote:
> On 10/15/2015 08:34 AM, Mike Frysinger wrote:
> > background:
> > everyone wants @system to be slim, but most people want the initial stage
> > tarball that we release and you install Gentoo from to not be completely
> > sparse.  we've got a bug for this topic:
> > https://bugs.gentoo.org/393445
> > 
> > items to sort out:
> > - should the list of packages be in catalyst or profile-stacked content
> > -> imo it should be entirely in the profile
> > 
> > - should the packages list be in a new packages.default, or should we 
> > create a
> >   new set to hold it, or should we just go with @profile ?
> > -> @profile has the advantage of already existing.  we have to be careful 
> > so as
> >to make it difficult to uninstall packages that the user does not 
> > actually
> >want.
> 
> In portage, the current meaning of @profile is very similar to @system,
> except that it implies that members specify dependencies completely
> (allowing for optimal parallelization) [1]. The @profile set is only
> enabled for profiles from repositories that have "profile-formats =
> profile-set" set in metadata/layout.conf. It's an extension which is not
> covered by PMS.

layout.conf isn't covered by PMS, nor are sets, and packages file format is
compatible with PMS.  so i think we are OK here.

> > - if the packages aren't in @profile, should they be seeded in @world ?
> > -> imo yes as  we don't want all the default packages getting depcleaned as
> >soon as you start using the new install.  if they're in @profile, then 
> > this
> >is a moot point (assuming depclean does not clean out @profile).
> 
> In portage, @world = @profile + @selected + @system, which means that
> @profile is protected from depclean since it's a part of @world.

so if iputils is in @profile, and i do:
emerge -C iputils
i don't get the ugly warning about it being in @system, but if i do:
emerge @world
iputils comes back.  i think that's OK actually since people can do:
emerge @selected
which has the classic @world meaning.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] ironing out release tarballs

[Mike Frysinger]

On 15 Oct 2015 19:01, Alexis Ballier wrote:
> On Thu, 15 Oct 2015 11:34:22 -0400 Mike Frysinger wrote:
> > - should the packages list be in a new packages.default, or should we
> > create a new set to hold it, or should we just go with @profile ?
> > -> @profile has the advantage of already existing.  we have to be
> > careful so as to make it difficult to uninstall packages that the
> > user does not actually want.
> > 
> > - if the packages aren't in @profile, should they be seeded in
> > @world ? -> imo yes as  we don't want all the default packages
> > getting depcleaned as soon as you start using the new install.  if
> > they're in @profile, then this is a moot point (assuming depclean
> > does not clean out @profile).
> 
> some kind of 'world' file in profiles like the 'packages' one that is
> just used to populate world file after (or just before) stage3 build ?

i suggested the name "packages.default" originally to convey the notion
that it's just the default set of packages (you'd find in a release).
keeping the "packages." prefix seemed to be better namespace wise.

doesn't require a PMS update because only releng tools (catalyst) would
read it.  set integration would have to conform to PMS.

> not sure if sets provide the same flexibility: i can imagine iputils in
> that set, but also another embedded profile with
> busybox[make-symlinks], or the bsds

i'm not sure putting USE flag qualifiers makes sense as the next time the
package updates, the USE flags will change.  if profiles want to default
USE flags, the existing package.use makes more sense imo.
-mike


signature.asc
Description: Digital signature

[gentoo-dev] ironing out release tarballs

[Mike Frysinger]

background:
everyone wants @system to be slim, but most people want the initial stage
tarball that we release and you install Gentoo from to not be completely
sparse.  we've got a bug for this topic:
https://bugs.gentoo.org/393445

items to sort out:
- should the list of packages be in catalyst or profile-stacked content
-> imo it should be entirely in the profile

- should the packages list be in a new packages.default, or should we create a
  new set to hold it, or should we just go with @profile ?
-> @profile has the advantage of already existing.  we have to be careful so as
   to make it difficult to uninstall packages that the user does not actually
   want.

- if the packages aren't in @profile, should they be seeded in @world ?
-> imo yes as  we don't want all the default packages getting depcleaned as
   soon as you start using the new install.  if they're in @profile, then this
   is a moot point (assuming depclean does not clean out @profile).

- should stage3 be @system only, or @system+@profile, or 
  @system+@profile+packages.default ?
-> this depends on the previous discussion a bit.  today, stage3's are 
   @system, but imo @system+@profile is reasonable.  see next question too.

- should we release stage4's instead of stage3's ?
-> if we keep stage3 as @system-only, then we'd build stage4's which would add
   @profile/whatever
-> downside is that we've been training the world to download & install stage3
   for almost 15 years
-> imo as long as the default @profile is kept slim, adjusting the definition of
   a stage3 is OK
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] [rfc] drop iputils from @system (i.e. ping)

[Mike Frysinger]

i will drop iputils from @system:
https://bugs.gentoo.org/563148

but not until our releases are sorted out:
https://bugs.gentoo.org/393445

and i'll see if we can't get that sorted out sooner rather than later
-mike


signature.asc
Description: Digital signature

[gentoo-dev] [rfc] enable USE=xattr by default

[Mike Frysinger]

USE=xattr is needed nowadays to support:
- filesystem caps (those things that let you drop set*id and generally
  improves system security w/little to no runtime overhead)
- PaX file markings (replaces binutils ELF markings)
- selinux

we actually have USE=filecaps on by default already, and catalyst
hard requires tar[xattr] in order to work.  the hardened profile
also package.use.force's this flag on for some core packages.

not too many packages actually utilize this flag, and when they do,
it's to pull in the attr package which clocks in at <200 KiB.  the
runtime overhead tends to be low to non-existent as xattrs tend to
be used only when requested.

when support is not available in the FS or kernel, packages should
generally fall back gracefully.

anyone opposed to flipping this flag on by default ?

reference:
https://bugs.gentoo.org/506198
https://bugs.gentoo.org/556408
-mike


signature.asc
Description: Digital signature

[gentoo-dev] [rfc] drop iputils from @system (i.e. ping)

[Mike Frysinger]

iputils is currently in @system for everyone.  by default, it only
installs `ping`.  do we feel strongly enough about this to require
all systems include it ?  or should this wait for the long idea of
releasing stage4's instead of stage3's ?
-mike


signature.asc
Description: Digital signature

[gentoo-dev] Re: [PATCH] autotools.eclass: support AM_GNU_GETTEXT_REQUIRE_VERSION

[Mike Frysinger]

On 13 Oct 2015 18:25, Michał Górny wrote:
> gettext 0.19.6 supports AM_GNU_GETTEXT_REQUIRE_VERSION in addition to
> AM_GNU_GETTEXT_VERSION.

ok, although not entirely correct -- gettexize supports this, but autoreconf
does not.  we also send a patch to the autoconf project to update things.

> // proxying this patch for Michał Bartoszkiewicz

you should fix the --author of your commit then
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] gcc-5 news item wrt C++ ABI

[Mike Frysinger]

On 04 Oct 2015 01:16, hasufell wrote:
> On 10/03/2015 04:13 AM, Mike Frysinger wrote:
> > Title: GCC 5 Defaults to the New C++11 ABI 
> > Author: Mike Frysinger 
> > Content-Type: text/plain
> > Posted: 2015-10-02
> > Revision: 1
> > News-Item-Format: 1.0
> > Display-If-Installed: >=sys-devel/gcc-5
> > 
> > GCC 5 uses the new C++ ABI by default.  When building new code, you might 
> > run
> > into link time errors like:
> > ...: undefined reference to 
> > '_ZNSt6chrono12steady_clock3nowEv@GLIBCXX_3.4.17'
> > Or you might see linkage failures with "std::__cxx11::string" in the output.
> > 
> > These are signs that you need to rebuild packages using the new C++ ABI.
> > You can quickly do so by using revdep-rebuild like so:
> > # revdep-rebuild --library 'libstdc\+\+\.so\.6'
> 
> We shouldn't assume a particular PM/toolset in news items, IMO. Just
> saying that people might have to rebuild packages linked against
> libstdc++.so.6 should be enough.

there's no requirement for you to use revdep-rebuild.  including quick
insns for the common case is a no brainer really.

> They can read the docs if they don't know how.

and they can if the common case doesn't work for them.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] gcc-5 news item wrt C++ ABI

[Mike Frysinger]

On 05 Oct 2015 20:45, Paweł Hajdan, Jr. wrote:
> On 10/3/15 4:13 AM, Mike Frysinger wrote:
> > Title: GCC 5 Defaults to the New C++11 ABI 
> > Author: Mike Frysinger 
> > Content-Type: text/plain
> > Posted: 2015-10-02
> > Revision: 1
> > News-Item-Format: 1.0
> > Display-If-Installed: >=sys-devel/gcc-5
> > 
> > GCC 5 uses the new C++ ABI by default.  When building new code, you might 
> > run
> > into link time errors like:
> > ...: undefined reference to 
> > '_ZNSt6chrono12steady_clock3nowEv@GLIBCXX_3.4.17'
> > Or you might see linkage failures with "std::__cxx11::string" in the output.
> > 
> > These are signs that you need to rebuild packages using the new C++ ABI.
> > You can quickly do so by using revdep-rebuild like so:
> > # revdep-rebuild --library 'libstdc\+\+\.so\.6'
> > 
> > For more details, feel free to peruse:
> > https://developerblog.redhat.com/2015/02/05/gcc5-and-the-c11-abi/
> > https://blogs.gentoo.org/blueness/2015/03/10/the-c11-abi-incompatibility-problem-in-gentoo/
> 
> Curious, can one reasonably easy downgrade from GCC 5 back to GCC 4?
> 
> Are there any instructions for that? Is it sufficient to do a similar
> revdep-rebuild command?
> 
> In case the downgrade would horribly break systems or be otherwise
> highly nontrivial, I'd recommend some note for that.

it's like any other attempt to downgrade an ABI: you're on your own.
in Gentoo, we guarantee backwards compatibility, not forward -- this
is not specific to GCC.

in practice, as long as you don't unmerge gcc-5, you can switch the
active compiler to gcc-4.9 and use it, but the runtime libs will be
taken from the latest one you have installed (gcc-5).
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] gcc-5 news item wrt C++ ABI

[Mike Frysinger]

On 03 Oct 2015 18:30, Ciaran McCreesh wrote:
> On Sat, 3 Oct 2015 13:24:11 -0400 Mike Frysinger wrote:
> > On 03 Oct 2015 13:38, Ciaran McCreesh wrote:
> > > On Fri, 2 Oct 2015 22:13:09 -0400 Mike Frysinger wrote:
> > > > Display-If-Installed: >=sys-devel/gcc-5
> > > 
> > > This means that two years from now, when stages are built using GCC
> > > 5, every new user will get this news item shown to them.
> > 
> > multiple news items already use this syntax
> 
> Yes, and they cause problems. Do you want to cause another problem, or
> do you want to think more carefully about who should see the news item?

i see no reason to hold things up when the issue won't show up for over a
year, can be retroactively fixed, and really makes no difference to the
status quo.  so if you had actual thoughts on improving things (rather
than pointless rhetorical questions), feel free to post them.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] gcc-5 news item wrt C++ ABI

[Mike Frysinger]

On 03 Oct 2015 13:38, Ciaran McCreesh wrote:
> On Fri, 2 Oct 2015 22:13:09 -0400 Mike Frysinger wrote:
> > Display-If-Installed: >=sys-devel/gcc-5
> 
> This means that two years from now, when stages are built using GCC 5,
> every new user will get this news item shown to them.

multiple news items already use this syntax
-mike


signature.asc
Description: Digital signature

[gentoo-dev] gcc-5 news item wrt C++ ABI

[Mike Frysinger]

Title: GCC 5 Defaults to the New C++11 ABI 
Author: Mike Frysinger 
Content-Type: text/plain
Posted: 2015-10-02
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: >=sys-devel/gcc-5

GCC 5 uses the new C++ ABI by default.  When building new code, you might run
into link time errors like:
...: undefined reference to '_ZNSt6chrono12steady_clock3nowEv@GLIBCXX_3.4.17'
Or you might see linkage failures with "std::__cxx11::string" in the output.

These are signs that you need to rebuild packages using the new C++ ABI.
You can quickly do so by using revdep-rebuild like so:
# revdep-rebuild --library 'libstdc\+\+\.so\.6'

For more details, feel free to peruse:
https://developerblog.redhat.com/2015/02/05/gcc5-and-the-c11-abi/
https://blogs.gentoo.org/blueness/2015/03/10/the-c11-abi-incompatibility-problem-in-gentoo/


signature.asc
Description: Digital signature

Re: [gentoo-dev] Re: moving gcc-5.2 to unstable

[Mike Frysinger]

On 02 Oct 2015 02:21, Ryan Hill wrote:
> IMO these should be fixed before we unmask:
> 
>546742: x11-apps/sessreg-1.1.0 fail to build with gcc5
>547626: dev-lang/python-3.3 / 3.4 test_faulthandler hangs with GCC 5.1
>547950: app-shells/zsh-5.0.7-r2 builds but has runtime errors with GCC 5

done

>555866: media-libs/phonon-4.8.3-r1[qt5] fails to build with gcc-5

it already has a patch that's been merged upstream, so just waiting on the kde
guys to actually merge it.  i don't think we need to block gcc-5 unmasking on it
if it's not going to get merged any time soon.

also it relies on USE=qt5 (my qt4 builds are fine).  not sure the distribution
of those flags in practice.

> > the only glaring issue is the C++11 ABI breakage:
> > https://bugs.gentoo.org/542482
> > 
> > we already posted a news item when the breakage started in gcc-4.7:
> > 
> > https://archives.gentoo.org/gentoo-dev/message/4fa0c84858b4df49668da20302fc5b6f
> > 
> > but since gcc-5.x makes this the new default standard, more people are going
> > to run into it, so we probably want a reminder.  do we want any sort of
> > automation otherwise here ?
> 
> I think we need a news item to remind people they really do have to emerge -e
> @world after this one or they could have a bad time.

feel like writing it ? ;)

> FWIW I updated one system from 4.9 to 5.2 by rebuilding ~700 packages in 
> random
> order just to see how bad the ABI breakage would be and only ran into it once.
> I may have just gotten lucky though.

i upgraded gradually and it wasn't that much of a hassle, but it helps to know
how to read the failing logs/symbols.  so an empty world would be OK.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] binutils-libs: new package for binutils libs

[Mike Frysinger]

On 01 Oct 2015 22:24, Michał Górny wrote:
> Dnia 2015-10-01, o godz. 16:15:32 Mike Frysinger napisał(a):
> > On 01 Oct 2015 21:10, Michał Górny wrote:
> > > Dnia 2015-09-29, o godz. 10:21:14 Mike Frysinger napisał(a):
> > > > if your package depended on binutils because you wanted to link against
> > > > libbfd or libopcodes, or you omitted the dep entirely (because you 
> > > > didn't
> > > > notice?), there's a new package you should convert to using:
> > > > sys-libs/binutils-libs
> > > 
> > > What about packages building binutils plugins? Should them be using
> > > binutils-libs too, or somehow binding to a specific binutils version?
> > 
> > the only thing you need is the header file right ?  binutils-libs provides
> > those.  if you need something else, you'll need to provide concrete details.
> 
> Yes. But shouldn't I be concerned about potential ABI mismatch between
> binutils-libs and the active linker?

probably, but that's already the case today.  i don't think binutils-libs
changes the status quo.  something to think about in:
https://bugs.gentoo.org/494228
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] binutils-libs: new package for binutils libs

[Mike Frysinger]

On 01 Oct 2015 21:10, Michał Górny wrote:
> Dnia 2015-09-29, o godz. 10:21:14 Mike Frysinger napisał(a):
> > if your package depended on binutils because you wanted to link against
> > libbfd or libopcodes, or you omitted the dep entirely (because you didn't
> > notice?), there's a new package you should convert to using:
> > sys-libs/binutils-libs
> 
> What about packages building binutils plugins? Should them be using
> binutils-libs too, or somehow binding to a specific binutils version?

the only thing you need is the header file right ?  binutils-libs provides
those.  if you need something else, you'll need to provide concrete details.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] moving gcc-5.2 to unstable

[Mike Frysinger]

On 01 Oct 2015 10:11, Alexandre Rostovtsev wrote:
> On Thu, 2015-10-01 at 09:49 -0400, Mike Frysinger wrote:
> > what do people want to have in place before we move gcc-5.2 into ~arch ?
> 
> For one thing, the fix for runtime failure in 64-bit wine:
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66838
> https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=225935

did you file a bug for toolchain@ ?  i'm not seeing one.
changes don't go in w/out a bug on our side.
-mike


signature.asc
Description: Digital signature

[gentoo-dev] moving gcc-5.2 to unstable

[Mike Frysinger]

what do people want to have in place before we move gcc-5.2 into ~arch ?

the general list looks pretty good:
https://bugs.gentoo.org/536984

the only glaring issue is the C++11 ABI breakage:
https://bugs.gentoo.org/542482

we already posted a news item when the breakage started in gcc-4.7:

https://archives.gentoo.org/gentoo-dev/message/4fa0c84858b4df49668da20302fc5b6f

but since gcc-5.x makes this the new default standard, more people are going to
run into it, so we probably want a reminder.  do we want any sort of automation
otherwise here ?
-mike


signature.asc
Description: Digital signature

[gentoo-dev] gcc-4.9.3 going stable

[Mike Frysinger]

gcc-4.9.3 is stabilizing:
https://bugs.gentoo.org/561844
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] binutils-libs: new package for binutils libs

[Mike Frysinger]

On 29 Sep 2015 19:54, Andrew Savchenko wrote:
> On Tue, 29 Sep 2015 10:21:14 -0400 Mike Frysinger wrote:
> > if your package depended on binutils because you wanted to link against
> > libbfd or libopcodes, or you omitted the dep entirely (because you didn't
> > notice?), there's a new package you should convert to using:
> > sys-libs/binutils-libs
> > 
> > this supports subslots & multilib and is sane to depend on unlike binutils
> > where you can have multiple versions installed or active versions selected.
> 
> What about stable packages? Since binutils-2.25.1-r1 is stable,
> binutils-libs-2.25.1 should be stabilized as well and I have a
> package which needs this (dev-util/oprofile).

there's no real reason to accelerate stabilization.  stable binutils (well
binutils-config to be exact) continues to provide the libs/headers and will
do so until everything is ready to go stable.
-mike


signature.asc
Description: Digital signature

[gentoo-dev] binutils-libs: new package for binutils libs

[Mike Frysinger]

if your package depended on binutils because you wanted to link against
libbfd or libopcodes, or you omitted the dep entirely (because you didn't
notice?), there's a new package you should convert to using:
sys-libs/binutils-libs

this supports subslots & multilib and is sane to depend on unlike binutils
where you can have multiple versions installed or active versions selected.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Introduce ppc64le architecture into gentoo ! please share your comments

[Mike Frysinger]

On 25 Sep 2015 10:32, Leno Hou wrote:
> On Thu, Sep 24, 2015 at 11:07 PM, Mike Frysinger wrote:
> > On 14 Aug 2015 15:52, Leno Hou wrote:
> > > On Wed, Aug 12, 2015 at 3:47 PM, Mike Frysinger wrote:
> > > > On 12 Aug 2015 15:20, Leno Hou wrote:
> > > > > **Most importantly, Any Ideas/steps of how to  porting gentoo on
> > > > > ppc64le architecture?**
> > > >
> > > > do you have hardware ?  then it's simply a matter of booting Gentoo in
> > > > it and filing/fixing bugs :).
> > >
> > > YES. We have KVM virtual machine of ppc64le.  Can we
> > > booting/filing/fixing by KVM ?
> >
> > KVM is fine.  i'm assuming you can't boot a ppc64le vm when the host is
> > ppc64be ?
> 
> We can boot ppc64le by KVM on POWER7  (abbrev. PowerKVM)
> and KVM on Power7 is big endian. If you have real POWER7 hardware,

we have a Gentoo box running on a POWER7 from IBM:
IBM,8231-E2B POWER7 32 x 3.5GHz

it has KVM enabled in it.  so i guess we should be able to start a LE
instance in KVM there.

> you can install Ubuntu or RedHat ( integrated with KVM by default) on
> POWER7.

are you really making this suggestion on a Gentoo list ? ;)
booting other distros isn't generally interesting to us.
don't you already have a Gentoo instance booting ?
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Introduce ppc64le architecture into gentoo ! please share your comments

[Mike Frysinger]

On 14 Aug 2015 15:52, Leno Hou wrote:
> On Wed, Aug 12, 2015 at 3:47 PM, Mike Frysinger wrote:
> > On 12 Aug 2015 15:20, Leno Hou wrote:
> > > **Most importantly, Any Ideas/steps of how to  porting gentoo on  ppc64le
> > > architecture?**
> >
> > do you have hardware ?  then it's simply a matter of booting Gentoo in it
> > and
> > filing/fixing bugs :).
> >
> 
> YES. We have KVM virtual machine of ppc64le.  Can we booting/filing/fixing
> by KVM ?

KVM is fine.  i'm assuming you can't boot a ppc64le vm when the host is
ppc64be ?  i don't think any Gentoo dev has access to ppc64le hardware,
so we'd rely on ibm to fix bugs and such.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] git history older than "proj/gentoo: Initial commit" (56bd759)

[Mike Frysinger]

On 13 Aug 2015 17:29, Rich Freeman wrote:
> On Thu, Aug 13, 2015 at 3:55 PM, "Paweł Hajdan, Jr." wrote:
> > I'd like to start with: kudos for the very skilfully performed migration
> > from CVS to git! I just committed a simple changed and it worked great.
> >
> > I was curious and started exploring the repo a little bit, and the
> > initial commit says:
> >
> >> This commit is the start of the NEW history.
> >> Any historical data is intended to be grafted onto this point.
> >
> > Is the historical data available now? Is it still work in progress?
> >
> 
> The official version is still pending.
> 
> My unofficial version (which as far as I can tell is about as good as
> it is going to get, but consider it draft) is at:
> https://github.com/gentoo/gentoo-gitmig-20150809-draft
> 
> (The official version will no doubt be hosted on pure-FOSS infra.)

so we don't have to waste git server resources on it, we could create a git
bundle and mirror that and use http/https to redistribute.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] [PATCH] document openssh-7.0 dsa key change #557388

[Mike Frysinger]

On 13 Aug 2015 17:18, Mike Gilbert wrote:
> On Wed, Aug 12, 2015 at 11:17 PM, Mike Frysinger  wrote:
> > +If you are stuck with DSA keys, you can re-enable support locally by
> > +updating your sshd_config file with a line like so:
> > +   PubkeyAcceptedKeyTypes=+ssh-dss
> 
> I think this should also mention that PubkeyAcceptedKeyTypes applies
> to the ssh client, and can be added to ~/.ssh/config.

it applies to both.  if the server doesn't have it, it won't accept what
the client offers.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Is the $Id$ line in our ebuilds still useful?

[Mike Frysinger]

On 13 Aug 2015 10:36, William Hubbs wrote:
> I understood the usefulness of this line to some when we were using CVS
> since it expanded into the ebuild revision, date, etc.
> 
> This expansion doesn't take place under git, so now I don't understand
> the usefulness of this line. If I have missed something, can someone
> fill me in, or if it isn't useful any more can we consider removing it?

delete it and be done
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Why gcc-config is a separate utility, not a module for eselect?

[Mike Frysinger]

On 02 Mar 2015 16:57, viv...@gmail.com wrote:
> good memory,
> maybe someone could write a frontend in eselect to gcc-config, to have a
> proved manager _and_ everything in one place.

done for the next release
https://bugs.gentoo.org/507870
-mike


signature.asc
Description: Digital signature

[gentoo-dev] [PATCH] profiles: linux: enable USE=seccomp by default

[Mike Frysinger]

---
 profiles/default/linux/make.defaults | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/profiles/default/linux/make.defaults 
b/profiles/default/linux/make.defaults
index 7ad3bdb..be2f6a1 100644
--- a/profiles/default/linux/make.defaults
+++ b/profiles/default/linux/make.defaults
@@ -17,6 +17,9 @@ USE="berkdb crypt ipv6 ncurses nls pam readline ssl tcpd zlib"
 # make sure toolchain has sane defaults 
 USE="${USE} fortran openmp"
 
+# Security ftw.
+USE="${USE} seccomp"
+
 # 2010/10/21 - Ole Markus With 
 # These USE flags were originally inserted here because of PHP
 # and were later removed by me. Reinserting the USE flags again because they 
are
-- 
2.4.4

Re: [gentoo-dev] [PATCH] document openssh-7.0 dsa key change #557388

[Mike Frysinger]

On 13 Aug 2015 09:00, Kristian Fiskerstrand wrote:
> On 08/13/2015 05:17 AM, Mike Frysinger wrote:
> > +Your best option is to generate new keys using newer types such as
> > rsa +or ecdsa or ed25519.  RSA keys will give you the greatest
> > portability +with other clients/servers while ed25519 will get you
> > the best security +with OpenSSH (but requires recent versions of
> > client & server).
> 
> Strictly speaking DSA/DSS is newer than RSA (FIPS-186-1 came in early
> 90's, RSA around since 70s, although the ElGamal signature scheme was
> around before that).

i'll rephrase:
-Your best option is to generate new keys using newer types such as rsa
+Your best option is to generate new keys using strong algos such as rsa

> ECC gives a better performance on the same
> security level when comparing to DSA/RSA, however claiming better
> security in general isn't necessarily valid, Ed25519 is a signature
> scheme over Curve25519 which is a 256 bit curve generally considered
> to be 128 bit security level, roughly comparable to a 3072 bit RSA key.

using ed25519 allows you to build openssh w/USE=-ssl which does get you
better security due to the smaller attack surface.  but the point of the
news item is to push people in the right direction w/out getting into a
dissertation on the nuances/details that people realistically won't grok
and won't make a difference to them.  if they're experts/interested, it
should be easy to locate additional material (including the linked page).
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Introduce ppc64le architecture into gentoo ! please share your comments

[Mike Frysinger]

On 13 Aug 2015 07:58, 姜渠 wrote:
> 2015-08-12 15:47 GMT+08:00 Mike Frysinger:
> > On 12 Aug 2015 15:20, Leno Hou wrote:
> > >> 2.  How to control endian difference via profiles ? i.e.  *How to get
> > >> ppc64le as a full stage/profile along side ppc64* ?
> > >>  Could you give me in detail ?
> >
> > >you probably want to create a new profile dir:
> > >profiles/arch/powerpc/ppc64/little-endian/
> > >then add a make.defaults file with the right CHOST defaults.  as we find
> > >packages that have problems on little endian, that provides you a safe
> > >space to mask features too.
> >
> > >then create a new target for linux users:
> > >
> >  profiles/default/linux/powerpc/ppc64/13.0/64bit-userland/little-endian/
> > >that'll inherit the arch/powerpc/ppc64/little-endian parent
>
> I tried this way and could merge some packages quite well, that's great
> and really helpful.
> But I still quite confused about the CHOST, such as if I couldn't compile
> "sandbox" successfully in this method, however when I tried to use ppc32's
> profile, it builds well without any errors (similar situation of other
> packages on ppc64's profile as well). What's that mean? how to fix this?
> Could you give me some details ?

w/out error messages it's hard to guess at what the problem is you're seeing.
-mike


signature.asc
Description: Digital signature

[gentoo-dev] [PATCH] document openssh-7.0 dsa key change #557388

[Mike Frysinger]

---
 .../2015-08-13-openssh-weak-keys.en.txt| 26 ++
 1 file changed, 26 insertions(+)
 create mode 100644 
2015/2015-08-13-openssh-weak-keys/2015-08-13-openssh-weak-keys.en.txt

diff --git 
a/2015/2015-08-13-openssh-weak-keys/2015-08-13-openssh-weak-keys.en.txt 
b/2015/2015-08-13-openssh-weak-keys/2015-08-13-openssh-weak-keys.en.txt
new file mode 100644
index 000..8dece5e
--- /dev/null
+++ b/2015/2015-08-13-openssh-weak-keys/2015-08-13-openssh-weak-keys.en.txt
@@ -0,0 +1,26 @@
+Title: OpenSSH 7.0 disables ssh-dss keys by default
+Author: Mike Frysinger 
+Content-Type: text/plain
+Posted: 2015-08-13
+Revision: 1
+News-Item-Format: 1.0
+Display-If-Installed: net-misc/openssh
+
+Starting with the 7.0 release of OpenSSH, support for ssh-dss keys has
+been disabled by default at runtime.  If you rely on these key types,
+you will have to take corrective action or risk being locked out.
+
+Your best option is to generate new keys using newer types such as rsa
+or ecdsa or ed25519.  RSA keys will give you the greatest portability
+with other clients/servers while ed25519 will get you the best security
+with OpenSSH (but requires recent versions of client & server).
+
+If you are stuck with DSA keys, you can re-enable support locally by
+updating your sshd_config file with a line like so:
+   PubkeyAcceptedKeyTypes=+ssh-dss
+
+Be aware though that eventually OpenSSH will drop support for DSA keys
+entirely, so this is only a stop gap solution.
+
+More details can be found on OpenSSH's website:
+   http://www.openssh.com/legacy.html
-- 
2.4.4

Re: [gentoo-dev] .gitignore

[Mike Frysinger]

On 12 Aug 2015 18:27, Brian Dolbec wrote:
> 2)  There is another alternate location that you can define files to
> ignore locally without having to commit them to .gitignore.
> Consider .gitignore a global setting.  There is another setting
> inside .git/info/exclude which is a local config file that will persist
> and not be affected by pulls.
> 
>   So please use that for local exclusions you want to add and not try to
>   force them into a global .gitignore which is part of the repo.
>   Something that seems to be hotly debated. ;)

as i stated, there's no reason for these paths to ever be committed.
conversely, some people (not unreasonably so) will place files in there
that have historically had known meanings.  adding these to the global
gitignore is simply the right thing to do and negatively impacts no one.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Introduce ppc64le architecture into gentoo ! please share your comments

[Mike Frysinger]

On 12 Aug 2015 15:20, Leno Hou wrote:
> 2.  How to control endian difference via profiles ? i.e.  *How to get
> ppc64le as a full stage/profile along side ppc64* ?
>  Could you give me in detail ?

you probably want to create a new profile dir:
profiles/arch/powerpc/ppc64/little-endian/
then add a make.defaults file with the right CHOST defaults.  as we find
packages that have problems on little endian, that provides you a safe
space to mask features too.

then create a new target for linux users:
profiles/default/linux/powerpc/ppc64/13.0/64bit-userland/little-endian/
that'll inherit the arch/powerpc/ppc64/little-endian parent

> 3.  ppc64 already have stage3,  why ppc64le tends to only be used in
> embedded setups ?

i said "ppc little endian", not "ppc64le".  historically speaking, ppc64le 
hasn't been a thing, and the only people doing ppc little endian are 32bit
embedded users.  that doesn't mean we can't make stages/iso for both.

> 4.  I would like become a developer of porting gentoo on ppc64le.  Anyone
> could help/mentor me to join this project ?

ideally someone on the ppc side would pick you up, but i think they've been
a bit of a skeleton team of late.  so if need be, i can help you here.

> 5.  https://wiki.gentoo.org/wiki/Porting   The Section 'Converting to
> Gentoo' needs to be updated.
>  From portage-2.2.20 on, please download portage and install it by
> 'python setup.py install'

you mean my bootstrap-portage script ?

> **Most importantly, Any Ideas/steps of how to  porting gentoo on  ppc64le
> architecture?**

do you have hardware ?  then it's simply a matter of booting Gentoo in it and 
filing/fixing bugs :).
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Introduce ppc64le architecture into gentoo ! please share your comments

[Mike Frysinger]

On 11 Aug 2015 10:49, James Le Cuirot wrote:
> If ppc64le does become popular then I would suggest that we drop 32-bit
> ppc first. Others may disagree though. :)

ppc isn't being dropped, and ppc64le is entirely orthogonal to support for it
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Introduce ppc64le architecture into gentoo ! please share your comments

[Mike Frysinger]

On 11 Aug 2015 10:45, Anthony G. Basile wrote:
> On 8/11/15 10:33 AM, Ian Stakenvicius wrote:
> > On 11/08/15 06:11 AM, Leno Hou wrote:
> >> I think ppc64le would become popular,
> >> https://en.wikipedia.org/wiki/Ppc64.
> >>
> >> 1. enable porting x86 Linux based application with minimal effort.
> >>   2. Some PowerPC user, little endian apparently feels cheap, wrong,
> >> and PCish. 3. Other distrbutions like Ubuntu, Redhat and SUSE
> >> already support little endian in powerpc.
> >
> > In terms of the codepaths, what's different between ppc64le vs ppc64,
> > and ppc64le vs amd64 ?  Obviously kernels will differ, but in terms of
> > C/C++/other compiled source code what needs to change?
> >
> > If all this needs is its own profile for a CHOST/CBUILD specification
> > and it can leverage an existing keyword, then this should be rather
> > simple to implement yes?
> 
> We would leverage this on ppc64 keyword.  It is a bit dangerous to claim 
> that a pkg stable on ppc64 is stable on ppc64le, but we would live with 
> that risk.  Ideally you should test on both.  The situation is analogous 
> to mips where there are many different ISAs and both be and le.  It is 
> one of the reasons mips is hard to move back into stable.  But having 
> stable keywords is really nice when it comes to building and maintaining 
> stages and keeping base pkgs versions in sync with the other arches.  
> For this reason, I would even been in favor of restoring stable mips 
> with the understanding that "stable" carries something of a risk when 
> crossing the be/le boundry, or the mips I vs mips III, or 32 vs 64, etc.

yes, we should just re-use the existing KEYWORDS and control the endian
differences via profiles.  it's how other arches (mips, ppc, arm, arm64)
are handled currently.

note: people have already built Gentoo for ppc little endian, but that
tends to only be used in embedded setups, so the builds don't get published
like other arches as stages.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Re: rsync mirror security

[Mike Frysinger]

On 11 Aug 2015 15:23, Kent Fredric wrote:
> On 11 August 2015 at 15:06, Mike Frysinger wrote:
> > it would have to re-use the same tag name every time otherwise we end up 
> > with
> > 17.5k/8.7k/4.3k/whatever new tags per year ... a really bad idea
> 
> I was very much under the impression git is not designed with repeated
> tag replication in consideration.

git has no problem fetching rewritten tags.  internally, it doesn't care
either -- a tag is merely a reference to an object.

> The git tag documentation very much implies that any tag having its
> reference changed will result in effort being required of everyone who
> wishes to consume that tag. ( It literally brands  the act of
> re-tagging things to be "insane" )
> 
> Tags are very much intended to be immutable references to commits.

the git docs take the stance that publishing any mutable names is wrong.
same goes for rebasing and publishing rewritten history.  that's simply
the recommended practice.  it doesn't mean that the world blows up when
you do rewrite things.

> If you need mutable references to commits, isn't that what branches are for?

no, that's not what they're for.  
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Re: rsync mirror security

[Mike Frysinger]

On 10 Aug 2015 16:05, Matthias Maier wrote:
> > Users can fetch/pull from Github.
> 
> We could also provide automatic signed tags every 30min/1h/2h/whatever
> (signed with a suitable infrastructure key). With that, the integrity of
> a tagged git checkout can be easily verified on client side.

it would have to re-use the same tag name every time otherwise we end up with 
17.5k/8.7k/4.3k/whatever new tags per year ... a really bad idea

depending on how fast the process is, it could just be part of the receive hook
on the server that does the checking now.  that way the tag is always up to date
with every push a developer makes.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] .gitignore

[Mike Frysinger]

On 10 Aug 2015 09:17, Michał Górny wrote:
> Dnia 2015-08-10, o godz. 02:42:21 Mike Frysinger napisał(a):
> > On 10 Aug 2015 08:28, Justin (jlec) wrote:
> > > I like to propose to add the md5-cache into it. Which other files are of 
> > > interest?
> > 
> > /distfiles/
> > /local/
> > /packages/
> 
> Those directories should not be ignored. Those should not exist for
> a long time.

there's no reason people can't use these on their own system.  there's no
reason they should be added to the git repo which means, if a user opted
to utilize them, they should be ignored.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] .gitignore

[Mike Frysinger]

On 10 Aug 2015 08:28, Justin (jlec) wrote:
> how do we maintain this file?

like any other file.  git add && git commit.

> I like to propose to add the md5-cache into it. Which other files are of 
> interest?

/distfiles/
/local/
/packages/

/metadata/md5-cache/
-mike


signature.asc
Description: Digital signature

[gentoo-dev] Re: [gentoo-core] Git Migration: go-live!

[Mike Frysinger]

On 09 Aug 2015 12:18, Agostino Sarubbo wrote:
> 1) The git workflow [1] does not mention to add PORTAGE_GPG_KEY to make.conf 
> and neither to use the long gpg key. Does the short create a problem?

it does not

> 2) The git workflow [1] says to do git config --local commit.gpgsign 1 - Do 
> we 
> need to use git push --signed if was already in the config ?

yes.  commit & push are independent operations.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-core] [gentoo-dev] Git Migration: go-live!

[Mike Frysinger]

On 09 Aug 2015 11:31, Marc Schiffbauer wrote:
> * Michael Weber schrieb am 09.08.15 um 11:00 Uhr:
> > On 08/09/2015 07:36 AM, Robin H. Johnson wrote:
> > > I'm only 90% sure that everything works, but I've spent almost the 
> > > entire day on it, and there's more to go tomorrow.
> > Thanks a lot!
> > 
> > use case: my cvs tree had uncommitted ebuild work (yes, you caught me
> > actually doing something).
> > now `cvs diff` no longer works, how can i track down my local changes?
> > besides diffing against git tree, brain memory aka shell history and
> > find -newer?
> 
> I'd say: 
> 
> - tar your *.ebuild and files/* stuff away
> - then "git clone" the new git repo.
> - untar your files in the new git repo
> - use "git diff"

there will be a ton of cvs keyword noise in there though.  need to run
a sed on the files to clear it out.

it also will include noise where your local checkout was behind the latest
tree, so it'll only really work if you ran `cvs up` in the whole tree just
before it was shutdown.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-scm] Re: [gentoo-dev] Git Migration: go-live!

[Mike Frysinger]

On 09 Aug 2015 14:54, Alexey Shvetsov wrote:
> Hi all!

please don't top post

> Current repoman complains about headers in ebuilds
> 
> >>> Creating Manifest for /home/alexxy/Gentoo/gentoo/sys-cluster/open-mx
>ebuild.badheader  1
> sys-cluster/open-mx/open-mx-1.5.4.ebuild: Malformed CVS Header on 
> line: 3
> 
> So may be its better to drop $Id: $ completely?

it should look like:
# $Id$

but even then, yes, we should just trim the line
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Re: Git Migration: go-live!

[Mike Frysinger]

On 09 Aug 2015 04:16, Ryan Hill wrote:
> On Sun, 9 Aug 2015 05:36:16 + "Robin H. Johnson" wrote:
> > On Sat, Aug 08, 2015 at 05:47:14PM +, Robin H. Johnson wrote:
> > > On Thu, Jul 02, 2015 at 09:39:52PM +, Robin H. Johnson wrote:
> > > > 2015/08/08 15:00 UTC - Freeze
> > > > 2015/08/08 19:00 UTC - Git commits open for developers
> > This is going live in a few minutes. There was a lot of delays and snags
> > that were hit. QA has a lot of reviewing to do of in-tree patches with
> > long-standing CVS keyword damage. gkeys is also not sufficiently baked,
> > so we're using some scripting for now instead [1].
> > 
> > The new setup DOES enforce that commits AND pushes are signed.
> > 
> > I'm only 90% sure that everything works, but I've spent almost the
> > entire day on it, and there's more to go tomorrow.
> > 
> > Other old CVS repos are still closed for the moment, they will re-open
> > tomorrow.
> 
> So for someone who hasn't been following any of this, is there an idiot's 
> guide
> on how make the Gentoo?

Robin's set of insns had everything i needed to get going, and i've never
done git signing before

the only thing to note is that our documentation has generally said you
should generate a dedicated key for signing (with a short expiration),
but the set of gpg keys in ldap generally have been your long-lived key
that you use for e-mail/etc...  so if you followed that, your ebuild key
won't be in ldap (so add it using the ldap wiki guide), and you'll have
to wait for the keys to be synced by infra before you can push.

what were you having trouble with ?
-mike


signature.asc
Description: Digital signature

[gentoo-dev] new mips dev box

[Mike Frysinger]

Google has donated a nice mips box to us for general development.  it is beefy 
enough and has lots of disk space that we're opening it up to any Gentoo dev 
like any other dev box -- create chroots and such.

it's running a 64bit kernel and thus supports any of the mips ABIs 
(o32/n32/n64), although the default ABI in the / is n32.

if people want access, feel free to e-mail me privately.  username/ssh keys are 
kept in sync with your general Gentoo creds (i.e. what you have in ldap on 
dev.g.o) so there's no need to specify those details.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] new eclass: go-live.eclass for handling go live ebuilds

[Mike Frysinger]

On 08 Jun 2015 14:38, William Hubbs wrote:
> # Copyright 2015 Gentoo Foundation

normally we use the header from skel.ebuild everywhere

> # We depend on dev-vcs/git since it is the most used vcs for Go
> # packages. However we will not depend on all vcs's Go supports at the
> # eclass level. If your package, or one of its dependencies, uses
> # another vcs, please depend on it directly.
> 
> DEPEND=">=dev-lang/go-1.4.2
>   dev-vcs/git"

that really isn't what i was suggesting nor does it seem to be justified ?
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] RFC: Indention in metadata.xml

[Mike Frysinger]

On 06 Jun 2015 12:17, Ulrich Mueller wrote:
> > On Sat, 6 Jun 2015, Michał Górny wrote:
> 
> > Visual space is what you set in your editor. Which also gives tab
> > the advantage that you can set it to something good for you, like
> > 'more than 2 spaces so that it is readable'.
> 
> *If* we should agree on using tabs, then we should also standardise
> the tab width. Using the same rules for indenting and whitespace as
> for ebuilds (i.e., tab stops every four positions) suggests itself:
> https://devmanual.gentoo.org/ebuild-writing/file-format/index.html#indenting-and-whitespace

if there's any standard at all for metadata.xml, it should be the same as 
ebuilds.  there's no reason to deviate.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] new eclass: go-live.eclass for handling go live ebuilds

[Mike Frysinger]

On 05 Jun 2015 09:34, William Hubbs wrote:
> On Fri, Jun 05, 2015 at 12:54:45AM -0400, Mike Frysinger wrote:
> > On 04 Jun 2015 14:10, William Hubbs wrote:
> > > # @MAINTAINER:
> > > # William Hubbs 
> > > # @BLURB: Eclass for fetching and unpacking go repositories.
> > > # @DESCRIPTION:
> > > # This eclass is written to ease the maintenance of live ebuilds
> > > # of software written in the Go programming language.
> > 
> > this should note the ebuild is responsible for depending on the right vcs 
> > packages.  e.g. if you use git, then you need to depend on git.
> 
> Since "go get" fetches $EGO_PN and its dependencies, there is no way an
> ebuild author could get this right without reading all of the import
> statements in the source for their package and all of its dependencies.
> I don't really want to ask ebuild authors to keep up with all of that.

i'm aware.  my point is that with some sites, you know they're going to be 
using 
*at least* one vcs.  if they're pointing to github, that will be git.  if the 
project ends up only pulling from git, then you've automatically made it work 
for them.

if they need additional vcs's, then they can simply depend on it directly.  we 
don't need to be perfect here, and if we can cover the majority of cases, i 
think it's worth the effort.

> > >   if [[ ${EVCS_OFFLINE} ]]; then
> > >   export GOPATH="${S}:${GOPATH}"
> > 
> > what if GOPATH isn't set ?  should this always be appending a colon ?
> 
> I thought it would always be set at this point because it was initially
> set to ${EGO_STORE_DIR} in the env_setup function. What I can do, if it
> makes things more clear, is to replace the value of GOPATH instead of
> prepending it.

you're right, i forgot about that line.  it should be fine.  it'll clobber 
GOPATH that the user has, but we probably want that anyways right ?
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] new eclass: go-live.eclass for handling go live ebuilds

[Mike Frysinger]

On 04 Jun 2015 14:10, William Hubbs wrote:
> # @ECLASS: go-live.eclass

since we're going to have a common go eclass, and i don't think we'll want to 
call it "go.eclass", this too probably should not be go-xxx.  if we assume the 
base one will be "golang.eclass", then this should be golang-xxx.eclass.  i'd 
prefer golang-vcs.eclass myself as that's the naming we've been moving towards.

> # @MAINTAINER:
> # William Hubbs 
> # @BLURB: Eclass for fetching and unpacking go repositories.
> # @DESCRIPTION:
> # This eclass is written to ease the maintenance of live ebuilds
> # of software written in the Go programming language.

this should note the ebuild is responsible for depending on the right vcs 
packages.  e.g. if you use git, then you need to depend on git.

although ...

> # @ECLASS-VARIABLE: EGO_PN
> # @REQUIRED
> # @DESCRIPTION:
> # This is the import path for the go package. Please emerge dev-lang/go
> # and read "go help importpath" for syntax.
> #
> # Example:
> # @CODE
> # EGO_PN="github.com/user/project"
> # @CODE

can't we automate some of the common hosts ?  if it says github, we know it's 
going to be using at least git.

>   local saved_umask
>   if [[ ${EVCS_UMASK} ]]; then
>   saved_umask=$(umask)
>   umask "${EVCS_UMASK}" ||
>   die "${ECLASS}: bad options to umask: ${EVCS_UMASK}"
>   fi

use `eumask_push` instead

on a related note, i don't think we should encourage the implicit -n operator.  
it adds no overhead and really no code maintenance to specify it.  conversely,
i'm not sure it can be considered common usage.  and even if it is, i still 
don't see a good reason to not just use the explicit -n as it's clear to the 
reader what it's doing.

>   if [[ ! -d ${EGO_STORE_DIR} ]]; then
>   (
>   addwrite /
>   mkdir -p "${EGO_STORE_DIR}" || die
>   ) || die "${ECLASS}: unable to create ${EGO_STORE_DIR}"
>   fi

the inner die is redundant

>   if [[ ${saved_umask} ]]; then
>   umask "${saved_umask}" ||
>   die "${ECLASS}: unable to restore saved umask"
>   fi

use `eumask_pop` instead

>   [[ ${EGO_PN} ]] ||
>   die "${ECLASS}: EGO_PN is not set"

prefer -z && myself
[[ -z ${EGO_PN} ]] && die ...

>   if [[ ${EVCS_OFFLINE} ]]; then
>   export GOPATH="${S}:${GOPATH}"

what if GOPATH isn't set ?  should this always be appending a colon ?

>   local saved_umask
>   if [[ ${EVCS_UMASK} ]]; then
>   saved_umask=$(umask)
>   umask "${EVCS_UMASK}" ||
>   die "${ECLASS}: Bad options to umask: ${EVCS_UMASK}"
>   fi

use `eumask_push` instead

>   go get -d -t -u -v -x "$EGO_PN"

needs braces around ${EGO_PN}, and shouldn't this be calling `die` ?

would also be useful to show the command you're running:
set -- go get -d -t -u -v -x "${EGO_PN}"
echo "$@"
"$@" || die

>   if [[ ${saved_umask} ]]; then
>   umask "${saved_umask}" ||
>   die "${ECLASS}: unable to restore saved umask"
>   fi

use `eumask_pop` instead

>   export GOPATH="${S}:${GOPATH}"

same questions here
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] oops: "portage-latest.tar.*" are off-by-one.

[Mike Frysinger]

On 04 Jun 2015 21:46, Vadim A. Misbakh-Soloviov wrote:
> В письме от Чт, 4 июня 2015 11:17:01 пользователь Mike Frysinger написал:
> > if you have a bug to report, please use bugs.gentoo.org
> 
> I bet, "bug" will deprecate itself before even bug wranglers takes a look on 
> it.

i don't know what point you're trying to make.  the gentoo dev list is not for 
reporting bugs.  it never has been.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] oops: "portage-latest.tar.*" are off-by-one.

[Mike Frysinger]

if you have a bug to report, please use bugs.gentoo.org
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] LFS QA warnings coming soon to a build near you

[Mike Frysinger]

On 03 Jun 2015 10:26, Alexis Ballier wrote:
> On Tue, 2 Jun 2015 10:13:54 -0400 Mike Frysinger wrote:
> > On 01 Jun 2015 10:15, Alexis Ballier wrote:
> > > On Sun, 31 May 2015 11:17:50 -0400 Mike Frysinger wrote:
> > > > (3) considering the glibc effort has been stalled for over a year,
> > > > (1) is something we can help accomplish and make reasonable
> > > > progress on (4) glibc isn't the only one that implements LFS in a
> > > > transparent backwards compatible manner
> > > 
> > > maybe the fact that some file operations are broken with glibc's
> > > default settings on a somewhat popular fs would be a good argument
> > > to un-stall it ?
> > 
> > it isn't that black & white.  while for many packages the change
> > would be harmless, glibc is more conservative than that.  it can be
> > shown that a not uncommon coding style is to use long's everywhere
> > when dealing with the fs. when sizeof(off_t)==sizeof(long), this
> > works out.  when off_t is suddenly twice as large, then you can get
> > truncation at best (which is kind of the status quo) and random
> > corruption at worse (like an API that takes pointers to off_t's but
> > the caller passed in a long).  if you want to join the list upstream
> > and contribute to the discussion, you're more than welcome to.  the
> > maintainers aren't clueless -- they fully understand the trade-offs
> > we're discussing here and know that 32bit fs accesses lead to
> > failures (including stat).
> > 
> > since sitting on our hands and hoping for the best continues to
> > accomplish nothing, getting the various upstream packages to opt-in
> > to LFS themselves can make real progress now.
> 
> agreed, thanks for the explanation
> 
> i take it as the main goal of these qa warnings is to fix the above
> mentioned half broken packages and that pushing lfs flags everywhere is
> a slow but safe way to achieve it :)
> 
> it'd be interesting to have data about how many packages can break;
> my belief is that more than half the c/c++ programs use one way or
> another fs ops but maybe less than one in a thousand will break; i can
> understand this is still too much for a libc (even though other
> 'breaking fixes' weren't so controversial in the past), and we'll see
> after gathering the data your qa warnings will provide

let's ignore the open/read/write issue for now on the assumption it's more 
uncommon to incidentally have that break.  instead, let's look at things that
can hit inodes -- stat & dir listing.  a file simply being allocated a 64bit
inode will break an app -- both directly stating and even trying to list the 
dir.  oops! :)

here's the command i'm using for just inode funcs:
scanelf / -mqRygs \

'^((__)?[fl]?x?stat(v?fs)?(at)?|alphasort|getdirentries|readdir(_r)?|scandir(at)?|versionsort)$'
 
you'd have to ignore glibc and sandbox as they provide both 32bit & 64bit.

i have an x86 chroot for random testing, but it's not as "full" as my desktop.
it has a measily 245 packages installed.  of those:
 - 25 are using 32bit inode functions
 - 34 are using some 32bit fs interface (this is a superset of the above)

if someone had a fuller install of like >1000 pkgs, that'd be interesting.

> > as i already said, changing the default in *glibc* doesn't help
> > non-glibc systems.
> 
> even with ten different libc's, the order of magnitude is still smaller
> for changing the default :)

true.  each fight though will be significantly higher i think, assuming you can 
even find someone to talk to (as not all are open source projects).  and it 
will 
take longer for the fix to trickle out to deployments.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/gnugo: gnugo-3.9.1-r1.ebuild ChangeLog

[Mike Frysinger]

On 03 Jun 2015 00:28, Michael Palimaka wrote:
> On 02/06/15 23:52, Mike Frysinger wrote:
> > On 02 Jun 2015 23:07, Michael Palimaka wrote:
> >> On 02/06/15 21:38, Mike Frysinger wrote:
> >>> On 02 Jun 2015 20:47, Michael Palimaka wrote:
> >>>> On 02/06/15 17:04, Michał Górny wrote:
> >>>>> Dnia 2015-06-02, o godz. 03:58:35
> >>>>> "Michael Sterrett (mr_bones_)"  napisał(a):
> >>>>>> -DEPEND="readline? ( sys-libs/readline )
> >>>>>> +DEPEND="readline? ( sys-libs/readline:0 )
> >>>>>
> >>>>> This should be actually := (or :0=) for both deps since gnugo links to
> >>>>> them. This also applies to your remaining 'warning silencing' commits.
> >>>>
> >>>> Why? Blindly adding the subslot dep is a bad idea.
> >>>
> >>> in this particular case, the subslot usage is what we want since we're 
> >>> compiling+linking against it.  using readline:0 vs readline is still an 
> >>> improvement though.
> >>>
> >>> we also want a subslot on ncurses since we compile+link against it.
> >>>
> >>> i think it's pretty uncommon to use readline in a package and not want a 
> >>> subslot.  your package would have to be doing something uncommon like
> >>> dlopening it since the only thing readline provides is a library ...
> >>
> >> Neither readline nor ncurses define an explicit subslot, so I don't know
> >> what their future meaning might be.
> > 
> > their meaning would be the reasonable one -- to track the SONAME.  while it 
> > hasn't been deployed yet (due to those packages being on EAPI=4), i don't 
> > know 
> > what other value you'd expect it to be.  they've both broken their SONAMEs 
> > in 
> > the past.  readline in particular has been every major version (4.x, 5.x, 
> > 6.x).
> 
> Since you've clarified the future meaning for ncurses/readline, it's not
> a problem.
> 
> The point was it's not a good idea to use the operator unless without
> knowing what it means for the package in question (since a subslot can
> be used to handle a number of different situations, as I wrote previously).

you make a reasonable point, but i'd consider some of your examples as 
(ab|mis)use of subslots.  their purpose is to track ABI changes so as
to signal rebuilds.  if they've been appropriated for other uses, then
perhaps those libraries are doing it wrong ?  i expect subslots to do
one thing (what PMS describes/intends) and would be surprised to find
out that some packages are doing something else.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] LFS QA warnings coming soon to a build near you

[Mike Frysinger]

On 01 Jun 2015 09:51, Christopher Head wrote:
> On May 31, 2015 7:33:28 AM PDT, Alexis Ballier wrote:
> >I'm not sure what's best for every one:
> >1. Push hundreds of patches upstream to add lfs flags;
> >2. Apply your patch to our glibc ebuilds, fix the corner cases, and go
> >  back to glibc upstream with these data.
>
> If the changes are made to glibc, would these be under a new symbol version 
> for ABI compatibility, or just be changes to headers to make 
> _FILE_OFFSET_BITS=64 the default? If not, what about binary software? Not 
> saying you haven’t considered the relevant issues; I just haven’t seen binary 
> software brought up on this list yet.

regardless of what the headers export as a default, glibc's ABI would not 
change.  the CPPFLAGS merely control which set of symbols are used.  any
existing binary packages would continue to operate the same way they always
have.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] LFS QA warnings coming soon to a build near you

[Mike Frysinger]

On 01 Jun 2015 10:15, Alexis Ballier wrote:
> On Sun, 31 May 2015 11:17:50 -0400 Mike Frysinger wrote:
> > (3) considering the glibc effort has been stalled for over a year,
> > (1) is something we can help accomplish and make reasonable progress
> > on (4) glibc isn't the only one that implements LFS in a transparent
> > backwards compatible manner
> 
> maybe the fact that some file operations are broken with glibc's
> default settings on a somewhat popular fs would be a good argument to
> un-stall it ?

it isn't that black & white.  while for many packages the change would be 
harmless, glibc is more conservative than that.  it can be shown that a not 
uncommon coding style is to use long's everywhere when dealing with the fs.
when sizeof(off_t)==sizeof(long), this works out.  when off_t is suddenly 
twice as large, then you can get truncation at best (which is kind of the
status quo) and random corruption at worse (like an API that takes pointers
to off_t's but the caller passed in a long).  if you want to join the list
upstream and contribute to the discussion, you're more than welcome to.  the
maintainers aren't clueless -- they fully understand the trade-offs we're
discussing here and know that 32bit fs accesses lead to failures (including
stat).

since sitting on our hands and hoping for the best continues to accomplish
nothing, getting the various upstream packages to opt-in to LFS themselves
can make real progress now.

> > which leads me to the next part ... my first suggestion in the
> > tracker is for autotool based projects to use AC_SYS_LARGEFILE
> > because: (a) it supports a variety of systems
> > (b) as new systems come up or bugs are found or whatever, the
> > autoconf macro will improve and people eventually get those fixes for
> > free (c) it does it all transparently for you -- add the macro and
> > you're done (d) it fixes the package for all users, new & old
> > 
> > the reason i listed only the raw CPPFLAGS and autoconf macros are
> > because those are the two i'm familiar with.  i don't know how other
> > build systems (e.g. cmake) support this (assuming they do at all).
> > if people have other recipes on hand, then it would be great to
> > collect more there.
> 
> yes, but that is not what i am discussing: unless i missed something,
> they'll all end up one way or another adding the relevant defines;
> whether it is done with an m4 macro, append-lfs-flags, a cmake function
> or what else is an implementation detail of little interest to me trying
> to understand why we don't simply change the default :)

as i already said, changing the default in *glibc* doesn't help non-glibc 
systems.  using portable build systems (like autotools) lets you easily 
enable features like this and the build system knows the various platform
details.  if you decided to roll your own build system or use one that
isn't that portable, well that's kind of your fault isn't it ?  if you've
opted to only support a subset of systems, then that means adding these
CPPFLAGS yourself.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/gnugo: gnugo-3.9.1-r1.ebuild ChangeLog

[Mike Frysinger]

On 02 Jun 2015 23:07, Michael Palimaka wrote:
> On 02/06/15 21:38, Mike Frysinger wrote:
> > On 02 Jun 2015 20:47, Michael Palimaka wrote:
> >> On 02/06/15 17:04, Michał Górny wrote:
> >>> Dnia 2015-06-02, o godz. 03:58:35
> >>> "Michael Sterrett (mr_bones_)"  napisał(a):
> >>>> -DEPEND="readline? ( sys-libs/readline )
> >>>> +DEPEND="readline? ( sys-libs/readline:0 )
> >>>
> >>> This should be actually := (or :0=) for both deps since gnugo links to
> >>> them. This also applies to your remaining 'warning silencing' commits.
> >>
> >> Why? Blindly adding the subslot dep is a bad idea.
> > 
> > in this particular case, the subslot usage is what we want since we're 
> > compiling+linking against it.  using readline:0 vs readline is still an 
> > improvement though.
> > 
> > we also want a subslot on ncurses since we compile+link against it.
> > 
> > i think it's pretty uncommon to use readline in a package and not want a 
> > subslot.  your package would have to be doing something uncommon like
> > dlopening it since the only thing readline provides is a library ...
> 
> Neither readline nor ncurses define an explicit subslot, so I don't know
> what their future meaning might be.

their meaning would be the reasonable one -- to track the SONAME.  while it 
hasn't been deployed yet (due to those packages being on EAPI=4), i don't know 
what other value you'd expect it to be.  they've both broken their SONAMEs in 
the past.  readline in particular has been every major version (4.x, 5.x, 6.x).
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/gnugo: gnugo-3.9.1-r1.ebuild ChangeLog

[Mike Frysinger]

On 02 Jun 2015 20:47, Michael Palimaka wrote:
> On 02/06/15 17:04, Michał Górny wrote:
> > Dnia 2015-06-02, o godz. 03:58:35
> > "Michael Sterrett (mr_bones_)"  napisał(a):
> >> -DEPEND="readline? ( sys-libs/readline )
> >> +DEPEND="readline? ( sys-libs/readline:0 )
> > 
> > This should be actually := (or :0=) for both deps since gnugo links to
> > them. This also applies to your remaining 'warning silencing' commits.
> 
> Why? Blindly adding the subslot dep is a bad idea.

in this particular case, the subslot usage is what we want since we're 
compiling+linking against it.  using readline:0 vs readline is still an 
improvement though.

we also want a subslot on ncurses since we compile+link against it.

i think it's pretty uncommon to use readline in a package and not want a 
subslot.  your package would have to be doing something uncommon like
dlopening it since the only thing readline provides is a library ...
-mike


signature.asc
Description: Digital signature

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: linux-info.eclass

[Mike Frysinger]

On 02 Jun 2015 08:11, Michał Górny wrote:
> Dnia 2015-06-02, o godz. 04:27:35
> "Mike Frysinger (vapier)"  napisał(a):
> > +   for OUTPUT_DIR in "${SYROOT}" "${ROOT}" "" ; do
> 
> What's SYROOT? Did you mean SYSROOT?

thanks, fixed
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] LFS QA warnings coming soon to a build near you

[Mike Frysinger]

On 31 May 2015 11:58, Mike Gilbert wrote:
> On Sat, May 30, 2015 at 2:54 PM, Mike Frysinger wrote:
> > we've got a new QA check that warns whenever a package is built using a 
> > 32bit
> > filesystem interface.  in practice, this applies to arm/mips/ppc/sh/x86 
> > systems
> > (not including multilib -- for now).
> >
> > this topic has come up in Gentoo a few times over the years but we've never
> > really amassed the will power to fix it.  instead we fix it in one-offs 
> > based
> > on user reports (like "can't download 4GiB file with ftp" #101038).  this 
> > was
> > worked well enough because most users have moved on to 64bit systems and the
> > interaction with >2GiB files tends to correlate with a few packages.
> >
> > however, "recent" winds have started blowing where file systems are 
> > utilizing
> > 64bit inodes to handle large file counts.  this means apps that do even 
> > basic
> > things like stat() will now fail.  the number of applications that this 
> > affects
> > is significantly higher, although still relegated to systems that happen to 
> > use
> > a file system with 64bit inodes.
> 
> Does this issue affect software that only reads/writes small files and
> never calls stat? For example, pkg-config.

it is possible to use some file system operations and never run into problems.
the trouble is that it requires diligence and careful auditing, and you have to 
make sure your interactions with other packages are also OK.  considering how 
bad/unaware the wider community is wrt LFS, ABI compatibility, and such 
critical 
but oft overlooked issues, i suspect most people also won't have the will 
power/capabilities to keep up here.

conversely, flip the autoconf/cppflags magic, and most projects Just Work.

> It might still be nice to adjust such packages for consistency, but it
> might be harder to justify patches to upstream developers.

pkg-config already merged it and it's already been pulled back into Gentoo ;)
https://bugs.freedesktop.org/show_bug.cgi?id=90078
https://bugs.gentoo.org/550508

that said, i'm not entirely sure why there would be a lot of push back.
when i gathered data on this years ago (which i no longer have, so i'd have
to recreate), the increased foot print and runtime cost was not significant.
especially when you consider that we're talking about I/O operations which
inherently kill CPU performance due to stalls.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] LFS QA warnings coming soon to a build near you

[Mike Frysinger]

On 31 May 2015 16:33, Alexis Ballier wrote:
> On Sun, 31 May 2015 10:17:02 -0400 Mike Frysinger wrote:
> > On 31 May 2015 15:52, Alexis Ballier wrote:
> > > On Sun, 31 May 2015 13:50:49 +0200 Diego Elio Pettenò wrote:
> > > > On 31 May 2015 at 12:59, Alexis Ballier wrote:
> > > > > nice, but can't we add the lfs flags to our default toolchain
> > > > > flags or even better patch glibc headers to always redefine
> > > > > these functions to the 64bits variants?
> > > > 
> > > > No, because that can easily break ABI of programs that actually
> > > > want the non-LFS one (for instance anything that wraps around
> > > > function calls, including but not limited to padsp, aoss, and
> > > > similar wrappers.)
> > > 
> > > This seems easily fixed with an opt-out for lfs flags that such
> > > programs can use. They'll need to be touched to disable the QA
> > > warning anyway.
> > 
> > this is a discussion for upstream toolchain packages (largely glibc)
> > and in fact i started such a heretical thread over a year ago.  it
> > was not well received due to the implicit/silent ABI change that new
> > builds would receive.  glibc likes to be conservative as it is the
> > foundation of everything.
> > 
> > so unless glibc changes, updating our copy of glibc would only
> > somewhat help our users.  conversely, getting the changes pushed to
> > the respective upstream would help everyone.
> 
> I'm not sure what's best for every one:
> 1. Push hundreds of patches upstream to add lfs flags;
> 2. Apply your patch to our glibc ebuilds, fix the corner cases, and go
>   back to glibc upstream with these data.
> 
> Least to say is that I'm not a big fan of lfs flags as done in glibc and
> I certainly prefer 2., but you'd know better.

well if we're going to do arbitrary lists ;)
(1) your options aren't mutually exclusive
(2) implementing both are desirable
(3) considering the glibc effort has been stalled for over a year, (1) is 
something we can help accomplish and make reasonable progress on
(4) glibc isn't the only one that implements LFS in a transparent backwards 
compatible manner

which leads me to the next part ... my first suggestion in the tracker is for 
autotool based projects to use AC_SYS_LARGEFILE because:
(a) it supports a variety of systems
(b) as new systems come up or bugs are found or whatever, the autoconf macro 
will improve and people eventually get those fixes for free
(c) it does it all transparently for you -- add the macro and you're done
(d) it fixes the package for all users, new & old

the reason i listed only the raw CPPFLAGS and autoconf macros are because those 
are the two i'm familiar with.  i don't know how other build systems (e.g. 
cmake) support this (assuming they do at all).  if people have other recipes on 
hand, then it would be great to collect more there.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] LFS QA warnings coming soon to a build near you

[Mike Frysinger]

On 31 May 2015 15:52, Alexis Ballier wrote:
> On Sun, 31 May 2015 13:50:49 +0200 Diego Elio Pettenò wrote:
> > On 31 May 2015 at 12:59, Alexis Ballier wrote:
> > > nice, but can't we add the lfs flags to our default toolchain flags
> > > or even better patch glibc headers to always redefine these
> > > functions to the 64bits variants?
> > 
> > No, because that can easily break ABI of programs that actually want
> > the non-LFS one (for instance anything that wraps around function
> > calls, including but not limited to padsp, aoss, and similar
> > wrappers.)
> 
> This seems easily fixed with an opt-out for lfs flags that such
> programs can use. They'll need to be touched to disable the QA warning
> anyway.

this is a discussion for upstream toolchain packages (largely glibc) and in 
fact 
i started such a heretical thread over a year ago.  it was not well received due
to the implicit/silent ABI change that new builds would receive.  glibc likes to
be conservative as it is the foundation of everything.

so unless glibc changes, updating our copy of glibc would only somewhat help our
users.  conversely, getting the changes pushed to the respective upstream would 
help everyone.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] LFS QA warnings coming soon to a build near you

[Mike Frysinger]

On 31 May 2015 12:59, Alexis Ballier wrote:
> I don't understand why one should add append-lfs-flags to almost every
> single package out there.

no one is suggesting that route.  append-lfs-flags is a kludge (albeit an 
effective one) in the face of no upstream support.  if you look at the 
referenced tracker it includes pointers for fixing packages in ways that
can be sent upstream.
-mike


signature.asc
Description: Digital signature

[gentoo-dev] LFS QA warnings coming soon to a build near you

[Mike Frysinger]

we've got a new QA check that warns whenever a package is built using a 32bit 
filesystem interface.  in practice, this applies to arm/mips/ppc/sh/x86 systems
(not including multilib -- for now).

this topic has come up in Gentoo a few times over the years but we've never 
really amassed the will power to fix it.  instead we fix it in one-offs based 
on user reports (like "can't download 4GiB file with ftp" #101038).  this was 
worked well enough because most users have moved on to 64bit systems and the 
interaction with >2GiB files tends to correlate with a few packages.

however, "recent" winds have started blowing where file systems are utilizing
64bit inodes to handle large file counts.  this means apps that do even basic
things like stat() will now fail.  the number of applications that this affects
is significantly higher, although still relegated to systems that happen to use
a file system with 64bit inodes.

since our QA warnings in portage have historically proven themselves to (1) get
users to generate bug reports and (2) get the warnings fixed (both here and in
upstream), there is now a QA check for this issue.  the plan is to let this 
bake 
in portage- for a while before it gets kicked into ~arch and the flood gates
are unleashed.

more background details (including recipes for fixing the issue in your package)
can be found in the tracker:
https://bugs.gentoo.org/471102

an example warning message:
 * QA Notice: The following files were not built with LFS support:
 *   Please file a bug at http://bugs.gentoo.org/ and mark it as a blocker of 
471102.
 *   See that tracker bug (https://bugs.gentoo.org/471102) for more details.
 * fopen@@GLIBC_2.1 bin/route
 * fopen@@GLIBC_2.1 bin/ifconfig
 * fopen@@GLIBC_2.1 bin/hostname
 * __fxstat@@GLIBC_2.0,open@@GLIBC_2.0,fopen@@GLIBC_2.1,readdir@@GLIBC_2.0 
bin/netstat
 * fopen@@GLIBC_2.1 sbin/nameif
 * fopen@@GLIBC_2.1 sbin/ipmaddr
 * fopen@@GLIBC_2.1 sbin/arp
 * fopen@@GLIBC_2.1 sbin/iptunnel
 * fopen@@GLIBC_2.1 sbin/rarp
 * open@@GLIBC_2.0,creat@@GLIBC_2.0,fopen@@GLIBC_2.1 sbin/slattach
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Bugzilla config wrt games

[Mike Frysinger]

On 26 May 2015 18:07, Michał Górny wrote:
> Dnia 2015-05-26, o godz. 09:59:50 Thomas Kahle:
> > I maintain a game (games-strategy/freeotion) aside from the games herd.
> >  When users report bugs, they choose the "Games" component and then bugs
> > get auto-assigned to the games alias.  This is also the recommended
> > procedure:
> > https://wiki.gentoo.org/index.php?title=Project:Games
> > 
> > Given our games maintenance rules this seems wrong.  Shouldn't games
> > bugs be wrangled based on metadata like other bugs?
> > 
> > I understand that changing this behaviour would create a lot of useless
> > bugwrangling work... so maybe there is a different solution?
> 
> I'd say we should reset the default assignee to wranglers. This is once
> again a relict of treating games special for no good reason.

might want to cut out the editorialing.  there's very good reasons for it:
- there's a games component that users have historically rarely used 
incorrectly 
(e.g. filing non-games related bugs under it, and filing games bugs under 
something else)
- historically there have been very few people outside of the games herd that 
maintained games packages, and even then, the bug should be assigned to games 
and the maintainers cc-ed.

as i already said, we do this for other components/teams as well, so the 
handling of games bugs is not unique, both historically and today.  i don't 
think changing the behavior makes sense when the majority still should be 
assigned to games@.

if you wanted to address a real problem, then the bug i referenced would help 
for all packages/herds: http://bugs.gentoo.org/550158
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Bugzilla config wrt games

[Mike Frysinger]

On 26 May 2015 09:59, Thomas Kahle wrote:
> I maintain a game (games-strategy/freeotion) aside from the games herd.
>  When users report bugs, they choose the "Games" component and then bugs
> get auto-assigned to the games alias.  This is also the recommended
> procedure:
> https://wiki.gentoo.org/index.php?title=Project:Games
> 
> Given our games maintenance rules this seems wrong.  Shouldn't games
> bugs be wrangled based on metadata like other bugs?
> 
> I understand that changing this behaviour would create a lot of useless
> bugwrangling work... so maybe there is a different solution?

not really games specific -- this applies to every component that has a default 
assignee.  unless/until we can make bugzilla aware of specific packages that 
the 
user could select/enter so bugzilla could pull owner info out of metadata.xml 
directly, i think the status quo is the least crappy.

relevant: http://bugs.gentoo.org/550158
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Anti-spam changes: proposal to drop spammy mail

[Mike Frysinger]

On 23 May 2015 16:29, Niels Dettenbach (Syndicat.com) wrote:

i hope we also update the server to reject e-mails to mailing lists that 
include 
html nonsense
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] ELT-patches from overlay?

[Mike Frysinger]

On 11 May 2015 22:44, Benda Xu wrote:
> In libtool.eclass[1], it is mentioned in the comments of elt_patch_dir()
> that
> 
> # If an overlay has eclass overrides, but doesn't actually override the
> # libtool.eclass, we'll have ECLASSDIR pointing to the active overlay's
> # eclass/ dir, but libtool.eclass is still in the main Gentoo tree.  So
> # add a check to locate the ELT-patches/ regardless of what's going on.
> 
> 
> But quoting from PMS[2], "ECLASSDIR: The full path to the master
> repository’s eclass directory", ECLASSDIR always points to
> ${PORTDIR}/eclass, regardless how the repos.conf is configured.
> 
> 
> Thus as long as ELT-patches dir of the gx86 tree exists, there is no way
> to tell libtool.eclass to use it in my overlay.

that's the point of the change -- to locate ELT-patches that matches the 
libtool.eclass regardless of what the overlay is doing.  the intention was not 
to support local sets of ELT-patches while still using the libtool.eclass from 
elsewhere.  see the bug referenced in the commit:
https://bugs.gentoo.org/389009

if you duplicate libtool.eclass in your overlay, it should find ELT-patches 
there.  considering libtool.eclass is pretty tightly coupled to the contents of 
that dir, i'm not sure supporting overlays is desirable.
-mike


signature.asc
Description: Digital signature

[gentoo-dev] Re: [gentoo-project] Anti-spam changes: proposal to drop spammy mail

[Mike Frysinger]

hmm, of the ~90k messages i have in my local dir from ~7 years, it looks like 
~20 would have been incorrectly thrown away.  i can live with that.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] arm64 profile deletes?

[Mike Frysinger]

On 30 Mar 2015 09:54, Tom Gall wrote:
> Sorry for the trouble. My cvs history foo is a little weak but it appears 
> that someone went out and did some deleting in profiles/arch/arm64 of some 
> WIP 
> things without bothering to email, irc or otherwise communicate.

just use the web viewer:
https://sources.gentoo.org/profiles/arch/arm64/

that said, i don't see any recent commits in there from you ... maybe you made 
the changes to /usr/portage/profiles and didn't realize your cwd wasn't the cvs 
tree ?
-mike


signature.asc
Description: Digital signature

[gentoo-dev] glibc-2.21 going into ~arch

[Mike Frysinger]

with 2.20 going stable, and really no reports at all about 2.21, i'll be moving 
it into unstable soon
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Restoring from the Attic?

[Mike Frysinger]

On 21 Mar 2015 14:01, Joshua Kinard wrote:
> What's the procedure for restoring ebuilds from the CVS Attic?  I need to
> temporarily restore an ebuild from the Attic while hunting down a solution for
> Bug #543978.  The CVS Tutorial doesn't have anything on this specific 
> operation.

grab a specific file:
cvs up -r  

when you're done, reset it:
cvs up -A

or just download it by hand (use the "Show dead files" link):
http://sources.gentoo.org/$CATEGORY/$PN/
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] arm64 Mar 2nd update

[Mike Frysinger]

On 02 Mar 2015 17:14, Tom Gall wrote:
> I’ve put my experimental stage3 and portage snapshot in my dev space. See: 
> http://dev.gentoo.org/~tgall

you should take over uploading to our existing experimental space:
http://distfiles.gentoo.org/experimental/arm64/
should be easy to do ...

and lets update the Get Gentoo page to link to it:
http://www.gentoo.org/main/en/where.xml
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] find -delete safe to use?

[Mike Frysinger]

On 14 Mar 2015 23:14, James Le Cuirot wrote:
> I've long considered the -delete argument to find to be widely supported
> enough that using it in ebuilds should not be a problem. Indeed, a grep
> of the tree shows that it is frequently used, even in eclasses.
> 
> I've just noticed that the man page states that it is not present in
> the BSD version. findutils is now included in @system, even on BSD, but
> the ebuild looks as though it gets installed as gfind rather than find.

ebuilds may assume GNU findutils

> On a related note, should I ever include findutils in DEPEND? I've seen
> some instances of this, occasionally conditional on userland_GNU. On
> the one hand, it should always be present now, given what I said about
> @system above but on the other hand, if it gets installed as gfind then
> there's no point in pulling it in if you're only going to call find.

no
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] what's the correct format for bugs containing package name and version?

[Mike Frysinger]

On 05 Mar 2015 20:01, "Paweł Hajdan, Jr." wrote:
> I'm trying to find the best fix for
> 
> 
> Currently file-stabilization-bugs.py uses the '%s: stabilization
> request' % cpv format.
> 
> Here are some options I see:
> 
> a) keep '%s:' as is
> b) change to just '%s'
> c) change to '=%s:'
> d) change to '=%s'
> e) something else
> 
> What is your preference? Let's agree on something and avoid unnecessary
> changes on bugzilla.

(a)
-mike


signature.asc
Description: Digital signature

[gentoo-dev] [rfc] enable USE=seccomp in default/linux/ profiles

[Mike Frysinger]

pro: improved security in daemons (often network)
con: some packages might pull in libseccomp (~250KB)

there shouldn't be measurable runtime overhead here as the filtering is done by 
a JIT in the kernel itself.  if the kernel lacks support for seccomp, daemons 
generally should fallback at runtime.  if they don't, people should file bugs 
to 
get them fixed.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Making more repoman checks fatal

[Mike Frysinger]

On 16 Feb 2015 11:45, Rafael Goncalves Martins wrote:
> On Mon, Feb 16, 2015 at 11:19 AM, Mike Frysinger wrote:
> > On 16 Feb 2015 21:00, Patrick Lauer wrote:
> >> Thus I suggest making the following warnings proper errors:
> >
> > some of these are because they produce false positives.  at least these bugs
> > probably need to be fixed first:
> > https://bugs.gentoo.org/405017
> > https://bugs.gentoo.org/488836
> > https://bugs.gentoo.org/533460
> 
> I think that just the last bug is still valid.

the first is still broken:
$ cd dev-python/boto/
$ cvs up
$ repoman full

RepoMan scours the neighborhood...

Note: use --include-dev (-d) to check dependencies for 'dev' profiles

RepoMan sez: "If everyone were like you, I'd be out of business!"

$ rm *.ebuild
$ cvs up >&/dev/null
$ repoman full

RepoMan scours the neighborhood...
  ebuild.badheader  17
   dev-python/boto/boto-2.11.0.ebuild: Invalid Gentoo Copyright on line: 1
   dev-python/boto/boto-2.19.0.ebuild: Invalid Gentoo Copyright on line: 1
   ...
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/watchdog: watchdog-0.8.3.ebuild ChangeLog

[Mike Frysinger]

On 18 Feb 2015 23:10, Mike Gilbert wrote:
> On Wed, Feb 18, 2015 at 7:08 PM, Patrick Lauer  wrote:
> > On Wednesday 18 February 2015 18:43:59 hasufell wrote:
> >> Is there a communication problem?
> >>
> >> I don't remember getting either:
> >> * a bug report
> >> * a ping
> >> * a review request
> >>
> >> Did I miss something?
> >
> > Yes.
> >
> > Why is this package metadata missing the python herd for no reason?
> 
> Speaking as the current python lead, we don't claim "ownership" of
> everything in dev-python.
> 
> As a Gentoo developer, I find it silly to raise a stink on a mailing
> list over what appears to be a very simple version bump of a very
> simple ebuild. This is not going to convince anyone that a peer review
> workflow is a desirable thing; I don't want to have someone rubber
> stamp every trivial version bump.

+1
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Making more repoman checks fatal

[Mike Frysinger]

On 16 Feb 2015 21:00, Patrick Lauer wrote:
> Thus I suggest making the following warnings proper errors:

some of these are because they produce false positives.  at least these bugs 
probably need to be fixed first:
https://bugs.gentoo.org/405017
https://bugs.gentoo.org/488836
https://bugs.gentoo.org/533460
-mike


signature.asc
Description: Digital signature

Re: Re: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libusbhp: ChangeLog Manifest libusbhp-1.0.2.ebuild metadata.xml

[Mike Frysinger]

On 16 Feb 2015 13:12, Andreas K. Huettel wrote:
> Am Montag 16 Februar 2015, 07:03:18 schrieb Mike Frysinger:
> > except for two things:
> >  * that phrase is meaningless (legally speaking) and has been for a century
> > [1] * the header explicitly stated GPL-2 license
> 
> So you want to change a longstanding policy rule. Right. How about doing this 
> like everyone else and starting a discussion about it? You know, like, 
> talking 
> to people?

again, stop trying to put your words in my mouth and read my other replies.  
your perception of events & intentions is completely wrong.
-mike


signature.asc
Description: Digital signature

Re: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libusbhp: ChangeLog Manifest libusbhp-1.0.2.ebuild metadata.xml

[Mike Frysinger]

On 16 Feb 2015 12:53, Pacho Ramos wrote:
> El lun, 16-02-2015 a las 12:46 +0100, Pacho Ramos escribió:
> > El lun, 16-02-2015 a las 06:39 -0500, Mike Frysinger escribió:
> > [...]
> > 
> > Anyway, wouldn't have been much more useful for all to spend the effort
> > used in remove the package on simply fixing the header? :/
> 
> Ah, ok, I guess it's because of the "All rights reserved"
> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-libs/libusbhp/libusbhp-1.0.2.ebuild?revision=1.1
> 
> In that case I agree removing the ebuild was the safest approach (even
> if a mail or a bug would have being nice to notify the committed about
> that error)

except for two things:
 * that phrase is meaningless (legally speaking) and has been for a century [1]
 * the header explicitly stated GPL-2 license
-mike

[1] https://en.wikipedia.org/wiki/All_rights_reserved


signature.asc
Description: Digital signature

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libusbhp: ChangeLog Manifest libusbhp-1.0.2.ebuild metadata.xml

[Mike Frysinger]

On 16 Feb 2015 19:43, Patrick Lauer wrote:
> On Monday 16 February 2015 06:13:10 Mike Frysinger wrote:
> > even then, deleting an ebuild purely due to different copyright is
> > complete bs.  anyone who understands copyright knows the situation in
> > Gentoo is completely unenforceable.  we have no CLA.  this was
> > patrick/QA wasting people's time to check a meaningless box.
> 
> As others have pointed out, policy is policy. Don't shoot the massager.

again, that's bs.  nowhere does the policy state "silently delete things 
without 
talking to anyone", nor does it state "ignore common sense, blindly follow the 
rules, and act how your think the policy states".  nothing here was cause for 
alarm that could possibly have warranted straight up deletion.

> Since I can't just fix the copyright (that would be more wrong)

considering how copyright *actually* works for us, this statement is fairly 
ludicrous.

> I opted for the easy way out - remove offending bits.

sorry, but you did it wrong.  please don't do it again.
-mike


signature.asc
Description: Digital signature

Re: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libusbhp: ChangeLog Manifest libusbhp-1.0.2.ebuild metadata.xml

[Mike Frysinger]

On 16 Feb 2015 12:31, Andreas K. Huettel wrote:
> Am Montag 16 Februar 2015, 06:13:10 schrieb Mike Frysinger:
> > even then, deleting an ebuild purely due to different copyright is
> > complete bs.
> 
> The requirement for Gentoo copyright in the main tree is not optional, but 
> has 
> been policy for a very long time.

where exactly did i say i intended for it to stay that way ?  i was syncing 
multiple things that day from CrOS and one update i missed the pointless 
munging 
of the header.  had Patrick done the reasonable thing (actually talking to me), 
i could have fixed it fairly quickly.

but lets be clear here to illustrate the inane behavior you're attempting to 
justify.  the policy is not "it must be Gentoo copyright", but "it must have a 
header that says Gentoo copyright even though there's no legal basis for it".

> Just because you've been around forever doesnt mean you can break the rules 
> that everyone else is supposed to follow.

cut the crap.  trying to put words into my mouth doesn't stop making them yours.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libusbhp: ChangeLog Manifest libusbhp-1.0.2.ebuild metadata.xml

[Mike Frysinger]

On Mon, Feb 16, 2015 at 1:16 AM, Alec Warner  wrote:
> On Sun, Feb 15, 2015 at 8:05 PM, Mike Frysinger  wrote:
>> On Wed, Dec 31, 2014 at 12:21 AM, Patrick Lauer (patrick)
>>  wrote:
>> > patrick 14/12/31 05:21:11
>> >
>> >   Removed:  ChangeLog Manifest libusbhp-1.0.2.ebuild
>> > metadata.xml
>> >   Log:
>> >   QA: Remove package with invalid copyright
>>
>> you do not go reverting code without actually talking to people.  if
>> you feel like a revert is necessary, then file a bug.  putting a "QA"
>> tag at the start of the commit message doesn't give you a pass.
>
> Normally I'd side with you on this...but I'm fairly sure repoman doesn't let
> you commit packages to the tree missing these headers. This leads me to
> believe you didn't use repoman, or ignored it?

feel free to grab the code i originally committed and run `repoman
full` yourself.  no fatal errors.  in fact you can see the generated
tags in my commit message.

even then, deleting an ebuild purely due to different copyright is
complete bs.  anyone who understands copyright knows the situation in
Gentoo is completely unenforceable.  we have no CLA.  this was
patrick/QA wasting people's time to check a meaningless box.
-mike

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libusbhp: ChangeLog Manifest libusbhp-1.0.2.ebuild metadata.xml

[Mike Frysinger]

On Wed, Dec 31, 2014 at 12:21 AM, Patrick Lauer (patrick)
 wrote:
> patrick 14/12/31 05:21:11
>
>   Removed:  ChangeLog Manifest libusbhp-1.0.2.ebuild
> metadata.xml
>   Log:
>   QA: Remove package with invalid copyright

you do not go reverting code without actually talking to people.  if
you feel like a revert is necessary, then file a bug.  putting a "QA"
tag at the start of the commit message doesn't give you a pass.
-mike

Re: [gentoo-dev] udev-9999 (and upcoming 217) no longer has userspace firmware loader (will need Linux 3.7 for firmware's to be loaded)

[Mike Frysinger]

On 01 Sep 2014 06:30, Samuli Suominen wrote:
> On 01/09/14 03:37, Patrick Lauer wrote:
> >> Consider this message a prenotice, now you know it's gone
> > ... one more win for eudev. Sigh.
> 
> They are planning in dropping the userspace loader as well, it's
> redudant afterall.
> 
> Most firmware are kernel loadable by >= 3.7
> Everything is kernel loadable (3.7 and few later versions had some
> exceptions for more rare drivers) in latest

echo /bin/busybox mdev > /proc/sys/kernel/hotplug
-mike


signature.asc
Description: Digital signature