[gentoo-dev] Last rites: dev-python/couchdb-python

2020-11-05 Thread Dirkjan Ochtman
# Dirkjan Ochtman  (2020-11-05)
# Incorrect DISTUTILS_USE_SETUPTOOLS value, dead upstream.
# Removal in 30 days. Bug #748063
dev-python/couchdb-python



Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual

2019-10-26 Thread Dirkjan Ochtman
On Sat, Oct 26, 2019, 05:59 Kent Fredric  wrote:

> On Fri, 25 Oct 2019 15:03:39 -0700
> Georgy Yakovlev  wrote:
>
> > not used anymore
> >
> > Closes: https://bugs.gentoo.org/695698
> > Signed-off-by: Georgy Yakovlev 
>
>
> Its likely this removal will cause the same kinds of problems faced by
> the recent virtual/pam removal, just its more insidious, as the
> dependency on the virtual is hidden away inside an eclass.
>
> But this still means that anything users have already installed will
> still depend on this, and without --changed-deps=y, it will break
> portage's resolution of anything currently installed using this crate.
>
> You can work-around this by -r1 bumping everything that used this
> eclass  but this just goes to show why there's policy against
> eclasses changing the dependencies of their consumers without any
> consumer involvement.
>

In most if not all cases, this is just a build-time dependency. Do we
really have all these problems for build-time only dependencies?

>


[gentoo-dev] Re: [PATCH] cargo.eclass: add cargo_live_src_unpack()

2019-08-29 Thread Dirkjan Ochtman
On Thu, Aug 29, 2019 at 7:26 AM Georgy Yakovlev 
wrote:

> This function will allow using 'cargo fetch' during src_fetch
> Since only new cargo supports that, all live packages will
> have to depend on >=rust-1.37.0
>
>
Looks okay to me.

Regards,

Dirkjan


Re: [gentoo-dev] [PATCH] CPU_FLAGS_X86: Introduce 'sha' flag

2019-07-18 Thread Dirkjan Ochtman
On Thu, Jul 18, 2019, 15:53 Michał Górny  wrote:

> Introduce 'sha' flag that corresponds to SHA-NI instruction set.
> This has two potential users, and is present in git version
> of cpuid2cpuflags (pending release once the flag is added).
>

A bit of bikeshedding: as I understand it, SHA-NI covers SHA-1 and SHA-256,
but not SHA-3 or some of the other SHA-2 variants. Maybe name it sha-ni or
sha_ni to be more accurate?

>


[gentoo-dev] Gentoo on Discord

2019-04-29 Thread Dirkjan Ochtman
In this article on chat services used for OSS:

https://catfox.life/2019/04/28/keeping-libre-software-accessible-to-all/

I was surprised to see a mention of Gentoo as a project that uses "Discord
as an official method of communication". When I searched, I indeed found
https://discordapp.com/invite/gentoo. However, I'd never before heard we
were using Discord (and didn't find any mentions of Discord on the -dev or
-project mailing lists).

Is this indeed an official venue? It's not listed on
https://gentoo.org/support/ (which does mention IRC).

Regards,

Dirkjan


[gentoo-dev] [PATCH] eclass: add rust-toolchain.eclass

2018-10-15 Thread Dirkjan Ochtman
Signed-off-by: Dirkjan Ochtman 
---
 eclass/rust-toolchain.eclass | 120 +++
 1 file changed, 120 insertions(+)
 create mode 100644 eclass/rust-toolchain.eclass

diff --git a/eclass/rust-toolchain.eclass b/eclass/rust-toolchain.eclass
new file mode 100644
index 000..d09db264fc3
--- /dev/null
+++ b/eclass/rust-toolchain.eclass
@@ -0,0 +1,120 @@
+# Copyright 1999-2018 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: rust-toolchain.eclass
+# @MAINTAINER:
+# Rust Project 
+# @SUPPORTED_EAPIS: 6
+# @BLURB: helps map gentoo arches to rust ABIs
+# @DESCRIPTION:
+# This eclass contains a src_unpack default phase function, and
+# helper functions, to aid in proper rust-ABI handling for various
+# gentoo arches.
+
+case ${EAPI} in
+   6) : ;;
+   7) : ;;
+   *) die "EAPI=${EAPI:-0} is not supported" ;;
+esac
+
+inherit multilib-build
+
+# @ECLASS-VARIABLE: RUST_TOOLCHAIN_BASEURL
+# @DESCRIPTION:
+# This variable specifies the base URL used by the
+# rust_arch_uri and rust_all_arch_uris functions when
+# generating the URI output list.
+: ${RUST_TOOLCHAIN_BASEURL:=https://static.rust-lang.org/dist/}
+
+# @FUNCTION: rust_abi
+# @USAGE: [CHOST-value]
+# @DESCRIPTION:
+# Outputs the Rust ABI name from a CHOST value, uses CHOST in the
+# environment if none is specified.
+
+rust_abi() {
+  local CTARGET=${1:-${CHOST}}
+  case ${CTARGET%%*-} in
+aarch64*) echo aarch64-unknown-linux-gnu;;
+mips64*)  echo mips64-unknown-linux-gnuabi64;;
+powerpc64le*) echo powerpc64le-unknown-linux-gnu;;
+powerpc64*)   echo powerpc64-unknown-linux-gnu;;
+x86_64*)  echo x86_64-unknown-linux-gnu;;
+armv6j*s*)echo arm-unknown-linux-gnueabi;;
+armv6j*h*)echo arm-unknown-linux-gnueabihf;;
+armv7a*h*)echo armv7-unknown-linux-gnueabihf;;
+i?86*)echo i686-unknown-linux-gnu;;
+mipsel*)  echo mipsel-unknown-linux-gnu;;
+mips*)echo mips-unknown-linux-gnu;;
+powerpc*) echo powerpc-unknown-linux-gnu;;
+s390x*)   echo s390x-unknown-linux-gnu;;
+*)echo ${CTARGET};;
+  esac
+}
+
+# @FUNCTION: rust_all_abis
+# @DESCRIPTION:
+# Outputs a list of all the enabled Rust ABIs
+rust_all_abis() {
+  if use multilib; then
+local abi
+local ALL_ABIS=()
+for abi in $(multilib_get_enabled_abis); do
+  ALL_ABIS+=( $(rust_abi $(get_abi_CHOST ${abi})) )
+done
+local abi_list
+IFS=, eval 'abi_list=${ALL_ABIS[*]}'
+echo ${abi_list}
+  else
+rust_abi
+  fi
+}
+
+# @FUNCTION: rust_arch_uri
+# @USAGE:   [alt-distfile-basename]
+# @DESCRIPTION:
+# Output the URI for use in SRC_URI, combining $RUST_TOOLCHAIN_BASEURL
+# and the URI suffix provided in ARG2 with the rust ABI in ARG1, and
+# optionally renaming to the distfile basename specified in ARG3.
+#
+# @EXAMPLE:
+# SRC_URI="amd64? (
+#$(rust_arch_uri x86_64-unknown-linux-gnu rustc-${STAGE0_VERSION})
+# )"
+#
+rust_arch_uri() {
+  if [ -n "$3" ]; then
+echo "${RUST_TOOLCHAIN_BASEURL}${2}-${1}.tar.gz -> ${3}-${1}.tar.gz"
+  else
+echo "${RUST_TOOLCHAIN_BASEURL}${2}-${1}.tar.gz"
+  fi
+}
+
+# @FUNCTION: rust_all_arch_uris
+# @USAGE  [alt-distfile-basename]
+# @DESCRIPTION:
+# Outputs the URIs for SRC_URI to help fetch dependencies, using a base URI
+# provided as an argument.  Optionally allows for distfile renaming via a 
specified
+# basename.
+#
+# @EXAMPLE:
+# SRC_URI="$(rust_all_arch_uris rustc-${STAGE0_VERSION})"
+#
+rust_all_arch_uris()
+{
+  local uris=""
+  uris+="amd64? ( $(rust_arch_uri x86_64-unknown-linux-gnu   "$@") ) "
+  uris+="arm?   ( $(rust_arch_uri arm-unknown-linux-gnueabi  "$@")
+  $(rust_arch_uri arm-unknown-linux-gnueabihf"$@")
+  $(rust_arch_uri armv7-unknown-linux-gnueabihf  "$@") ) "
+  uris+="arm64? ( $(rust_arch_uri aarch64-unknown-linux-gnu  "$@") ) "
+  uris+="mips?  ( $(rust_arch_uri mips-unknown-linux-gnu "$@")
+  $(rust_arch_uri mipsel-unknown-linux-gnu   "$@")
+  $(rust_arch_uri mips64-unknown-linux-gnuabi64  "$@") ) "
+  uris+="ppc?   ( $(rust_arch_uri powerpc-unknown-linux-gnu  "$@") ) "
+  uris+="ppc64? ( $(rust_arch_uri powerpc64-unknown-linux-gnu"$@")
+  $(rust_arch_uri powerpc64le-unknown-linux-gnu  "$@") ) "
+  uris+="s390?  ( $(rust_arch_uri s390x-unknown-linux-gnu"$@") ) "
+  uris+="x86?   ( $(rust_arch_uri i686-unknown-linux-gnu "$@") ) "
+  echo "${uris}"
+}
-- 
2.18.1




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

2018-09-29 Thread Dirkjan Ochtman
On Sat, Sep 29, 2018 at 4:52 PM Thomas Deutschmann 
wrote:

> I agree. Communication was bad. We should have included dev howto with
> that announcement.
>

Thanks for the helpful pointers!

Regards,

Dirkjan


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

2018-09-29 Thread Dirkjan Ochtman
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
> 0b) disable that hook immediately.
>

Try git rebase -i and use "r" for "reword" on every commit.


> 1) Update repoman to enforce it _before_ the commit is executed.
>

Some kind of repoman support would make this much easier to handle. As it
is, doing this by hand for the trivial case (only my own changes) is a
PITA. repoman could grow some kind of --sign-off option that appends this
to the commit message presumably?

I think repoman checks happen on the tree, not on the commit, so I'm not
sure how you think enforcing it before the commit makes sense (the line is
effectively part of the commit).


> 2) Wait for the repoman update to trickle down to all developers.
> 3) Announce it ahead of time.
>

Some more lead time would be appreciated, yes.

Regards,

Dirkjan


Re: [gentoo-dev] [RFC] Removing support for mercurial repos in repositories.xml

2018-09-24 Thread Dirkjan Ochtman
On Sun, Sep 23, 2018 at 10:42 PM Michał Górny  wrote:

> 2. Mercurial is buggy and maintaining support for those repos is PITA.
>

As a former Mercurial maintainer, I'm very skeptical of claims that
Mercurial is that buggy or generally less well-maintained than Git. Still,
reality is that Gentoo is mostly focused on Git (and Mercurial use is
relatively limited in the broader free software community), so I could see
it makes sense to focus our resources on Git.

Regards,

Dirkjan


[gentoo-dev] Package up for grabs: dev-db/couchdb

2018-08-09 Thread Dirkjan Ochtman
While I have maintained this for a long time, I've been unhappy with
upstream since they released 2.x with no proper Unix build system (there
have also been a number of bundled dependencies that I have been unable to
move them off of). There is a newly released remote code execution
vulnerability, announced today (https://bugs.gentoo.org/663164) which has
only been fixed on 2.x; 1.x maintenance was recently ended.

If no one else wants to pick this up, it will probably get last rited soon.


Re: [gentoo-dev] Add rust eclass to support multi-target compilation

2018-07-31 Thread Dirkjan Ochtman
On Tue, Jul 31, 2018 at 12:03 PM Luca Barbato  wrote:

> > As far as I know, the Rust ecosystem is largely bimodal: stuff is either
> > compatible with stable and later, or it works only on nightly. It seems
> > very rare that code is actually tied to a particular Rust release and
> does
> > not compile against latest Rust stable. (Upstream actually promises they
> > won't break code except in case they need to fix a soundness issue in the
> > compiler.) So instead of building this whole target infrastructure (which
> > is definitely needed for something like Python or Ruby), we should be
> able
> > to just work with stable and nightly slots, and ebuilds can depend on
> those.
>
> This is true until you do not want to use libsyntax and other
> compiler-specific libraries.
>
> Because of the enforced ABI-randomness, what you built against stable
> must be rebuilt on stable.1, making those libraries non-shared might be
> a topic.
>

I'm not sure what you mean here, can you give an example?


> > Upstream is also very clearly packaging their core tooling as a single
> > package made up of a number of components, and these are distributed and
> > compiled together in common usage on other platforms (with the rustup
> > tooling). That also means they are tightly coupled -- for example,
> rustfmt
> > can change formats over time, and CI that checks formatting will need to
> > align with whatever the current stable Rust version of rustfmt is.
>
> Actually rustfmt is interesting since it does use libsyntax and
> depending on which project you may have to use the nightly rustfmt while
> targeting stable.
>

Yeah, but in my suggested approach we would have slotted rustfmt.


> > Installing the latest (nightly or beta) version of rustfmt while you
> have a
> > stable Rust toolchain installed is thus not a good idea. As another
> > example, cargo is now tagged as 0.28, but when passing --version it will
> > report as 1.27.0 -- actually the Rust toolchain version.
>
> Well it might be surprising, but for at least one project is actually
> required :)
>

So what project is that, and what exactly does it require? At some point if
your project requires very custom stuff maybe you should just build your
own Rust.


> > For these reasons, I think it would be better to align our Rust ebuilds
> > with upstream and work with single ebuilds (dev-lang/rust and
> > dev-lang/rust-bin) that install all the tools belonging to a particular
> > version of the Rust toolchain.
>
> > What tools are installed can be customized
> > with USE flags, and the default install can be minimal (just rustc and
> > cargo, which you need to build packages anyway).
>
> So once you need bindgen you have to rebuild rustc and then you need
> clippy you build again rustc?
>

Yes, it can be a pain, but I don't think "switching what auxiliary tools
are installed" is the common scenario that we should optimize for
necessarily.


> And what happens once you have yet-another-tool using libsyntax, you add
> it to the rustc ebuild and unleash a -r1 to the users?
>

If upstream includes another tool in their distribution, we add that to the
rust ebuild, yes.

I think there's a lot of value in aligning with upstream and with how
something is distributed on other platforms, because this reduces friction
for our users.

Regards,

Dirkjan


Re: [gentoo-dev] Add rust eclass to support multi-target compilation

2018-07-31 Thread Dirkjan Ochtman
On Mon, Jul 30, 2018 at 5:02 PM gibix  wrote:

> This will allows projects like rustfmt, clippy, bindgen that need runtime
> linking with the proper rust version to work correctly. Beyond this while
> rust is getting older as project we will see more projects that will
> require a specific rust version for compilation.
>

As I mentioned in the PR already, I'm not a fan of this change. (Context: I
have been writing Rust code for 2 years, I'm on the Rust team, and I've
done most of the maintenance on the dev-lang/rust ebuilds for the past year
or so.)

As far as I know, the Rust ecosystem is largely bimodal: stuff is either
compatible with stable and later, or it works only on nightly. It seems
very rare that code is actually tied to a particular Rust release and does
not compile against latest Rust stable. (Upstream actually promises they
won't break code except in case they need to fix a soundness issue in the
compiler.) So instead of building this whole target infrastructure (which
is definitely needed for something like Python or Ruby), we should be able
to just work with stable and nightly slots, and ebuilds can depend on those.

Upstream is also very clearly packaging their core tooling as a single
package made up of a number of components, and these are distributed and
compiled together in common usage on other platforms (with the rustup
tooling). That also means they are tightly coupled -- for example, rustfmt
can change formats over time, and CI that checks formatting will need to
align with whatever the current stable Rust version of rustfmt is.
Installing the latest (nightly or beta) version of rustfmt while you have a
stable Rust toolchain installed is thus not a good idea. As another
example, cargo is now tagged as 0.28, but when passing --version it will
report as 1.27.0 -- actually the Rust toolchain version.

For these reasons, I think it would be better to align our Rust ebuilds
with upstream and work with single ebuilds (dev-lang/rust and
dev-lang/rust-bin) that install all the tools belonging to a particular
version of the Rust toolchain. What tools are installed can be customized
with USE flags, and the default install can be minimal (just rustc and
cargo, which you need to build packages anyway).

Regards,

Dirkjan


Re: [gentoo-dev] rfc: [QA] Ban policy introduction

2018-07-30 Thread Dirkjan Ochtman
On Mon, Jul 30, 2018 at 8:52 AM Guilherme Amadio  wrote:

> If you introduce penalties for breaking prefix as well, I'm afraid many
> people will be unnecessarily penalized. I think that such penalties are
> counter productive in most cases. If someone is really being careless it
> might make sense to get some warning and lose commit access temporarily.
> If someone made a simple mistake that can be easily fixed, like version
> bumping a package that starts to fail in some corner case, then
> punishment doesn't make much sense.
>

The proposed policy already mentions that people will only be punished
after two warnings. This seems enough for me -- if people keep breaking
stuff despite warnings, a little penalty is probably a good thing.

The proposed policy already goes out of its way to require two warnings for
"independent" breakage, but it's not entirely clear what independent means
here. If you commit three breakages that are technically unrelated on the
same day, then you probably shouldn't be banned immediately. So I would
suggest also making clear that the warnings should be sent at least a few
days apart and that an initial penalty cannot happen until a few days apart
the second warning.

That said, I agree with those who are saying that breaking things should be
obvious, things like ignoring repoman and/or other CI messaging. If the
breakage is non-obvious and hard to spot locally, then we should instead
invest in tooling to make it more obvious. By "ignoring" here I do mean
that there needs to be a reasonable timeout -- sometimes if I commit a
change and get a CI alert after a few hours, it might be tricky due to
work/family/whatever concerns to fix it within, say, 24 hours.

Regards,

Dirkjan


Re: [gentoo-dev] RFC: Repoman to warn about suspicious =-dependencies

2018-03-26 Thread Dirkjan Ochtman
On Sun, Mar 4, 2018 at 12:37 PM, Michał Górny  wrote:

> I think this cause the trouble of specifying '-r0' rather rarely, and it
> will decrease the number of mistakes, also effectively making Gentoo
> development easier. It is somewhat inspired by the handling of slot
> operators (where repoman explicitly asks you to use ':*' instead
> of no operator when the latter would be ambiguous).
>
> What do you think?
>

Sounds good!

Regards,

Dirkjan


Re: [gentoo-dev] New category: app-metrics

2018-03-22 Thread Dirkjan Ochtman
On Tue, Mar 20, 2018 at 6:21 AM, Manuel Rüger  wrote:

> In addition, the following packages will drop their prometheus- prefix
> during the package move:
>
> * net-analyzer/prometheus-blackbox_exporter
> * net-analyzer/prometheus-node_exporter
> * net-analyzer/prometheus-redis_exporter
> * net-analyzer/prometheus-snmp_exporter
> * net-analyzer/prometheus-uwsgi_exporter
> * net-analyzer/prometheus-pushgateway
> * net-analyzer/prometheus-alertmanager
>
> With the growing adoption of prometheus I expect more exporters to be
> added (I have five more that I want to add in the near future).
>
>
On the face of it, I wouldn't drop the "prometheus-" prefix if app-metrics
is to be the home to other tools. Otherwise, other tools like graphite or
collectd might want very similar names for the same tools out  there.

Regards,

Dirkjan


Re: [gentoo-dev] Is removing old EAPIs worth the churn?

2018-03-06 Thread Dirkjan Ochtman
On Tue, Mar 6, 2018 at 2:52 AM, Matt Turner  wrote:

> In the end we might get to delete some code from portage or an eclass?
> Does this seem worth it?
>

To add to some of the points Kent made, I think so, yes: this means freeing
us from the cognitive overhead of thinking about older EAPIs at all, having
to remember the differences between those old EAPIs and the newer ones.
Removing that complexity from developer's minds as well as from our tooling
means our tooling will be we can spend our time and energy on other things,
which will be a win for the distribution.

Yes, the long tail is painful: these are probably the packages that haven't
been upgraded before for a reason, but actually putting the finishing
touches on the EAPI migration will be worth it in the end.

It might have been even better if Andreas or someone else had announced
this project/discussed the trade-offs before starting it.

Cheers,

Dirkjan


Re: [gentoo-dev] RFC: Bugzilla arch list reordering

2018-01-23 Thread Dirkjan Ochtman
On Tue, Jan 23, 2018 at 12:46 PM, Michał Górny  wrote:

> Since neither of the proposals has received any specific reply, I'm not
> sure how to proceed from here. I suppose we can possibly have two lists
> in different order so that people could use whichever they prefer.
>

Not sure having two lists in Bugzilla would be an improvement. It would be
nice if more people expressed a preference, though!

Regards,

Dirkjan


Re: [gentoo-dev] News Item: Portage Dynamic Deps

2018-01-22 Thread Dirkjan Ochtman
On Mon, Jan 22, 2018 at 8:01 AM, Zac Medico  wrote:

> According to Gentoo policy, future ebuild dependency changes need to be
> accompanied by a revision bump in order to trigger rebuilds for users.
> Therefore, you should only need to use --changed-deps=y for a single
> deep @world update. After that, if you encounter installed packages with
> outdated dependencies in a future deep @world update, then you should
> report it as a bug.


Can we get repoman to warn about changing dependencies without revbumps?

Cheers,

Dirkjan


Re: [gentoo-dev] RFC: Bugzilla arch list reordering

2018-01-16 Thread Dirkjan Ochtman
On Tue, Jan 16, 2018 at 11:19 AM, Michał Górny  wrote:

> I disagree. I think most of the developers are used to the lexical sort,
> and it keeps the order predictable. While I suppose keeping amd64
> and x86 alongside for the sake of being commonly used would make sense,
> I really have no clue how that would affect other arches.
>

It is a trade-off, of course. My hypothesis is that it would be easier to
use.


> By 'frequency' did you mean how many ebuilds are having the specific
> keyword? Could you make some quick stats that would show how this would
> look like right now?
>

Here's an estimation of the relative frequencies:

amd64 (37201)
x86 (33703)
ppc (15347)
arm (14387)
ppc64 (11647)
sparc (10054)
alpha (9219)
ia64 (8456)
hppa (8410)
arm64 (8194)
amd64-linux (7716)
mips (7602)
x86-linux (7409)
x86-fbsd (6102)
sh (4885)
s390 (4421)
ppc-macos (4098)
x86-macos (4028)
amd64-fbsd (3361)
x86-solaris (3202)
x64-macos (3187)
sparc-solaris (2464)
x64-solaris (2208)
m68k (2204)
sparc64-solaris (1344)
arm-linux (1135)
ppc-aix (971)
sparc-fbsd (902)
m68k-mint (626)
x64-cygwin (432)
x86-winnt (123)
x86-interix (5)
x86-cygwin (5)
ia64-hpux (5)
ppc64-linux (4)
arm64-linux (4)
x86-freebsd (1)

Regards,

Dirkjan


Re: [gentoo-dev] RFC: Bugzilla arch list reordering

2018-01-16 Thread Dirkjan Ochtman
On Mon, Jan 15, 2018 at 11:01 PM, Michał Górny  wrote:

> Besides regrouping, I've also reordered the keywords to use the same
> sorting order as eshowkw (i.e. ppc before ppc64), moved 'BSD' into teams

(in contrast to 'AMD64 FBSD' and 'X86 FBSD'), and added 'Prefix' team.
>

I think these are all good improvements. In terms of having the best user
experience, I would actually advocate changing the order to sort by
frequency/use. So the list would just start with amd64, then x86, arm64,
ppc, or something like that? Probably we should still match order with
eshowkw, maybe there should be a file somewhere that keeps the current
order and we can regenerate it from time to time based on the latest use
counts.

Regards,

Dirkjan


Re: [gentoo-project] Re: [gentoo-dev] [RFC] Splitting developer-oriented and expert user mailing lists

2017-12-04 Thread Dirkjan Ochtman
On Sun, Dec 3, 2017 at 10:43 PM, Michał Górny  wrote:

> > On the face of it, I like this proposal. On the other hand, wouldn't it
> be
> > better if we just had more active list moderators? That is, moderators
> who
> > move problematic user's posts to moderated by default, and then withhold
> > the specific posts if necessary?
>
> I don't think this is really technically feasible. I don't know if mlmmj
> has the specific feature you're asking for, and even if it did,
> moderation with mlmmj is practically impossible to use. Even for low-
> traffic channel like gentoo-dev-announce@ it's not working well.
>

Maybe we should move to a more modern list manager? I'm pretty sure mailman
can do this kind of stuff trivially. It feels bad if we have to institute
suboptimal processes due to crappy tooling, if better alternatives are
readily available.

Regards,

Dirkjan


Re: [gentoo-dev] [RFC] Splitting developer-oriented and expert user mailing lists

2017-12-03 Thread Dirkjan Ochtman
On Sun, Dec 3, 2017 at 12:18 AM, Michał Górny  wrote:

> 1. Posting to gentoo-dev@ and gentoo-project@ mailing lists will be
> initially restricted to active Gentoo developers.
>
> 1a. Subscription (reading) and archives will still be open.
>
> 1b. Active Gentoo contributors will be able to obtain posting access
> upon being vouched for by an active Gentoo developer.
>

On the face of it, I like this proposal. On the other hand, wouldn't it be
better if we just had more active list moderators? That is, moderators who
move problematic user's posts to moderated by default, and then withhold
the specific posts if necessary?

2. A new mailing list 'gentoo-expert' will be formed to provide
> a discussion medium for expert Gentoo users and developers.
>
> 2a. gentoo-expert will have open posting access like gentoo-dev has now.
>

I'm not sure this will be worth it. Who exactly do you think is the
audience for this mailing list? What is the goal? How is it different from
existing mailing lists?

Cheers,

Dirkjan


Re: [gentoo-dev] RFC v2: news item for the 17.0 profiles

2017-11-28 Thread Dirkjan Ochtman
On Tue, Oct 10, 2017 at 9:16 PM, Andreas K. Huettel 
wrote:

> =
> Title: New 17.0 profiles in the Gentoo repository
> Author: Andreas K. Hüttel 
> Posted: xxx
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Installed: >=sys-devel/gcc-6.4.0
>

So gcc-6.4.0 is now in stable on amd64, when do we expect the news item to
land? I was looking at testing the procedure out, but noticed eselect still
doesn't show the 17.0 profiles (I know I can twiddle the symlink instead,
but would like to test the full procedure).

Regards,

Dirkjan


Re: [gentoo-dev] Manifest2 hashes, take n+1-th

2017-10-20 Thread Dirkjan Ochtman
On Fri, Oct 20, 2017 at 11:23 AM, Ulrich Mueller <u...@gentoo.org> wrote:

> >>>>> On Fri, 20 Oct 2017, Dirkjan Ochtman wrote:
>
> > As Hanno was saying, we'll have decades of warning before a break
> > becomes practical, so I don't think this is a real concern.
>
> How can we be sure of that? I guess the same reasoning was applied
> when MD5 and SHA1 hashes were used.
>

Yeah, and it actually did happen that way. Typically before preimage
attacks (which are what we really care about here, as far as I understand
it) happen there are several other types of attacks that will happen first,
and that will provide advance warning about the level of security provided
by SHA2.

Cheers,

Dirkjan


Re: [gentoo-dev] Manifest2 hashes, take n+1-th

2017-10-20 Thread Dirkjan Ochtman
On Fri, Oct 20, 2017 at 12:49 AM, Gordon Pettey 
wrote:

> On Thu, Oct 19, 2017 at 5:32 PM, Hanno Böck  wrote:
>
>> On Thu, 19 Oct 2017 21:08:40 +0200
>> Michał Górny  wrote:
>>
>> >   manifest-hashes = SHA512 SHA3_512
>>
>> Counterproposal: Just use SHA512.
>>
>> There isn't any evidence that any SHA2-based hash algorithm is going to
>> be broken any time soon. If that changes there will very likely be
>> decades of warning before a break becomes practical.
>>
>> Having just one hash is simpler and using a well supported one like
>> SHA512 may make things easier than using something that's still not
>> very widely supported.
>
>
> Yet having more than one lets you match make sure nobody hijacked your
> manifest file when an attack vector is inevitably discovered for the old
> new algorithm (whether SHA2, SHA3, or BLAKE2), because you'll be able to
> confirm the file is the same one that matched the old checksum in addition
> to the new one.
>

As Hanno was saying, we'll have decades of warning before a break becomes
practical, so I don't think this is a real concern.

I think the problem of having this discussion on gentoo-dev this way is
that people with vastly different levels of security/crypto expertise are
discussing different options without much regard for the level of expertise
(and maybe even unaware of others' relevant expertise).

I support Hanno's suggestion of doing just SHA512, but would be interested
in hearing opinions from others who have apparent security/crypto
experience. Maybe the Security project can weigh the suggestions as well?

Cheers,

Dirkjan


[gentoo-dev] rust-toolchain.eclass RFC

2017-09-09 Thread Dirkjan Ochtman
A contributor has written the following eclass:

https://bugs.gentoo.org/attachment.cgi?id=464900

This would help extending support for Rust to other arches. As I'm not
deeply familiar with writing eclasses, I'd welcome any feedback on this
code. The general idea seems sane to me.

Cheers,

Dirkjan


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

2017-07-25 Thread Dirkjan Ochtman
On Tue, Jul 25, 2017 at 10:05 AM, Michał Górny  wrote:

> What do you think about it? Is there anything else that needs being
> covered?
>

Looks good to me. Thanks for writing it up!

Cheers,

Dirkjan


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

2017-07-25 Thread Dirkjan Ochtman
On Mon, Jul 24, 2017 at 11:22 PM, Sergei Trofimovich 
wrote:

> TL;DR;TL;DR:
> 
>
> This email seeks for one step towards less toil tied to gentoo's
> keywording/stabilization process. I've CCed a few groups who
> might be interested in making this area better:
>
> - gentoo-dev@ as it affects most devs (and non-devs!)
> - wg-stable@ as it overlaps quite a bit with efforts staged on STABLEREQ
>   (should I join? :)
> - arch-leads@ as it directly helps (or breaks everything for) arch teams
> - all individual arches for wider visibility
>

Thanks for kicking off this discussion. As a stable user, this is an
important topic to me.

Your email is kind of long, and I wonder if we can condense the problem
back to simpler first principles.

First, the assumption in our processes seems to be that many or important
bugs will be due to architecture-specific differences, and I wonder if that
assumption really holds up. Do arch testers for a smaller arch often find
problems that were not noticed on one of the larger arches? With the
languages and tools that we have today, it seems like for many of our
packages, bugs due to architectural differences represent a minority of the
problems we found. In this case, the whole idea of per-arch stabilization
does not really make sense, and doing away with that idea could drastically
shortcut our process.

Second, I believe a lot of the value in our stable tree comes *just* from
the requirement that stabilization is only requested after 30 days without
major bugs/changes in the unstable tree. Assuming there are enough users of
a package on unstable, that means important bugs can be shaken out before a
version hits stable. This could mean that potentially, even if we inverted
our entire model to say we "automatically" stabilize after a 30-day period
without major bugs, we hit most of the value of the stable tree with again
drastically reduced pain/work.

Cheers,

Dirkjan


[gentoo-dev] Re: Packages up for grabs

2017-06-28 Thread Dirkjan Ochtman
On Thu, Apr 27, 2017 at 12:58 PM, Dirkjan Ochtman <d...@gentoo.org> wrote:
> I also want to drop the following:
>
> - dev-lang/erlang
> - dev-vcs/hgsubversion

I'll drop these to maintainer-needed by July 1st.

Cheers,

Dirkjan



Re: [gentoo-dev] [RFC] Restricted version of gentoo-dev mailing list

2017-05-24 Thread Dirkjan Ochtman
On Tue, May 23, 2017 at 9:31 PM, Michał Górny  wrote:
> I'd like to request Infra to establish a new mailing list that would
> fill in the gap between our public mailing lists and the gentoo-core
> mailing list.

I agree with the others who've said that they don't think this is the
right solution. I've previously agreed we need moderation. I would
advocate that infra work on better moderation tools and/or mailing
list infrastructure that enables our use case.

(If we have problems with a lack of infra capacity making it
prohibitively expensive to move us forward, here's one solution that's
a little out there: just switch to hosted Discourse.)

Cheers,

Dirkjan



Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

2017-05-11 Thread Dirkjan Ochtman
On Thu, May 11, 2017 at 8:50 AM, David Seifert  wrote:
> 1. ppc(= 32 bit) will be massively dekeyworded, ppc64 will stay
> unchanged (also given that it is an active arch in general and gets CPU
> upgrades from IBM/OpenPOWER).

Sounds good.

You started the thread also talking about ia64 and sparc. What about those?

Cheers,

Dirkjan



Re: [gentoo-dev] [RFC] News item: GCC 6 defaults to USE="pie ssp", v2

2017-05-10 Thread Dirkjan Ochtman
On Wed, May 10, 2017 at 11:19 AM, Kristian Fiskerstrand  wrote:
> Sounds like a reasonable action plan. The consequences of such a change
> definitely seems to be sufficiently high to merit a proper migration
> plan which doesn't seem to have been established at this point. Whether
> that can be added to a later point with gcc6 (e.g by adding a new
> profile, or a later point release) I don't have strong opinions on, but
> there should be a plan and proper overview of the consequences.

Yeah, I think I agree. From the discussions so far, I think that we
should definitely aim for making pie the default for everyone (on
arches where it makes sense), but doing it in the gcc-6 now which has
seen only a short period of testing so far seems a bit hasty based on
data from the messages that I've seen in these threads so far.

Cheers,

Dirkjan



Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

2017-05-10 Thread Dirkjan Ochtman
On Tue, May 9, 2017 at 2:20 PM, Anthony G. Basile  wrote:
> I maintain quite a few ppc stage3's for uclibc and musl.  I would
> appreciate keeping ppc as is.  It is still a useful arch for many
> devices today, eg. some high end Mikrotik routers.

So are you willing to do the work? There are currently 68 open keyword
requests (oldest one reported in 2011) and 48 open stable requests
(oldest one reported in November).

Cheers,

Dirkjan



Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

2017-05-08 Thread Dirkjan Ochtman
On Mon, May 8, 2017 at 12:49 PM, Mikle Kolyada  wrote:
> Against. Do not touch things you are not working on, council has already
> dropped m68k s390 and sh to exp few years ago. Now we have a big mess
> there and only, while ia64 sparc and co have slow but progress and
> mature enough stable profiles.

Obviously we should prevent big messes from happening. But it's a
mistake that things I don't work on don't affect me -- work left over
by lagging arch teams can affect me in many ways, in terms of having
to keep older versions of my packages working and in the tree, and
having to keep track of many more KEYWORDREQs and STABLEREQs.

To me it's likely that the pace of stabilization for everyone is
affected by the slower arches, in the sense that maintainers are less
likely to stabilize newer versions if they see that arches can't keep
up with previous requests. This means that even stable amd64 users are
affected to some extent by ppc being slow to stabilize.

Cheers,

Dirkjan



Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

2017-05-07 Thread Dirkjan Ochtman
On Sun, May 7, 2017 at 9:23 PM, David Seifert  wrote:
> TL;DR
> ia64/ppc/sparc teams are pretty much dead. They have been for a long
> time and this won't change any time soon. Gentoo should focus its
> resources on archs that are important and has the manpower to support.
> Let us please drop these 3 archs to dev profiles to ease maintenance.

+1 good idea. The slowest arches slow things down for everyone else.

Cheers,

Dirkjan



[gentoo-dev] Last rites: www-apache/mod_authnz_persona

2017-04-27 Thread Dirkjan Ochtman
# Dirkjan Ochtman <d...@gentoo.org> (27 Apr 2017)
# Persona service has been discontinued. Masked for removal in 30 days.
www-apache/mod_authnz_persona



[gentoo-dev] Packages up for grabs

2017-04-27 Thread Dirkjan Ochtman
The proxy maintainer for syncthing just resigned, anyone want to pick it up?

- net-p2p/syncthing

I also want to drop the following:

- dev-lang/erlang
- dev-vcs/hgsubversion

(All should be in a fairly good state right now.)

Cheers,

Dirkjan



Re: [gentoo-dev] Reverse use of Python/Ruby versions

2017-04-10 Thread Dirkjan Ochtman
On Mon, Apr 10, 2017 at 8:37 AM, Michał Górny  wrote:
> It is always nice when a person who:

Please stop the sarcasm. While I understand the reaction, the idea in
itself does not seem totally crazy to me, and it seems useful to have
a discussion on its merits.

At the same time, I would not consider it far-fetched to say that you
proposed significant changes to handling of manifest hashes, without
deep knowledge of the security aspects of the hashing algorithms up
for discussion. This is sometimes how we learn. If you feel the thread
wastes time, you can just ignore it (as you seem to have done with the
manifest hashes thread after a few critical responses, somewhat to my
disappointment).

Cheers,

Dirkjan



Re: [gentoo-dev] Tree signing and verification on the user side - status?

2017-04-04 Thread Dirkjan Ochtman
On Tue, Apr 4, 2017 at 12:03 PM, Andreas K. Huettel
 wrote:
>> while we're discussing super-strength hash algos, it would be cool to know
>> what's still missing for
>> * rsync-side manifest signing in whatever way
>> * verification of such signatures in portage / emerge
>>
>
> (and just to put it in a reference frame, I'm these days reading mailing list
> discussions how cryptographic signing of our rsync tree is urgently needed...
> ... in the council agenda threads
> ... of the very first council
> ... i.e., 2005
> ... i.e., roughly 12 years ago.)

Was thinking exactly the same thing yesterday. How do we make it
happen? Do we have any ideas on feasible paths forward?

Cheers,

Dirkjan



Re: [gentoo-dev] [RFC] New Manifest hashes and how to enable them

2017-04-03 Thread Dirkjan Ochtman
On Mon, Apr 3, 2017 at 7:09 PM, Michał Górny  wrote:
> Your thoughts?

This seems pretty hasty.

First of all, SHA-256 should be safe for all intents and purposes, and
for the foreseeable future. This is nothing like Git's usage of SHA-1,
which was known to be on the way to brokenville for a long time. I
don't think there is a solid reason for deprecating it now.

Second, the amount of diversity proposed does not make sense. If
asked, I would propose we keep SHA-256 as one of the options and
additionally add a SHA3 variant and a BLAKE2 variant as other options.
This would provide more than enough diversity. Also totally agreed
with Vadim on the obscurity of the GOST algorithms.

But, this is the kind of thing where we really should get input from
the Security project, so we should get people like Hanno and Kristian
involved.

Third, I don't much trust the security record of the python libraries
mentioned. cryptography is the best Python library for crypto by far,
and I think we should use it exclusively for anything Python doesn't
provide in the stdlib. The PyCrypto security record is not exactly
stellar IIRC, and since pycryptodome is a fork of it, I don't trust it
that much, either.

But mainly, please, I think we should leave the security-sensitive
decisions to people with more security expertise.

Cheers,

Dirkjan



Re: [gentoo-dev] RFC: Introducing stable profiles for arm64 (aarch64)

2017-02-06 Thread Dirkjan Ochtman
On Sat, Feb 4, 2017 at 6:26 AM, Mart Raudsepp  wrote:
> I am working towards having a clean deptree for arm64 and afterwards
> marking the non-hardened 5 arm64 profiles stable (or 4 - I don't see
> value in the developer profile without the desktop specific
> subprofiles, until there are mix-ins).

While I'm not personally affected, this sounds like the culmination of
a lot of work. Great to see that we can still onboard a new
architecture.

Cheers,

Dirkjan



Re: [gentoo-dev] Guidelines for IUSE defaults

2017-02-02 Thread Dirkjan Ochtman
On Thu, Feb 2, 2017 at 4:36 PM, Michael Orlitzky  wrote:
> I'm not saying that we should have a minimal experience out-of-the-box,
> only that the base profile should result in an effectively-minimal set
> of USE flags. Adding IUSE defaults is essentially adding defaults to the
> base profile. Why does dev-java/icedtea try to pull in GTK (and thus X)
> on a headless server? That stuff belongs in a desktop profile, not in
> the base one.
>
> I don't think minimal should be our default, but it should be
> *possible*. It practically isn't so long as people mix uses #1, #3, and
> #4. I guess I would also be happy if we outlawed use #1 so that USE="-*"
> would be supported. In any case, we should document how to use them.
> Having them mean four different things causes confusion.

Like others, I think that having IUSE defaults as reflecting upstream
makes much more sense, because it makes more sense to put upstream's
nuances in the ebuilds than in some of our profiles. I've run systems
with -* before, and found it to work okay. These days I have a
somewhat more minimal set of disabled USE flags in make.conf, which
seems to work fine for my somewhat-minimal headless server, too.

Anyway, I don't know how prevalent your #1 is, but making -* more
supported seems more attractive to me than the other options.

Cheers,

Dirkjan



Re: [gentoo-dev] Fwd: Cron <gmirror@dipper> /usr/local/bin/pidlock -s rsync-gen /bin/bash /usr/local/bin/mastermirror/rsync-gen.sh

2017-01-27 Thread Dirkjan Ochtman
Wow, Michał, this email comes off as pretty harsh to me... Is that
really necessary?

On Fri, Jan 27, 2017 at 8:26 AM, Michał Górny  wrote:
> I should point out that:
>
> 1) CI is detecting this kind of issues much faster than you are,
> and reporting them both to the committer and to a *dedicated* mailing
> list, so your mail is completely redundant and delayed.

That sounds like a somewhat better solution, although sometimes it can
make sense to send email to where the developers are already, rather
than putting the onus on them to join a separate mailing list.

> 2) Spamming the developer mailing list is completely unprofessional
> here. If you are unhappy about those mails, just disable them, and stop
> blaming people for your misery. Trying to prove others incompetent
> helps nobody.

Come on... I think it's fair game to share news about people breaking
things on the gentoo-dev mailing list. Naming & shaming can be useful
sometimes. And even if you wanted to make this point, you should have
made it more constructively.

> That said, if you forward yet another mail with the same purpose,
> I will file a formal complaint at ComRel and request suspending your
> mailing list access.

This is completely out of line for me. It seems to me that Doug has
the best intentions. If you disagree with his approach, can we not
have a civilized discussion about it rather than going straight into
attack mode?

Cheers,

Dirkjan



Re: [gentoo-dev] berkdb and gdbm in global USE defaults

2017-01-27 Thread Dirkjan Ochtman
On Fri, Jan 27, 2017 at 4:33 AM, Mike Gilbert  wrote:
> Looking through our profiles, I see we have both berkdb and gdbm
> enabled "globally".
>
> default/linux/make.defaults:USE="berkdb crypt ipv6 ncurses nls pam
> readline ssl tcpd zlib"
> releases/make.defaults:USE="acl gdbm nptl unicode"
>
> Is there any reason to have these USE flags enabled globally?

Good question... I already disable them, I think, as it doesn't really
make sense from my perspective to enable them globally. I think
letting packages set their own defaults with IUSE would probably be a
better solution.

On Fri, Jan 27, 2017 at 8:54 AM, Mart Raudsepp  wrote:
> Ühel kenal päeval, N, 26.01.2017 kell 22:33, kirjutas Mike Gilbert:
>> I recently ran into a REQUIRED_USE constraint that required I select
>> between berkdb and gdbm for an email client.
>
> There shouldn't be a REQUIRED_USE constraint that forces you to select
> one or the other. The maintainer should be giving the choice of both,
> but if only one can be chosen, the maintainer should make the choice
> for you by preferring one of them. Likely gdbm, given berkdb licensing
> saga.

I'm not sure this makes sense to me. If the package will actually
select one implementation out of a set, it makes sense to me that the
maintainer for that package makes that choice explicit towards the
user. In that case, setting REQUIRED_USE accordingly seems exactly
right. The maintainer should set a good default, but if the user's USE
settings are inconclusive in getting to the choice of implementation,
it's better to whine explicitly than try to guess implicitly what the
user wanted.

On Fri, Jan 27, 2017 at 9:32 AM, Fabian Groffen  wrote:
> Replying here because I think said email client is the one I recently
> added REQUIRED_USE constraints for.
>
> Reason I added it is because it greatly simplified the ebuild: it's not
> just bdb and gdbm, but also tokyocabinet, qdbm and lmdb, with as result
> a lot of if-else-casing which implemented the implicit defaults before.
> I didn't realise changing this to REQUIRED_USE resulted in a conflict on
> default profiles, because I (obviously) have a package.use entry for the
> package.

I don't see Mike saying you got it wrong here. Reading your email, I
think you did the right thing.

Cheers,

Dirkjan



Re: [gentoo-dev] Re: Common rsync-gen errors, why they happen, and what you can do about it

2017-01-18 Thread Dirkjan Ochtman
On Wed, Jan 18, 2017 at 10:04 AM, Kent Fredric  wrote:
> That's not viable, mostly because the performance cost of doing so is 
> significantly
> time consuming, that it would block `git push` for minutes at a time, and all 
> users
> performing pushes would have to wait in a queue for several minutes per push.

This doesn't ring intuitively true for me. Maybe you're talking about
running a "repoman full" for every committed package; I'm not. The
checks Doug describes are all package-local. What makes this process
so expensive?

Even if it is true, the solution would be akin to more post-push check
automation (like some of Michal's work) instead of blocking
automation, not just saying "people should verify things before they
push".

Cheers,

Dirkjan



Re: [gentoo-dev] Re: Common rsync-gen errors, why they happen, and what you can do about it

2017-01-17 Thread Dirkjan Ochtman
On Wed, Jan 18, 2017 at 5:58 AM, Doug Freed  wrote:
> At some point, the repoman manifest-check, or some variation of it,
> will probably get added to a post-receive hook, which will then abort
> your push if you try to push something that would break the conversion
> process.  That said, you should still be doing your due diligence to
> ensure that eventual hook doesn't yell at you.

This sounds like a much better strategy to me. We're expecting people
to check things that should be easy to check for machines. Yes, some
people (like myself) will always use repoman to commit, but it would
be much better if something this important (because it basically
delays other updates to users everywhere) is checked by an automated
process for every push, and disallows pushes like this.

> I can see if it's something I need to fix with my code.  But it's been
> a while since that's been the case, so all the failures these days are
> primarily for the previously mentioned issues.

That makes sense. My other comment initially reading your email would
be, send those emails to gentoo-core or -project or whatever. If
others don't get to feel the pain (of every half-hour error emails,
for example), they will be much less compelled to fix the problem. So
absorbing this "pain" into just you or infra makes us less scalable as
a distribution, and less likely that someone will feel motivated to
add the extra bits of automation (like a git hook) that will make this
problem go away.

Cheers,

Dirkjan



Re: [gentoo-dev] Revision bumps vs git commits atomicity

2016-12-02 Thread Dirkjan Ochtman
On Fri, Dec 2, 2016 at 4:14 PM, Andrew Savchenko  wrote:
> What about the following forkflow:
> - version bump first with minimal changes required, but without
> pushing commit to the tree;
> - make each logical change as a separate commit without revision
> bumps and without pushing stuff to the tree (of course repoman
> scan/full is required as usual for each commit);
> - well test package after the last commit (that it builds with
> various USE flag combinations, old and new functionality works fine
> and so on);
> - fix any problems found and only afterwards push changes to the
> tree.
>
> This way users will see only foo-1.0 -> foo-1.1 change in the tree,
> while git will still retain each logical change as a separate
> commit, which will make future maintenance and debugging much
> easier.
>
> Of course a separate git branch may be used as well, but using
> branches for each half-a-dozen set of commits looks like an
> overkill to me.
>
> Thoughts, comments?

Sounds sensible to me, possibly to the point of not having to spell it
out? (As in, I don't see the mentioned policies as necessarily
conflicting.)

Cheers,

Dirkjan



Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-22 Thread Dirkjan Ochtman
On Mon, Aug 22, 2016 at 5:58 PM, William Hubbs  wrote:
> On Gentoo, this file does not exist, so I'm wondering how we can make it
> exist?

Not sure if/how related, but when I have:

djc@enrai ~ $ cat /etc/conf.d/hostname
# Set to the hostname of this machine
hostname="enrai"

Apache 2 tells me:

AH00558: apache2: Could not reliably determine the server's fully
qualified domain name, using 127.0.0.1. Set the 'ServerName' directive
globally to suppress this message[ ok ]

I've set dns_domain and dns_search in /etc/conf.d/net, and domain is
set in /etc/resolv.conf.

The Handbook also has a non-fully-qualified hostname set in
/etc/conf.d/hostname, and I didn't get this Apache warning on the
previous server I ran this stuff on.

Cheers,

Dirkjan



Re: #wg-stable: Reservations about a "STABLE" & "NeedsStable" bugzilla keywords (re: [gentoo-dev] New Working Group established to evaluate the stable tree)

2016-08-15 Thread Dirkjan Ochtman
On Mon, Aug 15, 2016 at 3:25 PM, Kristian Fiskerstrand  wrote:
>> very different process from handling bugs and feature requests. It
>> would be great if we had tooling that focuses on these instead of
>> trying to fit into the bug tracker. It would entail a different
>
> I'm not sure I agree on this point, my perspective is the state of the
> stable tree is exactly dependent on it being considered as part of the
> regular workflow of developers, which has at least been implied in the
> past[0] - resulting in e.g InVCS.
>
> Part of the discussion in that case is the number of developers running
> full testing (~arch) and might not care too much about the state of the
> stable tree, and having stabilization as part of the specific workflow
> will help the state of the stable tree by requiring the developer to
> care about it.

Ah, right. My perspective is mostly coming from the impression that
most developers don't seem to care much for the stable arch trees;
whereas I run stable with only a few exceptions, mostly for things
that I maintain myself.

The other angle here is that, for packages written in C/C++ at least,
it seems dangerous to assume that the package will just work on
non-x86 architectures (and I've even encountered packages where
upstream is somewhat hostile to 32-bits x86). If that is the case, and
assuming that maintainers do not have access to hardware for the other
architectures, then I'm not sure how much sense it makes to involve
the maintainer in the process of tracking stability for their package
on these other architectures, except insofar as explicitly requested
by the arch team.

To frame it differently, I think this whole discussion is very
different for amd64/x86 (which most packages are developed for) vs
pretty much every other architecture. The point is, it doesn't seem to
be a good idea to make people responsible for things that they're very
much not intrinsically motivated to care for, and making maintainers
care for keywording/stabilization on non-convential arches is tricky
from that perspective.

Cheers,

Dirkjan



Re: #wg-stable: Reservations about a "STABLE" & "NeedsStable" bugzilla keywords (re: [gentoo-dev] New Working Group established to evaluate the stable tree)

2016-08-15 Thread Dirkjan Ochtman
On Mon, Aug 15, 2016 at 3:03 PM, Kristian Fiskerstrand  wrote:
> Could you please elaborate a bit? In particular from perspective of (i)
> integration into current workflow, (ii) complexity in application
> maintenance/hosting (iii) cost/benefit considerations

Well, I think stabilization (and, to some extent, keywording) is a
very different process from handling bugs and feature requests. It
would be great if we had tooling that focuses on these instead of
trying to fit into the bug tracker. It would entail a different
workflow, obviously, but I think that's a plus in this case, and we
could make sure we have the command-line tools to make it easy to work
with.

Development/maintenance/hosting is an issue, though it's a bit hard to
say something definitive about it before there's more of a plan of how
such a tool could work. It's enough of a pain for me that I could see
myself investing some time in development.

Perhaps some kind of middle ground would be to handle this stuff in a
separate Bugzilla product, and then making sure we have some tooling
around that to better present the data.

Cheers,

Dirkjan



Re: #wg-stable: Reservations about a "STABLE" & "NeedsStable" bugzilla keywords (re: [gentoo-dev] New Working Group established to evaluate the stable tree)

2016-08-15 Thread Dirkjan Ochtman
On Mon, Aug 15, 2016 at 6:29 AM, Kent Fredric  wrote:
> This sort of stuff makes me feel bugzilla is entirely the wrong platform for
> handling stabilizations and keywords :/

I very much agree; some kind of minimal web app/API would probably be better.

Cheers,

Dirkjan



Re: [gentoo-dev] Packages up for grabs

2016-08-07 Thread Dirkjan Ochtman
On Sun, Aug 7, 2016 at 9:51 AM, Pacho Ramos  wrote:
> This packages are now up for grabs:
> app-portage/euscan

Patrick,

Are you still keeping euscan running?

Cheers,

Dirkjan



Re: [gentoo-dev] Packages up for grabs

2016-08-07 Thread Dirkjan Ochtman
On Sun, Aug 7, 2016 at 9:56 AM, Deven Lahoti  wrote:
> What's the policy on maintaining a package if I'm not (yet, hopefully) an
> official dev? I'd like to take on transmission-remote-gtk since I use it
> fairly often.

That would be great!

I think you want to start by looking at proxy maintenance:

https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers

Cheers,

Dirkjan



Re: [gentoo-dev] rfc: new global use flag: luajit

2016-07-15 Thread Dirkjan Ochtman
On Thu, Jul 14, 2016 at 4:34 PM, William Hubbs  wrote:
>> I'd rather avoid adding more of this until we figure out what to do
>> about multiple Lua versions. The Lua5.1/5.2 split is still stuck
>> nowhere, and luajit is yet another variant to handle.
>
> If we don't do this, the only way to add luajit support to dev-lua/busted is 
> to
> propegate the local use flag into all of its dependencies [1], and that is
> what I'm trying to avoid.

rspamd has (since [1]) used the jit flag to distinguish between lua
and luajit for a while. Then, lua is about lua support in general, and
jit can select between lua and luajit. This is maybe not the best
solution, but not so bad either, in my view.

Cheers,

Dirkjan

[1] https://bugs.gentoo.org/show_bug.cgi?id=572682



Re: [gentoo-dev] man pages: build or copy?

2016-07-09 Thread Dirkjan Ochtman
On Sat, Jul 9, 2016 at 3:54 PM, Neil Bothwick  wrote:
> I've created an ebuild for net-misc/zerotier [1]. This has a BDEP on
> app-text/ronn, the build system uses it to create the man pages. The
> trouble is that ronn is a Ruby program and pulls in a shedload of
> dependencies, just to install man pages.
>
> It seems to me to make more sense to put pre-built man pages in
> ${FILESDIR}/${PV} and copy them with doman. Is this considered the
> correct or acceptable way to deal with this?

In dev-libs/nanomsg, I've hidden building the docs behind the "doc"
USE flag. nanomsg builds it docs with AsciiDoc, which also pulls in
ruby and a bunch of stuff. Personally, I don't care that much about
the ruby packages, but on my servers, I don't generally even need ruby
itself, so I'd rather not install it. Since this grants the user the
choice of how to use your package, it seems in line with Gentoo's
principles.

Cheers,

Dirkjan



Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-10 Thread Dirkjan Ochtman
On Fri, Jun 10, 2016 at 3:06 PM, Ciaran McCreesh
 wrote:
> How do you know? What is your experience in the area of coordinating
> work across repos in a Gentoo-style distribution?

I don't have much experience with ebuilds, but I have plenty of
experience with software components distributed across git submodules,
and larger distributed systems distributed across a bunch of
components developed separately.

Cheers,

Dirkjan



Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-09 Thread Dirkjan Ochtman
On Thu, Jun 9, 2016 at 12:22 PM, Alexander Berntsen  wrote:
> If you mean that we should go with what is currently popular, then
> that would be Microsoft Windows, Mac OS X, and to a lesser degree
> Ubuntu. But I'm not sure what that mental exercise affords us. I am
> more concerned with how we can make Gentoo better, and how we can grow
> and evolve as a distro. I don't think Gentoo as it exists today will
> continue to be a success in 2025. From a user POV I already think that
> Gentoo is likely not the best distro choice for me. But instead of
> immediately abandoning ship like other developers have, I want Gentoo
> to improve.

If you think Exherbo is better for you, then you should probably
use/work on Exherbo instead.

I would tend to agree with those who have written that coordinating
work across repos is kind of a pain. The way we're currently setup,
with a largish active "core" repository and lots of little satellites
seems to work pretty well. We should always invest in ways to make it
easier to contribute work, and to become a dev, and I would not be
opposed to integrating layman/repositories.xml a bit more, but I don't
think your stated goal of totally decentralizing our ebuild tree will
make Gentoo better.

Cheers,

Dirkjan



Re: [gentoo-dev] The future of the Sunrise project

2016-06-07 Thread Dirkjan Ochtman
On Tue, Jun 7, 2016 at 5:37 PM, Michał Górny  wrote:
> I'm against keeping it in repos.xml for more than a month, considering
> the current (huge) state of breakage it is in. Other repositories with
> similar breakage were already removed.

Maybe do a regular old "Packages for grabs" thread to see if anyone
wants to salvage something? Could maybe even do a news message on the
site to get more eyeballs on it.

Cheers,

Dirkjan



Re: [gentoo-dev] The future of the Sunrise project

2016-06-07 Thread Dirkjan Ochtman
On Mon, Jun 6, 2016 at 11:23 PM, Michał Górny  wrote:
> Your thoughts?

I would agree that proxy-maint and GH pull requests are better than
sunrise, and so we should probably sunset (pun intended) the latter.

Cheers,

Dirkjan



Re: [gentoo-dev] Can ATs add missing test deps?

2016-06-06 Thread Dirkjan Ochtman
On Mon, Jun 6, 2016 at 12:36 PM, Alexis Ballier  wrote:
>> It happens every now and then that during ATing, I find that
>> USE=test should pull in extra deps. This usually is an easy and
>> not exactly controversial fix.
>
> +1
>
> I dont think anyone should be prevented from committing trivial fixes :)

+1 from me too.



Re: [gentoo-dev] [RFC] Masterplan for solving LINGUAS problems

2016-06-01 Thread Dirkjan Ochtman
On Wed, Jun 1, 2016 at 3:09 PM, Michał Górny  wrote:
> Excuse me but are you really serious? We are in this swamp because someone 
> tried to be too smart. And what solution do you propose? Let's add another 
> layer of complexity and smartness, for a single variable. Obviously nothing 
> can go wrong with this.

Please stop the derogatory remarks and unnecessary cynicism. If you
think some proposed solution is a bad idea, just explain why you think
it's a bad idea. Not everyone has the same perspective as you on these
things; nor are they likely to be converted to your stance by your
scolding them.

Cheers,

Dirkjan



Re: [gentoo-dev] Packages up for grabs

2016-05-29 Thread Dirkjan Ochtman
On Sun, May 29, 2016 at 5:33 PM, Kristian Fiskerstrand  wrote:
> dev-python/path-and-address

I've added the python project here, too.

Cheers,

Dirkjan



Re: [gentoo-dev] Packages up for grabs

2016-05-29 Thread Dirkjan Ochtman
On Sun, May 29, 2016 at 4:16 PM, Pacho Ramos  wrote:
> dev-python/pylast

I've added the python project for this one.

Cheers,

Dirkjan



Re: [gentoo-dev] Package up for grabs

2016-05-22 Thread Dirkjan Ochtman
On Sun, May 22, 2016 at 9:52 PM, Pacho Ramos  wrote:
> dev-python/pathtools
> dev-python/pygame_sdl2
> dev-python/pyuv
> dev-python/watchdog

I think the Python team can take pathtools and watchdog. Not so sure
about pyuv and pygame_sdl2, though.

Cheesr,

Dirkjan



Re: [gentoo-dev] Gentoo Overlays project needs you!

2016-05-17 Thread Dirkjan Ochtman
On May 17, 2016 8:45 AM, "Michał Górny"  wrote:
> For this reason, I would like to ask others to join the Overlays effort.

Sign me up, let's see what happens.

Cheers,

Dirkjan


[gentoo-dev] Re: USE flag proposal: memcached

2016-05-16 Thread Dirkjan Ochtman
On Sat, May 14, 2016 at 5:19 PM, Dirkjan Ochtman <d...@gentoo.org> wrote:
> I suppose the description can just be "Enable memcached support".

I went ahead and committed a slightly modified description to
use.desc. I also filed bugs against lighttpd (583158) and gearmand
(583160) to rename their flags from memcache to memcached. Anything
else to do here?

(Sorry if this is maybe slightly quick after the initial announcement;
it seemed like there was little discussion here, and today is a day
off so I have some time to do stuff...)

Cheers,

Dirkjan



Re: [gentoo-dev] NEW: split portage/repoman releases now in the tree

2016-05-16 Thread Dirkjan Ochtman
On Mon, May 16, 2016 at 3:39 AM, Brian Dolbec  wrote:
> repoman-2.3.0_rc1 is the stage2 rewrite code. The checks are now
> modular, and using the portage plugin system. The system is not yet
> fully plug and play. Those changes will take place in the stage3
> re-writes.

Thanks for working on this, it sounds great!

Cheers,

Dirkjan



[gentoo-dev] USE flag proposal: memcached

2016-05-14 Thread Dirkjan Ochtman
All,

I want to add a "memcached" USE flag to mail-filters/rmilter. Before
doing so, I looked if there was a global USE flag. There is not, but I
though see usage across 14 packages:

dev-db/pgpool2[memcached]: Use memcached for query caching
dev-php/pecl-mysqlnd_qc[memcached]: Use
dev-libs/libmemcached as a storage handler
mail-filter/opendkim[memcached]: Add support for using
dev-libs/libmemcached
mail-mta/postfix[memcached]: Add support for using
net-misc/memcached for lookup tables
net-analyzer/graphite-web[memcached]: Enable memcached support
net-analyzer/munin[memcached]: Install the packages required for
memcached monitoring.
net-mail/automx[memcached]: Enable memcached support
sys-auth/keystone[memcached]: Installs dependencies needed for using
memcached as a backend
sys-cluster/cinder[memcached]: Installs the memcached server
sys-cluster/gearmand[memcache]: Support memcache daemon (via
dev-libs/libmemcached) for the queue storage.
sys-cluster/nova[memcached]: Installs the memcached server
sys-cluster/swift[memcached]: adds memcached support
www-servers/lighttpd[memcache]: Enable memcache support for mod_cml
and mod_trigger_b4_dl

Most of these seem to depend on dev-libs/libmemcached or
net-misc/memcached, with a few packages depending on language-specific
stuff (e.g. dev-perl/Cache-Memcached or dev-python/python-memcached).

I suppose the description can just be "Enable memcached support".

Any objections?

Cheers,

Dirkjan



Re: [gentoo-dev] On banning merge commits

2016-05-08 Thread Dirkjan Ochtman
On Sun, May 8, 2016 at 2:00 PM, Michał Górny  wrote:
> No, he didn't. He stated an imaginary fact ('we all seem to agree...'), and 
> asked how to *enforce* that formally. That's not how you request differing 
> opinions.

He used "seem to" to state that it was his perspective, and asked
"What is the correct course of action?", which to me does not at all
read as only being about formal enforcement.

> It's rather the common Gentoo reboot in which for Nth time you propose the 
> same thing, pretend that all previous opposition didn't happen and hope 
> people will be tired enough to let you have what you want.

Apparently the previous times it was discussed there was no
satisfactory resolution, or the topic (or understanding thereof) has
advanced since then. Perhaps we should GLEPs more to document such
discussions, so that we don't have to repeat them all the time.

> My response is also a common Gentoo response to bad ideas, and it shouldn't 
> come as a surprise to anyone.

Well, even if it's common, I think it's much worse than Patrice's
initial email. If you think something is a bad idea, lay out why you
think so. If you don't want to repeat yourself, write it up in an
email list or blog post that you can link to after the fact. Your
response of posing a threat of quitting is not productive at all, and
seems kind of childish to me.

Cheers,

Dirkjan



Re: [gentoo-dev] Re: On banning merge commits

2016-05-08 Thread Dirkjan Ochtman
On Sun, May 8, 2016 at 11:25 AM, Kent Fredric  wrote:
> The essential idea being to minimise the amount of congnitive effort a
> human has when trying to explore the history and understand what
> "actually happened" from a master perspective.
>
> "Long histories that go for days only to merge one commit" tend to
> harm this, and I think that's the essential irritation.

This makes sense to me.

Personally, I think rebases are easy in the vast majority of the cases
(specificially for our gentoo tree, where actual conflicts are often
unlikely). However, for long-running branches (either in time, which I
think doesn't happen that often, or in work), making an explicit merge
could still make sense.

(I guess this is slightly different than somehow limiting the length
of the left-sized twig.)

Cheers,

Dirkjan



Re: [gentoo-dev] On banning merge commits

2016-05-08 Thread Dirkjan Ochtman
On Sun, May 8, 2016 at 7:09 AM, Michał Górny  wrote:
>> What is the correct course of action? I would very much like it to be worded 
>> in
>> a document (GLEP and/or Wiki page) so that confusion is avoided and we all 
>> are
>> on the same page on this topic.
>
> You start by accepting my retirement.

Hey Michał,

Patrice is just opening up a discussion on a mailing list. Clearly
there are opposing viewpoints on whether we should use merge commits
and/or how often. Making vague threats without any rationale/reasoning
about why you would dislike any change in this direction is completely
unproductive for the Gentoo community. I would be very interested in
what your proposed way forward is, and why.

Cheers,

Dirkjan



Re: [gentoo-dev] [PATCH] metadata.xsd: upstream maintainer must have exactly one element

2016-05-06 Thread Dirkjan Ochtman
On Fri, May 6, 2016 at 10:14 AM, Göktürk Yüksek  wrote:
> The change only reflects what's already in GLEP 68 [0] which itself
> derives this condition from GLEP 46 [1] which has the following clause:
>
> """
> name should contain a block of text with upstream's name, is mandatory
> and can only appear once.
> """
>
> It has been this way since ~2008 according to the GLEP bug [2].

Thanks. Still, if you want to elicit useful code reviews, my point
stands that it's probably useful to include more context in your
change requests.

Cheers,

Dirkjan



Re: [gentoo-dev] [PATCH] metadata.xsd: upstream maintainer must have exactly one element

2016-05-06 Thread Dirkjan Ochtman
On Fri, May 6, 2016 at 1:16 AM, Göktürk Yüksek  wrote:
> Signed-off-by: Göktürk Yüksek 
> ---
>  metadata.xsd | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/metadata.xsd b/metadata.xsd
> index 8bc6a4e..fe2c5d2 100644
> --- a/metadata.xsd
> +++ b/metadata.xsd
> @@ -137,7 +137,7 @@
>  minOccurs='0'/>
>  -   minOccurs='0'/>
> +   minOccurs='1'/>
> 
>  type='upstreamMaintainerStatusAttrType'
> default='unknown'/>

IMO this patch could do with a bit more rationale. Personally, I don't
like this change, as it seems enough in many cases to just add an
email address for an upstream maintainer (for example, maybe the
upstream maintainer is a mailing list?).

Cheers,

Dirkjan



Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2016-04-24 23:59 UTC

2016-04-26 Thread Dirkjan Ochtman
On Mon, Apr 25, 2016 at 2:05 AM, Robin H. Johnson  wrote:
> Removals:
> dev-go/ed25519  20160421-13:04 blueness   1b62db0
> dev-go/goptlib  20160421-13:04 blueness   1b62db0
> dev-go/siphash  20160421-13:04 blueness   1b62db0
> net-proxy/obfs4proxy20160421-13:04 blueness   1b62db0
>
> Additions:
> dev-go/ed25519  20160421-09:57 blueness   81b6ce6
> dev-go/ed25519  20160421-13:10 blueness   5b8d9c0
> dev-go/goptlib  20160421-09:57 blueness   81b6ce6
> dev-go/goptlib  20160421-13:11 blueness   4333ea4
> dev-go/siphash  20160421-09:57 blueness   81b6ce6
> dev-go/siphash  20160421-13:13 blueness   362b8e3
> net-proxy/obfs4proxy20160421-09:57 blueness   81b6ce6
> net-proxy/obfs4proxy20160421-13:07 blueness   d266ca4

What happened with these?

Cheers,

Dirkjan



Re: [gentoo-dev] glibc 2.23 and willfully breaking stuff

2016-04-19 Thread Dirkjan Ochtman
On Apr 19, 2016 6:28 PM, "Anthony G. Basile"  wrote:
> yeah we need to buy him a drink or something really.  i'd say make him a
> dev but i'm not sure i'd inflict that punishment on anyone :P

+1 make him a dev.

Cheers,

Dirkjan


Re: [gentoo-dev] Packages up for grab

2016-03-31 Thread Dirkjan Ochtman
On Thu, Mar 31, 2016 at 1:17 PM, Alexey Shvetsov  wrote:
> dev-python/configshell
> dev-python/rtslib

I looked at whether these should be owned by the Python team, but I
don't think they should be. It looks like they're low-level utilities
that happen to be written in Python. As such, they probably shouldn't
even be in dev-python.

Cheers,

Dirkjan



Re: [gentoo-dev] metadata.xml GLEP for review

2016-03-19 Thread Dirkjan Ochtman
On Wed, Mar 16, 2016 at 7:43 PM, Michał Górny  wrote:
> Therefore, I've been slowly writing a proper GLEP that would describe
> all of metadata.xml in detail. Here's the current draft for review:

Sounds like a good idea!

> https://wiki.gentoo.org/wiki/User:MGorny/GLEP:68

I reviewed your spec based on my experience from trying to create a
RELAX NG schema for all metadata.xml files that were in the tree at
the time. I assume you've also validated your spec against what's
actually being used? I have a few questions:

- I had the upstream maintainer's email element pegged as mandatory.
Don't you think that makes sense? A name-only maintainer element seems
relatively low-value to me.
- You list a number of the upstream child elements (changelog, doc,
bug-to) as "zero or more". Doesn't it make sense to make (some of)
these zero or one?

Cheers,

Dirkjan



[gentoo-dev] Re: [PATCH dtd] Remove outdated definition of global-scope

2016-03-02 Thread Dirkjan Ochtman
On Wed, Mar 2, 2016 at 12:38 PM, Michał Górny  wrote:
> Remove the long form of  element that was likely used (or
> supposed to be used) in the global metadata scope. It is currently
> referenced in  element only, and judging from the comments,
> it is supposed to always be a URL there.

LGTM!



Re: [gentoo-dev] libressl: proposing a new project and calling for help

2016-02-15 Thread Dirkjan Ochtman
On Sun, Feb 14, 2016 at 10:38 PM, Anthony G. Basile  wrote:
> We discussed the state of libressl today in the council.  Proceeding
> forward with that work, I'm going to propose a new project and getting
> together a team.  Much of the work has already done by hasufell and what
> remain is just following through on his plan.

Is "his plan" detailed anywhere? In other words, what does it mean to
sign up for this project? :)

Cheers,

Dirkjan



Re: [gentoo-dev] New USE_EXPAND NGINX_MODULES_STREAM

2016-02-04 Thread Dirkjan Ochtman
On Thu, Feb 4, 2016 at 11:27 AM, Jason Zaman  wrote:
> Which looks easier and nicer to you?
>
> NGINX_MODULES_HTTP="access auth_basic autoindex browser charset
> fancyindex fastcgi geo gzip limit_req limit_zone map memcached proxy
> realip referer rewrite scgi spdy split_clients ssi upstream_check
> upstream_ip_hash userid uwsgi"
>
> or:
>
> www-servers/nginx nginx_modules_http_access nginx_modules_http_auth_basic 
> nginx_modules_http_autoindex nginx_modules_http_browser 
> nginx_modules_http_charset nginx_modules_http_fancyindex 
> nginx_modules_http_fastcgi nginx_modules_http_geo nginx_modules_http_gzip 
> nginx_modules_http_limit_req nginx_modules_http_limit_zone 
> nginx_modules_http_map nginx_modules_http_memcached nginx_modules_http_proxy 
> nginx_modules_http_realip nginx_modules_http_referer 
> nginx_modules_http_rewrite nginx_modules_http_scgi nginx_modules_http_spdy 
> nginx_modules_http_split_clients nginx_modules_http_ssi 
> nginx_modules_http_upstream_check nginx_modules_http_upstream_ip_hash 
> nginx_modules_http_userid nginx_modules_http_uwsgi

Well, it seems like we could easily skip the _modules_http suffix, and
the difference would not nearly be so large.

The problem I have with it is that, as a user, it's yet another
concept to grasp and configure. Instead of just working with USE flags
(e.g. looking at use.desc or using ufed to review, configuring USE
flags in make.conf or package.use), I now have to find/learn a bunch
of new stuff. What packages use what USE_EXPAND things (e.g. apache
has two), what are valid values for all of these.

Where with simple USE flags, there is a single mechanism that I have
to learn and can apply across the board; with USE_EXPAND stuff, I have
to learn new stuff for each new package that adopts one or more
USE_EXPAND things.

So if this cosmetic expansion is the only advantage, that seems like a
relatively limited one (e.g. it could be improved a lot just by
formatting), and the trade-off of introducing all this extra
complexity doesn't make that much sense to me.

Cheers,

Dirkjan



Re: [gentoo-dev] New USE_EXPAND NGINX_MODULES_STREAM

2016-02-04 Thread Dirkjan Ochtman
On Wed, Feb 3, 2016 at 11:48 PM, Michał Górny  wrote:
> Could we please finally stop introducing global USE flags that are
> going to only be used by a single package? make.conf already looks like
> random mix of randoms these days, with some extra random cruft being
> added every second Tuesday.

This is an interesting point, which I hadn't thought much about.

It seems USE_EXPAND is really popular. What does it bring that has all
these advantages over normal USE flags? It seems like APACHE2_MPMS,
APACHE2_MODULES and CURL_SSL could just be normal USE flags with some
REQUIRED_USE stuff.

Actually, I'm not really sure I understand why we can't use normal USE
flags for CPU_FLAGS_X86 or PYTHON_TARGETS, either.

Cheers,

Dirkjan



[gentoo-dev] Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2016-02-14

2016-02-03 Thread Dirkjan Ochtman
On Tue, Feb 2, 2016 at 3:18 PM, Justin Lecher (jlec)  wrote:
> Could you please sum up the thread and come up with some precise
> question we should discuss or vote on.

The question is: what language should we use for XML validation in the future?

There are two main contenders: RELAX NG (with a compact and an XML
serialization) and XML Schema. Of course conversion between these
schema formats is possible, but the question is what the canonical
language should be and what other formats would be provided (and how).

Summary:

- I contended that RELAX NG compact serialization is more readable,
and that DTD and RELAX NG validation are equally fast. I don't have
much experience with XML Schema, but I do have a conversion tool for
RNC (compact RELAX NG) -> RNG (RELAX NG XML syntax).
- Michał has used both RELAX NG and XML Schema, and prefers the
latter. It's more popular, and it seems that cross-referencing things
is not supported (trivially) in RELAX NG, whereas it should be in XML
Schema.
- Robin prefers XML Schema, but can live with both.
- trang seems to be a pretty decent tool for schema conversion, but it
doesn't handle XML Schema as an input language (likely because of the
complexity of XML Schema).
- There is a standard for referring to RELAX NG or XML Schema schemas
from XML documents, which would be useful for tool authors.
- emacs nXML mode works only with RNC schema, which is a reason for
Ulrich to prefer it.
- Brian seems to like RNC for readability/flexibility reasons.

I hope other will jump in if they feel I missed
something/misrepresented their opinions.

Cheers,

Dirkjan



Re: [gentoo-dev] New schema language for metadata validation?

2016-01-27 Thread Dirkjan Ochtman
On Wed, Jan 27, 2016 at 4:43 PM, Michał Górny  wrote:
> Yes, that part makes some sense. Except that it immediately follows
> braces which makes me think it applies only to the thing in the braces.
> Furthermore, the use of {} vs () seems pretty much random, and the &
> is completely unclear what it could mean (I'm not reading the docs
> here!). I look at it and I wonder if that forces some ordering or not,
> if it supports interspersing or not. And finally, the fact that '*'
> follows closing brace on the other end of file does not help
> readability.

A full expression runs from a keyword to the closing brace (e.g.
"element  { }"). Parentheses are only used to group expressions
that have the infix operators (one of "," for concatenate -- e.g.,
order --, "|" -- alternative -- and "&" -- interleaving), because
there's no implicit precedence order. Yes, the quantizer comes at the
end. On the other hand, you could rewrite the large expression to be a
named pattern, and then put the quantization after the pattern name if
you prefer that style. That would probably make more sense for large
named patterns. :)

Cheers,

Dirkjan



Re: [gentoo-dev] New schema language for metadata validation?

2016-01-27 Thread Dirkjan Ochtman
On Wed, Jan 27, 2016 at 4:20 PM, Michał Górny  wrote:
> First of all, I don't like RELAX-NG Compact at all. It looks like
> someone tried hard to combine some variation of BNF, DOCTYPE
> and something else in order to get something that is both readable
> and compact. And got a result that doesn't meet either criteria.
> It looks like some terrible mixture of over-verbose descriptive text
> format with a lot of enigmatic symbols that are not even clear what
> they apply to.

Wow, that's surprising to me! I found that a lot of the compact syntax
made immediate sense to me as I was already familiar with what ?*+
mean from EBNF and regular expressions. For me, it's mostly how much
less verbose it is than a full XML syntax that makes it easier to
comprehend and manipulate.

> Secondly, RELAX-NG and XML Schema look pretty similar in volume.
> However, XML Schema looks definitely more readable, robust and XML-ish
> (and doesn't use camelcase!). Furthermore, as far as I'm aware XML
> Schema is more widely supported (not sure if that applies to any tools
> we're considering).

I agree that XML Schema is probably more widely supported, though it'd
be hard to assess by how much. On other hand, I find XML Schema much
less readable; and it feels like "more XML-ish" is just because it
uses namespaces a lot more, and is more commonly used? Indeed, to me
the fact that RELAX NG is less XML-ish is a positive aspect.

> Therefore, I'd suggest we just ship properly hand-written XML Schema,
> with some nice comments. I don't see a reason to ship any RELAX-NG
> files unless we actually have tools that support only that.

I'd be curious what Michael, Ulrich, and others think.

Cheers,

Dirkjan



Re: [gentoo-dev] New schema language for metadata validation?

2016-01-27 Thread Dirkjan Ochtman
On Tue, Jan 26, 2016 at 9:52 PM, Michael Orlitzky  wrote:
> I would appreciate examples of some common tasks like validating
> projects.xml, but since we don't have those now, it's not critical.
> This used to be kinda straightforward with xmllint,
>
>   $ xmllint --valid --noout projects.xml && echo "OK"

The closest equivalent for this is just:

xmllint --relaxng metadata.rng --noout metadata.xml && echo "OK"

I.e., you have to specify the schema file manually (also, as mentioned
before, libxml2 does not support RNC natively, so you have to convert
to RNG first -- but we can keep those around). You can use a non-HTTPS
URL for --relaxng, as well.

There is a standard to link an XML file to a RELAX NG (XML or compact
syntax) schema, here:

http://www.w3.org/TR/xml-model/

But libxml2 does not seem to support it; that is, substituting the
DOCTYPE for an xml-model processing instruction and then using xmllint
--valid does not do the right thing (it complains there's no DOCTYPE).

Cheers,

Dirkjan



Re: [gentoo-dev] Re: News item: Upgrading Apache from 2.2 to 2.4

2016-01-27 Thread Dirkjan Ochtman
On Fri, Jan 22, 2016 at 3:20 PM, Kristian Fiskerstrand  wrote:
> Advanced notice, please

Committed 2016-01-27-upgrading-to-apache-2_4 to news.

Time to request stabilization?

Cheers,

Dirkjan



Re: [gentoo-dev] New schema language for metadata validation?

2016-01-27 Thread Dirkjan Ochtman
On Wed, Jan 27, 2016 at 1:09 PM, Michał Górny  wrote:
> Could you post a generated .rng and XML Schema files for comparison?
> They don't have to be perfect conversions, just to see how different
> they are.

Here's the RNG, generated with dev-python/rnc2rng:

https://raw.githubusercontent.com/djc/gentoo-data-dtd/metadata-rnc/metadata.rng

The best way to convert from RELAX NG to XML Schema seems to be with
trang; I downloaded an older binary and a JDK on my laptop, but
couldn't easily get it to run. I don't really have a Gentoo machine on
which I want to install the whole Java shebang, so maybe someone else
can run a quick conversion?

Cheers,

Dirkjan



Re: [gentoo-dev] New schema language for metadata validation?

2016-01-27 Thread Dirkjan Ochtman
On Wed, Jan 27, 2016 at 3:21 PM, Michael Orlitzky  wrote:
>> But libxml2 does not seem to support it; that is, substituting the
>> DOCTYPE for an xml-model processing instruction and then using xmllint
>> --valid does not do the right thing (it complains there's no DOCTYPE).
>
> But does it /complain/ about the xml-model? Is it safe to add that to
> our XML files (in terms of tooling and stability of the spec)? If so, I
> can at least script the validation: parse the href from xml-model, fetch
> it somehow, run it through rnc2rng, and then pass it to xmllint.

It does not seem to complain about the xml-model, so that should be
quite viable.

Can I ask what your interest is? What tools are you involved with that
would want to use this?

> Or we could even generate the rng files automatically and host them like
> we do the DTDs to skip a step.

Yeah, that's what I was thinking. Too bad that we have to drag around
both, but I think the advantages in terms of readability and
modifiability for RNC and tool support for RNG really do make it the
best solution to have canonical RNCs with pre-generated RNGs.

Cheers,

Dirkjan



[gentoo-dev] New schema language for metadata validation?

2016-01-26 Thread Dirkjan Ochtman
All,

TL;DR: I think we should switch from DTD to RELAX NG (compact syntax,
ideally) for our XML validation needs. It is more expressive and more
readable.

Most people who know anything about XML stuff know that DTDs are not
that great a solution for validation. Their expression power is very
limited; there are a few examples of this is in our metadata.dtd [1].
For a few years now, I've wanted to see if we could replace
metadata.dtd with something in RELAX NG, which is a more modern XML
schema language; it's an ISO standard with an emphasis on readability
both for humans and for tools (by using a rigorous formalism). Some
arguments in favor of RELAX NG (and some counter-arguments) are
enumerated on Tim Bray's weblog [2]. I've created a compact syntax
schema for metadata that can validate all metadata.xml files currently
in the tree, as an example [3].

Some arguments against:

- Not enough tool support for RELAX NG: I'd be curious to hear what
tools you want to use. At least libxml2 supports RELAX NG natively.
The Python lxml library uses that support to provide pretty simple
RELAX NG validation. libxml2 does not have native compact syntax
support, but I maintain a simple library called rnc2rng [4] that is
used transparently by lxml if installed. rnc2rng also comes with a
rnc2rng command-line script to do the conversion.

- Performance: in a quick test with lxml (backed by libxml2), RELAX NG
validation takes very similar time compared to DTD. Testing with
~19000 metadata.xml files in the tree, with DTD (best of 3):

real0m2.861s
user0m2.560s
sys0m0.296s

With RNC (best of 3):

real0m3.058s
user0m2.688s
sys0m0.364s

We could probably easily maintain an XML Schema shadow schema if
that's really desired, but I would be in favor of making RELAX NG our
main schema language. I can easily do the work to update repoman for
this (I've already refactored the metadata code in repoman). What
other stuff would need to be updated?

Comments?

Cheers,

Dirkjan

[1] https://github.com/djc/gentoo-data-dtd/blob/metadata-rnc/metadata.dtd
[2] https://www.tbray.org/ongoing/When/200x/2006/11/27/Choose-Relax
[3] https://github.com/djc/gentoo-data-dtd/blob/metadata-rnc/metadata.rnc
[4] https://github.com/djc/rnc2rng



Re: [gentoo-dev] Gentoostats

2016-01-24 Thread Dirkjan Ochtman
On Sun, Jan 24, 2016 at 4:59 PM, Andreas K. Hüttel  wrote:
> Gentoostats is a typical stillbirth of the Gentoo Google Summer of Soon-
> Obsolete Code. Would I be happy if someone were to revive and actually deploy
> it (the last point is important!)? YES!

When I last looked into it, I couldn't actually access Gentoo infra to
deploy it on. If that would be possible, I wouldn't mind taking a look
at what can be done here.

Cheers,

Dirkjan



[gentoo-dev] Re: News item: Upgrading Apache from 2.2 to 2.4

2016-01-20 Thread Dirkjan Ochtman
On Wed, Jan 13, 2016 at 6:13 PM, Dirkjan Ochtman <d...@gentoo.org> wrote:
> After what feels like ages, we're just about ready to stabilize
> apache-2.4. Since this is a major upgrade that in many cases require
> configuration changes, we wanted to do a news item. After some
> discussion with Lars (Poly-C), here's an initial attempt at a draft.

I'm currently attempting this upgrade on a stable system I run. It
mostly just works, although I run into trouble when trying to load
modules that are not part of www-server/apache (e.g. mod_wsgi). I
resolved this by reemerging all packages listed in `equery b
/usr/lib/apache2/modules/*`, but maybe there's a different way? Should
this be in an elog message, or part of the news item?

Cheers,

Dirkjan



[gentoo-dev] Re: News item: Upgrading Apache from 2.2 to 2.4

2016-01-17 Thread Dirkjan Ochtman
Second attempt!

===

Title: Upgrading Apache from 2.2 to 2.4
Author: Dirkjan Ochtman <d...@gentoo.org>
Content-Type: text/plain
Posted: 2016-01-17
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: www-servers/apache

With the 2.4 branch released by upstream almost 4 years ago, stable
Gentoo systems will soon be upgraded from apache 2.2 to apache 2.4.
When upgrading, chances are some configuration changes have to be
made. Upstream has a handy guide:

https://httpd.apache.org/docs/2.4/upgrading.html

For more information on all the new features, start here:

https://httpd.apache.org/docs/trunk/new_features_2_4.html

===

A bit more concise and less personal. Better?

Cheers,

Dirkjan



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

2016-01-17 Thread Dirkjan Ochtman
On Sun, Jan 17, 2016 at 8:59 PM, Michał Górny  wrote:
> dev-lang/erlang  : djc@

erlang only gets whatever is necessary to keep bug reporters happy,
plus whatever I need to keep couchdb running. Please feel free to join
up if you have any related expertise whatsoever.

Cheers,

Dirkjan



Re: [gentoo-dev] Re: News item: Upgrading Apache from 2.2 to 2.4

2016-01-14 Thread Dirkjan Ochtman
On Thu, Jan 14, 2016 at 10:53 AM, Duncan <1i5t5.dun...@cox.net> wrote:
>> Display-If-Installed: www-servers/apache
>
> Can't that be made  2.4 need a news item about something they've already taken care of?

This makes sense to me, though I imagine it could be annoying if
people (stupidly, but whatever) postpone reading their news items
until after the upgrade. Is this a canonical approach? Would like some
feedback from the experts, here!

Cheers,

Dirkjan



[gentoo-dev] News item: Upgrading Apache from 2.2 to 2.4

2016-01-13 Thread Dirkjan Ochtman
Hi all,

After what feels like ages, we're just about ready to stabilize
apache-2.4. Since this is a major upgrade that in many cases require
configuration changes, we wanted to do a news item. After some
discussion with Lars (Poly-C), here's an initial attempt at a draft.

===

Title: Upgrading Apache from 2.2 to 2.4
Author: Dirkjan Ochtman <d...@gentoo.org>
Content-Type: text/plain
Posted: 2016-01-13
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: www-servers/apache

Upstream released the 2.4 version of the Apache HTTPD almost 4 years
ago. Though many users have moved to other HTTP servers, Portage still
has quite a few reverse dependencies, so it took the small team of
maintainers until now to bring Apache 2.4 to stable. In part, this is
because Apache 2.4 overhauls some often-used parts of the
configuration; chances that you will have to make some changes to your
configuration are quite high. On the other hand, apache-2.4.18
includes support for HTTP 2.0, so you get that (almost) for free!

Rather than trying to enumerate all the differences here, we'd like to
point you to the upstream upgrading document, which can be found here:

https://httpd.apache.org/docs/2.4/upgrading.html

For more information on all the new features, start here:

https://httpd.apache.org/docs/trunk/new_features_2_4.html

===

Please use your usual 72 hours of feedback window fruitfully!

Cheers,

Dirkjan



Re: [gentoo-dev] packages to grab

2016-01-08 Thread Dirkjan Ochtman
On Thu, Jan 7, 2016 at 2:50 PM, Justin Lecher (jlec)  wrote:
> due to changes in real life I need to cut back vastly my day to day
> maintainer work starting in February. So far I have no clue how much
> time I can devote to Gentoo in nearer future.

Sad to see this happen! I'm sure Gentoo will be worse off for it, but
best of luck with your real life stuff.

Cheers,

Dirkjan



Re: [gentoo-dev] packages to grab

2016-01-08 Thread Dirkjan Ochtman
On Thu, Jan 7, 2016 at 4:40 PM, Matthew Thode  wrote:
> gonna take these unless anyone yells at me.
>
> modified:   dev-python/ipaddress/metadata.xml
> modified:   dev-python/lz4/metadata.xml
> modified:   dev-python/mysqlclient/metadata.xml

It would probably make sense to put these in the Python project, too?

Cheers,

Dirkjan



Re: [gentoo-dev] RFC: automatically mailing people on pkgcheck problems with their packages

2015-12-06 Thread Dirkjan Ochtman
On Sun, Dec 6, 2015 at 3:36 PM, Michał Górny  wrote:
> So what do you think? Would it be fine to mail the package maintainers
> whenever their packages break? Would it be a problem if I just CC-ed
> all the maintainers on the gentoo-automated-testing mails? Please note
> that the breakages are catched per-package, and the script wouldn't be
> able to respect restrict="" or hand-written maintainer descriptions ;-).

Sounds great to me.

Cheers,

Dirkjan



Re: [gentoo-dev] Re: EAPI 6 portage is out!

2015-11-22 Thread Dirkjan Ochtman
On Sun, Nov 22, 2015 at 4:54 PM, Michael Palimaka  wrote:
> On 22/11/15 05:51, Andrew Savchenko wrote:
> Is the state of stable really that bad? I see this sentiment a lot.
>
> I run mostly-stable systems and rarely have an issue with old/missing
> packages (but I'm involved in the maintenance of many of the packages I
> use so I try to keep on top of stable requests).
>
> Are there particular areas that are lagging particularly, or is it just
> in general?

I also run mostly-stable systems, and mostly haven't had problems.
Some specific areas lag (like apache-2.4), but I think generally it
works quite well.

Cheers,

Dirkjan



Re: [gentoo-dev] Re: Gentoo-hosted code review

2015-11-02 Thread Dirkjan Ochtman
On Mon, Nov 2, 2015 at 2:04 PM, Kristian Fiskerstrand  wrote:
> The way I see it, keeping review and committing/pushing separate is a
> good thing, and removes a lot of the concerns about hosting a review
> platform as it is sufficient with read-access to repositories.
>
> Thanks for showing at least one of the alternatives.

+1.

FWIW, I think most of the innovation in review UX (insofar as there is
any) is happening on ReviewBoard, which is another FOSS review-only
tool, written on top of Django. A Python-based app might also be more
hackable for the Gentoo dev audience and possibly more
security-sensible. I know that Mozilla is starting to deploy it quite
successfully.

Cheers,

Dirkjan



  1   2   3   4   >