Re: [gentoo-dev] [PATCH] savedconfig.eclass: Remove old EAPI ED/EROOT workarounds
May 24, 2019 11:39 AM, "David Seifert" wrote:
> +case ${EAPI} in
> + [4-7]) ;;
> + *) die "EAPI=${EAPI:-0} is not supported" ;;
> +esac
> +
Hi,
I often wondered, why using a eapi-whitelisting logic instead of
eapi-blacklisting?
This kind of change forces to touch the eclass for the next eapi bump, while
being a more defensive
writing style, is it really needed?
Best regards,
Corentin “Nado” Pazdera
Re: [gentoo-dev] Is there any way I can help with pull requests?
October 14, 2018 8:17 PM, "Andreas K. Huettel" wrote: >> I've always considered the entry barrier to become a dev too much work for >> keeping a small involvement. I might just be lazy or not interested enough >> I agree. Still I must not be the only one. I might also just have a wrong >> impression of what's needed. > > Well, in the end the quizzes mostly reflect what you're supposed to know as a > dev. If you are ready to become one, writing them down shouldn't take more > than a day. > > (Hey, even if not, researching the answers and writing a first version down > shouldn't take more than a day.) I mostly agree, though I never quite understood why "ebuild quizz" seemed to be a lot about Gentoo social infrastructure + some technical questions and the "end quizz" seemed to be the actual ebuild quizz. I’m not knowledgeable enough yet I believe, but I’m not interested in getting the knowledge about comrel/council/foundation because I don’t care right now. I may revise my judgement in a year or ten. ;) Anyway it is probably more about how it sounds from an external point of view than about how it is, I am not that much invested in Gentoo. Corentin “Nado” Pazdera
Re: [gentoo-dev] Is there any way I can help with pull requests?
October 13, 2018 3:00 PM, "James Le Cuirot" wrote: > On Sat, 13 Oct 2018 13:28:02 +0200 > Ralph Seichter wrote: > >> Looking at the number of open pull requests (some of them my own), I >> wonder if Gentoo has become a bit of a victim of its own success as far >> as contributions are concerned. > > I've said as much, at least with regards to the addition of GitHub. The > problem is that maintainers are not supposed to just blindly merge > contributions but they often lack the time to test them. Such > contributions also frequently have issues as the authors have not done > the developer quizzes. We try to guide contributors through the > necessary changes but this can lead to fatigue on both sides. > >> Is there any way I could help the Gentoo team? Any vacancies that need >> to be filled, or work that needs to be done? > > Following what I said above, we need more actual bona fide developers > who have done the quizzes, understand the issues, can most important > can take responsibility for their own contributions. > > There is the proxy maintainers project, where we can accept > contributions with a little less scrutiny, but I personally feel that > these contributors really should just become developers. It doesn't > matter if you're only interested in one or two packages, any help is > very welcome. I've always considered the entry barrier to become a dev too much work for keeping a small involvement. I might just be lazy or not interested enough I agree. Still I must not be the only one. I might also just have a wrong impression of what's needed. Couldnt it be possible to create more granulars levels of involvement? Corentin “Nado” Pazdera
Re: [gentoo-dev] net-dns/dnssec-root: Blind stable on arm, critical bug 667774
October 11, 2018 5:10 PM, "Thomas Deutschmann" wrote: > Let me quote > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f6f6bb91b7f134a121ef9fa1dd504b9ca52c5aa8: > >> net-dns/dnssec-root: Blind stable on arm, critical bug 667774 >> >> Note that this is a major fail for a stable architecture. >> In addition, all arm devboxes are currently offline. >> >> Bug: https://bugs.gentoo.org/667774 >> Signed-off-by: Andreas K. Hüttel >> Package-Manager: Portage-2.3.49, Repoman-2.3.11 > > ...and now let's all sit down and enjoy how stable ARM users lose access > to the Internet and have to figure out how to deactivate DNSSEC to get > back online. ;] > > Maybe it is time to destabilize ARM on Gentoo to stop the impression > that we really support ARM. What's a "blind stable"? I'm guessing stabilizing without testing? If yes, why? I'm almost happy I dont use dnssec for once. Corentin “Nado” Pazdera
Re: [gentoo-dev] Packages up for grabs
> app-shells/zsh-completions I am a proxied maintainer but I’d like to push arm stabilization on this one. I’ll make a PR (or send patch on bgo if you prefer) adding myself in the metadata.xml if it's alright. -- Corentin “Nado” Pazdera
Re: [gentoo-dev] rfc: moving default location of portage tree (was: [gentoo-project] Call for agenda items - Council meeting 2018-07-29)
July 27, 2018 4:07 PM, "William Hubbs" wrote:
> On Fri, Jul 27, 2018 at 10:32:17AM +0200, Ulrich Mueller wrote:
>
>> So, considering all the feedback from mailing list and IRC:
>>
>> /usr/portage -> /var/db/repos/gentoo
>> /usr/portage/distfiles -> /var/cache{,/gentoo}/distfiles
>> /usr/portage/packages -> /var/cache{,/gentoo}/binpkgs
>>
>> Open question: Should we have the additional "gentoo" path component
>> for the ones in /var/cache? The tradeoff is between a path that is
>> easier to type, or slightly easier usage if someone wants to NFS mount
>> distfiles and binpkgs.
>
> Section 5.5.2 describes the directory structure of /var/cache. These
> paths are all optional [1].
>
> /var/cache/fonts
> /var/cache/man
> /var/cache/www
> /var/cache/
>
> Gentoo isn't a package, so I don't think /var/cache/gentoo/* is
> appropriate. Here is my proposal:
>
> /usr/portage -> /var/db/repos/gentoo
> /usr/portage/distfiles -> /var/cache/portage/distfiles
> /usr/portage/packages -> /var/cache/portage/binpkgs
>
> I'm not 100% comfortable with /var/db, but I don't have any better
> suggestion either.
>
> William
>
> [1]
> http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#varcacheApplicationCacheData
From the same source
"No other requirements are made on the data format of the cache directories."
And as you have quoted it, everything under /var/cache is optional.
So anything which doesn't conflict with another package seems fine according to
FHS.
--
Corentin “Nado” Pazdera
Re: [gentoo-dev] Adding USE=udev to linux profiles
July 20, 2018 2:55 PM, "Rich Freeman" wrote: > On Fri, Jul 20, 2018 at 8:39 AM wrote: > >> Why not introducing a new level in the hierarchy ? Something like "common" >> could be fit. >> >> default/linux/amd64/13.0 >> default/linux/amd64/13.0/common >> default/linux/amd64/13.0/common/desktop >> default/linux/amd64/13.0/common/developer >> ... >> >> By doing so we could still have a bare profiles with minimal things set to >> work, and have the >> common subset with sane defaults for most users. > > I think one of the issues is that our docs/defaults and the mentality > of our users tends to drive them to what looks like the most basic > starting point. > > I think that having a base profile intended just as an inheritance > point for other profiles makes sense technically, but it may not > actually be a good default for end-users. > > If you set up the example above, how many would would still pick 13.0 > as their starting point, and not common? > > Now, there is nothing that says that inheritance has to follow the > directory tree. We could have a > default/linux/amd64/13.0/donotuse/core profile that everything > inherits, and make that the minimal one. It just means that most > profiles under 13.0 wouldn't inherit 13.0. > > To some degree we may have painted ourselves into a bit of a corner by > presenting this as a heirarchy, as it tends to force the bottom of the > heirarchy to be the best profile for inheritance, when it is also the > first thing users see as well. I’m not sure I was clear enough in what 13.0 would mean : basically, its current content would be delegated to common, and 13.0 would keep only things needed to have minimal breakages/conflicts. And we would keep the current directory-like inheritance. Then about what is presented to users and how they choose it : we could adapt eselect-profile to hilight some suggested defaults by use-case and people who still want to pick the minimalist one can do so freely, as they are probably doing it right now anyway. -- Corentin “Nado” Pazdera
Re: [gentoo-dev] Adding USE=udev to linux profiles
Hi, July 20, 2018 2:26 PM, "Ben Kohler" wrote: > On 07/19/18 23:04, Michael Orlitzky wrote: > >> >> >> If you really want to enable it globally after being told that it's bad >> engineering and downright annoying, go do it in a profile that I can >> avoid and not "linux". > > I believe you're arguing against profile global USE in general, can you > start a new thread for that if you believe it's worth discussing? > > We do have global USE in profiles now and I believe that the sane > default for linux profiles is to have udev support globally. Why not introducing a new level in the hierarchy ? Something like "common" could be fit. default/linux/amd64/13.0 default/linux/amd64/13.0/common default/linux/amd64/13.0/common/desktop default/linux/amd64/13.0/common/developer ... By doing so we could still have a bare profiles with minimal things set to work, and have the common subset with sane defaults for most users. -- Corentin “Nado” Pazdera
Re: [gentoo-dev] understanting gentoo
March 24, 2018 11:40 AM, "Abhishek Kumar" wrote: hi everyone I want know about code that exist in gentoo (https://github.com/gentoo)/gentoo (https://github.com/gentoo/gentoo) which parse the command eslect news. Please respond as soon as possible. Hi, There are a ton of things I'd like to know too. Sadly, this aint magical and efforts must come from you. Hint : equery f eselect -- Corentin “Nado” Pazdera
Re: [gentoo-dev] [PATCH] use.desc: Correct/clarify SSL/TLS-related flags
January 31, 2018 10:53 AM, "Ulrich Mueller" <u...@gentoo.org> wrote: > The gnutls flag doesn't have the meaning "I want gnutls". It has > the meaning "I prefer net-libs/gnutls as SSL/TLS provider". So with > USE="-ssl" the gnutls flag is a no-op, and neither the ebuild nor > the user should have to care about it. > > Ulrich I agree, it is bothersome to have to add extra negative use flags when it could be ignored. -- Corentin “Nado” Pazdera
Re: [gentoo-dev] about stable, dev and exp profile status
January 11, 2018 9:52 AM, "Paweł Hajdan, Jr." <phajdan...@gentoo.org> wrote: > On 11/01/2018 08:43, Fabian Groffen wrote: > >> I always was under the impression the following order (and explanation) >> was the case: >> >> stable -> development -> experimental >> >> For this reason, e.g. Prefix profiles are (still) experimental, which >> means they really shouldn't bother non-Prefix people. Prefix users and >> developers work on an environment where those profiles are promoted to >> development ones, such that repoman kicks in for their work. (At least >> that was the idea.) >> >> I see you (re-)define dev as "developer's playground", and I wonder if >> in that case it wouldn't be better to introduce a new one instead? >> >> Maybe I'm just one of a few who thinks the order is reversed now. > > The stable -> dev -> exp order also feels more natural to me. > > I don't have a strong opinion on this though. > > Paweł I got the impression that it was indeed stable -> development -> experimental with dev as in development, it seemed logical to put it between stable and experimental. But now that I read these comments I wonder if it wasnt supposed to be called 'developers' and then the other way round makes sense too. -- Corentin “Nado” Pazdera
Re: [gentoo-dev] Deleting old news items
January 5, 2018 3:58 AM, "Alec Warner" <anta...@gentoo.org> wrote: > ... snip ... > + compatability with GLEP 45 [#glep-45]_. Translations should use the date of > + the original news item. An item is expired if the current date in UTC is > + greater than the expiration date of the item. Package manages should not > + display expired items. s/compatability/compatibility/ and s/Package manages/Package managers/ Regards, -- Corentin “Nado” Pazdera
Re: [gentoo-dev] The problem of unmaintained packages in Gentoo
Hi, December 20, 2017 5:46 PM, "Michał Górny" <mgo...@gentoo.org> wrote: > E. Some of the unmaintained packages are dependencies of other > maintained packages in Gentoo. However, developers usually don't want > to take them, even if their package is the only revdep. > > F. We are usually treecleaning packages as they become severely outdated > and broken. However, that takes serious amount of work too and usually > results in a lot of hostility from other developers (who don't want to > maintain the package in question) and users. > > G. In the past, I've attempted to evaluate the status of projects and to > clean some dead up. However, it's a lot of manual labor and it meets > with hostility from some of the Gentoo developers. > > H. For most things related to determining developer inactivity, we have > little to no automation. It's easy to tell when a developer stops > committing altogether but we have no special help in e.g. determining > that some packages are effectively unmaintained (and that would of > course meet with hostility). I believe there was some work in progress about automating check for new upstream version (via repology api I think). Couldn't this be used to check for maintainer abandon? Some bugs can't always be solved easily, so you can't take that into account to check for inactivity, but not adding new versions is, IMO, a sign that the maintainer doesn’t check often enough for updates. We could also send automatic mail a month (arbitrary choice) after a new version has been released upstream to the maintainer for the related ebuild with such a system, so that maintainers don't have to bother about that part anymore. I can't remember what was called the project but what's its current status? I don't know if a solution like that would change much to the situation, but I believe it should give us better insights about the state of the tree. Best regards, -- Corentin “Nado” Pazdera
Re: [gentoo-dev] git checkout in ebuild?
October 16, 2017 5:30 AM, "Damo Brisbane" wrote: Hello, I am wanting to make an ebuild for Intel's (Apache 2 licensed) snap monitoring framework (https://github.com/intelsdi-x/snap (https://github.com/intelsdi-x/snap)). It seems the current version (2.0.0) does not compile the golang binaries with some type of recent grpc API incompatibility. I can successfully compile by going: go get ... cd git checkout 1.3.0 make all This gets me the binaries (snaptel, snapteld); does anyone know if I can put this process (git checkout..) into an .ebuild file (or some other suggestion)? Cheers, Hi, You can use git-r3.eclass and use a specific tag or commit. See examples on the tree : https://github.com/gentoo/gentoo/search?utf8=%E2%9C%93=EGIT_COMMIT+git-r3= (https://github.com/gentoo/gentoo/search?utf8=%E2%9C%93=EGIT_COMMIT+git-r3=) Best regards, -- Corentin “Nado” Pazdera
Re: [gentoo-dev] Request for help: distributed pull request CI (pkgcheck)
December 7, 2016 7:57 PM, "Michał Górny" <mgo...@gentoo.org> wrote: > Can you think of any tools that could help me get the task done easily > and with as little of reinventing the wheel as possible? Right now, I > have just a lot of trivial shell script that checks pull request for > changes, checks them out, runs 'pmaint regen', pkgcheck, publishes all > kinds of results and statuses, and also compares QA results to > determine new failures created by the PR [1]. If this is already shell based, why not going for something like an ansible automated task or alike ? This way, helper would almost only need to give an ssh key to setup everything. Of course for managing the load it would need some more tinkering, and I’m not sure it would be totally flexible and expandable. -- Corentin “Nado” Pazdera
