Re: [gentoo-dev] Last standing Python 2.7 dependency
Hi all, I'd also like to clean my system and have it Python 2.7 free. Are there any guidelines to check which packages are still using pyton2_7 in my system? Thanks, Viktar On Fri, May 1, 2020 at 7:50 PM Michał Górny wrote: > On Fri, 2020-05-01 at 14:45 -0300, José de Paula Rodrigues wrote: > > Hi all, > > > > I've cleared my system from Python 2.7 almost entirely, with the sole > > exception being dev-lang/python-exec, which relies on a hack to absorb > all > > possible Python versions in python-utils-r1.eclass. Shouldn't python2_7 > be > > removed from _PYTHON_ALL_IMPLS there? > > > > python-exec does not depend on the Python interpreter, so you can > depclean it. > > -- > Best regards, > Michał Górny > >
Re: [gentoo-dev] Cleaning up the installation handbook (Legacy boot / MBR / ...)
On 5/2/20 4:30 PM, Andreas K. Hüttel wrote: > Hey all, > > our installation handbook is right now something of a mess (in particular > regarding partitioning, bootloader, gpt/uefi, ...) > > I'm hereby volunteering to clean things up. Thanks a lot for your work :) But - I'll go the brutal way: > > * Legacy boot and MBR will get kicked out. * > > This is your chance to protest or support. I would like to ask for this to be kept somewhere at least. Is it possible to put it in a separate section or in a page outside the handbook? Having a separate page for it in the wiki might be fine as well. (I don't know if non-devs are allowed to give an opinion, so apologies if I seem presumptuous) Best, Aisha > > Cheers, > Andreas > > signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Cleaning up the installation handbook (Legacy boot / MBR / ...)
сб, 2 мая 2020 г. в 23:51, Dale : > My system is not to old and would need legacy as a option as well. I > actually picked one that didn't do EFI and such. I'd be fine with a link to > another page tho. It may make it easier for everyone else while those of us > with legacy can still get to the info. > > Users point of view. +1 All my Gentoo systems, except one laptop, have been installed in legacy mode as well: Ryzen, Xeon, and others. I'm voting for keeping the chapter about legacy boot in the handbook or in the wiki. -- Regards, Alex
Re: [gentoo-dev] Cleaning up the installation handbook (Legacy boot / MBR / ...)
Georg Rudoy wrote: > On 02.05.2020 at 20:30 user Andreas K. Hüttel wrote: >> I'm hereby volunteering to clean things up. But - I'll go the brutal way: >> >> * Legacy boot and MBR will get kicked out. * >> >> This is your chance to protest or support. > I just installed Gentoo last month on an AMD64 machine that was booted in > legacy mode > and I had no control over that as far as I can tell. > That was a very recent, freshly ordered Ryzen 3700 Hetzner server. > > Dunno if such anecdotical evidence proves anything though. > > My system is not to old and would need legacy as a option as well. I actually picked one that didn't do EFI and such. I'd be fine with a link to another page tho. It may make it easier for everyone else while those of us with legacy can still get to the info. Users point of view. Dale :-) :-)
Re: [gentoo-dev] Cleaning up the installation handbook (Legacy boot / MBR / ...)
On 02.05.2020 at 20:30 user Andreas K. Hüttel wrote: > I'm hereby volunteering to clean things up. But - I'll go the brutal way: > > * Legacy boot and MBR will get kicked out. * > > This is your chance to protest or support. I just installed Gentoo last month on an AMD64 machine that was booted in legacy mode and I had no control over that as far as I can tell. That was a very recent, freshly ordered Ryzen 3700 Hetzner server. Dunno if such anecdotical evidence proves anything though. -- Georg Rudoy
[gentoo-dev] Cleaning up the installation handbook (Legacy boot / MBR / ...)
Hey all, our installation handbook is right now something of a mess (in particular regarding partitioning, bootloader, gpt/uefi, ...) I'm hereby volunteering to clean things up. But - I'll go the brutal way: * Legacy boot and MBR will get kicked out. * This is your chance to protest or support. Cheers, Andreas -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] last rites: dev-tex/revtex
# Andreas K. Hüttel (2020-05-02) # Included in recent texlive versions. Please uninstall. # Removal in 30 days. dev-tex/revtex -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH] rebar.eclass: Run tests with new code
On Sat, 02 May 2020 19:31:10 +0200
David Seifert wrote:
> Please use proper bash brackets and shorten everything to
>
> [[ ${1} == eunit ]] && local -x ERL_LIBS="."
Looks good, will do.
--
Hanno Böck
https://hboeck.de/
Re: [gentoo-dev] [PATCH] rebar.eclass: Run tests with new code
On Sat, 2020-05-02 at 19:02 +0200, Hanno Böck wrote:
> Due to an update of dev-erlang/fast_tls I noticed an issue in the
> rebar
> eclass with tests.
>
> It seems the way the eclass currently works it is running tests with
> the library installed in the system, not the code just compiled.
>
> This is obviously not what we want and it also obviously can fail if
> the new tests use features that aren't present in the old version in
> the system.
>
> The patch below fixes this and runs tests with libs from the current
> directory.
>
> Closes: https://bugs.gentoo.org/720448
> Signed-off-by: Hanno Böck
> ---
>
> diff --git a/eclass/rebar.eclass b/eclass/rebar.eclass
> index 92dd16b08..f9849f0ff 100644
> --- a/eclass/rebar.eclass
> +++ b/eclass/rebar.eclass
> @@ -105,6 +105,9 @@ erebar() {
> (( $# > 0 )) || die "erebar: at least one target is required"
>
> local -x ERL_LIBS="${EPREFIX}$(get_erl_libs)"
> + if [ "$1" = "eunit" ]; then
> + local -x ERL_LIBS="."
> + fi
> rebar -v skip_deps=true "$@" || die -n "rebar $@ failed"
> }
>
>
>
Please use proper bash brackets and shorten everything to
[[ ${1} == eunit ]] && local -x ERL_LIBS="."
[gentoo-dev] [PATCH] rebar.eclass: Run tests with new code
Due to an update of dev-erlang/fast_tls I noticed an issue in the rebar
eclass with tests.
It seems the way the eclass currently works it is running tests with
the library installed in the system, not the code just compiled.
This is obviously not what we want and it also obviously can fail if
the new tests use features that aren't present in the old version in
the system.
The patch below fixes this and runs tests with libs from the current
directory.
Closes: https://bugs.gentoo.org/720448
Signed-off-by: Hanno Böck
---
diff --git a/eclass/rebar.eclass b/eclass/rebar.eclass
index 92dd16b08..f9849f0ff 100644
--- a/eclass/rebar.eclass
+++ b/eclass/rebar.eclass
@@ -105,6 +105,9 @@ erebar() {
(( $# > 0 )) || die "erebar: at least one target is required"
local -x ERL_LIBS="${EPREFIX}$(get_erl_libs)"
+ if [ "$1" = "eunit" ]; then
+ local -x ERL_LIBS="."
+ fi
rebar -v skip_deps=true "$@" || die -n "rebar $@ failed"
}
--
Hanno Böck
https://hboeck.de/
[gentoo-dev] NATTkA updates: keyword expansion, CC-ARCHES, ALLARCHES and more
Hi, It's been some time since the last update on NATTkA. Here's just a short summary of new cool features. Keyword expansion in package lists == In order to improve compatibility with existing tools, once arches are CC-ed NATTkA automatically replaces `*` and `^` tokens in package lists with actual lists of keywords. If they happen to match current CC, it outputs the 'empty keyword list' for convenience. Note that the expansion happens only if arches are CC-ed and sanity- check passes. This is meant to avoid changing the package list while the developer is still working on it. CC-ARCHES = If CC-ARCHES keyword is present on the bug, the NATTkA will automatically CC arches and start keywording/stabilization once sanity- check passes. If keywords are specified on the package list, the union of all arch teams will be used for CC. If no keywords are specified for package on package list, NATTkA sees if `*` would yield consistent keywords throughout all packages. If this is the case, it CC-es the equivalent of `*`. Note that arch teams are CC-ed only when sanity-check passes. Again, this is meant to avoid CC-ing prematurely while developer is still working on the package list. If the bug is not checked, then you probably need to specify keywords. ALLARCHES = NATTkA now knows ALLARCHES and helps you do it. When the bug changes, NATTkA looks if all listed packages are marked and adds/removes ALLARCHES keyword appropriately. If you want to force ALLARCHES independently of , just set the keywords yourself once the sanity-check passes and NATTkA shouldn't touch it until next state change. `nattka apply`, `nattka commit` and `nattka resolve` know ALLARCHES too, and will automatically switch to applying all keywords if the bug is marked ALLARCHES. Less verbose output, more verbose logs == NATTkA used to be very verbose when it could no longer perform sanity- check. This involved spamming security bugs once arch teams finished but the bug was still open. Now NATTkA tries to be less verbose -- it tries to determine if there is any more work to be done, and skips bugs silently when all looks done. Note that this could mean silently skipping bugs in corner cases. If NATTkA does not seem to tackle your bug, try `nattka sanity-check ` and it will log the reason. Now the logs in 'pretend' mode include all the changes that would be done to bugs, including specific comments and package list expansions. New `nattka make-package-list` command == Did you ever rely on stable-bot/NATTkA to tell you which dependencies need to be keyworded? Now you can do it locally without updating the bug and waiting for NATTkA to complain. Just run: nattka make-package-list dev-foo/bar and NATTkA will run pkgcheck and add failing dependencies iteratively until it completes the package list or fails to satisfy pkgcheck. Note that this is a pretty early feature and it isn't very smart. It may fail at obvious stuff (like `<` deps) or produce extraneous packages. In particular, pkgcheck and repoman handle || deps somewhat poorly and they could bring extraneous solutions into the package list (e.g. asking you to keyword dev-python/sphinx and pypy3 even though the required PYTHON_TARGETS are masked on arch in question). Improvements will happen in the future. In particular, I'm looking forward to adding an interactive mode with package editing and stablereq support. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] NATTkA updates: keyword expansion, CC-ARCHES, ALLARCHES and more
Hi, It's been some time since the last update on NATTkA. Here's just a short summary of new cool features. Keyword expansion in package lists == In order to improve compatibility with existing tools, once arches are CC-ed NATTkA automatically replaces `*` and `^` tokens in package lists with actual lists of keywords. If they happen to match current CC, it outputs the 'empty keyword list' for convenience. Note that the expansion happens only if arches are CC-ed and sanity- check passes. This is meant to avoid changing the package list while the developer is still working on it. CC-ARCHES = If CC-ARCHES keyword is present on the bug, the NATTkA will automatically CC arches and start keywording/stabilization once sanity- check passes. If keywords are specified on the package list, the union of all arch teams will be used for CC. If no keywords are specified for package on package list, NATTkA sees if `*` would yield consistent keywords throughout all packages. If this is the case, it CC-es the equivalent of `*`. Note that arch teams are CC-ed only when sanity-check passes. Again, this is meant to avoid CC-ing prematurely while developer is still working on the package list. If the bug is not checked, then you probably need to specify keywords. ALLARCHES = NATTkA now knows ALLARCHES and helps you do it. When the bug changes, NATTkA looks if all listed packages are marked and adds/removes ALLARCHES keyword appropriately. If you want to force ALLARCHES independently of , just set the keywords yourself once the sanity-check passes and NATTkA shouldn't touch it until next state change. `nattka apply`, `nattka commit` and `nattka resolve` know ALLARCHES too, and will automatically switch to applying all keywords if the bug is marked ALLARCHES. Less verbose output, more verbose logs == NATTkA used to be very verbose when it could no longer perform sanity- check. This involved spamming security bugs once arch teams finished but the bug was still open. Now NATTkA tries to be less verbose -- it tries to determine if there is any more work to be done, and skips bugs silently when all looks done. Note that this could mean silently skipping bugs in corner cases. If NATTkA does not seem to tackle your bug, try `nattka sanity-check ` and it will log the reason. Now the logs in 'pretend' mode include all the changes that would be done to bugs, including specific comments and package list expansions. New `nattka make-package-list` command == Did you ever rely on stable-bot/NATTkA to tell you which dependencies need to be keyworded? Now you can do it locally without updating the bug and waiting for NATTkA to complain. Just run: nattka make-package-list dev-foo/bar and NATTkA will run pkgcheck and add failing dependencies iteratively until it completes the package list or fails to satisfy pkgcheck. Note that this is a pretty early feature and it isn't very smart. It may fail at obvious stuff (like `<` deps) or produce extraneous packages. In particular, pkgcheck and repoman handle || deps somewhat poorly and they could bring extraneous solutions into the package list (e.g. asking you to keyword dev-python/sphinx and pypy3 even though the required PYTHON_TARGETS are masked on arch in question). Improvements will happen in the future. In particular, I'm looking forward to adding an interactive mode with package editing and stablereq support. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] CFLAGS=-fno-common related breakage is incoming
On Sun, 19 Jan 2020 22:36:51 +
Sergei Trofimovich wrote:
> > What is happening?
>
> gcc-10 is coming soon. It will be more disruptive than gcc-9.
>
> One of the major changes is the switch from C{,XX}FLAGS=-fcommon
> to C{,XX}FLAGS=-fno-common by default: https://gcc.gnu.org/PR85678
>
> It's a planned change and not a gcc regression. It will expose some
> warts on old code and unblock minor optimisations accessing globals.
>
> The change has already happened in gcc trunk.
>
> > Is my package affected? Should I do anything?
>
> You can check proactively if your packages are affected.
>
> Add -fno-common to your make.conf's C{,XX}FLAGS and
> see if things still build.
>
> The typical symptom is a linker failure on multiple definitions
> for some global variable:
>
> ld: a.o:(.bss+0x0): multiple definition of `a'; main.o:(.data+0x0):
> first defined here
>
> > How to fix it?
>
> https://wiki.gentoo.org/wiki/Gcc_10_porting_notes/fno_common contains
> some examples. Ideally code will need a few 'extern' additions and maybe
> moving variable definitions.
>
> Example of proposed openrc fix:
> https://github.com/OpenRC/openrc/pull/348
>
> Adding 'append-flags -fcommon' might work as a temporary workaround.
>
> > Can I help?
>
> Glad you asked! We will need to gather failed packages and fix them
> upstream and downstream. Here is what you can do:
>
> 1. Add -fno-common to your make.conf's C{,XX}FLAGS
> 2. Build packages you maintain
> 3. Fix a bug upstream (or report a failure).
> 4. Pull a fix downstream (or file a bug and add it to the tracker).
>
> > What is already known to be broken? Can I look at example fixes?
>
> See https://wiki.gentoo.org/wiki/Gcc_10_porting_notes/fno_common
> for an artificial example.
>
> Gentoo tracker bug of known issues:
> https://bugs.gentoo.org/705764
> 15 bugs so far.
>
> SUSE tracker bug of known issues:
> https://bugzilla.suse.com/show_bug.cgi?id=1160244
> 95 bugs so far. A good source of packages to check against the
> ones you care about.
>
> > What does -fcommon do?
>
> Look up -fcommon in https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html
>
> > I have no idea why my package broke. The error does not make sense.
>
> Feel free to CC toolchain@ on a bug you observe and we'll try to sort it out.
With Toralf's help we now have rough estimate of broken packages. It's about
450 yet unfixed ones:
https://bugs.gentoo.org/showdependencytree.cgi?id=705764_resolved=1
gcc-10 will be released soon. Maybe in a week.
Please look at the broken list and fix your packages.
Thanks!
--
Sergei
[gentoo-dev] Re: Last rites: media-video/subliminal
On 19/04/2020 22:47, Michał Górny wrote: # Michał Górny (2020-04-19) # Unmaintained. Stuck on Python 3.6. Last release in 2016. # Removal in 30 days. Bug #718410. media-video/subliminal It's an active project. Just not doing releases often. Today 2.1.0 was released: https://github.com/Diaoul/subliminal/releases/tag/2.1.0 Add support for python 3.6, 3.7 and 3.8 Drop support for python 3.3 and 3.4
