On 9/4/20 8:39 AM, Florian Schmaus wrote:
> On 9/3/20 7:57 PM, Florian Schmaus wrote:
>> +systemd_profile_env_path = os.path.join(systemd_environment_dir,
>> + "10-gentoo-profile-env.conf")
>> +with open(systemd_profile_env_path, "w") as
# Andreas Sturmlechner (2020-09-04)
# No maintainer, defunct with modern browsers, bug #694024.
# Masked for removal in 30 days.
www-plugins/freshplayerplugin
signature.asc
Description: This is a digitally signed message part.
# Andreas Sturmlechner (2020-09-04)
# Depends on deprecated dev-qt/qtwebkit, maintainer unresponsive for 1.5 yr.;
# Upstream dead, fork available, bug #684678. Masked for removal in 30 days.
app-text/cutemarked
signature.asc
Description: This is a digitally signed message part.
# Andreas Sturmlechner (2020-09-04)
# Depends on deprecated dev-qt/qtwebkit, no more revdeps; bug #737928
# Masked for removal in 30 days.
kde-apps/libkgeomap
signature.asc
Description: This is a digitally signed message part.
# Louis Sautier (2020-09-04)
# Masked for removal in 30 days, no revdeps. Dependency of
# previously removed dev-python/flask-bootstrap
dev-python/flask-appconfig
signature.asc
Description: OpenPGP digital signature
Michael Orlitzky wrote:
>
> Who generates the metadata when I `git pull`?
For the gentoo repository, it is in general some gentoo server
which then pushes the calculated metadata to the repository which
you pull as a user.
It is *possible* to use the "plain" repository, but you have to
set up
On 9/3/20 7:57 PM, Florian Schmaus wrote:
> + systemd_profile_env_path = os.path.join(systemd_environment_dir,
> + "10-gentoo-profile-env.conf")
> + with open(systemd_profile_env_path, "w") as systemd_profile_env:
I just noticed that portage has
On 2020-09-04 09:22, Rich Freeman wrote:
>
> Current Gentoo policy:
>
> ...if the changes are likely to cause problems for end users."
If you're willing to ignore the user reports of problems, and ignore the
mailing list threads telling you that it will cause problems, and avoid
running any
On Fri, Sep 4, 2020 at 9:06 AM Michael Orlitzky wrote:
>
> It's easy to say "well this is not an issue because it can be solved by
> ..."
>
> If it's easy, get it added to the PMS and I'll agree with you.
>
Current Gentoo policy:
"Maintainers must not assume that dynamic dependencies will be
On Fri, 4 Sep 2020 09:06:46 -0400
Michael Orlitzky wrote:
> On 2020-09-04 08:54, Alexis Ballier wrote:
> >
> > py37 will (*) still be installed as it cannot be depcleaned because
> > of 1. emerge won't fail since deps are satisfied.
> >
> >
> > (*) or rather should, but I think the only case
On 2020-09-04 08:54, Alexis Ballier wrote:
>
> py37 will (*) still be installed as it cannot be depcleaned because of
> 1. emerge won't fail since deps are satisfied.
>
>
> (*) or rather should, but I think the only case that matters is a valid
> system state where noone forced uninstall of a
On Thu, 3 Sep 2020 14:17:06 -0400
Michael Orlitzky wrote:
> On 2020-09-03 12:38, Alexis Ballier wrote:
> >
> > if some upgrade wants a package with unmatched deps (e.g. not
> > installed at all or py38 usedep not satisfied), $PM will surely try
> > to satisfy it by installing an ebuild. I don't
On 2020-09-04 04:39, Martin Vaeth wrote:
>
>> That's completely legal according to the PMS, and also the
>> smart thing to do:
>
> s/smart/dumb/, but necessary for a dumb PM
Word games notwithstanding, these are the package managers described by
the PMS.
>> sourcing a few thousand lines of
Hi,
I'm listed as the maintainer of aqbanking and a bunch of packages that
are basically just its dependencies (though libchipcard and ktoblzcheck
may be used separately for some functionality).
This is a library for accessing german online banking systems (which
goes under the names HBCI or
[** Note 1: This only affects one specific profile. **]
[** Note 2: I am still testing the migration process proposed here. **]
Title: riscv multilib profile is going away
Author: Andreas K. Hüttel
Posted: 2020-09-06
Revision: 1
News-Item-Format: 2.0
Display-If-Profile:
Michael Orlitzky wrote:
> What's happening is that the PM is using the metadata from the installed
> version of the package, rather than the ninja-edited metadata in the
> repo (how would it know which ebuilds were edited meaningfully?).
The question is easy to answer:
It is reasonable to assume
On 2020-09-03 15:37, Marek Szuba wrote:
For the record, some mostly-cosmetic issues that have already been
identified. Will include them in the next revision:
> +if [[ ! ${_LUA_R0} ]]; then
> +
> +inherit multibuild toolchain-funcs
> +
> +BDEPEND="virtual/pkgconfig"
There should be no BDEPEND
17 matches
Mail list logo
