[gentoo-dev] Last rites: dev-python/drpython
# Virgil Dupras (24 May 2019) # py2 only, dead upstream, removal in 30 days. Bug #686668 dev-python/drpython pgpplxTItGgDM.pgp Description: PGP signature
[gentoo-dev] Last-rites: dev-python/detox
# Virgil Dupras (13 May 2019) # detox has been deprecated by the release of tox 3.7.0 which duplicates the # feature. Removal in 30 days. Bug #685870 dev-python/detox pgpcKi494VVKd.pgp Description: PGP signature
Re: [gentoo-dev] dev-python/fabric up for grabs
On Sat, 11 May 2019 09:52:11 +0200 Dennis Schridde wrote: > Hi Virgil! > > On Freitag, 10. Mai 2019 20:21:49 CEST Virgil Dupras wrote: > > As soon as the needs go over a bash script, there are much better tools out > > there for the job. > > Which tools do you recommend? > > --Dennis Although I don't use it anymore because I find it too heavy for my needs, Ansible is generally seen as a good replacement. Virgil pgpcUWdSIjhCc.pgp Description: PGP signature
[gentoo-dev] dev-python/fabric up for grabs
I'd like to last rite it but I thought I'd ask around and see if anyone use this. This package was popular in its first incarnation (py2 only) and I personally used it, but the v2 rewrite is really bad, doesn't have a good migration path for v1 scripts, and there's no point in using this over a simple bash script for new projects. As soon as the needs go over a bash script, there are much better tools out there for the job. With py2 going dark, if nobody uses its v2, there's no point in keeping it around. Unless someone is interested... pgp7_r_xn_tf9.pgp Description: PGP signature
[gentoo-dev] dev-python/pytest-relaxed: last rites
# Virgil Dupras (10 May 2019) # Has very limited use and is disruptive of other tests when activated. # Bug #685538. Removal in 30 days. dev-python/pytest-relaxed pgpCuz94uIQY_.pgp Description: PGP signature
[gentoo-dev] dev-python/djangocms-attributes-field: last rites
# Virgil Dupras (26 Apr 2019) # Should have been removed with django-cms a while back but wasn't. # Removal in 30 days. Bug #683862 dev-python/djangocms-attributes-field pgpvoE5tur7J9.pgp Description: PGP signature
[gentoo-dev] dev-python/yapps: last rites
# Virgil Dupras (26 Apr 2019) # Unmaintained, no revdeps. Removal in 30 days. Bug #618734 dev-python/yapps pgpretAlpgCq_.pgp Description: PGP signature
[gentoo-dev] dev-python/readme: last rites
# Virgil Dupras (12 Apr 2019) # Dead upstream, no revdeps. # Removal in 30 days. Bug #683146 dev-python/readme pgpnxZeq8JgQ9.pgp Description: PGP signature
[gentoo-dev] Last rites: dev-python/statistics and dev-python/reverend
# Virgil Dupras (31 Mar 2019) # Unmaintained, no revdeps. # Removal in 30 days. Bug #616596 dev-python/statistics dev-python/reverend pgp0lauMoAgWp.pgp Description: PGP signature
[gentoo-dev] Last rites: dev-python/pytest-capturelog
# Virgil Dupras (10 Mar 2019) # Merged in pytest, no revdep. Removal in 30 days. Bug #668746 dev-python/pytest-capturelog pgpjinFAIHOD9.pgp Description: PGP signature
[gentoo-dev] Last rites: dev-python/fusil
# Virgil Dupras (27 Jan 2019) # Dead upstream, no revdep. bug #618744 dev-python/fusil pgp37Tfj8hvx5.pgp Description: PGP signature
[gentoo-dev] Last rites: dev-python/python-social-auth and dev-python/python3-openid
# Virgil Dupras (27 Jan 2019) # Obsolete upstream. See bug #610466 and bug #645170 dev-python/python-social-auth dev-python/python3-openid pgpkHp77iupmc.pgp Description: PGP signature
Re: netsurf Prefix breakage (Was: [gentoo-dev] Packages up for grabs from xmw@g.o)
On Mon, 26 Nov 2018 20:34:56 +0800 Benda Xu wrote: > This is a serious regression for Prefix and caught a lot of users > without a warning. Could you please discuss on this kind of changes in > the mailing list beforehand? Discussing this change on the list? I haven't touched the eclass, I simply fixed the xmw-abandoned netsurf package which had been broken for 3 months prior to that (and by broken, I don't mean only on Prefix. Why talk about 1-1 features in those situations?). Fixing packages without touching eclasses doesn't require gentoo-dev review. Also, netsurf doesn't have any prefix keyword. Some of the lower-level libs have ~m68k-mint, but it isn't clear why because the only non-netsurf revdep to those libs is net-libs/libwebsockets and it isn't keyworded for prefix either. Please, open a ticket on the appropriate package with a description of an actual breakage and I'll be deligthed to address it. Regards, Virgil pgpafpvucDBRx.pgp Description: PGP signature
Re: [gentoo-dev] Packages up for grabs from xmw@g.o
On Sun, 25 Nov 2018 11:52:19 +0100 Michał Górny wrote: > Also, it missed the eclass: > > netsurf.eclass I've been getting rid of netsurf.eclass' usage. This can soon be last-rited. Only two-stabilizations away from that goal. Virgil pgpfoAcVCVzAq.pgp Description: PGP signature
[gentoo-dev] Last rites: dev-python/django-cms and related
# Virgil Dupras (14 Nov 2018) # Unmaintained and depending on an purged version (1.8) of Django. # Removal in 30 days. bug #664012 dev-python/django-cms dev-python/djangocms-admin-style dev-python/djangocms-file dev-python/djangocms-flash dev-python/djangocms-inherit dev-python/djangocms-link dev-python/djangocms-picture dev-python/djangocms-snippet dev-python/djangocms-teaser dev-python/djangocms-video dev-python/django-classy-tags dev-python/django-formtools dev-python/djangocms-text-ckeditor dev-python/django-sekizai dev-python/django-treebeard dev-python/aldryn-search dev-python/aldryn-bootstrap3 dev-python/django-filer dev-python/django-mptt pgpvX1IwCYI3a.pgp Description: PGP signature
Re: [gentoo-dev] Is there any way I can help with pull requests?
On Sat, 13 Oct 2018 20:18:06 +0200 Ralph Seichter wrote: > Glancing at my own open pull requests, it looks different (opened 15 and > 25 days ago, respectively). That is not meant as criticism; it just seems > to me that the team members who process PRs have a lot on their plates. Maybe I can try to explain why your 3 PRs [1] are still opened. The "skel.ebuild" one is easy: global changes have to be discussed on gentoo-dev. That the mailing list was recently whitelisted makes this harder than it should for non-devs. I believe such PRs take us by surprise and we don't have an efficient process for them. Areas for enhancement. The milter-regex one is, I think, a result of miscommunicating intent. zlogene does a great job on PRs by going over nearly all of them to catch obvious style problems. That you corrected them is good, but it doesn't mean that it's going to be merged anytime soon because this package is a net-mail package. Someone from that project [2] is going to have merge it, not zlogene. This is a tricky problem because it's completely understandable that you expect a timely response to your correction, but ultimately, you'll have to nudge someone from the net-mail project. But to know why you don't get a timely response, you need to intimately understand Gentoo's inner dynamics, which you can't. So, you think we rudely ignore you. But we don't, you're just lost in a Kafkaesque maze! Then, we're left with your nginx-unit PR, which is part of the proxy-maint program. Normally, those are well handled. In this case, we have mgorny who doesn't seem to like your PR. Devs tend to trust mgorny's judgement. It doesn't mean that he's right in this instance, but it adds a level of difficulty to the PR. The next dev to review this PR will have to be extra thorough with it if it's going to infirm mgorny's judgement. This places it in the "tricky PRs" mental bucket for, I guess, many proxy-maint members and it means that easier PRs will be processed before it. Sorry, it seems that you picked a tough package to be proxied-maintainer for. As I hope to have demonstrated, there is no ill intent or even negligence in the result that you observe. It's just that our processes are complex and far from perfect, and the workload, significant. In the end, I think, the best thing to do in most cases is to ping a dev after a reasonable timeout. We're mostly well intended and will take steps to minimize frustrations when we're made aware of them. Regards, Virgil [1]: https://github.com/gentoo/gentoo/pulls/rseichter [2]: https://wiki.gentoo.org/wiki/Project:Net-Mail pgpeHWvdV6kHH.pgp Description: PGP signature
[gentoo-dev] Last rites: dev-python/django-extensions (and friends)
# Virgil Dupras (15 Oct 2018) # Unmaintained, no revdep. Removal in 30 days. Bug #650048 dev-python/django-extensions dev-python/shortuuid dev-python/fexpect pgpiTeaLMzFSi.pgp Description: PGP signature
[gentoo-dev] Last rites: dev-python/jenkinsapi
# Virgil Dupras (12 Oct 2018) # Unmaintained, no revdep. Removal in 30 days. Bug #645384 dev-python/jenkinsapi pgpHv99GpiQ5m.pgp Description: PGP signature
[gentoo-dev] Last rites: dev-python/twill
# Virgil Dupras (12 Oct 2018) # Dead upstream, unmaintained, no revdep. Removal in 30 days. # Bug #285169 dev-python/twill dev-python/flask-testing pgpPN3DapwaK8.pgp Description: PGP signature
[gentoo-dev] Last rites: net-libs/libgcal
# Virgil Dupras (11 Oct 2018) # Dead upstream, unmaintained, no revdep. Removal in 30 days. # Bug #659532 net-libs/libgcal pgpG5rFWn0DSx.pgp Description: PGP signature
[gentoo-dev] Last rites: dev-libs/MicroJSON
# Virgil Dupras (11 Oct 2018) # Unmaintained, no revdep. Removal in 30 days. # Bug #661554 Bug #661552 dev-libs/MicroJSON dev-libs/UTF8Strings pgpW27TEA8__V.pgp Description: PGP signature
[gentoo-dev] Last rites: dev-python/stormpath
# Virgil Dupras (10 Oct 2018) # Unmaintained, no revdep. Removal in 30 days. # Bug #643536 dev-python/stormpath pgpuYAsTwML8C.pgp Description: PGP signature
[gentoo-dev] Last rites: dev-python/flask-restless
# Virgil Dupras (10 Oct 2018) # Dead upstream, depends on broken package. Removal in 30 days. # Bug #620098 dev-python/flask-restless pgp40pbaS18fV.pgp Description: PGP signature
[gentoo-dev] Last rites: app-office/openerp (and orphans)
# Virgil Dupras (07 Oct 2018) # Masked for removal, along with orphans, because it's unmaintained # and vulnerable. Bug #629270 app-office/openerp dev-python/pychart dev-python/pywebdav dev-python/vatnumber pgpLLrSXvkQdk.pgp Description: PGP signature
[gentoo-dev] Last rites: dev-python/recaptcha-client
# Virgil Dupras (30 Sep 2018) # Dead upstream, unmaintained, no revdeps. # Removal in 30 days, bug #611614 dev-python/recaptcha-client pgpNuy208YZe8.pgp Description: PGP signature
[gentoo-dev] Last rites: dev-python/tinydb
# Virgil Dupras (27 Sep 2018) # Outdated, unmaintained, no revdeps. # Removal in 30 days, bug #623292 dev-python/tinydb pgpKfjI02y_ai.pgp Description: PGP signature
[gentoo-dev] Last rites: dev-python/scrapy
# Virgil Dupras (27 Aug 2018) # Unmaintained for a long time, outdated, no revdep. Removal in 30 days. # Bug #626550 dev-python/scrapy dev-python/w3lib dev-python/queuelib pgpBl4qQVwYNE.pgp Description: PGP signature
Re: [gentoo-dev] [PATCH] use.desc: Improve description of USE=test
On Fri, 24 Aug 2018 10:27:01 -0400 Mike Gilbert wrote: > On Fri, Aug 24, 2018 at 9:23 AM Kent Fredric > wrote: > > > > On Tue, 21 Aug 2018 22:29:29 -0400 > > Mike Gilbert wrote: > > > > > Setting RESTRICT="!test? ( test )" is generally sufficient. > > > > But that would require setting that virtually *everything* that has > > both tests, and required dependencies for tests. > > > > Which, in my experience, is practically everything with tests. > > > > To the point it seems like that should be the *default* mechanic, > > not a requirement that everyone pay not to have a randomly broken > > package. > > If you want to define behavior that can be relied upon in ebuilds, it > should be specified in PMS. PMS does not define any meaning for the > "test" USE flag. > Which is the easiest path, updating the PMS or adding RESTRICT="!test? ( test )" to thousands of ebuilds? I don't see how we can realistically hope for every developer to cooperate in making sure that their ebuilds behave properly in "USE=-test" situation. Virgil pgpLpPBsPupc0.pgp Description: PGP signature
[gentoo-dev] Last rites: dev-python/django-pipeline
# Virgil Dupras (12 Aug 2018) # django-pipeline hasn't been maintained and has been broken for a # while. No revdep. Removal in 30 days. Bug #649838 dev-python/django-pipeline pgpzI7wdWd3EO.pgp Description: PGP signature
[gentoo-dev] Last rites: Django 1.8 and revdeps
# Virgil Dupras (02 Aug 2018) # Django 1.8 is unsupported and insecure. These packages haven't been # updated to work with up-to-date django. Removal in 30 days. Bug # #662632 pgpCl5dHuzgzy.pgp Description: PGP signature
Re: [gentoo-dev] [PATCH] virtualx.eclass: support EAPI 7
On Fri, 27 Jul 2018 07:39:10 +0200 Ulrich Mueller wrote: > >>>>> On Thu, 26 Jul 2018, Virgil Dupras wrote: > > > The only adjustment made here is setting BDEPEND instead of DEPEND > > when under EAPI 7. > > There's a third DEPEND assignment which you've missed, at the end of > the optional|tests case. > > Ulrich I skipped it because this case branch is EAPI 4/5 only and BDEPEND doesn't apply. Virgil pgpUj64YEb0Ct.pgp Description: PGP signature
[gentoo-dev] [PATCH] virtualx.eclass: support EAPI 7
The only adjustment made here is setting BDEPEND instead of DEPEND when
under EAPI 7.
(first time trying this, guidance/reviews appreciated, took mgorny's
git-r3 patch as a model)
---
eclass/virtualx.eclass | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/eclass/virtualx.eclass b/eclass/virtualx.eclass
index 38e629eef4f..cd0447a518c 100644
--- a/eclass/virtualx.eclass
+++ b/eclass/virtualx.eclass
@@ -14,7 +14,7 @@ case "${EAPI:-0}" in
0|1|2|3)
die "virtualx.eclass: EAPI ${EAPI} is too old."
;;
- 4|5|6)
+ 4|5|6|7)
;;
*)
die "virtualx.eclass: EAPI ${EAPI} is not supported
yet." @@ -53,7 +53,11 @@ case ${VIRTUALX_REQUIRED} in
manual)
;;
always)
- DEPEND="${VIRTUALX_DEPEND}"
+ if [[ ${EAPI:-0} != [0123456] ]]; then
+ BDEPEND="${VIRTUALX_DEPEND}"
+ else
+ DEPEND="${VIRTUALX_DEPEND}"
+ fi
RDEPEND=""
;;
optional|tests)
@@ -77,7 +81,11 @@ case ${VIRTUALX_REQUIRED} in
IUSE="${VIRTUALX_USE}"
;;
*)
- DEPEND="${VIRTUALX_REQUIRED}? ( ${VIRTUALX_DEPEND} )"
+ if [[ ${EAPI:-0} != [0123456] ]]; then
+ BDEPEND="${VIRTUALX_REQUIRED}? ( $
{VIRTUALX_DEPEND} )"
+ else
+ DEPEND="${VIRTUALX_REQUIRED}? ( $
{VIRTUALX_DEPEND} )"
+ fi
RDEPEND=""
IUSE="${VIRTUALX_REQUIRED}"
;;
--
2.16.4
pgpCWnjNj1PjS.pgp
Description: PGP signature
[gentoo-dev] Last rites: dev-python/django-celery
# Virgil Dupras (22 Jul 2018) # Depends on an unsupported version of django (1.8, will be removed soon) and # is rendered obsolete by the direct inclusion of django support in # >=dev-python/celery-4.0. Removal in 30 days. Bug #661804 dev-python/django-celery pgp2dFzWLY_cr.pgp Description: PGP signature
[gentoo-dev] New "Portage Security" wiki page
Hi everyone, With the recent Github incident, users have (rightfully) voiced concerns about the security of their Gentoo ebuild tree. Luckily, thanks to recent efforts on the repository verification feature, we can answer "yes, it's possible to update your ebuild tree in a convenient and secure manner", but documentation about how to do it is not readily available. I've seen some of these questions only partially answered due to our own lack of knowledge on this subject as developers. To fix this, I've been working, in the last few days, on a new "Portage Security" wiki page [1] that aims to guide the user to a secure setup and dispel doubts about the security of their setup. I would invite you to start pointing users to it when they ask questions on this matter. I'm not a very experienced developer and this has been written with the little knowledge I have, so I invite you to review and correct it if needed. Regards, Virgil Dupras [1]:https://wiki.gentoo.org/wiki/Portage_Security pgpmnmqfeNFCi.pgp Description: PGP signature
Re: [gentoo-dev] The problem of unmaintained packages in Gentoo
On Wed, 20 Dec 2017 17:49:03 +0100 Michał Górny <mgo...@gentoo.org> wrote: > So does anyone have any ideas on what we could realistically do right > now to improve things? Maybe some kind of official overlay for packages needing love? We could send outdated packages there to die or to be born again if the right person picks it up. The overlay could have more relaxed rules (not malicious and looking good? no need to test this, merge!) for PR merging. If the package degrades through bad PRs, fine, let's let it die. If it improves, good, it can be born again. I'm under the impression that such an overlay could release pressure on proxy-maint, allow treecleaners to clean more aggressively while keeping users happy. As a bonus, it could be an interesting path to becoming a gentoo developer. More relaxed rules could mean that anyone could assume maintainership of a dying package without having to wait for someone from proxy-maint to review every little change. This allows the would-be developer to be bolder with changes and prove herself better. (my apologies if this idea is not new, I haven't been following the ML for very long.) Regards, Virgil Dupras
