> On Sun, 31 May 2020, Zac Medico wrote:
> We've also got these other basename calls in fetch.py:
>> diff --git a/lib/portage/package/ebuild/fetch.py
>> b/lib/portage/package/ebuild/fetch.py
>> index 28e7caf53..56b375d58 100644
>> --- a/lib/portage/package/ebuild/fetch.py
>> +++
> On Sun, 31 May 2020, Zac Medico wrote:
> In order to ensure that the filename will not have an extra level of quoting
> in the mirror path, we'll have to do something like this wherever we
> translate a uri in SRC_URI to a filename:
> diff --git a/lib/portage/dbapi/porttree.py
> On Tue, 26 May 2020, Zac Medico wrote:
> On 5/26/20 12:48 AM, Michał Górny wrote:
>> On Mon, 2020-05-25 at 21:31 -0700, Zac Medico wrote:
>>> Since variables like A and AA can contain extremely large values which
>>> may trigger E2BIG errors during attempts to execute subprocesses, delay
> On Fri, 22 May 2020, Michał Górny wrote:
> Hence my question: do you find 'do not remove kernels listed in
> bootloader config' feature useful? Do you think it should remain the
> default? Do you think it is worthwhile to continue supporting it?
For GRUB, wouldn't the typical workflow
> On Thu, 21 May 2020, Robert Bridge wrote:
> There are only 4 billion to reverse, not that hard really with a
> rainbow table...
That's why I said salted hash.
signature.asc
Description: PGP signature
> On Thu, 21 May 2020, Robert Bridge wrote:
> On Thu, 21 May 2020 at 09:47, Michał Górny wrote:
>>
>> Option 1: IP-based limiting
>> ===
>>
> Preface this with IANAL, check with your own legal counsel...
> While IP address based methods might be attractive
> On Mon, 18 May 2020, William Hubbs wrote:
> I would like to start a discussion on checking the PROPERTIES value in
> ebuilds. Specifically this could be used to check for live ebuilds
> instead of assuming that the version number of an ebuild indicates
> whether the ebuild is live.
> The
> On Mon, 18 May 2020, William Hubbs wrote:
> I have been acting as a backup maintainer for dev-vcs/cli. A pull
> request was opened today that changes the way we detect whether the
> ebuild is live from looking for "live" in $PROPERTIES to the version
> number [1].
> A different dev
When implementing support for arches.desc in ebuild-mode, I noticed
that the GLEP would allow several lines with the same architecture in
the first column. So, specify that the arch must be unique.
I don't attach the full text because this is a one-line change.
Ulrich
From
> On Sun, 26 Apr 2020, Michael Orlitzky wrote:
> Fuel for the fire:
> * https://www.nongnu.org/lzip/lzip_benchmark.html
> * https://www.nongnu.org/lzip/xz_inadequate.html
Yep. That's why lzip is the dominant compression format now, and nobody
is using xz any more.
SCNR,
Ulrich
> On Sun, 26 Apr 2020, Michał Górny wrote:
> The other major problem is spam protection. The best semi-anonymous way
> I see is to use submitter's IPv4 addresses (can we support IPv6 then?).
> We could set a limit of, say, 10 submissions per IPv4 address per week.
> If some address would
> On Thu, 23 Apr 2020, Kent Fredric wrote:
> I've just discovered dev-perl/Ace has some fun questionable licensing
> which includes a lovely indemnity clause, which had previously gone
> unnoticed, and it stipulates additional requests for research
> publications, which is not something
# Ulrich Müller (2020-04-22)
# Package is no longer being updated upstream.
# Replaced by app-i18n/man-pages-l10n[l10n_pl].
# Masked for removal in 30 days. Bug #717744.
app-i18n/man-pages-pl
signature.asc
Description: PGP signature
>>>>> On Tue, 14 Apr 2020, Ulrich Mueller wrote:
> Last year, we had removed all news items up to 2013-12-31. I suggest
> that we do the same now for the items from 2014, namely:
>2014-02-25 Upgrade to >=sys-fs/udev-210
>2014-03-12 Profile EAPI 5 require
> On Tue, 21 Apr 2020, Michał Górny wrote:
> Please note that during the system upgrade some of the package
> dependencies may temporarily become missing. While this should not
> should not affect programs that are already fully loaded, it may cause
"should not" should not be duplicate.
# Ulrich Müller (2020-04-17)
# Upstream has moved the manpages-de project to manpages-l10n.
# We cannot move multiple packages to one, therefore removing the
# old package. Use app-i18n/man-pages-l10n[l10n_de] as replacement.
# Masked for removal in 30 days. Bug #717744.
app-i18n/man-pages-de
# Mattéo Rossillol‑‑Laruelle (2020-04-17)
# Very little activity for almost a year and the link to download the
# "compiled" man-pages is dead.
# Use app-i18n/man-pages-l10n[l10n_fr] as replacement.
# Masked for removal in 30 days (bug #717744).
app-i18n/man-pages-fr
signature.asc
Description:
# Ulrich Müller (2020-04-15)
# Last upstream release in 2001. HOMEPAGE disappeared in 2010.
# Use app-i18n/man-pages-l10n[l10n_nl] as replacement.
# Masked for removal in 30 days. Bug #713590.
app-i18n/man-pages-nl
signature.asc
Description: PGP signature
> On Wed, 15 Apr 2020, Matt Turner wrote:
>> This is a CBUILD type dependency, right? Then there is no good way to
>> express it in EAPI 7. Still, I think that it should be specified in
>> BDEPEND (and maybe RDEPEND in addition).
> I'm not sure what CBUILD means. What is that?
That's a
> On Wed, 15 Apr 2020, Matt Turner wrote:
> At the same time, fix the dependency on sys-libs/libcap by moving it to
> RDEPEND, as dependencies in DEPEND/BDEPEND are not guaranteed to exist
> during pkg_postinst() when this eclass is intended to run.
This is a CBUILD type dependency, right?
Last year, we had removed all news items up to 2013-12-31. I suggest
that we do the same now for the items from 2014, namely:
2014-02-25 Upgrade to >=sys-fs/udev-210
2014-03-12 Profile EAPI 5 requirement
2014-03-16 Ruby 1.8 removal; Ruby 1.9/2.0 default
2014-06-03 UPower loses
> On Mon, 13 Apr 2020, Michał Górny wrote:
> -When a profile of an architecture arch is tested, then repoman checks
> -consistency of the dependency tree for ``arch`` and for ``~arch`` separately.
> +Stable means that the architecture is actively maintaning stable keywords.
> On Sat, 11 Apr 2020, Michael Orlitzky wrote:
> NB: why are we still requiring a comment in
> 2020 to indicate that a package is maintainer-needed? That information
> is already present in and easily retrievable from the XML. If you're
> grepping XML, you're doing it wrong. Use e.g.
Also update the license to "Creative Commons Attribution-ShareAlike 4.0
International", please.
signature.asc
Description: PGP signature
> On Sun, 12 Apr 2020, Michał Górny wrote:
> glep-0072: Rename bad depgraph state to 'degraded'
>
> In Gentoo terms, 'testing' and 'unstable' are mostly synonymous,
> so using the two names for different purposes is confusing. Use
>
> On Sat, 11 Apr 2020, Marek Szuba wrote:
> I have tried doing this in pkg_preinst but alas, I have found out
> collision checks are performed before that function is invoked. I have
> also tried setting COLLISION_IGNORE in the replacing package but it
> seems that variable only works in
> On Sat, 11 Apr 2020, Marek Szuba wrote:
> Title: Manual steps required during upgrade to an eselect-free OpenCL set-up
Title is too long.
> Author: Marek Szuba
> Posted: 2020-05-01
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Installed: app-eselect/eselect-opencl
> We are now in
> On Sat, 11 Apr 2020, Michał Górny wrote:
> Thinking about it, all these terms seem too generic. Would be nice to
> find one that clearly suggests it's between testing and stable, and not
> 'lenient' in ~arch. How about 'transitional' or 'incomplete-stable'?
"interim"?
signature.asc
>>>>> On Fri, 10 Apr 2020, Ulrich Mueller wrote:
>> -``testing`` for all architectures where "inofficial" stable keywords are
>> +``degraded`` for all architectures where "inofficial" stable keywords are
> I am aware that it isn't your chang
> On Fri, 10 Apr 2020, Michał Górny wrote:
> In Gentoo terms, 'testing' and 'unstable' are mostly synonymous,
> so using the two names for different purposes is confusing. Use
> 'degraded' instead.
"Degraded" has a negative ring to it, so can you find another term?
How about "lenient" or
> On Fri, 10 Apr 2020, Michał Górny wrote:
> -In the main profiles directory, a file ``arches.desc`` is added. Name
> -and location are chosen in analogy to the existing ``profiles.desc`` file.
> -The format of ``arches.desc`` is as follows:
> +In the ``profiles`` subdirectory of the
> On Tue, 07 Apr 2020, Samuel Bernardo wrote:
> No assurance is also a level that takes place in the lower ranking
> level. If someone needs to use zoom because they are demanded by their
> boss I think that would be even more useful to know that it is possible
> to install zoom in Gentoo and
> On Thu, 02 Apr 2020, Rich Freeman wrote:
> I guess we could stick an einfo in the post-install messages,
Not sure if that's necessary. Zoom is a proprietary, closed-source,
fetch-restricted package, so users should know that they cannot expect
the same level of quality as for free
> On Thu, 02 Apr 2020, Alessandro Barbieri wrote:
> I have concerns about the inclusion of zoom in ::gentoo. For me it's
> more like a malware.
Gentoo is about choice. If users want to use Zoom (or have to, because
their employer schedules a meeting using that platform) then it is not
our
> On Thu, 02 Apr 2020, Piotr Karbowski wrote:
> Title: Deprecation and removal of legacy X11 input drivers.
Title has 52 chars which is too long (omit the full stop for a start).
> Author: Piotr Karbowski
> Posted: 2020-04-02
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Installed:
>>>>> On Tue, 31 Mar 2020, Ulrich Mueller wrote:
> I've sent an e-mail message upstream, asking for confirmation that 10.24
> can be used, copied, modified, and/or distributed freely.
This is the answer from upstream (posted here with permission):
| The license on http
> On Tue, 31 Mar 2020, James Cloos wrote:
> The only license i can see in that zip is the line in the pdf (which
> also says 10.24) that they are 'free for any use'.
Ah, I hadn't seen that one. I stand corrected then.
> If 10.24 is in wayback, 10.23 probably is as well.
> The last usable
> On Tue, 31 Mar 2020, Alessandro Barbieri wrote:
> Version 10.23 is here
> https://web.archive.org/web/20180129230141/http://users.teilar.gr/~g1951d/Symbola.zip
Actually, that zipball contains version 10.24, which is under the
restrictive license already:
$ fc-query -f '%{fontversion}'
> On Thu, 26 Mar 2020, William Hubbs wrote:
> If there's a way inside an eclass to check that the ebuild inheriting
> it is in ::gentoo, I will use it to die if the ebuild is in ::gentoo
> and this variable is set.
Oh please, not this again. An ebuild or eclass is supposed to work the
same
> On Wed, 25 Mar 2020, Ulrich Müller wrote:
> + local desktop="${exec%%[[:space:]]*}"
> + desktop="${T}/${desktop##*/}-${desktop_name}.desktop"
Alternatively, we could use the executable's basename only, without
appending PN (but still appending SLOT if different from 0). Or do we
> On Fri, 14 Feb 2020, Ulrich Müller wrote:
> Accessing ${S} in global scope is not allowed by PMS, therefore remove
> the global variable assignment of FONT_S which uses it. Add a fallback
> to ${S} in font_src_install() instead.
> Allow FONT_S to be an array, if there are multiple
# Ulrich Müller (2020-03-11)
# No license. HOMEPAGE is gone.
# Masked for removal in 14 days. Bug #450454.
games-misc/fortune-mod-humorixfortunes
signature.asc
Description: PGP signature
> On Sun, 08 Mar 2020, Michał Górny wrote:
> + The dev-python category contains packages whose primary purpose
> + is to provide Python modules, extensions and bindings, as well
> + as tools and utilities useful for development in the Python
> +
> On Sun, 08 Mar 2020, heroxbd wrote:
> debug-print-function ${FUNCNAME} "$@"
>
> + if [[ ${EUID} != 0 ]] ; then
> + einfo "Insufficient privileges to execute ${FUNCNAME[0]}"
Just a small comment on style, maybe try to stay consistent with the
rest of the eclass? That
> On Sat, 07 Mar 2020, Michał Górny wrote:
> Surely, you can claim we could just drop them to maintainer-needed.
> What problem does that solve? The package would still miss 3.7 support.
> Users will still suffer when we switch the default (if they have any
> users, that is). We would still
> On Sat, 07 Mar 2020, Matt Turner wrote:
>> > The list is almost exclusively about dev-python/, i.e. packages that
>> > do not install end-user applications but Python modules.
>>
>> Like www-apps/nikola, for example?
> This is not a productive way to communicate.
The point is that
> On Sat, 07 Mar 2020, Michał Górny wrote:
>> Just the ebuild being outdated doesn't sound like a sufficient reason
>> for removal of a package, at least not for those packages that install
>> applications for the end user.
> The list is almost exclusively about dev-python/, i.e. packages
> On Sat, 07 Mar 2020, Michał Górny wrote:
> Ebuilds. 183 of them. One is stuck on py2 but is included as only
> revdep.
Just the ebuild being outdated doesn't sound like a sufficient reason
for removal of a package, at least not for those packages that install
applications for the end
> On Sat, 07 Mar 2020, Michał Górny wrote:
> # Michał Górny (2020-03-07)
> # The following packages are stuck on Python 3.6, and have no reverse
> # dependencies. Please let the Python team know if you find some
> # of them still useful.
> # Removal in 30 days. Bug #711808.
Does this mean
> On Thu, 20 Feb 2020, Zac Medico wrote:
> Looks good. Even though earlier EAPIs are deprecated, would there be a
> problem with updating __eapi4_src_install for consistency?
I'd rather not, because for EAPIs 4 and 5 PMS specifies that the return
status of declare -p should be tested [1].
> On Wed, 19 Feb 2020, Patrick McLean wrote:
> If sshd is running, and a system is upgraded from to >=net-misc/openssh-8.2_p1, any new ssh connection will fail until sshd is
> restarted.
The ebuild currently has this warning:
ewarn "After upgrading to openssh-8.2p1 please restart sshd,
The devmanual says about live ebuilds:
| CVS ebuilds must be either with empty KEYWORDS or package.masked
| (but not both). Empty KEYWORDS are strongly preferred. This applies
| to "live" ebuilds (-) and to ebuilds that extract a static
| revision but still use CVS for fetching.
As of today,
> On Tue, 11 Feb 2020, Alexey 'Alexxy' Shvetsov wrote:
> Ok. What is you're suggestion?
If you really need that kind of mnemonics, how about 368 (68 being the
ASCII code for "D")?
Ulrich
signature.asc
Description: PGP signature
> On Fri, 07 Feb 2020, Matt Turner wrote:
> On Fri, Feb 7, 2020 at 9:10 AM Mike Pagano wrote:
>>
>> # Mike Pagano (2020-02-07)
>> # The standalone ebuild for this driver is made
>> # unnecessary as it is included in the package:
>> # sys-kernel/linux-firmware
>> sys-firmware/iwl6050-ucode
# Ulrich Müller (2020-02-05)
# Last version bump in 2014, while upstream is at 2019/1.
# Ebuild claims "free-noncomm", but has an inaccessible distfile
# behind a registration wall. Unresponsive Gentoo maintainer.
# Masked for removal in 30 days. Bug #702352.
sci-chemistry/shelx
signature.asc
# Ulrich Müller (2020-02-04)
# No license; copyright status unclear.
# Masked for removal in 30 days. Bug #634288.
games-misc/fortune-mod-calvin
games-misc/fortune-mod-futurama
# Ulrich Müller (2020-02-04)
# No license. HOMEPAGE and SRC_URI are gone.
# Masked for removal in 30 days. Bugs
The following came up in #gentoo-qa yesterday, in a discussion between
mgorny, soap and myself.
Historically, all ebuilds in the Gentoo repository were licensed under
GPL-2+. At a later point they were relicensed [1] to GPL-2. See [2] for
a rationale (or absence of it, YMMV).
However, in GLEP
# Ulrich Müller (2020-01-27)
# Removal requested by proxied maintainer:
# "Game already available in Valve Steam."
# License issues, unclear if zipball is redistributable.
# Masked for removal in 30 days. Bug #703496.
games-action/cs2d
signature.asc
Description: PGP signature
> On Wed, 22 Jan 2020, Matt Turner wrote:
> Title: Stable alpha keywords removed
> Author: Matt Turner
> Content-Type: text/plain
> Posted: 2020-01-22
> Revision: 1
> News-Item-Format: 1.0
Please use format 2.0 (and remove the Content-Type).
> Display-If-Keyword: alpha
> The Gentoo/Alpha
> On Tue, 21 Jan 2020, Ralph Seichter wrote:
> https://github.com/gentoo/gentoo/pull/13265
> After following the recent discussion here, I ask that somebody please
> decide on what to do with this PR, which I opened 2019-10-12.
You had suggested /var/lib/amavishome in that PR, three months
>>>>> On Mon, 20 Jan 2020, Michael Orlitzky wrote:
> On 1/20/20 2:02 AM, Ulrich Mueller wrote:
>> Quoting FHS-3.0 again:
>>
>> | On large systems (especially when the /home directories are shared
>> | amongst many hosts using NFS) it is useful to subdivi
> On Mon, 20 Jan 2020, William Hubbs wrote:
> as I recall I was one of the folks who suggested that uid-gid.txt should
> go in the api repository, but after thinking about it more and seeing it
> in practice, I see the error of my ways on this. ;-)
> Imo a better fit is the metadata
> On Mon, 20 Jan 2020, Michael Orlitzky wrote:
> install-qa-check.d: allow acct-user home directories under /home.
Nope. As you've been told, /home is site specific and can be setup in
multiple ways that are incompatible with the package manager installing
things there (the only exception
> On Sun, 19 Jan 2020, Zac Medico wrote:
> --- a/bin/ebuild-helpers/dosym
> +++ b/bin/ebuild-helpers/dosym
> @@ -21,14 +21,6 @@ fi
> destdir=${2%/*}
> [[ ! -d ${ED%/}/${destdir#/} ]] && dodir "${destdir}"
> target="${1}"
> -# DEPRECATED HACK: when absolute, prefix with offset for Gentoo
> On Sun, 19 Jan 2020, Michał Górny wrote:
> The sources are stored in proj/policy-guide.git [3]. If you wish to
> submit your own changes, you can either use the 'Policy Guide' bugzilla
> component [4] and/or GitHub mirror [5].
Please, no github for official policies. We should have a
> On Sat, 18 Jan 2020, Michael Orlitzky wrote:
> Where do we put amavis's home directory?
> [...]
> 3 /home/amavis also seems fine to me, except for the fact that it's a
> QA violation to install there.
> Note that we could always set system users' home directories to
>
# Ulrich Müller (2020-01-12)
# Runtime errors. Last upstream release in 2003. No license.
# Masked for removal in 30 days. Bug #703548.
games-board/cgoban2
signature.asc
Description: PGP signature
> On Tue, 07 Jan 2020, James Cloos wrote:
>>> That is untrue. They are public domain.
UM> Where did you get that information from?
> Some may not be. I didn't look at every page, but for ones like:
> http://crosswire.org/sword/modules/ModInfo.jsp?modName=DutSVV
> it says so on that
# Ulrich Müller (2020-01-07)
# No upstream SRC_URI. No license, so it cannot be mirrored.
# Masked for removal in 30 days. Bug #702936.
media-fonts/nepali-fonts
signature.asc
Description: PGP signature
> On Tue, 07 Jan 2020, James Cloos wrote:
UM> # Ulrich Müller (2020-01-06)
UM> # No license, therefore we have no permission to redistribute
> That is untrue. They are public domain.
Where did you get that information from?
I've tried to be thorough in https://bugs.gentoo.org/703604, but
# Ulrich Müller (2020-01-06)
# No license, therefore we have no permission to redistribute
# these packages on Gentoo mirrors. Distfiles are unversioned
# zipballs, which are updated in place when a new version is
# released. Since this will break digests, mirror restriction
# is not feasible.
#
Currently the devmanual git repository contains the history (converted
from subversion) back to 2006-02-20, but apart from two snapshots in
July and August 2005, we don't have anything from before. The wayback
machine has only an incomplete archive of the generated html [1].
Can anybody help? Any
> On Thu, 02 Jan 2020, Michał Górny wrote:
> --- a/eclass/ruby-ng.eclass
> +++ b/eclass/ruby-ng.eclass
> @@ -137,7 +137,7 @@ ruby_samelib() {
> local res=
> for _ruby_implementation in $(_ruby_get_all_impls); do
> has -${_ruby_implementation} $@ || \
> -
> On Tue, 31 Dec 2019, David Seifert wrote:
> On Tue, 2019-12-31 at 05:34 +0100, Michał Górny wrote:
>> --- a/eclass/ruby-ng.eclass
>> +++ b/eclass/ruby-ng.eclass
>> @@ -137,7 +137,7 @@ ruby_samelib() {
>> local res=
>> for _ruby_implementation in $(_ruby_get_all_impls); do
>> has
> On Fri, 27 Dec 2019, Thomas Deutschmann wrote:
> PS: Where were you when
> https://www.gentoo.org/support/news-items/2019-07-18-syncthing-update-incompatibility.html
> and
> https://www.gentoo.org/support/news-items/2019-11-25-rpi-firmware-dtb-files.html
> were posted? :-)
Indeed, they
> On Fri, 27 Dec 2019, Thomas Deutschmann wrote:
> Title: Genkernel 4 changed default kernel and initramfs filename
011223344
123456789012345678901234567890123456789012345678901234567
Too long, GLEP 42 allows a maximum of 50
# Ulrich Müller (2019-12-25)
# Broken SRC_URI. Most distfiles have no license,
# so we cannot distribute them on mirrors.
# Masked for removal in 30 days. Bug #635372.
x11-themes/audacious-themes
signature.asc
Description: PGP signature
> On Sat, 21 Dec 2019, Michael Orlitzky wrote:
> And for the record, commenting on standards in response to a series of
> commits that display low standards is not a personal attack.
*shrug* As a matter of fact, I've run that series of commits past the
QA lead, who has approved them.
> On Sat, 21 Dec 2019, Michael Orlitzky wrote:
> And then you tried to use my suggestion to be extra careful and run a
> CI check against me, which is obnoxious, so there you go.
Maybe you shouldn't suggest usage of non-free tools (like Github) then?
It's everyone's own choice if they want
> On Sat, 21 Dec 2019, Michael Orlitzky wrote:
> I was being safe, and assuming that your standards for shell scripting
> are as low as your standards for tree quality.
Nice, resorting to a personal attack when out of arguments. :(
> On Fri, 20 Dec 2019, Michael Orlitzky wrote:
> Portage seems OK with the missing dependency, but for the overall plan
> to work, you have to wait a long time before deleting virtual/emacs;
> otherwise the upgrade path is broken. With virtual/emacs-26 installed
> and "old" copies of the
> -RDEPEND=">=virtual/emacs-${NEED_EMACS:-23}"
> +RDEPEND=">=app-editors/emacs-${NEED_EMACS}:*"
... and of course, the slot operator isn't legal in EAPI 4. It is
trivial to fix, so I won't send a v3 for this.
signature.asc
Description: PGP signature
> On Fri, 20 Dec 2019, Alexis Ballier wrote:
> Should we use this to drop RDEPEND from pkg_*inst/rm phases ?
> PMS states "RDEPEND (unless the particular dependency results in a
> circular dependency, in which case it may be installed later)" which is
> kind of "maybe maybe not" and I'm not
> On Fri, 20 Dec 2019, Michał Górny wrote:
>>> Example 3: removing fetch restriction while leaving mirror
>>> restriction
>>> RESTRICT="fetch"
>>> SRC_URI="https://example.com/you-cant-fetch-this.zip
>>> fetch+https://example.com/you-cant-mirror-this.tar.bz2;
>> I had already asked this in
>>>>> On Wed, 18 Dec 2019, Ulrich Mueller wrote:
> # Ulrich Müller (2019-12-18)
> # Live ebuilds for Emacs from Git have been consolidated
> # into separate slots of the app-editors/emacs package.
> # Please update your package.keywords file accordingly.
S
# Ulrich Müller (2019-12-18)
# Live ebuilds for Emacs from Git have been consolidated
# into separate slots of the app-editors/emacs package.
# Please update your package.keywords file accordingly.
# Masked for removal in 30 days. Bug #291296.
app-editors/emacs-vcs
signature.asc
Description:
> On Wed, 18 Dec 2019, Michael Orlitzky wrote:
>> No revbumps will be done for this (and virtual/emacs will be simply
>> removed without prior masking).
> I guess it's nice that we know ahead of time, but is there any reason
> to suspect that this won't cause havoc?
Removal of the
> On Wed, 18 Dec 2019, Michał Górny wrote:
>> - Package mask app-editors/emacs-vcs (but not the virtual) for removal.
> Maybe package.deprecated the virtual?
Good idea. I have to get used to this. :-)
signature.asc
Description: PGP signature
> On Mon, 16 Dec 2019, Francesco Riosa wrote:
> what about getting rid of RESTRICT="fetch" and manage everything
> inside SRC_URI? Would that be technically feasible? Ideally marking
> only the not re-distributable download and leaving untouched the
> others
That would have the disadvantage
> On Mon, 16 Dec 2019, Michał Górny wrote:
> Proposed solution
> =
> The current proposal is based on extending the current URI syntax to
> permit excluding individual files from the restriction. The idea is to
> prepend 'fetch+' to protocol to undo fetch restriction, or to
# @DEAD
# Ulrich Müller (2019-12-16)
# No longer used by any ebuild in the Gentoo repository.
# Removal in 30 days.
signature.asc
Description: PGP signature
> On Sat, 14 Dec 2019, David Seifert wrote:
> Also, it makes egencache failures in overlays more descriptive, and
> hence I'd keep it for the time being.
WFM
signature.asc
Description: PGP signature
> On Sat, 14 Dec 2019, David Seifert wrote:
> case "${EAPI:-0}" in
> - 0|1|2|3|4|5|6|7)
> + [01234])
> + die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}"
> + ;;
> + [567])
> ;;
> *)
> die "Unsupported EAPI=${EAPI}
> On Sat, 14 Dec 2019, Michał Górny wrote:
> Actually, I added that because of your comment that people should be
> rebasing patches rather than removing context.
Isn't rebasing easier than removing context, anyway? I'd trust the
maintainer to do the right thing there.
The main argument is
Some ebuilds output SGR control sequences (formerly known as ANSI escape
sequences) to the terminal, i.e., they do things like:
echo -e "\033[1m${@}\033[0m"
einfo "Fetching \e[1m${r}\e[22m ..."
ewarn "\033[1;33m**\033[00m"
echo -ne "\a" #
> On Fri, 13 Dec 2019, Mike Gilbert wrote:
>> > It also triggers pointless bug reports. Please remove this.
>>
>> I don't like that eqawarn either (see above).
>>
>> OTOH, users shouldn't normally have "qa" in PORTAGE_ELOG_CLASSES,
>> so they won't see the warning?
> Here's a bug report
>>>>> On Thu, 12 Dec 2019, Mike Gilbert wrote:
> On Wed, Nov 27, 2019 at 11:14 PM Michał Górny wrote:
>> On Wed, 2019-11-27 at 23:49 +0100, Ulrich Mueller wrote:
>> > The difference is that there is now a QA warning for something that
>> > is
> On Thu, 12 Dec 2019, Mike Gilbert wrote:
> I think this should be reverted. It causes too much noise, and
> "solves" a problem only very rarely.
Now, how many lines of output does this typically produce, compared
to the total size of a typical build log? Especially with mgorny's
subsequent
# Ulrich Müller (2019-12-11)
# No license. HOMEPAGE and SRC_URI are dead.
# Last visible upstream activity in 2000.
# The package contains only 7 man pages in total.
# Masked for removal in 30 days. Bug #702468
app-i18n/man-pages-da
signature.asc
Description: PGP signature
> On Sat, 07 Dec 2019, Ulrich Müller wrote:
> The eclass failed to remount a read-only mounted /boot, because package
> collision sanity checks in recent Portage versions prevented it from
> reaching pkg_preinst() at all. Furthermore, with the "mount-sandbox"
> feature enabled, the mount
501 - 600 of 2165 matches
Mail list logo
