Re: [gentoo-dev] Re: [RFC] Splitting dev-lang/python into per-slot packages, starting with 3.14
On 12/10/24 15:03, Michał Górny wrote: emerge =python-3.14 would install both a non-freethreading and a freethreading version and it would satisfy 3_14 and 3_14t at the same. But that's not how PMs work? It would install only the "newer" version, which would probably mean freethreading, which is not what people usually want. I mean that the python-3.14 ebuild would install both versions for the time being. the PM does not see anything special. lu
Re: [gentoo-dev] Re: [RFC] Splitting dev-lang/python into per-slot packages, starting with 3.14
On 12/10/24 11:13, Michał Górny wrote:
On Sat, 2024-10-12 at 10:50 +0200, Luca Barbato wrote:
On 12/10/24 10:12, Michał Górny wrote:
Comments?
I'm afraid it would lead to way too many packages and I'm not sure the
overall experience would be an improvement.
5 are too many?
potentially it is python_{version}_{variants} so at least 10*2 assuming
we keep around 3.{N..N+5} and we have two worthy variants.
Plus the chore of treecleaning older packages. Not sure if it is worth it.
With your proposed solution, if an user wants to have any version of
python what should ask to emerge?
Can you actually imagine having a Gentoo system with no Python
preinstalled, with an user actually needing to emerge one?
right now if I need a specific version of python I have to do emerge
=python-N* and usually it works as intended.
people would have to get used to do emerge python_{that specific N}
In fact, even today "emerge dev-lang/python" is probably a bad solution,
as it will lead to a beta/rc version on an ~arch system most
of the time.
An alternative for freethreading support wouldn't be to install both
from the same package python-3.14 and have the two PYTHON_TARGETS ?
I don't understand.
emerge =python-3.14 would install both a non-freethreading and a
freethreading version and it would satisfy 3_14 and 3_14t at the same.
lu
[gentoo-dev] Re: [RFC] Splitting dev-lang/python into per-slot packages, starting with 3.14
On 12/10/24 10:12, Michał Górny wrote: Comments? I'm afraid it would lead to way too many packages and I'm not sure the overall experience would be an improvement. With your proposed solution, if an user wants to have any version of python what should ask to emerge? An alternative for freethreading support wouldn't be to install both from the same package python-3.14 and have the two PYTHON_TARGETS ? lu
[gentoo-dev] Re: New project: Vulkan
On 17/09/24 16:55, Matt Turner wrote: I suggest making a new Vulkan project within Gentoo and moving these packages from x11@ maintainership to it: dev-cpp/robin-hood-hashing dev-util/glslang dev-util/spirv-headers dev-util/spirv-tools dev-util/volk dev-util/vulkan-headers dev-util/vulkan-tools dev-util/vulkan-utility-libraries media-libs/shaderc media-libs/vulkan-layers media-libs/vulkan-loader (I've repeatedly forgotten to clean up shaderc and glslang when I clean up the others because they are the only two that are not maintained by x11@) Would it make sense to also give the group its own category? lu
[gentoo-dev] Re: [PATCH v2] profiles: promote USE=vulkan to global USE flag
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
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
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
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
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
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()
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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), ...
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
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&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
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
On 01/10/16 10:10, Michał Górny wrote: > explicitly selecting all targets. The item seems fine.
Re: [gentoo-dev] nftables
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
On 19/08/16 17:15, C Bergström wrote: > On Fri, Aug 19, 2016 at 11:01 PM, Luca Barbato 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
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
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/
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
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
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
On 09/04/16 13:53, Rich Freeman wrote: > On Sat, Apr 9, 2016 at 7:41 AM, Luca Barbato 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
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] Re: Bug #565566: Why is it still not fixed?
On 24/02/16 01:33, Duncan wrote: > That option is there, and indeed, a patch providing it was specifically > added to portage for infra to use, because appending entries to existing > files is vastly easier and more performant than trying to prepend entries > and having to rewrite the entire file as a result. This sounds wrong in many different ways. The changelog files are tiny and makes next to no difference truncate+write or append. lu
Re: [gentoo-dev] rfc: Does OpenRC really need mount-ro
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
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
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/
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
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
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
On 12/08/15 11:46, Shuai Zhao wrote: > 2015-08-12 15:47 GMT+08:00 Mike Frysinger : > >> 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
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
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
On 27/02/15 08:45, Ben de Groot wrote: > On 22 February 2015 at 03:43, Ben de Groot 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
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
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
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
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
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
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] ffmpeg vs libav choice of default
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] Review: USE=libav news item
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
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] keywording gcc-4.9 branch
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] Things one could be upset about
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] Things one could be upset about
On 17/01/15 16:03, Ciaran McCreesh wrote: On Sat, 17 Jan 2015 22:59:08 +0800 Patrick Lauer 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] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )
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] Regarding my final year thesis
On 16/01/15 18:30, Jan Matejka wrote: > On Fri, 07 Nov 2014 10:49:13 +0100 > Luca Barbato 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 un-ization, v2
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
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
On 26/11/14 22:52, Rich Freeman wrote: On Wed, Nov 26, 2014 at 4:21 PM, Tom Wijsman 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
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
On 05/11/14 18:49, Mike Gilbert wrote: On Wed, Nov 5, 2014 at 12:30 PM, Luca Barbato 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
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
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
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
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
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]
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
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] status of bugs blocking gcc-4.8.3
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] RFC: News item regarding c++98 vs c++11
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
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 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
On 27/09/14 14:22, Ciaran McCreesh wrote: On Sat, 27 Sep 2014 12:47:14 +0200 Luca Barbato 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. lu
Re: [gentoo-dev] Add bc back to the stage3
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
[gentoo-dev] Add bc back to the stage3
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] My masterplan for git migration (+ looking for infra to test it)
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.
Re: [gentoo-dev] My masterplan for git migration (+ looking for infra to test it)
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)
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)
On 14/09/14 17:15, Kent Fredric wrote: > On 15 September 2014 02:40, Michał Górny 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] python versioned libraries or not
On 08/12/13 00:44, hero...@gentoo.org wrote: > yac 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
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
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] Re: GCC 4.8 unmasking
On 14/08/13 01:40, Ryan Hill wrote: > On Tue, 13 Aug 2013 07:13:13 +0200 > Luca Barbato 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
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] GCC 4.8 unmasking
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
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
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
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
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
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
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
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
