[gentoo-dev] [PATCH 1/2] profiles/desc: descriptions for CPU_FLAGS_PPC use_expand
Signed-off-by: Georgy Yakovlev --- profiles/desc/cpu_flags_ppc.desc | 6 ++ 1 file changed, 6 insertions(+) create mode 100644 profiles/desc/cpu_flags_ppc.desc diff --git a/profiles/desc/cpu_flags_ppc.desc b/profiles/desc/cpu_flags_ppc.desc new file mode 100644 index 000..abd2434c4f5 --- /dev/null +++ b/profiles/desc/cpu_flags_ppc.desc @@ -0,0 +1,6 @@ +# Copyright 2019 Gentoo Authors +# Distributed under the terms of the GNU General Public License v2 + +altivec - Use the AltiVec instruction set +vsx - Use the Vector Scalar Extension instruction set (POWER7 and later) +vsx3 - Use the Vector Scalar Extension v.3 instruction set (POWER9 and later) -- 2.23.0
[gentoo-dev] [PATCH 2/2] profiles: Add CPU_FLAGS_PPC to USE_EXPAND
hide everywhere, and unhide in top level powerpc profile Signed-off-by: Georgy Yakovlev --- profiles/arch/powerpc/make.defaults | 9 + profiles/base/make.defaults | 4 ++-- 2 files changed, 11 insertions(+), 2 deletions(-) create mode 100644 profiles/arch/powerpc/make.defaults diff --git a/profiles/arch/powerpc/make.defaults b/profiles/arch/powerpc/make.defaults new file mode 100644 index 000..8613dd7619e --- /dev/null +++ b/profiles/arch/powerpc/make.defaults @@ -0,0 +1,9 @@ +# Copyright 2019 Gentoo Authors +# Distributed under the terms of the GNU General Public License v2 + +# All extra USE/etc should be specified in sub-profiles. +# DO NOT POLLUTE USE ON THIS PROFILE. + +# Georgy Yakovlev
[gentoo-dev] PATCH: add CPU_FLAGS_PPC USE_EXPAND
Possible users from the tree: altivec useflag consumers (many) media libraries (x264, x265, libpng and others.) also firefox-70[1] will have auto-detection of features but we may want to prevent automagic optimizations. cpuid2cpuflags support[2] is ready and and will be merged soon, so users will have a gentoo-way of setting those flags. And this patch in github PR[3] format for easy viewing [1] https://hg.mozilla.org/mozilla-central/rev/252643ff91c5 [2] https://github.com/mgorny/cpuid2cpuflags/pull/13 [3] https://github.com/gentoo/gentoo/pull/12829
[gentoo-dev] Last rites: www-apache/mod_pcgi2, www-apps/pcgi
# Michał Górny (2019-08-31) # Unmaintained. EAPI 0 ebuilds with multiple QA issues. Last release # added in 2003. Upstream removed all traces of it. # Removal in 30 days. Bug #693186. www-apache/mod_pcgi2 www-apps/pcgi -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH 1/2] profiles/desc: descriptions for CPU_FLAGS_PPC use_expand
On Sat, 2019-08-31 at 00:03 -0700, Georgy Yakovlev wrote: > Signed-off-by: Georgy Yakovlev > --- > profiles/desc/cpu_flags_ppc.desc | 6 ++ > 1 file changed, 6 insertions(+) > create mode 100644 profiles/desc/cpu_flags_ppc.desc > > diff --git a/profiles/desc/cpu_flags_ppc.desc > b/profiles/desc/cpu_flags_ppc.desc > new file mode 100644 > index 000..abd2434c4f5 > --- /dev/null > +++ b/profiles/desc/cpu_flags_ppc.desc > @@ -0,0 +1,6 @@ > +# Copyright 2019 Gentoo Authors > +# Distributed under the terms of the GNU General Public License v2 > + > +altivec - Use the AltiVec instruction set > +vsx - Use the Vector Scalar Extension instruction set (POWER7 and later) > +vsx3 - Use the Vector Scalar Extension v.3 instruction set (POWER9 and later) Do all those flags have real use cases in ::gentoo? I'd really prefer not having more 'unused flag' warnings ;-). -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last-rite: app-misc/pip3line
| # Joonas Niilola(2019-08-31) # No maintainer and no one stepped in to take it after a mailing # list announcement. Has QA issues and continuous CI issues. Removal # in 30 days. # Bugs: #690784, #691376, #693184 app-misc/pip3line |
Re: [gentoo-dev] [PATCH 1/2] profiles/desc: descriptions for CPU_FLAGS_PPC use_expand
On 8/30/19 11:11 PM, Michał Górny wrote: > On Sat, 2019-08-31 at 00:03 -0700, Georgy Yakovlev wrote: >> +altivec - Use the AltiVec instruction set >> +vsx - Use the Vector Scalar Extension instruction set (POWER7 and later) >> +vsx3 - Use the Vector Scalar Extension v.3 instruction set (POWER9 and >> later) > > Do all those flags have real use cases in ::gentoo? I'd really prefer > not having more 'unused flag' warnings ;-). > yeah, I have mentioned possible users above and there are plenty I haven't identified yet. patches to ebuilds will follow, I promise =) for example x264 if built with proper flags gives a noticeable boost, (at least 2x at encoding), totally worth it. ppc will not have a lot of flags like on arm or x86, maybe a couple more, but that's it for now. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 1/2] profiles/desc: descriptions for CPU_FLAGS_PPC use_expand
On Sat, 2019-08-31 at 00:19 -0700, Georgy Yakovlev wrote: > On 8/30/19 11:11 PM, Michał Górny wrote: > > On Sat, 2019-08-31 at 00:03 -0700, Georgy Yakovlev wrote: > > > > +altivec - Use the AltiVec instruction set > > > +vsx - Use the Vector Scalar Extension instruction set (POWER7 and later) > > > +vsx3 - Use the Vector Scalar Extension v.3 instruction set (POWER9 and > > > later) > > > > Do all those flags have real use cases in ::gentoo? I'd really prefer > > not having more 'unused flag' warnings ;-). > > > > yeah, I have mentioned possible users above and there are plenty I > haven't identified yet. patches to ebuilds will follow, I promise =) > > for example x264 if built with proper flags gives a noticeable boost, > (at least 2x at encoding), totally worth it. > > ppc will not have a lot of flags like on arm or x86, maybe a couple > more, but that's it for now. > Just to be clear: we're not talking about -m compiler flags, are we? 'cause those should be handled via CFLAGS. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH 1/2] profiles/desc: descriptions for CPU_FLAGS_PPC use_expand
On 8/30/19 11:29 PM, Michał Górny wrote: > On Sat, 2019-08-31 at 00:19 -0700, Georgy Yakovlev wrote: >> On 8/30/19 11:11 PM, Michał Górny wrote: >>> On Sat, 2019-08-31 at 00:03 -0700, Georgy Yakovlev wrote: >> +altivec - Use the AltiVec instruction set +vsx - Use the Vector Scalar Extension instruction set (POWER7 and later) +vsx3 - Use the Vector Scalar Extension v.3 instruction set (POWER9 and later) >>> >>> Do all those flags have real use cases in ::gentoo? I'd really prefer >>> not having more 'unused flag' warnings ;-). >>> >> >> yeah, I have mentioned possible users above and there are plenty I >> haven't identified yet. patches to ebuilds will follow, I promise =) >> >> for example x264 if built with proper flags gives a noticeable boost, >> (at least 2x at encoding), totally worth it. >> >> ppc will not have a lot of flags like on arm or x86, maybe a couple >> more, but that's it for now. >> > > Just to be clear: we're not talking about -m compiler flags, are we? > 'cause those should be handled via CFLAGS. > of course not just compiler flags, that's clear. for example libpng has --enable-powerpc-vsx ./configure flag, and build system will do it's black magic with intrinsics if it's passed. signature.asc Description: OpenPGP digital signature
[gentoo-dev] [RFC] Mass last-riting of x86-but-not-amd64 packages
Hello, We still have a lot of packages that are keyworded ~x86/x86 but were never keyworded ~amd64. While I suppose there might be exceptions to that, in most cases it means that simply nobody has been using it for years. Many of them are still at EAPI 0; some were ported to newer EAPIs specifically to clean old EAPIs. I've already cleaned up some false positives (like svgalib). If you know more, please let me know. I have mixed feelings about games on the list. On one hand, it's rather obvious that they're x86 binary games. However, if somebody actually used them, they would have probably gained amd64 multilib compat by now. --- app-admin/consolehm app-admin/longrun app-emulation/vov app-misc/hatools app-misc/tprint app-shells/shish app-text/fdftk app-text/freepwing dev-db/vbisam dev-embedded/jtag dev-embedded/powersoftplus-libftdi dev-games/flinker dev-games/gtkradiant dev-games/hlsdk dev-lang/gwydion-dylan-bin dev-lang/mozart dev-lang/mozart-stdlib dev-lang/tinycobol dev-libs/asyncresolv dev-libs/cpl-stratego dev-libs/gnulib dev-libs/libsqlora8 dev-libs/libtrain dev-libs/libvolume_id dev-libs/mps dev-lisp/cmucl dev-scheme/kawa dev-util/ald games-action/battalion games-action/fakk2 games-action/postalplus games-arcade/epiar games-arcade/gunocide2ex games-emulation/mekanix games-fps/aaut games-fps/industri games-fps/red-blue-quake2 games-fps/tenebrae games-fps/tribes2 games-fps/unreal-tournament-strikeforce games-fps/ut2003-bonuspack-cm games-fps/ut2003-bonuspack-de games-fps/ut2003-bonuspack-epic games-fps/wolfgl games-misc/c++robots games-roguelike/hengband games-server/bf1942-lnxded games-server/mtavc games-strategy/mindrover-demo games-strategy/netpanzer media-gfx/zgv media-plugins/vdr-bgprocess media-plugins/vdr-pilot media-plugins/vdr-proxy media-plugins/vdr-quicktimer media-plugins/vdr-radiolist media-sound/cmix media-sound/hearnet media-sound/imp3sh media-video/maven-poke media-video/recmpeg media-video/xanim-export net-analyzer/mrtg-ping-probe net-analyzer/nagios-sap-ccms-plugin net-analyzer/ndsad net-analyzer/neti net-analyzer/quidscor net-analyzer/rrdcollect net-analyzer/sguil-sensor net-dialup/cistronradius net-dialup/dgcmodem net-dialup/tkvoice net-dns/tinystats net-firewall/pftop net-irc/ptlink-ircd net-irc/ptlink-opm net-libs/roadrunner net-libs/vanessa-mcast net-mail/fastforward net-mail/gensig net-mail/qmail-lint net-mail/qmail-qsanity net-misc/blinkperl net-misc/dcetest net-misc/hlfl net-misc/ip-sentinel net-misc/lambdamoo net-misc/netprofiles-ims net-misc/selfdhcp net-misc/shout net-misc/smbc net-p2p/gnut net-p2p/mktorrent-borg net-p2p/myster net-p2p/smet2html net-p2p/xnap net-wireless/orinoco-fwutils sys-apps/byld sys-apps/checkservice sys-apps/fwcrv sys-apps/hardened-shadow sys-apps/lcdsplash sys-apps/lcdutils sys-apps/netboot-base sys-auth/icmpdn sys-auth/pam_smb sys-boot/cromwell sys-boot/cromwell-bin sys-boot/psoload sys-boot/raincoat sys-cluster/feedbackd-agent sys-cluster/feedbackd-master sys-cluster/ocfs sys-fs/atari-fdisk sys-fs/davl sys-fs/fuse4bsd sys-fs/hfsplusutils sys-fs/scan-ffs sys-kernel/xbox-sources sys-libs/lrmi sys-power/athcool sys-process/fuser-bsd www-apache/mod_diagnostics www-apache/mod_pcgi2 www-apache/mod_vdbh www-apps/browser-config www-apps/metadot www-apps/pcgi www-client/ck4up x11-drivers/xf86-video-geode x11-misc/bblaunch x11-misc/i855crt x11-misc/xhkeys x11-plugins/gkrellm-plugins x11-plugins/wmXName x11-plugins/wmacpimon x11-plugins/wmbatteries x11-plugins/wmlongrun x11-plugins/wmrecord x11-wm/treewm -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] Mass last-riting of x86-but-not-amd64 packages
Ühel kenal päeval, L, 31.08.2019 kell 10:03, kirjutas Michał Górny: > x11-drivers/xf86-video-geode This one is a required driver for Geode LX hardware, which is 32bit. Mart signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] Mass last-riting of x86-but-not-amd64 packages
Hi Michał, On 2019.08.31 09:03, Michał Górny wrote: > Hello, > > We still have a lot of packages that are keyworded ~x86/x86 but were > never keyworded ~amd64. While I suppose there might be exceptions to > that, in most cases it means that simply nobody has been using it for > years. x86, the 32 bit variety, is still popular at the low power end of the spectrum for things like network appliances. Not the sort of hardware you would play many games on these days. Proceed with caution. Mask them and leave them in the tree. Wait and see who shouts, if anyone. Low power systems don't get updated terribly regularly, so be prepared to leave the packages in the tree for a lot longer than the customary 30 days. > > Many of them are still at EAPI 0; some were ported to newer EAPIs > specifically to clean old EAPIs. > > I've already cleaned up some false positives (like svgalib). If you > know more, please let me know. > > I have mixed feelings about games on the list. On one hand, it's > rather > obvious that they're x86 binary games. However, if somebody actually > used them, they would have probably gained amd64 multilib compat by > now. > > --- > [snip list] > > -- > Best regards, > Michał Górny > > -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods arm64 pgp66BNhk29KZ.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Mass last-riting of x86-but-not-amd64 packages
Hi, most of my points were just said. Two additional notes: - dev-embedded/jtag says upstream is dead anyway and it recommends an alternative we have inside our tree, dev-embedded/urjtag. - games-strategy/netpanzer got a rewrite called version 2.something, which looks active/used. Please reflect these in the masking message(s). However, thanks for the housekeeping! Kind regards, Nils -- GPG fingerprint: '766B 8122 1342 6912 3401 492A 8B54 D7A3 FF3C DB17' Holgersson
Re: [gentoo-dev] [RFC] Mass last-riting of x86-but-not-amd64 packages
On 8/31/19 4:03 AM, Michał Górny wrote: > > I've already cleaned up some false positives (like svgalib). If you > know more, please let me know. > > ... > dev-libs/gnulib This one has only prefix keywords and is maintained by prefix@. It has a recentish EAPI=6 version.
[gentoo-dev] acct-{user,group}/i2p request for 493
Hello,
`net-vpn/i2p` currently adds a "i2p" user and group with a random
uid/gid; it needs to run a daemon. I'm the proxy-maint for it so I
created acct-{user,group}/i2p and assigned 493:493 which are free
according to https://api.gentoo.org/uid-gid.txt
If that's good for you, the PR waiting validation is there
https://github.com/gentoo/gentoo/pull/12785
Thanks.
--
Valérian Rousset
[gentoo-dev] [PATCH] acct-group/plugdev: Introduce new group (GID 272)
Signed-off-by: Michał Górny --- acct-group/plugdev/metadata.xml | 8 acct-group/plugdev/plugdev-0.ebuild | 9 + 2 files changed, 17 insertions(+) create mode 100644 acct-group/plugdev/metadata.xml create mode 100644 acct-group/plugdev/plugdev-0.ebuild diff --git a/acct-group/plugdev/metadata.xml b/acct-group/plugdev/metadata.xml new file mode 100644 index ..0319eec4c8be --- /dev/null +++ b/acct-group/plugdev/metadata.xml @@ -0,0 +1,8 @@ + +http://www.gentoo.org/dtd/metadata.dtd";> + + + mgo...@gentoo.org + Michał Górny + + diff --git a/acct-group/plugdev/plugdev-0.ebuild b/acct-group/plugdev/plugdev-0.ebuild new file mode 100644 index ..14c2c876eedf --- /dev/null +++ b/acct-group/plugdev/plugdev-0.ebuild @@ -0,0 +1,9 @@ +# Copyright 2019 Gentoo Authors +# Distributed under the terms of the GNU General Public License v2 + +EAPI=7 + +inherit acct-group + +DESCRIPTION="Group controlling access to removable media" +ACCT_GROUP_ID=272 -- 2.23.0
Re: [gentoo-dev] acct-{user,group}/i2p request for 493
> On Sat, 31 Aug 2019, Tharrvik wrote:
> `net-vpn/i2p` currently adds a "i2p" user and group with a random
> uid/gid; it needs to run a daemon. I'm the proxy-maint for it so I
> created acct-{user,group}/i2p and assigned 493:493 which are free
> according to https://api.gentoo.org/uid-gid.txt
We had skipped 493 and 492 previously, because Archlinux uses them for
oidentd and oprofile (which we also have as packages, so they'll have
to be converted to the new scheme).
AFAICS, 484 would be the next free number (when counting down from 499).
Ulrich
signature.asc
Description: PGP signature
Re: [gentoo-dev] acct-{user,group}/i2p request for 493
> On Sat, 31 Aug 2019, Ulrich Mueller wrote: > AFAICS, 484 would be the next free number (when counting down from 499). I just see that i2pd has 470, maybe take the adjacent 471? signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Mass last-riting of x86-but-not-amd64 packages
On Sat, Aug 31, 2019 at 1:04 AM Michał Górny wrote: > sys-fs/hfsplusutils Your script should probably check for other keywords as well. This package is almost entirely for use on ppc/ppc64 machines. For whatever reason it has an x86 keyword as well, so the lack of an amd64 keyword doesn't indicate that it should be removed.
Re: [gentoo-dev] [RFC] Mass last-riting of x86-but-not-amd64 packages
On Sat, 2019-08-31 at 13:14 -0700, Matt Turner wrote: > On Sat, Aug 31, 2019 at 1:04 AM Michał Górny wrote: > > sys-fs/hfsplusutils > > Your script should probably check for other keywords as well. This > package is almost entirely for use on ppc/ppc64 machines. For whatever > reason it has an x86 keyword as well, so the lack of an amd64 keyword > doesn't indicate that it should be removed. > I've already removed it from the list, along with other packages that have revdeps. However, I don't think that's a really good argument. Many ancient packages have x86 and ppc keywords which doesn't make them any less dead. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] Mass last-riting of x86-but-not-amd64 packages
On Sat, 31 Aug 2019 10:03:47 +0200 Michał Górny wrote: > dev-games/flinker This builds and starts on amd64 but I'm dubious about whether it would work correctly in practise. I don't imagine anyone will want to use it. Best just let it die. > dev-games/gtkradiant This has been superseded a few times over and the current fork is NetRadiant-custom. There is an open bug about the older NetRadiant but I only dabbled in Quake mapping so never cared enough. https://bugs.gentoo.org/352981 > dev-games/hlsdk This is a remnant of the Half-Life server stuff that vapier removed in 2005 with the message "valve sucks at linux". I could say more about it but nobody cares. > games-action/battalion > games-action/fakk2 > games-action/postalplus > games-arcade/epiar > games-arcade/gunocide2ex > games-emulation/mekanix > games-fps/aaut > games-fps/industri > games-fps/red-blue-quake2 > games-fps/tenebrae > games-fps/tribes2 > games-fps/unreal-tournament-strikeforce > games-fps/ut2003-bonuspack-cm > games-fps/ut2003-bonuspack-de > games-fps/ut2003-bonuspack-epic > games-fps/wolfgl > games-misc/c++robots > games-roguelike/hengband > games-server/bf1942-lnxded > games-server/mtavc > games-strategy/mindrover-demo > games-strategy/netpanzer I'll try to look through some of these. I still care about UT and even worked on (but didn't finish) a new UT99 ebuild not so long ago. Unfortunately it's never been a top priority. > sys-fs/atari-fdisk This is still usable on m68k, which is the Atari's own architecture. The code assumes 32-bit longs so it won't work on 64-bit but it probably wouldn't be that hard to fix if someone cared enough. I'm interested in m68k but for the Amiga rather than the Atari. I'm not sure how useful this is in practise. On the Amiga, I would still use the AmigaOS partitioning tool over something like this. There is no replacement for the Atari on Linux as far as I can see though so I think it should stay. -- James Le Cuirot (chewi) Gentoo Linux Developer pgp9QsRuUlfe4.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 3/5] www-apps/gitea: Use acct-{group,user}/git
On Sat, 2019-08-17 at 17:29 -0400, Michael Orlitzky wrote: > On 8/17/19 4:43 PM, Michał Górny wrote: > > > I realize we'd have to tell people how to rename the account to support > > > upgrades -- but is there some other reason to keep the shared "git" name? > > > > The argument I've been told is that users expect 'git@...' to work > > as remote URI on their boxes. They don't want users to bind the URI to > > specific implementation. > > > > It's not really a URI... it's a username on a remote machine. And these > "users" are programmers =P > > But, I can understand not wanting to tell a bunch of strangers to edit > all of their ~/.git/config files at this point. > > Instead of configuring both packages to use different users, could we > configure them to share a working directory? If we give the "git" user a > home directory of /var/lib/git [0], then as far as I can tell, both > gitolite and gitea will be happy with that. They use different > configuration file names and repository locations, and wouldn't need to > block each other. It is an interesting concept. However, it assumes that all existing installations need to be migrated to the new directory, and I don't think it's safe to try to do it automatically. So it really sounds like we're a. adding extra work on sysadmins, and b. breaking stuff on upgrade, on the vast majority of production systems that only care about having one of them installed. > > > [0] This doesn't violate the guidelines that I posted since real humans > log in as this account to clone repos out of $HOME. Moreover, I don't > think that either gitolite or gitea references this path itself -- it > really belongs to the user. > > -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
