[gentoo-dev] Re: [PATCH v2] profiles: promote USE=vulkan to global USE flag

[Luca Barbato]

On 22/05/23 22:41, Nick Sarnie wrote:

On 5/22/23 16:40, Matt Turner wrote:

On Mon, May 22, 2023 at 4:27 PM Sam James  wrote:

Thanks to leio for this improved phrasing.

Signed-off-by: Sam James 
---
  profiles/use.desc | 1 +
  1 file changed, 1 insertion(+)

diff --git a/profiles/use.desc b/profiles/use.desc
index 2d5489acc568..47438c839071 100644
--- a/profiles/use.desc
+++ b/profiles/use.desc
@@ -344,6 +344,7 @@ videos - Install optional video files (used in 
some games)

  vim-syntax - Pulls in related vim syntax scripts
  vnc - Enable VNC (remote desktop viewer) support
  vorbis - Add support for the OggVorbis audio codec
+vulkan - Add support for 3D graphics and computing via the Vulkan 
cross-platform API

  wavpack - Add support for wavpack audio compression tools
  wayland - Enable dev-libs/wayland backend
  webkit - Add support for the WebKit HTML rendering/layout engine
--
2.40.1


Looks good to me.


Same, rb


+1

[gentoo-dev] Re: [PATCH] profiles/targets/desktop: disable USE=xvid by default

[Luca Barbato]

On 12/01/22 03:45, Georgy Yakovlev wrote:
> it's an ancient codec that is barely used nowadays
> so let's disable it by default.
> Users are free to re-enable if required.
> 

It is fine, btw this mpeg4 dialect is still supported by libavcodec so
only people wanting to encode using the original codec instead
libavcodec would need to enable it.

lu

[gentoo-dev] Re: [RFC] Proposed dates for Python 3.10 switch and Python 3.8 removal

[Luca Barbato]

On 11/11/21 17:05, Michał Górny wrote:
> Hi,
> 
> I'd like to add some dates regarding 3.8 removal and 3.10 switch to
> the implementation timeline [1].
> 
> Unless I'm mistaken, CPython is following a yearly release cycle these
> days.  I think it would make sense to also aim for a yearly cycle
> in Gentoo, i.e. roughly switch to the next minor version every year.
> 
> Hence my proposal would be to:
> 
> a. ASAP: send "please port your packages to py3.9" mail
> 
> b. 2022-06-01: remove py3.8 target
> 
> c. ASAP: stabilize Python 3.9 interpreter + start working towards
> unmasking python3_9 flag on stable
> 
> d. 2022-06-01: switch the default to py3.10
> 
> In other news, there's a good chance that PyPy3 will catch up to 3.9
> before we remove 3.8.
> 
> WDYT?

If the interpreters we support are aligned to 3.9 by the time python 3.8
is EOL, it is fine.

Maybe could be good to add tags to git when we do this so people have an
easy way to update from older setups.

lu

[gentoo-dev] Re: Guidance on adding kernel config checks to ebuilds

[Luca Barbato]

On 27/09/21 18:10, Mike Gilbert wrote:
> I'm looking to solicit opinions on when it is appropriate for an
> ebuild to check for kernel config options using linux-info.eclass. I
> don't think we have any guidelines documented, instead leaving it up
> to the "common sense" of package maintainers.
> 
> Adding linux-info calls to pkg_pretend or pkg_setup causes slowdowns
> when running emerge, so we should do so only when there is a
> compensating benefit. It doesn't make sense to check for kernel
> options that are very commonly enabled. But what is "very common"?
> 
> An obvious example would be CONFIG_INET, which controls IPv4 support
> in the kernel. It does not make sense to check for that in every
> package that uses AF_INET sockets.
> 
> A less obvious example: a user filed a bug against net-misc/dhcpcd
> today asking that we check for CONFIG_PACKET [1]. My first thought was
> "why would you ever disable that?". The option description even says
> "if unsure, say Y". However, I suppose it is technically possible to
> run a Linux system with it disabled.
> 
> I think a reasonable rule of thumb would be to assume we can rely on
> options that are enabled by "make defconfig". If the user chooses to
> disable them, they are responsible for anything that breaks.
> 
> Thoughts?

We can document in the wiki that going against defconfig means you keep
the pieces when something explodes colorfully and/or come up with a even
smaller list of config items expected.


lu

Re: [gentoo-dev] News item for eudev deprecation

[Luca Barbato]

On 22/08/21 22:14, Anthony G. Basile wrote:
> Hi everyone,
> 
> Yes!  It is time to finally deprecate eudev!  sys-fs/udev now builds
> under musl!  My original purpose for maintaining eudev was because
> systemd + musl did not play well together when udev was absorbed into
> the sytemd repo.  Now thanks to patches from openembedded, they do, and
> my original reason for maintaining eudev is no longer valid.  So its
> time to retire eudev.  It has served its purpose as a stop-gap.
> 

Upstream systemd is still prone to use any glibc-only api they find
interesting and any gcc-only feature they deem useful (as seen in a
recent discussion on the musl ml this month).

OpenEmbedded shares, hopefully, all our requirements regarding libc and
compiler so it is good to work with them, assuming maintaining the
patchset on top of udev is simpler than adding the udev changes on top
of eudev.

In both cases it is lots of work and I'm grateful to the people that are
willing to put effort in supporting standard libcs and alternative C
compilers :)

lu

Re: [gentoo-dev] [RFC] Removing SHA512 hash from Manifests

[Luca Barbato]

On 24/07/21 17:16, Michał Górny wrote:
> Hi, everyone.
> 
> I've been asked to repost the idea of removing SHA512 hash from
> Manifests, effectively limiting them to BLAKE2B.
> 
> The 'old' set of Gentoo hashes including SHA512 went live in July 2012.
> In November 2017, we have decided to remove the two other hashes and add
> BLAKE2B in their stead.  Today, all Gentoo packages are using BLAKE2B
> and SHA512 hashes.
> 
> To all extent, this is purely a cosmetic change.  The benefit from
> removing the additional hash is negligible, both from space perspective
> and hashing speed perspective.  The benefit from keeping two hashes is
> also negligible.
> 
> Back during the 2017 discussion, Infra came to the conclusion that we're
> going to keep SHA512 for a transition period, then remove it, and stay
> with a single hash algorithm.  In my opinion, we have kept it long
> enough.
> 
> WDYT?
> 

I'd remove it once we have a second hash to add and/or BLAKE2B is
widespread enough on upstream.

lu

Re: [gentoo-dev] [PATCH 2/2] kernel-install.eclass: Warn about linux-firmware in pkg_pretend()

[Luca Barbato]

On 17/06/2020 12:57, Ulrich Mueller wrote:

On Wed, 17 Jun 2020, Michał Górny wrote:
  

+# @FUNCTION: kernel-install_pkg_pretend
+# @DESCRIPTION:
+# Check for missing optional dependencies and output warnings.
+kernel-install_pkg_pretend() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   if ! has_version -d sys-kernel/linux-firmware; then
+   ewarn "sys-kernel/linux-firmware not found installed on your 
system."
+   ewarn "This package provides various firmware files that may be 
needed"
+   ewarn "for your hardware to work.  If in doubt, it is 
recommended"
+   ewarn "to pause or abort the build process and install it 
before"
+   ewarn "resuming."
+
+   if use initramfs; then
+   elog
+   elog "If you decide to install linux-firmware later, you can 
rebuild"
+   elog "the initramfs via issuing a command equivalent 
to:"
+   elog
+   elog "emerge --config ${CATEGORY}/${PN}"
+   fi
+   fi
+}


Should we really warn about a package that (in its default
configuration) can only be installed if the user accepts non-free
licenses?


Yes, since those binary blobs are needed to have functioning hardware.

lu

Re: [gentoo-dev] [PATCH 1/2] eclass/cargo.eclass: add cargo_src_configure

[Luca Barbato]

On 12/06/2020 18:24, Georgy Yakovlev wrote:

On 6/12/20 4:16 AM, Luca Barbato wrote:

On 12/06/2020 11:04, Georgy Yakovlev wrote:

+# cargo_src_configure --no-default-features


Shall we default in not-defaulting so we can spare some boilerplate?

I don't think so. Let me explain.

First of all, this will force to explicitly micro-manage all the
features for all the packages in the tree.



The idea is:
- if myfeatures is empty, do not pass --no-default-features.
- if myfeatures has content, automatically pass --no-default-features.

--no-default-features --features default seems working as intended btw.

lu

Re: [gentoo-dev] [PATCH 1/2] eclass/cargo.eclass: add cargo_src_configure

[Luca Barbato]

On 12/06/2020 11:04, Georgy Yakovlev wrote:

+#  cargo_src_configure --no-default-features


Shall we default in not-defaulting so we can spare some boilerplate?

lu

Re: [gentoo-dev] Re: [PATCH] eclass/cargo.eclass: drop EAPI=6 support

[Luca Barbato]

On 12/06/2020 05:15, Georgy Yakovlev wrote:

This will also allow me to start adding cross support to cargo.eclass
with new cross-friendly variables.


experimental cross support landed in rust-1.44.0 today [1]



Yes please :)

lu

Re: [gentoo-dev] dev-python/llvmlite update to 0.32

[Luca Barbato]

On 10/05/2020 13:21, Aisha Tammy wrote:

On 5/10/20 2:02 AM, Michał Górny wrote:

W dniu sob, 09.05.2020 o godzinie 22∶39 -0400, użytkownik Aisha Tammy
napisał:

Hey all,
   I was hoping to upgrade the dev-python/numba jit compiler in proxy-
maint but it depends on dev-python/llvmlite >=0.31
Current version of llvmlite is stuck at 0.30 which is preventing the
numba package from being upgraded.
It is at a risk of last rite retiring because its stuck at 3.6


It is more likely to be last rited because upstream still didn't manage
to port it to LLVM 9.  I don't have LLVM 8 anymore, and I don't have
the resources to build 3 different LLVM versions.


The following issue tells that LLVM 9 is now supported :)
https://github.com/numba/llvmlite/issues/523

They haven't updated their documentation correctly.

PS: regarding lack of resources.
I have a spare computer and am willing to use that to do some testing for
interesting packages like these. I hope it can help us keep a few more
packages that would otherwise be killed off.

PPS: an aside, but i was always curious where the term last rited came from.
I feel like I am part of the mafia when I use that term XD


It is more about being an undertaker :)

lu

Re: [gentoo-dev] [PATCH 3/3] app-admin/kube-bench: convert to go-module go.sum

[Luca Barbato]

On 09/02/2020 22:16, Michael 'veremitz' Everitt wrote:

It is left as an exercise for the reader, who is transgressing here...



I warned you [once][1] that this kind of banter is not welcome.
This is the second warning.

lu

[1]: https://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg87818.html

[gentoo-dev] Re: [PATCH] linux-mod.eclass: pass proper arch to kernel's build system

[Luca Barbato]

On 03/01/2020 12:52, Jason A. Donenfeld wrote:

A user reported that when compiling modules for a system with a 64-bit
kernel and a 32-bit userland, there were linker errors. This patch here
is an attempt to fix that by making sure that we always use the kernel
ABI when giving target build parameters.

Signed-off-by: Jason A. Donenfeld 
Fixes: https://bugs.gentoo.org/704468
Cc: joakim.tjernl...@infinera.com
Cc: ker...@gentoo.org
---
  eclass/linux-mod.eclass | 11 +++
  1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/eclass/linux-mod.eclass b/eclass/linux-mod.eclass
index b6dc2c84d09..60b0d88e9b9 100644
--- a/eclass/linux-mod.eclass
+++ b/eclass/linux-mod.eclass
@@ -671,13 +671,16 @@ linux-mod_src_compile() {
# spaces that must be preserved. If don't do this, then 
the stuff
# inside the variables gets used as targets for Make, 
which then
# fails.
-   eval "emake HOSTCC=\"$(tc-getBUILD_CC)\" \
-   CROSS_COMPILE=${CHOST}- \
-   LDFLAGS=\"$(get_abi_LDFLAGS)\" \
+   local KERNEL_CHOST="$(ABI=${KERNEL_ABI} get_abi_CHOST)"
+   local KERNEL_LDFLAGS="$(ABI=${KERNEL_ABI} 
get_abi_LDFLAGS)"
+   local HOST_CC="$(tc-getBUILD_CC)"
+   eval "emake HOSTCC=\"${HOST_CC}\" \
+   CROSS_COMPILE=${KERNEL_CHOST}- \
+   LDFLAGS=\"${KERNEL_LDFLAGS}\" \
${BUILD_FIXES} \
${BUILD_PARAMS} \
${BUILD_TARGETS} " \
-   || die "Unable to emake HOSTCC="$(tc-getBUILD_CC)" 
CROSS_COMPILE=${CHOST}- LDFLAGS="$(get_abi_LDFLAGS)" ${BUILD_FIXES} ${BUILD_PARAMS} 
${BUILD_TARGETS}"
+   || die "Unable to emake HOSTCC="${HOST_CC}" 
CROSS_COMPILE=${KERNEL_CHOST}- LDFLAGS="${KERNEL_LDFLAGS}" ${BUILD_FIXES} ${BUILD_PARAMS} 
${BUILD_TARGETS}"
cd "${OLDPWD}"
touch "${srcdir}"/.built
fi



It seems doing what it is supposed to do. what is the testing condition?

lu

Re: [gentoo-dev] [PATCH v2] ruby-ng.eclass: Include (-) in RUBY_TARGETS USE-dependencies

[Luca Barbato]

On 03/01/2020 23:34, Michael 'veremitz' Everitt wrote:

On 03/01/20 10:36, David Seifert wrote:

On Thu, 2020-01-02 at 21:54 +, Michael 'veremitz' Everitt wrote:

On 02/01/20 21:08, Michał Górny wrote:

On Thu, 2020-01-02 at 21:15 +0100, Ulrich Mueller wrote:

On Thu, 02 Jan 2020, Michał Górny wrote:

--- a/eclass/ruby-ng.eclass
+++ b/eclass/ruby-ng.eclass
@@ -137,7 +137,7 @@ ruby_samelib() {
local res=
for _ruby_implementation in $(_ruby_get_all_impls); do
has -${_ruby_implementation} $@ || \
-   res="${res}ruby_targets_${_ruby_impleme
ntation}?,"
+   res="${res}ruby_targets_${_ruby_impleme
ntation}(-)?,"
done
  
  	echo "[${res%,}]"

Hadn't we established that ruby_samelib() is dead code, no longer
used
since 2010?


You did.  However, it isn't marked as private API and I'm not the
eclass
maintainer to take care of removing public API.  I have no clue if
Ruby
project doesn't have some secret overlays using it.


 You can't use QA super-powerz ?! BDFL + sub-BDFL ?!
*

* Thought the tags probably worth making explicit


Can you please stop polluting the -dev mailing list with this senseless
chatter?



Perhaps I should remind you that this is a public mailing list (or hasn't
successfully been censored Yet) and not a private communication channel for
developers (see -core for this). But I don't need to tell you this



Hi, at least a person is displeased with your attempt at humor, could 
you please stop doing this? It does not add anything to the conversation 
and it is unpleasant.


lu

PS: This counts as friendly warning.

[gentoo-dev] Re: [RFC] Perspectives on improving (dis-hacking) python-single-r1

[Luca Barbato]

On 23/11/2019 16:48, Michał Górny wrote:

Hello,

Some aspects of the current design of python-single-r1 are gross hack.
I'd like to discuss potential alternatives to them.


Preamble

For the purpose of this mail, let's establish two terms.

'Single' will refer to packages allowing the user to select 1 out of N
supported Python implementations.  This generally means programs linking
to libpython, foreign build systems and end-user apps where installing
multiple copies of the code makes no sense.  Those are the packages
using python-single-r1.

'Multi' will refer to packages allowing the user to select M out of N
supported Python implementations.  This generally means ebuilds for
Python packages (modules, extensions).  Those are the packages using
python-r1 (usually via distutils-r1).

'Single' packages can PYTHON_USEDEP-end either on other 'single'
or on 'multi' packages.  However, 'multi' packages can only
PYTHON_USEDEP-end on other 'multi' packages (because 'single' wouldn't
ever be able to satisfy >1 impl).


Current status
==
Currently, 'single' packages use two sets of USE flags: PYTHON_TARGETS
and PYTHON_SINGLE_TARGET.  The latter is used to select
the implementation used, and the former is used only for technical
reasons.  Selected PST is required to be also enabled in PT.

All dependencies enforce both PST and PT match.  The PYTHON_USEDEP is
generally a giant hack that's meant to work both for depending
on 'single' and 'multi' packages.  I'm not convinced this was the best
choice anymore.

In single-to-single deps, PYTHON_USEDEP enforces both PST and PT flags
to match.  This means that if two packages have matching PST but for
some reason were built with different PT, users end up having to switch
PT and rebuild the package without any real change.

In single-to-multi deps, PYTHON_USEDEP enforces PT flags.  For this
reason, we need to enforce that selected PST is always present in PT,
and users always have to put both flags in package.use.

There's also a gross hack in PYTHON_USEDEP in 'multi' packages that
means to prevent multi-to-single deps.  However, the dep mismatch it
causes is not very readable.


Alternative 1: PYTHON_TARGETS only
==
The first alternative I'd like to explore is removing
PYTHON_SINGLE_TARGET flags.  Why were they added in the first place?
The primary goal was to be able to set PT to 2.7+3.x without requiring
people to adjust flags for every 'single' package out there.  Plus, it
turned out very convenient for Python team members who want to enable
all PT but obviously can't do the same for PST.

Originally I brought this proposal in context of automated REQUIRED_USE
conflict resolution.  However, that was rejected by the Council.  Still,
it may start making sense again in the near future when we start
removing py2.7 and pypy2.7 support.  If we can limit PT to one
implementation, and handle the remaining packages via IUSE defaults
and package.use, this may just work.

The inconvenience to people enabling multiple PT will remain though.


Alternative 2: new dependency API
=
If PST is going to stay, we may look into removing PT from 'single'
packages instead.  The idea is to provide new method of generating
cross-package deps that doesn't require fake flags.

PYTHON_USEDEP would continue working through a transitional period.
When it's entirely gone, we can remove PYTHON_TARGETS from 'single'
packages.

Single-to-single deps would switch to PYTHON_SINGLE_USEDEP, that only
enforces PST and disregards PT entirely.

Single-to-multi deps would have to use a new generator function,
$(python_gen_multi_dep ...) that would create appropriate USE-mapping
from PST to PT.

Example ebuild would have:

RDEPEND="app-foo/singlepkg[${PYTHON_SINGLE_USEDEP}]
 $(python_gen_multi_dep '
  dev-python/foo[${PYTHON_USEDEP}]
  dev-python/bar[${PYTHON_USEDEP}]
 ')"

This will generate something like:

 pst_python2_7? (
 dev-python/foo[pt_python2_7(-)]
 dev-python/bar[pt_python2_7(-)]
 )
 pst_python3_7? (
 dev-python/foo[pt_python3_7(-)]
 dev-python/bar[pt_python3_7(-)]
 )


Your opinions
=
So, WDYT?  Do you think this approach is worthwhile?  Do you see other
options?




The new dependency API proposal looks nicer to me.

lu

[gentoo-dev] Re: EAPI 2 must die

[Luca Barbato]

On 06/06/2019 09:05, Matt Turner wrote:

On Wed, Jun 5, 2019 at 11:39 PM Agostino Sarubbo  wrote:


On giovedì 6 giugno 2019 08:25:54 CEST Luca Barbato wrote:

Anybody has hardware to test it?


I can do it on timberdoodle.


The issue is that the package is for "OldWorld" Macs (like 20+ years
old). We recently dropped the bootloader, sys-boot/quik, so I think
we'd be fine to drop sys-apps/powerpc-utils as well.



Exactly :)

I'm fine with treecleaning it.

lu

[gentoo-dev] Re: EAPI 2 must die

[Luca Barbato]

On 06/06/2019 07:06, Andreas K. Huettel wrote:

Hi all,

for the package maintainers among you, here's the list of remaining EAPI=2
packages. Please help getting the number down to zero soon!!!

Cheers,
Andreas

sys-apps/powerpc-utils-1.1.3.18-r2


This is ancient in many different ways :) Anybody has hardware to test it?

lu

[gentoo-dev] Re: How to handle ROC forks of llvm and clang

[Luca Barbato]

On 14/12/2018 21:00, Craig Andrews wrote:
Since ROC will eventually upstream all of it's work, (2) is ideal - but 
I have no idea what the timeline on that upstreaming effort may be, and 
I can't find anything that gives a hint.


I'd rather go with 1 and update the deps once llvm upstream gets the 
right support.


lu

Re: [gentoo-dev] [RFC] Global use flag: opus

[Luca Barbato]

On 13/10/2018 11:28, Michał Górny wrote:

> Two cases are unclear:
> 
>   media-video/libav: Use the external opus library for encoding and
> decoding.
>   virtual/ffmpeg: Use the external opus library for encoding and
> decoding.
> 
> 

They should be renamed libopus I'm afraid

[gentoo-dev] Re: The state of libav stabilisation

[Luca Barbato]

On 12/09/2018 12:38, Andreas Sturmlechner wrote:
> Is there anyone still working on libav support? It appears to me that 
> transition[1] and stabilisation[2] trackers are stuck for a long time without 
> activity. Missing libav-12 stabilisation means that in several stable 
> packages, USE=libav is already inaccessible without manual unmasking of the 
> use flag. I am not prepared to start reverting upstream commits for  support[3].
> 
> If this is not going to change, maybe media-video/libav should be dropped to 
> ~arch. This is still better than dropping support per-package or plastering 
> package.use.stable.mask with libav entries.
> 
> [1] https://bugs.gentoo.org/show_bug.cgi?id=libav-12
> [2] https://bugs.gentoo.org/617508
> [3] https://bugs.gentoo.org/665518
> 
> 
> 

I guess nobody had time to, libav-12 is working correctly on those arches.

Thanks for reminding us.

lu

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

[Luca Barbato]

On 31/07/2018 09:35, Dirkjan Ochtman wrote:
> On Mon, Jul 30, 2018 at 5:02 PM gibix  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.

> 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.

> 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 :)

> 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?

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?

Sorry, does not sound good.

lu

[gentoo-dev] Re: Suggestions for simplifying VIDEO_CARDS situation

[Luca Barbato]

On 17/06/2018 06:40, Matt Turner wrote:
> I would like to somehow get rid of the 'classic' and 'gallium' USE
> flags entirely, but I'm not totally sure how. Maybe I can enable them
> dependent on VIDEO_CARDS...

But shouldn't mesa have a software fallback for a good deal of those
features?

Probably some logic to issue a warning might help reduce the report
about confusing combinations w/out being too annoying?

lu

[gentoo-dev] Re: Current status with openssl-1.1

[Luca Barbato]

On 09/06/2018 10:22, Lars Wendler wrote:
> Hello dear Gentoo Devs,
> 
> this is somewhat written out of frustration so please bear with me ;)
> 
> CCing crypto@ in case they can provide some valuable input to the
> topic. If not, sorry guys for wasting your time.
> 
> As you might have noticed, although being published back in August
> 2016, we still have openssl-1.1 in package.mask due to the numerous
> build issues we still have with various packages[1] that uses openssl.
> 
> "Why is that so?" do I hear you asking. "Debian already switched over
> to openssl-1.1 for months already".
> 
> Well... the did not entirely switch yet. There are still packages that
> are being compiled/linked against openssl-1.0 in Debian because their
> respective upstreams refuse to collaborate.
> 
> The most prominent example is openssh[2] which also is the reason that
> this topic gives me so much frustration. They simply refuse to add
> compatibility code for openssl-1.1 because openssl upstream did such a
> silly move with making lots of interfaces opaque and make openssl-1.1
> mostly incompatible with code written against older openssl versions.
> 
> This and the fact that you can build openssl-1.1 with three different
> API versions (0.9.8, 1.0.0 and 1.1.0) makes it exceptionally hard for
> openssl consumers to migrate their code to openssl-1.1.
> 
> openssh upstream even raised the idea to simply focus crypto support in
> their software on libressl which I personally think is a really bad
> move. But coming from the same people (openssh and libressl are both
> developed by OpenBSD people), it's no big surprise this idea came up at
> some point.

Is libressl providing an API that is less silly and somehow compatible
with applications using the openssl-1.1 API ?

Do we have an openssh alternative that is interoperable AND usable?

Is it possible to have the never-libressl software use another
TLS/crypto provider?

lu

[gentoo-dev] Re: glibc-2.26 and changes with SunRPC, libtirpc, ntirpc, libnsl (NIS and friends), ...

[Luca Barbato]

On 18/09/2017 11:56, Andreas K. Huettel wrote:

So glibc-2.26 is already out for some time, but we still haven't keyworded it
yet. Why?

* I want to use the opportunity to make the long-delayed switchover from
glibc-internal SunRPC (long deprecated and outdated) to external
implementations (libtirpc, and possibly ntirpc).

* The (outdated and deprecated) NIS(YP) and NIS+ support (libnsl) has been
removed from glibc (except for a compatibility library that doesnt install
headers), and is now provided by net-libs/libnsl (increased soversion).

This mail is mainly about how to best structure the transition.
Comments, suggestions, corrections, feedback welcome.

1) About RPC.

AFACIS there are three implementations:
a) SunRPC, headers in /usr/include, code provided by glibc
b) net-libs/libtirpc, headers in /usr/include/libtirpc, library -l tirpc
c) (?) net-libs/ntirpc, headers in /usr/include/ntirpc, library -l ntirpc

Option a) is going away with sys-libs/glibc-2.26-r1.
Options b) and c) may in addition need headers from net-libs/rpcsvc-proto
I haven't done any testing with c) yet, will do so.
a), b), and c) are co-installable.

My suggestion for an ideal implementation would be that any package that uses
RPC defines useflags:
sunrpc - build against glibc

So this one is transient.


libtirpc - build against net-libs/libtirpc
ntirpc - build against net-libs/ntirpc
with
REQUIRED_USE="^^ ( sunrpc libtirpc ntirpc )"
If rpc support is optional with useflag rpc, then this becomes
REQUIRED_USE="rpc? ( ^^ ( sunrpc libtirpc ntirpc ) )"

Since the three options are coinstallable I see no problems with a package
only supporting a subset, but I have no clue how this interacts at runtime.


If they aren't ABI-compatible you would expect explosions once you link 
two libraries linked to the two different implementation (assuming they 
aren't macro-mangling everything).



Of course this "ideal option" is also the most work-intensive.

Both libtirpc and ntirpc supply a packageconfig file. Porting a package means
pointing it to the right include directory (at compile time) and library name
(at link time); if that's not done, a build fails because the rpc headers
cannot be found.
(In my @system chroot, python fails atm.)

2) About YP / NIS / NIS+.

a) The old libnsl implementation is provided by glibc, soversion 1.
b) An updated and much improved implementation is provided by net-libs/libnsl,
soversion 2.

glibc-2.26 installs only the library for a), and no headers.
Since I dont want to mess with currently used glibc ebuilds, net-libs/libnsl
requires at least our glibc-2.26 (otherwise you get file collisions).

Porting a package means adding a dependency in the style of
|| ( 

Beside making sure the providers are mix-and-matchable w/out pain sounds 
good.


We could check if the other libc could be switched to the external 
provider and play the lazy card and just always force an external 
implementation.


lu

[gentoo-dev] Re: [PATCH] toolchain.eclass: add DEPEND to dev-libs/boehm-gc, bug #617788

[Luca Barbato]

On 5/9/17 7:15 PM, Matthias Maier wrote:
> sys-devel/gcc-7.1.0 requires external dev-libs/boehm-gc, the internal
> copy got removed [1].
> 
> [1] https://gcc.gnu.org/viewcvs/gcc?view=revision=242985
> ---
>  eclass/toolchain.eclass | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
> index acdd401..db6e643 100644
> --- a/eclass/toolchain.eclass
> +++ b/eclass/toolchain.eclass
> @@ -178,6 +178,12 @@ fi
>  
>  tc_version_is_at_least 4.5 && RDEPEND+=" >=dev-libs/mpc-0.8.1:0"
>  
> +if in_iuse objc-gc ; then
> + if tc_version_is_at_least 7 ; then
> + RDEPEND+=" objc-gc? ( >=dev-libs/boehm-gc-7.4.2 )"
> + fi
> +fi
> +
>  if in_iuse graphite ; then
>   if tc_version_is_at_least 5.0 ; then
>   RDEPEND+=" graphite? ( >=dev-libs/isl-0.14 )"
> 

looks fine.

[gentoo-dev] Re: gcc-6.x status inquiry

[Luca Barbato]

On 5/3/17 6:43 PM, William Hubbs wrote:
> Hey all,
> 
> I am asking about this because I have been asked to look into
> packaging software that has a specific requirement for >=gcc-6 in order
> to build [1].
> 
> I see that gcc-6.3 doesn't have keywords, so I'm
> wondering when it will get them? Does anyone have any idea? I'm not
> talking about stable keywords, just ~. ;-)
> 
> Thanks much,
> 
> William
> 
> [1] https://www.cockroachlabs.com/docs/install-cockroachdb.html
> 

As I said few times, we should dump gcc-5 sooner than later and any
software that does not build with gcc-6 should be p.masked and dropped
from the tree if there isn't a nice fix for it.

So, I'm not seeing anything wrong in ~ gcc-6.

lu

[gentoo-dev] Re: LLVM-3.9 news item for review

[Luca Barbato]

On 01/10/16 10:10, Michał Górny wrote:
> explicitly selecting all targets.

The item seems fine.

Re: [gentoo-dev] nftables

[Luca Barbato]

On 09/09/16 02:31, Ian Bloss wrote:
> Anyone actively using nftables for their firewall over iptables?
> Considering giving it a go as the syntax looks much nicer than iptables.
> 

I'm using a bit and just works fine =)

lu

Re: [gentoo-dev] New project: LLVM

[Luca Barbato]

On 19/08/16 17:15, C Bergström wrote:
> On Fri, Aug 19, 2016 at 11:01 PM, Luca Barbato <lu_z...@gentoo.org> wrote:
>> BTW is pathscale ready to be used as system compiler as well?
> 
> I wish, but no. We have known issues when building grub2, glibc and
> the Linux kernel at the very least. Someone* did report a long time
> ago that with their unofficial port, were able to build/boot the
> NetBSD kernel.
> (*A community dev we trusted with our sources and was helping us with
> portability across platforms)
> 
> The stuff with grub2 may potentially be fixed in the "near" future...
> the others are more tricky. In general if clang can do it, we have a
> strong chance as well.

I see, it is getting quite close =)

> As a philosophy - "we" aren't really trying to be the best generic
> compiler in the world. We aim more on optimizing as much for known
> targets. So if by system you mean, a compiler that would produce an
> "OS" which only runs on a single class of hardware, then yeah it could
> work at some point in the future. Specifically, on x86 we default on
> host CPU optimizations. So on newer Intel hardware it's easy to get a
> binary that won't run on AMD or older 64bit Intel.
> 
> More recently on ARMv8 - we turn on processor specific tuning. So
> while it may "run", the difference between APM's mustang and Cavium
> ThunderX is pretty big and running binaries intended for A and ran on
> B would certainly take a hit.. (this is just the tip of the iceberg)

This is not a problem for Gentoo, actually sounds a good match for one
of our many use-cases =)

> For HPC codes or anything where you get loops or computationally
> complex - the gloves are off and I could see big differences... (again
> being general and maybe a bit dramatic for fun)

I started to do some decoding benchmark across compiler version some
time ago, I should try to put in the mix your compiler as well and
eventually blog about it =)

lu

Re: [gentoo-dev] New project: LLVM

[Luca Barbato]

On 19/08/16 19:13, C Bergström wrote:
> I finally got it to build and here's the size numbers
> 952K./lib/libc++abi.a
> 616K./lib/libc++abi.so.1.0
> 
> If the above isn't enough motivation and you really want benchmarks
> which prove it's a pig... I'll try to figure something else
> 
> Not exactly a 1:1 comparison because I think other things are mixed in, but...
> 352K/usr/lib/gcc/x86_64-linux-gnu/4.9/libsupc++.a
> 356K/usr/lib/gcc/x86_64-linux-gnu/5/libsupc++.a
> 
> In the land of HPC we frequently statically link stuff... not that
> 864KB is big by any sort of modern definition, but it does raise
> questions..
> 

We aren't in love with any specific implementation of it so it is nice
to have some comparison.

We could probably start a page in the wiki about it.

As said, the only part that makes uncomfortable about libcxxrt seems the
lack of versions and releases.

Surely we can cut another snapshot out of it and be happy about it.

lu

Re: [gentoo-dev] New project: LLVM

[Luca Barbato]

On 19/08/16 05:11, C Bergström wrote:
> I think you're getting a bit confused
> 
> libsupc++ is the default now, from GNU
> 
> libcxxabi is the bloated runtime from Apple
> 
> libcxxrt is the faster c++ runtime, PathScale+David Chisnall, which
> PathScale and FreeBSD use by default. We don't need a version number
> because it's pretty much rock solid stable for a while.

C++ is evolving so it will be needed in the future =) Please consider
adding some versions even if it is a bourden.

> I'd encourage you to consider libcxxrt for at least the code size and
> performance reasons. Build it and you'll see. Locally my unoptimized
> libcxxrt.so is like 88K. How much is your libcxxabi (static and
> shared)
> 
> 88K/opt/enzo-2016-06-26/lib/6.0.983/x8664/64/libcxxrt.so
> 140K/opt/enzo-2016-06-26/lib/6.0.983/x8664/64/libcxxrt.a
> // This seems larger than I remember and I need to check why.
> 
> https://github.com/pathscale/libcxxrt

BTW is pathscale ready to be used as system compiler as well?

lu

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

[Luca Barbato]

On 18/04/16 00:50, Anthony G. Basile wrote:

> Does base-system object if I bump it to EAPI=5 before I commit the
> ssl-cert patch?  I'll start stabilization too obviously.
> 

Please do.

Re: [gentoo-dev] usr merge

[Luca Barbato]

On 09/04/16 14:37, Rich Freeman wrote:
> I've certainly haven't had many problems with dracut.  When it fails
> it is usually because I'm doing something ELSE that is off-the-wall
> and it just doesn't have a plugin for it yet.  (And in those cases it
> isn't like the kernel tends to get it right without an initramfs.)
> 
> I'd certainly want to test it on a merged /usr, but I'd be surprised
> if it doesn't work, since it was designed to run on distros that are
> using a merged /usr.

I think that should be the first thing to do not the last one =)

> In an ideal world, you might argue that / should just be a tmpfs or
> something almost as ephemeral.  It is just a place you hang everything
> else off of.

That would be the core concept, but then you can just not have /bin
/sbin /lib .

> The thing I like about the merge is that it basically puts all your
> distro-supplied stuff in one place.  /usr basically becomes the OS
> minus state.  If things started out that way and you just had a short
> stub loader that gets things initialized, and I were arguing that
> instead of that little initialization stub you should break up /usr so
> that the root count mount /usr, would that sound all that compelling?
> I think having it all in one mountpoint seems a lot more compelling. 

you cannot ever have everything in 1 mount point, you just move the
problem somewhere else you notice less (initramfs), but the problem
remains and either is solved or not.

having everything in /usr and then copy it over ${somewhere} is there,
it can be debated if /bin or initramfs is the best place to put it.

lu

Re: [gentoo-dev] usr merge

[Luca Barbato]

On 08/04/16 14:55, Rich Freeman wrote:
> The purpose of a /usr merge is to get all the stateless stuff into one place.

beside what you have in /etc ...

usr-merge, in practice just moves early-boot/core tools where the rest
of the userspace lives.

> Some of the ultimate goals include:
> 1.  A read-only /usr

And mixing early-boot tools with post-boot userspace would help how?

> 2.  Having /usr signature-verified at boot

Because /etc is totally unimportant.

> 3.  Having everything that runs signature-checked before it is run

Because obviously you do not need to signature-check per executable.

> 4.  Having /usr shared across many containers/etc.

Because obviously it is the early-boot userspace spoiling this.

> 5.  Stateless systems - boot with a /usr and it creates the rest
> dynamically, and they're lost when the container is shut down.

Sounds backwards in many different ways.

> Put it this way, if you were designing a new OS from scratch today,
> would it make more sense to put all the distro-supplied
> binaries/libraries under a single path off the root, or off of many
> paths from the root?

You mean /usr/local ?

The whole thing ceases to be important once you have bind-mount and PATH
imho.

There is the specific need to have all the tools needed to boot in a
single place that can be accessed with ease.

It being /bin or initramfs or /boot/bin is completely cosmetic.

But you need a easy and reliable way to get it.

The idea of having / just holding the mount points and then have all the
other paths mounted by the early boot is fun only on paper I'm afraid.
(and we aren't even getting there since I bet /etc will stay in the root
partition for ages).

lu

Re: [gentoo-dev] usr merge

[Luca Barbato]

On 09/04/16 13:53, Rich Freeman wrote:
> On Sat, Apr 9, 2016 at 7:41 AM, Luca Barbato <lu_z...@gentoo.org> wrote:
>> On 05/04/16 03:19, William Hubbs wrote:
>>> Thoughts on any of this?
>>
>> The whole usr-merge moves the problem of putting stuff in / to putting
>> the very same stuff in the initrd when something different from busybox
>> (or equivalent) is needed to get the early boot mounting.
>>
>> Do we have a reliable way to address this now?
>>
> 
> Put the very same stuff in the initramfs?  Most initramfs creation
> scripts should already do this automatically, and with compat symlinks
> even those that don't probably will still end up doing it anyway..

The question is different: do they work reliably?

usr-merge does not solve any problem in itself (and it is totally
backwards, if somebody wants to simplify would do /usr -> /), but makes
more evident that you might need lots of the userspace to successfully
complete your early boot.

lu

Re: [gentoo-dev] usr merge

[Luca Barbato]

On 05/04/16 03:19, William Hubbs wrote:
> Thoughts on any of this?

The whole usr-merge moves the problem of putting stuff in / to putting
the very same stuff in the initrd when something different from busybox
(or equivalent) is needed to get the early boot mounting.

Do we have a reliable way to address this now?

If the answer is no, maybe we should focus on solving it first and then
think how to move stuff around.

lu

Re: [gentoo-dev] rfc: Does OpenRC really need mount-ro

[Luca Barbato]

On 16/02/16 19:05, William Hubbs wrote:
> All,
> 
> I have a bug that points out a significant issue with
> /etc/init.d/mount-ro in OpenRC.
> 
> Apparently, there are issues that cause it to not work properly for file
> systems which happen to be pre-mounted from an initramfs [1].

Who is using that file system? Ideally if "we" are the last user of the
file system it should be safe to mount ro it as well.

In general this happens when there is a "too smart to fit /" filesystem
in use.

In general that means that the same stuff used in /usr to mount it
should live in the initrd...

In general deprecating split-/usr moves the problem in in supporting fat
initrds to begin with. (I guess needing a boot filesystem that is fuse
based and needs rabbitmq or postgresql might be extra fun btw).

> This service only exists in the Linux world; there is no equivalent in
> OpenRC for any other operating systems we support.

Given it is a safety feature I do not know how the other kernels achieve
the same out of box.

> The reason it exists is very vague to me; I think it has something to do
> with claims of data loss in the past.

I think any fuse-supporting system should have it for more or less
obvious reasons (see the evil example above).

lu

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

[Luca Barbato]

On 09/02/16 04:09, Rich Freeman wrote:
> On Mon, Feb 8, 2016 at 7:58 PM, Anthony G. Basile  wrote:
>>
>> what does in-house tool mean?  i'm a gentoo developer but i also work
>> on an upstream project (eudev) that 14 distros use.
>>
>> some of the criticism given here are my concerns as well and i've
>> spoken with the various distros --- slack, parted magic, puppy.  they
>> get what's going on and they still see eudev is the best way forward
>> for now.  it may not be in the future, but neither will a udev
>> extracted from a compiled full systemd codebase.
> 
> How many of those 14 distros have more than 14 users?
> 

Alpine is quite used as docker image base nowadays... I'd say that alone
makes it _quite_ widely used.

lu

Re: [gentoo-dev] New virtual: virtual/jack for jack protocol implementations

[Luca Barbato]

On 04/02/16 15:05, Alexis Ballier wrote:
> Hi,
> 
> We've been supporting jack sound server [1] for a long time.
> Currently, we're supporting jack1 as
> media-sound/jack-audio-connection-kit. However, jack2 has been out for
> quite some time.
> 
> As its name does not imply, jack2 is not really the successor of jack1
> but rather another implementation of the same protocol [2]. As such, I
> don't think it is wise to add jack2 as an update to jack1 in
> media-sound/jack-audio-connection-kit but rather to add a new package
> (media-sound/jack2) along with a virtual that packages can depend onto.
> 
> Proposed ebuild for the virtual is here:
> https://github.com/suhr/gentoo/commit/1aebd8e72ff4ff2665761fc3b07f796945aa0943
> 
> Best regards,
> 
> Alexis.
> 
> 
> [1] http://www.jackaudio.org/
> [2]
> https://github.com/jackaudio/jackaudio.github.com/wiki/Q_difference_jack1_jack2
> 

Sounds a good idea.

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

[Luca Barbato]

On 11/11/15 10:09, Michał Górny wrote:
> I'd rather use the old standard 80. Minus 8 characters for friendly
> e-mail quoting, which is also kinda 'old standard'.

You can suggest as above, with this tone, and probably you would get
some consensus.

Personally I think 80col is nice since you can have three-way side by
side diff in most of the current screens.

You can deliver your point effectively w/out screaming and name calling.

lu

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

[Luca Barbato]

On 01/11/15 23:07, Michael Orlitzky wrote:
> On 11/01/2015 12:44 PM, Michael Palimaka wrote:
>> There's been a lot of discussion about relying on GitHub for pull
>> requests and code review and such, so I have set up a Phabricator
>> instance against gentoo.git to see how a free alternative might work.
>>
>> ...
>>
>> What do you think?
>>
> 
> Thanks for working on this. I personally didn't like Phabricator very
> much when I used it, but I'm glad someone is trying out code review
> platforms. I could live with it.

Most of the code-review platforms are cumbersome and inefficient
depending on the purpose.

Phab has some nice ideas (gamification is one of them), but overall I
feel interacting with it less pleasant than interacting with github and
gitlab (both have different defects).

Personally I wouldn't mind having a gitlab setup if there is consensus
in going in that direction.

If we want to try to do something more simple, patchwork or plaid (from
truly yours =p) might be options as well.

lu

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

[Luca Barbato]

On 24/09/15 14:23, Leno Hou wrote:
> On Fri, Sep 11, 2015 at 8:01 PM, Leno Hou  wrote:
> 
>>
>> 2. We believe to make Gentoo support ppc64le, we still need to compile
>> kernel and bootloader
>>
>>- Which version of kernel provided by Gentoo would you suggest us to
>>use?
>>
>>   As to Ubuntu, there will be many patches to make the kernel
>> workable, so how to patch
>>   our Gentoo kernel  to make it work for ppc64le?
>>
> 
> Upstream's 4.2.1 is OK  :-)
> I've compiled sys-kernel/gentoo-sources-4.2.1 on Ubuntu and
> successfully booted  Ubuntu as following.
> root@ppc64le:~# uname -a
> Linux ppc64le 4.2.1-gentoo #1 SMP Wed Sep 23 19:28:17 PDT 2015
> ppc64le ppc64le ppc64le GNU/Linux
> 
> 
>>- Which version of grub suitable for ppc64le ?  Is there any patches
>>to ppc64le grub ?
>>
>> 3. When the gentoo we make out workable on ppc64le, we would like to know
>> the process of
>> making it officially supported by Gentoo community
>>
>>- For each arch, do we have a subteam to verify the packages? If so,
>>how to reach these guys?
>>- For hardware environment, does anyone have Power8 systems ?
>>
>>  Again, please apply POWER8 Systems and join our work  :-)
>  [1]: https://www.runabove.com/instances/ibm-power8.xml
>  [2]: https://ptopenlab.com/cloudlabconsole/#/
>  [3]: http://osuosl.org/services/powerdev/request_hosting

We do not have an IBM contact (that I know) otherwise I'd love to get 3
powerdev minimal paravirt enviroments to test BE, LE and Power7.

Anybody with ties with IBM willing to help? =)

lu

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

[Luca Barbato]

On 12/08/15 11:46, Shuai Zhao wrote:
 2015-08-12 15:47 GMT+08:00 Mike Frysinger vap...@gentoo.org:
 
 On 12 Aug 2015 15:20, Leno Hou wrote:
 **Most importantly, Any Ideas/steps of how to  porting gentoo on  ppc64le
 architecture?**

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

 
 Yeah, we has several virtual machines of PPC64le.
 

Are they based on qemu or something completely different?

lu

Re: [gentoo-dev] RFC: pkg_needrebuild() API for smart-live-rebuild

[Luca Barbato]

On 07/08/15 19:01, Michał Górny wrote:
 Does this sound fine?

It does

 Any suggestions?

Having a reduced scope and not covering corner cases is fine now, so no =)

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

Re: [gentoo-dev] [RFC] Rebooting the Installer Project

[Luca Barbato]

On 18/07/15 21:01, Matthew Marchese wrote:
 I'd like to hear it all so please speak your mind. Looking forward to
 hearing from you.

The plan is good, having multiple backends is a boon since then you can
have large install images and tiny install images.

An installer is basically covering partitioning, networking, audio/video
configuration.

If you can start with the simplest use-case and increase complexity
gradually you will succeed.

It is an exercise of patience and I praise you for giving it a try.

[gentoo-dev] Re: Fonts project meeting and elections

[Luca Barbato]

On 27/02/15 08:45, Ben de Groot wrote:
 On 22 February 2015 at 03:43, Ben de Groot yng...@gentoo.org wrote:
 To anyone within Gentoo who is interested in fonts

 I would like to announce a meeting to be held in #gentoo-meetings on
 Freenode, on Friday February 27 at 06:00 UTC, unless another date
 and/or time will be suggested by people who want to attend.
 
 Since nobody actually showed up, here is what I've decided and am proposing:
 
 1. lu_zero, matsuu, pva: do you still want to be members of the Fonts
 project? Then add yourselves to the new project page:
 https://wiki.gentoo.org/wiki/Project:Fonts

I do not have enough time for it right now.

 2. Since aballier voted for me, and there were no other nominations,
 we default to me becoming the lead.

Fine for me.

 3. Handling of fonts with both truetype and opentype variants, as
 brought up in https://bugs.gentoo.org/406301#c8
 Since OpenType is an extension of TrueType, and superior for desktop
 and printing use, I propose that we prefer installing just OpenType.
 But this should be user configurable, so in those cases I propose we
 do:
 
 IUSE=+opentype
 if use opentype; then
 FONT_SUFFIX=otf
 else
 FONT_SUFFIX=ttf
 fi

If both are installed which is picked?

 5. Some fonts have webfont variants (WOFF is the important one here).
 This may be useful for users doing web development. What are your
 thoughts on installing those (conditionally, toggled by useflag)?

I'd make it an use expand

FONTS=otf ttf woff

If nothing is set install all, if some are set install those.

lu

Re: [gentoo-dev] arm64 update

[Luca Barbato]

On 19/02/15 01:05, Anthony G. Basile wrote:

I have about $1000 in grant money.  Want to recommend some equipment?


The dragonboard might be good BUT there are doubts on software availability.

lu

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

[Luca Barbato]

On 16/02/15 12:58, Mike Frysinger wrote:

On 16 Feb 2015 19:43, Patrick Lauer wrote:

On Monday 16 February 2015 06:13:10 Mike Frysinger wrote:

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


As others have pointed out, policy is policy. Don't shoot the massager.


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


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


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


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


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



Can we just have repoman directly fix the entry automatically since in 
itself is nearly-pointless?


Another option is remove that header and just state that all the .ebuild 
are under $license in a simpler way...



lu

Re: [gentoo-dev] Re: ffmpeg vs libav choice of default

[Luca Barbato]

On 14/02/15 19:41, Fabio Erculiani wrote:

If only libav and ffmpeg developers would stop breaking their API on
every release...
Just break it once and for all. It's so sad that I still can't upgrade
from libav-9 because of this.

Feature request: could you stop breaking the API for a couple of
years? Thanks. If you say that you have to, well, I won't believe you.



Libav 10 and Libav 11 had no api removal for that reason and probably 
Libav 12 will see only few items deprecated since 2 years removed.


lu

Re: [gentoo-dev] Re: ffmpeg vs libav choice of default

[Luca Barbato]

On 09/02/15 10:17, Alexis Ballier wrote:

(nb: you can see that this precise one is mostly fixed already.)



I hope it is completely fixed already =\

lu

Re: [gentoo-dev] Re: ffmpeg vs libav choice of default

[Luca Barbato]

On 08/02/15 17:13, Alexis Ballier wrote:

What we need instead of such endless debate  happy bashing (been
there, done that) is people doing the work. That's what will improve
the distribution. I thought letting libav be the default would improve
that;


If nobody helps fixing the orphaned and near orphaned applications we 
distribute nothing good happens and sadly in the past months I had been 
busy with more rl tasks.



unfortunately this is not the case today: libav ebuilds are good,
tree-wide integration is not. I find it a bit sad and sarcastic that
we're close to have ffmpeg-2.2 stable while libav-10 is not even
unmasked: One big feature of the two versions is the h265/hevc decoder,
and as I understood it, most of the work has been done on the libav
side...


libav-10 and libav-11 are the same api wise, sadly I had to wait for 
handbrake to provide a new release and I hadn't time to install and 
check all the near orphaned application that call direct the ffmpeg command.


I had no problems with using libav-11 since it was released but I kept 
it masked while patching stuff.


Sadly the time I can spend doing opensource stuff can be compressed from 
time to time and maybe is nicer develop interesting stuff such as useful 
API and features than write tons of s:CODEC_ID:AV_CODEC_ID: over 
countless packages.


lu

Re: [gentoo-dev] ffmpeg vs libav choice of default

[Luca Barbato]

On 04/02/15 11:40, Michał Górny wrote:

It's easiest to look at the trackers:

- ffmpeg-2 [1] -- 26/26 fixed,
- ffmpeg-2.4 [2] -- 3/3 fixed (but unsure if there won't be more),
- libav-9 [3] -- 55/55 fixed,
- libav-10 [4] -- 11/25 fixed.

No offense here but in my experience, ffmpeg support in Gentoo is fixed
faster than libav.


Given I have to fix the downstream issues first in Libav and then 
whenever FFmpeg decides to drop the stale API they get those for free 
I'm not surprised.


As per Libav, I managed to convince my fellow developers not to drop 
2-years old APIs for some more time, since there is enough orphaned 
software using it (thus why libav 10 and 11 had been kept API (source) 
compatible) and we (as Libav) spent a decent chunk of time to get 
updates for a good number of them.


Sadly the balance between the requirements of our active users, that 
demands better APIs and the latent users, that did not update since 
version 0.8 or so, was a bit too much toward the former.


I'd like not to have to discuss more than this since I'm strongly 
related to Libav and I have no time to get involved in a discussion with 
fans.


lu

Re: [gentoo-dev] ffmpeg vs libav choice of default

[Luca Barbato]

On 04/02/15 14:25, Jason A. Donenfeld wrote:

By now it should be clear to most people that everything goes smoother,
works better for the end user, and causes less breakage when *ffmpeg is the
default, not libav*.


Works better is a matter of perception, if I (and the few that help me 
not afraid of having rabid FFmpeg-fans bite them) fix the bulk of the 
issues early surely those that use FFmpeg get a smoother experience.


Again it is one project parasiting everything the other does.

Currently I'm trying to get Libav not to drop the old APIs as hard as I 
could so at least that part would be even.


Probably I should stop caring about the breakages myself and wait until 
they hit FFmpeg and let other do the work so I can spend my spare time 
in implementing more features instead.


lu

Re: [gentoo-dev] Review: USE=libav news item

[Luca Barbato]

On 27/01/15 01:19, Gordon Pettey wrote:

Chromaprint will work /differently/ depending on which is used. I added
libav support to it, but the fingerprints are not the same as fingerprints
generated when using ffmpeg. I've not gotten around to fixing that, so if
such a list is being compiled it should be noted on the don't arbitrarily
switch between ffmpeg and libav if this tool is important to you list.



chromaprint uses a coarse (and quick) resampler if I recall correctly 
and that would lead to differences if the resampler used is different, I 
never had the time to check if would be possible to set it to use a 
specific resampler that would work in the same way.


lu

Re: [gentoo-dev] arm64

[Luca Barbato]

On 25/01/15 03:57, Tom Gall wrote:

Hi All,

This is sort of a CFP in some ways but not quite that formal. I’ve

been throttled back on arm64 for a bit as the hardware I’ve had access
to has all been painfully remote and configured in ways that was less
than optimal for massive key wording efforts.


That’s about to change.

So if there are others out there who have the same interest be great

to coordinate efforts and get this moving along so we have arm64 stages
and start to pull together install instructions for the varies pieces of
hardware starting to show up.


Best, Tom





I have interest and hopefully I'll get some hardware (assuming the 
seller fixes his shopify instance...)


lu

Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )

[Luca Barbato]

On 20/01/15 03:07, Michael Orlitzky wrote:

On 01/19/2015 05:44 PM, Pacho Ramos wrote:


I agree with your suggestion but I would prefer the Remi's approach of
letting people to know if they want ffmpeg or libav, otherwise it is
not so obvious to know what disabling/enabling one of that USE flags
will end up causing without reading each ebuild :/ (also, maybe some
ebuilds will use one logic while others the inverse)



This triggered a repressed memory of a bug once filed against me:

https://blog.flameeyes.eu/2009/01/tinderboxing-problems-missing-default-use-flags

I vaguely agree, but please address any hate mail to Diego.




Why?

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

[Luca Barbato]

On 17/01/15 16:03, Ciaran McCreesh wrote:

On Sat, 17 Jan 2015 22:59:08 +0800
Patrick Lauer patr...@gentoo.org wrote:

The problem isn't the constants, though. The problem is the
resolution algorithm. There's not much point tweaking performance
until the resolver is fixed to produce a correct answer...


Patches welcome :)


If I send you a patch that updates all the documentation to use Paludis
rather than Portage, will you welcome it?



If you rewrite paludis in C99 or equally language with non-brittle 
runtime (libc++ isn't really viable yet =/) I would seriously consider it.


lu

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

[Luca Barbato]

On 19/01/15 16:47, hasufell wrote:

I think you forgot an important point:

* lack of practical QA: no review workflow and no appropriate tools for
reviewing

I could start a long text block about why reviewing is mandatory for QA,
but let's just think about it this way:
What do you think would happen if the linux kernel switched to CVS and
gave the most active 250 collaborators direct push access to the main
Linus repository?

I hope greg k-h does not read this. He'd probably get a heart attack.

Also: people seem to think we don't have enough manpower for a review
workflow. No, it's really the other way around. If you make
collaboration difficult, then you need a lot more manpower.



I already pointed out that there are _not_ good review tools. There are 
not for a by-email workflow we have in Libav, there aren't really for a 
tool-mediated workflow we could have in Gentoo.


I have no problems in devoting some time on preparing a tool suited for 
our purpose (once we switch to git), but I'd need more volunteers to 
help me with it.


lu

Re: [gentoo-dev] keywording gcc-4.9 branch

[Luca Barbato]

On 17/01/15 18:43, Anthony G. Basile wrote:

Hi everyone,

It looks like there aren't too many bugs against gcc-4.9 (bug #495124).
There are a couple having to do with lto and one which is hardened
specific, but its probably a good idea to start keywording on the
various arches so we can get more bug reports and not trail behind.  So
I opened bug #536874.

I've followed Ryan's workflow where he has one bug for gcc 4.9 porting
and another for keywording/stabilization.  I'm not sure why he did it
this way, but it may be less confusing in the future to have just one
which track the state of the ebuild from keyword masked, to keyworded to
stabilization.

@rhill, any advice here :)




Word of warning, asan was still terminally broken on nontrivial code 
last time I tested it.


lu

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

[Luca Barbato]

On 16/01/15 18:30, Jan Matejka wrote:
 On Fri, 07 Nov 2014 10:49:13 +0100
 Luca Barbato lu_z...@gentoo.org wrote:
 
 On 07/11/14 06:06, Harsh Bhatt wrote:
 
 Also make might enjoy improvements.
 
 shake?

Anything written in haskell tend to be impractical to deploy.

tup managed to get lots of great ideas spoiled by being impractically
extremist in tracking the directory changes.

lu

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

[Luca Barbato]

On 09/12/14 17:34, Michał Górny wrote:


I'm all for keeping it simple. However, backwards compatibility makes
it hard to keep things simple. I'd love to do, say, metadata.yml
supporting stuff like:

- maintainer: f...@gentoo.org, b...@gentoo.org

- maintainer:
   - name: Foo Bar
 email: f...@gentoo.org
   - b...@gentoo.org

(pseudo-code, not sure if it's 100% valid YAML)



Would be neat though.

Back to the discussion would be nice to have just proj...@gentoo.org 
instead of complex mappings.


lu

Re: [gentoo-dev] Make 'vaapi' USE flag global

[Luca Barbato]

On 28/11/14 13:20, Sergey Popov wrote:

Packages that uses 'vaapi' local USE-flag:

media-libs/avidemux-core
media-libs/xine-lib
media-tv/mythtv
media-tv/xbmc
media-video/avidemux
media-video/ffmpeg
media-video/hwdecode-demos
media-video/libav.
media-video/mpv
media-video/vlc
virtual/ffmpeg
www-plugins/gnash

Descriptions for that flag are pretty the same and we already have
'vdpau' USE flag, which is for someway similar technology.

So, how about making this flag global too?



I'm fine for it.

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

[Luca Barbato]

On 26/11/14 22:52, Rich Freeman wrote:

On Wed, Nov 26, 2014 at 4:21 PM, Tom Wijsman tom...@gentoo.org wrote:

On Sat, 22 Nov 2014 00:34:33 + (UTC)
Duncan 1i5t5.dun...@cox.net wrote:


While it pains me to say this, unfortunately it looks like we have
another toxic person situation to deal with, with all the
implications that come with it. Maybe it's time to deal with it.


Toxic wars have casualties; in one of the sides, or in both of them.

IOTW; you're already dealing with it, you can only change the outcome.



Can you be clear as to what you're recommending?

Are you suggesting that instead of trying to mediate between people
who don't get a long, it would be better to just pick one or the other
as the winner and boot the other out?


You are missing the point completely.


One of the challenges here is that if we were talking about just one
productive person who tended to drive everybody away that would be one
thing.  The problem is that we have a lot of productive people who
have different sorts of personality quirks.


This is not a matter of quirks. It is not a *quirk* making a mess of 
other people work and doing that repeatedly.


It is *not* getting along or not, it is having one side causing damage 
and not being accounted for that for reasons that are and will make us 
bleed contributors.


And what annoys me the most is that the issue would had been solved by 
_fixing_ the bugzilla setup but apparently nobody had the time or the 
will, me included, mostly since I do not dabble in perl.


lu

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

[Luca Barbato]

On 07/11/14 06:06, Harsh Bhatt wrote:


This idea seems bit interesting, about how the bug tracker works.
In this i just need to confirm that how much mathematical aspect
can be included. It's a good idea to work on.



Also make might enjoy improvements.

lu

Re: [gentoo-dev] Implicit system dependency

[Luca Barbato]

On 05/11/14 18:49, Mike Gilbert wrote:

On Wed, Nov 5, 2014 at 12:30 PM, Luca Barbato lu_z...@gentoo.org wrote:

On 05/11/14 02:16, Michael Orlitzky wrote:


When I was taking my ebuild quizzes, I asked for someone to clarify the
implicit system dependency that we have enshrined in the devmanual:

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

There is... some agreement, but also special cases and special-special
cases that are folklore-only at this point. To me it seems like a fine
thing to ask the council to sort out, so I'm asking here for discussion.

Can we come up with an idiot-proof list (or FLOWCHART, even!) of what
should and should not be excluded from *DEPEND?



Assume a C runtime and a C compiler do exist.



I would extend that to a C++ compiler and library as well.


We are having yet another C++-moment (libstdc++ as usual) so it might 
change, please beware.


lu

Re: [gentoo-dev] Implicit system dependency

[Luca Barbato]

On 05/11/14 02:16, Michael Orlitzky wrote:

When I was taking my ebuild quizzes, I asked for someone to clarify the
implicit system dependency that we have enshrined in the devmanual:

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

There is... some agreement, but also special cases and special-special
cases that are folklore-only at this point. To me it seems like a fine
thing to ask the council to sort out, so I'm asking here for discussion.

Can we come up with an idiot-proof list (or FLOWCHART, even!) of what
should and should not be excluded from *DEPEND?



Assume a C runtime and a C compiler do exist.

Re: [gentoo-dev] terminal spreadsheet - sc fork

[Luca Barbato]

On 03/11/14 20:24, Andrés Martinelli wrote:

Yes, Vim license was the base of it, as I noticed, at least by now, that it
meets the requirements I thought necessary. About that mistake, thanks for
noticing it. It will be corrected.



Just:

- change the name, it conflicts with another package.
- use AGPLv3 + as many exceptions as you like if you want something 
special, who doesn't agree with them has to stay with the vanilla agpl3 
with all its forced freedom.
- I'd advise to stay with LGPL though. (it is actually GPL3+exceptions 
as well)


I hope it helps.

lu

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

[Luca Barbato]

On 02/11/14 14:22, Pacho Ramos wrote:

El dom, 02-11-2014 a las 13:07 +, Diego Elio Pettenò escribió:



How do you strip the html code? I was unsure about to do that :/


You should have asked. There is no need to strip. I upload both HTML
and text alike.



Ah, ok. Anyway, if AxS can tell me how was doing that would be
interesting as who knows when could become useful to me in the future :)



in python you can (ab)use BeautifulSoup.

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

[Luca Barbato]

On 01/11/14 11:47, Diego Elio Pettenò wrote:

The problem with it's trivial to do that in python so just do it is
that first of all Python is not my language of choice, so the whole
infrastructure is currently not written in Python at all. And all the
people, including Luca, who promised they can convert it to Python in
no time, never delivered. Beside the point that, if it's so trivial
for somebody, I would expect it'll take them less time to provide me
with the tool, rather than complain about it.


Sorry I hadn't time to do that and everything fell low in the todolist 
since the tinderbox was put on hold.


That said, we have enough people with python skills could we just pick 
few days and come up with a good solution?


lu

Re: [gentoo-dev] status of bugs blocking gcc-4.8.3

[Luca Barbato]

On 30/10/14 15:06, Jan Kundrát wrote:

On Saturday, 25 October 2014 12:47:21 CEST, Luca Barbato wrote:

The ABI mismatch is due the library not being versioned properly as
usual?


Please note that this would be a hard thing to do. This is not just a
matter of calling an appropriate version of a given function; there are
no guarantees about the internal layout of the data structures, etc.
Furthermore, portions of C++ code might be inlined, so whenever you have
a library compiled with different GCC versions, these cannot exchange
any data which embed a C++11 data type inside. That's quite a bummer --
std::string and std::list have both changed in C++11 (forbidden
ref-counting of std::string and O(1) size of std::list::size()). The
upstream's promise is that the ABI will eventually ebcome stable when
they remove the experimental label on their C++11 support.

I suspect that the only solution would be a full ABI version number
change at that time, though, and people want to avoid doing this because
that will of course break all C++ programs out there. It would be
terrific if the GCC guys provided a reasonable roadmap, because saying
we support C++11 while also saying don't combine code built by 4.7
and 4.8, that's totally unsupported is a bit strange. Yes, limited time
and limited manpower and what not, but it's still something which makes
using all of the C++11 features a very risky business.


And obviously providing libstdc++ and libstdc++11 (and matching headers) 
is not an option =\


_quite_ annoying indeed

lu - hoping rust won't have such issues.

Re: [gentoo-dev] Clang toolchain [Was: status of bugs blocking gcc-4.8.3]

[Luca Barbato]

On 27/10/14 12:07, M. Ziebell wrote:

Does clang compile glibc already?
At the last GNU Cauldron the speaker said that clang fails because
of:[1]
- nested functions
- VLAIS

How did you avoid that problem?


musl is known to work fine.

Re: [gentoo-dev] status of bugs blocking gcc-4.8.3

[Luca Barbato]

On 24/10/14 19:12, Anthony G. Basile wrote:
 bug 513386 - net-libs/webkit-gtk-2.4.3 - ./.libs/libwebkitgtk-3.0.so:
 undefined reference to `_ZNSt6chrono12steady_clock3nowEv@GLIBCXX_3.4.17'
 - This is a problem.  It relates to abi mismatching with libstdc++.

The ABI mismatch is due the library not being versioned properly as usual?

 The bug details how you can hit it in gentoo. Martin von Gagern pushed
 the issue upstream and pretty much got the answer we're on our own  So
 we'll have to deal with this as we go forward.
 Seehttps://gcc.gnu.org/bugzilla/show_bug.cgi?id=61758

Not sure if the llvm C++ runtime might help here or it is any better
than the one provided by gnu, but might be a good time to gather
volunteers to provide a mean to use clang as main compiler out of box.

Being on your own is not an answer I like to hear. Nor the whole
approach to the discussion.

lu

Re: [gentoo-dev] status of bugs blocking gcc-4.8.3

[Luca Barbato]

On 25/10/14 13:09, Matthias Maier wrote:
 
 Not sure if the llvm C++ runtime might help here or it is any better
 than the one provided by gnu, but might be a good time to gather
 volunteers to provide a mean to use clang as main compiler out of box.
 
 libc++ makes stricter ABI guarantees [1]. But from personal experience I
 would not consider it a replacement for libstdc++ in the near future.

Probably we could join forces with FreeBSD to help pushing fixes to
applications upstream.

 I have set up some lxc containers with clang/libc++ with promising
 results (and I plan to keep up testing with it once in a while).

Could you please blog or add some notes to the wiki about it?

lu

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

[Luca Barbato]

On 20/10/14 00:53, Anthony G. Basile wrote:
 Hi everyone,
 
 I debated about whether to write a news item about c++11 abi. Usually
 our news items are about some change which requires user intervention. 
 But this is just precautionary.  With more packages needing c++11
 because of source changes, we may want to inform users about breakage at
 the ABI level in case they do something like add -std=c++11 to their
 global CXXFLAGS.
 
 Let me know if you think its worth sending out and/or any other
 suggestions.

Shorter form:

Since gcc-4.7 there is a -std=c++11 option, do not use it since it
breaks the ABI, resulting in a non-functional system.

lu

Re: [gentoo-dev] Add bc back to the stage3

[Luca Barbato]

On 27/09/14 15:19, Luca Barbato wrote:

On 27/09/14 14:22, Ciaran McCreesh wrote:

On Sat, 27 Sep 2014 12:47:14 +0200
Luca Barbato lu_z...@gentoo.org wrote:

Because I'd expect a stage3 to be posix compliant


I agree. It's time to replace nano with Vim.



Surely certain stuff might enjoy having ex available as well.

Probably busybox could be enough for both use-cases.


What about documenting this detail somewhere?

lu

Re: [gentoo-dev] Add bc back to the stage3

[Luca Barbato]

On 17/09/14 14:09, Jorge Manuel B. S. Vicetto wrote:

On Wed, 17 Sep 2014, Luca Barbato wrote:


The bc utility is part of the posix tools and it might be used to build
linux among the other stuff.


Luca,

bc is not in the system set and is a dependency of the kernel or any
other package that needs it, so why do we need to include a package that
takes ~20 seconds to build?


Because I'd expect a stage3 to be posix compliant and it is a pain to 
remember that Gentoo doesn't have it by default (since the errors can be 
quite vague).


lu

Re: [gentoo-dev] My masterplan for git migration (+ looking for infra to test it)

[Luca Barbato]

On 14/09/14 17:15, Kent Fredric wrote:
 On 15 September 2014 02:40, Michał Górny mgo...@gentoo.org wrote:
 
 However, I'm wondering if it would be possible to restrict people from
 accidentally committing straight into github (e.g. merging pull
 requests there instead of to our main server).

 
 
 Easy.
 
 Put the Gentoo repo in its own group.
 Don't give anyone any kinds of permissions on it.
 Have only one approved account for the purpose of pushing commits.
 Have a post-push hook that replicates to github as that approved account
 
 = Github is just a read only mirror, any pull reqs submitted there will be
 fielded and pushed to gentoo directly.
 
 Only downside there is the way github pull reqs work is if the final SHA1's
 that hit tree don't match, the pull req doesn't close.
 
 Solutions:
 
 - A) Have somebody tasked with reaping old pull reqs with permissions
 granted. ( Uck )
 - B) Always use a merge of some kind to mark the pull req as dead ( for
 instance, an ours merge to mark the branch as deprecated )

C) Ask nicely Github to have an application key and have a pull-request
bridge to avoid the problem completely.

I'd complete the migration first and discuss this kind of details later.

lu

Re: [gentoo-dev] My masterplan for git migration (+ looking for infra to test it)

[Luca Barbato]

On 14/09/14 16:46, Michał Górny wrote:
 Of course, if we can't spare the resources to do intermediate updates,
 we may as well switch to cron-based update method.

The mirror have a sync time, so basically regenerating the cache and
pushing the tree with further toward the user can happen the same way
w/out impacting anybody.

We could just snapshot the tree when the regen starts and push that
commit to the user git and rsync.

People is still supposed to play nice and sync not every minute.

lu

Re: [gentoo-dev] My masterplan for git migration (+ looking for infra to test it)

[Luca Barbato]

On 14/09/14 17:30, Patrick Lauer wrote:
 Are we going to disallow merge commits and ask devs to rebase local
 changes in order to keep the history clean?
 
 Is that going to be sane with our commit frequency?
 

Which is our commit frequency? Worst case we can aggregate changes and
push them in bulk.

lu

Re: [gentoo-dev] My masterplan for git migration (+ looking for infra to test it)

[Luca Barbato]

On 15/09/14 01:21, Patrick Lauer wrote:
 On Sunday 14 September 2014 15:42:15 hasufell wrote:
 Patrick Lauer:
 Are we going to disallow merge commits and ask devs to rebase local
 changes in order to keep the history clean?

 Is that going to be sane with our commit frequency?

 You have to merge or rebase anyway in case of a push conflict, so the
 only difference is the method and the effect on the history.

 Currently... CVS allows you to run repoman on an outdated tree and push
 broken ebuilds with repoman being happy. Git will not allow this.
 
 iow, git doesn't allow people to work on more than one item at a time?

It does.

 That'd mean I need half a dozen checkouts just to emulate cvs, which somehow 
 doesn't make much sense to me ...

Your statement sounds strange to me.

commands you need to know:

git rebase -i

git add (-p)

git commit (-p)

git branch/checkout

Examples

edit cat/pkg/foo.ebuild

edit cat2/pkg/bar.ebuild

edit profile

git add -p# to select by line what you want in the commit

git commit# and you write down the commit message

git commit -p # to do both at the same time.

git commit -p # again to lump other changes line by line

OR

edit cat/pkg/foo.ebuild

git commit -a # everything (that's tracked) you edited gets in a commit

edit cat/pkg/bar.ebuild

git commit -a # everything (that's tracked) you edited gets in again

...

git rebase -i # sort out what you want commit merge, edit, drop etc

git push.




Git let you do whatever you do in cvs, but in a _much_ saner and faster way.

[gentoo-dev] Add bc back to the stage3

[Luca Barbato]

The bc utility is part of the posix tools and it might be used to build
linux among the other stuff.

lu

Re: [gentoo-dev] python versioned libraries or not

[Luca Barbato]

On 08/12/13 00:44, hero...@gentoo.org wrote:
 yac y...@gentoo.org writes:
 
 Shouldn't pkg-conifg --libs handle this?
 
 Oh, good idea. But boost doesn't have pkg-config entries.
 
 Then I see this one, an upstream issue
 
  https://svn.boost.org/trac/boost/ticket/1094
 

Are you willing to poke upstream again? I'm not sure which problem they
have with pkg-config that a little more awareness wouldn't solve.

lu

Re: [gentoo-dev] Gentoo Upgrade Guide and EAPI

[Luca Barbato]

On 29/09/13 04:12, hero...@gentoo.org wrote:
 It's just a starting point, though. I still don't have a clear plan yet.
 
 After reading carefully the thread Ulrich pointed out, it seems that
 refactoring ebuild/eclass is invevitable, which calls for an overlay to
 carry it on.

That would be much welcome, having new people in toolchain and trying to
get new useful stuff done while we aren't breaking our users (hint, some
people are already sad for the /usr thing) seems a good idea.

lu - still too busy with stuff...

Re: [gentoo-dev] Changes in libreoffice ebuild

[Luca Barbato]

On 13/08/13 10:10, Tomáš Chvátal wrote:

 [3] https://wiki.documentfoundation.org/Development/gerrit

And all boils down to the fact gerrit needs to be fixed to take patches
from a mailing list or provide some sane alias to cope with it's
specific ways...

lu

Re: [gentoo-dev] Re: GCC 4.8 unmasking

[Luca Barbato]

On 14/08/13 01:40, Ryan Hill wrote:
 On Tue, 13 Aug 2013 07:13:13 +0200
 Luca Barbato lu_z...@gentoo.org wrote:
 
 On 13/08/13 03:41, Ryan Hill wrote:
 I don't see any reason to keep this masked other than bug #416069, which
 needs to be fixed anyways.  How does Friday sound?

 https://bugs.gentoo.org/416069  xorg-2.eclass: add
 --disable-selective-werror to configure https://bugs.gentoo.org/461954  GCC
 4.8 porting

 gcc-4.8 can miscompile libc

 http://gcc.gnu.org/bugzilla//show_bug.cgi?id=56888

 We should make sure we do not get bitten by this.
 
 We don't build glibc with -O3.  Other libc's should either not use -O3 or
 use -fno-tree-loop-distribute-patterns where applicable.
 

On certain arches the memcpy tranformation happens even on lower
optimization levels or so I saw reported.


lu

Re: [gentoo-dev] Changes in libreoffice ebuild

[Luca Barbato]

On 14/08/13 17:56, Peter Stuge wrote:
 Luca Barbato wrote:
 [3] https://wiki.documentfoundation.org/Development/gerrit

 And all boils down to the fact gerrit needs to be fixed to take
 patches from a mailing list
 
 Usually Gerrit just needs an OpenID in order to accept git push via SSH.
 
 That seems significantly better to me than parsing emails.

# git-way:

git commit ...

git send-email -10 --compose --to patc...@project.org

# gerrit-way:

Register with gerrit

Install the magic gerrit commit hooks

OR

Figure out how you should push your try


## Then we have feedbacks and we want to provide updates

# git-way:

Read the email comments

git rebase -i

git send-email -8 --compose --in-reply-to --to patc...@project.org

# gerrit-way

Follow the links to the website with the comments.

Read the documentation again since you will forget how to push stuff in
gerrit, hope the commit hook you have manages the rebase and push again.


---

Gerrit probably can be nice if you are used to it, you always have a
browser open and you do not have a wast mean to move from your mail
client to your git (people with emacs would explain better, I use vim
and thunderbird and yet I'm quicker in addressing projects using the git
email approach than those that use gerrit.

lu

Re: [gentoo-dev] GCC 4.8 unmasking

[Luca Barbato]

On 13/08/13 03:41, Ryan Hill wrote:
 I don't see any reason to keep this masked other than bug #416069, which
 needs to be fixed anyways.  How does Friday sound?
 
 https://bugs.gentoo.org/416069  xorg-2.eclass: add --disable-selective-werror 
 to configure
 https://bugs.gentoo.org/461954  GCC 4.8 porting

gcc-4.8 can miscompile libc

http://gcc.gnu.org/bugzilla//show_bug.cgi?id=56888

We should make sure we do not get bitten by this.

lu

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[Luca Barbato]

On 01/08/13 04:48, William Hubbs wrote:
 I would rather not carry distro-specific patches forever to support
 something like this, so please forward your patches upstream.

The code is in a public git, it is even not written by me, anybody can
forward it to upstream...

lu

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[Luca Barbato]

On 01/08/13 17:04, William Hubbs wrote:
 There is a hack in our udev and kmod ebuilds that makes it possible to
 build the static libraries, but I think we should remove that hack since
 upstream bans building them.

linking statically makes the problem apparent, I guess isn't that wise
hiding it under a rug and hoping it won't ever bite you.

Anyway I volunteered Federico to sort out this mess and he got that part
more or less done.

My github has his changes and I started to track what picked my attention.

lu

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[Luca Barbato]

On 01/08/13 17:36, Michał Górny wrote:
 So esystemd and ekmod now?

You know my stance on systemd, for me it is a jumble of bad and
interesting ideas not so soundly implemented, I do not have much time or
will to play with that thing.

kmod on the other hand had a pressing issue and getting it fixed-ish
took about an evening while having Federico see around it.

lu

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[Luca Barbato]

On 01/08/13 19:46, Pacho Ramos wrote:
 El jue, 01-08-2013 a las 18:11 +0200, Luca Barbato escribió:
 On 01/08/13 17:36, Michał Górny wrote:
 So esystemd and ekmod now?

 You know my stance on systemd, for me it is a jumble of bad and
 interesting ideas not so soundly implemented, I do not have much time or
 will to play with that thing.

 kmod on the other hand had a pressing issue and getting it fixed-ish
 took about an evening while having Federico see around it.

 lu

 
 But, what are the advantages of putting a lot of effort in keeping
 static libs for udev?

A lot of effort means not using random-clashing-names, not keeping
functions around just because.

 Looks like nothing really need them, and even
 Debian (that doesn't use systemd by default) drops them

Robbat said he wants to keep the stuff working, thus I lent him an hand
while introducing a friend to a small codebase with a good number of
practices I consider faulty but sort of easy to fix.

lu

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[Luca Barbato]

On 01/08/13 19:54, Samuli Suominen wrote:
 still, first the patch goes upstream and after upstream review and 
 commit to git it goes in tree otherwise we opt to the fallback and
 disable udev from lvm2/cryptsetup when USE=static is enabled (like
 cryptsetup upstream suggested to me) gentoo-specific patches mangling
 namespace of udev, kmod, whatever doesn't sound good at all however
 working it with upstream sounds great

I just spent an evening introducing a friend willing to have a look the
codebase. My solution to the problem of clashing symbols had been 3 fold:

- many functions are small and already inline, they are using in the
tool (bad practice IMHO) and in the library once. Making them static is
easy and works.

- some functions are using inside the library a couple of times, adding
an (ugly) privkm_ is enough to avoid the problem.

- some functions were used just in the tool and not in the library,
moved where it belongs.

Instead of running around in circles screaming static linking is unholy
fixing it that way wouldn't had take much...

I won't expect upstream picking up what Federico wrote anytime out of
pride more than technical merit.

lu

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[Luca Barbato]

On 01/08/13 23:53, Michał Górny wrote:
 That would be a lot of effort if upstream doesn't accept it and we end
 up patching it all the way...

kmod isn't complex and probably could be made even a bit more compact,
considering also the pace of its development and the kind of changes in
the last month I doubt would be so incredible.

b6adccd6ff819b8befc48ede41a13f2201dce443 is quite enlightening on which
are their best practises anyway.

lu

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[Luca Barbato]

On 01/08/13 04:03, William Hubbs wrote:
 On Wed, Jul 31, 2013 at 07:42:26PM +, Robin H. Johnson wrote:
 As both a member of base-system, and the lvm2 maintainer, I'm going to
 go and look at fixing them, because I'd prefer to keep them available as
 static builds.
 
 Robin,
 
 I'm curious what the use case for keeping them as static builds is? I
 would rather see that support dropped as well.
 
 Udev and kmod upstream do not support static builds so I want
 to drop that support from our ebuilds.

I started fixing that in kmod and got something else more pressing to
do, today I'll spend the whole day trying to get that in shape.

Help welcome obviously.

As said before using correct C namespacing isn't rocket science.

(obviously when you start seeing unchecked mallocs and reallocs in
library code you might shiver a bit... but that can be fixed later as well)

lu

Re: [gentoo-dev] new category: games-adventure/

[Luca Barbato]

On 07/14/2013 07:47 PM, Diego Elio Pettenò wrote:
 On 14/07/2013 18:42, Peter Stuge wrote:
 I bet you a tasty beverage that it will grow over time! :)
 
 I don't believe in the future until I can see it. I'm pretty sure that's
 the same thing that they said about app-antivirus at some point (can
 somebody _kill_ that category please?!)

Or maybe populate it by adding few more. I guess there isn't much
interest or clamav is really that good.

lu

Re: [gentoo-dev] News item preceding net-print/cups-1.6 stabilization

[Luca Barbato]

On 06/29/2013 12:03 AM, Andreas K. Huettel wrote:
 script to your default runlevel). By default cups-browsed uses the

basically the functionality got split in a stand alone daemon?

Re: [gentoo-dev] Re: eselect init

[Luca Barbato]

On 06/22/2013 12:07 PM, Pacho Ramos wrote:
 After talking with WilliamH yesterday, I have this opinion:
 - Playing with /sbin/init (instead of /sbin/einit) has two interesting
 advantages:
 1. For example, I now have init=/sbin/e4rat-preload in my grub.conf, if
 I do a typo, it would fallback to /sbin/init. If /sbin/init is provided
 by sysvinit, people running other init providers could have problems.
 This wouldn't occur if /sbin/init has been changed to use desired init
 system.
 2. Tools like e4rat or bootchart launch /sbin/init, if I switch to
 systemd, I would need to edit separate configuration files for each tool
 to point to new init. This wouldn't occur if we play with /sbin/init
 = we would only change init in one place
 
 - I have two doubts:
 1. Why do we need a wrapper instead of changing symlinks?

So once I'm not busy playing with pixels and hw accels I would implement
addons support in the wrapper (so bootchart and e4rat would just ran by
the init wrapper)

 2. Why Fabio chose to move sysvinit to subdirectories... wouldn't be
 much simpler to simply rename /sbin/init to /sbin/sysvinit?

I prefer /bin/init but any place would fit (and should be configurable
anyway)

lu

Re: [gentoo-dev] eselect init

[Luca Barbato]

On 06/21/2013 01:26 PM, Pacho Ramos wrote:
 Thanks for the explanation. But I think that, currently, the only
 remaining objection is whether play with /sbin/init (that needs
 sysvinit to be changed if I don't misremember) or with /sbin/einit.
 Looks like mgorny has shown some problems on relying on einit instead
 of plain init regarding to fallback :/

I prefer having /sbin/init used for the pivot since /sbin/einit is a bit
more brittle and as Fabio did the whole machinery is _still_ opt-in.

lu

Re: [gentoo-dev] eselect init

[Luca Barbato]

On 06/21/2013 05:23 PM, Fabio Erculiani wrote:
 Fix the reason why the wrapper got broken then.
 If the wrapper broke, it is most likely a symptom of a bigger problem.
 
 I think that sysvinit's /sbin/init should be renamed to /sbin/sysvinit
 (or /bin/sysvinit?), anyway...
 

/bin/init

lu

Re: [gentoo-dev] eselect init

[Luca Barbato]

On 06/21/2013 06:50 PM, William Hubbs wrote:
 On Fri, Jun 21, 2013 at 05:13:33PM +0100, Markos Chandras wrote:
 On 21 June 2013 16:29, Michał Górny mgo...@gentoo.org wrote:
 Dnia 2013-06-21, o godz. 10:16:10
 William Hubbs willi...@gentoo.org napisał(a):

 On Fri, Jun 21, 2013 at 12:23:28PM +0200, Michał Górny wrote:
 If eselect-init installs the wrapper as /sbin/einit, we don't have to
 touch /sbin/init at all, then, the only thing someone would have to do
 is to add an entry to their boot loader with init=/sbin/einit on the kcl
 to use it.

 But *if* the wrapper fails to run somehow, e.g. becomes broken,
 the kernel will fallback to the standard location.

 Yes, but if the wrapper replaces /sbin/init, like it does now, and the
 wrapper gets broken, I think you are left with an unbootable system.

 Then kernel falls back to safe /bin/sh which is a minimal safe fallback.

 --
 Best regards,
 Michał Górny

 Correct. Even if your init end up being broken you end up with a shell
 so you can fix things yourself.
 
 The case we are ignoring here is the indirection in the wrapper. e.g.
 the wrapper, /sbin/init is a valid process, but the process it tries to
 run, say /bin/foobar, is not.
 
 I'm thinking that no matter where we put the wrapper, either as a custom
 version of /sbin/init or as something like /bin/einit, once the kernel
 hands things off to the wrapper, if the wrapper fails to run the
 executable it is directed to run, we are hosed.
 

I asked to mgorny to try that already, and he did and reported already,
you can try for yourself and see what happens.

lu - no, I won't tell what happens so you will try for yourself