[gentoo-dev] Last rites: media-video/unifi-video
# Ben Kohler (2024-04-07) # Abandoned upstream long ago in favor of Unifi Protect (running only on an # official Unifi appliance. Likely contains lots of security holes in bundled # libs. # Removal on 2024-05-07. Bug #928881 acct-group/unifi-video acct-user/unifi-video media-video/unifi-video
[gentoo-dev] Last rites: sys-apps/memtest86
# Ben Kohler (2024-04-07) # Long ago forked to and obsoleted by sys-apps/memtest86+. Upstream has # abandoned this for their proprietary UEFI-based one (packaged in gentoo as # as sys-apps/memtest86-bin). # Removal on 2024-05-07. Bug #502464, #607494, #628528, #750677, #887003, # #912973, #920109 sys-apps/memtest86
[gentoo-dev] Re: Packages up for grabs: media-gfx/rawtherapee media-libs/libiptcdata
On 2/24/23 04:58, Marek Szuba wrote: In light of the current (proxied) maintainer having stated they no longer have a Linux desktop and therefore expect difficulties in continuing to maintain their packages, media-gfx/rawtherapee I will take this one unless anyone else is really passionate about it. It's related to one of my other packages (fotoxx) and I've done the last bump and a few minor fixes on it already. -Ben
Re: [gentoo-dev] https://packages.gentoo.org/ - lag
On 9/10/21 5:42 AM, Jaco Kroon wrote: So just wondering how frequently packages.gentoo.org updates? https://bugs.gentoo.org/811801 -Ben
Re: [gentoo-dev] [PATCH] profiles/default/linux: Add USE="bzip2 lzma zstd" to defaults
On 7/12/21 12:25 PM, Michael Orlitzky wrote: We've kept things the same level of difficulty for one group of people, but made them much harder for another. In no situation can anyone who wants everything enabled have a harder time than 'adds USE="bzip2 lzma zstd" to make.conf', but everyone else suffers to some degree. That's discouraging choice overall. Point taken. If IUSE="-flag" were actually common in reality, I'd use it as evidence that MY way is better, but alas.. =) -Ben
Re: [gentoo-dev] [PATCH] profiles/default/linux: Add USE="bzip2 lzma zstd" to defaults
On 7/12/21 10:30 AM, Peter Stuge wrote: Matt Turner wrote: If you can find a case where you wouldn't want to enable one of these USE flags, please let me know and I'll reconsider my position. My catalyst spec files all have use: -* foo bar x y z specifically because the defaults are never what I want for any given system. I build desktops, servers, containers, VM appliance images and embedded system, and I know what I want in each one. Especially the latter frequently have only very few USE flags set and I want zero extra dependencies. I think you're making a great argument that you'd be completely unaffected by any of the suggestions in this thread. I don't consider needing "use: -*" at all a desirable situation. This catalyst warning might support that: Warning!!! The use of -* in $stage/use will cause portage to ignore package.use in the profile and portage_confdir. You've been warned! I see it as a shortcoming of the standard profiles that I have to essentially create my own in order to get what I want, as opposed to being able to build upon something truly minimal. I'd claim most of these packages' bzip2/lzma/zstd USE flags should be removed in favor of statically enabling them That is the direct opposite of Gentoo's single most core value: choice Choice makes sense when there's a legitimate trade-off to be made. I explained that and why I frequently do not want those USE flags set, demonstrating that I want choice here. You can of course dismiss any concern which disagrees with your opinion as illegitimate. Please do not bother asking questions if that's your style. Choice isn't dogma. Is there a difference between dogma and value? I understand choice to be a core value in Gentoo. Maybe that's wrong (now)? Core values are more important than pretty much anything else. Choice isn't always possible. That's not this case. If choice is indeed a core value then where choice is pretty easy (this case) in my mind there needs to be an overwhelmingly strong argument to conciously and intentionally disable choice. Just don't do it. Kthx. This kind of thing is nothing but irritating. Please don't do this. I'm sorry if it wasn't clear that "Just don't do it. Kthx." meant exactly what you wrote: This kind of thing (increase default USE-flags) is nothing but irritating. Please don't do this. Kind regards //Peter Hi Peter, Nobody is "disabling choice" here, a change in defaults doesn't remove your ability to choose something else. And I understand your sentiment that adding more default-on flags goes against YOUR goals of a minimal gentoo, but I'd like to remind you and others that this minimalism is not the goal of every gentoo user. More default features might irritate you and other minimalists, but it may significantly improve the gentoo experiences of everyone else. I want to be clear that I'm not saying you are wrong, but remember that your perspective is not the only correct one on this topic. -Ben
Re: [gentoo-dev] [PATCH] profiles/default/linux: Add USE="bzip2 lzma zstd" to defaults
On 7/8/21 6:54 AM, Michael Orlitzky wrote: On Wed, 2021-07-07 at 22:01 -0700, Matt Turner wrote: Enable these flags by default, since they effectively add no additional dependencies: Why? This list should be getting smaller, not larger. That's a valid opinion/viewpoint, but it's not a fact. Someone may have wanted these features to be optional, but that doesn't automatically imply that they should be disabled for everyone out of the box. Not everyone wants minimalism, some people want the expected features to just be enabled by default. -Ben
[gentoo-dev] [PATCH] udev.eclass: minor @USAGE fixes
Signed-off-by: Ben Kohler
---
eclass/udev.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/udev.eclass b/eclass/udev.eclass
index baf60584938..2873ae9a92c 100644
--- a/eclass/udev.eclass
+++ b/eclass/udev.eclass
@@ -80,7 +80,7 @@ get_udevdir() {
}
# @FUNCTION: udev_dorules
-# @USAGE: rules [...]
+# @USAGE: [...]
# @DESCRIPTION:
# Install udev rule(s). Uses doins, thus it is fatal in EAPI 4
# and non-fatal in earlier EAPIs.
@@ -95,7 +95,7 @@ udev_dorules() {
}
# @FUNCTION: udev_newrules
-# @USAGE: oldname newname
+# @USAGE:
# @DESCRIPTION:
# Install udev rule with a new name. Uses newins, thus it is fatal
# in EAPI 4 and non-fatal in earlier EAPIs.
--
2.23.0
[gentoo-dev] [PATCH] texlive-common.eclass: fix several @USAGE problems
Signed-off-by: Ben Kohler
---
eclass/texlive-common.eclass | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/eclass/texlive-common.eclass b/eclass/texlive-common.eclass
index e9a2eee65bd..b36be7a4db3 100644
--- a/eclass/texlive-common.eclass
+++ b/eclass/texlive-common.eclass
@@ -61,7 +61,7 @@ texlive-common_is_file_present_in_texmf() {
}
# @FUNCTION: texlive-common_do_symlinks
-# @USAGE: < src > < dest >
+# @USAGE:
# @DESCRIPTION:
# Mimic the install_link function of texlinks
#
@@ -99,7 +99,7 @@ texlive-common_do_symlinks() {
}
# @FUNCTION: etexlinks
-# @USAGE: < file >
+# @USAGE:
# @DESCRIPTION:
# Mimic texlinks on a fmtutil format file
#
@@ -117,7 +117,7 @@ etexlinks() {
}
# @FUNCTION: dobin_texmf_scripts
-# @USAGE: < file1 file2 ... >
+# @USAGE: [file2] ...
# @DESCRIPTION:
# Symlinks a script from the texmf tree to /usr/bin. Requires permissions to be
# correctly set for the file that it will point to.
@@ -133,10 +133,10 @@ dobin_texmf_scripts() {
}
# @FUNCTION: etexmf-update
-# @USAGE: In ebuilds' pkg_postinst and pkg_postrm phases
# @DESCRIPTION:
# Runs texmf-update if it is available and prints a warning otherwise. This
-# function helps in factorizing some code.
+# function helps in factorizing some code. Useful in ebuilds' pkg_postinst and
+# pkg_postrm phases.
etexmf-update() {
if has_version 'app-text/texlive-core' ; then
@@ -151,10 +151,10 @@ etexmf-update() {
}
# @FUNCTION: efmtutil-sys
-# @USAGE: In ebuilds' pkg_postinst to force a rebuild of TeX formats.
# @DESCRIPTION:
# Runs fmtutil-sys if it is available and prints a warning otherwise. This
-# function helps in factorizing some code.
+# function helps in factorizing some code. Used in ebuilds' pkg_postinst to
+# force a rebuild of TeX formats.
efmtutil-sys() {
if has_version 'app-text/texlive-core' ; then
--
2.23.0
[gentoo-dev] [PATCH] s6.eclass: minor @USAGE fixes
Signed-off-by: Ben Kohler
---
eclass/s6.eclass | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/eclass/s6.eclass b/eclass/s6.eclass
index 32521515497..245df1e1118 100644
--- a/eclass/s6.eclass
+++ b/eclass/s6.eclass
@@ -48,7 +48,7 @@ s6_get_servicedir() {
}
# @FUNCTION: s6_install_service
-# @USAGE: servicename run finish
+# @USAGE: [finish]
# @DESCRIPTION:
# Install an s6 service.
# servicename is the name of the service.
@@ -75,7 +75,7 @@ s6_install_service() {
}
# @FUNCTION: s6_service_down
-# @USAGE: servicename
+# @USAGE:
# @DESCRIPTION:
# Install the "down" flag so this service will not be started by
# default.
@@ -97,7 +97,7 @@ s6_service_down() {
}
# @FUNCTION: s6_service_nosetsid
-# @USAGE: servicename
+# @USAGE:
# @DESCRIPTION:
# Install the "nosetsid" flag so this service will not be made a session
# leader.
--
2.23.0
[gentoo-dev] [PATCH] ruby-fakegem.eclass: function name typo fix & minor @USAGE fixes
Signed-off-by: Ben Kohler
---
eclass/ruby-fakegem.eclass | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/eclass/ruby-fakegem.eclass b/eclass/ruby-fakegem.eclass
index a6a7654f9e6..f75e1669b0c 100644
--- a/eclass/ruby-fakegem.eclass
+++ b/eclass/ruby-fakegem.eclass
@@ -207,7 +207,7 @@ ruby_fakegem_gemsdir() {
}
# @FUNCTION: ruby_fakegem_doins
-# @USAGE: file [file...]
+# @USAGE: [file...]
# @DESCRIPTION:
# Installs the specified file(s) into the gems directory.
ruby_fakegem_doins() {
@@ -217,8 +217,8 @@ ruby_fakegem_doins() {
) || die "failed $0 $@"
}
-# @FUNCTION: ruby_fakegem_newsins
-# @USAGE: file filename
+# @FUNCTION: ruby_fakegem_newins
+# @USAGE:
# @DESCRIPTION:
# Installs the specified file into the gems directory using the provided
filename.
ruby_fakegem_newins() {
@@ -262,7 +262,7 @@ ruby_fakegem_install_gemspec() {
}
# @FUNCTION: ruby_fakegem_gemspec_gemspec
-# @USAGE: gemspec-input gemspec-output
+# @USAGE:
# @DESCRIPTION:
# Generates an installable version of the specification indicated by
# RUBY_FAKEGEM_GEMSPEC. This file is eval'ed to produce a final specification
@@ -272,7 +272,7 @@ ruby_fakegem_gemspec_gemspec() {
}
# @FUNCTION: ruby_fakegem_metadata_gemspec
-# @USAGE: gemspec-metadata gemspec-output
+# @USAGE:
# @DESCRIPTION:
# Generates an installable version of the specification indicated by
# the metadata distributed by the gem itself. This is similar to how
@@ -282,7 +282,7 @@ ruby_fakegem_metadata_gemspec() {
}
# @FUNCTION: ruby_fakegem_genspec
-# @USAGE: output-gemspec
+# @USAGE:
# @DESCRIPTION:
# Generates a gemspec for the package and places it into the "specifications"
# directory of RubyGems.
@@ -327,7 +327,7 @@ EOF
}
# @FUNCTION: ruby_fakegem_binwrapper
-# @USAGE: command [path] [content]
+# @USAGE: [path] [content]
# @DESCRIPTION:
# Creates a new binary wrapper for a command installed by the RubyGem.
# path defaults to /usr/bin/$command content is optional and can be used
--
2.23.0
[gentoo-dev] [PATCH] qmail.eclass: minor @USAGE fix
Signed-off-by: Ben Kohler
---
eclass/qmail.eclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/eclass/qmail.eclass b/eclass/qmail.eclass
index 150b6c00aab..8dd3ae99043 100644
--- a/eclass/qmail.eclass
+++ b/eclass/qmail.eclass
@@ -69,7 +69,7 @@ dospp() {
}
# @FUNCTION: dosupervise
-# @USAGE: dosupervise [ ]
+# @USAGE: [ ]
# @DESCRIPTION:
# Install runfiles for services and logging to supervise directory
dosupervise() {
--
2.23.0
[gentoo-dev] [PATCH] prefix.eclass: minor @USAGE fix
Signed-off-by: Ben Kohler
---
eclass/prefix.eclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/eclass/prefix.eclass b/eclass/prefix.eclass
index 8ae3e3a531d..435e99fdf92 100644
--- a/eclass/prefix.eclass
+++ b/eclass/prefix.eclass
@@ -111,7 +111,7 @@ hprefixify() {
}
# @FUNCTION: prefixify_ro
-# @USAGE: prefixify_ro .
+# @USAGE:
# @DESCRIPTION:
# prefixify a read-only file.
# copies the files to ${T}, prefixies it, echos the new file.
--
2.23.0
[gentoo-dev] [PATCH] perl-app.eclass: remove unneeded @USAGE lines
Signed-off-by: Ben Kohler
---
eclass/perl-app.eclass | 3 ---
1 file changed, 3 deletions(-)
diff --git a/eclass/perl-app.eclass b/eclass/perl-app.eclass
index 6b762dd83b3..074902294e5 100644
--- a/eclass/perl-app.eclass
+++ b/eclass/perl-app.eclass
@@ -21,7 +21,6 @@ case "${EAPI:-0}" in
esac
# @FUNCTION: perl-app_src_prep
-# @USAGE: perl-app_src_prep
# @DESCRIPTION:
# This is a wrapper function to perl-app_src_configure().
perl-app_src_prep() {
@@ -29,7 +28,6 @@ perl-app_src_prep() {
}
# @FUNCTION: perl-app_src_configure
-# @USAGE: perl-app_src_configure
# @DESCRIPTION:
# This is a wrapper function to perl-module_src_configure().
perl-app_src_configure() {
@@ -37,7 +35,6 @@ perl-app_src_configure() {
}
# @FUNCTION: perl-app_src_compile
-# @USAGE: perl-app_src_compile
# @DESCRIPTION:
# This is a wrapper function to perl-module_src_compile().
perl-app_src_compile() {
--
2.23.0
[gentoo-dev] [PATCH] bash-completion-r1.eclass: minor @USAGE syntax fixes
Signed-off-by: Ben Kohler
---
eclass/bash-completion-r1.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/bash-completion-r1.eclass b/eclass/bash-completion-r1.eclass
index 7a69f485a74..636371df9d6 100644
--- a/eclass/bash-completion-r1.eclass
+++ b/eclass/bash-completion-r1.eclass
@@ -91,7 +91,7 @@ get_bashhelpersdir() {
}
# @FUNCTION: dobashcomp
-# @USAGE: file [...]
+# @USAGE: [...]
# @DESCRIPTION:
# Install bash-completion files passed as args. Has EAPI-dependant failure
# behavior (like doins).
@@ -106,7 +106,7 @@ dobashcomp() {
}
# @FUNCTION: newbashcomp
-# @USAGE: file newname
+# @USAGE:
# @DESCRIPTION:
# Install bash-completion file under a new name. Has EAPI-dependant failure
# behavior (like newins).
--
2.23.0
[gentoo-dev] [PATCH] common-lisp-3.eclass: fix various @USAGE inconsistencies
Some of these functions are missing @USAGE even though they do require
arguments. There's also a redundant function name in a few places.
Signed-off-by: Ben Kohler
---
eclass/common-lisp-3.eclass | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/eclass/common-lisp-3.eclass b/eclass/common-lisp-3.eclass
index ae229491025..65ad5a58a34 100644
--- a/eclass/common-lisp-3.eclass
+++ b/eclass/common-lisp-3.eclass
@@ -75,6 +75,7 @@ common-lisp-install-one-source() {
}
# @FUNCTION: lisp-file-p
+# @USAGE:
# @DESCRIPTION:
# Returns true if ${1} is lisp source file.
lisp-file-p() {
@@ -84,6 +85,7 @@ lisp-file-p() {
}
# @FUNCTION: common-lisp-get-fpredicate
+# @USAGE:
# @DESCRIPTION:
# Outputs the corresponding predicate to check files of type ${1}.
common-lisp-get-fpredicate() {
@@ -98,7 +100,7 @@ common-lisp-get-fpredicate() {
}
# @FUNCTION: common-lisp-install-sources
-# @USAGE: common-lisp-install-sources path [...]
+# @USAGE: [...]
# @DESCRIPTION:
# Recursively install lisp sources of type ${2} if ${1} is -t or
# Lisp by default. When given a directory, it will be recursively
@@ -126,6 +128,7 @@ common-lisp-install-sources() {
}
# @FUNCTION: common-lisp-install-one-asdf
+# @USAGE:
# @DESCRIPTION:
# Installs ${1} asdf file in CLSOURCEROOT/CLPACKAGE and symlinks it in
# CLSYSTEMROOT.
@@ -140,7 +143,7 @@ common-lisp-install-one-asdf() {
}
# @FUNCTION: common-lisp-install-asdf
-# @USAGE: common-lisp-install-asdf path [...]
+# @USAGE: [...]
# @DESCRIPTION:
# Installs all ASDF files and creates symlinks in CLSYSTEMROOT.
# When given a directory, it will be recursively scanned for ASDF
@@ -167,7 +170,6 @@ common-lisp-3_src_install() {
}
# @FUNCTION: common-lisp-find-lisp-impl
-# @USAGE: common-lisp-find-lisp-impl
# @DESCRIPTION:
# Outputs an installed Common Lisp implementation. Transverses
# CLIMPLEMENTATIONS to find it.
@@ -179,7 +181,7 @@ common-lisp-find-lisp-impl() {
}
# @FUNCTION: common-lisp-export-impl-args
-# @USAGE: common-lisp-export-impl-args
+# @USAGE:
# @DESCRIPTION:
# Export a few variables containing the switches necessary
# to make the CL implementation perform basic functions:
--
2.23.0
[gentoo-dev] [PATCH] tmpfiles.eclass: fix @USAGE to not include function name
Signed-off-by: Ben Kohler
---
eclass/tmpfiles.eclass | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/eclass/tmpfiles.eclass b/eclass/tmpfiles.eclass
index 68478ffbcd6..360c5e3b816 100644
--- a/eclass/tmpfiles.eclass
+++ b/eclass/tmpfiles.eclass
@@ -63,7 +63,7 @@ esac
RDEPEND="virtual/tmpfiles"
# @FUNCTION: dotmpfiles
-# @USAGE: dotmpfiles ...
+# @USAGE: ...
# @DESCRIPTION:
# Install one or more tmpfiles.d files into /usr/lib/tmpfiles.d.
dotmpfiles() {
@@ -84,7 +84,7 @@ dotmpfiles() {
}
# @FUNCTION: newtmpfiles
-# @USAGE: newtmpfiles .conf
+# @USAGE: .conf
# @DESCRIPTION:
# Install a tmpfiles.d file in /usr/lib/tmpfiles.d under a new name.
newtmpfiles() {
@@ -102,7 +102,7 @@ newtmpfiles() {
}
# @FUNCTION: tmpfiles_process
-# @USAGE: tmpfiles_process ...
+# @USAGE: ...
# @DESCRIPTION:
# Call a tmpfiles.d implementation to create new volatile and temporary
# files and directories.
--
2.23.0
[gentoo-dev] Gentoo i486 support
Hi guys,
For some time now, we've been shipping broken i486 stage3s that do not
run on pre-i686 hardware [1]. Due to a change in catalyst [2], we no
longer set CXXFLAGS in the default make.conf, so the x86 profiles' (imho
wrong/broken) defaults [3] kick in.
I'd like to get this fixed, and I see 3 possible solutions, listed in
order of my own preference:
1) Adjust x86 profile defaults to drop the problematic -march=i686.
This would be more in line with amd64 profiles (et al), which set no
-march value so it can run on any hardware for this arch.
2) Patch catalyst to start setting CXXFLAGS again. Rather than roll
back to exactly CXXFLAGS="${CFLAGS}" again, it's been suggested that we
start setting COMMON_FLAGS, and CFLAGS="${COMMON_FLAGS}"
CXXFLAGS=${COMMON_FLAGS}" etc. I prepared such a patch a while back
[4], which seems to work but may need a bit of updating.
3) Drop i486 support. We're only pretending to have support now, we
could officially stop building these broken stages completely.
Personally I think #1 is the most technically correct and least amount
of work. The only result will be slightly less optimized builds for
people who choose not to customize *FLAGS at all in make.conf. But this
is correct behavior. What we have now is akin to setting -march=core2
on amd64 stage3 and saying "oops it doesn't work on early 64bit AMD
cpus, but oh well most people have newer and will appreciate the
optimization".
Thoughts?
-Ben
[1] https://bugs.gentoo.org/654080
[2]
https://gitweb.gentoo.org/proj/catalyst.git/commit/?id=b409bd9bb4b50f69a555e4e148057ade86a7ed16
[3]
https://gitweb.gentoo.org/repo/gentoo.git/tree/profiles/arch/x86/make.defaults
[4] https://bugs.gentoo.org/575446#c4
Re: [gentoo-dev] Adding USE=udev to linux profiles
On 07/26/2018 02:59 AM, Andrew Savchenko wrote: Hi! On Thu, 19 Jul 2018 16:51:17 -0500 Ben Kohler wrote: I'd like to propose adding USE=udev to our linux profiles (in profiles/default/linux/make.defaults probably). This flag is already enabled on desktop profiles but it also affects quite a few packages used on non-desktop linux systems. This flag provides useful functionality that most linux users will want. I'm a bit surprised that we still don't have it in all linux profiles, but I think we've worked around this in the past by adding IUSE=+udev to quite a few of those packages (33 packages, 116 ebuilds, by my count). This missing flag came to my attention again on bug 661584 where lvm2 has IUSE=+udev but cryptsetup has only IUSE=udev, so non-desktop users have a bit of a mismatch between the 2 and get ugly errors on cryptsetup. Since this flag only affects linux, I think it makes more sense to set it in linux profiles than to use IUSE defaults. Any objections to this idea? A user had contacted me with his input from the HPC world, I'm redirecting his e-mail here. James is whitelisted now so he can further participate in this discussion himself if necessary. As an HPC user of Gentoo I agree that minimal and highly optimized Gentoo setups are indeed very useful and must stay that way. Begin forwarded message: Date: Wed, 25 Jul 2018 13:31:59 -0400 From: james To: birc...@gentoo.org Subject: udev's future Hello Andrew, Sorry, I do not have direct posting ability to gentoo-dev, so in hopes of finding a dev-sponsor, I hope you will paraphrase this email to you for the sake of preventing 'dev as a default' or base setting of any sort. My research and testing for new HPC configurations, has systemd and udev at the heart of codes to avoid to optimize the heterogeneous nature of the clusters I'm building. In fact my development work, although delayed due to transient-illness, is more of a gentoo-centric convergence of embedded-gentoo, minimal (server) gentoo, gentoo-hpc clusters and unikernels. As far as performance and security are concerned 'less' is always better. Those codes and ebuild that are desired are to added in a higher level; hoping to continue the leverage the portage tree of applications, only as dynamically required. Avoidance of setting udev or in any form mandating any part of systemd will have dire consequences and cost me months, if not years to find a way to 'totally undo' the ravages of udev. Minimized kernels are also fundamental to my loosely-coupled (gentoo) HPC development. Even tiny Rtos based embedded linux systems are in the process of being included in a loosely-coupled gentoo centric heterogeneous HPC cluster. I would 'beg' against making udev primary under any circumstance. Gentoo has a unique and powerful position, just for it's position of choice and minimizational features; After 15 years, I'd hate to have to work in another distro, as gentoo has served me extraordinarily well over the decades. sincerely, James Horton, PE Best regards, Andrew Savchenko No one was ever talking about forcing udev usage, just default-enabling support on a few MORE packages than we already do. Our standard linux stage3's are already udev-enabled. But not udev-forced, anywhere. Nothing about my proposal was going to force udev on people who don't want udev at all-- let's not even go down that rabbit hole of discussion. I was only pushing for more consistency-- either your system would be fully udev-enabled, or not at all. -Ben
Re: [gentoo-dev] Adding USE=udev to linux profiles
On 07/25/2018 02:28 AM, Andrew Savchenko wrote: Adding udev to the base profile will make customization much harder for people unwilling to use udev. This is the problem. To stay on the original track, I was suggesting adding it to the linux profile component, not base. And people who are unwilling to use udev would disable it globally, like people who are unwilling to use pam or ipv6. But I understand where you're coming from in general-- that we've already achieved a good minimal balance in enabling udev only where it's really needed, and enabling it in linux make.defaults will make it difficult to get back to that state. So I will just continue to ask for IUSE=+udev where I believe it's very important for sane functionality of a particular package. In other words, I'm no longer pushing for the make.defaults change. -Ben
Re: [gentoo-dev] Adding USE=udev to linux profiles
On 07/19/18 23:04, Michael Orlitzky wrote: > > No I'm not. I'm saying add them per-package, because it's a better > design. We have package.use in profiles now, not just IUSE defaults. > > Global defaults have problems: > > * They can't be undone. It's next to impossible for me to undo > USE=udev when set in a profile that is inherited by all others. > > * USE=udev means different things for different packages. You think it > "makes udev work" or whatever, but nobody has any idea what it does > for half of the packages that use it. The meaning is package- > specific, so the default should be package-specific. > > * They're easy to set, but hard do unset when you realize you were > wrong a year from now. > > If you really want to enable it globally after being told that it's bad > engineering and downright annoying, go do it in a profile that I can > avoid and not "linux". > I believe you're arguing against profile global USE in general, can you start a new thread for that if you believe it's worth discussing? We do have global USE in profiles now and I believe that the sane default for linux profiles is to have udev support globally. -Ben pEpkey.asc Description: application/pgp-keys
Re: [gentoo-dev] Adding USE=udev to linux profiles
On 07/19/18 22:40, Benda Xu wrote: > > To represent the Gentoo Prefix users, we would like to have USE=udev > turned off or even hard masked on linux-prefix profiles. > > Yours, > Benda > I believe this is an argument in favor of moving the default to profiles then, out of IUSE defaults, right? -Ben pEpkey.asc Description: application/pgp-keys
Re: [gentoo-dev] Adding USE=udev to linux profiles
On 07/19/18 20:54, Mikle Kolyada wrote: > +1. widely used profiles should have as least flags enabled by default > as possible, I would not be happy with +udev on my servers. > I disagree with this premise. The default and most widely used profiles should fit the most common use cases. I'd be curious as to what problems would be caused on your servers if this flag were turned on-- specifically what packages will get the flag turned on, where that bothers you? On my servers, the impact is very minimal. I'm not totally sure that my proposal of USE=udev is correct/justified, but there are a few counter-arguments I've heard that I don't think hold water, I'd like to focus on the others. -Ben pEpkey.asc Description: application/pgp-keys
Re: [gentoo-dev] Adding USE=udev to linux profiles
On 07/19/2018 05:00 PM, Michael Orlitzky wrote: Please add defaults per-package, only where they make sense. Enabling flags globally creates a huge headache for people that want them off. If I want to undo your new flag, I have to set USE="-udev" globally, and that clobbers any important per-package defaults that maintainers have set. I was well aware of that when I prepared this proposal, and it's true of every USE flag in any profile's make.defaults. I still believe it's the correct course of action. Thanks, Ben
[gentoo-dev] Adding USE=udev to linux profiles
Hello, I'd like to propose adding USE=udev to our linux profiles (in profiles/default/linux/make.defaults probably). This flag is already enabled on desktop profiles but it also affects quite a few packages used on non-desktop linux systems. This flag provides useful functionality that most linux users will want. I'm a bit surprised that we still don't have it in all linux profiles, but I think we've worked around this in the past by adding IUSE=+udev to quite a few of those packages (33 packages, 116 ebuilds, by my count). This missing flag came to my attention again on bug 661584 where lvm2 has IUSE=+udev but cryptsetup has only IUSE=udev, so non-desktop users have a bit of a mismatch between the 2 and get ugly errors on cryptsetup. Since this flag only affects linux, I think it makes more sense to set it in linux profiles than to use IUSE defaults. Any objections to this idea? Thanks, Ben
Re: [gentoo-dev] Re: RFC: News: systemd sysv-utils blocker resolution
On Tue, Dec 26, 2017 at 6:11 PM, Rich Freeman <ri...@gentoo.org> wrote: > Does this still cause a warning? I thought that openrc/sysvinit were > now pulled in via a virtual these days (alongside systemd), and were > not directly in @system. Or do we still have functions.sh issues? > > -- > Rich > Still throws warning due to unresolved bug https://bugs.gentoo.org/375115 -Ben
Re: [gentoo-dev] newsitem: openrc-0.28 mounts efivars read only
On Thu, Jul 13, 2017 at 9:29 AM, Mike Gilbert <flop...@gentoo.org> wrote: > > We are actually talking about protecting people who run something like > rm -rf /sys/firmware/efi/efivars/ as root. > > If you are dumb enough to do something like that, you almost deserve > to spend a couple hundred on a new motherboard. > > While I can think of a few ways you can accidentally do this via bindmounts and such, I think it's also worth mentioning that this "bricking" only happens on a very very small number of systems with a specific buggy UEFI implementation, the vast majority of UEFI hardware will not be "bricked" by wiping efivars. I'm still onboard with protecting users from this out of the box, but it's not like without this change, we'll have gentoo boxes dropping dead all over the place every week. We're protecting from something that requires both a very specific firmware bug AND serious user error, to trigger. -Ben
Re: [gentoo-dev] Sets vs Meta ebuilds
On Mon, Jul 10, 2017 at 4:42 PM, William L. Thomson Jr. <wlt...@o-sinc.com> wrote: > > If people understood, then saying use -c or -C makes no sense. It does > not address the lack of output from either I am talking about. > > -- > William L. Thomson Jr. > I really thought I understood you in that you wanted true reverse dependencies calculated, to check against that, and warn for it. I think that you are actually talking about a warning upon forced unmerge of anything not in /var/lib/portage/world, is that correct? -Ben
Re: [gentoo-dev] Sets vs Meta ebuilds
On Mon, Jul 10, 2017 at 3:27 PM, William L. Thomson Jr. <wlt...@o-sinc.com> wrote: > > > Not sure why anyone would have objection to such a warning like exists > for other things. Or providing more information to the user as to why a > package was not removed, or should not be removed. > > -- > William L. Thomson Jr. > If you want dependencies checked, use the correct option which checks them. This takes significantly longer than -C, as it's significantly more complex to check for. As far as I can tell, you are literally asking for -C to behave like -c, when you could just be using -c instead. -Ben
Re: [gentoo-dev] Sets vs Meta ebuilds
> > > - The -c option should say why it will not remove. > > > -- > William L. Thomson Jr. > It does, if you use the --verbose flag. This is mentioned in your emerge output a few times. -Ben
Re: [gentoo-dev] Sets vs Meta ebuilds
On Mon, Jul 10, 2017 at 2:36 PM, William L. Thomson Jr. <wlt...@o-sinc.com> wrote: > ... > Calculating dependencies... done! > >>> No packages selected for removal by depclean > >>> To see reverse dependencies, use --verbose > Packages installed: 1779 > Packages in world:194 > ... > # emerge -pC gcc > * This action can remove important packages! In order to be safer, use > * `emerge -pv --depclean ` to check for reverse dependencies > before > * removing packages. > > ... > > You aren't taking the time to read your own emerge output. Now, both of these recommend --pretend, but you can use --ask with it, for a safe unmerge that checks for reverse deps THEN allows you to continue only if it's safe. Try "emerge -cav gcc. -Ben
Re: [gentoo-dev] Sets vs Meta ebuilds
On Mon, Jul 10, 2017 at 2:25 PM, William L. Thomson Jr. <wlt...@o-sinc.com> wrote: > On Mon, 10 Jul 2017 15:15:35 -0400 > "William L. Thomson Jr." <wlt...@o-sinc.com> wrote: > > > # emerge -pC tomcat-servlet-api > > * This action can remove important packages! In order to be safer, > > use > > * `emerge -pv --depclean ` to check for reverse dependencies > >before > > * removing packages. > > Rather than a message like the above. I think portage should generate a > message/warning saying you are removing a package that is not in your > world file. Which means you are removing a package you did not install > directly. Just like if you were to remove a system package. > > That way people would know if they are removing something that is a > dependency. > > -- > William L. Thomson Jr. > Use -c rather than -C, like grknight suggested, and it will. -Ben
Re: [gentoo-dev] Guidelines for IUSE defaults
On Thu, Feb 9, 2017 at 2:18 PM, Daniel Campbell <z...@gentoo.org> wrote: > > I support the idea of a profile-set variable that determines whether or > not IUSE is respected. Minimalists get their systems faster, we get > something that adds to Gentoo's versatility and an additional profile. > Of course, we should be asking the anti-IUSE people if that would be > good enough to make the profiles/systems they want possible. > > -- > Daniel Campbell - Gentoo Developer > OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net > fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 > > Can't this already be accomplished by modifying the USE_ORDER variable? -Ben
Re: [gentoo-dev] Uppercase characters in package names
> > > Keep in mind some will emerge libraries dependencies for their own projects > and development. They do not always have to be merged as a dependency of > another package. > > It might be confusing to know when it is acceptable to use mixed case and > not. > > -- > William L. Thomson Jr. > It's really not confusing, you're making up issues just to hear yourself talk. -Ben
Re: [gentoo-dev] grub-2 configuration
On Sat, Oct 8, 2016 at 9:28 AM, Tom H <tomh0...@gmail.com> wrote: > On Tue, Oct 4, 2016 at 11:34 PM, William Hubbs <willi...@gentoo.org> > wrote: > > > > You don't have to use grub-mkconfig. You can write /boot/grub/grub.cfg > > by hand if you want, and it appears that the syntax is documented in > > the grub info pages. > > If you write "/boot/grub/grub.cfg" by hand and run grub-mkconfig by > mistake, you'll wipe out your config. It's safer to write it to > "/etc/grub.d/40_custom" and "chmod -x" the other files in > "/etc/grub.d/". > > Well "grub2-mkconfig" by itself doesn't write anywhere unless you pass a -o parameter. If you are "accidentally" running "grub2-mkconfig -o /boot/grub/grub.cfg" and it catches you by surprise that /boot/grub/grub.cfg is overwritten, you have bigger problems. Let's not make up problems where there are none. -Ben
Re: [gentoo-dev] Asking for permission to update packages from LINGUAS to L10N
On 11 August 2016 at 04:22, NP-Hardass <np-hard...@gentoo.org> wrote: > Looks to me like we can't edit that eclass in place, so if we are to > keep it, we should probably revbump it, update the -r1 to L10N, and add > a deprecation warning to the old eclass to help maintainers migrate over. > > Any opinions? I'd be happy work on the revbump for the eclass if we > decide to go that route. CC'ing yngwin since it is his eclass. Feel free to revbump it and change it to whatever works for current needs. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Changing order of default virtual/udev provider
On Wed, Feb 17, 2016 at 7:39 AM, Richard Yao <r...@gentoo.org> wrote: > > > I have no idea why we are even discussing the choice of default for > virtual/udev to have subdiscussions about kdbus. Practically everyone on > the list thinks eudev is the best choice. > I think a lot of us appreciate that eudev exists as a lifeboat or backup plan, but want to wait until there's a real, obvious, technical reason to switch. MOST of the reasons given have just been vague predictions of future doom and gloom. And if we dare ask for more technical reasons, we get berated for being a "systemd lover". "Let's wait until udev becomes unusable" doesn't seem that unreasonable to me, and it has nothing to do with being pro or anti systemd. -Ben
Re: [gentoo-dev] LibreSSL import plan
On Tue, Sep 29, 2015 at 8:43 AM, hasufell <hasuf...@gentoo.org> wrote: > On 09/29/2015 03:32 PM, Rich Freeman wrote: > > [...] > > I have waited 9 days. I don't see a reason to wait another few weeks, > just because you like to bikeshed a lot. > > I honestly feel like you are wasting my time, unless _you_ can come up > with a better solution and offer to do the actual work. > > So far, no one has worked much on libressl, except me, blueness, hannob > and a few community contributors (like Aric Belsito). > > That said, I will go ahead with my work now. If you have something to > actually contribute, please ping me. > > It makes me sad to see how you treat your fellow developers. I apologize in advance for wasting more precious seconds of your time reading this. -Ben
Re: [gentoo-dev] .gitignore
On 14 August 2015 at 14:02, Michał Górny mgo...@gentoo.org wrote: Dnia 2015-08-13, o godz. 21:17:22 Patrick McLean chutz...@gentoo.org napisał(a): We should have common editor artifacts and backup files in there, I generally use this in just about every repository I touch: *~ .*.sw[po] .*.un~ *# .#* This should cover vim and emacs, if there other editors that like to drop files around, we should consider adding those as well.0 set directory=~/tmp,/var/tmp It's usually a bad idea to leave temporary files in cwd :P. It is. But how many people actually bother to change the defaults? -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Re: Referencing bug reports in git
I vote for a simple Bug: 333531 If it is going to be any longer than that, then you need to make sure it is part of the commit message template magic. Because I'm surely not the only one who is lazy and thus averse to typing anything longer for the most common use case: Gentoo bugs. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] useflag policies
On 4 August 2015 at 22:56, Ian Stakenvicius a...@gentoo.org wrote: Are there any cases where things actually break if a package has both flags enabled? IE, is three a package with IUSE=qt4 qt5 that when both flags are enabled would build for qt5 only, and happens to be a dependency atom of something else that needs it to have qt4 support? That to me is the only case where a REQUIRED_USE needs to be set on a package. I'm not aware we have such a package, but I may be overlooking something. Either way, I think it is a dangerous road to go down that way. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] useflag policies
On 5 August 2015 at 03:09, Davide Pesavento p...@gentoo.org wrote: On Mon, Aug 3, 2015 at 8:59 PM, Ben de Groot yng...@gentoo.org wrote: On 4 August 2015 at 04:20, Rich Freeman ri...@gentoo.org wrote: [...] Gentoo should be the best of both worlds. We should give users the power to tweak things, but we shouldn't force them to play with config files all day long just to have a functional system. If users want to care we let them care instead of telling them don't touch like most other distros, but if they don't care we still provide reasonable defaults. And that is exactly what we do. The kde profile enables qt4, the plasma profile enables qt5, the other profiles have no qt* useflags enabled. These are reasonable defaults. As tetromino pointed out, this is very far from the real current situation. Indeed, I was wrong here. We will need another solution. Of course some users will proceed to enable both qt4 and qt5 globally in their make.conf, but I don't think it is unreasonable to expect them to then deal with adding exceptions to package.use for those packages where exactly-one-of is required. In my opinion, this is the way Gentoo has always worked, and we should simply recommend users to only set one of the qt* useflags as globally enabled, if they want to prevent such micro-management. Hiding the qt4 option is in my opinion the wrong solution around people complaining after they have consciously enabled both flags. If this is not acceptable (or absolutely unusable as one dev put it), then we need a proper solution, which a) will not hide the qt4 option, and b) will prevent triggering required_use blockage by choosing qt5 over qt4 in case both are enabled, while c) informing the user about this. This probably requires new eclass or even EAPI functionality. Please go ahead and design and implement such functionality (a sort of REQUIRED_USE defaults). Something along the lines of PYTHON_TARGETS could work. But personally, I'm happy with REQUIRED_USE. In the meantime, we will apply the policies written in the Qt project wiki page. Except for the one that is wrong. In the meantime, we should stick with the policies adopted at the qt3 to qt4 transition (explicit versioned useflags) and let the user deal with per-package management if they enable both flags. We didn't have REQUIRED_USE at the time of the qt3-qt4 transition, so this point is completely moot. We had something worse. That didn't prevent us from using it tho. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] useflag policies
On 4 August 2015 at 04:20, Rich Freeman ri...@gentoo.org wrote: [...] Gentoo should be the best of both worlds. We should give users the power to tweak things, but we shouldn't force them to play with config files all day long just to have a functional system. If users want to care we let them care instead of telling them don't touch like most other distros, but if they don't care we still provide reasonable defaults. And that is exactly what we do. The kde profile enables qt4, the plasma profile enables qt5, the other profiles have no qt* useflags enabled. These are reasonable defaults. Of course some users will proceed to enable both qt4 and qt5 globally in their make.conf, but I don't think it is unreasonable to expect them to then deal with adding exceptions to package.use for those packages where exactly-one-of is required. In my opinion, this is the way Gentoo has always worked, and we should simply recommend users to only set one of the qt* useflags as globally enabled, if they want to prevent such micro-management. Hiding the qt4 option is in my opinion the wrong solution around people complaining after they have consciously enabled both flags. If this is not acceptable (or absolutely unusable as one dev put it), then we need a proper solution, which a) will not hide the qt4 option, and b) will prevent triggering required_use blockage by choosing qt5 over qt4 in case both are enabled, while c) informing the user about this. This probably requires new eclass or even EAPI functionality. In the meantime, we should stick with the policies adopted at the qt3 to qt4 transition (explicit versioned useflags) and let the user deal with per-package management if they enable both flags. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] useflag policies
On 3 August 2015 at 01:33, Andrew Savchenko birc...@gentoo.org wrote: On Mon, 3 Aug 2015 00:34:51 +0800 Ben de Groot wrote: [...] This policy will allow to USE both qt versions whichever is available preferring newer one. Quite reasonable approach. Alternatives (^^() and ??()) will require micromanagement (e.g. pagkage.use.conf) for dozens if not hundreds of packages for no good reason. If someone still needs to override such policy (e.g. to use qt4 when both are available), this can be done by per-package configuration. My idea is that packages should be fully controllable, but choises of default behaviour should be done so, that in most cases micromanagement will not be necessary. I like this qt policy and I'm not sure if it violates any current rule. See https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies under 1.4 and 1.5. QA has spoken out pretty clearly against unversioned gtk or qt useflags, and in favour of explicit versioned useflags. Dropping the explicit qt4 useflag in these cases goes against (at least the spirit of) this. [...] So I propose to add somewhere to devmanual/policies the following recommendation: If package supports several versions of the same technology (e.g. qt4 and qt5) and more than one is enabled by USE flags, ebuild should prefer the later one (in terms of technology generation).. If we adopt this, we should make sure the users understand this policy, because it hides certain details from the user. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] useflag policies
On 3 August 2015 at 09:37, Rich Freeman ri...@gentoo.org wrote: On Sun, Aug 2, 2015 at 9:03 PM, Patrick Lauer patr...@gentoo.org wrote: I find setting USE=qt4 -qt5 a lot more obvious than having USE=qt (why not USE=X ?) which then does different things based on another useflag, sometimes. Maybe. It's horribly inconsistent and even might change result over time, which is not very user-friendly. The problem is that this approach breaks down with scenarios which are likely to be commonplace. I want to use fooplayer and bargrapher which are two qt-based applications. fooplayer only supports qt4, and bargrapher only supports qt5. What USE flags should I set, without restorting to per-package flags? These packages would not have useflags, as they only use one toolkit. Then I also install klunkybrowser which supports both qt4 and qt5 but not at the same time, so how should I manage my flags for that? Set your global default in make.conf as either qt4 or qt5. If you want to deviate from that for some package, you can set per package use flags. Easy peasy. Clear and straightforward. Principle of least surprise. The current qt policy just has each package support only one version using USE=qt No, that is not at all the case. We have banned a simple qt useflag since many years (which is also the QA policy). We have been using versioned qt3, qt4, qt5 useflags. and while it denies user choice for klunkybrowser it is at least simple. The alternative of qt means I don't care what version is also simple Except many users do care. I don't see the benefit in changing the way we used to do this. The approach qt4=qt4 and qt5=qt5 seems simpler on the surface, but it means that users end up having to set tons of per-package configurations when they don't actually care which one they use, and it also doesn't necessarily hint to users which will give them the best experience on each package. If they don't care, they can simply follow the defaults and not set any qt4 or qt5 useflags in make.conf. Right now you can get away with just USE=qt4 -qt5 because we don't have many qt5-only packages in the tree As I said before, this is of no consequence, as there would be no mutually exclusive qt4 and qt5 useflags anyway for those packages. The problem only appears with packages that force a choice between qt4 and qt5, and users that have enabled both useflags globally. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] useflag policies
On 3 August 2015 at 11:30, Rich Freeman ri...@gentoo.org wrote: On Sun, Aug 2, 2015 at 11:24 PM, Ben de Groot yng...@gentoo.org wrote: I want to use fooplayer and bargrapher which are two qt-based applications. fooplayer only supports qt4, and bargrapher only supports qt5. What USE flags should I set, without restorting to per-package flags? These packages would not have useflags, as they only use one toolkit. What if qt support is optional, and I do/don't want it enabled? Users who don't care, simply follow the defaults as set by the package maintainer or profile. Users who do care wouldn't mind adding a rule to their package.use. -- Cheers, Ben | yngwin Gentoo developer
[gentoo-dev] useflag policies
Recently some team members of the Qt project have adopted these ebuild policies: https://wiki.gentoo.org/wiki/Project:Qt/Policies I have an issue with the policy adopted under Requires one of two Qt versions. In my opinion, in the case where a package offers a choice between qt4 or qt5, we should express this in explicit useflags and a REQUIRED_USE=^^ ( qt4 qt5 ). This offers the user the clearest choice. Other developers state that users are not interested in such implementation details, or that forced choice through REQUIRED_USE is too much of a hassle. This results in current ebuilds such as quassel to not make it clear that qt4 is an option. This goes against the principle of least surprise, as well as against QA recommendations. I would like to hear specifically from QA about how we should proceed, but comments from the wider developer community are also welcome. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Re: Reverted python3.4 defaults
On 20 July 2015 at 17:27, Jason Zaman perfin...@gentoo.org wrote: On Mon, Jul 20, 2015 at 10:39:25AM +0200, Dirkjan Ochtman wrote: On Mon, Jul 20, 2015 at 6:03 AM, Ben de Groot yng...@gentoo.org wrote: I would like to hear from the other team members, yes. I have sympathy towards those who are asking for only one Python in stages (as in, I would be fine with that), but I very much think we should not leave Python 3 out of generally installed systems by default. We need to move through the transition, and increasing the barriers to Python 3 adoption will only make that process slower. I also feel like a voting process for this is probably not a solution. I also very much dislike shipping only python2. Having only one python is admirable and I'm all for it but if we only ship one by default it should be python3. That is a nice sentiment, but unpractical. We have a lot more packages that require python2, while we only have 74 that require python3. While it may be possible to ship with python3 only (I haven't looked at what the packages in stage3 support), users will almost certainly need to install python2 when they start installing more packages. But if we ship with python2 only, then most users won't need python3. Those who want it, can of course simply add it. Going with python2 as default simply makes more sense. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Re: Reverted python3.4 defaults
On 20 July 2015 at 00:03, Mike Gilbert flop...@gentoo.org wrote: If there are no objections, I would like to enable python3.4 by default on Saturday, July 25. That means making the following change: profiles/base/make.defaults: PYTHON_TARGETS=python2_7 python3_4 I would like to note that we only have around 50 packages that require python3, while the majority requires python2, and the remainder will function with either. For this reason it seems to make more sense to me to only set PYTHON_TARGETS=python2_7 as default, and leave adding any python3_* targets to the user. This will also debloat our stage3 tarballs. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Re: Reverted python3.4 defaults
On 20 July 2015 at 02:31, Mike Gilbert flop...@gentoo.org wrote: On Sun, Jul 19, 2015 at 12:42 PM, Ben de Groot yng...@gentoo.org wrote: On 20 July 2015 at 00:03, Mike Gilbert flop...@gentoo.org wrote: If there are no objections, I would like to enable python3.4 by default on Saturday, July 25. That means making the following change: profiles/base/make.defaults: PYTHON_TARGETS=python2_7 python3_4 I would like to note that we only have around 50 packages that require python3, while the majority requires python2, and the remainder will function with either. For this reason it seems to make more sense to me to only set PYTHON_TARGETS=python2_7 as default, and leave adding any python3_* targets to the user. This will also debloat our stage3 tarballs. It looks like we have eliminated most (all?) of the unbounded dependencies on dev-lang/python from the gentoo repository, so this could actually work to satisfy the goal of smaller stages and only having one version of python installed. However, it feels like a step backward to me; I would rather treat python3 as the primary interpreter and python2 as the one necessary for the legacy baggage. I understand the sentiment, and I wish it was possible. I'm not some kind of Luddite. But too many useful packages (still) depend on python2. A couple of months ago I tried switching to python3 (either 3.3 or 3.4) only, but I had a growing list of stuff I wanted that ended up in my package.use/py2 file. Pretty soon I decided it was not worth the trouble, and I switched back to python 2.7 only. My tree grepping shows 1527 out of 2371 packages with python support need py2 and don't work with py3. It is definitely too early to treat python2 as legacy. There are two packages I want to use that need python 3 (compton and pybugz), but I decided I can live without them. And I think this is true for many of our users. They could happily live with just python 2.7 as only default. If they do want py3 packages, it is easy enough to add that to PYTHON_TARGETS in make.conf, or individual useflags in package.use. I don't see any strong technical reason to switch from python2 + python3 to python2-only enabled. Some people don't like having two versions of python installed -- that's about the gist of it. Indeed, there is no strong technical reason, except that some people like to keep their systems more lean. But I think having a smaller stage3 tarball is a more important reason. The python team has historically left that up to the RelEng team, which has been averse to handling that themselves. So, I'm personally not going to make that change without some kind of vote on it. I can arrange a vote within the python team if you like. I would like to hear from the other team members, yes. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Re: Reverted python3.4 defaults
On 20 July 2015 at 01:01, Anthony G. Basile bluen...@gentoo.org wrote:
On 7/19/15 12:42 PM, Ben de Groot wrote:
On 20 July 2015 at 00:03, Mike Gilbert flop...@gentoo.org wrote:
If there are no objections, I would like to enable python3.4 by
default on Saturday, July 25. That means making the following change:
profiles/base/make.defaults:
PYTHON_TARGETS=python2_7 python3_4
I would like to note that we only have around 50 packages that require
python3, while the majority requires python2, and the remainder will
function with either. For this reason it seems to make more sense to
me to only set PYTHON_TARGETS=python2_7 as default, and leave adding
any python3_* targets to the user. This will also debloat our stage3
tarballs.
What are those 50 packages, if you have the list handy? Its not the number
but their impact.
It's actually 74 packages at current, if my quick and dirty grepping is correct:
% qgrep -H PYTHON_COMPAT | grep -v python2 | grep -v 'python{2' | cut
-f1 -d : | cut -f 1,2 -d / | uniq
app-accessibility/accerciser
app-accessibility/orca
app-accessibility/speech-dispatcher
app-admin/cdist
app-arch/tardelta
app-arch/vimball
app-backup/backintime
app-editors/gedit
app-editors/gedit-plugins
app-editors/retext
app-emulation/lxc
app-i18n/ibus-cangjie
app-misc/media-player-info
app-portage/grs
app-text/nfoview
dev-libs/libgit2-glib
dev-libs/libixion
dev-python/aiohttp
dev-python/asyncio
dev-python/beautifulsoup
dev-python/cangjie
dev-python/cfgio
dev-python/dugong
dev-python/elasticsearch-py
dev-python/mypy
dev-python/pmw
dev-python/polygon
dev-python/pydns
dev-python/pyfltk
dev-python/pymtp
dev-python/python3-openid
dev-python/pythondialog
dev-python/pyx
dev-python/simpletal
dev-python/torment
dev-python/utmp
dev-util/cligh
dev-util/devhelp
dev-util/fatrace
dev-vcs/gitg
games-util/nml
gnome-base/gnome-shell
gnome-extra/gnome-builder
media-gfx/blender
media-gfx/eog-plugins
media-sound/gnome-music
media-sound/lyvi
media-sound/pithos
media-sound/rhythmbox
media-video/gaupol
media-video/pitivi
net-analyzer/pypacker
net-irc/znc
net-misc/gns3-converter
net-misc/gns3-gui
net-misc/gns3-server
net-misc/wget
net-news/canto-curses
net-news/canto-daemon
sci-electronics/pulseview
sci-electronics/sigrok-cli
sci-libs/libsigrokdecode
sys-apps/razercfg
sys-block/blocks
sys-fs/s3ql
sys-kernel/kergen
sys-process/systemd-cron
www-client/pybugz
www-client/qutebrowser
x11-apps/intel-gpu-tools
x11-misc/compton
x11-misc/dex
x11-misc/redshift
x11-misc/treeline
I have removed portage and python-exec as false positives from this
grep. Then there is net-misc/wget which only needs python if USE=test
is enabled. There may be a few more like that.
I don't see anything else that is immediately important.
--
Cheers,
Ben | yngwin
Gentoo developer
Re: [gentoo-dev] Problems updating Qt from 4.8.6 to 4.8.7
On Sun, Jul 5, 2015 at 2:25 PM, Sebastian Pipping sp...@gentoo.org wrote: I really wonder if there is any update path from having dev-qt/qtcore-4.8.6-r2 dev-qt/qtgui-4.8.6-r4 installed before to dev-qt/qtcore-4.8.7 dev-qt/qtgui-4.8.7 Usually this kind of conflict happens when for SOME reason, at least one part of the dev-qt/*:4 collection is not being pulled into the depgraph, like if there's one qt* package which is now orphaned/depcleanable. If even one piece is not pulled into the dep list, it will try to hold all the rest of the pieces back at 4.8.6. Something like this may help, to just force all installed qt4 pieces to upgrade, regardless of whether they are deps of anything: emerge -1av $(qlist -ICS dev-qt/ | grep 4$) Another possibility for a conflict is if you have some package.use entries for dev-qt/ that are too version specific, where the upgraded 4.8.7 version of some component would not meet the USE requirements of some reverse dep. Then it'd lock that one component at 4.8.6 and again it's game-over for the upgrade. Hope this helps, Ben Kohler (iamben @ Freenode)
Re: [gentoo-dev] Problems updating Qt from 4.8.6 to 4.8.7
On 6 July 2015 at 03:25, Sebastian Pipping sp...@gentoo.org wrote: On 05.07.2015 20:44, Alexandre Rostovtsev wrote: What I usually end up doing is listing my installed dev-qt/qt* ebuilds, and updating all of them together explicitly: emerge -1 qtcore:4 qtgui:4 qtsql:4 etc. That's what I tried but it doesn't seem to work with this update. Looking at the dependencies of qtgui dev-qt/qtgui-4.8.6-r4 DEPEND ~dev-qt/qtcore-4.8.6 dev-qt/qtgui-4.8.7 DEPEND ~dev-qt/qtcore-4.8.7 I really wonder if there is any update path from having dev-qt/qtcore-4.8.6-r2 dev-qt/qtgui-4.8.6-r4 installed before to dev-qt/qtcore-4.8.7 dev-qt/qtgui-4.8.7 after. Right now, it looks like I have to use emerge -C .. to un-install them completely, temporary breaking Qt and installing 4.8.7 fresh. I'm still hoping for some way to not needing to do that. Alternatively, just try emerge --update --deep world - it probably should work if you have a consistent, complete and updateable world set. That's where I'm coming from. It doesn't stop complaining because of Qt. Best, Sebastian See also https://wiki.gentoo.org/wiki/Qt/FAQ#Why_do_I_get_blockers_when_trying_to_emerge_Qt.3F -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] RFC News item: FFmpeg default
On 11 April 2015 at 15:19, Ben de Groot yng...@gentoo.org wrote: And since this is now on the Council's agenda, we're waiting for their decision. Since the Council had no objections, this has now been committed. Thanks for all the feedback. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] RFC News item: FFmpeg default
On 7 April 2015 at 15:00, Alexis Ballier aball...@gentoo.org wrote: On Tue, 7 Apr 2015 07:13:16 +0800 Ben de Groot yng...@gentoo.org wrote: Please also note that some packages support only one of the two implementations. An attempt to install one of those packages may result in blockers requiring the user changes the global USE=libav state. The most notable example of such package is media-video/mplayer. -media-video/mpv may be used as a replacement for users who prefer libav. +media-video/mpv may be used as a replacement for users who prefer libav, +even though upstream mpv developers recommend using ffmpeg. This is off-topic, and strongly biased. The original statement may give the impression that mpv is to libav what mplayer is to ffmpeg. Many users were surprised to find out that mpv upstream actually recommends ffmpeg, and that some of mpv's features do not work with libav. If we are going to specifically recommend mpv, then it is something users need to be aware of. We could change it to: media-video/mpv works with both ffmpeg and libav, though some of its features require ffmpeg. Or something along those lines. I'd rather drop entirely that part about mplayer/mpv; I agree this is something users need to be aware of if we recommend mpv but with ffmpeg as default the mplayer hard requires ffmpeg is no longer an issue. Otherwise, we might as well note that gst-libav recommends... heh... libav, and as such all gst based players (totem, firefox, etc.) Alexis. Good point. So let's drop The most notable example ... until the end of the paragraph. And since this is now on the Council's agenda, we're waiting for their decision. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] libressl status
On 7 April 2015 at 06:07, Jason A. Donenfeld zx...@gentoo.org wrote: Solution: Packages that will compile against either one get || (openssl libressl). Packages that require a specific one will just have that one listed. Openssl will block Libressl and vice versa. This would result in a similar mess as we have been dealing with in the ffmpeg / libav situation. Please don't do that. Make the choice explicit, and don't rely on semi-automagic dependency resolution. Also, explain clearly to users what the default implementation is and why. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] RFC News item: FFmpeg default
On 6 April 2015 at 17:35, Michał Górny mgo...@gentoo.org wrote: Dnia 2015-04-06, o godz. 14:10:12 Ben de Groot yng...@gentoo.org napisał(a): On 30 March 2015 at 00:23, Michał Górny mgo...@gentoo.org wrote: Dnia 2015-03-30, o godz. 00:07:16 Include example code. Updated version: Title: FFmpeg default Author: Ben de Groot yng...@gentoo.org Content-Type: text/plain Posted: 2015-04-07 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: media-video/ffmpeg Display-If-Installed: media-video/libav Since the choice between ffmpeg and libav has been made more explicit, there has been a lot of discussion about what the default implementation should be. It can be concluded that media-video/ffmpeg has wider support, and would be somewhat more convenient for most end-users. For this reason the default implementation has been switched back from media-video/libav to media-video/ffmpeg by removing the libav useflag from the base profile. 'Switched back' is suggesting there was some 'unintentional' switch from ffmpeg to libav. Keep this free of politics, and just 'switched'. No, it does not suggest that. It simply reflects the history of the issue: once upon a time we had ffmpeg. Then libav was introduced and at some point made the default implementation. Now we are switching back to ffmpeg as default implementation. There is no politics in my statement. If the libav useflag is already globally enabled or disabled in /etc/portage/make.conf, then no further action is required. Users who implicitly relied on libav being enabled in their profile, and who wish to continue using libav, should enable USE=libav in their /etc/portage/make.conf file. Also please prepare an update to the USE=libav news item to state updated default. Diff: --- /var/portage/metadata/news/2015-02-01-use-libav/2015-02-01-use-libav.en.txt 2015-02-04 05:31:20.0 +0800 +++ /home/ben/tmp/2015-02-01-use-libav.en.txt 2015-04-06 14:05:56.982039939 +0800 @@ -2,7 +2,7 @@ Author: Michał Górny mgo...@gentoo.org Content-Type: text/plain Posted: 2015-02-01 -Revision: 1 +Revision: 2 News-Item-Format: 1.0 Display-If-Installed: media-video/ffmpeg Display-If-Installed: media-video/libav @@ -20,17 +20,17 @@ However, whenever appropriate additional USE=libav will be introduced to control the preference of one implementation over the other. -Users who currently use libav (the Gentoo default) do not have to -perform any action since USE=libav is enabled by default. It should be -noted that the users still need to enable USE=ffmpeg on packages with -optional libav support as well. Users who want to use ffmpeg instead -need to specify USE=-libav in make.conf explicitly. +Users who currently use libav need to enable USE=libav in +/etc/portage/make.conf. It should be noted that users still need to +enable USE=ffmpeg on packages with optional libav support as well. +Users who currently use ffmpeg need to take no action. Please also note that some packages support only one of the two implementations. An attempt to install one of those packages may result in blockers requiring the user changes the global USE=libav state. The most notable example of such package is media-video/mplayer. -media-video/mpv may be used as a replacement for users who prefer libav. +media-video/mpv may be used as a replacement for users who prefer libav, +even though upstream mpv developers recommend using ffmpeg. This is off-topic, and strongly biased. The original statement may give the impression that mpv is to libav what mplayer is to ffmpeg. Many users were surprised to find out that mpv upstream actually recommends ffmpeg, and that some of mpv's features do not work with libav. If we are going to specifically recommend mpv, then it is something users need to be aware of. We could change it to: media-video/mpv works with both ffmpeg and libav, though some of its features require ffmpeg. Or something along those lines. Please do not alter the state of 'libav' flag on a per-package basis (e.g. via package.use). The flag needs to be set globally to have FYI: since Council's meeting in one week, I have added this to the agenda. I'm really concerned about Gentoo's PR when users suffer due to developers ping-ponging implementations/defaults. It's not so much ping-ponging as stumbling upon what is the best solution for our users. Some years ago libav was made a soft default. And if I recall correctly, that was done with very little discussion. Recently this default was made harder by adding USE=libav to the base profile. This resulted in quite a backlash from users. Moreover, many upstreams of consuming packages actually prefer ffmpeg. Add to that the upstream ffmpeg policy of merging in changes from libav. All in all, from an end-user point of view it makes more sense to have ffmpeg as default. And when users were asked, they overwhelmingly expressed support for changing
Re: [gentoo-dev] RFC News item: FFmpeg default
On 30 March 2015 at 00:23, Michał Górny mgo...@gentoo.org wrote: Dnia 2015-03-30, o godz. 00:07:16 Include example code. Updated version: Title: FFmpeg default Author: Ben de Groot yng...@gentoo.org Content-Type: text/plain Posted: 2015-04-07 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: media-video/ffmpeg Display-If-Installed: media-video/libav Since the choice between ffmpeg and libav has been made more explicit, there has been a lot of discussion about what the default implementation should be. It can be concluded that media-video/ffmpeg has wider support, and would be somewhat more convenient for most end-users. For this reason the default implementation has been switched back from media-video/libav to media-video/ffmpeg by removing the libav useflag from the base profile. If the libav useflag is already globally enabled or disabled in /etc/portage/make.conf, then no further action is required. Users who implicitly relied on libav being enabled in their profile, and who wish to continue using libav, should enable USE=libav in their /etc/portage/make.conf file. Also please prepare an update to the USE=libav news item to state updated default. Diff: --- /var/portage/metadata/news/2015-02-01-use-libav/2015-02-01-use-libav.en.txt 2015-02-04 05:31:20.0 +0800 +++ /home/ben/tmp/2015-02-01-use-libav.en.txt 2015-04-06 14:05:56.982039939 +0800 @@ -2,7 +2,7 @@ Author: Michał Górny mgo...@gentoo.org Content-Type: text/plain Posted: 2015-02-01 -Revision: 1 +Revision: 2 News-Item-Format: 1.0 Display-If-Installed: media-video/ffmpeg Display-If-Installed: media-video/libav @@ -20,17 +20,17 @@ However, whenever appropriate additional USE=libav will be introduced to control the preference of one implementation over the other. -Users who currently use libav (the Gentoo default) do not have to -perform any action since USE=libav is enabled by default. It should be -noted that the users still need to enable USE=ffmpeg on packages with -optional libav support as well. Users who want to use ffmpeg instead -need to specify USE=-libav in make.conf explicitly. +Users who currently use libav need to enable USE=libav in +/etc/portage/make.conf. It should be noted that users still need to +enable USE=ffmpeg on packages with optional libav support as well. +Users who currently use ffmpeg need to take no action. Please also note that some packages support only one of the two implementations. An attempt to install one of those packages may result in blockers requiring the user changes the global USE=libav state. The most notable example of such package is media-video/mplayer. -media-video/mpv may be used as a replacement for users who prefer libav. +media-video/mpv may be used as a replacement for users who prefer libav, +even though upstream mpv developers recommend using ffmpeg. Please do not alter the state of 'libav' flag on a per-package basis (e.g. via package.use). The flag needs to be set globally to have -- Cheers, Ben | yngwin Gentoo developer
[gentoo-dev] RFC News item: FFmpeg default
Title: FFmpeg default Author: Ben de Groot yng...@gentoo.org Content-Type: text/plain Posted: 2015-04-01 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: virtual/ffmpeg Since the choice between ffmpeg and libav has been made more explicit, there has been a lot of discussion about what the default implementation should be. It can be concluded that media-video/ffmpeg has wider support, and would be somewhat more convenient for most end-users. For this reason the default implementation has been switched back from media-video/libav to media-video/ffmpeg by removing the libav useflag from the base profile. If the libav useflag is already globally enabled or disabled in /etc/portage/make.conf, then no further action is required. Users who implicitly relied on libav being enabled in their profile, and who wish to continue using libav, should enable this in their local /etc/portage configuration. -- Cheers, Ben | yngwin Gentoo developer
[gentoo-dev] Last-rite x11-themes/gtk-engines-qtcurve
# Ben de Groot yng...@gentoo.org (29 Mar 2015) # Merged with qtcurve-qt4 into x11-themes/qtcurve (with gtk useflag) # Removal in 30 days. See also bug #544406. x11-themes/gtk-engines-qtcurve -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] RFC: app-eselect category
On 29 March 2015 at 04:47, Ulrich Mueller u...@gentoo.org wrote: Now the number of eselect-* packages in the app-admin category has grown to 52. Should we create a new app-eselect category for them? I think this is a good idea. So +1 from me. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] rfc: zsh completions -- optional or mandatory?
On 27 March 2015 at 00:51, William Hubbs willi...@gentoo.org wrote: The other method is shown by dev-vcs/hub at least, and maybe several other packages -- e.g. unconditionally installing the completions according to our small files installation practice and not reflecting the rdepend on app-shells/zsh. This is standard practice already (e.g. for systemd unit files and bash completion files), so this should be followed for zsh completion files as well. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Re: multilib amd64 news item for review
On 18 March 2015 at 20:46, Duncan 1i5t5.dun...@cox.net wrote: Ben de Groot posted on Wed, 18 Mar 2015 15:40:02 +0800 as excerpted: On 17 March 2015 at 23:33, Michał Górny mgo...@gentoo.org wrote: Dnia 2015-03-15, o godz. 15:11:47 Michał Górny mgo...@gentoo.org napisał(a): Here's -r1: [...] I think this is really great! Just one small nitpick: Note that after performing this step, 32-bit applications on user's system may become temporarily broken. Make that the user's system. What about... Note: 32-bit applications may be temporarily broken after this step. Concise and to the point. =:^) Even better! -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] multilib amd64 news item for review
On 17 March 2015 at 23:33, Michał Górny mgo...@gentoo.org wrote: Dnia 2015-03-15, o godz. 15:11:47 Michał Górny mgo...@gentoo.org napisał(a): Here's -r1: [...] I think this is really great! Just one small nitpick: Note that after performing this step, 32-bit applications on user's system may become temporarily broken. Make that the user's system. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Re: [gentoo-dev-announce] Last rites: media-video/mplayer2 media-video/smplayer2
On 16 March 2015 at 21:54, Юра Цимбалов yura.t...@gmail.com wrote: That would be great, but it depends on getting newer mpv stable, while (s)mplayer2 is dead and broken right now. https://bugs.gentoo.org/buglist.cgi?quicksearch=mplayer2list_id=2703540 Why it's broken? As stated in my original message: See bugs 452484, 485994, 512082, 519212. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Re: [gentoo-dev-announce] Last rites: media-video/mplayer2 media-video/smplayer2
On 16 March 2015 at 19:17, Alexander Berntsen berna...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 16/03/15 11:09, Nikos Chantziaras wrote: On 16/03/15 11:58, Alexander Berntsen wrote: Does smplayer work with mpv? Version 14.9.0.6690 and up supports mpv. Then I would encourage that we stabilise this before removing (s)mplayer2. That would be great, but it depends on getting newer mpv stable, while (s)mplayer2 is dead and broken right now. Anyway, it's probably a good idea to get that process started. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] multilib amd64 news item for review
On 15 March 2015 at 22:43, Ulrich Mueller u...@gentoo.org wrote: On Sun, 15 Mar 2015, Michał Górny wrote: Hello, everyone. Here's the first draft of news item for gx86-multilib. I tried to cover all the important aspects. Please review and let me know what you think. Title: True multilib support on amd64 Author: Michał Górny mgo...@gentoo.org Content-Type: text/plain Posted: 2015-01-28 Revision: 1 News-Item-Format: 1.0 Display-If-Keyword: amd64 Display-If-Keyword: ~amd64 Users of no-multilib profiles won't be affected, so maybe Display-If-Profile should be used (in addition, or instead of Display-If-Keyword)? Starting with 2015-03-29, we are enabling the true multilib support on amd64 and masking the old emul-linux-x86 package sets for removal. This change provides I'm not a native speaker, but shouldn't a future tense be used here? English teacher here: no. The present continuous (are enabling) is a normal way to express the future in English. The only changes necessary here, as already noted, is changing 'with' to 'on' before the date, and dropping 'the' before true. It may be nice to specify *stable* amd64. I would also say that 'true' is incorrect, as the emul packages were also truly multilib, just implemented in a different way. Maybe 'eclass-based' is more specific and less opinionated? our users with the opportunity to build 32-bit libraries from source with all the flexibility given by ebuilds, rather than relying on pre-packaged binary versions of them. [...] installed on their systems. This will aid the Package Manager in choosing the correct dependency resolution path. If using Portage, this can be done using the following command: $ emerge -C 'app-emulation/emul-linux-x86*' Note that after performing this step, 32-bit applications on your system So far you have used third person throughout, so avoid the your here. I agree. Maybe 'that'? -- Cheers, Ben | yngwin Gentoo developer
[gentoo-dev] Last rites: media-video/mplayer2 media-video/smplayer2
# Ben de Groot yng...@gentoo.org (15 Mar 2015) # These projects have been abandoned upstream. Most mplayer2 devs have moved # on to media-video/mpv, and users are suggested to do the same. We have # media-video/baka-mplayer and media-video/smplayer available as Qt-based GUIs. # See bugs 452484, 485994, 512082, 519212. Removal in 30 days. media-video/mplayer2 media-video/smplayer2 -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Naming of repositories: gento-x86 edition, bike shedding wanted
On 15 March 2015 at 06:34, Andreas K. Huettel dilfri...@gentoo.org wrote:
imho,
Questions:
0. What names for the tree/repository.
gentoo
(it's also the repo_name)
Our repo is already named gentoo, so this makes the most sense.
But I wouldn't mind gentoo-main either. But then we should also
change the repo_name.
While we are at it, can we change the default location from
/usr/portage to something like /var/repos/${repo_name} then?
--
Cheers,
Ben | yngwin
Gentoo developer
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles/base: package.use.mask
mr_bones_15/03/09 18:15:22 Modified: package.use.mask Log: hide the qt5 stuff for yabause for now [...] +# Michael Sterrett mr_bones_@g.o (09 Mar 2015) +# Mask qt5 support until qt5 is stable so as to not +# hold up making yabause stable. +games-emulation/yabause qt5 This is not necessary since qt5 is in base/use.stable.mask -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Re: Should there be a preference with qt4 and qt5 USE flags?
On 9 March 2015 at 04:17, Johannes Huber j...@gentoo.org wrote: Am Sonntag, 8. März 2015, 21:50:02 schrieb Nikos Chantziaras: On 08/03/15 21:35, Alexandre Rostovtsev wrote: On Sun, 2015-03-08 at 21:31 +0200, Nikos Chantziaras wrote: Some ebuilds in portage for Qt-based software support both Qt4 as well as Qt5. Some have +qt4 qt5 in IUSE, others have qt4 qt5. Is there a guideline for this somewhere? If a package needs Qt and thus lists: REQUIRED_USE=^^ ( qt4 qt5 ) but otherwise doesn't prefer one version over the other and both are equally well supported, should qt4 still be enabled by default? As long qt5 is testing only qt4 makes sense. This. For now, we need to prefer qt4, if there is a choice between qt4 and qt5. (Unless upstream has already abandoned the qt4 option, which makes it less of a choice, I guess.) But please set useflags for both options, so the choice is clear to the user. As soon as qt5 goes stable, I think we should switch to qt5 as default where possible. And especially when we have an at-least-one-of or an either-or required-use, we need to have one of the options set as default. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Re: Fonts project meeting and elections
On 1 March 2015 at 23:36, Guilherme Amadio ama...@gentoo.org wrote: On Sun, Mar 01, 2015 at 08:59:38PM +0800, Ben de Groot wrote: On 28 February 2015 at 19:52, Michael Orlitzky m...@gentoo.org wrote: On 02/28/2015 01:47 AM, Ben de Groot wrote: If we do the use expand, we should leave it up for users to set. I suggest we default to only otf, if there is a choice. Other formats should not be installed by default, unless it's the only option for that package. This is going to get confusing fast -- please consider just installing everything by default. If you default to only OTF, what happens when you install a foo-ttf package? Is it a no-op? What if there's a package that only ships WOFF files? A combination of TTF and WOFF? Most of the fonts are tiny and it's not worth the hassle to avoid a few kilobytes. It will also keep the eclass nice and clean. If you default to installing everything, then when a user goes out of his way to remove (say) WOFF, you can go ahead and just ignore WOFF files even if the result is something stupid like an empty package. (The webfonts might be useful for clients, by the way. If they're not installed locally, your browser downloads them on-demand and caches them for later use.) Actually, after thinking about it some more, and doing some more research, I think this approach is unnecessary. Unless someone can tell me otherwise, I don't think we have any software that can handle truetype fonts but not opentype fonts. Most if not all of these packages use media-libs/freetype, which displays both formats just fine. So when we have font packages that offer both ttf and otf, then we should just install the superior format, which is OpenType. For packages that only offer one format, we install that format. Webfonts are also not an issue, as they are simply repackaged OpenType fonts aimed at web delivery. But most web developers use third party CDNs for that, such as Google Fonts. For the very few people who want to serve WOFF fonts from their own websites, I'm sure they can locate them as necessary. And webfonts are not useful for clients. Users should simply install the otf (or ttf) format of those fonts locally, and they will be picked up instead of the webfonts. Summarized, I propose the following policy: 1. If there is a choice of formats between otf and ttf, install only otf. 2. Do not install webfonts. I agree with your policy, but I think it's still a good idea to offer a mechanism to install the other formats for those who need it, maybe via truetype and woff or webfont USE flags. LaTeX, for example, may not be able to use OpenType fonts, unless you use XeTeX, or other newer variant, and sometimes a package you may want to use is only available for plain LaTeX or PDFTeX (pst-solides3d and pstricks come to mind). We could have global USE flags for each popular font format, turn on the flag for OpenType by default, and let users choose extra formats they want. Another thing we might want to work on is on a way to convert fonts for use with legacy LaTeX software that can't use OpenType files. Alexis, can you shed some light on this from the TeX side? What font formats can be used by various TeX packages? -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Re: Fonts project meeting and elections
On 28 February 2015 at 19:52, Michael Orlitzky m...@gentoo.org wrote: On 02/28/2015 01:47 AM, Ben de Groot wrote: Since this is mostly used for web developers, I recommend to leave it off for desktop users, but possibly on for servers, for example. If we do the use expand, we should leave it up for users to set. I suggest we default to only otf, if there is a choice. Other formats should not be installed by default, unless it's the only option for that package. This is going to get confusing fast -- please consider just installing everything by default. If you default to only OTF, what happens when you install a foo-ttf package? Is it a no-op? What if there's a package that only ships WOFF files? A combination of TTF and WOFF? Most of the fonts are tiny and it's not worth the hassle to avoid a few kilobytes. It will also keep the eclass nice and clean. If you default to installing everything, then when a user goes out of his way to remove (say) WOFF, you can go ahead and just ignore WOFF files even if the result is something stupid like an empty package. (The webfonts might be useful for clients, by the way. If they're not installed locally, your browser downloads them on-demand and caches them for later use.) Actually, after thinking about it some more, and doing some more research, I think this approach is unnecessary. Unless someone can tell me otherwise, I don't think we have any software that can handle truetype fonts but not opentype fonts. Most if not all of these packages use media-libs/freetype, which displays both formats just fine. So when we have font packages that offer both ttf and otf, then we should just install the superior format, which is OpenType. For packages that only offer one format, we install that format. Webfonts are also not an issue, as they are simply repackaged OpenType fonts aimed at web delivery. But most web developers use third party CDNs for that, such as Google Fonts. For the very few people who want to serve WOFF fonts from their own websites, I'm sure they can locate them as necessary. And webfonts are not useful for clients. Users should simply install the otf (or ttf) format of those fonts locally, and they will be picked up instead of the webfonts. Summarized, I propose the following policy: 1. If there is a choice of formats between otf and ttf, install only otf. 2. Do not install webfonts. Your thoughts? -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] [RFC] luajit global useflag
On 26 February 2015 at 22:44, Michał Górny mgo...@gentoo.org wrote: Ben de Groot yng...@gentoo.org napisał: % quse -D luajit local:luajit:app-editors/gvim: Use dev-lang/luajit instead of dev-lang/lua local:luajit:app-editors/vim: Use dev-lang/luajit instead of dev-lang/lua local:luajit:app-editors/vim-qt: Use dev-lang/luajit instead of dev-lang/lua local:luajit:games-action/minetest: Use dev-lang/luajit instead of dev-lang/lua local:luajit:games-engines/solarus: Use LuaJIT instead of default Lua. local:luajit:games-roguelike/stone-soup: Use dev-lang/luajit as scripting backend instead of dev-lang/lua. local:luajit:media-sound/csound: Use the lua just-in-time compiler dev-lang/luajit instead of dev-lang/lua local:luajit:media-video/mpv: Use dev-lang/luajit instead of dev-lang/lua local:luajit:www-client/luakit: Use the lua just-in-time compiler dev-lang/luajit instead of dev-lang/lua, which should make luakit faster. local:luajit:www-servers/nginx: Use dev-lang/luajit instead of dev-lang/lua for lua support when building the lua http module. I propose we make luajit a global useflag, using the description from media-sound/csound: Use the lua just-in-time compiler pkgdev-lang/luajit/pkg instead of pkgdev-lang/lua/pkg How about we figure out how to handle multiple versions and interpreters sanely instead? Not that I mind USE=luajit but I do mind the huge conditionals with random USE flags like recently suggested for neovim. That would be great going forward. But at this point it's a non-issue. There is a choice between lua-5.1 and luajit. Other lua versions have been masked since like forever. And I don't see that situation changing anytime soon. Or maybe one of the other lua package maintainers has plans? -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Re: Fonts project meeting and elections
On 28 February 2015 at 00:26, Guilherme Amadio ama...@gentoo.org wrote: On Fri, Feb 27, 2015 at 03:45:23PM +0800, Ben de Groot wrote: 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'm listed, but why can I not edit the page? I'd like to be able to. You need to contact a...@gentoo.org to give you developer status on the wiki. 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 Both this and the use expand suggested by Luca seem good methods. I also suggest we prefer OpenType over TrueType whenever possible. We need to get an addition to the eclass whipped up then, for use expand handling. 4. Project member should have a look at font bugs. https://bugs.gentoo.org/buglist.cgi?quicksearch=media-fonts has a lot of low hanging fruit: version bumps, dead homepages, etc. Also some good new packages. I've seen a few of those and suggested webpages for a couple of them. I can go fix some of these if nobody else does. Please do. 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)? Since this is mostly used for web developers, I recommend to leave it off for desktop users, but possibly on for servers, for example. If we do the use expand, we should leave it up for users to set. I suggest we default to only otf, if there is a choice. Other formats should not be installed by default, unless it's the only option for that package. Anything else you want to discuss? I'd like to suggest that we do not name new font packages font-*, but simply by the name of the typeface, such as open-sans, source-pro, etc. I totally agree. I would also like to prevent format suffixes, such as in ttf-bitstream-vera. And I would also like just lowercase package names. I think all font-* packages we have in the tree are X.org shipped bitmap fonts. It's a useful indication for most users to ignore these. There is Source Serif, Source Sans, and Source Han Sans that are not packaged yet (see https://github.com/adobe-fonts for more info), We do have media-fonts/source-pro, and I am planning on bumping that package, as per bug #429780. I am hesitant to include the Han font tho, since it is a 700+ MB download that may catch users unawares. as well as many other nice and well-known typefaces and icon fonts such as Aller, Amble, Casper, Clear Sans, Entypo, Font Awesome, Signika, Comic Neue, Fira, Nexa, Exo, Nobile, Open Sans, etc. Some of those are on my to-do list already, but feel free to add others. There is also the really nice Input (http://input.fontbureau.com), but its license is only free for personal use, so we may need to talk to its designer to see if we can package it at all. I'm using it on my laptop, and it's a pleasure to read and very customizable. The non-redistributable license is a problem. That's why I have chosen not to include Envy R (which is somewhat popular for coding too). Adding fonts with fetch restrictions seem counter-productive to me. Users can simply download them for themselves and drop them in ~/.fonts/. Well, maybe opening a #gentoo-fonts on IRC will be a nice way to coordinate our efforts. I don't think there will be that much to discuss on an ongoing basis wrt fonts that it warrants a new channel. Let's keep it in #gentoo-desktop for now, and see if we actually need a dedicated channel. Also, this is definitely a minor thing, but all designers prefer the term typeface to font when referring to typefaces, so they'd probably be happy if media-fonts became media-type, or something similar. The distinction is that the set of fonts (regular, light, bold, condensed, etc) is what makes a typeface, which is the general style of all fonts in the set. Anyway, just food for thought. I am aware of this, but the usage of fonts is so ingrained in the popular mind, and it's a minor mistake at worst. I don't think it is worth going thru the trouble of renaming the category (and fixing all revdeps) for. We could use typeface in descriptions tho. Finally, I would like to bring up fontconfig-ultimate [1] with a user provided ebuild [2] and some discussion on the forums [3]. There are also many fixed fonts available, packaged for Arch Linux [4]. There is some user demand for this, so I think we should package it. I haven't yet taken the time to do so (too much other stuff going on). What are your thoughts? 1: https://github.com/bohoomil
Re: [gentoo-dev] Re: Fonts project meeting and elections
On 27 February 2015 at 18:34, Peter Stuge pe...@stuge.se wrote: Ben de Groot wrote: 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 So if I first USE=-opentype and later USE=opentype the filenames would change even though the fonts are actually the same. Do you know that no software packages will get horribly confused by that, and end up doing silly things such as listing each font twice? So what are you suggesting? -- Cheers, Ben | yngwin Gentoo developer
[gentoo-dev] Re: Fonts project meeting and elections
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 2. Since aballier voted for me, and there were no other nominations, we default to me becoming the lead. 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 4. Project member should have a look at font bugs. https://bugs.gentoo.org/buglist.cgi?quicksearch=media-fonts has a lot of low hanging fruit: version bumps, dead homepages, etc. Also some good new packages. 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)? Anything else you want to discuss? -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] why is a line in /usr/portage/profiles/base/package.use.mask ignored?
On Wed, Feb 25, 2015 at 5:23 AM, gro...@gentoo.org wrote: Hello *, dev-lisp/ecls-15.2.21 does not compiled with USE=cpu_flags_x86_sse. So, I've added the line =dev-lisp/ecls-15.2.21 cpu_flags_x86_sse to .../profiles/base/package.use.mask. But I still see dns ~ # emerge -pv dev-lisp/ecls [ebuild R] dev-lisp/ecls-15.2.21:0/15.2.21::gentoo [15.2.21:0/15.2.21::grozin] USE=X emacs libatomic%* threads unicode -debug -gengc -precisegc CPU_FLAGS_X86=sse* 0 KiB Why isn't sse masked? Andrey This is because these cpu_flags_x86_* flags are masked globally in profiles/base/use.mask then unmasked where they're valid, like in profiles/arch/amd64/use.mask. So that later (global) unmask overrides your package-specific mask in the base profile. If you add your package.use.mask entry in profiles/arch/amd64/package.use.mask then I believe it should work. -Ben
Re: [gentoo-dev] do we need special elog messages for bindist?
On Wed, Feb 25, 2015 at 1:38 PM, Mike Gilbert flop...@gentoo.org wrote: I would like to remove the elog for a couple of reasons: 1. The use flag description is there for whoever cares to read it. There is no need to alert the user every time. 2. We are not lawyers, and I have no business giving legal advice about patent law which varies from country to country. To take it one step further: I think it would make more sense to call the flag h264 or something similar. We could then set RESTRICT=h264? ( bindist ) if we want to give some indication that it is not appropriate for binary redistribution. What you're saying here makes sense and I agree, but our users are already pretty confused about USE=bindist... what it does, why it's enabled by default, etc. If this is going to stay enabled by default in our stage3s (there's an open bug about possibly changing that) then I really think we should add a paragraph to the handbook that explains things. It seems that most new users don't have any idea what bindist is until they find some feature missing or they hit the classic openssl/openssh blocker and someone has to explain the whole thing to them. So in summary, let's get rid of the per-ebuild einfo warnings but let's educate the users about USE=bindist earlier. -Ben
Re: [gentoo-dev] [PATCH] qmake-utils.eclass: add qt{4,5}_get_bindir helper functions
On 20 February 2015 at 04:06, Jeroen Roovers j...@gentoo.org wrote: On Wed, 18 Feb 2015 19:58:29 +0800 Ben de Groot yng...@gentoo.org wrote: The attached patch proposes two helper functions to be added to qmake-utils.eclass. These functions echo the correct directory where qt binaries such as moc and lrelease are located. They can be used in ebuilds when such binaries need to be called directly. (Ebuilds should not rely on qtchooser for this.) Please review before I commit. Looks good (barring what Davide noted). Do you have a list of ebuilds that might benefit? I know net-analyzer/wireshark might, but it doesn't even use qmake-utils.eclass right now simply because it doesn't use qmake (but it does use moc and uic, so I wouldn't expect to find those functions in an eclass seemingly about qmake). Committed, with improvements by Davide. Based on a quick qgrep for lrelease/moc/uic, packages that would benefit are: app-cdr/qpxtool app-crypt/pinentry app-editors/znotes app-text/diffpdf app-text/qpdfview dev-util/universalindentgui games-board/qgo games-emulation/higan games-kids/cubetest games-util/higan-purify media-sound/lastfmplayer media-sound/musescore media-video/smplayer media-video/videocut media-video/vlc media-video/xvideoservicethief net-analyzer/wireshark net-im/psi net-im/skype net-p2p/transmission sci-calculators/speedcrunch sci-geosciences/gpsbabel sci-geosciences/merkaartor sci-visualization/qtiplot/ sys-boot/unetbootin -- Cheers, Ben | yngwin Gentoo developer
[gentoo-dev] [RFC] luajit global useflag
% quse -D luajit local:luajit:app-editors/gvim: Use dev-lang/luajit instead of dev-lang/lua local:luajit:app-editors/vim: Use dev-lang/luajit instead of dev-lang/lua local:luajit:app-editors/vim-qt: Use dev-lang/luajit instead of dev-lang/lua local:luajit:games-action/minetest: Use dev-lang/luajit instead of dev-lang/lua local:luajit:games-engines/solarus: Use LuaJIT instead of default Lua. local:luajit:games-roguelike/stone-soup: Use dev-lang/luajit as scripting backend instead of dev-lang/lua. local:luajit:media-sound/csound: Use the lua just-in-time compiler dev-lang/luajit instead of dev-lang/lua local:luajit:media-video/mpv: Use dev-lang/luajit instead of dev-lang/lua local:luajit:www-client/luakit: Use the lua just-in-time compiler dev-lang/luajit instead of dev-lang/lua, which should make luakit faster. local:luajit:www-servers/nginx: Use dev-lang/luajit instead of dev-lang/lua for lua support when building the lua http module. I propose we make luajit a global useflag, using the description from media-sound/csound: Use the lua just-in-time compiler pkgdev-lang/luajit/pkg instead of pkgdev-lang/lua/pkg -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] [RFC] please review ebuilds for neovim and deps
On 23 February 2015 at 14:17, Vadim A. Misbakh-Soloviov m...@mva.name wrote:
I'd also say:
neovim:
CDEPEND=dev-lang/luajit
...
dev-lua/LuaBitOp
1) I'm not sure luajit:1 fits the dep
2) LuaJIT:2 has it's own bit modules and is unneded LuaBitOp
Thanks! I don't know that much about lua, so this is very helpful.
Unibilium:
1.1.2 made a day ago. Bump, please ;)
Already on it.
lua-MessagePack:
RDEPEND==dev-lang/lua-5.1
And what about LuaJIT? Huh?
Yeah, but I just followed what I found upstream.
Also, I've it in lua overlay, called dev-lua/messagepack, though. Naming can
be discussed.
I don't mind either way. But again, I just followed upstream.
But main point is:
RDEPEND=
!luajit? (
!lua53? (
|| (
=dev-lang/lua-5.1*
=dev-lang/lua-5.2*
)
)
lua53? ( =dev-lang/lua-5.3* )
)
luajit? ( dev-lang/luajit:2 )
...
src_install() {
local lua=lua
use luajit lua=luajit
insinto $($(tc-getPKG_CONFIG) --variable INSTALL_LMOD ${lua})
if use lua53; then
doins src5.3/MessagePack.lua
else
doins src/MessagePack.lua
fi
}
Thanks. But I think we can simplify that for now, since lua53 isn't
available (neither in the official tree or the lua overlay) and
=lua-5.2 is hardmasked.
--
Cheers,
Ben | yngwin
Gentoo developer
Re: [gentoo-dev] [RFC] please review ebuilds for neovim and deps
On 23 February 2015 at 01:39, William Hubbs willi...@gentoo.org wrote:
On Sat, Feb 21, 2015 at 09:18:08AM +0100, Michał Górny wrote:
neovim:
# Copyright 1999-2015 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
EAPI=5
inherit cmake-utils flag-o-matic
DESCRIPTION=Vim's rebirth for the 21st century
HOMEPAGE=https://github.com/neovim/neovim;
if [[ ${PV} == ]]; then
inherit git-r3
EGIT_REPO_URI=git://github.com/neovim/neovim.git
KEYWORDS=
else
inherit vcs-snapshot
COMMIT=8efb3607a7f6cefce450953c7f8d5e3299347bae
SRC_URI=https://github.com/${PN}/${PN}/tarball/${COMMIT} -
${P}.tar.gz
I don't think relying on stability of generated tarballs is a good
idea. The same applies to almost all other ebuilds.
If the tarball is based on an upstream tag, you should be fine, but this
does not work for a commit hash like what is being used here.
For more info on this, check out the man page for git archive. In
particular, how it handles timestamps inside the tarball.
In a nutshell, if you use git archive to create a tarball based on a
commit hash, the time stamps of the files inside the tarball are
different each time you create it, but this is not true if the tarball
is based on an upstream tag.
William
Thanks for the explanation! I'll roll tarballs then for our use until
upstream does tags or releases.
--
Cheers,
Ben | yngwin
Gentoo developer
Re: [gentoo-dev] Fonts project meeting and elections
On 22 February 2015 at 23:27, Guilherme Amadio ama...@gentoo.org wrote: Hello, On Sun, Feb 22, 2015 at 03:43:33AM +0800, 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. There hasn't been much activity in the fonts area of Gentoo, and our lead seems to be MIA. The main points on the agenda: 1. Who wants to be member of the Fonts project, and help out? 2. Members to elect a new lead. I'm nominating myself. 3. Make a plan for dealing with open bugs 4. Open floor Yes, I would like to be part of the team. I was thinking about creating a Typography project, but if there is already a Fonts project, it will work just as well. I won't nominate myself as a lead, since I just became a Gentoo dev, but I do want to help. I will show up to the meeting. Welcome to the team! -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Hello Everyone
On 22 February 2015 at 20:05, Tushar Rajput tushra...@gmail.com wrote: I am novice programmer and wants to contribute to gentoo.Can you give me some details? Thanks We actually have a wiki page that does: https://wiki.gentoo.org/wiki/Contributing_to_Gentoo -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Fonts project meeting and elections
On 22 February 2015 at 17:52, Alexis Ballier aball...@gentoo.org wrote: Hi Ben, On Sun, 22 Feb 2015 03:43:33 +0800 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. [...] The main points on the agenda: 1. Who wants to be member of the Fonts project, and help out? 2. Members to elect a new lead. I'm nominating myself. I've been on the alias and maintaining a few fonts (or rather, fonts/tex) packages for a while now, whatever that means. I won't be able to attend the meeting, but considering you've been the (only?) one doing most of the work on fonts side recently, count my vote approval for you being the lead. Alexis. Thanks and welcome to the team! -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] [RFC] please review ebuilds for neovim and deps
SLOT=0
KEYWORDS=~amd64 ~x86
IUSE=
DEPEND==dev-python/click-3.0
=dev-python/msgpack-0.4.0
!python_targets_pypy? ( dev-python/greenlet )
!python_targets_python3_4? ( dev-python/trollius )
What?! What are those negative deps supposed to mean?
We need pypy OR greenlet, and python-3.4 OR trollius. This was the
simplest way I saw to express that.
I'm pretty sure you meant:
$(python_gen_cond_dep 'python*' 'dev-python/greenlet[${PYTHON_USEDEP}]')
$(python_gen_cond_dep python{2_7,3_2,3_3} 'pypy*'
'dev-python/trollius[${PYTHON_USEDEP}]')
Hmm, black magic?! Tasty!
After perusing the grimoire--I mean eclass--I get the idea. Thanks for the hint!
RDEPEND=${DEPEND}
S=${WORKDIR}/${P/neovim-/}
--
Best regards,
Michał Górny
Thanks for reviewing!
--
Cheers,
Ben | yngwin
Gentoo developer
[gentoo-dev] Fonts project meeting and elections
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. There hasn't been much activity in the fonts area of Gentoo, and our lead seems to be MIA. The main points on the agenda: 1. Who wants to be member of the Fonts project, and help out? 2. Members to elect a new lead. I'm nominating myself. 3. Make a plan for dealing with open bugs 4. Open floor -- Cheers, Ben | yngwin Gentoo developer
[gentoo-dev] Fonts project meeting and elections
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. There hasn't been much activity in the fonts area of Gentoo, and our lead seems to be MIA. The main points on the agenda: 1. Who wants to be member of the Fonts project, and help out? 2. Members to elect a new lead. I'm nominating myself. 3. Make a plan for dealing with open bugs 4. Open floor -- Cheers, Ben | yngwin Gentoo developer
[gentoo-dev] Last rites: media-fonts/culmus-ancient
# Ben de Groot yng...@gentoo.org (21 Feb 2015) # Duplicates media-fonts/culmus[ancient] (bug #486814). # Masked for removal in 30 days. media-fonts/culmus-ancient -- Cheers, Ben | yngwin Gentoo developer
[gentoo-dev] [RFC] please review ebuilds for neovim and deps
At the suggestion of radhermit, I'm putting my neovim deps ebuilds up here for review, before I commit them to the official tree. Do you see any possible improvements? Right now the neovim ebuild does not install any global default nvimrc like we do with vim. We should probably consider doing so. Also, I'm looking for the best way to let neovim use the vim plugins we install in $VIMRUNTIME (such as gentoo-syntax). The ebuilds are available in my personal dev overlay, and I'm attaching them to this mail. -- Cheers, Ben | yngwin Gentoo developer neovim-0.0.0_pre20150220.ebuild Description: Binary data libtermkey-0.17.ebuild Description: Binary data msgpack-0.6.0_pre20150220.ebuild Description: Binary data unibilium-1.1.1.ebuild Description: Binary data lua-MessagePack-0.3.2.ebuild Description: Binary data neovim-python-client-0.0.28.ebuild Description: Binary data trollius-1.0.4.ebuild Description: Binary data
[gentoo-dev] [PATCH] qmake-utils.eclass: add qt{4,5}_get_bindir helper functions
The attached patch proposes two helper functions to be added to
qmake-utils.eclass. These functions echo the correct directory where
qt binaries such as moc and lrelease are located. They can be used in
ebuilds when such binaries need to be called directly. (Ebuilds should
not rely on qtchooser for this.)
Please review before I commit.
--
Cheers,
Ben | yngwin
Gentoo developer
--- gentoo-x86/eclass/qmake-utils.eclass 2014-11-22 11:04:23.765870730 +0800
+++ overlay/qt/eclass/qmake-utils.eclass 2015-02-11 23:10:51.067484243 +0800
@@ -51,6 +51,25 @@
esac
}
+# @FUNCTION qt4_get_bindir
+# @DESCRIPTION:
+# Get the correct location of Qt4's installed binaries.
+qt4_get_bindir() {
+ local qtbindir=${EPREFIX}/usr/$(get_libdir)/qt4/bin
+ if [[ -x ${qtbindir} ]]; then
+ echo ${qtbindir}
+ else
+ echo ${EPREFIX}/usr/bin
+ fi
+}
+
+# @FUNCTION qt5_get_bindir
+# @DESCRIPTION:
+# Get the correct location of Qt5's installed binaries.
+qt5_get_bindir() {
+ echo ${EPREFIX}/usr/$(get_libdir)/qt5/bin
+}
+
# @VARIABLE: EQMAKE4_EXCLUDE
# @DEFAULT_UNSET
# @DESCRIPTION:
@@ -158,11 +177,7 @@
[[ -n ${EQMAKE4_EXCLUDE} ]] eshopts_pop
- # determine qmake binary location
- local qmake_path=${EPREFIX}/usr/$(get_libdir)/qt4/bin/qmake
- [[ ! -x ${qmake_path} ]] qmake_path=${EPREFIX}/usr/bin/qmake
-
- ${qmake_path} \
+ $(qt4_get_bindir)/qmake \
-makefile \
QMAKE_AR=$(tc-getAR) cqs \
QMAKE_CC=$(tc-getCC) \
@@ -213,7 +228,7 @@
ebegin Running qmake
- ${EPREFIX}/usr/$(get_libdir)/qt5/bin/qmake \
+ $(qt5_get_bindir)/qmake \
-makefile \
QMAKE_AR=$(tc-getAR) cqs \
QMAKE_CC=$(tc-getCC) \
Re: [gentoo-dev] ffmpeg vs libav choice of default
On 4 February 2015 at 17:26, Alexis Ballier aball...@gentoo.org wrote: On Wed, 4 Feb 2015 10:12:12 +0100 Ulrich Mueller u...@gentoo.org wrote: With the recent introduction of the libav USE flag, the Gentoo default for ffmpeg vs libav is more pronounced than it was before (with libav being listed first in || ( ) dependencies). In the replies to http://forums.gentoo.org/viewtopic.php?p=7694982 several users have expressed their preference for ffmpeg. So can someone please remind me what are the technical reasons why we prefer libav over ffmpeg? good luck ! wait for other opinions, but I'd say: libav has a cleaner codebase and stricter development rules. (NB: some gentoo devs are member of the core libav dev team) IMHO, from a pure consumer POV where I want to play a random video and my programs using the libraries not to break, ffmpeg is much better (more codecs get in faster, API is preserved a bit longer), so I never understood nor agreed with that choice of default. I think for our users the latter is more important. After all the discussion we had here and on the forums, I propose we change the default to ffmpeg. Thoughts? -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Git mirror news: travis-ci running repoman, git-cvs merge revert tools
On 8 February 2015 at 18:38, Michał Górny mgo...@gentoo.org wrote: Hello, everyone. I would like to announce that our little rsync-git band-aid mirror [1] is doing fine and we're actively working towards improving Gentoo development experience. First of all, we have enabled tree-wide repoman scans using travis-ci [2]. Besides providing regularly updated repository state report, it can be used to scan Pull Requests for tree-wide damage :). Asides from the benefit to external contributors, Gentoo developers can use it to avoid having to run repoman locally. For example, if you are doing a big old version cleanup, do it in git and submit a Pull Request, and travis will figure out if you don't break any revdeps. Secondly, I have committed app-portage/lightweight-cvs-toolkit for your committing pleasure. It consists of three tools: a. lcvs-init -- that can be used to quickly create partial CVS checkout, having only pure categories checked out. The repository is set to use 'gentoo' as master, so you can easily commit into CVS while keeping the dependencies, eclasses and profiles synced to your regular rsync/git checkout (with working cache!). The idea is explained more thoroughly on the wiki [3] and in the script output. b. lcvs-merge-pr -- a convenient tool to merge github PR (or any git patch) into your CVS checkout. It 'cvs up -dP' directories as necessary, git-applies the patch omitting ChangeLogs and Manifests, calls cvs add/cvs rm as appropriate. All you have to do is update the ChangeLog and commit :). More about merging on the wiki [4]. c. lcvs-revert -- a convenient tool to revert commits. Pretty much the idea is: someone breaks something e.g. by removing ebuilds, and you want to revert that. Instead of playing all the fancy 'cvs add' magic, you just find the matching git commit and lcvs-revert it. Using logic similar to lcvs-merge-pr, it fetches the diff and reverse-applies it. Then you check if everything went fine, ChangeLog and commit :). More info on the wiki [5] as well. Thanks to all the people that helped me get this running, and have fun :). [1]:https://github.com/gentoo/gentoo-portage-rsync-mirror [2]:https://travis-ci.org/gentoo/gentoo-portage-rsync-mirror [3]:https://wiki.gentoo.org/wiki/Lightweight_CVS_Checkout [4]:https://wiki.gentoo.org/wiki/Project:Git_mirror/Merging_Pull_Requests [5]:https://wiki.gentoo.org/wiki/Project:Git_mirror/Reverting_Gentoo_commits Thank you! This looks really useful. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog
On 7 February 2015 at 23:06, hasufell hasuf...@gentoo.org wrote:
DEPEND=
unzip is missing from DEPEND
I thought portage auto-depends on this. But I can add || ( unzip zip )
to be explicit.
I don't know, but it's definitely not in @system. Afair we are only
allowed to omit deps from that set.
OK, added.
src_compile() {
local my_arch
use x86 my_arch=x86-32-old
use cpu_flags_x86_sse my_arch=x86-32
use amd64 my_arch=x86-64
use cpu_flags_x86_popcnt my_arch=x86-64-modern
use cpu_flags_x86_avx2 my_arch=x86-64-bmi2
emake build ARCH=${my_arch} CXX=$(tc-getCXX) CXXFLAGS=${CXXFLAGS}
This currently breaks all cpu flags, because it overwrites anything the
Makefile does to CXXFLAGS, including -msse and -DIS_64BIT and even other
flags that are not CPU specific (e.g. -DNDEBUG).
Thanks for catching this! I guess we do need to patch the Makefile
then, to *also* honour user-set CXXFLAGS and LDFLAGS. Or could we get
away with just letting the Makefile do its thing?
I've hit this bug myself in my overlay... I'll probably get up a pull
request upstream today.
I think it's okay now. They do += so the user cxxflags and ldflags do
get honoured, but they end their own flags at the end of it. I've
added some more configuration options to the ebuild (optimize and
debug are important here).
--
Cheers,
Ben | yngwin
Gentoo developer
Re: [gentoo-dev] ffmpeg vs libav choice of default
On 7 February 2015 at 07:03, Jason A. Donenfeld zx...@gentoo.org wrote: Welp, the votes clearly show ffmpeg is desired by users. Can we stop this nonsense and just do that? The people have spoken. Ffmpeg shall be default. Except Gentoo is not a democracy. It is still important data to take into consideration tho. -- Cheers, Ben | yngwin Gentoo developer
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog
On 7 February 2015 at 00:59, hasufell hasuf...@gentoo.org wrote:
Ben de Groot (yngwin):
yngwin 15/02/05 20:09:33
Added:stockfish-6.ebuild metadata.xml Manifest ChangeLog
Log:
Initial commit (bug #318337)
First off: thank you for the review!
EAPI=5
inherit toolchain-funcs
This breaks consistency. Now users cannot rely on games.eclass anymore.
We should either abandon it completely or follow it consistently.
I thought we had abandoned it already?
Is there anything to be gained from using games.eclass here? It is a
chess engine that simply installs one file in /usr/bin/.
DESCRIPTION=The strongest chess engine in the world
This isn't very informative. I'd suggest
DESCRIPTION=Free UCI chess engine derived from Glaurung 2.1
I just took the description from upstream's website. But you are
right, it could be more informative. Will fix.
HOMEPAGE=http://stockfishchess.org/;
Probably add the github link here too.
I will unify the live and release ebuilds.
SRC_URI=https://stockfish.s3.amazonaws.com/${P}-src.zip;
LICENSE=GPL-3
SLOT=0
KEYWORDS=~amd64 ~x86
IUSE=cpu_flags_x86_avx2 cpu_flags_x86_popcnt cpu_flags_x86_sse
DEPEND=
unzip is missing from DEPEND
I thought portage auto-depends on this. But I can add || ( unzip zip )
to be explicit.
RDEPEND=
S=${WORKDIR}/${P}-src/src
src_prepare() {
sed -e 's:-strip $(BINDIR)/$(EXE)::' -i Makefile
}
missing || die... I'd also rather make this a patch, so it doesn't
silently break on version bump
The die would not accomplish anything, unless the file wasn't there
anymore. I thought this was too simple for a patch, but see below.
src_compile() {
local my_arch
use x86 my_arch=x86-32-old
use cpu_flags_x86_sse my_arch=x86-32
use amd64 my_arch=x86-64
use cpu_flags_x86_popcnt my_arch=x86-64-modern
use cpu_flags_x86_avx2 my_arch=x86-64-bmi2
emake build ARCH=${my_arch} CXX=$(tc-getCXX) CXXFLAGS=${CXXFLAGS}
This currently breaks all cpu flags, because it overwrites anything the
Makefile does to CXXFLAGS, including -msse and -DIS_64BIT and even other
flags that are not CPU specific (e.g. -DNDEBUG).
Thanks for catching this! I guess we do need to patch the Makefile
then, to *also* honour user-set CXXFLAGS and LDFLAGS. Or could we get
away with just letting the Makefile do its thing?
Fixing this should definitely be done in a revbump.
Obviously. Will do.
--
Cheers,
Ben | yngwin
Gentoo developer
Re: [gentoo-dev] Re: ffmpeg vs libav choice of default
On 7 February 2015 at 10:08, Mike Auty ike...@gentoo.org wrote: [...] I was concerned that a warning which had been in place in package.mask since September was removed by a different developer than the one who put it in place, I discussed this beforehand with said developer on IRC. and that a package was unmasked (while a USE flag was masked) which then forced everyone who read the portage news article and swapped mplayer to mpv based on the article, to then be told they have to rebuild with ffmpeg after all, and potentially rebuild a lot of other packages because of that. I was not aware of mpv upstream preference for ffmpeg when that news item was written, or I would have brought up that issue. You are right that the resulting situation is more confusing than it should be. Maybe I should have insisted on a news item, even tho maksbotan didn't think that was necessary. Do you think a news item to explain this situation and giving explicit instructions for users who wish to stay with libav would be useful? The mask of the USE flag even removed the possibility of building the newer mpv with libav No. Users can unmask the useflag and build mpv with libav if they wish. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] ffmpeg vs libav choice of default
On 6 February 2015 at 00:20, hasufell hasuf...@gentoo.org wrote: Ben de Groot: On 4 February 2015 at 21:49, Chí-Thanh Christopher Nguyễn chith...@gentoo.org wrote: Ulrich Mueller schrieb: In the replies to http://forums.gentoo.org/viewtopic.php?p=7694982 several users have expressed their preference for ffmpeg. To help finding out what users actually think, I added a poll to the forum to ask them about their preference. https://forums.gentoo.org/viewtopic-t-1010096.html They seem pretty strongly in favour of changing the default back to ffmpeg: https://forums.gentoo.org/viewtopic-t-1010096-postdays-0-postorder-asc-vote-viewresult.html 57% is not pretty strongly. It's a bit more than the half. If we add up the votes to a simpler overview, we get at this point: ffmpeg 66.4% libav8.2% don't care 24.0% other1.4% I think that's pretty clear. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] ffmpeg vs libav choice of default
On 4 February 2015 at 20:43, Mike Auty ike...@gentoo.org wrote: Whilst the default *is* still in place (and particularly after the recent news article detailing that users should be using libav), could we please keep commits like the following until *after* we've made an agreed upon decision please? http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/profiles/package.mask?r1=1.16328r2=1.16329 Anyone using mpv (because mplayer does not work with libav, and they were directed to use mpv by the news article) will now be hit by blockers attempting to reinstall ffmpeg. It's fine to have disagreements, but airing them in front of the users like this is not an ideal situation... That would suggest political motives or something of the sort. But that is far from the truth. Newer mpv versions were masked for many months, for no apparently valid reason, except that the libav versions on which it optionally (!) depended were masked. Since we introduced the libav useflag, we have now a way to finally make mpv-0.7* (using the upstream recommended ffmpeg as default) visible to ~arch users, without the need to unmask it. Users who wish to use libav with it, can do so by unmasking the useflag and the relevant libav version. (While before they would have had to unmask both mpv and libav. The resulting change is minor.) Fewer users will now need to unmask mpv-0.7*. Besides, it is a reminder that upstream recommends ffmpeg, which comes as a surprise to many. And as a result, we can unmask the newest version of smplayer, which can now function as a GUI frontend for mpv as well. I would say this is an overall improvement for our end-users. I don't want to get into the politics of it, but just look at it from a practical perspective. -- Cheers, Ben | yngwin Gentoo developer
