>>>>> On Sun, 07 Jan 2024, Michał Górny wrote:
> On Sun, 2024-01-07 at 17:58 +0100, Ulrich Mueller wrote:
>> I cannot really see a delineation between app-text and [dev]-doc.
>>
>> For example, packages like psmark, xmlto, or even texi2html are general
>>
> On Wed, 10 Jan 2024, Florian Schmaus wrote:
> On 10/01/2024 12.04, Sam James wrote:
>> 1) The name seems odd (why not readme.gentoo-r2)?
>> 2) Why can't the existing eclass be improved?
> Both points, the name of the eclass and the question if this should be
> added to the existing eclass o
>>>>> On Wed, 10 Jan 2024, Florian Schmaus wrote:
> On 10/01/2024 14.58, Ulrich Mueller wrote:
>> Looks like readme.gentoo-r1 already gives you control over this:
>> # If you want to show them always, please set FORCE_PRINT_ELOG to a non empty
>> # value in
> On Tue, 16 Jan 2024, Florian Schmaus wrote:
> case ${EAPI} in
> - 7) inherit eapi8-dosym ;;
> + 7)
> + inherit eapi8-dosym
> + dosym(){ dosym8 "$@"; }
For good reason, eapi-dosym.eclass doesn't override package manager
commands, and the texlive eclasses shou
# Ulrich Müller (2024-01-30)
# SLOT 25 of app-editors/emacs, corresponding to GNU Emacs version 25.3.
# This version was released in May 2018. Please upgrade to >=emacs-26
# and update your Emacs Lisp packages with emacs-updater.
# Removal on 2024-02-29. Bug #923329.
app-editors/emacs:25
signatu
> On Wed, 31 Jan 2024, Andreas Fink wrote:
> With the move of sys-devel/autoconf to dev-build/autoconf the ebuild
> has some inconsistency, namely in the RDEPEND section, it is saying:
> RDEPEND="
> ${BDEPEND}
>> =dev-build/autoconf-wrapper-20231224
> sys-devel/gnuconfig
>
> On Sat, 03 Feb 2024, Maciej Barć wrote:
> -if [[ ${CATEGORY}/${PN} != dev-dotnet/dotnet-runtime-nugets ]] ; then
> +if [[ "${CATEGORY}/${PN}" != dev-dotnet/dotnet-runtime-nugets ]] ; then
These quotes are not necessary.
> - if [[ ${CATEGORY}/${PN} != dev-dotnet/csharp-gentoodotnetinfo
> On Sat, 03 Feb 2024, Maciej Barć wrote:
> +# @FUNCTION: dotnet-pkg-base_restore_tools
> +# @USAGE: [config-file] [args] ...
> +# @DESCRIPTION:
> +# DEPRECATED, use "dotnet-pkg-base_restore_tools" instead.
Should be a hyphen here (...restore-tools), I guess?
> On Sat, 03 Feb 2024, Maciej Barć wrote:
> +dotnet-pkg_force-compat() {
> + if [[ -z "${DOTNET_PKG_COMPAT}" ]] ; then
Quotes are not needed.
> On Sat, 03 Feb 2024, Maciej Barć wrote:
> + find "$(pwd)" -maxdepth 1 -iname "nuget.config" -delete ||
Is there any special reason for using "$(pwd)" instead of . here?
> + case "${1}" in
Quotes not needed.
> + if [[ -d "${1}" ]] ; then
Quotes not needed.
> On Sat, 10 Feb 2024, Daniel Simionato wrote:
> I'd like to start a discussion regarding setting HOME_MODE by default in
> the /etc/login.defs file (owned by sys-apps/shadow package).
> Upstream keeps HOME_MODE commented:
> https://github.com/shadow-maint/shadow/blob/3e59e9613ec40c51c19c7bb
> On Wed, 14 Feb 2024, Michał Górny wrote:
> The following packages are now looking for a new maintainer, due to
> their prior maintainer being inactive:
> sys-firmware/iwl3160-7260-bt-ucode
> sys-firmware/iwl3160-ucode
> sys-firmware/iwl7260-ucode
These should be treecleaned, because sys-ke
> On Mon, 26 Feb 2024, Andrew Nowa Ammerlaan wrote:
> Title: installkernel is no longer implicitly installed
> Author: Andrew Ammerlaan
> Posted: 2024-02-26
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Installed: sys-kernel/installkernel
> Display-If-Installed: >=sys-apps/debianutils-5.
> On Tue, 27 Feb 2024, Rich Freeman wrote:
> On Tue, Feb 27, 2024 at 9:45 AM Michał Górny wrote:
>>
>> Given the recent spread of the "AI" bubble, I think we really need to
>> look into formally addressing the related concerns.
First of all, I fully support mgorny's proposal.
>> 1. Copyrig
> On Wed, 28 Feb 2024, Michał Górny wrote:
> On Tue, 2024-02-27 at 21:05 -0600, Oskari Pirhonen wrote:
>> What about cases where someone, say, doesn't have an excellent grasp of
>> English and decides to use, for example, ChatGPT to aid in writing
>> documentation/comments (not code) and puts
> On Thu, 29 Feb 2024, Michał Górny wrote:
>> +"${EPREFIX}"/usr/bin/fmtutil-sys --all &> /dev/null \
>> +|| die -n "fmtutil-sys returned non-zero exit
>> status ${res}"
> Put '||' at end of the line, then you won't need the redundant
> backslas
> On Thu, 29 Feb 2024, Florian Schmaus wrote:
> @@ -178,6 +178,10 @@ etexmf-update() {
> if has_version 'app-text/texlive-core' ; then
> if [[ -z ${ROOT} && -x "${EPREFIX}"/usr/sbin/texmf-update ]] ;
> then
> "${EPREFIX}"/usr/sbin/texmf-update
> +
>>>>> On Fri, 01 Mar 2024, Florian Schmaus wrote:
> On 29/02/2024 21.40, Ulrich Mueller wrote:
>>>>>>> On Thu, 29 Feb 2024, Florian Schmaus wrote:
>>
>>> @@ -178,6 +178,10 @@ etexmf-update() {
>>> if has_version 'app-text/t
# Ulrich Müller (2024-03-06)
# Inactive upstream maintainer. Needs porting to PEP 517 (or better,
# from Python to Emacs Lisp) and from layman to repository.eselect.
# Removal on 2024-05-05. Bug #909887, #909890.
app-portage/g-sorcery
app-portage/gs-elpa
signature.asc
Description: PGP signature
> On Tue, 02 Apr 2024, Florian Schmaus wrote:
> + # If we are updating this package, then there is no need to update
> + # the tlpdb in postrm, as it will be again updated in postinst.
> + [[ -n ${REPLACING_VERSIONS} && ${EBUILD_PHASE} == postrm ]] && return
Sorry for having misse
> On Sat, 06 Apr 2024, Eddie Chapman wrote:
> [...] this is ridiculous and unnecessary :-).
Indeed.
SCNR,
Ulrich
eutils.eclass is no longer used by any ebuild in the Gentoo repository.
Removal in 60 days, i.e. on 2024-06-08, so overlays will have enough
time to update.
From a1f28063e0ba2192a120d15fd82a2d59ae10c892 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ulrich=20M=C3=BCller?=
Date: Mon, 8 Jan 2024 15:11:
> On Sun, 28 Apr 2024, Florian Schmaus wrote:
> --- a/eclass/texlive-common.eclass
> +++ b/eclass/texlive-common.eclass
> @@ -270,10 +270,18 @@ texlive-common_update_tlpdb() {
> touch "${new_tlpdb}" || die
>
> if [[ -d "${tlpobj}" ]]; then
> - find "${tlpobj}" -maxdept
> On Wed, 01 May 2024, Florian Schmaus wrote:
> + local grep_expressions=()
Declare f as local, too.
> + # Transform texlive_core_man_pages into grep expressions
> + # that will be used to filter out any man page that is
> +
> On Wed, 01 May 2024, Maciej Barć wrote:
> Also no license link. Afaik all contribs are under GPL-2.
That's not entirely correct. The files in the licenses/ directory
aren't, and patches in packages' files/ dirs generally follow the
license of their upstream project.
Ulrich
signature.asc
> On Wed, 01 May 2024, Maciej Barć wrote:
>>> Also no license link. Afaik all contribs are under GPL-2.
>> That's not entirely correct. The files in the licenses/ directory
>> aren't, and patches in packages' files/ dirs generally follow the
>> license of their upstream project.
> See, so it
> On Fri, 03 May 2024, Sam James wrote:
> + case ${EAPI} in
> + 5|6) DEPEND=${GNUCONFIG_DEPEND} ;;
> + *) BDEPEND=${GNUCONFIG_DEPEND} ;;
> + esac
Drop EAPI 5 while at it?
signature.asc
Description: PGP signature
> On Fri, 03 May 2024, James Calligeros wrote:
> +Title: Potentially breaking upgrade - media-video/wireplumber-0.5.2
The title must have 50 chars as a maximum, by GLEP 42. If it is longer,
then it isn't guaranteed that eselect news will display it properly.
> +Author: James Calligeros
> +P
> On Sun, 05 May 2024, Paul Zander wrote:
> +# Copyright 1999-2024 Gentoo Authors
> +# Distributed under the terms of the GNU General Public License v2
No objections to a copyright header, though we probably don't need one
for a short file like this. But make it a realistic starting year sinc
> On Sun, 05 May 2024, Paul Zander wrote:
> indent_size is the width in spaces, we use tabs.
> tab_width would be the tab width in spaces, but there is no reason to
> force this.
The Devmanual says that "each tab represents four spaces" [1,2], and
ebuild-mode implements it so [3]. Maybe it wo
epatch.eclass is no longer used by any ebuild in the Gentoo repository.
(It is inherited by eutils.eclass which is itself slated for removal.)
Removal on 2024-06-08.
From 4bbeea154b6bf6a5ff93a80e83c5c8ee753c282a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ulrich=20M=C3=BCller?=
Date: Wed, 8 May 202
> On Thu, 09 May 2024, Michał Górny wrote:
>> +# it from being changed. The variable is left writable for use in overlays;
>> +# package naming restrictions would prohibit some otherwise-valid usernames.
> You're not following the original style (double spaces).
This is less about style than
> On Sun, 12 May 2024, Hans de Graaff wrote:
> -# @SUPPORTED_EAPIS: 7
> +# @SUPPORTED_EAPIS: 7, 8
No comma there.
signature.asc
Description: PGP signature
> On Mon, 20 May 2024, Florian Schmaus wrote:
> - [[ "${PIPESTATUS[*]}" == "0 "[01]" 0" ]]
> - eend $? || die "error installing man pages"
> + [[ "${pipestatus}" == "0 "[01]" 0" ]]
Quotes around ${pipestatus} are redundant.
> +
> On Wed, 22 May 2024, Mike Gilbert wrote:
> Signed-off-by: Mike Gilbert
> ---
> eclass/verify-sig.eclass | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
> diff --git a/eclass/verify-sig.eclass b/eclass/verify-sig.eclass
> index b74ed78290aa..4d48c9ed8503 100644
> --- a/e
> On Wed, 29 May 2024, Sam James wrote:
> # Sam James (2024-05-29)
> # OpenPGP key of malicious xz co-maintainer. This key is no longer used
> # by any ebuilds in tree. Removal on 2024-06-29.
> # Bug #928134.
> sec-keys/openpgp-keys-jiatan
Just out of interest, by what chain of trust was thi
> On Sun, 02 Jun 2024, Florian Schmaus wrote:
> Note that this changes readme.gentoo-r1.eclass to export phase
> functions when it previously did not.
IMHO that's a very bad idea and will probably break ebuilds that rely
on the current behaviour.
(Also, readme.gentoo.eclass used to export ph
> On Sun, 02 Jun 2024, Florian Schmaus wrote:
> + (
> + insinto "${_GREADME_DOC_DIR}"
> +
> + doins "${_GREADME_TMP_FILE}"
> + cksum --raw "${_GREADME_TMP_FILE}" | newins -
> "${_GREADME_HASH_FILENAME}"
> + assert
> + )
Why do you need
> On Sun, 02 Jun 2024, Eli Schwartz wrote:
> Per the commit message, the old readme and the new readme can have the
> same contents, but be compressed by different compressors on the live
> system vs the image, and/or a compressor with unstable algorithms,
> and/or one that isn't installed at
> On Sun, 02 Jun 2024, Florian Schmaus wrote:
>> IMHO that's a very bad idea and will probably break ebuilds that rely
>> on the current behaviour.
> I pondered about this and its one of the reasons I'd rather start with
> a fresh eclass.
> That said, worst case scenario I could came up with
> On Sun, 02 Jun 2024, Eli Schwartz wrote:
> readme.gentoo-r1.eclass as proposed in this thread is exactly such an
> upstream program (gentoo is the upstream, and gentoo cannot cope with
> compressed files there).
> It strikes me as rules lawyering to use this as an argument against
> the ecl
> On Tue, 04 Jun 2024, Florian Schmaus wrote:
> Both is fine with me.
> That said, many filesystem support inline data. If I am not mistaken,
> then its even enabled by default for xfs (which we recommend in the
> handbook) and btrfs. Also some README.gentoo files become suitable for
> inlini
> On Tue, 04 Jun 2024, Florian Schmaus wrote:
> And yes, "docompress -x README.gentoo" would make the code mch
> simpler.
Go for it then. Apparently it is the lesser evil.
signature.asc
Description: PGP signature
> On Sat, 08 Jun 2024, Michał Górny wrote:
> No ebuilds are using the ltprune.eclass anymore, so I've marked it @DEAD
> for removal.
gnome2.eclass still inherits ltprune, shouldn't this be updated first?
That is, drop EAPI 6 support from gnome2.eclass?
Ulrich
signature.asc
Description: PGP
>>>>> On Sat, 08 Jun 2024, Ulrich Mueller wrote:
> gnome2.eclass still inherits ltprune, shouldn't this be updated first?
> That is, drop EAPI 6 support from gnome2.eclass?
I.e. like this?
From cb1cfe6e9fae160f5934ef490386fd6799123793 Mon Sep 17 00:00:00 2001
Fro
> On Sat, 08 Jun 2024, Ulrich Müller wrote:
> - [[ $# != 1 ]] && die "${FUNCNAME[0]} must receive exactly one argument"
> + [[ $# = 1 ]] || die "${FUNCNAME[0]} must receive exactly one argument"
Ten seconds after hitting send I notice that these should use -eq,
not =. Also elsewhere
> On Thu, 13 Jun 2024, Florian Schmaus wrote:
> +# Copyright 1999-2024 Gentoo Authors
> +# Distributed under the terms of the GNU General Public License v2
> +
> +# @ECLASS: greadme.eclass
> +# @MAINTAINER:
> +# Florian Schmaus
> +# @AUTHOR:
> +# Author: Florian Schmaus
> +# @SUPPORTED_EAPIS
> On Thu, 13 Jun 2024, Florian Schmaus wrote:
>>> +_GREADME_DOC_DIR="usr/share/doc/${PF}"
>> It is somewhat unusual to call insinto or docompress with a relative
>> path. I'd use "/usr/share/doc/${PF}" here.
>>
>>> +_GREADME_REL_PATH="${_GREADME_DOC_DIR}/${_GREADME_FILENAME}"
>> Why must this
>>>>> On Thu, 13 Jun 2024, Ulrich Mueller wrote:
>> +if $append; then
> Please use the conventional coding style, i.e. ${append}.
Or rather, assign the variable to empty or non-empty and test for
[[ -n ${append} ]] instead of executing it as a true or false command
> On Thu, 13 Jun 2024, Michał Górny wrote:
> + "$(tc-getCC)" ${CFLAGS} ${CPPFLAGS} -c -x c - -o /dev/null <<-EOF
> &>/dev/null
IIUC, tc-getCC can return values like "x86_64-pc-linux-gnu-gcc -m32
-mfpmath=sse", so probably you want to lose the quotes there.
Ulrich
signature.asc
Descrip
> On Sun, 16 Jun 2024, Florian Schmaus wrote:
> First, the content of README.gento will only be shown on new
Typo.
> +greadme_pkg_postinst() {
> + debug-print-function ${FUNCNAME} "${@}"
> +
> + if [[ ! -v _GREADME_SHOW ]]; then
> + die "_GREADME_SHOW not set. Did you cal
> On Mon, 17 Jun 2024, Michał Górny wrote:
> I think it would be less confusing to have an optional arg to Closes,
> something like:
> Closes[PKGREMOVED]: ...
Yay, bikeshedding. :) But seriously, since we already have:
Signed-off-by: ... (DCO-1.1)
I'd suggest using similar syntax, i.e.
> On Tue, 18 Jun 2024, Florian Schmaus wrote:
>>> Finally, unlike readme.gentoo-r1.elcass, this eclass does not need
>>> to store the content of the readme in an environment variable. Not
>>> having to store the content in an environment variable reduces the
>>> pollution of the environment (s
> On Tue, 18 Jun 2024, Florian Schmaus wrote:
> Any preference regarding the auto-formatting tool? The
> readme.gentoo-r1.eclass uses fold, but fmt (both are in coreutils)
> would probably also be an option (and has a --uniform-spacing option
> ;)).
readme.gentoo.eclass originally had fmt, bu
> On Wed, 19 Jun 2024, Florian Schmaus wrote:
> -# not getting it automatically formatted by fmt. If empty, it will
> -# rely on fmt for formatting and 'echo -e' options to tweak lines a bit.
> +# not getting it automatically formatted by fold. If empty, it will
> On Wed, 26 Jun 2024, Andrew Nowa Ammerlaan wrote:
> +# @SUPPORTED_EAPIS: 6 7 8
AFAICS, no EAPI 6 ebuild inherits mount-boot, so EAPI 6 could be
dropped?
signature.asc
Description: PGP signature
> On Wed, 26 Jun 2024, Andrew Nowa Ammerlaan wrote:
> --- a/eclass/dist-kernel-utils.eclass
> +++ b/eclass/dist-kernel-utils.eclass
> @@ -26,7 +26,7 @@ case ${EAPI} in
> *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
> esac
>
> -inherit toolchain-funcs
> +inherit mount-boot-util
>>>>> On Thu, 27 Jun 2024, Andrew Nowa Ammerlaan wrote:
> On 27/06/2024 06:00, Ulrich Mueller wrote:
>> AFAICS, no EAPI 6 ebuild inherits mount-boot, so EAPI 6 could be
>> dropped?
> Yes, might as well drop that now. Here's v2:
> +# @FUNCTI
> On Tue, 02 Jul 2024, Ionen Wolkens wrote:
> On a side-note, it was further a no-op for linux-mod-r1 which opted to
> intentionally ignore BUILD_FIXES (variable is currently read by kernel-2
> and linux-mod-r0) and nobody complained.
> If wanted, technically all references of BUILD_FIXES cou
Unused. Removal on 2024-08-08.
signature.asc
Description: PGP signature
> On Tue, 16 Jul 2024, Florian Schmaus wrote:
> Notes:
> - also show readme contents if FEATURES=nodoc
Good. :)
> --- /dev/null
> +++ b/eclass/greadme.eclass
> @@ -0,0 +1,257 @@
> +# Copyright 1999-2024 Gentoo Authors
> +# Distributed under the terms of the GNU General Public License v2
> On Tue, 23 Jul 2024, Florian Schmaus wrote:
>> Having more than one element in REPLACING_VERSIONS is certainly a
>> corner case, but I still wonder about the logic. Shouldn't it be
>> the other way around, i.e. if there is _any_ empty ${_GREADME_SHOW}
>> then there is an identical file insta
> On Sat, 27 Jul 2024, Maciej Barć wrote:
>> app-emacs/scala-mode
> I would be against removing this pkg except that it is true that it
> depends on a Scala interpreter on runtime, very weird design choice.
It is an optional feature which is only needed for running the Scala
interpreter with
> On Sun, 04 Aug 2024, Andreas K Huettel wrote:
> Step 4: Prepare and publish a migration guide for users.
> Right now I assume this will mostly mean "select new profile". However,
> I have no clue how portage reacts when $ARCH changes.
Presumably this will also require eselect to be updated
> On Mon, 19 Aug 2024, Robin H Johnson wrote:
> On Sun, Aug 18, 2024 at 04:20:05PM +, Andrey Grozin wrote:
>> Can anybody with the current mesa try to emerge fricas[doc] and tell us if
>> it works (any lisp will do, probably, sbcl is the most reasonable one; by
>> the way, clozurecl comp
Eclasses that support EAPI 6 only, which is no longer used in the
Gentoo repository.
Removal in 30 days, i.e. on 2024-09-25.
--- a/eclass/eapi7-ver.eclass
+++ b/eclass/eapi7-ver.eclass
@@ -1,6 +1,7 @@
# Copyright 1999-2021 Gentoo Authors
# Distributed under the terms of the GNU General Public L
Unused. Removal in 30 days, i.e. on 2024-09-25.
From 17c11b3d8225ff68bf081488e0285ed117a3c1c6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ulrich=20M=C3=BCller?=
Date: Mon, 26 Aug 2024 14:23:04 +0200
Subject: [PATCH] plasma-mobile.kde.org.eclass: Mark as DEAD
MIME-Version: 1.0
Content-Type: text/plain
> On Tue, 27 Aug 2024, Robin H Johnson wrote:
> We only JUST got rid of the last EAPI6 ebuilds in the main tree.
Note that the council deprecated EAPI 6 on 2021-07-11 and banned it
on 2023-07-11.
> There are overlays that still have EAPI6 ebuilds - and depend on these
> ebuilds.
> When is a
Deprecation of an EAPI should not be deferred forever. This update of
GLEP 83 will allow it after a longer waiting period of 48 months even if
only one newer EAPI would exist at that point.
From a1177143b51a374d0acda06915047b7573203a84 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ulrich=20M=C3=BCller?
Version 2. No material changes, but clarified wording and added an
example. Thanks to robbat2 for his comments.
Patch and full new text of the GLEP are attached below.
From 97fbff191d6b9a896d875f88f303816f7804a768 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ulrich=20M=C3=BCller?=
Date: Fri, 30 Aug
> On Mon, 10 Dec 2012, Sergei Trofimovich wrote:
> gentoo-x86/profiles/updates $ LANG=C ls -1 --sort=time
> [long list omitted]
> old entries are done in different context (comparing to 2012):
> - some packages change names 2 or 3 times
> - slots have different meaning
> moreover:
> - if
> On Mon, 17 Dec 2012, Michał Górny wrote:
> On Mon, 17 Dec 2012 11:23:00 +0100
> Diego Elio Pettenò wrote:
>> I would say let's work on that so that portage can keep them there.
>> Although I'm more for /var/cache/portage myself, as both distfiles and
>> tree can be re-generated.
> +1 on /
> On Mon, 17 Dec 2012, William Hubbs wrote:
> This all started with the April 2012 council meeting when it was
> pushed through that separate /usr without an initramfs is a
> supported configuration, so yes, the previous council started this
> issue.
Sorry, but that's not an accurate account
> On Wed, 19 Dec 2012, Diego Elio Pettenò wrote:
> On 19/12/2012 13:44, Marc Schiffbauer wrote:
>> I would suggest /var/portage ...
> Seriously, mine is going to be a huge veto here with as much power I
> can put.
Why? The portage tree is of central importance for Gentoo, so IMHO a
second-le
> On Wed, 19 Dec 2012, Brian Dolbec wrote:
> just to clarify, I'm voting for...
> /var/cache/distfiles
> /var/cache/packages
Fine.
> /var/cache/repositories/
> /var/cache/repositories/gentoo <== the main portage tree
> /var/cache/repositories/local<== the new location for a local over
> On Thu, 20 Dec 2012, Rich Freeman wrote:
> I actually like the /var/cache/repositories approach. You can always
> add a symlink to it if you want to for convenience (as I already do
> for /var/lib/portage/world). There is really nothing special about
> /usr/portage, other than it being the
> On Thu, 20 Dec 2012, Diego Elio Pettenò wrote:
>> /var/cache/portage/distfiles
>> /var/cache/portage/repositories/gentoo
>> /var/cache/portage/repositories/{sunrise,kde,gnome,whatever,layman,grabs}
>> /var/db/portage/repositories/{non-cache,repo,names,go,here}
> +1
-1
The subdirs are too
The FHS says:
/var/cache is intended for cached data from applications. Such data
is locally generated as a result of time-consuming I/O or
calculation. The application must be able to regenerate or restore
the data.
Now I wonder: After removal of e.g. the Portage tree from a system,
> On Thu, 20 Dec 2012, Michael Mol wrote:
/var/cache/portage/distfiles
/var/cache/portage/repositories/gentoo
/var/cache/portage/repositories/{sunrise,kde,gnome,whatever,layman,grabs}
/var/db/portage/repositories/{non-cache,repo,names,go,here}
>> -1
>>
>> The subdirs are
>>>>> On Thu, 20 Dec 2012, Ian Stakenvicius wrote:
> On 20/12/12 12:27 PM, Ulrich Mueller wrote:
>> The FHS says:
>>
>> /var/cache is intended for cached data from applications. Such
>> data is locally generated as a result of time-consuming I/O or
&g
> On Thu, 20 Dec 2012, Ciaran McCreesh wrote:
>> We should go with a shorter (easier to remember, easier to type) path
>> and move things at least one level up. Two would be even better.
> You shouldn't ever be typing that path in...
Ebuilds tell users to do so:
pkg_nofetch() {
einfo "P
> On Thu, 20 Dec 2012, Rich Freeman wrote:
>> If only a small subset of licenses require it, then maybe we should just
>> use dodoc on those licenses that require it. Saving all licenses could
>> be overkill.
> Seems like a reasonable compromise. I would think such licenses would
> be rare.
> On Fri, 21 Dec 2012, Duncan wrote:
>>> The FHS says:
>>>
>>>/var/cache is intended for cached data from applications. Such
>>>data is locally generated as a result of time-consuming I/O or
>>>calculation. The application must be able to regenerate or
>>>restore the data.
>
> On Fri, 21 Dec 2012, Richard Yao wrote:
> Dear Everyone, sys-libs/glibc contains LICENSE="LGPL-2", but it
> would appear to be subject to roughly a dozen licenses, many of
> which are not in the tree?
> http://sourceware.org/git/?p=glibc.git;a=blob;f=LICENSES;h=80f7f1487947f57815b9fe076fadc
> On Mon, 24 Dec 2012, Sebastian Pipping wrote:
> On 20.12.2012 19:14, Ciaran McCreesh wrote:
>> The tree is a database. It belongs in /var/db/.
> I don't see /var/db in the latest release of the Filesystem
> Hierarchy Standard:
> http://www.pathname.com/fhs/pub/fhs-2.3.html#THEVARHIERARCH
> On Mon, 24 Dec 2012, Diego Elio Pettenò wrote:
>> /var/cache/packages/ PKGDIR
> Maybe /var/spool/binpkgs ?
This doesn't look right to me. /var/spool contains things like printer
queues or outgoing mail that are typically deleted after processing.
Ulrich
>>>>> On Mon, 24 Dec 2012, Diego Elio Pettenò wrote:
> On 24/12/2012 14:32, Ulrich Mueller wrote:
>> This doesn't look right to me. /var/spool contains things like
>> printer queues or outgoing mail that are typically deleted after
>> processing.
> Not
>>>>> On Mon, 24 Dec 2012, Diego Elio Pettenò wrote:
> On 24/12/2012 16:43, Ulrich Mueller wrote:
>> Why not? Because they are distributed to other systems?
> More because they can be used as a backup themselves, if I want to
> keep older versions available.
This
>>>>> On Sat, 29 Sep 2012, Rich Freeman wrote:
> On Sat, Sep 29, 2012 at 5:21 PM, Ulrich Mueller wrote:
>>>>>>> On Sat, 29 Sep 2012, Chí-Thanh Christopher Nguyễn wrote:
>>> If we start to measure the software freedom of the code inside the
>>
> On Sun, 13 Jan 2013, Michał Górny wrote:
>> How does something not have a homepage? If upstream is gone, then by
>> definition, gentoo's the "upstream" as we're distributing it, so
>> gentoo.org becomes the homepage.
> If something is a six-liner made by Gentoo and for Gentoo, noone care
> On Thu, 17 Jan 2013, Ben de Groot wrote:
> Presently we already have a good number of split qt-* library
> packages in x11-libs. With the arrival of Qt5 upstream has gone a
> lot further in modularization, so we expect the number of packages
> to grow much more. We, the Gentoo Qt team, are o
> On Sun, 3 Feb 2013, Ryan Hill wrote:
> We have eclasses that require Bash 4 (eg. multiprocessing.eclass
> uses BASHPID).
I wonder why it would be needed there. Doesn't $$ work?
Ulrich
I always wondered why we are using such bulky names like
CCPL-Attribution-ShareAlike-2.5 for the Creative Commons licenses,
instead of CC-BY-SA-2.5 like everyone else. The latter also used by
our documentation pages and is the name in the SPDX license list [1],
So, while in general I'm against ren
>>>>> On Fri, 8 Feb 2013, Ben de Groot wrote:
> On 8 February 2013 00:31, Alec Warner wrote:
>> On Thu, Feb 7, 2013 at 8:07 AM, Ulrich Mueller wrote:
>>> So, while in general I'm against renaming of licenses (e.g.,
>>> it would be pointless to rena
> On Fri, 8 Feb 2013, Tomáš Chvátal wrote:
> 2013/2/8 Diego Elio Pettenò :
>> I would say that we might want to review linux-firmware, and if the
>> newest firmware _is_ there, just get rid of the split one.
>>
> That should be probably the best approach, to actually kill of the
> lone ones a
> On Sat, 09 Feb 2013, Samuli Suominen wrote:
>> I disagree. Why should we force users to install lots of crap (some
>> of it being non-free) that they will never need because they don't
>> have the hardware?
> Maybe you don't understand how linux-firmware package works. It only
> installs wh
> On Sat, 9 Feb 2013, Michał Górny wrote:
> I don't think that solves the license problem properly. Say, if user
> doesn't want non-free software, he's going to have the whole package
> masked. He'd have to work-around license + savedconfig.
> Now that I look at it, it seems that the ebuild d
> On Sat, 16 Feb 2013, Diego Elio Pettenò wrote:
>> Please don't. I think it would suck to lose the higher resolution.
> Use savedconfig and stop wasting our collective time for your
> personal lazyness.
Huh? Savedconfig isn't a solution for the license issue.
Ulrich
> On Sat, 16 Feb 2013, Diego Elio Pettenò wrote:
> On 16/02/2013 15:41, Rick "Zero_Chaos" Farina wrote:
>>
>> Yup, we sure can remove them, and if no one beat me to it I will do
>> that now.
> Go for it.
Please don't.
Can we please stop removing individual firmware packages until
sys-kerne
> On Sat, 16 Feb 2013, Rick \"Zero Chaos\" Farina wrote:
>> Huh? Savedconfig isn't a solution for the license issue.
> If he doesn't agree to the license he can use savedconfig to not
> install those firmware packages.
Yes, but ACCEPT_LICENSE wouldn't work. It would still be necessary to
inc
801 - 900 of 2160 matches
Mail list logo
