[gentoo-dev] Re: [gentoo-dev-announce] Packages up for grabs: app-doc/zeal, x11-terms/pangoterm, maybe dev-ruby/neovim-ruby-client

[Jeroen Roovers]

On Sun, 28 Jun 2020 19:26:14 +0200
Michał Górny  wrote:

> Due to the maintainer going AWOL

Surely you meant MIA.


Kind regards,
 jer

[gentoo-dev] Package up for grabs: sys-apps/lsb-release

[Jeroen Roovers]

sys-apps/lsb-release - Linux Standard Base version query program

Low maintenance, but with six open bug reports.


Regards,
 jer

[gentoo-dev] Re: Last rites: =x11-drivers/nvidia-drivers-375* =x11-drivers/nvidia-drivers-378* =x11-drivers/nvidia-drivers-381* =x11-drivers/nvidia-drivers-384* =x11-drivers/nvidia-drivers-387* =x11-d

[Jeroen Roovers]

On Fri, 14 Dec 2018 15:04:22 +0100
Jeroen Roovers  wrote:

> According to Nvidia these are former "Short Lived" branches that are
> no longer supported.
> 
> 
> # Jeroen Roovers  (14 Dec 2018)
> # Deprecated short lived branches
> # https://www.nvidia.com/object/unix.html
> # File a bug report if you need to use one of these
> # Removal on or about 14 January 2019
> =x11-drivers/nvidia-drivers-375*
> =x11-drivers/nvidia-drivers-378*
> =x11-drivers/nvidia-drivers-381*
> =x11-drivers/nvidia-drivers-384*
> =x11-drivers/nvidia-drivers-387*
> =x11-drivers/nvidia-drivers-396*

I additionally masked =x11-drivers/nvidia-drivers-304* after I was
notified that a security bug[1] requires the removal of the last
version of x11-base/xorg-server that =x11-drivers/nvidia-drivers-304*
supports. Nvidia ended support for the 304 branch around the end of
2017[2].


Kind regards,
 jer


[1] https://bugs.gentoo.org/669588
[2] https://nvidia.custhelp.com/app/answers/detail/a_id/3142

Re: [gentoo-dev] Last rites: =x11-drivers/nvidia-drivers-375* =x11-drivers/nvidia-drivers-378* =x11-drivers/nvidia-drivers-381* =x11-drivers/nvidia-drivers-384* =x11-drivers/nvidia-drivers-387* =x11-d

[Jeroen Roovers]

On Sun, 16 Dec 2018 14:45:11 -0500
Matt Turner  wrote:

> I guess my question to you is whether you think it's okay to mask -304
> for removal or whether there are enough users that we should keep it
> under package.mask?

"The Linux 304.* legacy driver series is the last to support the NV4x
and G7x GPUs and motherboard chipsets based on them. Support for new
Linux kernels and X servers, as well as fixes for critical bugs, will
be included in 304.* legacy releases through the end of 2017." [1]

That should be fine, then: 304 no longer receives security support so it
can go away along with xorg-server-1.19.


Kind regards,
 jer


[1] https://nvidia.custhelp.com/app/answers/detail/a_id/3142

Re: [gentoo-dev] Last rites: =x11-drivers/nvidia-drivers-375* =x11-drivers/nvidia-drivers-378* =x11-drivers/nvidia-drivers-381* =x11-drivers/nvidia-drivers-384* =x11-drivers/nvidia-drivers-387* =x11-d

[Jeroen Roovers]

On Sun, 16 Dec 2018 23:12:55 +0200
Mart Raudsepp  wrote:

> > It's bug https://bugs.gentoo.org/669588  
> 
> That bug should have remained open until cleanup is concluded, afaik.
> Could also change whiteboard to s/stable/cleanup/  (I was about to
> reopen and do that, but bugzilla suddenly had me logged out and don't
> have pw handy).

It also depends on https://bugs.gentoo.org/show_bug.cgi?id=670068
("net-misc/tigervnc-1.9.0-r1 stable request") which is still open.

> While already replying here, this last rites should have been posted
> to gentoo-dev-announce@ as well.

Oh. I'll forward it.


Kind regards,
 jer

Re: [gentoo-dev] Last rites: =x11-drivers/nvidia-drivers-375* =x11-drivers/nvidia-drivers-378* =x11-drivers/nvidia-drivers-381* =x11-drivers/nvidia-drivers-384* =x11-drivers/nvidia-drivers-387* =x11-d

[Jeroen Roovers]

(Re-sending using the proper e-mail address)

On Sat, 15 Dec 2018 21:53:03 +1300
Kent Fredric  wrote:

> On Fri, 14 Dec 2018 15:04:22 +0100
> Jeroen Roovers  wrote:
>   
> > According to Nvidia these are former "Short Lived" branches that
> > are no longer supported.
> > 
> > 
> > # Jeroen Roovers  (14 Dec 2018)
> > # Deprecated short lived branches
> > # https://www.nvidia.com/object/unix.html
> > # File a bug report if you need to use one of these
> > # Removal on or about 14 January 2019
> > =x11-drivers/nvidia-drivers-375*
> > =x11-drivers/nvidia-drivers-378*
> > =x11-drivers/nvidia-drivers-381*
> > =x11-drivers/nvidia-drivers-384*
> > =x11-drivers/nvidia-drivers-387*
> > =x11-drivers/nvidia-drivers-396*
> 
> I personally have a 540M, for which the "newest" supporting drivers
> are 396.18  

No, 390.87 is the latest for your chip and is not masked for removal.

The 396 branch has seen no updates since 10 April 2018 while the 390
branch was last updated on 27 August 2018. Higher major versions do not
mean you have something better or newer.


Kind regards,
 jer

Re: [gentoo-dev] Last rites: =x11-drivers/nvidia-drivers-375* =x11-drivers/nvidia-drivers-378* =x11-drivers/nvidia-drivers-381* =x11-drivers/nvidia-drivers-384* =x11-drivers/nvidia-drivers-387* =x11-d

[Jeroen Roovers]

On Fri, 14 Dec 2018 12:03:52 -0800
Matt Turner  wrote:

> Thanks. What do we want to do about -304?

It's not on the list above because it's a "legacy driver", not a
"short lived" branch[1]. It's not relevant in this context what happens
to the 304 branch, the context being a cleanup of intermediate branches
that were abandoned and surpassed by "long lived" branches.

> It still requires xorg-server-1.19 which I'd like to drop due to a
> security vulnerability. After the listed versions are gone, -304 will
> be the only thing keeping 1.19 in tree.

I see no open security bug report for this. If we had one of those, then
we could write a package.mask entry for both xorg-server and
nvidia-drivers with a reference to the security issue, or add the
branches that are now masked for removal. That way people can plan
their hardware's obsolescence properly or shift to a different driver.


Kind regards,
 jer


[1] https://www.nvidia.com/object/IO_32667.html

[gentoo-dev] Last rites: =x11-drivers/nvidia-drivers-375* =x11-drivers/nvidia-drivers-378* =x11-drivers/nvidia-drivers-381* =x11-drivers/nvidia-drivers-384* =x11-drivers/nvidia-drivers-387* =x11-drive

[Jeroen Roovers]

According to Nvidia these are former "Short Lived" branches that are no
longer supported.


# Jeroen Roovers  (14 Dec 2018)
# Deprecated short lived branches
# https://www.nvidia.com/object/unix.html
# File a bug report if you need to use one of these
# Removal on or about 14 January 2019
=x11-drivers/nvidia-drivers-375*
=x11-drivers/nvidia-drivers-378*
=x11-drivers/nvidia-drivers-381*
=x11-drivers/nvidia-drivers-384*
=x11-drivers/nvidia-drivers-387*
=x11-drivers/nvidia-drivers-396*


Kind regards,
 jer

Re: [gentoo-dev] [RFC] Global use flag 'zip'

[Jeroen Roovers]

On Fri, 12 Oct 2018 22:09:52 +0200
Michał Górny  wrote:

> Hi,
> 
> I'd like to propose adding the following global USE flag:
> 
>   zip - Enable support for .zip archives

The file format is called ZIP.



Kind regards,
   jer

Re: [gentoo-dev] net-dns/dnssec-root: Blind stable on arm, critical bug 667774

[Jeroen Roovers]

On Thu, 11 Oct 2018 19:14:00 +0200
Thomas Deutschmann  wrote:

> > 1) Someone blind-stabled something on arm and it broke (doesn't
> > build?) 2) The arm team failed to mark a package stable before a
> > hard deadline (DNSSEC key rotation)

"Blind-stabled"...

> But that's not the point here. The point was to get some attention
> that again we have a lacking architecture (net-dns/dnssec-root is not
> the only package where ARM arch team is lacking behind) which affects
> anyone "trusting" somehow in STABLE keywords.

The trustworthiness of stable keywords has been eroding for years.

It started when a...@gentoo.org found ways to automate "compile-testing"
on many architectures, taking work away from people who actually cared
about those architectures, reducing arch team efforts to trying to
catch up with ago's work. While it was a valiant effort to reduce
architecture teams' backlogs, I couldn't stress enough at the time how
taking decisions on behalf of all users of an architecture isn't
something you can automate, for instance putting effort into
stabilisations for (sets of) packages that may have ceased being useful
on respective platforms, so that users would switch to cherry-picking
their own stable targets instead of relying on stable keywords to still
be meaningful.

Where "compile-testing" failed as runtimes do not necessarily reflect
that what is being compiled does actually work, architecture teams had
to pick up those pieces of now incorrectly stable-keyworded packages
that got strewn around in automation's wake.

Even more recently a new trend arose where just about anybody who
maintains a package takes stabilisation decisions, usually citing some
"all arches" policy, and in this case "blind-stabled", on behalf of
architecture teams. This new direction is likely based on the same
backlog pressure[0], a sense of emergency because of security issues,
and the desire to clean up obsolete ebuilds.

Having mostly stepped away from concerted stabilisation efforts myself
for those reasons among others, I can only speak for myself in stating
that my trust in stable keywords is at its lowest ever ebb.


Kind regards,
 jer


[0] Wait, didn't we get rid of that? Ah no, the automation effort
reduced architecture team involvement to the point of being
non-existent.

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: net-libs/libssh2/

[Jeroen Roovers]

OK, let's do a full review of your review.


On Mon, 01 Oct 2018 17:00:24 +0200
Michał Górny  wrote:

> On Mon, 2018-10-01 at 11:46 +0000, Jeroen Roovers wrote:
> > commit: d866d4705e1e4a092579a31df2815e3407950a19
> > Author: Jeroen Roovers  gentoo  org>
> > AuthorDate: Mon Oct  1 11:45:43 2018 +0000
> > Commit: Jeroen Roovers  gentoo  org>
> > CommitDate: Mon Oct  1 11:46:10 2018 +
> > URL:
> > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d866d470
> > 
> > net-libs/libssh2: Add USE=mbedtls, switch to cmake for building
> > 
> > * Add support for net-libs/mbedtls
> > * Switch to cmake as the autotools build is even more broken
> > * Remove USE=static-libs as that inhibits building shared libs
> > * Use REQUIRED_USE to force choosing a crypto backend

You completely skipped over the improvements. In effect, you show
yourself to be completely unresponsive to what were considered positive
changes to the author of the work.

Then you begin to pick apart what you think is wrong. It's not obvious
why you are doing it this way, and with regard to practically all
of your earlier e-mails addressed to me, I can only assume malice.

> So your src_compile() is now broken for Ninja users, and src_test()
> is broken altogether.  How about cmake-multilib eclass?

ninja is a thing? Can you explain what it is? Can you show me how it's
broken, and how I reproduce the ninja problem, pro forma by filing a bug
report at https://bugs.gentoo.org/

> > +DESCRIPTION="Library implementing the SSH2 protocol"
> > +HOMEPAGE="https://www.libssh2.org;
> > +SRC_URI="https://www.${PN}.org/download/${P}.tar.gz;
> > +
> > +LICENSE="BSD"
> > +SLOT="0"
> > +KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~mips ~ppc ~ppc64
> > ~s390 ~sh ~sparc ~x86 ~amd64-fbsd ~x86-fbsd ~amd64-linux ~x86-linux
> > ~ppc-macos ~x64-macos ~x86-solaris" +IUSE="gcrypt libressl mbedtls
> > test zlib"  
> 
> IUSE=test is not used at all.

So that's a minor problem we could fix even without a revision bump.
You could have pointed it out in that missing bug report.

> > +REQUIRED_USE="
> > +   ?? ( gcrypt libressl mbedtls )
> > +"
> > +
> > +RDEPEND="
> > +   !libressl?
> > ( >=dev-libs/openssl-1.0.1h-r2:0=[${MULTILIB_USEDEP}] )
> > +   gcrypt?
> > ( >=dev-libs/libgcrypt-1.5.3:0[${MULTILIB_USEDEP}] )
> > +   libressl? ( dev-libs/libressl:0=[${MULTILIB_USEDEP}] )
> > +   mbedtls? ( net-libs/mbedtls )  
> 
> By the way, MULTILIB_USEDEP certainly missing here.

This wants another explanation. How is this different from the ebuild
that went before, -r1? You don't even explain what you think the
problem is. You're not trying to be nice. I have to make an effort
to turn your comment into intelligible English.

MULTILIB_USEDEP *is* missing here? By here you presumably mean
net-libs/mbedtls needs it because that's the line your comment follows?
Right?

So you could have said:

That should be
mbedtls? ( net-libs/mbedtls[MULTILIB_USEDEP] )

> > +   zlib? ( >=sys-libs/zlib-1.2.8-r1[${MULTILIB_USEDEP}] )
> > +"
> > +DEPEND="${RDEPEND}"
> > +
> > +PATCHES=(
> > +   "${FILESDIR}"/${PN}-1.8.0-libgcrypt-prefix.patch  
> 
> You sure this autoconf patch is needed for CMake build?

It's harmless. See above. But you also know that it is not needed, but
you're not kindly pointing that out, you're just taking any opportunity
to make a snide comment.

> > +   "${FILESDIR}"/${PN}-1.8.0-mansyntax_sh.patch
> > +   "${FILESDIR}"/${PN}-1.8.0-openssl11-memleak.patch
> > +   "${FILESDIR}"/${PN}-1.8.0-openssl11.patch
> > +)
> > +
> > +multilib_src_configure() {
> > +   local crypto_backend=OpenSSL
> > +   if use gcrypt; then
> > +   crypto_backend=Libgcrypt
> > +   elif use mbedtls; then
> > +   crypto_backend=mbedTLS
> > +   fi
> > +
> > +   local mycmakeargs=(
> > +   -DBUILD_SHARED_LIBS=ON
> > +   -DCRYPTO_BACKEND=${crypto_backend}
> > +   -DENABLE_ZLIB_COMPRESSION=$(usex zlib)
> > +   )
> > +   cmake-utils_src_configure
> > +}
> > +
> > +multilib_src_install_all() {
> > +   einstalldocs
> > +   find "${D}" -name '*.la' -delete || die  
> 
> They must have hacked that CMake hard to get it to generate .la files.

So again it's harmless? But you're in snide mode now.

> > +   mv "${D}"/usr/share/doc/${PN}/*
> > "${D}"/usr/share/doc/${PF}/ || die
> > +   rm -r "${D}"/usr/share/doc/${PN}/ || die
> > +}
&g

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: net-libs/libssh2/

[Jeroen Roovers]

On Mon, 01 Oct 2018 17:00:24 +0200
Michał Górny  wrote:

> So your src_compile() is now broken for Ninja users, and src_test()
> is broken altogether.  How about cmake-multilib eclass?

DROP

> IUSE=test is not used at all.

THAT

> By the way, MULTILIB_USEDEP certainly missing here.

BLOODY

> You sure this autoconf patch is needed for CMake build?

AWFUL

> They must have hacked that CMake hard to get it to generate .la files.

ATTITUTE

Re: [gentoo-dev] Signed-off-by verification incoming

[Jeroen Roovers]

On Sat, 29 Sep 2018 15:25:25 +0200
Dirkjan Ochtman  wrote:

> On Sat, Sep 29, 2018 at 3:14 PM Jeroen Roovers  wrote:
> 
> > 0a) Explain to me how to fix my commits that I now can't push, or
> Try git rebase -i and use "r" for "reword" on every commit.

`git rebase ---signoff` did the trick.


Kind regards,
 jer

Re: [gentoo-dev] Signed-off-by verification incoming

[Jeroen Roovers]

On Sat, 29 Sep 2018 10:19:10 +0200
Michał Górny  wrote:

> Hi, everyone.
> 
> Just FYI, I'm going to enable the git hook to verify Signed-off-by
> tags on gentoo.git (most likely all repos later on).  I've tested it
> against all the test cases I could think of but if you have any
> trouble pushing, please ping me or others in #-infra.
> 
> Please note that for the hook to work:
> 
> 1. Every commit must contain 'Signed-off-by' of the committer.
> 
> 2. You must use your @gentoo.org address in committer (this was
> already enforced)  and in Signed-off-by.
> 
> 3. You must use your real name *as stated in LDAP* in Signed-off-by
> (committer can be anything).  Both regular (cn) and ASCII (gecos)
> version is accepted, and the match should be case-insensitive (at
> least as far as case-insensitive works in bash).
> 
> If you need to change your real name to match your preferred spelling
> (e.g. 'Matt' to 'Matthew'), please ping us as well.
> 
> As a side note, I'd like to repeat that while this is not enforced,
> if you merge a copyrightable (i.e. non-trivial) external contribution,
> please get Signed-off-by from its author and append yours below it.
> 

remote: 8833535ff8f041d308284149193f5c7322b37b26: no GCO sign-off
present
remote: e034098e139484cddd1614b55b844898190b21d6: no GCO sign-off
present
remote: a1c64ac2ac71ef2291d472318d5ffc2218800cd4: no GCO sign-off
present
remote: 1e846c6372d629171b16282db5ce644577a991fc: no GCO sign-off
present
remote: e567d8374ec8cbb6f79ac1a3ceef3c71de529d6e: no GCO sign-off
present
remote: 6131f30065fbff4a50259b81b4e9e88b2ad03661: no GCO sign-off
present

Please:

0a) Explain to me how to fix my commits that I now can't push, or
0b) disable that hook immediately.
1) Update repoman to enforce it _before_ the commit is executed.
2) Wait for the repoman update to trickle down to all developers.
3) Announce it ahead of time.
4) Re-enable the hook.

Re: [gentoo-dev] Changing policy about -Werror

[Jeroen Roovers]

On Sun, 9 Sep 2018 14:32:21 +0300
Andrew Savchenko  wrote:

> Hi!
> 
> Our current -Werror policy demands unconditional removal:
> https://devmanual.gentoo.org/ebuild-writing/common-mistakes/index.html#-werror-compiler-flag-not-removed

Which is great.

> I think this is wrong, see bugs 665464, 665538 for a recent
> discussion why.

That's just QA failing to be human in one report and then again in
another report. It happens all the time and cannot be fixed, so you seem
to instead suggest banning -Werror wrong because some developers think
they can sanely cat-herd -Werror's overreaching effects.

> My point is that in *most* cases -Werror indeed should be removed,
> because upstream rarely can keep up with all possible configure,
> *FLAGS, compiler versions and arch combinations. But! In some cases
> — especially for security oriented software — this flag may be
> pertain and may be kept at maintainer's discretion.
  ^^^
Pertinent, you meant to say, I assume.

If you really have to support this mistaken (upstream) sense of
security, instead go for -Werror= (see gcc(1)) i.e. turn very
specific warnings into errors instead of turning _all_ warnings into
errors.

> The rationale is that -Werror usually points to dangerous
> situations like uninitialized variables, pointer type mismatch or
> implicit function declaration (and much more)

No it does not. It merely turns warnings (non-fatal) emitted by the
actual checks into errors (fatal). It does not cause any checks to be
performed or warnings to be issued by itself.

Setting or allowing a blanket -Werror therefore causes innocuous
warnings like this:

   warning: format not a string literal, argument types not checked
   [-Wformat-nonliteral]
   (In other words: FIXME: I didn't check this format because it was not
   a string literal and I cannot yet resolve those into an actual format
   defined elsewhere.*)

and this:

   # hppa2.0-unknown-linux-gnu-gcc -fstack-protector main.c
   cc1: warning: -fstack-protector not supported for this target

into hilarious errors.

To some those might look like succeeding security checks, but they're
really failing sanity checks.

> which may lead to serious security implications.
> 
> So, if maintainer has enough manpower to support this flag, we
> should allow to keep it. Of course if it will cause long-standing
> troubles (e.g. bugs opened for a long time) QA should have power to
> remove it or demand its removal.
> 
> So my proposal is:
> 
> 1) Deprecate QA policy with unconditional demand of -Werror removal.

You have yet to give arguments for its removal. Like, proper and
particular examples of where -Werror benefits everyone. So far I've
seen only some hand-waving of the (in)security banner. 

Unless you meant to say that security is improved when you can't
install the software when of -Werror prevents it from being built,
because then you've already solved the entire problem of the software's
purported vulnerabilities, indeed.

> 2) Add to devmanual's chapter on -Werror an exception clause about
> security-oriented software and maintainer's right to make final
> decision.

That clause will be the laughing stock of the security community.


Regards,
 jer


* We have plenty of bug reports already where one "security researcher"
points out that the build fails when the former warning is triggered
when -Werror is injected, and it might indeed look like a lurking
security issue if it weren't for the fact that the format sanity check
never took place.

Re: [gentoo-dev] [PATCH] use.desc: Improve description of USE=test

[Jeroen Roovers]

 Hi Kent,


On Sat, 25 Aug 2018 01:23:06 +1200
Kent Fredric  wrote:

> On Tue, 21 Aug 2018 22:29:29 -0400
> Mike Gilbert  wrote:
> 
> > Setting RESTRICT="!test? ( test )" is generally sufficient.  
> 
> But that would require setting that virtually *everything* that has
> both tests, and required dependencies for tests.

Oh, 2012 just called.

> Which, in my experience, is practically everything with tests.
> 
> To the point it seems like that should be the *default* mechanic, not
> a requirement that everyone pay not to have a randomly broken package.

"
  [S]etting FEATUTES=-test USE=-test means rebuilding a lot of the
  installed packages. Instead, since USE=test is special already (it
  should only affect what happens in src_test(), right?) we might as
  well disable the test phase, tell the user in einfo, and be done with
  it. We could even write that to vdb so that on the next run, the
  package is re-emerged but with src_test() getting run properly this
  time.
"

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


Kind regards,
 jer

[gentoo-dev] Fw: "Please let's talk if spamming everyone pointlessly is really needed."

[Jeroen Roovers]

Behold the magic of emergency announcements.

Begin forwarded message:

Date: Sat, 09 Jun 2018 12:56:03 +0200
From: "Andreas K. Huettel" 
To: Jeroen Roovers 
Cc: bugzi...@gentoo.org, com...@gentoo.org
Subject: Re: "Please let's talk if spamming everyone pointlessly is
really needed."


Am Donnerstag, 7. Juni 2018, 22:39:22 CEST schrieb Andreas K. Huettel:
> Am Donnerstag, 7. Juni 2018, 20:51:30 CEST schrieb Jeroen Roovers:  
> > What's going on here?
> > 
> > "Please let's talk if spamming everyone pointlessly is really
> > needed." ^^^
> > 
> > If your mind is made up about the point of mass
> > changes, then why bother enquiring about it? I would think infra@
> > takes such actions to protect the services, not to argue about the
> > merits of changes.  
> 
> This wasn't infra, this was me. Following a complaint on #g-comrel, I
> checked the bug backlog and saw that you changed (likely much) more
> than 50 bugs in a very short time. On a quick glance the changes were
> against longstanding policy.
>   

After team-internal discussion I've reactivated your account.

Please,

* involve the community on the mailing lists regarding similar policy
  changes,
* at least try coordinate with Infra whether mass mails in such cases
  could be suppressed somehow,
* and try to act in a way that the rest of us somewhat understands.

The ban can be reinstated if the majority of comrel thinks it's
necessary.

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, perl, libreoffice, comrel)

[gentoo-dev] ATTN: Fw: "Please let's talk if spamming everyone pointlessly is really needed."

[Jeroen Roovers]

 Hello fellow humans,


this is a brief headsup about my current inability to communicate
through the official channel bugs.gentoo.org because of what seems like
a ComRel[1] action[2] suspending my account. If you have important
information to share on the many hundreds of packages I maintain, do
not hesitate to use my e-mail address directly or approach me on IRC
(Freenode or OFTC).


Kind regards,
 jer


[1] I.e. the people purportedly responsible for ensuring proper
communications between members of the Gentoo Linux community.

[2]
https://rooversj.home.xs4all.nl/gentoo/2018-06-07-204422_1920x1080_scrot.png




Begin forwarded message:

Date: Thu, 07 Jun 2018 22:39:22 +0200
From: "Andreas K. Huettel" 
To: Jeroen Roovers 
Cc: bugzi...@gentoo.org, com...@gentoo.org
Subject: Re: "Please let's talk if spamming everyone pointlessly is
really needed."


Am Donnerstag, 7. Juni 2018, 20:51:30 CEST schrieb Jeroen Roovers:
> What's going on here?
> 
> "Please let's talk if spamming everyone pointlessly is really needed."
> ^^^
> 
> If your mind is made up about the point of mass
> changes, then why bother enquiring about it? I would think infra@
> takes such actions to protect the services, not to argue about the
> merits of changes.  

This wasn't infra, this was me. Following a complaint on #g-comrel, I
checked the bug backlog and saw that you changed (likely much) more
than 50 bugs in a very short time. On a quick glance the changes were
against longstanding policy.

Thank you for getting back.

* If you see the necessity to change a long-standing guideline, 
* and if that involves a lot of people getting a lot of non-informative 
bugmail ("spam"), 

I would be very grateful if you could 

* inform the community about the policy change on the mailing lists, 
* and coordinate with Infra so the mails are suppressed somehow.

Thank you. I will happily re-activate your account if you agree to
this, otherwise I'll defer a decision on that to the rest of comrel and
a vote.

> For my part, I was doing what I have been doing for more than a
> decade.  

That is part of the problem.

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, perl, libreoffice, comrel)

Re: [gentoo-dev] Proliferation of IUSE=static-libs in Gentoo

[Jeroen Roovers]

On Thu, 08 Mar 2018 16:40:44 +0100
Michał Górny  wrote:

> As part of that we also shouldn't deliver static libraries

OK, so you want to absolutely kill dead the only current sane way for
developers who use Gentoo to ship static binaries to their users'
target systems? Drive them away to another Linux distro that does
support being the build platform that they need? Or force everyone to
use EXTRA_ECONF"--enable-static" and hope for them that it works for
all packages? All just because static linking *between* ebuilds is bad?

> So, developers, please *stop adding USE=static-libs* to random
> libraries that have no reason whatever to be statically linked to.

You could just as well work on stopping the package manager from linking
to static libraries instead and leave other developers to add
IUSE=static-libs as they please, so that no one has to worry about
static linking of packages that we do support in the package manager.

Please rethink your stated opinion thoroughly.

Also, please drop "random" from every odd sentence you post - it makes
your target audience feel like they're idiots who "didn't get it".

Also, please stop marketing your opinions as set in stone policy -
you're here to discuss things and develop policy, but your condescending
and authoritarian tone isn't helping the argument.


Kind regards,
 jer

Re: [gentoo-dev] [PATCH 1/1] profiles: drop USE=cracklib from base/make.defaults.

[Jeroen Roovers]

On Fri, 22 Dec 2017 12:30:35 -0500
Michael Orlitzky <m...@gentoo.org> wrote:

> On 12/21/2017 02:27 PM, Jeroen Roovers wrote:
> > On Thu, 21 Dec 2017 10:10:30 -0500
> > Michael Orlitzky <m...@gentoo.org> wrote:
> >   
> >> The "cracklib" USE flag ... this commit removes it from
> >> base/make.defaults.
> >>
> >> Closes: https://bugs.gentoo.org/635698  
> > 
> > As there:  
> >> ...  
> > 
> > Let me (easily) counter that by stating that having cracklib in
> > place makes people pick better passwords. Especially the brand new
> > Linux users we see so many of might benefit from a default
> > mechanism that helps them make better security choices, but I am
> > sure even advanced users and systems administrators might set a
> > "temporary" POC password "quickly" and then later see their systems
> > go into production without a second thought about using stronger
> > passwords.

> I don't think that "some people want it enabled" is enough
> justification to keep this in the base profile that is the parent of
> all others.

OK, let me explain again.

In #gentoo we give a lot of attention and support to people who want to
set up full disk encryption, tor, VPNs, and other security mechanisms,
and this tells me that they actually want security. By saying that "some
people [might] want it enabled" you ignore one of the main reasons why
people turn to Gentoo Linux in the first place.

Having it enabled by default prompts new users and veteran users alike
to think about password safety, because this means that you get
reminded of possibly bad passwords *during* installation/while setting
up your services.

People can always disable it easily when they feel they do not need it
(any longer).

> If you disagree, please make your voice heard on the bug.

I already did that parallel to my response here. Note that *this* is
the proper venue for discussing sweeping changes like this, and that a
bug report that saw no input from anyone else for a couple of months
is not.

You already went ahead and committed that change without proper
discussion and waving away the input you did get suggesting you should
drop it, so I have now reverted it. Next time, please discuss your
problems with sane defaults like these before doing anything rash.

As quoted from the bug report, please address these:
1) Why you think having USE=cracklib enabled by default is a *problem*
which needs to be addressed by way of its removal. My original response
questioned that, but you didn't actually answer it.

2) What you plan to do to have USE=cracklib enabled by default. Two
people suggested you should keep this (one way or another) but instead
everyone is now without it enabled by default.

3) This bug report sat there for two months without notice to
gentoo-dev@ (and largely immaterial, without even a response from the
teams you CC'd). There was no proper discussion about a change that
affects not just developers, but all users, and hardly anyone knew
about it until you posted your patch.


Kind regards,
 jer

Re: [gentoo-dev] [PATCH 1/1] profiles: drop USE=cracklib from base/make.defaults.

[Jeroen Roovers]

On Thu, 21 Dec 2017 10:10:30 -0500
Michael Orlitzky  wrote:

> The "cracklib" USE flag has long (since 2007ish) been enabled by
> default for all profiles. But, the features that it provides are not
> critical for any of the packages that use it: typically, the library
> is used to evaluate a candidate password and to prevent the user from
> choosing a weak one.
> 
> Since the flag is not critical, and because we now have per-package
> USE defaults, this commit removes it from base/make.defaults.
> 
> Closes: https://bugs.gentoo.org/635698

As there:

So as to recap that lengthy discussion of the pros and cons of having
cracklib protect people from using bad passwords by default, to you it
does "not look critical". I can't even tell what you mean by that. I
guess you were picking low hanging fruits and thought you might start
some spring cleaning? Because that's the only thing I can make of this
change: it's old so it's probably useless.

Let me (easily) counter that by stating that having cracklib in place
makes people pick better passwords. Especially the brand new Linux
users we see so many of might benefit from a default mechanism that
helps them make better security choices, but I am sure even advanced
users and systems administrators might set a "temporary" POC password
"quickly" and then later see their systems go into production without a
second thought about using stronger passwords.

Please close that bug report.



Kind regards,
 jer

[gentoo-dev] autotools.eclass: automatically move configure.in to configure.ac

[Jeroen Roovers]

https://bugs.gentoo.org/show_bug.cgi?id=426262diff --git a/eclass/autotools.eclass b/eclass/autotools.eclass
index 2710bf827b..76a5c2eade 100644
--- a/eclass/autotools.eclass
+++ b/eclass/autotools.eclass
@@ -341,10 +341,11 @@ eautoconf() {
 		echo
 		die "No configure.{ac,in} present!"
 	fi
-	if [[ ${WANT_AUTOCONF} != "2.1" && -e configure.in ]] ; then
-		eqawarn "This package has a configure.in file which has long been deprecated.  Please"
-		eqawarn "update it to use configure.ac instead as newer versions of autotools will die"
-		eqawarn "when it finds this file.  See https://bugs.gentoo.org/426262 for details."
+	if [[ ${WANT_AUTOCONF} != "2.1" && -e configure.in && ! -e configure.ac ]] ; then
+		eqawarn "This package has a configure.in file which has long been deprecated. Since no"
+		eqawarn "configure.ac is present either, we rename configure.in to configure.ac. If"
+		eqawarn "this causes problems, please file a bug report and make it block bug #426262."
+		mv configure.{in,ac} || die
 	fi
 
 	autotools_run_tool --at-m4flags autoconf "$@"

Re: [gentoo-dev] Bugzilla package list editing

[Jeroen Roovers]

On Tue, 02 May 2017 14:32:13 +0200
Ulrich Mueller  wrote:

> > On Tue, 2 May 2017, Chí-Thanh Christopher Nguyễn wrote:  
> 
> > Also very common is that he changes fully qualified package names
> > (which is the correct syntax per [1]) into fully qualified package
> > atoms (which is the legacy syntax). Bug 616260 is one such
> > example.  
> 
> > [1] https://bugs.gentoo.org/page.cgi?id=fields.html  
> 
> Can't the stable-bot enforce the correct syntax?

Correct syntax, you say?

[1] says:
"""
= Version Dependencies =
Sometimes a particular version of a package is needed. Where this is
known, it should be specified. A simple example:

DEPEND=">=dev-libs/openssl-0.9.7d"
"""

What happens when you want an exact version? Can you write

"""
DEPEND="dev-libs/openssl-0.9.7d"
"""

instead? (Don't answer that, keep reading.)


[2] says:
"""
   Atom Prefix Operators [> >= = <= <]
  Sometimes you want to be able to depend on general
   versions rather than specifying exact versions all the time.
   Hence we provide standard boolean operators:

  Examples:
   >media-libs/libgd-1.6
   >=media-libs/libgd-1.6
   =media-libs/libgd-1.6
   <=media-libs/libgd-1.6
   https://devmanual.gentoo.org/general-concepts/dependencies/index.html
[2] https://dev.gentoo.org/~zmedico/portage/doc/man/ebuild.5.html

Re: [gentoo-dev] Bugzilla package list editing

[Jeroen Roovers]

On Tue, 2 May 2017 13:05:38 +0200
Chí-Thanh Christopher Nguyễn  wrote:

> One recent example of non-maintainer activity in the package list
> field is bug 613104, where he just removed the entire package list
> (and then marked the bug WONTFIX).

I've been in desktop-misc@ since at least October 2011. Additionally, I
explained to Harri Nieminen (Moiman) what was wrong with that bug
report, so I didn't "just" close the bug - I explained what was
happening to the packages that he does _not_ officially maintain.



Good luck with the cabal,
 jer

Re: [gentoo-dev] [PATCH] sys-libs/ncurses: Use --cache-file to speedup subsequent econf runs

[Jeroen Roovers]

On Tue, 21 Mar 2017 19:33:46 +0100
Michał Górny  wrote:

> If you really believe users should suffer a 30-minute rebuild for
> a build-time fix, sure.

Your statement implies that indiscriminately using the unstable branch
shouldn't involve unnecessary suffering, whereas I thought suffering is
the sole purpose of indiscriminately using the unstable branch.


Kind regards,
 jer

Re: [gentoo-dev] bzipped manpages

[Jeroen Roovers]

On Mon, 9 Jan 2017 09:08:22 +0100
Jan Stary  wrote:

> This is Gentoo 2.2 (4.4.6-gentoo x86_64).

That doesn't actually tell any Gentoo user anything about your system
except a very specific few bits of data which do not relate at all to
the rest of the subject matter of your e-mail.


Kind regards and good luck with [1],
 jer



[1] echo 'PORTAGE_COMPRESS=""' >> /etc/portage/make.conf; \
emerge -e world# [2]
[2] This emerge call might be quicker:
emerge -1 `find /usr/share/man -type f`
depending on the (maximum) length of the argument list.

Re: [gentoo-dev] Re: The changes about the stabilization process

[Jeroen Roovers]

On Wed, 28 Dec 2016 22:31:19 +
Ciaran McCreesh  wrote:

> We made a deliberate decision not to use the word "atom" in PMS
> because it means subtly different things in different contexts.

You're doing it again! You're not citing any decisions on actual
mailing lists, chat logs or in documentation, and you use qualifications
like "subtl[e]" to denote some deeper rationale that is apparently very
difficult to explain to the "uninitiated". Good job, if your job was to
deter the "uninitiated".

Where was that decision recorded? What subtle differences did you
perceive? Which contexts lead to those different meanings, and why did
you not keep "atom" and qualify it according to context? Did you
document the history, present and future of the term "atom" so you
could point out why it was rejected for future use? Even, what
real-world problem were you trying to solve in rejecting "atom"?


 jer

Re: [gentoo-dev] Re: The changes about the stabilization process

[Jeroen Roovers]

On Thu, 29 Dec 2016 03:49:30 +1100
Michael Palimaka  wrote:

> > Can you please avoid reintroducing the term "atom" there, when we
> > are trying to get rid of it elsewhere [1]? Note that PMS doesn't
> > define the term [2].  
> 
> Any suggestions for improved text? Ideally it would be
> stabilisation/keywording agnostic as the same field is used in both
> components.

How about "atoms". We've been using that for ages (regardless of what
PMS authors think) so why change it now? Alternatively, I would propose
to call them "bikesheds" as that will work just as well as any other
label and will succinctly refer to the creative process that made it
a replacement for "atoms".


 jer

Re: [gentoo-dev] linux-mod.eclass: Check for !TRIM_UNUSED_KSYMS

[Jeroen Roovers]

On Tue, 29 Nov 2016 10:39:04 -0500
Mike Gilbert <flop...@gentoo.org> wrote:

> On Tue, Nov 29, 2016 at 9:14 AM, Jeroen Roovers <j...@gentoo.org>
> wrote:
> > --- a/eclass/linux-mod.eclass
> > +++ b/eclass/linux-mod.eclass
> > @@ -566,6 +566,9 @@ linux-mod_pkg_setup() {
> > return
> > fi
> >
> > +   # External modules use kernel symbols (bug #591832)
> > +   export CONFIG_CHECK+=" !TRIM_UNUSED_KSYMS"
> > +
> > linux-info_pkg_setup;
> > require_configured_kernel
> > check_kernel_built;
> >  
> 
> There is no need to export CONFIG_CHECK to the environment here.

Interesting. The same is done in linux-mod_pkg_setup_binary(), so which?


 jer

[gentoo-dev] linux-mod.eclass: Check for !TRIM_UNUSED_KSYMS

[Jeroen Roovers]

--- a/eclass/linux-mod.eclass
+++ b/eclass/linux-mod.eclass
@@ -566,6 +566,9 @@ linux-mod_pkg_setup() {
return
fi

+   # External modules use kernel symbols (bug #591832)
+   export CONFIG_CHECK+=" !TRIM_UNUSED_KSYMS"
+
linux-info_pkg_setup;
require_configured_kernel
check_kernel_built;

Re: [gentoo-dev] Developer GitHub usernames

[Jeroen Roovers]

On Mon, 21 Nov 2016 20:36:42 +
Ciaran McCreesh  wrote:

> Wait what. Why am I being blamed for any of this? I assure you, Michał
> isn't one of my sockpuppet developer accounts, and my involvement with
> Github as a company is limited to them buying me an awful lot of
> free booze once. I think you might be seeing conspiracies in the
> wrong place...

Oh, might have misread something. Sorry, Ciaran.


 jer

Re: [gentoo-dev] Developer GitHub usernames

[Jeroen Roovers]

On Mon, 21 Nov 2016 10:01:47 +0100
Michał Górny  wrote:

> Since some of our people don't want to admit they're using GitHub or
> otherwise want to pretend they're not

Interesting how you simply can't understand that some people hate
mixing work and pleasure[1] and how you then need to ridicule what you
don't understand, Ciaran.


 jer



[1] Or indeed hate using some third party's proprietary website
that has the barest possible support for managing multiple user
profiles in a single account and seems to be geared toward the Web
2.0 or "social media" inclined.

Re: [gentoo-dev] Mirrors corrupts?

[Jeroen Roovers]

On Sat, 8 Oct 2016 14:52:13 +
Joakim Tjernlund  wrote:

> Tried several mirrors and I still get:


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

Re: [gentoo-dev] recent glibc commit breaks boost on sparc64

[Jeroen Roovers]

On Thu, 08 Sep 2016 18:49:06 -0400
alexmcwhir...@triadic.us wrote:

> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.

See what happened there?


Kind regards,
 jer

Re: [gentoo-dev] [PATCH] versionator.eclass: Add tests for parameter counts

[Jeroen Roovers]

On Sun, 24 Jul 2016 12:17:56 +0200
Michał Górny  wrote:

> But that's a social problem that could easily solved by more
> proactive retirements, and not a good API design point.

You need some trained and payed PR people to correct your writings
before they go to press or you will never be elected president.


 jer

Re: [gentoo-dev] new developers' keyword requests

[Jeroen Roovers]

On Fri, 20 May 2016 21:47:56 -0700
Matt Turner  wrote:

> On Thu, May 19, 2016 at 6:36 PM, Daniel Campbell 
> wrote:
> > To make sure I understand what you're getting at, are you saying
> > some devs get on board and then request to add keywords to packages
> > that they already maintain?  
> 
> No, you've misunderstood.
> 
> He's saying people add new packages and then speculatively add
> keywords for a bunch of architectures that they haven't tested.

No, that's already covered very well in the quizzes and devmanual.

What I mean is keyword requests of the type: "Hi, I maintain this
package now, and I'm very excited about it, so can I have these random
keywords added, please?"

I have plenty of examples of such keyword requests collected over the
years; anyone should be able to find them easily.


Regards,
 jer

Re: [gentoo-dev] new developers' keyword requests

[Jeroen Roovers]

On Thu, 19 May 2016 18:36:22 -0700
Daniel Campbell  wrote:

> To make sure I understand what you're getting at, are you saying some
> devs get on board and then request to add keywords to packages that
> they already maintain? If said arches are already supported in Gentoo
> I see little problem with that, especially if they intend on being
> part of the arch testing team for that arch or have access to the
> hardware.

I am not talking about adding architecture keywords to profiles/.
I am talking about adding architecture keywords to ebuilds.


Regards,
 jer

[gentoo-dev] new developers' keyword requests

[Jeroen Roovers]

Perhaps it's a good idea to add a section to the devmanual about adding
new keywords to packages.

Recruits in particular might benefit from some background on what
keywording means and when it should be done, especially before they
start maintaining packages and then realise their packages are so
beautiful that they positively *deserve* to have some random keywords
added. This is not productive.

The way it works is that users of
specific architectures find that a package works for them on their
systems (which have enough resources and have the correct interfaces for
that particular program to be used conveniently, and so on), and that
they then request that their architecture keyword be added. What
doesn't work is having a handful of keywords on a package that nobody
cares about who actually uses the architectures in question.

Since over the years the Random Keyword Requests happen a *lot* right
after recruitment, it might even be useful to ask about this in the
quizzes. (The answer: your time is better spent fixing actual bugs.
bumping versions, adding features and maintaining a stable branch,
rather than raising the architecture count for your packages for no
adequately explored reason.)


Kind regards,
 jer

Re: [gentoo-dev] [PATCH] eutils.eclass: Add awk wrapper - eawk - edit file in place

[Jeroen Roovers]

On Wed, 18 May 2016 19:31:38 -0400
Göktürk Yüksek  wrote:

> There could be some performance implications. cat will usually do
> slow, buffered I/O. cp tries to be smarter with allocation, i.e. it
> may take advantage of the btrfs specific clone to do a O(1) copy.

Really? We're talking about editing streams of usually a couple of
kilobytes and performance is what you're worried about? Because of
not using one particular filesystem maybe? Really?


 jer

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

[Jeroen Roovers]

On Sat, 7 May 2016 23:25:58 +0200
Michał Górny  wrote:

> Do you seriously expect this code to work? How about testing? Or
> reading diffs before committing?


Somebody could have a go at implementing this:

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

It's been brewing for half a decade. Maybe it's time. :)


Regards,
 jer

Re: [gentoo-dev] On banning merge commits

[Jeroen Roovers]

On Sun, 8 May 2016 05:53:42 -0700
Brian Dolbec  wrote:

> It is these
> larger commit branches that are much more difficult to "git pull
> --rebase && git push --signed" successfully without some other pushes
> in between causing a rejected non-fast forward push.

You mean doing

until ; do ; done

is not already as optimal as you could get?


 jer

Re: [gentoo-dev] Reminder: ALLARCHES

[Jeroen Roovers]

On Sun, 1 May 2016 16:16:59 -0700
Daniel Campbell <z...@gentoo.org> wrote:

> On 05/01/2016 07:03 AM, Andreas K. Huettel wrote:
> > Am Sonntag, 1. Mai 2016, 15:32:27 schrieb Jeroen Roovers:  
> >> On Sat, 30 Apr 2016 23:16:42 +0200  
> > 
> > (For the record, hppa is definitely NOT the problem.)
> >   
> Forgive me, I just pulled hppa out of the air as an example of a
> secondary, different arch. afaict nobody's really picking on a
> specific arch.

[Well, since we're trying to stay non-specific here and failing anyway,
I might as well add that HPPA currently has more than ten dozen open
stabilisation/keywording requests and that I find little time to
address them these days except for the bare necessities like security
keywording.]

The more generic problem is this. As I have said many times before,
doing generous sweeping stabilisations for obsolete architectures is
time-consuming and pointless. "One man and his magic script" is no cure
for our stabilisation efforts as you cannot expect any attention to
architecture specific details or environment in which those
architectures are used from a single person who hasn't even seen,
touched or smelled most of those architectures in hardware.

Consider that only few architectures may be considered "workstation
class", i.e. those you would nowadays use to develop/compile/test
software for other architectures on. Compared to ten or fifteen years
ago, few such architectures remain: Alpha, HPPA, MIPS and SPARC
workstations are fast becoming too slow, (open source) software no
longer supports their quirks, and keeping such basic modern day
workstation amenities as a browser alive for a specific architecture
requires a lot of love and still leaves open a huge performance gap
compared to x86, PowerPC and perhaps some of the faster ARM systems
(IA64 being in limbo). Packages are being "compile-tested" (whatever
that is) and branded "stable" while no-one actually makes sure keeping
those packages stable makes any sense. [I should know: HPPA runs a
stable Firefox that (with an ad blocker in place) takes a few _minutes_
to process the usual JavaScript attached to common web pages.]

In short, keeping the former workstation class architectures up to date
with workstation class packages (desktop environments, web browsers,
IDEs, wide support for scientific calculation, scripting languages, even
media players and professional audio sofware) is pointless, and yet the
evidence says that's exactly where the effort is going.

The solution is to have people with an actual interest in a specific
architecture determine whether stabilising a package is viable, and
taking sensible action, like dropping stable keywords where applicable.

Stabilising simply because maintainers need to clean up old ebuilds
simply prolongs the needless assignment of resources that will never be
used since we can already do this by running build systems on unstable
ebuilds without the need to make that distinction. Having ALLARCHES on
top of that means blindly stabilising for both obsolete and current
architectures, which actually adds on top of the existing problem and
creates new problems, like calling something "stable" that obviously
isn't because the label is applied without the QA.


 jer

Re: [gentoo-dev] Reminder: ALLARCHES

[Jeroen Roovers]

On Sat, 30 Apr 2016 23:16:42 +0200
"Andreas K. Huettel"  wrote:

> just as a small reminder, to ease the load on all arch teams:
> 
> If a stablerequest has the keyword ALLARCHES set, then 
> * the first arch that tests successfully and stabilizes 
> * can and *should* immediately stabilize for all requested arches!

can => is allowed
should => may

> Whether this keyword is set on a bug is decision of the package
> maintainer. 
> 
> For example, Perl team sets ALLARCHES normall for all pure-perl
> packages (i.e., no compilation / gcc involved).

And it means we're missing opportunities where "pure" interpreted
packages may test corner cases of the language implementation and find
bugs in (JIT or previously) "compiled" code. And that means we're
calling things "stable" that may expose such bugs that turn out not to
be corner cases at all and affect running systems in unpleasant ways.



 jer

Re: [gentoo-dev] [warning] the bug queue has 82 bugs

[Jeroen Roovers]

On Sat, 06 Feb 2016 22:02:45 +
"M. J. Everitt"  wrote:

> On 06/02/16 22:00, Alex Alexander wrote:
> > Our bug queue has 82 bugs!
> >
> > If you have some spare time, please help assign/sort a few bugs.
> >
> > To view the bug queue, click here: http://bit.ly/m8PQS5
> >
> > Thanks!
> >  
> Only 82? that's not, like, 4k ... :)
> http://tinyurl.com/maintainer-wanted .

Yes, that's because this e-mail report is about new and unassigned bug
reports, and you're talking about assigned bug reports about new
packages.


 jer

Re: [gentoo-dev] abusive behaviour / communications from a user

[Jeroen Roovers]

On Tue, 2 Feb 2016 11:14:20 +0800
Ian Delaney  wrote:

> Members of comrel

[...]

> Please consider this and assess as you see fit.

kthx


 jer

Re: [gentoo-dev] News item: Apache "-D PHP5" needs update to "-D PHP"

[Jeroen Roovers]

On Mon, 4 Jan 2016 01:26:28 +0100
Sebastian Pipping  wrote:

> Hi!
> 
> 
> Better late then never.  Posting 72 hours from now the earliest as
> advised by GLEP 42.  Feedback welcome as usual.
> 
> 
> ===
> Title: Apache "-D PHP5" needs update to "-D PHP"
> Author: Sebastian Pipping 
> Content-Type: text/plain
> Posted: 2016-01-04
> Revision: 1
> News-Item-Format: 1.0
> Display-If-Installed: app-eselect/eselect-php[apache2]
> 
> With >=app-eselect/eselect-php-0.8.1, to enable PHP support
> for Apache 2.x file /etc/conf.d/apache2 no longer

... 2.x, the file ...

> needs to read

=> should no longer read

> 
>   APACHE2_OPTS=". -D PHP5"
> 
> but
> 
>   APACHE2_OPTS=". -D PHP"
> 
> , i.e. without "5" at the end.  This change is related to

instead, i.e. ...

> unification in context of the advent of PHP 7.x.

Vague.

> With that change, guard "" in file
> /etc/apache2/modules.d/70_mod_php.conf
> has a chance to actually pull in PHP support.

We'd like to be pretty certain that PHP application server is going to
"actually" do that.

> Without updating APACHE2_OPTS, websites could end up serving
> PHP code (include configuration files with passwords)
> unprocessed to website visitors!

That would mean there is an additional (local) security problem.



 jer

Re: [gentoo-dev] gst-plugins-bad-1.6.2 No shmsink/shmsrc on armv7-hardfp

[Jeroen Roovers]

On Sat, 2 Jan 2016 11:43:17 +0530
Mandar Joshi  wrote:

> shmsink/shmsrc don't seem to get installed when installing
> gst-plugins-bad-1.6.2. I don't know if the problem exists on other
> arches as well.

That's what we have a bug tracker for:

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


 jer

Re: [gentoo-dev] [PATCH 10/15] perl-module.eclass: Rename SRC_TEST to DIST_TEST in EAPI=6 and default to "do parallel"

[Jeroen Roovers]

On Fri, 11 Dec 2015 22:03:06 +0100
dilfri...@gentoo.org wrote:

> From: "Andreas K. Huettel (dilfridge)" 
> 
> ---
>  eclass/perl-module.eclass | 40
> +++- 1 file changed, 23
> insertions(+), 17 deletions(-)
> 
> diff --git a/eclass/perl-module.eclass b/eclass/perl-module.eclass
> index efcc47c..0d428d2 100644
> --- a/eclass/perl-module.eclass
> +++ b/eclass/perl-module.eclass
> @@ -154,6 +154,8 @@ if [[ ${EAPI:-0} = 5 ]] ; then
>   
> SRC_URI="mirror://cpan/authors/id/${MODULE_AUTHOR:0:1}/${MODULE_AUTHOR:0:2}/${MODULE_AUTHOR}/${MODULE_SECTION:+${MODULE_SECTION}/}${MODULE_A}"
>   [[ -z "${HOMEPAGE}" ]] && \
>   HOMEPAGE="http://search.cpan.org/dist/${MODULE_NAME}/;
> +
> + SRC_TEST="skip"
>  else
>   DIST_NAME=${DIST_NAME:-${PN}}
>   DIST_P=${DIST_NAME}-${DIST_VERSION:-${PV}}
> @@ -168,7 +170,6 @@ else
>  fi

You're disabling src_test() by default in any ebuild that happens to
inherit perl-module. Everyone who wants a way around that has to set
STUPID_VARIABLE now. Why?


 jer

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-python/pyfltk/, dev-python/pyfltk/files/

[Jeroen Roovers]

On Sun, 8 Nov 2015 08:50:51 +0100
Michał Górny  wrote:

> you just removed the last version supporting python2.7.
> As a result, matplotlib and pygene can't be installed at all:

pyfltk-1.3.3 works absolutely fine with python2.7. I wonder who removed
_that_.


 jer

Re: [gentoo-dev] ChangeLog

[Jeroen Roovers]

On Mon, 2 Nov 2015 16:17:18 -0500
"Aaron W. Swenson"  wrote:

> Vadim, please don't top post.

But do quote some forty lines from the message you reply to. It
really helps in case someone lost the original, right? :-)


 jer

Re: [gentoo-dev] Github PR commenting policy

[Jeroen Roovers]

On Fri, 18 Sep 2015 20:09:16 -0400
Fernando Rodriguez  wrote:

> Github allows editting of comments in pull requests. Is there a
> policy regarding that? I've noticed a comment disappear which makes
> the rest of the conversation seem out of place.

My personal policy is to completely ignore anything Gentoo related that
gets posted on Github. I am also actively contemplating leaving the
Gentoo organisation on Github altogether since it's basically useless
(for reasons such as the one you mentioned) and since we have our own
bug tracker already.


 jer

Re: [gentoo-dev] ALLARCHES and the maintainer action(s)

[Jeroen Roovers]

On Sat, 19 Sep 2015 14:24:25 +0200
Agostino Sarubbo  wrote:

> Unfortunately some people forget to look at the KEYWORDS field and
> stabilize the package only for one architecture.

Funny to see how you use "forget" here. How about, laugh at and ignore?

> At this point I'm asking maintainer(s) to stabilize/keyword their
> packages when an arch developer made a stabilization and forget to do
> the task for all arches.
> 
> In this way you give an hand to the arch teams.

No, you don't. I'll just call that "stabilisation theatre" (harking back
to "security theatre") and leave it at that.


 jer

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: ChangeLog qt4-build-multilib.eclass

[Jeroen Roovers]

On Fri, 12 Jun 2015 19:05:18 +0200
Davide Pesavento p...@gentoo.org wrote:

  @@ -470,7 +470,7 @@
mv ${pcfile} ${ED}/usr/$(get_libdir)/pkgconfig
  || die done
eshopts_pop
  - rmdir ${D}/${QT4_LIBDIR}/pkgconfig || die
  + rmdir ${D}/${QT4_LIBDIR}/pkgconfig
 
qt4_install_module_qconfigs
qt4_symlink_framework_headers
 
  And now you're doing a QA violation. Just don't call rmdir if
  something doesn't exist instead of ignoring the result and letting
  it spit random errors, all into 'did not exist' basket.
 
 Wow. QA violation. Sounds quite exaggerated don't you think?

No.


 jer

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

[Jeroen Roovers]

On Sun, 7 Jun 2015 17:28:03 -0400
Mike Gilbert flop...@gentoo.org wrote:

 Sorry, I could I have sworn I saw something about easier scripting
 somewhere in the thread.

Now you have two problems. ;-)


 jer

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

[Jeroen Roovers]

On Sun, 7 Jun 2015 04:40:47 + (UTC)
Duncan 1i5t5.dun...@cox.net wrote:

 Well, yes, but vgacon is rather dated, now.

Never heard of a serial console? It's dated sure enough, but I for
one use them on a daily basis, and not by choice.


 jer

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: ChangeLog kde5.eclass

[Jeroen Roovers]

On Sun, 17 May 2015 06:08:56 +1000
Michael Palimaka kensing...@gentoo.org wrote:

15 May 2015; Michael Palimaka kensing...@gentoo.org
kde4-base.eclass: Sync with KDE overlay - update SRC_URI.
  
 
 This is a complete description of the changes made.

OK, then that dash should be interpreted as an em dash, I guess, and
Sync with KDE overlay is a development note intended for that overlay
(yeah, we downstreamed that!) that accidentally slipped into the main
tree, adding nothing useful.


  jer

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: ChangeLog kde5.eclass

[Jeroen Roovers]

On Sun, 10 May 2015 06:44:30 +0200
Michał Górny mgo...@gentoo.org wrote:

  +  09 May 2015; Manuel Rüger mr...@gentoo.org kde5.eclass:
  +  Sync with overlay.
 
 This isn't a really useful ChangeLog note (commit message), you know?
 Describe *what* you change, do not expect users to go try to figure
 out where the overlay is and which changes you merged.

Nothing positive happened yet to the ChangeLog entry. Instead we got
more.

  15 May 2015; Michael Palimaka kensing...@gentoo.org
  kde4-base.eclass: Sync with KDE overlay - update SRC_URI.

Hi KDE people, you can fix ChangeLog entries. So now you know.


 jer

Re: [gentoo-dev] Hey arch teams, we need your input!

[Jeroen Roovers]

On Sun, 26 Apr 2015 08:04:11 -0400
Rich Freeman ri...@gentoo.org wrote:

 On Sun, Apr 26, 2015 at 5:59 AM, Pacho Ramos pa...@gentoo.org wrote:
 
  Currently, a problem is that everybody uses different formatting
  for stabilization bug reports making them more difficult to be
  parsed.
 
 
 For clarity, are we talking about parsing by a human brain, or parsing
 by a computer program?

Both. If the Summary is structured properly, YOU can parse a list of
Summaries quicker[1] and a MACHINE can parse it more reliably.

 If the latter, would it make more sense to just break things out into
 fields, instead of carefully building a structured text field which we
 then have to carefully break back down?  We might as well start
 sticking xml in the summary.

Now you're breaking the human interface with XML.

 If we're talking about human parsing, can you give an example of how
 variation makes your life more difficult today?  I'm just trying to
 understand what we're trying to fix...

Reading through hundreds of Summaries. If the atoms and the request
variant are always in the same place, parsing by humans is MUCH quicker.

Why do I feel I keep pointing out the obvious (for around ten years
already)?


Kind regards,
 jer


[1] Especially when it doesn't contain fluff like please or the
umpteenth variant on stable.

Re: [gentoo-dev] Should this be considered a gcc bug?

[Jeroen Roovers]

On Tue, 21 Apr 2015 09:57:16 +0600 (NOVT)
gro...@gentoo.org wrote:

 However, after this fix the upstream CFLAGS were appended to the
 user-supplyed ${CFLAGS}. And the upstream CFLAGS contain -O3.

There is your problem. We filter out those compiler flags that affect
the output, so -O3 should go (and e.g. -Wall could stay).


 jer

Re: [gentoo-dev] Version Bumps

[Jeroen Roovers]

On Sat, 28 Mar 2015 12:16:30 +0100
Justin Lecher (jlec) j...@gentoo.org wrote:

 Please check packages more carefully e.g. comparing configure.ac,
 Makefile.am, README, INSTALL, setup.py, requirements.txt and what all
 those names are.

Also make sure your CApitalisation in ChangeLog MEssages is COrrect.

jlec → gentoo-x86 (sci-biology/allpathslg/) Version BUmp; move to
EAPI=5 and autotools-utils.eclass; thanks Martin Mokrejs for preparing
the bump
jlec → gentoo-x86 (net-analyzer/ospd/) Version BUmp; Drop py3 support, bug 
#530992


 jer

Re: [gentoo-dev] Re: [warning] the bug queue has 89 bugs

[Jeroen Roovers]

On Fri, 27 Feb 2015 17:03:40 + (UTC)
Duncan 1i5t5.dun...@cox.net wrote:

  BTW, maybe this process can be partially automated?
 
 AFAIK, it's a lot more automated than it used to be, but not yet
 fully automated.  I'm sure Jer can fill you in on the details.

Nothing about bug wrangling is automated, unless you mean the trivial
scripts individual wranglers might use to gather information.

Automating the processes of basic communication and relations
between/among humans is probably not within the scope of the Gentoo
Project for the next few years.


 jer

Re: [gentoo-dev] [PATCH 1/2] Document policy of not relying on implicit eclass inherits]

[Jeroen Roovers]

 From: Ian Delaney idel...@gentoo.org

 This single change will make my commits of last 2 years a violation
 of policy, in a retrograde manner ofcourse.  

You'll have to fix those ebuilds. The policy was already in place
before[1] you were around[2].

 The flaw here is that it is using a black and white and reductionist
 approach.

No, the flaw is that you directly use functions from an eclass that you
are not inheriting. That you have been doing it for two years doesn't
change anything.


 jer


[1]
http://archives.gentoo.org/gentoo-dev/message/95e9f3e489cb84949c4bc5e7399e0ddf
[2] https://bugs.gentoo.org/show_bug.cgi?id=390951

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

[Jeroen Roovers]

On Tue, 10 Mar 2015 20:58:06 +
Markos Chandras hwoar...@gentoo.org wrote:

 Would it be terribly difficult to set a template in the Summary
 field whenever the Keywording and Stabilization component is
 selected when filing a bug?

No, just very naive.

Just today I caught yet another fresh keywording request that
had neither the Keywording and Stabilization component nor the
KEYWORDREQ keyword set.


 jer

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

[Jeroen Roovers]

On Fri, 6 Mar 2015 14:27:38 -0500
Rich Freeman ri...@gentoo.org wrote:

 but if people are suffering burnout over editing the line it this
 doesn't seem like the biggest value-add to me.

That didn't happen.


 jer

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

[Jeroen Roovers]

On Thu, 05 Mar 2015 15:20:23 -0500
Michael Orlitzky m...@gentoo.org wrote:

 So jer format is something like %s - foo.

Yes. I now have a format named after me.

 I guess I subconsciously reverted to using a colon because that's what
 makes the most sense to me. But there is a little ambiguity with slots
 in the package atom.

That should be fine. To me it's all about increased legibility through
the use of _whitespace_, not the actual delimiter. Put there whatever
you want.

 Maybe we should ask the bug wranglers team to come up with some
 guidelines and stick them on the project page? Then we can do whatever
 they prefer.

What I haven't seen at all in the past six years is people doing what
b-w prefers. Which is why I'm currently on leave with regard to the
daily 5 hour job of bug wrangling. I simply burned out some two weeks
ago and I'm gradually picking up much more interesting tasks rather
than going back to the grind.

One of the major problems is that there is no format we agree on, which
gives plenty of bad examples in the tracker that are validated over and
over for users (broadly speaking, bugzilla users) picking their own
format based on whatever they can come up with. Every attempt to push a
standard has beached on bikeshedding about the format so far.


 jer

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

[Jeroen Roovers]

On Thu, 05 Mar 2015 20:01:23 +0100
Paweł Hajdan, Jr. phajdan...@gentoo.org wrote:

 I'm trying to find the best fix for
 https://bugs.gentoo.org/show_bug.cgi?id=535814
 
 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.

Put a space before the colon (or any delimiter you happen to prefer).
Both cpv:XYZ and cpv::ABC have a special meaning. If nothing else it
improves legibility through the simple application of whitespace.

As for the equal sign, portage should really simply support leaving it
out and interpret '=' as the default. Functionally there should be no
difference between '=a/b-c' and 'a/b-c' anyway, and yet it trips up
emerge.


 jer

Re: [gentoo-dev] [PATCH] qmake-utils.eclass: add qt{4,5}_get_bindir helper functions

[Jeroen Roovers]

On Wed, 18 Feb 2015 19:58:29 +0800
Ben de Groot yng...@gentoo.org wrote:

 The attached patch proposes two helper functions to be added to
 qmake-utils.eclass. These functions echo the correct directory where
 qt binaries such as moc and lrelease are located. They can be used in
 ebuilds when such binaries need to be called directly. (Ebuilds should
 not rely on qtchooser for this.)
 
 Please review before I commit.

Looks good (barring what Davide noted).

Do you have a list of ebuilds that might benefit?

I know net-analyzer/wireshark might, but it doesn't even use
qmake-utils.eclass right now simply because it doesn't use qmake (but it
does use moc and uic, so I wouldn't expect to find those functions in an
eclass seemingly about qmake).


 jer

Re: [gentoo-dev] ebuild copyright assignment

[Jeroen Roovers]

On Wed, 18 Feb 2015 08:48:19 +0100
Justin (jlec) j...@gentoo.org wrote:

 On 18/02/15 08:40, Jeroen Roovers wrote:
  I seem to recall the developer quizzes may have had (or indeed
  requested) some more information on this matter.
 
 The test ebuild focuses on this topic.

What is that?


 jer

Re: [gentoo-dev] ebuild copyright assignment

[Jeroen Roovers]

On Wed, 18 Feb 2015 09:34:21 +0100
Justin (jlec) j...@gentoo.org wrote:

 At the end of the review session we ask the recruits to fix an ebuild
 which has numerous technical and, as mentioned, legal aspects to take
 care of.

That's a novelty I wasn't aware of, then. The technical
practicalities of copyright assignment have a legal basis which I
assume the test ebuild question(s) doesn't quiz recruits on.


jer

[gentoo-dev] ebuild copyright assignment

[Jeroen Roovers]

On Mon, 16 Feb 2015 06:39:51 -0500
Mike Frysinger vap...@gentoo.org wrote:

 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.

Correct, but I have my doubts about the allegedly wobbly legal basis. I
do vividly recall reading these:

http://www.gentoo.org/proj/en/devrel/copyright/index.xml
http://web.archive.org/web/20040604022011/http://www.gentoo.org/doc/en/policy.xml

Copyright in ebuilds (and documentation) should always be assigned to
Gentoo Technologies. Developers must never put their own names in
copyright lines. For more information, please see
http://www.gentoo.org/proj/en/devrel/copyright-assignment.xml
http://web.archive.org/web/20040624223240/http://www.gentoo.org/proj/en/devrel/copyright-assignment.xml

(Page moved to
http://www.gentoo.org/proj/en/devrel/copyright/index.xml
http://web.archive.org/web/20040618235041/http://www.gentoo.org/proj/en/devrel/copyright/index.xml)

This was the pseudo-legal language in place when I became a developer,
and as of this day I still assume all ebuilds' copyright MUST be
assigned to the project. The language does seem to have disappeared
from the website, though. Regardless, the mechanism was that by way of
adding that header, you assign all rights to the Gentoo Foundation,
nee Gentoo Technologies.

I seem to recall the developer quizzes may have had (or indeed
requested) some more information on this matter.

I seem to recall the wobbly legal basis assumed that the entire ebuild
format was copyrighted, which I would agree is unenforceable. But the
language that used to say all ebuilds' copyrights should be assigned
to [Gentoo] would still hold.

Note that I am not talking about QA actions or other trivial stuff that
happened in the tree one day here - I'm just wondering where the legal
language from 2004 went.


 jer

Re: [gentoo-dev] missing opengl dependency header

[Jeroen Roovers]

On Thu, 12 Feb 2015 14:46:17 +0100
Nicolas Sebrecht nicolas.s-...@laposte.net wrote:

 I've compiled love2d-0.9.1 from the sources with Gentoo.

We cannot fix what you do while you work around the package manager. If
it has an ebuild that fails, then we can help you. This mailing list
certainly isn't the right place to seek support with that, and the bug
tracker might be neither if no ebuild controls that build attempt.

 In fact, /usr/include/GL/glext.h is a relative symlink to
   ../../lib64/opengl/global/include/GL/glext.h

Please file a bug report if that is still appropriate.


 jer

[gentoo-dev] Re: [gentoo-dev-announce] lastrite; dev-python/cl

[Jeroen Roovers]

On Thu, 12 Feb 2015 14:46:41 +0800
IAN DELANEY idel...@gentoo.org wrote:

 # Ian Delaney idel...@gentoo.org (12 Feb 2015)
 # upstream found to be dead, hash values now fail,
 # no longer has relevance, masked for removal in 30 days
 app-office/openerp-client
 app-office/openerp-server
 app-office/openerp-web

Something went wrong here. What is the relation between dev-python/cl
and these three?


 jer

Re: [gentoo-dev] Suggestion about how to tell ATs that a package can be stabilized on all arches at the same time

[Jeroen Roovers]

On Sun, 08 Feb 2015 11:17:19 +0100
Pacho Ramos pa...@gentoo.org wrote:

 Many times has raised the question about how we could handle those
 packages (like icon packs, wallpapers...) that are not arch dependent
 and, then, could be stabilized all at the same time by the first arch
 team that is going to stabilize it.

If you do that, then what is the point of having a stable request in
the first place? The many-eyeballs argument is gone then, so what are we
left with?

It isn't a team that is doing the stabilisation, it's a single person
who may or may not have looked at what the new version does and how
well it installs, and may or may not feel some pressure to rush it.

As I said before many times, having more people on more architecture
teams look at the same problem actually helps catch bug at a late
stage but arguably still in time. Removing or weakening that last line
of defence (either by having a single person do stabilisations for
multiple architectures, or by removing most architecture teams from each
single task) will increase the bug rate for stable ebuilds (even more).


 jer

Re: [gentoo-dev] about the stable requests

[Jeroen Roovers]

On Sat, 31 Jan 2015 14:40:47 +0100
Agostino Sarubbo a...@gentoo.org wrote:

 Looks like everyone is file stable requests with own 
 rules or better to say is without common rules.

What is the problem?

 I'd like to document a sort of best-practice(s) on 
 our wiki.

 Who want to partecipate?

It's a wiki. Nothing is stopping you from drafting anything and then
proposing to make that into something canonical.


 jer

Re: [gentoo-dev] Things one could be upset about

[Jeroen Roovers]

On Sat, 17 Jan 2015 13:44:21 +0100
Dirkjan Ochtman d...@gentoo.org wrote:

 Also, I hate something like
 ['dev-python/restkit[python_targets_python2_7(-)?,-python_single_target_python2_7(-)]'].
 What the hell kind of warning is that? I guess maybe these are the
 results of USE_EXPAND trickery and what not, but it would sure be nice
 to have something more readable.

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


 jer

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libuv: libuv-1.2.1.ebuild ChangeLog

[Jeroen Roovers]

On Mon, 19 Jan 2015 17:02:11 -0500
Rich Freeman ri...@gentoo.org wrote:

 You're complaining about how somebody made a fix that they wouldn't
 have had to make but for the commit you made without consulting with
 them.

No, I didn't do that commit at all and only a little complaining. This
is between hasufell and patrick. I see now how you're confused there,
so I'll skip the rest of your explaining since it shouldn't have been
addressed to me at all. :)


 jer

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libuv: libuv-1.2.1.ebuild ChangeLog

[Jeroen Roovers]

On Fri, 16 Jan 2015 15:26:55 +
hasufell hasuf...@gentoo.org wrote:

 Patrick Lauer (patrick):
  patrick 15/01/16 04:16:55
  
Modified: ChangeLog
Added:libuv-1.2.1.ebuild
Log:
Bump

 
 I expect people to ask me for review if they bump any of my packages.
 That includes QA team members.

The only (QA) problem I see is the pointless removal of the ebuild in
question and the subsequent addition of a pointless revision bump with
no clue as to why it was removed or why the revision bump was required:

*libuv-1.2.1-r1 (16 Jan 2015)
 
  16 Jan 2015; Julian Ospald hasuf...@gentoo.org
+libuv-1.2.1-r1.ebuild:
  version bump
 
  16 Jan 2015; Julian Ospald hasuf...@gentoo.org -libuv-1.2.1.ebuild:
  rm unreviewed ebuild


Also, nobody brought up the QA role but you.


 jer

Re: [gentoo-dev] Things one could be upset about

[Jeroen Roovers]

On Sat, 17 Jan 2015 19:35:09 +0800
Patrick Lauer patr...@gentoo.org wrote:

 * AutoRepoman catches on average maybe 2 user-visible breakages.
 Mostly removing stable on HPPA ;)
 Fix: Make repoman faster (tree-wide scans take ~2 CPU-hours)
 Fix: Remind people that using repoman is not optional

repoman doesn't check reverse dependencies for the package you're
working on.

eshowkw(1) displays keywording in a pretty nice graph. Avoiding removing
the (last) stable ebuild probably involves having that automatically
invoked on entering (or working in, at some point) a package directory
and actually reading the output before you decide to remove any ebuild.


 jer

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libuv: libuv-1.2.1.ebuild ChangeLog

[Jeroen Roovers]

On Mon, 19 Jan 2015 18:17:12 +0100
Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com wrote:

 The broken libuv-1.2.1.ebuild was not disabling unwanted addition of
 -g to CFLAGS. The fix for this problem affected installed files, so
 revision bump was required.

Yes, and I was talking about ChangeLog entries to that effect.


  jer

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libuv: libuv-1.2.1.ebuild ChangeLog

[Jeroen Roovers]

On Mon, 19 Jan 2015 10:21:15 -0500
Rich Freeman ri...@gentoo.org wrote:

 On Mon, Jan 19, 2015 at 4:40 AM, Jeroen Roovers j...@gentoo.org
 wrote:
 
  The only (QA) problem I see is the pointless removal of the ebuild
  in question and the subsequent addition of a pointless revision
  bump with no clue as to why it was removed or why the revision bump
  was required:
 
 
 You'd probably do well to read:
 https://en.wikipedia.org/wiki/Clean_hands
 
 The TL;DR of that is People who live in glass houses shouldn't throw
 stones.
 
 I get that you're probably not being serious, but if for some reason
 you are I'd suggest letting somebody else in QA handle it.
 
 And, really, next time just talk to somebody before you go bumping
 their ebuilds.  If they're not cooperative then you'll garner a lot
 more sympathy.  This is staff quiz kind of stuff.

I have no idea why you're telling me all that. I don't normally quote
excessive context but in this case I really don't see how my text and
your text connect.


 jer

Re: [gentoo-dev] metadata.xml unherd/-ization, v2

[Jeroen Roovers]

On Tue, 9 Dec 2014 12:59:26 +0100
Ulrich Mueller u...@gentoo.org wrote:

  On Tue, 9 Dec 2014, Michał Górny wrote:
 
  As for the exact details, I've pretty much decided to go for
  featurism here, IOW making everyone happy. It also proves how absurd
  typing maintainers is but if you really feel like having it, sure.
  The default is 'developer', herd/ tags would be converted into
  'herd' and there are other options including 'proxy-maintainer',
  'project', 'team' meant to fit all our wannabies. The diff explains
  the particular options.
 
 !ELEMENT maintainer ( email, (description| name)* )
  +!-- maintainer organizational type --
  +!-- developer: regular Gentoo developer (direct e-mail) --
  +!-- herd: herd (defined in herds.xml) --
 
 As the previously stated goal was to get rid of herds, I don't
 understand why you want to reintroduce them as a value of the
 type attribute. The existing herd elements should become either
 type=project or type=team (everything that is not a project,
 I suppose).

Probably because of the rather verbose criticism brought forward by a
single developer.


 jer

Re: [gentoo-dev] Running repoman on the portage tree

[Jeroen Roovers]

On Tue, 18 Nov 2014 21:17:19 -0500
Alec Ten Harmsel a...@alectenharmsel.com wrote:

 * It took over 4 hours

Fun! 

 * So many (~3MB output) warnings, especially upstream parallel
 compilation bug... thought autoconf handled this, but I guess not

autoconf doesn't fix build systems like that. Also, repoman misses a
lot of those `(make|MAKEOPTS=).* -j1' strings so your report is
incomplete. ;)


 jer

Re: [gentoo-dev] [gentoo-project] Re: towards a more distributed model

[Jeroen Roovers]

On Wed, 19 Nov 2014 18:54:05 +0100
hasufell hasuf...@gentoo.org wrote:

 At that point it is forked. I don't see what's wrong with forking.

Forking wouldn't be the problem. Duplication of effort would be the
problem.


 jer

Re: [gentoo-dev] [gentoo-project] Re: towards a more distributed model

[Jeroen Roovers]

On Thu, 20 Nov 2014 01:36:11 +0100
viv...@gmail.com viv...@gmail.com wrote:

  At that point it is forked. I don't see what's wrong with forking.
  Forking wouldn't be the problem. Duplication of effort would be the
  problem.

 worse, mutually incompatibility would be much worse

I was talking about what is problematic about the act of creating
another instance in a different overlay. Not about the
well-known problems that ensue afterwards.


  jer

Re: [gentoo-dev] REQUIRED_USE=test vs. repoman

[Jeroen Roovers]

On Sat, 08 Nov 2014 20:49:10 +0100
Thomas Kahle to...@gentoo.org wrote:

 However, repoman complains:
 
   REQUIRED_USE.syntax   1
media-libs/leptonica/leptonica-1.71-r1.ebuild: REQUIRED_USE: USE
 flag 'test' is not in IUSE
 
 I commited with -f, because I think repoman is wrong.  Any opinions?

repoman was right.

# ebuild leptonica-1.71-r1.ebuild test
Appending /newaches/gentoo/cvs/gentoo-x86 to PORTDIR_OVERLAY...
Forcing test.
Error(s) in metadata for 'media-libs/leptonica-1.71-r1':
  REQUIRED_USE: USE flag 'test' is not in IUSE


Now I can't test it.


 jer

Re: [gentoo-dev] Regarding my final year thesis

[Jeroen Roovers]

On Thu, 06 Nov 2014 14:25:46 +0100
Jauhien Piatlicki jauh...@gentoo.org wrote:

 Mathematics you said? That's nice. You can, for example, redesign our
 portage's dependency solving algorithm

More generally perhaps: do something interesting with the portage tree.
If not as directly useful as fixing dependency, a look at how bits of
the tree changed over time (particularly with regard to
inter-dependencies between the bits) could be much more interesting
than regarding any particular snapshot.

The other huge multidimensional tree we have is the bug tracker
database. Several social science majors have already tried to do
something intelligible with the bug tracker data (and failed in my
opinion) so I am confident that someone who doesn't have that socially
oriented view of networks might be able to come up with more outrageous
and interesting viewpoints on how the bug tracker actually works and how
various bits of it interconnect, or doesn't work and don't connect,
respectively.


 jer

Re: [gentoo-dev] RFC: future.eclass

[Jeroen Roovers]

On Thu, 06 Nov 2014 12:40:33 -0800
Zac Medico zmed...@gentoo.org wrote:

 On 11/06/2014 12:11 PM, Michał Górny wrote:
  # multilib.eclass collisions
  get_libdir() { future_get_libdir ${@}; }
  # eutils.eclass collisions
  einstalldocs() { future_einstalldocs ${@}; }
 
 This collision handling mechanism seems pretty reasonable.
 Alternatively, maybe it could die if the functions are already
 defined, and advise the developer that future should be inherited
 later than multilib and eutils.

I'm not aware of any current definition of order in eclass inheritance.
We sure have issues with inheriting eclasses in a different order giving
different results now. Is this something that's in the works for a
future EAPI, then?


 jer

Re: [gentoo-dev] RFC: future.eclass

[Jeroen Roovers]

On Thu, 06 Nov 2014 13:42:43 -0800
Zac Medico zmed...@gentoo.org wrote:

 On 11/06/2014 01:32 PM, Jeroen Roovers wrote:
  I'm not aware of any current definition of order in eclass
  inheritance.
 
 Maybe PMS doesn't say anything about the order (yet). However, I'm
 fairly sure that all package managers process eclasses in the same
 order that they are passed as arguments to inherit. Otherwise,
 eclasses would not be able to properly override functions defined by
 eclasses earlier in the inherit chain.

If the order is important, then the ebuild should call each phase or
utility function explicitly. Expecting the order of inheritance to
convey the same thing instead of making explicit calls might work from
the package manager's perspective, but the ebuild writer is lost in the
woods. With that in mind we might argue that a change in the order of
inheritance should never cause a different outcome.

 In the context of future.eclass, eutils and multilib could simply
 check if the relevant functions were defined earlier, and die in that
 case.

Would the bash internal `readonly -f' work for that?

  We sure have issues with inheriting eclasses in a different order
  giving different results now. Is this something that's in the works
  for a future EAPI, then?
 
 No, but as said, I'm fairly sure that all package managers process
 eclasses in the same order that they are passed as arguments to
 inherit.

Well, that's convenient but you should probably not start relying on
it now. In that case we might want to discuss inheriting in
alphabetical order and numbering the eclasses cleverly, too. Or rename
this one to zfuture.eclass.


 jer

Re: [gentoo-dev] Last rites media-fonts/oxygen-fonts

[Jeroen Roovers]

On Thu, 06 Nov 2014 22:03:26 +0100
Manuel Rüger mr...@gentoo.org wrote:

 # Manuel Rüger mr...@gentoo.org (6 Nov 2014)
 # Use kde-base/oxygen-fonts instead
 # Masked for removal in 30 days
 media-fonts/oxygen-fonts

That one wasn't up for a pkgmove?


  jer

Re: [gentoo-dev] Last rites media-fonts/oxygen-fonts

[Jeroen Roovers]

On Thu, 06 Nov 2014 23:44:24 +0100
Manuel Rüger mr...@gentoo.org wrote:

 It could have been introduced to the tree as a pkgmove, but it wasn't.
 The best solution for now is imho to lastrite it.

You could still do the pkgmove right now, and not wait thirty days. :)


  jer

Re: [gentoo-dev] Last rites media-fonts/oxygen-fonts

[Jeroen Roovers]

On Thu, 6 Nov 2014 22:49:38 +
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:

 Not if the new package has already been added you can't. Moving a
 package on top of an existing package is very very bad.

Also, the versions don't actually match so the content will probably
have changed. Oh well.


 jer

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-roguelike/stone-soup: stone-soup-0.14.1.ebuild stone-soup-0.15.1-r1.ebuild stone-soup-0.15.1.ebuild stone-soup-0.13.2.ebuild stone-soup

[Jeroen Roovers]

On Wed, 05 Nov 2014 17:06:52 +0100
hasufell hasuf...@gentoo.org wrote:

 Could you elaborate how to query that field via eix which is the
 de-facto standard for finding packages?

The official standard for finding packages is packages.gentoo.org. It
(and the somewhat popular eix) have no problems at all reading
the DESCRIPTION variable from the actual ebuilds.

# eix eix
[I] app-portage/eix
 Available versions:  0.25.5 0.29.3{tbz2} ~0.29.6 ~0.30.0 ~0.30.1
 ~0.30.2 {clang debug +dep doc nls optimization security sqlite
 strong-optimization strong-security swap-remote tools
 zsh-completion LINGUAS=de ru}
 Installed versions:
 0.29.3{tbz2}(06:55:52 27/05/14)(dep doc nls sqlite -clang -debug
 -optimization -security -strong-optimization -strong-security
 -swap-remote -tools -zsh-completion LINGUAS=-de -ru)

 Homepage:http://eix.berlios.de
 Description: Search and query ebuilds, portage incl. local
 settings, ext. overlays, version changes, and more

In this splendidly exemplary case, eix actually read the description
from the ebuild - its very own metadata.xml does not have one.


 jer

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-roguelike/stone-soup: stone-soup-0.14.1.ebuild stone-soup-0.15.1-r1.ebuild stone-soup-0.15.1.ebuild stone-soup-0.13.2.ebuild stone-soup

[Jeroen Roovers]

On Wed, 5 Nov 2014 17:27:51 +0100
Jeroen Roovers j...@gentoo.org wrote:

 On Wed, 05 Nov 2014 17:06:52 +0100
 hasufell hasuf...@gentoo.org wrote:
 
  Could you elaborate how to query that field via eix which is the
  de-facto standard for finding packages?
 
 The official standard for finding packages is packages.gentoo.org. It
 (and the somewhat popular eix) have no problems at all reading
 the DESCRIPTION variable from the actual ebuilds.

Which has me wondering if anything out there except human eyes every
reads longdescription.


  jer

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-roguelike/stone-soup: stone-soup-0.14.1.ebuild stone-soup-0.15.1-r1.ebuild stone-soup-0.15.1.ebuild stone-soup-0.13.2.ebuild stone-soup

[Jeroen Roovers]

On Wed, 05 Nov 2014 17:36:34 +0100
hasufell hasuf...@gentoo.org wrote:

 You were proposing that I strip down the DESCRIPTION field in my
 ebuild and put the keywords relevant for finding the package into
 longdescription in tag metadata.xml.

No, I was proposing the overly long description should go to
longdescription /. As for the DESCRIPTION variable, it looks like it
can be shortened easily.

Dungeon Crawl Stone Soup is a role-playing roguelike game of
exploration and treasure-hunting in dungeons
Dungeon Crawl Stone Soup - a roguelike RPG dungeon crawler

Since it appears to be an actual roguelike (and not merely a game with
permadeath as is how these days people interpret it) you could actually
get it down to: Dungeon Crawl Stone Soup - a dungeon crawler.

 That leads to the question how do you read the longdescription field
 from metadata.xml via eix or other commonly used tools for finding
 packages. packages.gentoo.org doesn't allow it either.

packages.g.o simply links to metadata.xml. I guess that works.


 jer

Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11

[Jeroen Roovers]

On Fri, 31 Oct 2014 16:28:56 +
Diego Elio Pettenò flamee...@flameeyes.eu wrote:

 So who wants to pick up the pieces now? Because I'm almost pissed off
 enough to turn down the tinderbox and give a big FU to Gentoo already.
 https://bugs.gentoo.org/show_bug.cgi?id=527608

Apparently Mr. Frysinger needs an education?


 jer

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-roguelike/stone-soup: stone-soup-0.14.1.ebuild stone-soup-0.15.1-r1.ebuild stone-soup-0.15.1.ebuild stone-soup-0.13.2.ebuild stone-soup

[Jeroen Roovers]

On Mon, 27 Oct 2014 19:58:15 +
hasufell hasuf...@gentoo.org wrote:

 I want to keep the over-long description unless we have some sort of
 ebuild aliases.

longdescription /


 jer

Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11

[Jeroen Roovers]

On Sat, 18 Oct 2014 14:03:07 -0400
Michael Orlitzky m...@gentoo.org wrote:

 If this is what's holding up a tinderbox run, add me to the bug
 template as a CC and I'll personally download and attach every log to
 bugzilla.

If the bugzilla API allows it, a very simple script should be able to
do this, including compression.


 jer

Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11

[Jeroen Roovers]

On Sun, 19 Oct 2014 10:14:18 +0200
Jeroen Roovers j...@gentoo.org wrote:

 On Sat, 18 Oct 2014 14:03:07 -0400
 Michael Orlitzky m...@gentoo.org wrote:
 
  If this is what's holding up a tinderbox run, add me to the bug
  template as a CC and I'll personally download and attach every log
  to bugzilla.
 
 If the bugzilla API allows it, a very simple script should be able to
 do this, including compression.

That said, having people{who?}[1] resolve those bugs as NEEDINFO is
pretty silly. The only point in requiring attached build logs is to
make sure we don't depend on resources beyond the project's control[2].
Clearly those tinderbox build logs already meet that requirement and
should be allowed.


 jer


[1] Oh wait, no, I think I know this one. You should be ashamed.
[2] To make it even more silly, you could put those in
dev.gentoo.org/~${USER}/public_html and nothing would really
change. Or assign a Gentoo controlled domain name to that Amazon
thingy and nothing would really change.

Re: [gentoo-dev] RFC: News item regarding c++98 vs c++11

[Jeroen Roovers]

On Sun, 19 Oct 2014 18:53:43 -0400
Anthony G. Basile bluen...@gentoo.org wrote:

 we may want to inform users about breakage at the ABI level in case
 they do something like add -std=c++11 to their global CXXFLAGS.

You mean tell them they get to keep the pieces?


 jer

Re: [gentoo-dev] Re: RFC: Deprecating and killing herds in metadata.xml

[Jeroen Roovers]

On Wed, 8 Oct 2014 00:07:07 +0200
Tom Wijsman tom...@gentoo.org wrote:

 If the name is omitted, then we lose that; that is not the way
 forward.

I'm pretty sure we already addressed this in another branch of this
thread. Bringing up the workings of IRC bots doesn't add anything.


 jer