Re: [gentoo-dev] Last rites: dev-python/* leaf packages
On Thu, 2019-12-05 at 03:56 +0100, Thomas Deutschmann wrote: > Hi, > > On 2019-12-05 01:15, Aaron Bauman wrote: > > * Removal in 30 days > > Why? I understand that Py2 will reach EOL upstream status but we all > know that Py2 will *not* disappear and stop working in 26 days... > > There's no reason to mask/remove currently known working software. > Yes, there is. Not saying about any particular package out there but the Python team is *overwhelmed*. We can't reasonably be expected to maintain 1200+ packages, many of them requiring a lot of work. It's easy to claim everything is all right without actually working on it. Many of those packages may not pose problems in the next weeks. Some of them probably already take part in the big 'target mishap' when their dependencies dropped py2 support, and more will in the coming weeks, months. Now imagine that 500+ packages are depending on pytest that doesn't support py2 anymore. And that number is probably far smaller than reality because a lot of packages are bad quality and don't run tests at all. You people need to start thinking of terms of real benefit to users. Keeping old, unmaintained, semi-broken packages has little benefit to users. Quadruplicating maintenance burden effectively harms *active* packages, and that is much more painful to users. Do you think we'd be stuck with unmaintained Python 3.6 in stable if people actively kicked stuff we can't maintain? Do you think we'd be stuck with Python 3.7 packages being *unkeyworded* on almost all arches? -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Last rites: dev-python/* leaf packages
On 05.12.19 01:15, Aaron Bauman wrote: > Fellow devs, [...] > net-misc/trackma > dev-python/inotifyx > dev-python/disqus-python > dev-python/figleaf > dev-python/pysvg a python-3 version is available at: https://github.com/alorence/pysvg-py3 https://pypi.org/project/pysvg-py3/ > dev-python/sphinxcontrib-ditaa > dev-python/pyrax > dev-python/tgmochikit [...] Best regards, Poncho
Re: [gentoo-dev] Last rites: dev-python/* leaf packages
On 2019-12-05 04:06, William Hubbs wrote: > On Thu, Dec 05, 2019 at 03:56:05AM +0100, Thomas Deutschmann wrote: >> On 2019-12-05 01:15, Aaron Bauman wrote: >>> * Removal in 30 days >> >> Why? I understand that Py2 will reach EOL upstream status but we all >> know that Py2 will *not* disappear and stop working in 26 days... >> >> There's no reason to mask/remove currently known working software. >> >> net-nntp/sabnzbd is a perfect example. Up to date in repository and working. First, this was just an example. For sabnzbd I know that upstream is working on Py3 support. It will happen somewhere in 2020... I expect this for most software still in use. My point was a general note: I don't understand why we should rush and kick out software without Py3 support *yet* when Py2 is still a thing. Sure, we will reach the point when Py2 is only needed by 1-2 packages and at this point we can start discussing to drop them including entire Py2 support. But this will take 1-2 years... I mean: OpenSSL-1.0.2x will go EOL on 2019-12-31... I don't see us masking Are you volunteering to maintain it or open an upstream bug and askthem > to move to py3? ...and sometimes I am also just a user. I cannot maintain all software I use :-) -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites: dev-python/* leaf packages
On Thu, Dec 05, 2019 at 03:56:05AM +0100, Thomas Deutschmann wrote: > Hi, > > On 2019-12-05 01:15, Aaron Bauman wrote: > > * Removal in 30 days > > Why? I understand that Py2 will reach EOL upstream status but we all > know that Py2 will *not* disappear and stop working in 26 days... > > There's no reason to mask/remove currently known working software. > > net-nntp/sabnzbd is a perfect example. Up to date in repository and working. Are you volunteering to maintain it or open an upstream bug and askthem to move to py3? I tend to think that we should either get py2 only software to move to py3 or remove it. William signature.asc Description: Digital signature
Re: [gentoo-dev] Last rites: dev-python/* leaf packages
Hi, On 2019-12-05 01:15, Aaron Bauman wrote: > * Removal in 30 days Why? I understand that Py2 will reach EOL upstream status but we all know that Py2 will *not* disappear and stop working in 26 days... There's no reason to mask/remove currently known working software. net-nntp/sabnzbd is a perfect example. Up to date in repository and working. -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites: dev-python/* leaf packages
On 05.12.2019 01:15, Aaron Bauman wrote: dev-python/nototools media-fonts/noto-emoji ^ these two recent-ish gained python3 support upstream in a new released version
Re: [gentoo-dev] Last rites: dev-python/* leaf packages
On Thu, Dec 05, 2019 at 12:28:04AM +, Michael 'veremitz' Everitt wrote: > On 05/12/19 00:15, Aaron Bauman wrote: > > Fellow devs, > > > dev-python/sqlitecachec > > dev-python/supervisor-quick > > dev-python/python-cdb > > dev-python/fabric > ^ https://github.com/mathiasertl/fabric/ is a fork of fabric for py3.4+ > FYI. Also on PyPi at https://pypi.org/project/Fabric3/. > > dev-python/foolscap > > net-fs/tahoe-lafs > > dev-python/pyvtk > > > HTH, > veremitz/Michael. > Ah, you found a false positive as well. Fixing it up now. -- Cheers, Aaron signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites: dev-python/* leaf packages
On 05/12/19 00:15, Aaron Bauman wrote: > Fellow devs, > dev-python/sqlitecachec > dev-python/supervisor-quick > dev-python/python-cdb > dev-python/fabric ^ https://github.com/mathiasertl/fabric/ is a fork of fabric for py3.4+ FYI. Also on PyPi at https://pypi.org/project/Fabric3/. > dev-python/foolscap > net-fs/tahoe-lafs > dev-python/pyvtk HTH, veremitz/Michael. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-python/* leaf packages
Fellow devs, * These packages are (mostly) leaf dev-python/* packages which have no py3 impl in the ebuild * Packages not from dev-python/* are preceded by the relevevant dev-python/* pkg which caused the package to be masked. * This is just the "tip of the iceberg" of py2 only packages. As such, due to the sheer number of packages, it is nearly impossible for any one person or project to address them all. * Many of these packages are likely not needed, but some will be. If you find a package that is needed please update/port/fix the ebuild/src to support py3 * This is not a "go fix it or it dies" stance. If you can please assist in identifying which packages have upstream supported py3 impls please feel free to ping me to support porting the ebuild. * There may be false positives. Sorry about that. Feel free to adjust the mask and remove any py2 only ebuilds (e.g. multiple versions/revisions of ebuilds and one of them only supports py2) * Removal in 30 days Always happy to help/assist in keeping things moving along within Gentoo. - net-misc/trackma dev-python/inotifyx dev-python/disqus-python dev-python/figleaf dev-python/pysvg dev-python/sphinxcontrib-ditaa dev-python/pyrax dev-python/tgmochikit dev-python/pyndex dev-python/nototools media-fonts/noto-emoji dev-python/python-mhash dev-python/guppy dev-python/dib-utils dev-python/py-notify x11-misc/magick-rotation dev-python/superlance dev-python/rlcompleter2 dev-python/pylibpcap dev-python/libextractor-python dev-python/happydoc dev-python/irman-python dev-python/python-recaptcha dev-python/dirq dev-python/ropemacs dev-python/lp_solve dev-python/stapler dev-python/flask-dashed dev-python/buzhug dev-python/pyao dev-python/libiscsi-python dev-python/ushlex dev-python/hcluster dev-python/lupy dev-python/snakefood dev-python/sqlitecachec dev-python/supervisor-quick dev-python/python-cdb dev-python/fabric dev-python/foolscap net-fs/tahoe-lafs dev-python/pyvtk dev-python/pycdio media-sound/whipper dev-python/hachoir-regex app-misc/hachoir-subfile dev-python/pymad dev-python/audioread dev-python/pyacoustid media-sound/beets dev-python/numdisplay dev-python/python-fastcgi dev-python/workerpool dev-python/eyeD3 media-sound/abcde media-sound/gpodder dev-python/py-smbpasswd dev-python/cherrytemplate dev-python/python-catcher dev-python/pystatgrab dev-python/pp dev-python/keyczar dev-python/keyrings_alt dev-util/Orange dev-python/python-exconsole dev-python/ttfquery dev-python/pyoembed www-apps/blohg-tumblelog dev-python/webhelpers dev-python/optcomplete dev-python/hcs-utils dev-python/python-prctl net-p2p/pybitmessage dev-python/asciitree net-misc/irrtree dev-python/python-pluginloader dev-vcs/hg-fast-export dev-python/pychef dev-python/mwlib-ext dev-python/vatnumber dev-python/pyml dev-python/bicyclerepair dev-python/cement app-misc/yworklog net-misc/pycnb dev-python/turbolift dev-python/PyZilla dev-python/pydvdread dev-python/m2secret dev-python/pyPdf app-text/pdfshuffler dev-python/hp3parclient dev-python/clientcookie dev-python/python-pam dev-python/python-caja dev-vcs/rabbitvcs dev-python/louie dev-python/graphy net-analyzer/namebench dev-python/gdmodule dev-python/pythonutils net-nntp/sabnzbd dev-python/qserve dev-python/pyifp dev-python/telarchive dev-python/XenAPI dev-python/sudsds dev-python/webpy dev-python/slowaes dev-python/beanstalkc dev-python/PySensors dev-python/RecSQL dev-python/pyclamav dev-python/pycdf dev-python/libnatpmp dev-python/sabyenc dev-python/weberror dev-python/sancho dev-python/jonpy dev-python/pyelemental dev-python/sclapp dev-python/pynag dev-python/newt_syrup dev-python/stripogram dev-python/anyvc dev-python/simplesettings dev-python/pykota net-print/pykota dev-python/ropeide dev-python/pycryptopp net-fs/tahoe-lafs dev-python/piddle dev-python/python-oembed dev-python/log4py dev-python/htmlgen dev-python/pyamf -- Cheers, Aaron signature.asc Description: PGP signature
Re: [gentoo-dev] Usefulness of HOMEPAGE=https://www.gentoo.org
On Wed, Dec 4, 2019 at 9:26 AM Michał Górny wrote: > On Wed, 2019-12-04 at 17:24 +0200, Joonas Niilola wrote: > > On 12/4/19 5:21 PM, Kent Fredric wrote: > > > On Wed, 04 Dec 2019 13:36:07 +0100 > > > Michał Górny wrote: > > > > > > > My point is: gentoo.org as a HOMEPAGE sucks. Please use something > more > > > > specific instead. Even link to gitweb would be more helpful because > it > > > > would at least be relevant to the package in question. > > > I agree so much I would support the addition of a QA check for this. > > > > > I take it you haven't checked the CI results lately? Reaction to that > > probably spawned this ML thread. > > > > https://qa-reports.gentoo.org/output/gentoo-ci/output.html > > Actually, I've requested that check. However, I didn't expect that many > packages to be affected. > > Given that it's open season on me lately, and apparently people feel > offended when bugs are reported for their packages, I've decided to > start by trying to make people realize the problem globally first. > When QA was run by Diego, he suffered some of the same problems. A lot of this comes down to three factors (IMHO.) - Lack of buy-in from developers. When you add a QA thing, you are asking people to do more work. If they don't agree with the work, they have no real incentive to do it. I don't see a lot of incentive building here and so for some efforts adoption of fixes is slow / low. In addition, expectations are often not set (at all[1]) or not shared with the group (e.g. QA and the community disagree on the expectation; often in relation to timelines or end goals.) - The above leads to the stick instead of the carrot. Instead of helping people adhere to the policy and recruiting the community to do the work, QA takes an adversarial approach where the policy is wielded as a cudgel to 'force' people to do the work. This then leads to the comments like the above (e.g. "its open season on mgorny") because often forcing people to do work on a tight timetable does not generate trust or goodwill and encourages the adversarial relationship between the community and QA. - This perception that perfection is required and imperfect packages are ripe for removal. This again creates this air of anxiety between a package maintainer and QA where QA can basically invent new reasons to mask arbitrary[0] packages. -A [0] I'm not suggesting this is the intent of the QA team, but it's one narrative that a non-QA member might have and the QA team is fairly adversarial and often takes little action to dissuade this narrative from taking hold. [1] Some good examples are things like EAPI deprecation https://archives.gentoo.org/gentoo-dev/message/aef37db23c862865fffdd24071fce1ec. You notice that Andreas has articulated some goal (no more EAPI2), has clearly specified the packages that need work, and has encouraged people to help achieve the goal. Even the tone is positive. I want to help! This is different from messaging like "Hey you have 7 days to fix your EAPI2 packages or I will mask them!". This may encourage me to save my packages (from the evil QA team) but it doesn't make me love the QA team at all; it makes me feel negative feelings. > -- > Best regards, > Michał Górny > >
Re: [gentoo-dev] Usefulness of HOMEPAGE=https://www.gentoo.org
On 12/4/19 7:26 PM, Michał Górny wrote: > On Wed, 2019-12-04 at 17:24 +0200, Joonas Niilola wrote: >> On 12/4/19 5:21 PM, Kent Fredric wrote: >>> On Wed, 04 Dec 2019 13:36:07 +0100 >>> Michał Górny wrote: >>> My point is: gentoo.org as a HOMEPAGE sucks. Please use something more specific instead. Even link to gitweb would be more helpful because it would at least be relevant to the package in question. >>> I agree so much I would support the addition of a QA check for this. >>> >> I take it you haven't checked the CI results lately? Reaction to that >> probably spawned this ML thread. >> >> https://qa-reports.gentoo.org/output/gentoo-ci/output.html > Actually, I've requested that check. However, I didn't expect that many > packages to be affected. > > Given that it's open season on me lately, and apparently people feel > offended when bugs are reported for their packages, I've decided to > start by trying to make people realize the problem globally first. That's a nice initiatitve. Overall I feel like (global) future CI checks should be discussed first, because they affect everyone who's committing, and it feels weird starting to suddenly receive mails about things you've pushed a hundred times before. As seen by the evergrowing list of new warnings, people just start to ignore these new checks or "fix it on next version bump", because knowledge wasn't there on a previous one. -- juippis signature.asc Description: OpenPGP digital signature
[gentoo-dev] RFC: request IDs for u:oidentd g:oidentd
Hello, given the discussion around the IDs a few days ago, i'd like to request 493 as UID and GID for the package net-misc/oidentd. reasoning being this is the one used in Arch. Others either use next available (Fedora) or nobody:nobody (SuSE) Thanks, Robert
Re: [gentoo-dev] Usefulness of HOMEPAGE=https://www.gentoo.org
On Wed, 2019-12-04 at 17:24 +0200, Joonas Niilola wrote: > On 12/4/19 5:21 PM, Kent Fredric wrote: > > On Wed, 04 Dec 2019 13:36:07 +0100 > > Michał Górny wrote: > > > > > My point is: gentoo.org as a HOMEPAGE sucks. Please use something more > > > specific instead. Even link to gitweb would be more helpful because it > > > would at least be relevant to the package in question. > > I agree so much I would support the addition of a QA check for this. > > > I take it you haven't checked the CI results lately? Reaction to that > probably spawned this ML thread. > > https://qa-reports.gentoo.org/output/gentoo-ci/output.html Actually, I've requested that check. However, I didn't expect that many packages to be affected. Given that it's open season on me lately, and apparently people feel offended when bugs are reported for their packages, I've decided to start by trying to make people realize the problem globally first. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Usefulness of HOMEPAGE=https://www.gentoo.org
On Wed, 4 Dec 2019 17:24:54 +0200 Joonas Niilola wrote: > I take it you haven't checked the CI results lately? Reaction to that > probably spawned this ML thread. In that case, good work :) pgp3S4GcNB4R5.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Usefulness of HOMEPAGE=https://www.gentoo.org
On 12/4/19 5:21 PM, Kent Fredric wrote: > On Wed, 04 Dec 2019 13:36:07 +0100 > Michał Górny wrote: > >> My point is: gentoo.org as a HOMEPAGE sucks. Please use something more >> specific instead. Even link to gitweb would be more helpful because it >> would at least be relevant to the package in question. > I agree so much I would support the addition of a QA check for this. > I take it you haven't checked the CI results lately? Reaction to that probably spawned this ML thread. https://qa-reports.gentoo.org/output/gentoo-ci/output.html signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Usefulness of HOMEPAGE=https://www.gentoo.org
On Wed, 04 Dec 2019 13:36:07 +0100 Michał Górny wrote: > My point is: gentoo.org as a HOMEPAGE sucks. Please use something more > specific instead. Even link to gitweb would be more helpful because it > would at least be relevant to the package in question. I agree so much I would support the addition of a QA check for this. A page on wiki.gentoo.org would be in every way superior if there's no other good alternative. pgpNRAeRiw91q.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Re: HOMEPAGE and DESCRIPTION in ebuilds? (was: Usefulness of HOMEPAGE=https://www.gentoo.org)
On Wed, 4 Dec 2019 13:44:22 +0100
Miroslav Šulc wrote:
> it's proly little bit off this topic, but why do we have to copy
> homepage and description from ebuild to ebuild? wouldn't it be better to
> move this information to metadata.xml and keep it just there? or does in
> reality one package really have various homepages and various
> descriptions for different versions? metadata.xml could also contain
> more structured data like you outlined, i.e. link to homepage,
> sources/repository, bug tracker and possibly other.
Also, widespread in usage in dev-perl/, the homepage can be reasonably
defaulted, and so, 99% of ebuilds there have a HOMEPAGE value
conjugated from ${PN}
Can't reasonably do that in metadata.xml
So any proposal that involves metadata.xml must allow for it being an
auxiliary to the value in the ebuild
( ie: if there is a HOMEPAGE in the ebuild, it should take precedence
over reading metadata.xml )
pgpToaepYq4jW.pgp
Description: OpenPGP digital signature
Re: [gentoo-dev] Usefulness of HOMEPAGE=https://www.gentoo.org
On Wed, 2019-12-04 at 13:36 +0100, Michał Górny wrote: > My point is: gentoo.org as a HOMEPAGE sucks. Please use something more > specific instead. Even link to gitweb would be more helpful because it > would at least be relevant to the package in question. I've forgot to mention one thing: if you really don't have a proper homepage, then we have the special value of: https://wiki.gentoo.org/wiki/No_homepage which is generally better than gentoo.org in the regard that it explicitly defines the problem. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: HOMEPAGE and DESCRIPTION in ebuilds? (was: Usefulness of HOMEPAGE=https://www.gentoo.org)
On Wed, 2019-12-04 at 13:44 +0100, Miroslav Šulc wrote: > hi, > > it's proly little bit off this topic, but why do we have to copy > homepage and description from ebuild to ebuild? wouldn't it be better to > move this information to metadata.xml and keep it just there? or does in > reality one package really have various homepages and various > descriptions for different versions? metadata.xml could also contain > more structured data like you outlined, i.e. link to homepage, > sources/repository, bug tracker and possibly other. > Inertia. It's been proposed years ago, never moved forward. The relevant bug is here: https://bugs.gentoo.org/186454 If you want to discuss it further, please do it on the bug (even though it's closed). -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: HOMEPAGE and DESCRIPTION in ebuilds? (was: Usefulness of HOMEPAGE=https://www.gentoo.org)
hi, it's proly little bit off this topic, but why do we have to copy homepage and description from ebuild to ebuild? wouldn't it be better to move this information to metadata.xml and keep it just there? or does in reality one package really have various homepages and various descriptions for different versions? metadata.xml could also contain more structured data like you outlined, i.e. link to homepage, sources/repository, bug tracker and possibly other. miroslav Dne 04. 12. 19 v 13:36 Michał Górny napsal(a): Hi, Many of Gentoo-originating packages are listing the main Gentoo site as HOMEPAGE. In my opinion, this is suboptimal (not to say 'useless'). I can think of a few uses for HOMEPAGE: 1. providing additional information about the package (before the user chooses it), 2. providing easy access to (additional) documentation, 3. providing easy access to package sources, 4. providing easy access to bug reporting, 5. providing easy access to downloads. A good HOMEPAGE is dedicated to the package in question, and makes it easy to find all the stuff (and all other stuff the user might need). The more effort user needs to put into finding what he needs, the worse HOMEPAGE is. Now, if I consider gentoo.org as a HOMEPAGE for ~90 packages it currently is, it's horribly bad. I suppose that in some cases authors meant to indicate that Gentoo is the package's upstream. However, by going to the main Gentoo site, it's *very hard* to find anything about the package in question. Just please select a totally random package from those listing gentoo.org as HOMEPAGE, then go to gentoo.org and try to find either of the points listed above. If you click 'Downloads', you're certainly not going to find anything relevant. Through 'Support', you may eventually find that tiny Bugzilla button at the bottom... and then try to find the correct Product. You may also find gitweb link somewhere, and try to see if the project has a repo there. Or maybe it's somewhere else, or maybe it existed on somebody's devspace once. My point is: gentoo.org as a HOMEPAGE sucks. Please use something more specific instead. Even link to gitweb would be more helpful because it would at least be relevant to the package in question.
[gentoo-dev] Usefulness of HOMEPAGE=https://www.gentoo.org
Hi, Many of Gentoo-originating packages are listing the main Gentoo site as HOMEPAGE. In my opinion, this is suboptimal (not to say 'useless'). I can think of a few uses for HOMEPAGE: 1. providing additional information about the package (before the user chooses it), 2. providing easy access to (additional) documentation, 3. providing easy access to package sources, 4. providing easy access to bug reporting, 5. providing easy access to downloads. A good HOMEPAGE is dedicated to the package in question, and makes it easy to find all the stuff (and all other stuff the user might need). The more effort user needs to put into finding what he needs, the worse HOMEPAGE is. Now, if I consider gentoo.org as a HOMEPAGE for ~90 packages it currently is, it's horribly bad. I suppose that in some cases authors meant to indicate that Gentoo is the package's upstream. However, by going to the main Gentoo site, it's *very hard* to find anything about the package in question. Just please select a totally random package from those listing gentoo.org as HOMEPAGE, then go to gentoo.org and try to find either of the points listed above. If you click 'Downloads', you're certainly not going to find anything relevant. Through 'Support', you may eventually find that tiny Bugzilla button at the bottom... and then try to find the correct Product. You may also find gitweb link somewhere, and try to see if the project has a repo there. Or maybe it's somewhere else, or maybe it existed on somebody's devspace once. My point is: gentoo.org as a HOMEPAGE sucks. Please use something more specific instead. Even link to gitweb would be more helpful because it would at least be relevant to the package in question. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
