[gentoo-dev] Last rites: media-libs/libav

2020-03-25 Thread Matt Turner

Acked by lu_zero on IRC.

# Matt Turner  (2020-03-25)
# No releases in two years. No commits in upstream git in last six months.
# Many open security bugs. Masked for removal in 30 days.
media-video/libav
media-libs/libpostproc


signature.asc
Description: PGP signature


[gentoo-dev] Re: [PATCH v2] fixheadtails.eclass: drop the sed dependency

2020-03-25 Thread Mike Gilbert
On Wed, Mar 25, 2020 at 1:40 PM David Michael  wrote:
>
> On Fri, Mar 20, 2020 at 5:12 PM David Michael  wrote:
> > Signed-off-by: David Michael 
> > ---
> >
> > Changes since v1:
> >   * Drop the dependency altogether
> >
> >  eclass/fixheadtails.eclass | 4 +---
> >  1 file changed, 1 insertion(+), 3 deletions(-)
> >
> > diff --git a/eclass/fixheadtails.eclass b/eclass/fixheadtails.eclass
> > index c19d33924aa..475b182843a 100644
> > --- a/eclass/fixheadtails.eclass
> > +++ b/eclass/fixheadtails.eclass
> > @@ -1,4 +1,4 @@
> > -# Copyright 1999-2014 Gentoo Foundation
> > +# Copyright 1999-2020 Gentoo Authors
> >  # Distributed under the terms of the GNU General Public License v2
> >
> >  # @ECLASS: fixheadtails.eclass
> > @@ -8,8 +8,6 @@
> >  # Original author John Mylchreest 
> >  # @BLURB: functions to replace obsolete head/tail with POSIX compliant ones
> >
> > -DEPEND=">=sys-apps/sed-4"
> > -
> >  _do_sed_fix() {
> > einfo " - fixed $1"
> > sed -i \
> > --
> > 2.21.1
>
> Can this patch be applied?

Done.



[gentoo-dev] Re: [PATCH v2] fixheadtails.eclass: drop the sed dependency

2020-03-25 Thread David Michael
On Fri, Mar 20, 2020 at 5:12 PM David Michael  wrote:
> Signed-off-by: David Michael 
> ---
>
> Changes since v1:
>   * Drop the dependency altogether
>
>  eclass/fixheadtails.eclass | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/eclass/fixheadtails.eclass b/eclass/fixheadtails.eclass
> index c19d33924aa..475b182843a 100644
> --- a/eclass/fixheadtails.eclass
> +++ b/eclass/fixheadtails.eclass
> @@ -1,4 +1,4 @@
> -# Copyright 1999-2014 Gentoo Foundation
> +# Copyright 1999-2020 Gentoo Authors
>  # Distributed under the terms of the GNU General Public License v2
>
>  # @ECLASS: fixheadtails.eclass
> @@ -8,8 +8,6 @@
>  # Original author John Mylchreest 
>  # @BLURB: functions to replace obsolete head/tail with POSIX compliant ones
>
> -DEPEND=">=sys-apps/sed-4"
> -
>  _do_sed_fix() {
> einfo " - fixed $1"
> sed -i \
> --
> 2.21.1

Can this patch be applied?

Thanks.

David



Re: [gentoo-dev] Last rites: media-video/syncplay

2020-03-25 Thread Nils Freydank
Am Mittwoch, 25. März 2020, 08:38:47 CET schrieb Michał Górny:
> # Michał Górny  (2020-03-25)
> # Unmaintained.  Python 3 support requires a version bump.  Bad quality
> # ebuild.
> # Removal in 30 days.  Bug #710240.
> media-video/syncplay

There is a pending PR on github.com:
https://github.com/gentoo/gentoo/pull/15077

--
PGP fingerprint: '00EF D31F 1B60 D5DB ADB8 31C1 C0EC E696 0E54 475B'
keybase.io/nfreydank

signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] rfc: backward-incompatible changes in eclasses

2020-03-25 Thread Michał Górny
William,

So many things are wrong with this e-mail, I'm not even sure where to
start.  In my opinion, this mail shouldn't have ever happened.  While
I believe you had a good intent, this does not justify sending such
mails without verifying your claims first.


On Mon, 2020-03-23 at 13:23 -0500, William Hubbs wrote:
> it has been brought to my attention that there have been several
> backward-incompatible changes made to the python eclasses lately.

The mail starts with an accusation.  While it doesn't name it
explicitly, I think it's pretty clear that all the recent changes
in the eclasses were done by me.  As such, it is an accusation that I've
done *multiple* 'backward-incompatible changes'.  This either implies
that I've deliberately broke something, or that I've been careless,
incompetent.  Either way is bad for me.

Now, as we established there was only one backwards-incompatible change,
not *several*.  Furthermore, FWICS this mail isn't even about that one. 
It's about changes that were fully backwards compatible and under normal
circumstances couldn't have broken any overlays.

Don't you think that if someone is going to publicly make such
an accusation, the absolutely minimal thing to do would be to verify it?
As I'm pretty sure you're aware, I'm available practically every day
and it would be sufficient to *ask* to make it clear what the problem
is.  However, in this case it seems that the accusation was built on top
of misunderstood rumors coming from a third party, that were turned into
public mailing list discussion without any kind of verification.

Of course, you could say that the matter could be corrected in reply to
this mail.  However, this does not change the fact that it is entirely
possible that someone will make an opinion about my actions without
verifying your claims or skimming replies to the thread to see that they
are entirely unfounded.  In other words, this mail is slanderous.

> It is true that everything in ::gentoo has been fixed along with the
> changes to the eclasses; however, when a change like this goes into a
> widely used eclass it breaks overlays with little to no notice;

Just to be clear, the only reason that 'overlays' were broken is that
the overlay in question was forking one of the python eclasses without
forking the others.  As a result, the change in *internal* eclass API
has caused a missync between eclasses effectively used by the overlay
in question.

More specifically, the overlay in question was forking python-utils-r1. 
When new function (_python_export) was introduced in it, the forked
eclass did not provide it and other eclasses failed to call it.

I'm not aware of any clean way of introducing new internal functions
that won't break this case.  I don't believe it makes sense to expect
developers to cope with that.  Moreover, I think it is entirely unfair
to complain that I haven't predicted that someone could be doing this.

> especially since we do not require developers to be subscribed to this
> mailing list.

From 20140408 Council meeting summary:

| * While it is any developer's choice not to participate on the gentoo-
| dev and gentoo-project mailing lists, they nevertheless serve as main
| communication  channels. If something has been discussed there,
| and then action has been taken, the council regards ignorance
| of the discussion not as a good foundation for protests against
| the actions.  [1]

The remaining part of the mail is written with the assumption that
a breaking change has occurred, so I'm going to skip it.

Finally, I don't understand why Council is CC-ed to the mail.  Since
I haven't been approached with any problem, I don't think there is any
reason to request Council intervention here.


[1] https://projects.gentoo.org/council/meeting-logs/20140408-summary.txt

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Re: [PATCH] desktop.eclass: Sanitize filename of desktop entry.

2020-03-25 Thread Ulrich Mueller
> On Wed, 25 Mar 2020, Ulrich Müller wrote:

> + local desktop="${exec%%[[:space:]]*}"
> + desktop="${T}/${desktop##*/}-${desktop_name}.desktop"

Alternatively, we could use the executable's basename only, without
appending PN (but still appending SLOT if different from 0). Or do we
really expect collisions between different packages that install
executables with the same name?

What do you think?

Ulrich


signature.asc
Description: PGP signature


[gentoo-dev] [PATCH] desktop.eclass: Sanitize filename of desktop entry.

2020-03-25 Thread Ulrich Müller
make_desktop_entry() extracts the first component of the filename from
the Exec key in the desktop entry. This can however include arguments
which will end up in the filename. For example, www-client/links has
"Exec=links -g %u", resulting in links_-g_%u-links-2.desktop as the
name of the file.

The current extraction pattern originates from this CVS commit:
https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/eutils.eclass?r1=1.271=1.272
with the commit message "scrub exec filename in case someone does
something silly like pass the fullpath to a binary".

Before that commit, anything after a space in Exec would have been
removed. Restore that behaviour, and in addition use only the
executable's basename.

While at it, get rid of the sed call and handle everything in bash.

Signed-off-by: Ulrich Müller 
---
 eclass/desktop.eclass | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/eclass/desktop.eclass b/eclass/desktop.eclass
index 6fc72ab8ec03..f310f210dfba 100644
--- a/eclass/desktop.eclass
+++ b/eclass/desktop.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2018 Gentoo Foundation
+# Copyright 1999-2020 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 # @ECLASS: desktop.eclass
@@ -162,8 +162,8 @@ make_desktop_entry() {
else
local desktop_name="${PN}-${slot}"
fi
-   local desktop="${T}/$(echo ${exec} | sed 
's:[[:space:]/:]:_:g')-${desktop_name}.desktop"
-   #local desktop=${T}/${exec%% *:-${desktop_name}}.desktop
+   local desktop="${exec%%[[:space:]]*}"
+   desktop="${T}/${desktop##*/}-${desktop_name}.desktop"
 
# Don't append another ";" when a valid category value is provided.
type=${type%;}${type:+;}
-- 
2.26.0


signature.asc
Description: PGP signature


[gentoo-dev] Last rites: net-irc/redirbot

2020-03-25 Thread Michał Górny
# Michał Górny  (2020-03-25)
# Unmaintained.  Python 2 only.  Last commit in 2013.
# Removal in 30 days.  Bug #714632.
net-irc/redirbot

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: media-video/syncplay

2020-03-25 Thread Michał Górny
# Michał Górny  (2020-03-25)
# Unmaintained.  Python 3 support requires a version bump.  Bad quality
# ebuild.
# Removal in 30 days.  Bug #710240.
media-video/syncplay

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: net-im/pyicq-t, dev-python/nevow

2020-03-25 Thread Michał Górny
# Michał Górny  (2020-03-25)
# Unmaintained.  Python 2 only.  Last release in 2009, homepage
# archived.  Last user of dev-python/nevow.
# Removal in 30 days.  Bug #714626.
net-im/pyicq-t
dev-python/nevow

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part