Re: [gentoo-dev] [RFC] Codec project
On Thu, Jun 11, 2020 at 07:11:33AM -0500, Dale wrote: > As a user, how about media? Multimedia? Or would those interfere with > other packages? > > I might add, regardless of name, will it be active enough to keep it > alive or will it go the same as the last? > > Dale > > :-) :-) Please see the replies in the previous thread this was forked from. Ultimately, this just "officially" gave other devs the right to touch the impacted packages. Nothing has really changed... -- Cheers, Aaron signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Codec project
On Wed, Jun 10, 2020 at 08:25:20PM +0200, Michał Górny wrote: > Hi, > > Let's split this from [1] as I suppose having it in middle of high-noise > 'up for grabs' might prevent some interested people from seeing it. > > The general purpose of codec project [2] is to maintain core libraries > for various multimedia format encoder/decoder libraries. It's like > gfx+sound+video except only for core packages and not every possible > single viewer, player, editor, frontend... I believe that this specific > focus make more sense than the wider projects, i.e. it is more likely > than N people will actually co-maintain libraries used by many tools vs > N people co-maintain 20 alternative sound players (when they are > unlikely to use more than one at a time). > > The main questions are: > > 1. Should the project be focused on reference/most common > implementations, or maybe more of them? Say, giflib vs libnsgif. > I think the latter library is specific to a few programs right now but > if it gets more popular, it would fit. > I am not really sure that we *need* a project. I have seen many devs takeover several packages... of those individuals, they are active and I don't believe they would complain if others touched former @graphics packages. > 3. What about libraries implementing media-specific streaming protocols? As stated above, I am not sure we need a project to maintain these. Of course, it *would* be nice. Attempting to define something out of such disparity seems frivolous, but I understand the intention. Additionally, I am not advocating for the disbandment of all projects, but simply those that lack impact. It was more an effort to show that *most* individuals in said project were slacking, but would complain when others attempted to assist. -- Cheers, Aaron signature.asc Description: PGP signature
[gentoo-dev] Re: [PATCH] eclass/cargo.eclass: drop EAPI=6 support
This will also allow me to start adding cross support to cargo.eclass
with new cross-friendly variables.
experimental cross support landed in rust-1.44.0 today [1]
[1] https://bugs.gentoo.org/679878
On 6/11/20 8:11 PM, Georgy Yakovlev wrote:
> no consumers left in the tree
>
> Signed-off-by: Georgy Yakovlev
> ---
> eclass/cargo.eclass | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
> index ad90a0c7dd8..ccbf87aa9a6 100644
> --- a/eclass/cargo.eclass
> +++ b/eclass/cargo.eclass
> @@ -16,7 +16,6 @@ _CARGO_ECLASS=1
> RUST_DEPEND=">=virtual/rust-1.37.0"
>
> case ${EAPI} in
> - 6) DEPEND="${RUST_DEPEND}";;
> 7) BDEPEND="${RUST_DEPEND}";;
> *) die "EAPI=${EAPI:-0} is not supported" ;;
> esac
>
[gentoo-dev] [PATCH] eclass/cargo.eclass: drop EAPI=6 support
no consumers left in the tree
Signed-off-by: Georgy Yakovlev
---
eclass/cargo.eclass | 1 -
1 file changed, 1 deletion(-)
diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index ad90a0c7dd8..ccbf87aa9a6 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -16,7 +16,6 @@ _CARGO_ECLASS=1
RUST_DEPEND=">=virtual/rust-1.37.0"
case ${EAPI} in
- 6) DEPEND="${RUST_DEPEND}";;
7) BDEPEND="${RUST_DEPEND}";;
*) die "EAPI=${EAPI:-0} is not supported" ;;
esac
--
2.27.0
[gentoo-dev] Revival of Gentoo BugDay: everyone is welcome to come debug
# Gentoo BugDay Come join us over at #gentoo-bugday on freenode IRC on the first Saturday of every month to squash bugs and make Gentoo a bit more awesome. You don't need to be a Gentoo developer or even a coder to help us on BugDay. Our next BugDay is on 4th July 2020 and we have started making preparations for selecting and prioritizing bug categories for that day. ## Bug categories The bug categories should be broad enough that there will be a lot of bugs being targeted. We keep a option poll open to everybody to help us narrow down the categories of bugs to focus. The opinion poll is there to get an input from everyone about how to best tackle the current bug situation and get an understanding of the community and developer priorities. The poll is open at https://dudle.inf.tu-dresden.de/Bugday_2020-07-04/ Be sure to vote in the poll to get your opinion heard. ## For developers Even if you have never coded for Gentoo you can help us with your experience. It's always valuable to have your experience to guide us. Things to help with - Find a related bug that piques your interest. - Look at upstream if this has been reported to them. - If not, make a bug report to the upstream developers. - If they have already seen it, check if they have managed to patch it. - If not, try to gather as much information as you can about the bug so that it may help the developer tackling it. - Alert us at #gentoo-bugday and interact with us to see if this can be squashed. ## For users Users are one of the most important part of Gentoo and this is the occasion for them to talk the developers and make your bugs looked at. Take a look at the categories for BugDay at the poll link and the final BugDay wiki page - Find a related bug that you have experienced and has not been fixed yet - Try to see how it can be reproduced.Gnome not doing proper logins on you laptop? - The related bug reports have been ignored for months you say? Come poke us about these bugs at #gentoo-bugday on the freenode IRC and we will begin squashing any of those that are pending. ## Whats in it for me? Bragging rights, permanently being listed on the charts of BugDay, sense of entitlement. Any person who helps us solve valid problems will be given the honor of being listed on the page. Even users who help related bugs and find links which make our problem solving easier will be put on a pedestal. ## Contributors Thanks a lot to jstein@ for being the gracious organizer and making sure everything goes smoothly. And special thanks to contributors who have worked on our previous BugDays. Past contributors: - https://wiki.gentoo.org/wiki/Bugday_2020-06-06
[gentoo-dev] Packages up for grabs app-text/groonga{,-normalizer-mysql}
I have no further interest in the following packages which are now maintainer-needed: app-text/groonga app-text/groonga-normalizer-mysql Brian signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Codec project
Kent Fredric wrote: > On Wed, 10 Jun 2020 20:25:20 +0200 > Michał Górny wrote: > >> The general purpose of codec project [2] is to maintain core libraries >> for various multimedia format encoder/decoder libraries. It's like >> gfx+sound+video except only for core packages and not every possible >> single viewer, player, editor, frontend... I believe that this specific >> focus make more sense than the wider projects, i.e. it is more likely >> than N people will actually co-maintain libraries used by many tools vs >> N people co-maintain 20 alternative sound players (when they are >> unlikely to use more than one at a time). > Somehow I get the impression that "codec" as a scope is still too general. > > For instance, people well acquainted with audio codecs aren't > necessarily well acquainted with video codecs, or image codecs. > > A package that only does audio-playback for instance, won't be of > interest to somebody who predominantly cares about video playback. > > I'm not entirely against it as a concept as-is, I just suspect it will > reiterate the previous problem. As a user, how about media? Multimedia? Or would those interfere with other packages? I might add, regardless of name, will it be active enough to keep it alive or will it go the same as the last? Dale :-) :-)
Re: [gentoo-dev] [RFC] Codec project
> 1. Should the project be focused on reference/most common > implementations, or maybe more of them? Say, giflib vs libnsgif. > I think the latter library is specific to a few programs right now but > if it gets more popular, it would fit. It's mostly a question of critical mass. To give an example from a different corner of Gentoo... Initially net-libs/libtirpc was more of an obscurity, a more feature-complete replacement for code within glibc. Back then it didn't matter so much who maintained it. In the meantime, the corresponding part of glibc has been phased out, and everyone is relying on libtirpc. So now it's important that it is well- maintained, and it's taken care of by base@. > 2. How many kinds of media should the project accept? Audio, graphics, > video seem pretty obvious. Containers too. libass makes sense as it is > specifically for video subtitles. Anything else? Again, critical mass should be the main criterion. Things that are used by many different packages, with many different maintainers. If a library is only used by LibreOffice, it makes more sence that it is maintained by office@. If a library is used exclusively via kde-frameworks, the same for kde@. I wouldn't be too restrictive regarding the type of media. > 3. What about libraries implementing media-specific streaming protocols? > E.g. libshout, live... I suppose the ones specific to voip would fall > into voip project's domain instead. Same arguments... > > > [1] > https://archives.gentoo.org/gentoo-dev/message/79073ab9c7cebd79fc12e897e110 > bc3c [2] https://wiki.gentoo.org/wiki/Project:Codec_project -- 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.
