Re: [gentoo-dev] Deprecating repoman
On Fri, 11 Mar 2022 10:25:19 -0800 Alec Warner wrote: > On Fri, Mar 11, 2022 at 9:14 AM Peter Stuge wrote: > > > > Matt Turner wrote: > > > repoman is inferior to other tooling mentioned. The other tooling > > > is actually run in CI. > > > > The problem seems to be that CI is running something other than > > developers run, not the other way around. > > > > > > > Developers should get the same warnings locally as in CI. > > > > I agree. And developers and their tools should not have to bend to > > whatever CI does, I think the other way around makes more sense. > > > > > > CI doesn't use repoman because of performance issues. > > I think the problem is that making committers use the CI tool is > technically a fairly straightforward change; while everything you > discuss further in the thread is not; because it implies people will > work on improving tools that have shown little or no progress on > improving in the 15 years I've been in Gentoo. > Somewhat incorrect here. I did the majority of the re-write to make the code maintainable, extensible not that long ago. It even has the ability to be repository configurable and include the ability for custom repository plugin checks to be added and run. The CI system was being developed at the same time using pkgcheck. See my other reply to WilliamH for more detail about that and fundamental speed differences. > > > > What if pkgcore evolves to provide a portage-compatible API? > > No API is planned and no one is working on it. > I and a few others did some work to ensure pkgcore had some usable api's from early in it's development. But pkgcore is so different from portage code, it was difficult for early to mediocre python devs to wrap their head around. There was even work to make porthole be able to use pkgcore as it's backend package manager, but it was never fully utilized due to more work needed on pkgcore for some functionality. > > > > Then CI could use repoman without performance problems, and > > developers would also enjoy improved performance, without spending > > time on replacing tooling which already works for them. > No, pkgcore and it's QA tool pkgcheck are designed to work together. Repoman is designed to work with portage base code. Checks can be designed to work on either, but not both. The missing checks that the CI does can be added to repoman, but the primary dev(s) creating them on the CI don't recreate them for repoman. They want to work on pkgcheck. Repoman code will NEVER be as fast as pkgcheck due to the legacy portage code structure it relies on. Pkgcore was a re-design from the ground up to to improve upon the shortcomings of the original portage structure. This resulted in vast speed improvements and reduction in lines of code to do the same functionality. Portage (due to Zac) has made vast improvements in structure, but still requires a ton more changes to get to where it should be. > The benefit of getting people to change their behavior is that the > benefits (less breakage, better tooling) are achieved now; as opposed > to in some hypothetical future where repoman is improved. > Note that we have been waiting for 'improved repoman' for about 8 > years; so..I'm not willing to bet on it when we have better tooling > that works today and the primary complaint is that...what exactly? > > The new workflow with pkgcheck was announced at the end of 2019: > https://blogs.gentoo.org/mgorny/2019/12/12/a-better-ebuild-workflow-with-pure-git-and-pkgcheck > > It's been 2 years, I think we can bring everyone into the fold here. > > > > > Looking into the future then maybe portage could even come to use > > pkgcore for the low-level things that pkgcore does, then even users > > could enjoy improved performance. > > Many things could happen but again, if you talk to people who work on > pkgcore; there is no concrete plan for this. So I don't see why we are > betting on it happening. > > If you read radhermit's blog: > https://pkgcraft.github.io/posts/timesink-chronicles/ you can get one > take on the project and why it struggled. > > -A > > > > > > > Right? > > > > //Peter > > >
Re: [gentoo-dev] Deprecating repoman
On Thu, 10 Mar 2022 12:07:40 -0600 William Hubbs wrote: > On Thu, Mar 10, 2022 at 09:29:59AM -0800, Matt Turner wrote: > > On Wed, Mar 9, 2022 at 11:09 PM Joonas Niilola > > wrote: > > > > > > On 9.3.2022 23.00, Matt Turner wrote: > > > > I'd like to deprecate and ultimately remove repoman. I believe > > > > that dev-util/pkgcheck and pkgcommit (from > > > > app-portage/mgorny-dev-scripts) are far superior replacements, > > > > and it makes sense to have people using the same tool and > > > > seeing the same warnings as in the CI. > > > > > > > > Are there any useful checks or behaviors of repoman that are > > > > missing from pkgcheck and pkgcommit? > > > > > > > > Thanks, > > > > Matt > > > > > > > > > > I still fail to see the "why" in here. Repoman is better than > > > pure 'git commit' that I know some people still like to use, and > > > as long as it's kept maintained. > > > > repoman is inferior to other tooling mentioned. The other tooling is > > actually run in CI. Developers should get the same warnings locally > > as in CI. Restated another way: I'm tired of telling people to stop > > using repoman or "pkgcheck would have caught that". > > I am going to nit-pick here, but pkgcheck pulls in pkgcore still. As > far asI know, pkgcore was meant to be a portage-like package manager, > but it isn't maintained. So, can we break that dependency before we > make pkgcheck the official tool for qa checks? I would rather not have > pkgcore landing on everyone's systems unless it is usable. If I am > wrong about pkgcore, please correct me and I'll be quiet, but if not > let's make pkgcheck independent from it before we deprecate repoman. > > Thanks, > > William William. pkgcheck uses pkgcore base code as it's library for accessing and evaluating repositories and ebuilds just like repoman uses portage api's to do the same. This is why pkgcheck is primarily faster than repoman. pkgcore was a re-design from the ground up of how to handle repositories and ebuilds within them, with efficiency and speed in mind. Unfortunately, pkgcore never gained enough developer support to to keep up with EAPI changes and the miriad of portage options that kept expanding. So pkgcore never ended up replacing portage as our main package manager. This is one reason why Brian eventually gave up on it and subsequently left gentoo. While I put a lot of effort into the re-write of repoman so that the code is maintainable, more easily extendable. It will never be as fast as pkgcheck due to the legacy portage code it is based on. Yes, repoman could be updated to do more checks and catch everything that pkgcheck does. It can be made to do many of the checks in parrallel, but it will never be as efficient as pkgcheck due to the underlying portage code it uses. I largely stopped working on repoman/gentoo due to the near constant bitching about nearly everything I did from another (ahem) gentoo developer which shall remain un-named. My only concern about the possible deprecation of repoman, is the fact that is is based on the current official and primary package manager code used in gentoo. While pkgcheck is not. For that reason, changes made to the core code is mostly automatically carried over to repoman without need to change repoman as well. Ideally, development should be moved to pkgcore and portage be put into maintenance mode only. With pkgcore taking over as the primary package manager for gentoo. But Zac is just too damn efficient at updating/fixing portage bugs! As well as adding features and options... (too damn many to remember half of them now)
Re: [gentoo-dev] Re: Python 2.7 cleanup: plan B
On Tue, 11 Aug 2020 23:41:33 + (UTC)
"Thomas Mueller" wrote:
> > Hi, everyone.
>
> > TL;DR: we might keep Python 2.7 supported as a build-time dependency
> > of a few packages as necessary, while removing the eclass support
> > for installing packages for py2.7.
>
>
> > As I've mentioned earlier, the plan is to get rid of Python 2.7
> > target support at the beginning of 2021. The plan was to last rite
> > all remaining packages failing to support Python 3 at 2021-01-01,
> > and remove the eclass support on 2021-02-15. At the same time, the
> > Python interpreter was going to stay around for as long as
> > necessary.
>
> > I've also mentioned that there is a high risk that this will not be
> > possible because of a few large entities ignoring the problem
> > and failing to port their build system scripts away from Python 2.
> > We can't really last rite all major web browsers, and postponing
> > the deadline indefinitely is not a good solution either.
>
> > Therefore, I advise the following plan B: if it is impossible to
> > remove Python 2.7 support from packages entirely, the support for
> > installing Python packages for Python 2.7 will be removed.
> > However, there will be exemptions granted for build-time
> > dependencies on the Python interpreter to keep things working, for
> > as long as the interpreter itself is going to stay.
>
> > The candidates for exemptions are pypy/pypy3 (CPython 2.7 is needed
> > for bootstrap on new platforms), Mozilla products, WebKit and
> > WebKit-based browsers.
>
> > Best regards,
> > Micha=C5=82 G=C3=B3rny
>
> I believe net-print/hplip also depends on Python 2.7. This is
> print/hplip in NetBSD pkgsrc and FreeBSD ports.
>
> Or did they fix that recently?
>
> Possibly hplip is mainly for older HP printers, not sure about what's
> going on with HP laser printers more recently.
>
> Maybe that's why there has been reluctance to fix the Python 2.7
> dependency?
>
> I have such an HP printer (LaserJet M1212nf MFP), and my experience
> dissuades me from ordering anything further from HP.
>
> I think most everybody involved with open-source would agree that
> proprietary binary plugins suck.
>
> Tom
>
>
latest hplip has: PYTHON_COMPAT=( python3_{6,7,8} )
and older one was just missing py3.8
Re: [gentoo-dev] dev-python/rstcheck-3.3.1: Add rstcheck python package (#16399)
On Thu, 25 Jun 2020 23:23:29 +0100 Samuel Bernardo wrote: > Hi Brian > > On 6/25/20 11:18 PM, Brian Dolbec wrote: > > You add yourself as primary maintainer. The proxy maintainers will > > add themselves for the merge to the repo after all review is done. > > This will mean that you will need to maintain the pkg, do the > > version bumps, etc.. The proxy team will help merge the changes to > > the ebuild tree. > > That means that I can submit the ebuild metadata without maintainer? > > Thanks > > yes, you do not need to add a Gentoo maintainer unless asked to.
Re: [gentoo-dev] dev-python/rstcheck-3.3.1: Add rstcheck python package (#16399)
On Thu, 25 Jun 2020 23:11:29 +0100 Samuel Bernardo wrote: > Hi, > > I send this email to ask for your help on selecting the project > maintainer for a new ebuild. > > I created a pull request for the ebuild in subject[1] and the QA > reports complaints about missing project maintainer[2]. What should I > do? > > Thanks > > [1] https://github.com/gentoo/gentoo/pull/16399 > > [2] > https://qa-reports.gentoo.org/output/gentoo-ci/2e4d12bbfa/output.html#dev-python/rstcheck > > You add yourself as primary maintainer. The proxy maintainers will add themselves for the merge to the repo after all review is done. This will mean that you will need to maintain the pkg, do the version bumps, etc.. The proxy team will help merge the changes to the ebuild tree.
Re: [gentoo-dev] Last rites: app-cdr/sync2d
On Fri, 5 Jun 2020 18:27:51 -0700 Christopher Head wrote: > On Fri, 5 Jun 2020 12:40:17 -0700 > Matt Turner wrote: > > > With that in mind, I don't expect it to gain Python 3 support, nor > > do I expect an additional 15 days of waiting time to change that > > fact. 15 vs 30 days doesn't seem worth squabbling over. > > Not that I care about this specific case, but isn’t the 30-day time > period also meant as a nice long warning time for people *using* the > package to give them time to migrate to something else before it > starts to be unsupported, potentially break the depgraph, no longer be > installable on additional systems, and so on? The fact that the tree is git based now. It is easy to checkout the tree and checkout the tree at a state where the pkg is still there. You can then copy it to an overlay to keep around for hownever long. The 30 days were more for when the tree was in CVS. There it was much more complicated to get the pkg from the attic. Also, if it is installed, there is a copy of the ebuild in the installed db: /var/db/pkg/cat/pkg-version The only other potential caveat is that the source tarball must still be available from upstream. Our mirrors will eventually drop the source since the pkg/version is no longer in the ebuild tree.
Re: [gentoo-dev] Value of Continuous integration vs Code Review / Pull Requests
On Wed, 27 May 2020 01:28:02 -0700 Alec Warner wrote: > On Wed, May 27, 2020 at 1:09 AM Brian Dolbec > wrote: > > > On Tue, 26 May 2020 20:24:56 -0700 > > Alec Warner wrote: > > > > > The TL;DR is that a crack team of infra-folks[0] have been putting > > > together demos of CI services and things like gitlab / gitea / > > > gerrit and so on. > > > > > > Some of these come in combined (e.g. gitlab offers repo hosting, > > > code review / pull reqs, CI services, and deploy services.) Some > > > of these are piecemeal (e.g. gerrit has code review, zuul has CI) > > > and gitea offers repo-hosting but CI is separate (e.g. drone.) > > > > > > On the infra-side, I think we are pretty happy with repo-hosting > > > (gitolite) and repo-serving (gitweb). We are missing a CI piece > > > and a pull-request piece. Most of the users using PRs use either > > > a gitlab or github mirror. > > > > > > I think the value of CI is pretty obvious to me (and I see tons > > > of use cases in Infra.) We could easily build CI into our current > > > repository solution (e.g. gitolite.) However gitolite doesn't > > > really support PRs in a uniform way and so CI is mostly for > > > submitted code; similar to the existing ::gentoo repo CI offered > > > by mgorny. > > > > > > If we build a code review solution (like gitea / gerrit) would > > > people use it? Would you use it if you couldn't merge (because > > > the code review solution can't gpg sign your commits or merges) > > > so a tool like the existing pram tool would be needed to merge? > > > > > > -A > > > > > > [0] Mostly arzano, if I'm honest. I am just the point-y haired > > > manager in this effort. > > > > There are several CI systems that could be used. As for CI, my > > experience has been with buildbot. It would be fairly > > straightforward to integrate with the current gitolite/gitweb > > hosting. It is also extremely flexible in its capabilities, > > although can be difficult to master. It has a good web interface, > > but it can even be run via it's API's using curses, python, > > bash, There is a buildbot-travis plugin which is capable of > > running existing .travis file configurations. It also extends its > > capabilities to include custom buildbot step definitions. I have > > not packaged it yet for gentoo, but it is on my todo list. One of > > buildbot's capabilities is the ability to run tests/builds on > > multiple workers (different arches or whatever) both in parallel or > > series. It could be made to integrate with our bugzilla using the > > python client (pybugs was it?). > > My understanding is that CI systems are all quite similar. We have > configured gitlab-ci, drone, and zuul as tests and I am familiar with > travis-ci and buildbot from other projects. I'm less concerned about > this aspect tbh. I'm also not super concerned about packaging. E.g. > for gitlab-runner (the worker portion of gitlab-ci) we just deploy > upstream containers and don't package them in ::gentoo at all. Our > onprem gitlab is a container solution; gitea is a container solution; > our SSO IDP is a container solution; gerrit is currently a container > solution. These don't bother me (too much, ugh zuul uses zookeeper? > ugh.) > > The major differentiators for CI appear to be: > - SCM support (we currently only really care about git compatible > systems, but some contenders only support some providers.) > - builders / workers (how do they deploy). For example gitlab has a > container based work executor while zuul uses ansible; I suspect > - Authentication (ideally should support SAML or openID so we can > integrate with our alpha sso solution for Gentoo.) > - The webUI; e.g is the solution horrible to use / interact with. > Hard to say without a trial, IMHO. > > -A > > > > > > But that still leaves a PR/code review option. > > > > I have another buildbot version bump to 2.8.0 to do. While reading over the changes. There are changes to the gerrit integration (GerritEventLogPoller) which I did not know it had or used. There is also a change in the 2.7.0 buildbot-worker: * Command buildbot-worker create-worker now supports ipv6 address for buildmaster connection. I know that buildbot have been creating buildbot containers since the 1.x series, but I've not worked with them. I am planning to learn how to use buildbot with containers and kubernetes. I will certainly check out how that worker command works. whether it is a docker or kubernetes command or either... So, buildbot may be a good option since it can integrate with gerrit and (I think) dynamically deploy workers in containers. So be able to integrate with our existing git/gitweb/bugzilla as well as github/gitlab
Re: [gentoo-dev] Packages up for grabs
On Wed, 27 May 2020 17:39:21 +0200 Piotr Karbowski wrote: > Hi, > > On 27/05/2020 01.31, Brian Dolbec wrote: > > * dev-python/boto3 > > * dev-python/botocore > > Do you mind if I join you on those? I use them a lot, and I planned to > comaintain awscli since Patrick is the only one current maintainer of > those, boto3 is vital part of it too. > > -- Piotr. > Yes, by all means join in :)
Re: [gentoo-dev] Value of Continuous integration vs Code Review / Pull Requests
On Tue, 26 May 2020 20:24:56 -0700 Alec Warner wrote: > The TL;DR is that a crack team of infra-folks[0] have been putting > together demos of CI services and things like gitlab / gitea / gerrit > and so on. > > Some of these come in combined (e.g. gitlab offers repo hosting, code > review / pull reqs, CI services, and deploy services.) Some of these > are piecemeal (e.g. gerrit has code review, zuul has CI) and gitea > offers repo-hosting but CI is separate (e.g. drone.) > > On the infra-side, I think we are pretty happy with repo-hosting > (gitolite) and repo-serving (gitweb). We are missing a CI piece and a > pull-request piece. Most of the users using PRs use either a gitlab > or github mirror. > > I think the value of CI is pretty obvious to me (and I see tons of use > cases in Infra.) We could easily build CI into our current repository > solution (e.g. gitolite.) However gitolite doesn't really support PRs > in a uniform way and so CI is mostly for submitted code; similar to > the existing ::gentoo repo CI offered by mgorny. > > If we build a code review solution (like gitea / gerrit) would people > use it? Would you use it if you couldn't merge (because the code > review solution can't gpg sign your commits or merges) so a tool like > the existing pram tool would be needed to merge? > > -A > > [0] Mostly arzano, if I'm honest. I am just the point-y haired > manager in this effort. There are several CI systems that could be used. As for CI, my experience has been with buildbot. It would be fairly straightforward to integrate with the current gitolite/gitweb hosting. It is also extremely flexible in its capabilities, although can be difficult to master. It has a good web interface, but it can even be run via it's API's using curses, python, bash, There is a buildbot-travis plugin which is capable of running existing .travis file configurations. It also extends its capabilities to include custom buildbot step definitions. I have not packaged it yet for gentoo, but it is on my todo list. One of buildbot's capabilities is the ability to run tests/builds on multiple workers (different arches or whatever) both in parallel or series. It could be made to integrate with our bugzilla using the python client (pybugs was it?). But that still leaves a PR/code review option.
Re: [gentoo-dev] Packages up for grabs
On Tue, 26 May 2020 23:12:06 +0100 Andrey Utkin wrote: > I have transitioned to "away" state as I have to reclaim my time for > other uses. Here I am trying to reduce the scope of my Gentoo > responsibilities to make potential return to activity less dreadful > and overwhelming. > > Call for successors > === > > The following are the packages I do not currently use myself so have > the least motivation about. Dropping me from maintainers list is > encouraged. > > WIFI access point service: > > * net-wireless/hostapd > (Co-maintained by zerochaos, still additional attention is > encouraged.) > > Python API for AWS: > > * dev-python/s3transfer > * dev-python/boto3 > * dev-python/botocore I can take boto3, botocore since they are needed for buildbot
Re: [gentoo-dev] [RFC] Anti-spam for goose
On Sat, 23 May 2020 07:20:22 +1200 Kent Fredric wrote: > On Thu, 21 May 2020 10:47:07 +0200 > Michał Górny wrote: > > > Other ideas > > === > > Do you have any other ideas on how we could resolve this? > > And a question I'd like to revisit, because nobody responded to it: > > - What are the incentives a would-be spammer has to spam this service. > > Services that see spam *typically* have a definable objective. > > *Typically* it revolves around the ability to submit /arbitrary text/, > which allows them to hawk something, and this becomes a profit motive. > > If we implement data validation so that there's no way for them to > profit off what they spam, seems likely they'll be less motivated to > develop the necessary circumvention tools. ( as in, we shouldn't > accept arbitrary CAT/PN pairs as being valid until something can > confirm those pairs exist in reality ) > > There may be people trying to jack the data up, but ... it seems a > less worthy target. > > So it seems the largest risk isn't so much "spam", but "denial of > service", or "data pollution". > > Of course, we should still mitigate, but /how/ we mitigate seems to > pivot around this somewhat. We cannot exclude overlays which will have cat/pkg not in the main gentoo repo. So, we should not excludea submission that includes a few of these. They would just become irrelevant outliers to our processesing of the data. In fact some of these outlier pkgs could be relevant to our including that pkg into the main repo. But, like you I agree that purely spam submissions would be few, if any.
Re: [gentoo-dev] rfc: "emerge --sync" vs "emaint sync"
On Wed, 6 May 2020 17:02:42 -0500
William Hubbs wrote:
> All,
>
> I know that most of our documentation tells people to use "emerge
> --sync"; however, today I heard about "emaint sync" for the first
> time. ;-)
>
> Which one should we use? Will there be a phase-out for "emerge
> --sync" or "emaint sync"? Are the plans to keep both available?
>
> Thanks,
>
> William
>
Hi William. emaint --sync is not going to replace emerge --sync.
They both use the same plugin sync modules.
The difference between them is that emerge --sync is generally done to
sync all repositories defined which have [auto-sync] = yes. Zac
extended it to do individual repositories as well if you specify the
repo name.
ie: emerge --sync foo
emaint --sync offers fine grained syncing of individual repositories
via several options. With emaint you can set a repo's [auto-sync] = no
and still manually sync it on demand from emaint. It offers some
additional capabilities that some power users/devs may need/enjoy
depending on their work flow.
Here are the emaint sync options:
-r REPO, --repo REPO (sync module only): -r, --repo Sync the specified repo
-A, --allrepos(sync module only): -A, --allrepos Sync all repos that
have a sync-url defined
-a, --auto(sync module only): -a, --auto Sync auto-sync enabled
repos only
--sync-submodule {glsa,news,profiles}
(sync module only): Restrict sync to the specified
submodule(s)
ie: emaint sync -r foo -r bar
The --sync-submodule option was added for developers working from the
git tree with the other git tree submodules added the the base gentoo
git ebuild tree. In our case the profiles did end up as part of the
main ebuild tree. But you can add the glsa and news git repos to the
git ebuild tree in order to make a complete repository.
NOTE: the above pertains to the developer git tree, not the anonymous
git tree. That git repo has had the glsa and news repos added to it
for general consumption.
Re: [gentoo-dev] Last standing Python 2.7 dependency
On Sun, 3 May 2020 08:37:27 -0400 Brian Evans wrote: > On 5/3/20 2:58 AM, Fabian Groffen wrote: > > On 02-05-2020 23:24:42 -0700, Brian Dolbec wrote: > >> On Sun, 3 May 2020 07:28:50 +0200 > >> Viktar Patotski wrote: > >> > >>> Hi all, > >>> > >>> I'd also like to clean my system and have it Python 2.7 free. Are > >>> there any guidelines to check which packages are still using > >>> pyton2_7 in my system? > >>> > >>> Thanks, > >>> Viktar > >>> > >> > >> There are both equery and enalyze commands in gentoolkit that can > >> give you reports about what pkgs are installed. > >> > >> equery hasuse > >> enalyze analyze [use|pkguse] > >> > >> for help on them: > >> equery -h > >> equery hasuse -h > >> enalyze -h > >> enalyze a -h > > > > In addition to these great tools, portage-utils' quse might also be > > useful: > > > > % quse python2_7 > > ... > > > > > > Thanks, > > Fabian > > > > All of the mentioned tools will show if packages have the flag but not > necessarily have it active. Not True: enalyze does strictly installed pkgs analysis, plus has the ability to rebuild package.accept_keywords and package.use files after profile changes or disaster (file loss, etc) > > eix has an option to search the active flag: > > eix --installed-with-use > > However, this still skips build-time dependencies that may keep python > 2.7 around. > > The most accurate way to see what's tied to python 2.7 is to pretend > to remove it: > emerge -pvc dev-lang/python:2.7 > > Brian >
Re: [gentoo-dev] Last standing Python 2.7 dependency
On Sun, 3 May 2020 07:28:50 +0200 Viktar Patotski wrote: > Hi all, > > I'd also like to clean my system and have it Python 2.7 free. Are > there any guidelines to check which packages are still using pyton2_7 > in my system? > > Thanks, > Viktar > There are both equery and enalyze commands in gentoolkit that can give you reports about what pkgs are installed. equery hasuse enalyze analyze [use|pkguse] for help on them: equery -h equery hasuse -h enalyze -h enalyze a -h
Re: [gentoo-dev] Packages up for grabs: dev-python/pythondialog /ramlfications /repoze-sphinx-autointerface /robotframework /sleekxmpp /sphinxcontrib-issuetracker /toro /tx*
On Sun, 26 Apr 2020 17:43:16 +0200 Michał Górny wrote: > The Python team will no longer maintain the following packages. They > all need porting to Python 3.7 and newer, and have some obstacle > in doing so. They have only few revdeps which we do not maintain. > > dev-python/pythondialog > dev-python/ramlfications > dev-python/repoze-sphinx-autointerface > dev-python/robotframework > dev-python/sleekxmpp > dev-python/sphinxcontrib-issuetracker > dev-python/toro > dev-python/txaio > dev-python/txAMQP > dev-python/txgithub > dev-python/txrequests > > > pythondialog is used by net-analyzer/gvm-tools (jonas.licht@) > and net-vpn/protonvpn-cli (ilmostro7@). It is missing tests. > > ramlfications are used by dev-util/buildbot (dolsen@ indicate he'll > revive it). The tests fail already and it's on 2016 snapshot. > It seems pretty much dead. > > repoze-sphinx-autointerface is used by dev-python/txtorcon (just taken > by dolsen@). It is missing tests. > > robotframework is needed only for dev-python/robotbackgroundlogger > (zmedico@). It is missing tests. > > sleekxmpp is used by net-im/err (pinkbyte@) and net-im/spectrum2 > (conikost@, andrey_utkin@). It is broken with py3.7 and upstream > has archived the repository. > > sphinxcontrib-issuetracker is used only by dev-python/pydocstyle > (python@, monsieurp@, andrewammerlaan@). Either the tests or the > whole package is broken with Sphinx 3 (and possibly older). > > toro is needed only by dev-python/thriftpy (sci@). Some of the tests > are failing (already) and no upstream activity since 2016. > > txaio is only used by dev-util/buildbot (dolsen@) and sci-libs/vtk > (sci@). All tests fail with a test suite error. > > txAMQP by dev-python/carbon (patrick@, grobian@). Tests require > a system instance of rabbitmq server. > > txgithub is the only package that I managed to test up to Python 3.8 > (though either test coverage or API coverage is near zero). It is > used by dev-util/buildbot (dolsen@). > > txrequests is used by dev-util/buildbot (dolsen@). It is missing > tests. > Yes, I'll take the buildbot ones again. ramlfications had been dropped by buildbot. It is only for buildbot-0.9.7 which I'll be cleaning out, so we can mark it for cleaning.
Re: [gentoo-dev] Last rites: dev-python/txtorcon
On Sun, 26 Apr 2020 14:49:25 +0200 Michał Górny wrote: > # Michał Górny (2020-04-26) > # Unmaintained. Stuck on Python 3.6. No revdeps. > # Removal in 30 days. Bug #719604. > dev-python/txtorcon > I'm taking maintainence back, is a dependency for crossbar which I am bringing back too.
Re: [gentoo-dev] [RFC] Ideas for gentoostats implementation
On Sun, 26 Apr 2020 11:32:06 +0200 Toralf Förster wrote: > On 4/26/20 11:09 AM, Ulrich Mueller wrote: > > Instead of using the IP address, you could generate a UUID when > > installing the tool. > > like the pfl tool did ? > Like the last gentoostats gsoc project did. As for enterprise/school/multiple clone deployments. Those are generated by one person/team, then deployed. We would need that person/team to only enable their test system for gentoostats/disabled for deployments. Repeated failure to do that could result in that uuid being blacklisted. Part of the initial profile details for that vm/image would be some details about approx numbers of deployments (yes, subject to change. But useful to know whether it is 10-15 or 100-500. type of deployment ie: vm/docker/kubernetes/desktop/server...
Re: [gentoo-dev] Packages up for grabs: dev-python/{autobahn,cbor,girder-client,kazoo,libcloud,logbook}
On Fri, 24 Apr 2020 08:22:47 +0200 Michał Górny wrote: > Hi, > > The following packages will no longer be maintained by the Python > team: > > dev-python/autobahn > dev-python/cbor I'll maintain these again along with buildbot now that I am back. > dev-python/girder-client > dev-python/kazoo > dev-python/libcloud > dev-python/logbook > > All of them are stuck on py3.6 and have 1-2 revdeps, and aren't very > useful to the general Python community. All of them have some > problems that prevent us from testing them, and generally would > qualify for last rites if they were not blocked by the revdeps. > > autobahn is only used by vpython (sci@), vtk (sci@) and buildbot (last > rited). It is multiple versions behind upstream. > > cbor is needed for autobahn and ros. It hasn't been touched since > 2016. The test suite fails, and is pretty unreadable. It looks like > a new serialization format that didn't work out. Hopefully newer buildbot versions won't need as many deps and we can clean some of the old ones... > > girder-client is only sed by yt (sci-astronomy@). The ebuild doesn't > declare tests. > > kazoo has no real revdeps (only zake that are 'testing utilities' for > kazoo). Testing requires a running Zookeeper instance. > > libcloud is used by salt only (chutzpah@). It has all tests > restricted because of 'known test failures'. Someone needs to put an > effort to make the tests pass or at least filter out these that don't > pass and run the rest. > > logbook is used only by pyfa and nikola. I've tried bumping it > but a lot of tests still fail with the newest version and then one > seems to hang. > > Expect more as I proceed with py3.7 testing. >
Re: [gentoo-dev] New Python application with multiple new dependencies
On Sat, 13 Apr 2019 23:03:53 +0200 Michał Górny wrote: > On Sat, 2019-04-13 at 22:27 +0200, Ralph Seichter wrote: > > Hi folks, > > > > imagine a Python application "monty" with the following requirements > > listed in setup.py: > > > > install_requires=[ > > 'ham>=1.0', > > 'spam>=2.0', > > 'eggs>=1.5' > > ] > > > > If I want to add "monty" as a new Gentoo package, and if none of > > "ham", "spam" and "eggs" are so far available as Gentoo packages, > > what is the recommended way of handling this situation? > > I presume you want to proxy-maintain all of those packages. > > > > > 1. Create one pull request that contains separate commits for adding > > each of the four Python packages? > > This one. We generally find it easier when we see the big picture > in one place. > > By the way, there's gentoo-proxy-maint@ ml for this kind of questions. > Also, it is best to state that these new pkgs are a depencency of "monty" in their commit messages. It can be clearer as to why these are in the tree if "monty" drops them as a dependency later and there are no other reverse deps for them in the tree. ie: app-foo/ham: New pkg, depencency of app-foo/monty-1.2.3
Re: [gentoo-dev] adding app-crypt/gentoo-keys to @system
On Tue, 19 Feb 2019 23:03:51 -0600 Matthew Thode wrote: > On 19-02-20 00:00:04, Michael Orlitzky wrote: > > On 2/19/19 11:21 PM, Matthew Thode wrote: > > >> > > >> What problem would this solve? (Is adding gentoo-keys to @system > > >> the least bad way to solve it?) > > >> > > > > > > It'd allow the stage tarballs (3,4) to use webrsync-gpg to verify > > > portage tarballs. This is useful for the initial sync (as called > > > out in our manual). Otherwise using emerge-webrsync could be > > > mitm'd or otherwise messed with. > > > > Ok, then I agree with the goal if not the solution. This is a > > portage-specific thing, namely > > > > FEATURES=webrsync-gpg > > > > that should be enabled by default on a stage3. (Making new users go > > out of their way to add basic security is daft.) Portage already has > > USE=rsync-verify, and I think we could either > > > > a) expand the meaning of that flag to include enabling > > webrsync-gpg by default, and to pull in gentoo-keys; or > > > > b) add another (default-on) flag like USE=webrsync-verify to do it > > > > That flag would be enabled by default, so gentoo-keys would be > > pulled in as part of @system without actually being *in* the > > @system. Something along those lines would achieve the same goal in > > a cleaner way. > > > > > > This worksforme (optional, default enabled dep of portage with a > default feature flag change). > > > > As far how we treat deps of @system packages, since this does not > > > have any deps that should help check that box for anyone > > > worried. > > > > I meant the other way around. Once gentoo-keys is in @system, > > packages will (inconsistently) omit gentoo-keys from (R)DEPEND. > > There's no real policy or consensus on the matter, and it makes it > > a real PITA if we ever want to remove things from @system, because > > lots of packages will break in unpredictable ways. > > > > Ah, ya, that makes sense. > One of the things that releng has bantered about the last few years is making a stage4 with these extra non @system pkgs. The stage4 would allow all the extra pkgs needed for new installs without adding to @system. The system set could possibly be trimmed a little more then too. Then knowledgeable users could work with minimal stage3's when it suits their purpose while new users doing installs get the advantage of the additional pre-installed pkgs.
Re: [gentoo-dev] rfc: moving default location of portage tree (was: [gentoo-project] Call for agenda items - Council meeting 2018-07-29)
On Fri, 27 Jul 2018 16:31:15 +0200 Ulrich Mueller wrote: > > On Fri, 27 Jul 2018, Corentin “Nado” Pazdera wrote: > > > July 27, 2018 4:07 PM, "William Hubbs" > > wrote: > > >> 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. > >> > >> [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. > > That's how I would read it, too. We could of course invent a package > name (like "package-manager" for virtual/package-manager) but it seems > cumbersome, and I don't see any benefit of it. > > There also is /var/cache/fonts, so the FHS itself lists an example of > a directory that's not named after a specific package. > > Ulrich /var/db/repos/gentoo /var/cache/distfiles /var/cache/binpkgs Works for me, just please keep "portage" out of it, after all distfiles are not restricted to portage use only, and neither are binpkgs. There is alternate binpkg installers. pgpNgTs22e92A.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Packages up for grabs: app-backup/fsarchiver, app-cdr/daa2iso...
On Thu, 19 Jul 2018 10:10:11 +0200 Michał Górny wrote: > Hello, > > Due to Markos Chandras' prolonged absence, the following packages are > up for grabs now: > > dev-util/buildbot-slave I've taken over all buildbot maintenance. This one will be tree-cleaned soon. The old buildbot-0.8 releases are long since dead upstream. I will begin that process once I stabilize one of the newer releases. pgpETlmIeVsOT.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: moving default location of portage tree
On Thu, 12 Jul 2018 17:35:41 -0700 Raymond Jennings wrote: > On Thu, Jul 12, 2018 at 12:47 PM Brian Dolbec > wrote: > > > > On Thu, 12 Jul 2018 11:49:37 -0700 > > Raymond Jennings wrote: > > > > > In that case, I vote for /var/cache/portage, since that's > > > literally what purpose it serves. Namely, the cache of the > > > gentoo infra's current copy of teh portage tree. > > > > > > On Thu, Jul 12, 2018 at 11:00 AM Alec Warner > > > wrote: > > > > > > > > On Thu, Jul 12, 2018 at 1:43 PM, Raymond Jennings > > > > wrote: > > > >> > > > >> Just for the record, but would putting a setting inside > > > >> /etc/portage/make.conf be the appropriate way to handle this? > > > >> > > > > > > > > The settings already exist (and have existed for 10 years.) This > > > > bikeshed discussion is literally trying to decide what the > > > > default should be. > > > > > > > > -A > > > > > > > > > > > This is not a personal attack against you. Just picked this one to > > say something again... > > > > > > PLEASE, PLEASE stop calling it the "portage" tree. The repo name is > > "gentoo". "portage is the default package manager, but not the only > > choice. Far too often, it takes awhile to figure out what someone > > is trying to say because of that confusion between the tree and the > > package manager. > > Point of order: > > http://distfiles.gentoo.org/snapshots and numerous pieces of > documentation call it "portage" > > The confusion is ingrained by documentation. > Yes, it is, and well we can't very well change the documentation until we can get an end to this new default path bikeshed. Council will need to make the decision (soon I hope)... Then we make all the changes necessary. -- Brian Dolbec
Re: [gentoo-dev] rfc: moving default location of portage tree
On Thu, 12 Jul 2018 11:49:37 -0700 Raymond Jennings wrote: > In that case, I vote for /var/cache/portage, since that's literally > what purpose it serves. Namely, the cache of the gentoo infra's > current copy of teh portage tree. > > On Thu, Jul 12, 2018 at 11:00 AM Alec Warner > wrote: > > > > On Thu, Jul 12, 2018 at 1:43 PM, Raymond Jennings > > wrote: > >> > >> Just for the record, but would putting a setting inside > >> /etc/portage/make.conf be the appropriate way to handle this? > >> > > > > The settings already exist (and have existed for 10 years.) This > > bikeshed discussion is literally trying to decide what the default > > should be. > > > > -A > > > This is not a personal attack against you. Just picked this one to say something again... PLEASE, PLEASE stop calling it the "portage" tree. The repo name is "gentoo". "portage is the default package manager, but not the only choice. Far too often, it takes awhile to figure out what someone is trying to say because of that confusion between the tree and the package manager. PLUS, it has been decided already long ago that the directory name should reflect the repository name. We have been enforcing that rule for overlays for a long time. It has just been taking a long time to get our tooling in order so that we can change our own to follow that rule. So, "portage" should not be a directory name in the new default path. -- Brian Dolbec
Re: [gentoo-dev] rfc: moving default location of portage tree
On Mon, 9 Jul 2018 12:21:36 -0500 William Hubbs wrote: > All, > > is there a tracker for when the portage tree can be moved out of > /usr/portage by default? > > If not, what is the status of us being able to do this? > > Thanks, > > William > I don't recall a tracker bug ever being created. It required the stages be generated by catalyst-3 which can be configured to any location for the tree defaults. catalyst-2 had paths hard-coded all over the place, plus used those paths as keys in python dictionaries... I believe all stages are now built with catalyst-3 for all arches, but I don't know about some of the lesser used arches as some of those are older dates. That and a portage release with the new default location set in it's backup configs. So, it should be ready to convert if the minor arches stage are being generated with catalyst-3 -- Brian Dolbec pgpJWo1O2DkxL.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH v3 10/12] glep-0063: Make 2-yearly expiration term mandatory
On Fri, 06 Jul 2018 08:51:12 +0200 Michał Górny wrote: > W dniu pią, 06.07.2018 o godzinie 06∶28 +, użytkownik Robin H. > Johnson napisał: > > On Fri, Jul 06, 2018 at 08:18:32AM +0200, Michał Górny wrote: > > > > option a) > > > > 2 years + N: > > > > 2 weeks <= N <= 3 months. > > > > > > > > option b) > > > > Change the wording to be 'at most 2 years' instead of 'exactly > > > > 2 years'. > > > > > > That *is* the wording. > > > > I apologize. I took ulm's post as canonical and didn't confirm in > > the original GLEP text. > > > > Further change to follow in response to the original text. > > > > > > Separately: > > > > Is two weeks enough time for a new key distribution to users? > > > > > > I originally wanted to specify one month but k_f insisted on > > > something shorter. 2 weeks were the compromise we agreed on. > > > That said, I'd say weekly 'gpg --refresh' is what we should > > > recommend as the bare minimum. > > > > > > That said, the point of two weeks is mostly to give us time to > > > remind developers that their key is expiring and to give them > > > time to actually read their mail and do it before it actually > > > expires. > > > > Please let's start reminding them BEFORE that. I have seen a lot of > > .away files over the last decade, and taking a 2-week offline > > vacation does happen. > > The problem is, Gentoo developers are really hostile people. If you > remind them *before* the term, they are not very nice because how does > someone dare remind very important developer who was planning to do it > week before expiration, and now he needed to waste his precious time > reading your mail. > I never experienced a single developer show or say anything like you are suggesting. Most, thanked me for the reminder whether it was in IRC or email. And since I always cc'd the gkeys alias (most needed changes to meet the spec too), I'm sure Kristian will confirm this. -- Brian Dolbec pgp5aZWnCcqDB.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH v3 10/12] glep-0063: Make 2-yearly expiration term mandatory
On Fri, 06 Jul 2018 08:18:32 +0200 Michał Górny wrote: > W dniu pią, 06.07.2018 o godzinie 06∶08 +, użytkownik Robin H. > Johnson napisał: > > On Fri, Jul 06, 2018 at 07:43:56AM +0200, Ulrich Mueller wrote: > > > > > > > > On Thu, 5 Jul 2018, Michał Górny wrote: > > > > Replace the disjoint 'minimum' and 'recommendation' for > > > > expiration with a single requirement. Make it 2 years. Also, > > > > remove disjoint expiration recommendation for the primary key > > > > and subkeys since many developers fail at implementing that > > > > anyway. > > > > > > Still NACK. If expiration is exactly 2 years and renewal must > > > happen 2 weeks before the expiry date, then it is not possible to > > > keep the same date. > > > > > > Example: The key will expire at 2018-12-31, so it must be renewed > > > at 2018-12-17 or earlier. This will make it impossible to keep > > > the same month and day (unless one would reset it to 2019-12-31, > > > which is only one year though). > > > > > > So please, make it something like 2 years + 3 months. > > > > option a) > > 2 years + N: > > 2 weeks <= N <= 3 months. > > > > option b) > > Change the wording to be 'at most 2 years' instead of 'exactly 2 > > years'. > > That *is* the wording. > > > Separately: > > Is two weeks enough time for a new key distribution to users? > > I originally wanted to specify one month but k_f insisted on something > shorter. 2 weeks were the compromise we agreed on. That said, I'd > say weekly 'gpg --refresh' is what we should recommend as the bare > minimum. > > That said, the point of two weeks is mostly to give us time to remind > developers that their key is expiring and to give them time to > actually read their mail and do it before it actually expires. > I have gkeys spec-check start warning at 30 days, and it has been my experience that often it only gets renewed last minute (depends on how active the developer is. As it is one of those things that gets put off thinking there is still lots of time... But also, many of those had keys that did not meet the spec requirements. -- Brian Dolbec pgphYyrmtOdFC.pgp Description: OpenPGP digital signature
[gentoo-dev] Lastrites: app-crypt/gkeys-gen
# Brian Dolbec (4 July 2018) # No longer needed, newer app-crypt/gnupg-2 versions have simple cli options # for generating new keys and doing key maintenance. Removal in a month app-crypt/gkeys-gen -- Brian Dolbec
Re: [gentoo-dev] rfc: killing mediawiki
On Wed, 4 Jul 2018 19:21:53 +1200 Kent Fredric wrote: > On Tue, 3 Jul 2018 12:39:43 -0500 > William Hubbs wrote: > > > I don't care that we have a wiki, but can we please look into > > killing mediawiki and look at something with a git backend? It > > would be very nice to be able to edit wiki pages in markdown or > > another similar format and use git to control the changes instead > > of editing in a browser. > > 1. Who are the primary beneficiaries of this suggestion?: > > a. People with expert knowledge of development systems and people > with Gentoo Privileges > > b. End users who may not be experts, in all things development, but > may be able to contribute and consume content. > > 2. What compromises in flexibility does this create? Eg: Do suggested >replacements have capacity to have arbitrary HTML and templating? > Or are they restricted to the terribly narrow featureset of Markdown? > > > If you're optimising for 1-a and your choice of compromise results in > a reduction in functionality with regards to clear, flexible, and > expressive content, it will be hard to sell me on the idea. > 3) The ability of someone with a sight disability, the actual ability to contribute to the project. We as a project should try make our documentation accessible to as broad an audience as possible. I know from personal experience and having worked with such a person, to make it possible to work with cli tools to be able to interact with normally browser only visual interfaces which are extremely poor to work with using a screen reader. At my work, I personally made a github python library and cli interface for github, and worked to create templates for a go-jira command line interface so a visually impaired co-worker could interact with those systems. -- Brian Dolbec pgp2ADbD_1YTy.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: why are we still distributing the portage tree via rsync?
On Tue, 3 Jul 2018 10:22:35 -0500 William Hubbs wrote: > All, > > Mostly because of the recent "trustless infrastructure" thread, I am > wondering why we are still distributing the portage tree primarily > via rsync instead of git? > > Can someone educate me on that, and is it worth considering moving > away from rsync distribution? > > Thanks, > > William > because: 1) it is still the most bandwidth economical means of distributing the tree 2) we have a large infrastructure of rsync mirrors, which we do not for git. 3) see #1 -- Brian Dolbec pgpjViOjx5GaR.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Trustless Infrastructure
On Mon, 2 Jul 2018 11:01:58 -0500 R0b0t1 wrote: > On Mon, Jul 2, 2018 at 10:36 AM, Jason A. Donenfeld > wrote: > > Hey guys, > > > > While our infrastructure team has some nice technical competence, > > the recent disaster and ongoing embarrassing aftermath has made > > ever more urgent the need to have end-to-end signatures between > > developers and users. While the infrastructure team seems fairly > > impressive at deploying services and keeping the house running > > smoothly, I'd rather we don't place additional burden on them to do > > everything they're doing securely. Specifically, I'd like to ensure > > that 100% of Gentoo's infrastructure can be hacked, yet not > > backdoor a single witting user of the portage tree. Right now, as > > it stands, rsync distributes signatures to users that are derived > > from some infrastructure-controlled keys, not from the developers > > themselves. > > > > Proposal: > > - Sign every file in the portage tree so that it has a corresponding > > .asc. Repoman will need support for this. > > Signed hashes should be faster, no? Each directory with files could > have a manifest. > > > - Ensure the naming scheme of portage files is sufficiently strict, > > so that renaming or re-parenting signed files doesn't result in > > RCE. [*] > > - Distribute said .asc files with rsync per usual. > > Rsync would work with this setup, but there is also webrsync-gpg in > Portage right now. This covers the vast majority of usecases right > now. There is often no need to sync more than once per day. > > Speaking of, the keys for that have lapsed. Will they be updated? > > Cheers, > R0b0t1 > app-crypt/gentoo-keys has been updated yesterday. with renewed interest in gpg signatures, I will endeavor to keep it updated until is fully automated. -- Brian Dolbec
Re: [gentoo-dev] Suggestions for simplifying VIDEO_CARDS situation
On Sat, 16 Jun 2018 21:40:10 -0700 Matt Turner wrote: > Hello, > > VIDEO_CARDS is an annoying mess. We used to have radeon, intel, and > some others in media-libs/mesa's VIDEO_CARDS. radeon and intel > corresponded to disparate sets of drivers -- VIDEO_CARDS=radeon has > meant classic r100, r200, r300, and r600 drivers and gallium r600 and > radeonsi drivers. VIDEO_CARDS=intel has meant classic i915 and i965 > drivers as well as gallium i915. > > I added more-specific VIDEO_CARDS for those separate drivers a few > years ago, so that users could set VIDEO_CARDS="radeon radeonsi" and > only get the one radeonsi driver they actually wanted while still > enabling support for x11-libs/libdrm's radeon support code which is > used by most of those radeon drivers. Of course some users want this > control and others don't care at all. > > The confusion comes in with "classic" DRI drivers vs Gallium drivers. > The Gallium abstraction layer allows a hardware driver to handle > multiple APIs -- OpenGL, D3D9, OpenCL, video decode APIs, etc. For > instance, users try to build the classic i965 driver (there is no > Gallium driver for this hardware) with USE=opencl or USE=vaapi and > don't understand why they didn't get what they wanted (or REQUIRED_USE > prevents them from doing so). > > Should of Mesa's USE flags, d3d9, llvm, lm_sensors, opencl, openmax, > unwind, vaapi, vdpau, xa, and xvmc are Gallium-only. Should I make a > USE_EXPAND for Gallium-only options to attempt to avoid confusion? > Another point of confusion: not all Gallium drivers support all of > these features. For instance only the r600 and radeonsi drivers > support OpenCL. How to best handle this? > > It seems like at one extreme you build an extensive set of > REQUIRED_USE conditions that force users to micromanage their USE > flags, or you let them enable all sorts of impossible combinations and > deal with the confused bug reports. > > I would like to somehow get rid of the 'classic' and 'gallium' USE > flags entirely, but I'm not totally sure how. Maybe I can enable them > dependent on VIDEO_CARDS... > > Suggestions welcome. > What about creating a tiny pkg that has all the combinations in a dictionary and can set the USE and VIDEO_CARDS flags according to the video card(s) you have. This would be along the same lines as the app-portage/cpuid2cpuflags pkg. Then the pkg is updated as new drivers and combinations are changed. Perhaps have it run in pkg_postisnt to print any irregularities it finds and ewarn they need fixing. -- Brian Dolbec
Re: [gentoo-dev] Openstack Summit MeetUp: dinner planning for Wednesday?
On Mon, 14 May 2018 22:49:26 + "Robin H. Johnson" wrote: > On Sun, May 13, 2018 at 01:11:30PM -0700, Jack Morgan wrote: > > Gentoo, > > > > I will be attending the Openstack Summit in Vancouver, BC. The > > conference is May 21-24th. I would like to organize a Gentoo meetup > > for those attending or living in the area. I personally will be > > there from May 20th - 26th. > > > > Please reply if you are interested in meeting and which > > day(s)/time(s) you are available. I'm looking forward to it! > I'm Vancouver-local, and will ALSO be attending the summit. > > Available for events during the daytime during the conference, and > also evenings of Monday & Wednesday. I am NOT available on the > evenings. > > As a note, Monday is a (provincial) public holiday in Vancouver, and > you may find a lot of restaurants closed (more than the ones that are > usually closed Mondays). > > Unless there are specific objections, let's try to plan the meetup for > Wednesday evening based on the above? > > I can help to arrange a dinner outing Wednesday evening. If you're > interested, privately email me. Please include a mention of specific > dietary requirements if any. > I am also local to Vancouver, but won't be at the event. Wednesday works better for me too. My daughter has ball games Tuesday and Thursday. -- Brian Dolbec pgphPm7lUDY8d.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Monthly x11@ project status for May 2018
On Mon, 7 May 2018 13:38:47 -0700 Matt Turner wrote: > > If there's a way to have repoman alert developers to deprecated > dependencies in the same way we handle deprecated eclasses, I'd like > to know about it. > > Currently there is not. Thinking out loud... It would mean parsing package.mask to generate the list filtering out those with "masked for removal", from other general mask reasons, but even that is not consistent. from another email in today's batch... (not to pick on this one, was just a lucky coincidence) eg: Subject: [gentoo-dev] Last rites: old, ruby23-only, slots of various ruby packages # Hans de Graaff (7 May 2018) # Old slots that are ruby23-only and no longer maintained # upstream, and that do not have packages depend on them. # Migrate to newer slot of the same package. Perhaps we would need to add a separate last-rites.mask list that the package manager merges internally as part of the .mask stack. That would make just one file to load without a need for filtering. A separate list might also be beneficial for the undertakers and any tooling for its automation. (I am not familiar with any of that tooling) I would then suggest the dependency depth check to default to one (or two) so as to not slow things down drastically. Perhaps a Q/A check report to scan the whole tree on a weekly basis. But that would also require PMS to be updated for the new file, which means a council vote... -- Brian Dolbec pgpDUQqsEMJ4M.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Questions on overlays, repositories and PMS
On Fri, 23 Feb 2018 18:36:07 +0100 Michael Lienhardt wrote: > I started refactoring my solver to make it more modular, to fix some > details w.r.t. the PMS and to manage different repositories. I thus > have several questions on how multiple repositories work in portage. > > 1. My understanding was that /etc/portage/repos.conf replaced the > PORTDIR_OVERLAY variable, however this variable is still documented > (e.g. in > https://devmanual.gentoo.org/general-concepts/overlay/index.html). > Was my intuition right? Or in other word, it is enough to only look > at /etc/portage/repos.conf? In general, an overlay is a repository, > i.e., a valid tree layout for the PMS, right (as stated in > https://devmanual.gentoo.org/general-concepts/overlay/index.html)? > Yes, you should not have to look at the old make.conf variables, yes, they do work, but mostly for backward compatibility with some old third party tools. Those really need to be updated. I forget now how many there are, but if I remember correctly only 2 or 3 are left. And yes, we have been slow to get them updated or replaced. > 2. the PMS states that any valid repository has a profiles folder > which can contain profiles and a package.mask file. > - can the profiles in a repository different from DEFAULT be > selected? > - is the package.mask file apply only on the packages of that > repository, or on every packages of every repositories listed > in /etc/portage/repos.conf? > > 3. many repositories do not have an eclass folder, and miss many > (optional) configuration files in the profiles folder (like > arch.list, categories): > - is such information implicitly inherited from the DEFAULT > repository (even though > https://wiki.gentoo.org/wiki//etc/portage/repos.conf states that it > is not)? the brother overlay > (https://github.com/stefan-langenmaier/brother-overlay) does not > specify any masters > - when the eclass folder, profiles/arch.list and such are present, > is the data from the DEFAULT repository still implicitly inherited? > - when the eclass folder, profiles/arch.list and such are present, > are they visible globally (i.e., a package from another repository > can use a keyword of the arch.list and inherit from one of the > eclass)? > > 4. is the "masters" attribute in /etc/portage/repos.conf make the > repository inherit other data than the eclasses? > > 5. since every repos can have a profiles/categories file, is the > file /etc/portage/categories obsolete (or should it be)? > > > Best Regards, > Michael Lienhardt > > -- Brian Dolbec
Re: [gentoo-dev] AMD64 Arch Testers needed urgently
On Wed, 13 Dec 2017 15:55:59 -0500 Lucas Ramage wrote: > I see, well I can setup buildbot to do that. Is there some place in > particular that I should send my test results? > > On Wed, Dec 13, 2017 at 1:28 PM, Aaron W. Swenson > wrote: > > > On 2017-12-13 13:20, Lucas Ramage wrote: > > > > In my discussions with other developers, I've found that this > > > > is the > > > > > > > biggest concern. Most devs are runnning ~amd64, so they don't > > > feel that > > > > they can mark things stable. > > > > > > W > > > hat about running a stable chroot? Are there any tools that can > > > be used to automate this process? > > > > Yes, a stable chroot is okay, and there is app-portage/tatt that > > can run through the various USE flag combinations for you. > > > > It’s output isn’t terribly helpful, so it takes a little while to > > understand what it’s trying to tell you. > > > > > Lucas, ping me on irc/email me directly. I have been maintaining buildbot in gentoo for awhile and my day job is working on/developing buildbot scripts. I am planning out some pkg bumping scripts to help with regular pkg maintenance. I hope to have some initial code running during the holiday break. There should be a bunch of shared factory code possible as there will be some overlap in their needs. -- Brian Dolbec
Re: [gentoo-dev] Help testing ebuilds? golang/Fabio load balancer
On Sat, 11 Nov 2017 12:31:15 -0500 Michael Orlitzky wrote: > Essentially,we have two commands to create a directory, "dodir" and > "do-empty-dir" (which we call "keepdir"). The latter is only necessary > due to an implementation detail, so it doesn't belong in the user > interface -- the PM should figure out what to do. > > As far as the actual implementation goes, I'm not sure that > automatically-generated ".keep" files are better than having the > package manager maintain its own database. The latter would be more > complex, but would avoid littering everyone's filesystems with > ".keep" files. > Well, for: 1) using .keepdir files makes this package manager non-specific, ie: using a different PM would mean it too sees that it is suppose to be kept. 2) Most ebuilds don't need/or use .keepdir, so I doubt there are that many littering up your filesystem. 3) There already is a database of the files installed by a package. But, how does it know which other packages might need to install to that directory. So, what does it do on unmerge of the package. Typically, the package manager will refuse to remove a non-empty directory after the files it is removing are removed. 4) Creating a single database for these will make the system more vulnerable to corruption and data loss. It would save on disk usage and number of inodes used. But there is a tradeoff between space and robustness. If one .keepdir is lost, it may only affect a few packages. If the database becomes corrupted. It could potentially mean the loss of much more of your installed pkg data. Spanning a great deal of the installed pkgs. In this case simplicity of .keepdir is in my opinion, much better than a single db. -- Brian Dolbec
Re: [gentoo-dev] Reviving the Sandbox project
On Fri, 22 Sep 2017 15:06:49 + James McMechan wrote: > On Fri, Sep 22, 2017 at 5:27 AM, Rich Freeman > wrote: > >On Fri, Sep 22, 2017 at 7:38 AM, Sergei Trofimovich > > wrote: > >> > >> Some other distros try harder to isolate build environment either > >> through chroot and/or private mount/user/network namespace that > >> contains only explicitly specified files in build environment. > >> > >> That would require more cooperation from package manager to fetch > >> list of all visible depends. > >> > > > >I definitely think this is something that would be VERY useful to > >have, because it makes build-time dependency issues almost > >impossible. > > > >However, you don't need that complete solution just to have a > >sandbox. You could simply create a container with the entire > >contents of the main filesystem, but read-only, with the exception > >of the build area. That would replicate the functionality of the > >current sandbox and would be easier than building out just the files > >specified in the dependencies. > > > >The main issue I see with making it dependency aware is performance. > >You would need to walk all the dependencies and their run-time > >dependencies, and the system set, and then individually bind-mount > >the files that belong to them read-only into the container. That > >isn't necessarily difficult, but I imagine that it would be slow. > >Walking the dependencies obviously already happens during resolution > >so that could probably be cached. You could also cache the list of > >files for the system set, and you could even maintain a snapshot of > >these that is used as the base of the container (somebody would need > >to work out the savings of doing this vs the cost of updating it > >every time a system set package changes). > > > >However, the main thing I wanted to point out is that you don't need > >a dependency-aware solution to just replace the existing sandbox. > > > >> I like clear sandbox error reporting. > > > >As far as error reporting goes, you would get kernel-level errors > >like attempting to write to a read-only bind mount, or trying to > >read a file that doesn't exist. To a portage dev it should be > >pretty obvious what is going on. You could add canned text to the > >portage error output at the end. I'm not sure how visible the > >problems would be to portage except to the degree that the build > >system makes them visible > >- it would just see make terminate with a non-zero return. > > > >I would think that containers would be almost completely bug-free > >though. The only thing I could see as an issue is some build system > >that relies on IPC with the host, network access, etc. Namespaces > >themselves are very robust, and the kernel already looks at every > >process as belonging to a set of namespaces even in the default case > >where you only have one set of namespaces on the system, so they > >don't involve different code paths/etc. > > > >-- > >Rich > > Another possibility, could be to have the sandbox be an overlayfs > not of the build directory but of the entire system starting at "/" > and stick that into the container, only CLONE_NEWNS looks to be > needed. > > A container with all writes going to the upper layer of the overlay > could be safe against even #RM -RF / and other disasters, while still > tracking what is happening during the build. > > Should performance be too much of a problem having a bind mount of > the build directory on top of the overlay should give normal > performance to everything that is obeying good practice. > > After the build completes the directory that was mounted as upper > could be scanned to find any wayward writes that had occurred... > > This would not require LD_PRELOAD or ptrace eliminating most of the > "high magic" currently used. > > Just yesterday I had a lot of ptrace failures while trying something > odd with ROOT= and custom USE > > Jim McMechan I kinda like this idea, It looks to me to have pretty much all the benefits of a sandbox and nearly none of the drawbacks. Sounds like it should get more research into this idea, figure out it's limitations and if there are any caveats. -- Brian Dolbec
Re: [gentoo-dev] About adding a *warning* to remind maintainers to check for new PYTHON_COMPAT values
On Mon, 10 Jul 2017 15:41:04 +0200 Kristian Fiskerstrand wrote: > On 07/10/2017 03:35 PM, Kent Fredric wrote: > > On Mon, 10 Jul 2017 13:43:43 +0200 > > Pacho Ramos wrote: > > > >> Yes, but it's similar as the cases when we need to fix our packages > >> to work with a newer library they depend on. In this case it would > >> be even easier as we can have multiple python versions and switch > >> to the newer one for testing while going back to the stable one (if > >> preferred) later. > >> > > > > I'm starting to think we need a collection of QA scripts in a repo > > somewhere, optimized for symlinking into /etc/portage/hooks/install/ > > > > I might've read things too quickly, we're not talking a repoman check > here? > Yes, the warning would be a repoman check for version bumps, etc... What he is talking about, is OT, and I want to automate with a buildbot instance that can do automated testing for all python pkgs (to start with) that have tests enabled in the ebuild. I am also planning to help with automatic version bumps for those pkgs as well. If not committed straight to the tree, then emailed as a patch to the maintainers, perhaps in a pending repo/branch, bugzilla... TBD. Oh, and I want to connect as many arch specific workers to it as well. That should ease ebuild bumps, PYTHON_COMPAT and keywording maintainence. Once in place and operational, it should give the groundwork to add other pkg types, not just python based pkgs. -- Brian Dolbec pgpN7g2ENsI6V.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Should the compressed archive of an executable file be executable too?
On Sun, 18 Jun 2017 13:41:17 +0200 Jonas Stein wrote: > Dear all, > > if we compress an executable script > hello.sh > with bzip2 or gzip the result is a file > hello.sh.bz2 or hello.sh.gz > with executable permissions. However it is not executable, of course. > > ./hello.sh.bz2 > "cannot execute binary file: Exec format error" > > One can not blame bzip2 for it, because it is exactly what its man > page writes: > "Each compressed file has the same modification date, permissions, > and, when possible, ownership as the corresponding original, so that > these properties can be correctly restored at decompression time." > > On gentoo systems we can find many archives with with executable bit > by running > > $ find /usr/share/doc/ -executable -type f > > > * Is it proper to install compressed archives (.zip, .gz, .bz2) > with executable permissions? > > * Should we compress executable files at all? > (Example scripts are usually very small.) > > * Should we remove the executable permission of example scripts > anyway, because the user should not execute it directly, but > rather see it as example? The user reads it, copies and modifies > it and then sets the +x. > > > I am interested in your comments and wish you a nice Sunday. > yeah, makes sense to drop +x, it is better to look at the examples before running them blindly. -- Brian Dolbec
Re: [gentoo-dev] Reverse use of Python/Ruby versions
On Sun, 9 Apr 2017 23:36:18 +0200 Francesco Riosa wrote: > On 09/04/2017 18:15, William L. Thomson Jr. wrote: > > Not sure if this is practical, it may be less work if the use of > > Python and Ruby versions ( maybe others ) is reversed. Rather than > > adding all the versions that the ebuild supports. What if it only > > included versions it did not support? > > > > Rational > > When new versions are added. Ebuilds must be updated to support the > > new version. This can require editing a decent amount of ebuilds. > > Many may work fine with the new version. Making this extra needless > > work. From a user point of view, You cannot move to the newer > > version without keeping older around till all are updated to the > > newer version. > > > > Now one could say its the same work to mark versions not supported. > > But I think there is less of that. Also if something supports and > > older version and not newer, it may stand out more failing. > > Requiring someone to reduce to the older version, and maybe filing > > bugs to get it updated to the newer version. > > > > Python 2.7 stuff aside. I am not sure how many Python and Ruby > > packages break with a newer release. In pythons case I think once > > they support Python 3.x, there is little chance if it breaking with > > further 3.x releases. Not sure about Ruby. > > > > I could be very wrong and the present way of doing things being the > > only way. However if this is feasible it may lead to less work. It > > would allow all packages to move to a newer version. Also allowing > > punting of older sooner. This leaves the versions solely up to the > > eclasses. Then ebuilds simply mark the unsupported versions. Just > > like we do now with adding versions it does support. > > > > Which if something was say only Python 2.7. It would have a >= to > > excluded any newer version of Python. That said, we could do the > > same with the current way. Saying this supports Python/Ruby >=SLOT. > > > > Either way I do not think the current way is the best way. You have > > to add every version/slot to ebuilds that work fine with any > > version. When new ones are added, the ebuild has to be touched > > again. When it may work fine with a new version without requiring > > the ebuild to be modified. > > > > This came up with some stuff requiring ruby23 as I moved to 24. > > Looking around some stuff has Python 3.5 some 3.6, but all 3.4. So > > I will stick to 3.4 till everything is at 3.6. Otherwise no point > > and still have other versions. > > > > The approach mentioned above, if the packages do not have issue. I > > could go ahead and switch to ruby24 and pyton 3.6 across the board. > > Which I cannot do now till a bunch of ebulids have their targets > > increased. > > > +1 to the python part, cannot speak about ruby. > or totally automate the addition of python versions to ebuilds at the > exact time of bumping dev-lang/python. > > This could be partially automated using buildbot. The easiest would be for pkgs containing working test suites. Those that pass could be auto-enabled with that python with ~arch keywords. I think if a stable pkg is to be added the new python, it should be via a revision bump and ~arch'ing the keywords. But we could enforce the bot to rev-bump all ebuilds just as easily. Pkgs without tests, those would be harder and we could do some basic tests on those, like syntax, test imports, but would require additional means of testing in order to qualify for an auto-python addition. It should also be possible for the bot to scrape setup.py for comppatible python versions. Many of the pkgs I have been working with recently have them listed. Also there is travis.yml files in many upstream pkg repos which can also be scraped for tested pythons. It could certainly reduce the manpower needed to keep things up to date. -- Brian Dolbec
Re: [gentoo-dev] Proposal: profiles/arches.desc - improve repoman flexibility (with other benefits)
this arch at all. (In my opinion not necessary, since we > can always set all profiles of an arch to exp.) > > > 4] Meaning for other tools > All arches set to "stable" are considered "stable arches", meaning > * they get listed first in eshowkw > * they require stabilization requests in bugzilla > * ... > > > 5] Initial value in the Gentoo repository > On introduction, the setting will be "stable" for all stable arches, > "testing" for all arches where "inofficial" stable keywords exist > (sh, s390, ...), and "unstable" everywhere else. > > > 6] Rationale > At the moment we have several cases where repoman finds its limits: > > a) An arch loses its stable status (imagine s390), but the arch team > doesnt want to drop all the stable keywords since they are useful for > stage building. Since stable keywords on s390 are an > arch-team-internal thing, everyone can drop the latest stable version > of a package, and it's the arch team's responsibility to keep their > "unofficial stable tree" straight. Right now this means that we have > to set all *profiles* of this arch to "exp", otherwise repoman throws > errors about a broken stable deptree. If we do that, repoman does > however also not check ~s390 consistency, meaning that the ~s390 > deptree will soon be broken as well. With arches.conf, one could set > (arch: testing, profile: stable), which results in stable keywords > being ignored, but the ~s390 deptree still being enforced. > > b) An arch prepares for becoming a stable arch (think arm64). > So, first the ~arm64 deptree should be fine, and then stable keywords > can be added. However, to avoid repoman errors as long as the stable > deptree isnt complete yet the profiles need to be set to dev/exp, and > again this brings the danger of the ~arm64 deptree getting > inadvertently broken. Again the combination (arch: testing, profile: > stable) helps. > > Finally, at the moment the "semi-official" algorithm to figure out if > an *arch* is stable (i.e., requires stabilization requests etc bla > bla) is to check if the arch has any stable profile. This makes > non-stable arches which want to keep a consistent deptree (think > mips) impossible. Reading the arch status from arches.desc instead > solves this problem. > > > 7] Compatibility > > a) No arches.desc and new system, or arch not listed in arches.desc > Arches are treated as "stable" by repoman (current behaviour), with > profile status according to profiles.desc. So, business as usual. > Gentoolkit and other tools trying to determine a list of stable > arches should fall back to current method of scanning profiles.desc > for stable profiles. > > b) arches.desc and old system > Tools ignore the unknown file (?). > Repoman and other tools may emit surplus dependency errors when > profiles are checked on arches that are "testing" (they check the > consistency of the stable tree alone, which is not OK, since "arch" > is supposed to be treated like "~arch"). This affects only > development work and can be fixed by updating repoman. > > c) PMS may need to be amended to allow the additional file. > > > 8] Several repositories > > If arches.desc is present in several repositories, then the strictest > setting for an arch wins. [I don't really see many usecases for this > though.] > > > Congratulations for getting this far. What's your opinion? > -- Brian Dolbec pgp9tJJDrGBMM.pgp Description: OpenPGP digital signature
[gentoo-dev] Gentoolkit-dev is now merged into >=gentoolkit-0.4.0 (Deprecation warning)
We are pleased to announce that the remaining useful gentoolkit-dev tools have now been merged into the main gentoolkit package. The tools moved are: ebump ekeyword imlate The remaining tools are no longer used for the gentoo repository and considered deprecated. With the release of gentoolkit-0.4.0 you will now be required to unmerge gentoolit-dev to install >=app-portage/gentoolkit-0.4.0. This will only affect ~arch or version users at this time that have both packages installed. Stable versions of both packages remain in the tree and can co-exist with each other. Once gentoolkit-0.4.0 has been stabilized, the remaining gentoolkit-dev releases will be masked for removal and subsequent tree-cleaning. Thank you -- Brian Dolbec
Re: [gentoo-dev] New Project: Gentoostats
On Thu, 5 Jan 2017 22:06:23 -0800 Daniel Campbell wrote: > Still, interesting project and I might run it on a machine if it can > help us out. > What do you mean "if"... You __WILL__ run it!! ;) -- Brian Dolbec pgpVwdxfQbgPH.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Signature found, but from unknown key (see push-cert)
On Sun, 1 Jan 2017 16:31:27 +0300
Andrew Savchenko wrote:
> Hi,
>
> On Sun, 1 Jan 2017 18:12:23 +0700 (+07) gro...@gentoo.org wrote:
> > Happy new year to *,
> >
> > Yesterday I've changed expiration dates of my gpg key and its
> > subkeys. And today I cannot push to Gentoo repo:
> >
> > remote: Signature found, but from unknown key (see push-cert)
> > remote: Your push was not signed with a known key.
> > remote: You MUST use git push --signed with a known key.
> > remote: If you just updated your key, please wait 15 minutes for
> > sync. remote: git-receive-pack variables:
> > remote: GIT_PUSH_CERT='ef16430106a13fa3758d2211100be5b9f2bd88d8'
> > remote: GIT_PUSH_CERT_KEY=''
> > remote: GIT_PUSH_CERT_NONCE='1483268914-e0cd9c07e06304c00a64'
> > remote: GIT_PUSH_CERT_NONCE_SLOP=''
> > remote: GIT_PUSH_CERT_NONCE_STATUS='OK'
> > remote: GIT_PUSH_CERT_SIGNER=''
> > remote: GIT_PUSH_CERT_STATUS='N'
> > remote: A push-cert was found, and follows:
> > remote: =
> > remote: certificate version 0.1
> > remote: pusher 0x3AFFCE974D34BD8C 1483268914 +0700
>
> Looks like git hook is still using your old key. You should wait
> for a day or so in order for your change to propagate through
> servers. It this doesn't help, you should probably contact infra to
> update your key.
>
> Best regards,
> Andrew Savchenko
No, infra has it refreshing keys several times an hour.
I just dig another gkeys run and refreshed the keys from the servers.
You did not reset the expiry on your signing subkey. See the following
reports which show the details. After you reset it and gpg --send-key
it to the keyservers again. It can take a few hours for it to
propagate and to be able to push to the gentoo repo again.
===
dolsen@vulture /var/lib/gkeys $
python3.4 /var/lib/gkeys/gentoo-keys/gkeys/bin/gkeys
-c /var/lib/gkeys/gkeys.conf list-key -C gentoo-devs -n grozin
Nick.: grozin
Name.: Andrey Grozin
Keydir...: grozin
Gpg info.: /var/lib/gkeys/keyrings/gentoo-devs/grozin/pubring.gpg
--
pub rsa4096/53D4ABFA88DD61C4 2013-02-26 [SC] [expires:
2017-12-24] Key fingerprint = 6FCC 83E2 6D94 FB05 4B76 1016 53D4 ABFA
88DD 61C4 uid [ unknown] Andrey Grozin (science)
sub rsa4096/34966948B00C83E6 2013-02-26 [E]
[expires: 2017-12-24]
Gkey task results:
Done.
dolsen@vulture /var/lib/gkeys $
python3.4 /var/lib/gkeys/gentoo-keys/gkeys/bin/gkeys
-c /var/lib/gkeys/gkeys.conf spec-check -C gentoo-devs -n grozin
Checking keys...
grozin, Andrey Grozin: 0x53D4ABFA88DD61C4
==
--
Fingerprint..: 6FCC83E26D94FB054B76101653D4ABFA88DD61C4
Key type : PUBCapabilities.: scESC
Algorithm: Pass Bit Length...: Pass
Create Date..: Pass Expire Date..: Pass
Key Version..: Pass Validity.: -, Unknown
Days till expiry.: 356
Capability...: Pass
Qualified ID.: Pass
This primary key.: Pass
--
Fingerprint..: 902F154026C4AD5055486D0234966948B00C83E6
Key type : SUBCapabilities.: e encrypt
Algorithm: Bit Length...:
Create Date..: Pass Expire Date..: Pass
Key Version..: Pass Validity.: -, Unknown
Days till expiry.: 356
Capability...: Pass
Qualified ID.: Pass
This subkey..: Pass
--
Fingerprint..: 08C4EDF669C5A630FE7DEB943AFFCE974D34BD8C
Key type : SUBCapabilities.: s
Algorithm: Pass Bit Length...: Pass
Create Date..: Pass Expire Date..: Pass
Key Version..: Pass Validity.: e, Expired
Days till expiry.: 0
Capability...: Pass
Qualified ID.: Pass
This subkey..: Fail
Key summary
primary..: Pass signing subkey: Fail
encryption subkey: Yes authentication subkey: No
SPEC requirements: Fail
No signing capable subkey:
Andrey Grozin : 6FCC83E26D94FB054B76101653D4ABFA88DD61C4
Failed to pass SPEC requirements:
Andrey Grozin : 6FCC83E26D94FB054B76101653D4ABFA88DD61C4
Gkey task results:
Found Failures:
---
Revoked: 0
Invalid: 0
No Signing subkey..: 1
No Encryption subkey...: 0
Algorithm..: 0
Bit length.....: 0
Qualified IDs..: 0
Expiry.: 0
Expiry Warnings: 0
SPEC requirements..: 1
=
SPEC Approved..: 0
dolsen@vulture /var/lib/gkeys $
--
Brian Dolbec
pgpiNpf50PLG8.pgp
Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Proposal for addition of distribution variables
earched
> and contacted before Gentoo's.
>
> By replacing references to 'bugs.gentoo.org' passed to ./configure
> with ``${DISTRO_BUG_URL}``, the Gentoo project will have a significant
> reduction in wasted effort handling inappropriately filed bugs when
> the issues are caused by changes by the forks and derivatives.
>
>
> Roadmap
> - ---
>
> Since the shell environment is flexible, this change can be
> implemented almost immediately; the defaults specified in the Gentoo
> base profile ensure that at worst nothing will immediately change. As
> forks, derivatives, and other organisations change the environment
> variables in their profiles or ``make.conf`` files, all updated
> ebuilds will immediately reflect the changes.
>
> During this, the variables can be added to the EAPI=7 specification,
> and may eventually be added to PMS §11.1.
>
>
> Suggested Wording
> - -
>
> Attached is a patch for pms.git with suggested wording for the two
> variables mentioned above.
>
> - --
> A. Wilcox (awilfox)
> Project Lead, Adélie Linux
> http://adelielinux.org
oooh, I like it :)
- --
Brian Dolbec
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQJ8BAEBCgBmBQJYRM8DXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNUQ3Qzc0RTA4MUNDNzBEQjRBNEFBRjVG
QkJEMDg3Mjc1ODIwRUQ4AAoJEPu9CHJ1gg7YBygP/2nQpokQuH00x8AfYO10lT11
XfVQuDEcDwsq2dtai1w7Q19nSdlQU1Re6HR8CV76aZcohis0dJOBV0gbF/vdU+oH
tbw7MBjXJDRELKs1+imxbpLvFmMjeTlRE/rm0qtjafmSq1ZfHZlqzA+pDjInTGvX
fcH57ee39PPK+j3zOU2ZRfnv/OhiFg30YRDPQ88YS9uaVng7TJGxLgAjLVI2TICq
1dyiSCDzRNDmYBxZxgbw/FOE5gk3nqKHOQ6mBhbfeXHYuZPNEAO3/lBErWqB51R9
S20HP9J1gXzD7JeQcumrmoF5rxoJ4XyjtQti75HnEY338V08DlSzPqTbFZB+yL1l
irG6BU/CAJKlN6Kj8uoTKc8vv+wLIGFW2ecaoBJO59t8FdW6fk86M76bGlC72Ghv
+b7hZUA9z3V40cwUBJ2CeZwo3xxk7eQqmhAsuq+SiYs4kpeOShGSjf9be4IX787J
8NDhuzxJAiSbZdfIkqVwG1gsXjcGMxemp2/8cghN86S+ESHGNEGG5Q/VMaRBcNnt
l+ciFVPFHZ8pVbJ+zjKfS+x4j38NXfCY1NDnG3VNu+/uSyznWFCkZExfwSWflB1R
+j6I5ulxnbHCr+HWjIgW0gl3eCDXO5ESOlfTs3gXvYEbteb0pAtVJQGPNi3JB856
Cy7Y++qf+4xrlAWAZ5cA
=C/+p
-END PGP SIGNATURE-
Re: [gentoo-dev] OT Who runs Gentoo was -> RFC: Userkit.eclass
On Sat, 03 Dec 2016 16:49:19 -0500 "William L. Thomson Jr." wrote: > On Saturday, December 3, 2016 11:27:20 AM EST Brian Dolbec wrote: > > > > I think you will find that ChromeOS is not really based on Gentoo, > > but built using Gentoo as the base os it IS built from. It is > > still Linux based, but ChromeOS doe not use ebuilds and such for > > normal operations. But the binary pkgs that build it are custom > > built using Gentoo's ebuild system and modified package management > > systems. > > All that sounds like it is based on Gentoo. Its packages before they > turn them into binaries are ebuilds. > > > The > > final resulting OS has it's own methods of updating itself and > > installing the binaries. (At least that is the way it was some > > years ago, last I had looked) > > Yes, but if you want to modify any binaries etc, you are back to > ebuilds. If you want to add a new package not available its the same > thing. They use overlay concepts etc. > > I do get ChromeOS is very different, kinda like Android, you must > flash images you build. No installing it in the normal sense. > > No matter what terms you use, Google uses Gentoo to build products it > makes money off. In that sense I think it could give back allot. If > not in donations, resources (tinderbox), etc. > Well, It does give back some. I know there are times patches are pushed to gentoo from them. Plus we get financial support from them via the Google Summer Of Code. It has been pointed out recently that the majority of our available funds have come from the GSOC. Not only that, but it also helps us get new developers to work with and further Gentoo projects. -- Brian Dolbec pgppzGjJj1BIz.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] OT Who runs Gentoo was -> RFC: Userkit.eclass
On Sat, 03 Dec 2016 12:08:44 -0500 "William L. Thomson Jr." wrote: > On Saturday, December 3, 2016 5:58:29 PM EST Tobias Klausmann wrote: > > Hi! > > > > On Sat, 03 Dec 2016, William L. Thomson Jr. wrote: > > > Google has hired a few core developers as has Gaikai. Both seem > > > to be good, though not sure Google is giving back as much given > > > their financial benefit. Gaikai isn't selling an OS, but Google > > > is based on Gentoo... > > > > That last bit is not true. While yes, Chrome OS and Core OS had a > > Gentoo base, a lot was done of top of that. > > I realize I left out ChromeOS in the previous comment, last bit. I > was not meaning to imply Google ran on Gentoo, just ChromeOS was > based on it. > > Thanks for some insight into Google though! > I think you will find that ChromeOS is not really based on Gentoo, but built using Gentoo as the base os it IS built from. It is still Linux based, but ChromeOS doe not use ebuilds and such for normal operations. But the binary pkgs that build it are custom built using Gentoo's ebuild system and modified package management systems. The final resulting OS has it's own methods of updating itself and installing the binaries. (At least that is the way it was some years ago, last I had looked) -- Brian Dolbec pgpxLUP0qbKGd.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Uppercase characters in package names
On Fri, 2 Dec 2016 13:38:19 -0600 William Hubbs wrote: > On Fri, Dec 02, 2016 at 07:47:01PM +0100, Michał Górny wrote: > > On Fri, 2 Dec 2016 13:02:48 -0500 > > Mike Gilbert wrote: > > > > > The devmanual states: > > > > > > The name section should contain only lowercase non-accented > > > letters, the digits 0-9, hyphens, underscores and plus > > > characters. Uppercase characters are strongly discouraged, but > > > technically valid. > > > > > > https://devmanual.gentoo.org/ebuild-writing/file-format/index.html > > > > > > > > > Why are uppercase characters strongly discouraged? > > > > > > Wouldn't it make sense to follow upstream's naming convention? > > > > I'd say keeping things lowercase makes sense for end user packages. > > For pure dependencies with consistent conventions (e.g. perl), it > > makes sense to keep upstream's naming. > > I'm not advocating renaming this, but I found an example of this when > looking to package something: > > dev-python/configargparse is called ConfigArgParse upstream. > If we had named it dev-python/ConfigArgParse, we wouldn't need to set > MY_PN, MY_P or S in our ebuild, and I wouldn't have had to check the > package to see if it was the same as the package I need to depend on. > > William > It gets worse than that. I recently added several pkg to the tree that had slightly different names for the github repo than they publishedin pypi. I in turn ended up naming it slightly different to fit our category/pkg system. So, the end result is not one common name, but three. For some, I tried to stick with the github repo name, despite getting the tarball from pypi due to the inconsistent github sha's. -- Brian Dolbec pgpCuU6XZuV45.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Uppercase characters in package names
On Fri, 2 Dec 2016 13:02:48 -0500 Mike Gilbert wrote: > The devmanual states: > > The name section should contain only lowercase non-accented letters, > the digits 0-9, hyphens, underscores and plus characters. Uppercase > characters are strongly discouraged, but technically valid. > > https://devmanual.gentoo.org/ebuild-writing/file-format/index.html > > > Why are uppercase characters strongly discouraged? > > Wouldn't it make sense to follow upstream's naming convention? > I think so. In at least one of the pkgs I created, I used mixed case to prevent conflicts with other existing projects that google, pypi, etc. searching returned results for. But still have the name represent what it did. -- Brian Dolbec
Re: [gentoo-dev] [PATCH] distutils-r1.eclass, drop unused egg-base settings
On Tue, 29 Nov 2016 19:13:19 -0500 Mike Gilbert wrote: > On Tue, Nov 29, 2016 at 6:57 PM, Brian Dolbec > wrote: > > > > While working on the last 2 version bumps to the twisted package, I > > kept getting an error in which the *egg-info/SOURCES.txt file > > absolute paths for all the files found in that very same > > directory. They are required to be relative paths only. This > > problem currently only affects some pkgs depending on the > > setuptools pkg for install. The source of the change is that > > setuptools patches the cpython findall() with one that returns > > relative paths for anything in/below the passed in base directory. > > Everything else it returns the absolute path. > > > > Why we should apply this: > > > >Python upstream has merged the setuptools findall() code and > > will be included in the next releases of python, 2.7.13, 3.4.6, > > 3.5.4 (I think). So, there is potential for many more python pkgs > > to be affected by this that are not requiring setuptools for > > install. Without the ebb-base setting, the egg-info/* files are not > > included in SOURCES.txt. The install proceeds without error. > > > >NOTE: This first affects the python_compile_all phase, long > > before it even tries to run the tests (if enabled). > > > > > > Some history: > > > >The egg-base settings were originally added for parallel > >testing/install purposes. They are not used due to problems in > >parallelizing testing, etc.. (something along those lines, I > >don't want to search thru the logs, and mails to see what > > Michal's original words were about it.) > > > > I am working on twisted-16.5.0 and 16.6.0 releases (tests are still > > failing), but 16.6.0 has many improvements to the testing code, so > > has a lot fewer errors to fix. Once these are fixed and the eclass > > changes are merged, I will be able to add it to the tree. > > > > See attached patch. NOTE: actual commit message will be > > different/updated correctly. This was just an interim patch for > > testing and initial review. > > > > Seems ok to me. Hopefully it doesn't break something in a subtle, hard > to detect way. ;-) > I agree, but with 1600+ dev-python/*.* ebuilds, it would take one hell of a tinderbox run to check for definite breakage. Subtle runtime breakage is quite another. -- Brian Dolbec
[gentoo-dev] [PATCH] distutils-r1.eclass, drop unused egg-base settings
While working on the last 2 version bumps to the twisted package, I
kept getting an error in which the *egg-info/SOURCES.txt file absolute
paths for all the files found in that very same directory. They are
required to be relative paths only. This problem currently only affects
some pkgs depending on the setuptools pkg for install. The source of
the change is that setuptools patches the cpython findall() with one
that returns relative paths for anything in/below the passed in base
directory. Everything else it returns the absolute path.
Why we should apply this:
Python upstream has merged the setuptools findall() code and will be
included in the next releases of python, 2.7.13, 3.4.6, 3.5.4 (I
think). So, there is potential for many more python pkgs to be
affected by this that are not requiring setuptools for install.
Without the ebb-base setting, the egg-info/* files are not included
in SOURCES.txt. The install proceeds without error.
NOTE: This first affects the python_compile_all phase, long before
it even tries to run the tests (if enabled).
Some history:
The egg-base settings were originally added for parallel
testing/install purposes. They are not used due to problems in
parallelizing testing, etc.. (something along those lines, I
don't want to search thru the logs, and mails to see what Michal's
original words were about it.)
I am working on twisted-16.5.0 and 16.6.0 releases (tests are still
failing), but 16.6.0 has many improvements to the testing code, so has a
lot fewer errors to fix. Once these are fixed and the eclass changes
are merged, I will be able to add it to the tree.
See attached patch. NOTE: actual commit message will be
different/updated correctly. This was just an interim patch for
testing and initial review.
--
Brian Dolbec
From 95ae3bf2c330ca3c527a6350829e3b6fc7fb9dc8 Mon Sep 17 00:00:00 2001
From: Brian Dolbec
Date: Fri, 25 Nov 2016 11:48:09 -0800
Subject: [PATCH] nuke setting egg info path
---
eclass/distutils-r1.eclass | 5 -
1 file changed, 5 deletions(-)
diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index 2db3be8..68151af 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -288,8 +288,6 @@ distutils_install_for_testing() {
PYTHONPATH=${libdir}:${PYTHONPATH}
local add_args=(
- egg_info
- --egg-base="${libdir}"
install
--home="${TEST_DIR}"
--install-lib="${libdir}"
@@ -394,9 +392,6 @@ _distutils-r1_create_setup_cfg() {
# make the ebuild writer lives easier
build-scripts = %(build-base)s/scripts
- [egg_info]
- egg-base = ${BUILD_DIR}
-
# this is needed by distutils_install_for_testing since
# setuptools like to create .egg files for install --home.
[bdist_egg]
--
2.9.3
Re: [gentoo-dev] ChangeLog generation, profiles/ mess.
On Tue, 29 Nov 2016 23:59:57 +0100 Ulrich Mueller wrote: > >>>>> On Tue, 29 Nov 2016, Robin H Johnson wrote: > > > TL;DR: Let's replace profiles/**/ChangeLog with profiles/ChangeLog, > >because it's a mess. > > > I'm writing the new changelog generation code [1][2], and I'm > > wondering if we can clean up the mess that we have in profiles/. > > > The existing Portage egencache --update-changelogs command does NOT > > generate any ChangeLogs for profiles/ (or eclasses, licenses, > > scripts, metadata, toplevel skel.*). > > I'd say keep it simple: > - one ChangeLog for each package dir, > - one ChangeLog for each first-level subdir other than categories > (i.e. eclass, licenses, profiles, etc.), > - no ChangeLog for category dirs (they contain only a single > metadata.xml), > - top-level ChangeLog for anything not covered by the other > ChangeLogs. > > Ulrich +1, keep it simple -- Brian Dolbec pgpY7ZcxtzCHE.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Future EAPI version operator changes
On Mon, 7 Nov 2016 22:47:24 +0200 Alon Bar-Lev wrote: > On 6 November 2016 at 12:52, Michał Górny wrote: > > Hi, everyone. > > > > > So, what are your comments? > > Hi, > > Just my 2 cents... > I kinda love the prefix nature of the expressions which is consistent > and easier to parse. > Using infix only for versions and leaving all the rest prefix will > create abnormality. > > Regards, > Alon > But the main problem with it is that most upstream requirements.txt, etc.,... all use the infix method. And I hate to say it, but more and more so-called "package management" systems (mostly language specific ones) all use that method. So transitioning to that, should make package maintenance easier. Possibly even have some automation tools to check them during version bumps, etc... -- Brian Dolbec
Re: [gentoo-dev] New single dev-python/twisted package releases in the tree
On Wed, 12 Oct 2016 16:35:25 -0700
Brian Dolbec wrote:
> Since the mid 15.x.x releases of twisted, upstream changed from the
> split releases twisted-{core,names,web,...} to a single twisted
> package release. Our gentoo tree has been behind with upstream
> releases since then partially due to this change and the work
> involved in the conversion.
>
> I am pleased to inform you that I have now completed the new twisted
> package ebuilds and updated/additional/new dependencies. There are
> now dev-python/twisted-16.2.0 and 16.3.2 releases in the gentoo tree
> and I am working on 16.4.1 to get the tests working before adding it
> to the tree. I have been doing testing of the 16.2 and 16.3 releases
> in my buildbot-0.9.0 (day job) work without any issues.
>
> Currently I have added dev-util/buildbot, dev-util/buildbot-worker,
> www-servers/tornado, dev-python/autobahn, dev-python/txrequests
> ebuilds which have ||() dependencies on either the old split twisted
> or new twisted single pkg dependencies.
>
> Since there are no longer any split twisted-* pkg releases, any new
> pkgs/ebuilds should be made with either the new dev-python/twisted
> only or ||() twisted pkgs dependencies as the maintainer sees fit. You
> should also list the new dev-python/twisted pkg first in any ||() deps
> you add. I have come across a portage bug where the resolver was not
> able to solve a conflict between the old split pkgs and the new single
> pkg where it should have been able to. This was partially due to
> having the old split twisted pkgs listed as the first (left) entry in
> the ||().
>
> You should not introduce new pkgs and hopefully new ebuild versions of
> existing pkgs that list only the old split twisted pkgs as
> dependencies. I am sure that eventually the old split releases will
> be tree-cleaned at some future point.
>
> Thank you
I forgot...
The new twisted package is also mostly python3 compatible. There is
code in twisted's setup.py that will not install modules to a py3 that
are not yet ported to python3. So, there should be no issue turn up
during the twisted install.
I have not checked as to which modules have not been ported yet, but
those modules will still install to python2.7. If you have any issues
with your pkg using twisted under python3, then you may have to
restrict py3 from your pkg's PYTHON_COMPAT. As I get caught up, I'll
check in more detail which modules are not yet ported. If you come
across any, feel free to send me a note or even add an ewarn to the
affected twisted ebuild about that sub-modules py3 availability.
--
Brian Dolbec
pgp48SDhsw0vP.pgp
Description: OpenPGP digital signature
[gentoo-dev] New single dev-python/twisted package releases in the tree
Since the mid 15.x.x releases of twisted, upstream changed from the
split releases twisted-{core,names,web,...} to a single twisted package
release. Our gentoo tree has been behind with upstream releases since
then partially due to this change and the work involved in the
conversion.
I am pleased to inform you that I have now completed the new twisted
package ebuilds and updated/additional/new dependencies. There are now
dev-python/twisted-16.2.0 and 16.3.2 releases in the gentoo tree and I
am working on 16.4.1 to get the tests working before adding it to the
tree. I have been doing testing of the 16.2 and 16.3 releases in my
buildbot-0.9.0 (day job) work without any issues.
Currently I have added dev-util/buildbot, dev-util/buildbot-worker,
www-servers/tornado, dev-python/autobahn, dev-python/txrequests
ebuilds which have ||() dependencies on either the old split twisted
or new twisted single pkg dependencies.
Since there are no longer any split twisted-* pkg releases, any new
pkgs/ebuilds should be made with either the new dev-python/twisted only
or ||() twisted pkgs dependencies as the maintainer sees fit. You
should also list the new dev-python/twisted pkg first in any ||() deps
you add. I have come across a portage bug where the resolver was not
able to solve a conflict between the old split pkgs and the new single
pkg where it should have been able to. This was partially due to having
the old split twisted pkgs listed as the first (left) entry in the ||().
You should not introduce new pkgs and hopefully new ebuild versions of
existing pkgs that list only the old split twisted pkgs as dependencies.
I am sure that eventually the old split releases will be tree-cleaned
at some future point.
Thank you
--
Brian Dolbec
pgpxfrk_UJPrK.pgp
Description: OpenPGP digital signature
Re: [gentoo-dev] New Working Group established to evaluate the stable tree
On Mon, 15 Aug 2016 09:40:39 -0400 Rich Freeman wrote: > On Mon, Aug 15, 2016 at 3:55 AM, Brian Dolbec > wrote: > > > > I have some trouble with not being able to close bugs as resolved > > when the fixes have been released. But I do see that the majority > > of what is being discussed relates to pkg ebuilds more than it does > > to coding projects. In that sense it sounds reasonable. But for > > me, most of my work is project coding, so it overlaps with making > > releases which involves the ebuild. As a project coder, I want to > > be able to close a bug when a release has been made that contains > > the fix. In some cases that release might not get stabilized, but > > another one later does. > > I'd suggest that we agree early-on that the scope of this is around > ebuild work. Not "upstream" work where the upstream is Gentoo. > > Of course, there could be overlap. portage-1.23.ebuild might have a > bug, and that gets fixed in the portage dev git, and later gets > released to portage-1.24, and then ends up in stable sometime later. > Those could be two separate bugs (the gentoo repo ebuild bug vs the > portage "upstream" bug), but I'm not sure that makes life easier. If > they were two separate bugs (as they would be if Gentoo weren't the > upstream) then the scope of this effort is focused on the Gentoo > ebuild repo bug. > I suppose we could use the tracker bug a little differently than we have to handle the release/ebuild stabilization process. We have often recycled a tracker to the next version, but instead we can generate a new one each time and allow it to be used this way. If a release is being skipped for stabilization, then it could be added to the next tracker's depend. The only thing is that we will still end up with duplicate bugs being filed since the trackers do not have any search data of the original bugs which have been fixed and released in an unstable version. Of which the original bug had been marked resolved. In this case, could the search system be modified to keep that search data until all references to that bug (ie: blocks the tracker bug) have been stabilized/closed. hmm, looking a bugzilla... Gentoo Linux: The Gentoo Linux Distribution – Ebuilds and System related issues Always attach the output of emerge --info to your bug report! Before reporting a bug, please make sure the issue you are about to file is not the result of a misconfiguration on your part. Our other support venues (for instance the Forums or IRC channels) can help you find out whether the issue warrants a bug report. Examples for bugs in this product: New package and version bump requests Compile errors (please follow the instructions contained in the error message!) Application crashes (be sure to have a backtrace available) General issues regarding your Gentoo system Examples for bugs that should NOT be filed here: Security updates (use Gentoo Security below) Documentation updates (use Documentation below) Issues regarding our website and infrastructure (use Gentoo Infrastructure or Website www.gentoo.org below) Issues about OpenRC, genkernel, or catalyst (use Hosted projects below) -- This is still a very broad range... This can still cover bugs for many small projects that are not in the hosted projects category. It also can contain bugs that will never involve stabilization of an ebuild. Perhaps we need to add a new category SPECIFICALLY for dealing with the stabilization process and/or Gentoo tree state. The current "Gentoo Linux" would continue to act as the catch-all, but as a bug is fixed and involves a release/in tree new version,..., it get's re-categorized to a "Gentoo Stabilization" (or some other aptly named) category. In that way, once a fix has been made the re-categorization could reduce the search results for projects working on bugs that need fixing. While at the same time, not completely close a bug. For tracker bugs, it would be the tracker that gets re-categorized to the specific "Gentoo Stabilization" category where it too could get better search results and/or some semi-automated tools could send reminders for ebuilds not stabilized after the 30 day time when that version has no bugs in the catch-all category. Also if bugs are filed against it, a tool could auto-tag it's DEPEND with the "Gentoo Linux" bug number. I think something like this could help improve the process. -- Brian Dolbec
Re: [gentoo-dev] New Working Group established to evaluate the stable tree
On Mon, 15 Aug 2016 12:05:43 +0800 Jason Zaman wrote: > On Mon, Aug 15, 2016 at 03:53:26PM +1200, Kent Fredric wrote: > > On Mon, 15 Aug 2016 11:45:22 +0800 > > Jason Zaman wrote: > > > > > IN_PROGRESS == we've put the fix in the git repo > > > RESO/TESTREQ == new release and in ~arch > > > > TESTREQ was incidentally my first thought. Only needs me to study > > how much that's already used and whether or not existing bugs with > > that flag meet that description or not. > > > > > > However, a distinction between IN_PROGRESS and RESO/TESTREQ is not > > possible here, because "in git" means "You'll get it if you sync > > >1h from now" > > Oh, I meant this is for our policy stuff. which is in > hardened-refpolicy.git and then every few weeks we make a release and > bump all the packages in sec-policy/selinux-*. For things that do not > need an actual release we just skip INPROG and go straight to TESTREQ > when we fix the ebuild in the tree. > > The important part to me is that RESO/FIXED should only mean fixed > when the problem is fixed in the stable tree too. There has to be > another state before FIXED that is for ~arch. If the package is not > stable on any arch then of course it is FIXED as soon as ~arch is > fixed. > > > IN_PROGRESS can thus only mean something about it being worked on > > but not yet pushed to the main git repo. (ie: overlays, private > > repos) > > > > But I would rather it part of the primary resolution path, not a > > mere property of the resolution type. > > > > Because its easier to say: > > > > UNCONFIRMED -> CONFIRMED -> INPROGRESS -> INVCS -> STABLE > > > > Than > > > > UNCONFIRMED -> CONFIRMED -> INPROGRESS -> (RESOLVED/TESTREQ) -> > > (RESOLVED/FIXED) > > They are roughly equivalent, yeah. But I prefer TESTREQ because its > easier to see in the bug list page. You can of course choose which > items are shown in the list in bugzilla but resolution is already > there so no need to add an extra column. > > -- Jason > > I have some trouble with not being able to close bugs as resolved when the fixes have been released. But I do see that the majority of what is being discussed relates to pkg ebuilds more than it does to coding projects. In that sense it sounds reasonable. But for me, most of my work is project coding, so it overlaps with making releases which involves the ebuild. As a project coder, I want to be able to close a bug when a release has been made that contains the fix. In some cases that release might not get stabilized, but another one later does. For me IN_PROGRESS means the problem is being worked on, not that a fix has been posted/committed anywhere. INVCS is once the fix has been committed to the source repo and not anything to do with an ebuild from the coders perspective. The problem is the overlap of bugzilla for both ebuild repositories and source repositories. So if there is any changes to be made to the different states possible... Just remember the the different perspectives and try to make it clear what they are for. Also, if a pkg is never stabilized... does that mean it's bugs can never be closed? So far in the discussion, that point has not been brought up, but is very relevant to the discussion. /me mumbles about the extra bookeeping that work-flow will make...and subsequently put off and/or forget to do ;) -- Brian Dolbec
Re: [gentoo-dev] news item: grub2 multislot use flag is being disabled
On Mon, 8 Aug 2016 09:12:32 -0500 William Hubbs wrote: > typo: anyonewho missed a space -- Brian Dolbec pgphFxTuJI75_.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Packages up for grabs
On Sun, 07 Aug 2016 10:24:08 +0200 Pacho Ramos wrote: > This packages are now up for grabs: > app-portage/g-sorcery > app-portage/gs-elpa > app-portage/gs-pypi I'll sign layman project up for these -- Brian Dolbec
Re: [gentoo-dev] Farewell Gentoo.
On Mon, 8 Aug 2016 08:24:16 -0400 "Jesus Rivero (Neurogeek)" wrote: > After so many years of being a proud Gentoo dev, it comes that time > when I have to say bye (at least for now). > > There are no words to describe what Gentoo and being a Gentoo dev > meant for me. > I've made really good friends, learned a ton of skills in many facets > of computing from incredibly amazing and knowledgable people, and was > a big part of me getting great job opportunities. > > I didn't want to part without first saying thanks to all the devs > that have and continue to make Gentoo such an amazing project. Keep > making Gentoo better! > > Keep in touch. > Farewell, and thanks! > Sad to see you go, but, also glad you were a dev for so many years :) I hope to see you around in the future too, even if it is only for visit :) Take care, have fun,... don't be a stranger ;) -- Brian Dolbec
Re: [gentoo-dev] Looking for a new mentor...
On Wed, 20 Jul 2016 15:13:56 -0400 alexmcwhir...@triadic.us wrote: > I've been working towards becomming a gentoo developer for while now > in order to bring the sparc port up to speed with the rest of the > gentoo project. In short there appear to be no active gentoo > developers working on sparc. > > I had a mentor earlier this year, but i can no longer get in touch > with him. > > I have both quizzes nearly complete, i just need someone to look over > them and answer a question or two. Any help would be greatly > appreciated. > Alex, it would be helpful to list your timezone and normal availability times. That will help potential mentors know if they match up availability times. Aside from sparc related updates, is there any other areas of the ebuild tree your more interested in like desktop environments, gnome, kde, *box, networking, tools... -- Brian Dolbec
Re: [gentoo-dev] [RFC] bugs.g.o: Killing VERIFIED state, possibly introducing STABILIZED
On Fri, 17 Jun 2016 18:46:16 +0200 Kristian Fiskerstrand wrote: > On 06/17/2016 06:41 PM, Rich Freeman wrote: > > On Fri, Jun 17, 2016 at 12:00 PM, Kristian Fiskerstrand > > wrote: > >> On 06/17/2016 03:58 PM, Rich Freeman wrote: > >>> > >>> That could actually be generalized. I could see many types of > >>> bugs where the issue is with upstream, and we might want to track > >>> the progress as upstream implements a fix, releases it, and then > >>> it is stabilized on Gentoo. So, maybe we need another state to > >>> track in upstream's VCS vs the Gentoo repo. > >> > >> For a great deal of this we have UPSTREAM keyword, and also > >> combination with PATCH keyword if we've submitted an own patch. > > > > Usually we mean UPSTEAM to mean that the issue is an upstream issue, > > and should be pursued there. Usually we don't use it to mean that > > the issue IS resolved upstream but we're waiting for a > > release/etc. I'm > > Well, the issue is still upstream in that case, so I don't see that > necessarily being different, we're still waiting for a release > upstream to make a new downstream ebuild and stabilize it, so it fits > with UPSTREAM > > > not sure how important the distinction is in practice. The portage > > team could of course use it differently. > > Yeah, I'm talking ebuilds here, not portage and similar bugs, I think > your point of having own keyword for portage and the likes makes sense > to distinguish it. > > Then everyone PLEASE stop referring to the Gentoo ebuild tree as portage. Reserve portage for the upstream PACKAGE MANAGER. Further, I have always treated bugs about portage code like any other upstream. Only difference being that the portage upstream bug system is the same bugzilla used for the Gentoo ebuild tree. So, there will be some differences in how bugs are treated. When we as upstream commit patches for bugs we tag them as InVCS and close them when they are in a release. We have not kept them open until that release has been stabilized unless we've missed closing it or been distracted and forgotten to clean them up. If you want to track that at the ebuild level, you could do that, but would need to identify it's tracker in a clear way to distinguish it from code bugs. -- Brian Dolbec pgp69AoKFcWN9.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Global USE=gui
On Tue, 7 Jun 2016 14:29:58 -0400 Michael Orlitzky wrote: > On 06/07/2016 12:20 PM, Michał Górny wrote: > > > > So many weird ideas... while the simplest one is a proper > > REQUIRED_USE with gui being the control flag, and IUSE defaults to > > select the preferred toolkit. > > > > This is what came to my mind. > > The underlying problem that we are hitting (a la Patrick) is that USE > flags are supposed to be a user-interface for building software from > source, but implementation details are an important part of > configuring the software to be built. > > It would be nice if USE=gui meant "build a GUI" and that was all the > input that we needed from the user. But if the upstream package > supports both QT and GTK and we need to pass either --with-qt or > --with-gtk to the build system, then there is an unavoidable choice > to be made. We can prefer one, but both options need to be available. > > If we want the best of both worlds -- a nice user-interface and full > configurability -- then we can use "the user wants a GUI" as a trigger > for the implementation choice. If there's a default implementation and > the user doesn't care, no further interference should be necessary. > Otherwise the presence of the generic USE=gui will let us know, so we > can let the user know, that he needs to pick one. > > This is where my thought from a few days ago kicks in... I had started to discuss it with Kristian. I propose to help alleviate the __MESS__ from all this force-foo and other complicated USE flag REQUIRED_USE madness... We instead implement something along the lines of: an ordered list of the gui toolkits in their preferred order of desirability. This should be an all inclusive list. Note: these are subject to package.use setting overrides. PREFERRED_GUIS="gtk2 qt4 qt5 x wxwidgets X ... ncurses tty -gkt3" In the above it means that if gtk2 is an option, then choose it, mask (de-select) the others. In there it also means DO NOT SELECT gtk3 So if you want a pkg and it NEEDS gtk3, then the PM will puke it back at you saying you can't have one without the other... So, then you have to fix it manually via package.use settings. Accept gtk3 for this pkg only (not that it doesn't likely have other gtk3 deps that will also need this...) In the general case it will pick the first toolkit in order of preference (left to right) and only that toolkit that the pkg is capable of using. For pkgs capable of multiple simultaneous toolkits installed, then again, manual intervention would be needed to set package.use. This would also have to be a package manager feature and run similar to the auto-unmask feature. FEATURES="preferred-guis" Let's try and keep things as simple as possible. From what I've gleaned form the emails I have read, is that what the general user wants to happen, select the toolkit in the order of their preference. -- Brian Dolbec
Re: [gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation
On Fri, 27 May 2016 11:35:01 -0500 Canek Peláez Valdés wrote: > On Fri, May 27, 2016 at 10:02 AM, Brian Dolbec > wrote: [snip] > > I'll be really sad when gtk2 is totally abolished in Gentoo. :( > > I suppose I'll have to break down and switch to KDE maybe. > > > > In my opinion the upstream gtk developers have gone somewhat bonkers > > with their cartoonish changes to the look, feel and generally > > un-intuitive user interface. The new file selector is irritating > > to use despite getting all the old behaviour settings I know of > > set, the lack of the ability to paste a path into it, forcing you > > to navigate directory by directory, and other BS behaviour... > > What's wrong with Ctrl-L to open the "Enter location or URL" text > field and pasting the path there? > > Regards. The unintuitive knowledge that that even existed for one. I have been informed in IRC about this and tried it. I also found out that you can just paste it without opening that box (haven't tried that yet) . Also typing / will bring it up. Without a / will start a search... All unintuitive changes since gtk2. I admit I don't know all the in's and out's of gtk2 either, but in gtk2 there was a small icon to open the text/paste box if it wasn't already a default. Also what is intuitive about special keystrokes in a gui? After all gui stands for Graphical User Interface. Keyboard shortcuts are one thing, totally hiding them from the interface quite another. There is a reason I tend to prefer __GOOD__ gui apps over command line ones in most cases. I hate trying/needing to memorize 100+ special keystrokes and/or commands and/or options for apps. It's more I know what I want to do, so do the few clicks/done, not spend half my time trying to read man pages/learn/memorize _some_app_ special keystrokes and/or command option in order to do it. -- Brian Dolbec
Re: [gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation
a GUI is optional.
>
> * USE=gtk3 may be used only for controlling extra libraries to be
> shipped for gtk3 support (the extra library file will link to gtk3),
> _in addition_ to gtk2 version. This is a temporarily measure until
> gtk2 support can be dropped and it will only ship gtk3 version of the
> library. This gives a flag to be able to USE depend on by gtk3 apps.
> This leaves the question about the opposite open, however. This is why
> USE=gtk2 would be bad for apps, maybe we need to use it for this
> library case, when gtk3 version is primary and we just have 1 app
> remaining that needs the gtk2 version or something.
> The concept of library is broad here, covering also gtk theme engines
> (x11-themes/gtk-engine-*, but they shouldn't be hard to split) and
> modules (e.g caribou, libcanberra)
>
> * Applications may only use a gtk2 based stack or gtk3 based stack in
> a given version/revision. gtk3 is strongly preferred when it is
> deemed to not have any regressions compared to gtk2 build, but the
> choice is ultimately with the maintainer. Once the application
> converts to using gtk3 in our distribution, it should try hard to
> stay that way in upcoming versions as well.
>
> * Some exceptions to the above may exist under heavy consideration,
> especially in cases where the toolkit usage is complex and may have
> some issues for some, but in general gtk3 support is deemed good by
> upstream. Most notable here would be browsers like firefox and
> chromium, which are using gtk dependency more for emulating the theme
> it uses, rather than using it as its real toolkit. If such exceptions
> are allowed, the USE flag naming here must be consistent amongst the
> exceptions. My proposal would be USE=force-gtk2 then, as I have no
> better ideas without stomping on the USE=gtk{2,3} historical meaning.
>
>
> When arguing in favor of supporting gtk2 builds more for apps, please
> do keep in mind that gtk2 really is pretty much dead. And no, MATE,
> XFCE and others are NOT continuing its support; they are just slow in
> fully converting to gtk3, but they are doing so and I expect both of
> those to be fully done this year, around autumn.
> If the issue is political or just a general gnome3 or gtk3 hate, then
> I would ask you to keep your political opinions or hate outside this
> thread and go contemplate on more important life issues.
> If the issue is lack of themes, then I would like you to help package
> more gtk3 themes. gtk3.20 now has a stable CSS based theme API and
> themes shouldn't be breaking anymore beyond this point, theoretically.
> And gtk3 theme packages should pretty much just be CSS files and some
> metadata. Though we have yet to get over that bumpy thing yet (a main
> reason gtk3.20 isn't in main tree yet).
>
> Thoughts? Agreements? Suggestions?
> I'm particularly interested in QA opinion here. I believe WilliamH
> wanted to spearhead this from their side.
>
>
> Regards,
> Mart Raudsepp
> Gentoo developer, GNOME team
>
I'll be really sad when gtk2 is totally abolished in Gentoo. :(
I suppose I'll have to break down and switch to KDE maybe.
In my opinion the upstream gtk developers have gone somewhat bonkers
with their cartoonish changes to the look, feel and generally
un-intuitive user interface. The new file selector is irritating to use
despite getting all the old behaviour settings I know of set, the lack
of the ability to paste a path into it, forcing you to navigate
directory by directory, and other BS behaviour... Some apps even have
less functionality and usefullnes. I have a local copy of
dev-vcs/gitg-0.27 ebuild which I use daily which despite some
instability is far more useful than it's "modern" counterpart. I use
xfce4 for both work and my own workstation, and like it, but it's apps
are getting increasingly more corrupted by gtk3isms :(
So, I accept I'll not be liked by the gtk team for wanting to keep gtk2
around still.
--
Brian Dolbec
Re: [gentoo-dev] Proposal for changes for the next EAPI version
On Tue, 17 May 2016 15:53:34 +0200 "M.B." wrote: > Am 17.05.2016 um 09:37 schrieb Pallav Agarwal: > > For normal users we wouldn't. But currently, arch-testers need to > > make a judgement call on what to test when a stable-req bug is > > filed. Tests run in src_test are provided by upstream, and does not > > guarantee that a package that has been merged will actually run on > > the system. If the maintainer could add a couple small scripts to > > check basic functionality > > of the merged package, it would make testing for arch testers much > > easier and reliable. > > Let me give an example. Let's say > > app-misc/screenfetch-2.7.7 is the current stable package for > > screenfetch in the portage tree. > > However, on running, it produces an error on the top, along with > > the proper output. > > If screenfetch-3.0.0 happens to fix that error, maintainer can add > > a simple script > > > >if [ "$(screenfetch 2>&1 1>/dev/null)" != "" ] then > > eerror "Still producing error" > >fi > > > > To make sure the build is properly updating the screenfetch > > version, and that > > the bug has in fact been fixed. This is the only way I can see to > > reliabily and automatically test packages that have been merged > > successfully. > > > > --- > > Regards, > > Pallav > > > > On Mon, May 16, 2016 at 10:08 PM, Luis Ressel > > wrote: > >> On Mon, 16 May 2016 18:13:33 +0530 > >> Pallav Agarwal wrote: > >> > >>> What I'm suggesting is to add a new function post_install_test. > >>> The function will run only if the build is being run for > >>> stabilization (either as a part of automated stabilization, or > >>> manual) which can be controlled by a USE flag. The function would > >>> also require independent dependencies in case it uses external > >>> applications to test the one being built. > >> > >> Could you please elaborate on this? We already have src_test() for > >> automated tests. Why would we want to run additional tests after > >> the package has been merged? > >> > >> -- > >> Regards, > >> Luis Ressel > >> > >> Luis Ressel > >> GPG fpr: F08D 2AF6 655E 25DE 52BC E53D 08F5 7F90 3029 B5BD > >> > > > > Good afternoon, > > facilities for running post-install (pre-merge) QA-checks are in > place. Please have a look at portage's misc-functions.sh, > install_qa_check() will reveal the locations where you can find the > installed checks, along with a place for local overrides. Perhaps you > can design something around this? > > With kind regards, > tomboy64 > These tests would be run post-merge, in the normal file system. Mainly for stabilization checks that can be automated, so not a QA-checks qualifier which looks for common problems that can potentially lead to bugs before it is merged to the normal file system. -- Brian Dolbec pgpX_padjvLLx.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] NEW: split portage/repoman releases now in the tree
On Tue, 17 May 2016 08:50:25 +0200 Marcin Mirosław wrote: > W dniu 16.05.2016 o 10:45, Dirkjan Ochtman pisze: > > On Mon, May 16, 2016 at 3:39 AM, Brian Dolbec > > wrote: > >> repoman-2.3.0_rc1 is the stage2 rewrite code. The checks are now > >> modular, and using the portage plugin system. The system is not yet > >> fully plug and play. Those changes will take place in the stage3 > >> re-writes. > > > > Thanks for working on this, it sounds great! > > But it doesn't sounds so great for every every user;) > https://bugs.gentoo.org/show_bug.cgi?id=583252 > > > There was a reason it was released as _rc1, And it was fixed real quick with _rc1-r1, it was a small easy fix. Incidentally , the error was in the portage code, not the new repoman code which your reply above seems to indicate. For those of you that might have installed _rc1, the easy fix is install repoman, then upgrade to _rc1-r1, then unmerge repoman if you don't want it. For those that may not know, _rc stands for release candidate, when major changes are done. Code is often released as a release candidate to shake out any missed change that might be needed but missed due to configuration and other conditions on the developers systems. Thank you to those that tested it quite thoroughly after I released it. Including finding the fix right away :D -- Brian Dolbec
[gentoo-dev] NEW: split portage/repoman releases now in the tree
portage-2.3.0_rc1 and repoman-2.3.0_rc1 are now in the tree. portage-2.3.0_rc1 is essentially the portage 2.2.28 release with only a few small patches applied. It mostly just installs less code, namely the repoman code. So, now servers and other systems that do not require repo Q/A ability will no longer get repoman installed anyway. repoman-2.3.0_rc1 is the stage2 rewrite code. The checks are now modular, and using the portage plugin system. The system is not yet fully plug and play. Those changes will take place in the stage3 re-writes. The two packages will remain in the same portage git repo, although the repoman code has been moved into it's own pkg directory. It is too tied into portage api's to be on it's own just yet. An that is not likely to happen until we get a stable portage API. This new system does allow for semi-independant releases for both repoman and portage. When important API's change, it will require both to be release at the same time. So you can look forward to seeing the minor version number to get more frequent bumps than it has this last decade. Currently, the portage ebuild does not RDEPEND on the repoman ebuild. You will have to explicitly emerge it for it to be installed. It has been suggested to add a use flag enabled RDEPEND (default on) for the dev profile. I will also be adding that to the portage- release for all profiles in the coming days. NOTES: Repoman now depends on lxml for it's xml parsing and error checking along with now using metadata.xsd. It now will report a lot more errors than the previous buggy code everyone has been using. I want to thank the following people for their help and contributions to make these releases: Zac Medico Alexander Bernsten Dirkjan Ochtman for the base xml re-write code Michal Gorny for the metadata.xsd changes Göktürk Yüksek for the metadata.xml test ebuilds patches. Mike Gilbert for all the testing on the rewite code, and a number of gen-b0rk repo test ebuilds. Coacher for the recent testing, bug reports and patches. And anyone else I missed ;) So, please report any issues with either the ebuilds or installs, bugs, etc... you know the drill ;) Don't forget, please contribute more test case ebuilds to the gen-b0rk repo. The better the test ebuild coverage we have, the better our Q/A tools (like repoman) will be and the less often things will be released broken. Thank you -- Brian Dolbec
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/
On Sun, 15 May 2016 04:18:39 -0700 Daniel Campbell wrote: > On 05/15/2016 02:15 AM, Brian Dolbec wrote: > > On Sun, 15 May 2016 11:05:21 +0200 > > Jeroen Roovers wrote: > > > >> On Sat, 7 May 2016 23:25:58 +0200 > >> Michał Górny wrote: > >> > >>> Do you seriously expect this code to work? How about testing? Or > >>> reading diffs before committing? > >> > >> > >> Somebody could have a go at implementing this: > >> > >> https://bugs.gentoo.org/show_bug.cgi?id=390651 > >> > >> It's been brewing for half a decade. Maybe it's time. :) > >> > >> > >> Regards, > >> jer > >> > > > > With the new repoman code structure, yes, it would be a lot easier > > to implement. > > > > Also with the gen-b0rk test repo, that will be a good testing ground > > for eclass changes too. It just needs more devs to make test > > ebuilds to get it fully populated ;) > > > What sort of test ebuilds are you looking for? There are a few > packages I'd like to see get into Gentoo but I don't want to break > anything. :P > Have a look at the gen-b0rk repo, See how the ebuilds are done, follow those examples. There are lots more errors that repoman looks for that are not yet covered by test ebuilds. There are a few more in other areas of code, but here is the biggest list of errors/warnings that repoman can test for. https://gitweb.gentoo.org/proj/portage.git/tree/repoman/pym/repoman/qa_data.py?h=repoman -- Brian Dolbec pgpRMqKiMf0hB.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/
On Sun, 15 May 2016 11:05:21 +0200 Jeroen Roovers wrote: > On Sat, 7 May 2016 23:25:58 +0200 > Michał Górny wrote: > > > Do you seriously expect this code to work? How about testing? Or > > reading diffs before committing? > > > Somebody could have a go at implementing this: > > https://bugs.gentoo.org/show_bug.cgi?id=390651 > > It's been brewing for half a decade. Maybe it's time. :) > > > Regards, > jer > With the new repoman code structure, yes, it would be a lot easier to implement. Also with the gen-b0rk test repo, that will be a good testing ground for eclass changes too. It just needs more devs to make test ebuilds to get it fully populated ;) -- Brian Dolbec
Re: [gentoo-dev] USE flag proposal: memcached
On Sat, 14 May 2016 11:32:02 -0400 "Anthony G. Basile" wrote: > On 5/14/16 11:19 AM, Dirkjan Ochtman wrote: > > All, > > > > I want to add a "memcached" USE flag to mail-filters/rmilter. Before > > doing so, I looked if there was a global USE flag. There is not, > > but I though see usage across 14 packages: > > > > dev-db/pgpool2[memcached]: Use memcached for query caching > > dev-php/pecl-mysqlnd_qc[memcached]: Use > > dev-libs/libmemcached as a storage handler > > mail-filter/opendkim[memcached]: Add support for using > > dev-libs/libmemcached > > mail-mta/postfix[memcached]: Add support for using > > net-misc/memcached for lookup tables > > net-analyzer/graphite-web[memcached]: Enable memcached support > > net-analyzer/munin[memcached]: Install the packages required for > > memcached monitoring. > > net-mail/automx[memcached]: Enable memcached support > > sys-auth/keystone[memcached]: Installs dependencies needed for using > > memcached as a backend > > sys-cluster/cinder[memcached]: Installs the memcached server > > sys-cluster/gearmand[memcache]: Support memcache daemon (via > > dev-libs/libmemcached) for the queue storage. > > sys-cluster/nova[memcached]: Installs the memcached server > > sys-cluster/swift[memcached]: adds memcached support > > www-servers/lighttpd[memcache]: Enable memcache support for mod_cml > > and mod_trigger_b4_dl > > > > Most of these seem to depend on dev-libs/libmemcached or > > net-misc/memcached, with a few packages depending on > > language-specific stuff (e.g. dev-perl/Cache-Memcached or > > dev-python/python-memcached). > > > > I suppose the description can just be "Enable memcached support". > > > > Any objections? > > > > Cheers, > > > > Dirkjan > > > > its a good idea given its popularity and the unequivocal meaning of > "memcached". so i say do it. > +1 -- Brian Dolbec
Re: [gentoo-dev] [PATCH] ebuild-writing/variables: better describe ROOT
On Tue, 10 May 2016 22:40:39 -0400 Mike Gilbert wrote: > On Tue, May 10, 2016 at 9:54 PM, Brian Dolbec > wrote: > >> I agree, repoman should be catching this stuff. > >> > > > > Then Please contribute some test ebuilds for the gen-b0rk repo to > > test repoman or any other Q/A apps with. If they fail to detect > > the test ebuilds, it will give us something to use to help trace > > the code errors. It'll also make for a much better testing system > > overall for any app performing any type of Q/A on ebuilds. > > I don't think there is a repoman check for ROOT in src functions > (yet). I was just saying that I think it would make sense to add that. > As you know, with the modular system now in place, It should be quite easy to add that check now. There is no need to figure out where in over 3000 lines of spaghetti code to insert it without messing up something else. Make the test ebuilds, at least one good one, plus however many to test the broken parts. It should only take an hour to add that check. -- Brian Dolbec
Re: [gentoo-dev] [PATCH] ebuild-writing/variables: better describe ROOT
On Tue, 10 May 2016 21:42:19 -0400
Mike Gilbert wrote:
> On Tue, May 10, 2016 at 5:25 PM, Michael Orlitzky
> wrote:
> > On 05/10/2016 02:28 PM, Mike Gilbert wrote:
> >> On Tue, May 10, 2016 at 11:08 AM, Michael Orlitzky
> >> wrote:
> >>> We have maybe 150 ebuilds in the tree using $ROOT in src_*
> >>> functions. Some are bugs, but many look OK to me. Do we really
> >>> want to say "never" do that?
> >>
> >> According to PMS, it is only legal in pkg functions.
> >>
> >> Can you point to an example where using ROOT in a src function is
> >> appropriate?
> >
> > Modulo the question "when should you use $ROOT over $EPREFIX"...
> >
> > * the chrome-binary-plugins ebuilds use it in src_install.
>
> This is quite obviously wrong. I happen to maintain that ebuild, so I
> just fixed.
>
> > * dmraid does
> >
> > einfo "Appending pkg.m4 from system to aclocal.m4"
> > cat "${ROOT}"/usr/share/aclocal/pkg.m4 >>"${S}"/aclocal.m4 ||
> > \ die "Could not append pkg.m4
>
> This should be one of two things:
>
> cat /usr/share/aclocal/pkg.m4
>
> Or, if prefix support is desired:
>
> cat "${EPREFIX}"/usr/share/aclocal/pkg.m4
>
> > Both of those look like EPREFIX candidates to me, but they're not
> > obviously wrong, either. Maybe it made sense in EAPI <= 3.
> >
> > Anywhere that you need addpredict() it also seems reasonable. The
> > v4l-dvb-saa716x ebuilds use "${ROOT}/usr/src/linux/" where EPREFIX
> > would not be a good replacement.
>
> Nah, usually addpredict is dealing with stuff in the system that is
> performing the build. Sandboxed phases should never be looking at
> ROOT.
>
> Those ebuilds should probably do addpredict /usr/src/linux instead.
>
> >
> > Something needs to be fixed, though: you're right that the PMS
> > limits ROOT to pkg_*. Who knew? If we want to be serious about
> > banning ROOT in src_*, we should add a repoman error.
>
> Based on my own understanding of the ROOT variable, its use in src
> functions is always nonsensical, especially when you consider binpkgs.
> A binpkg can be installed with a ROOT value that is completely
> different from its value when the package is being compiled.
>
> To put it another way, in src functions, ROOT could/should always be
> "/". The real value of ROOT isn't determined until merge time.
>
> I agree, repoman should be catching this stuff.
>
Then Please contribute some test ebuilds for the gen-b0rk repo to test
repoman or any other Q/A apps with. If they fail to detect the test
ebuilds, it will give us something to use to help trace the code errors.
It'll also make for a much better testing system overall for any app
performing any type of Q/A on ebuilds.
--
Brian Dolbec
Re: [gentoo-dev] On banning merge commits
On Sun, 08 May 2016 11:06:09 +0100 Amadeusz Żołnowski wrote: > I am working at the moment on debundling ejabberd. It will come with > ~30 packages and I will do "git merge --no-ff ejabberd-debundled" > because it will actually look less messy. > > Thanks, > -- Amadeusz Żołnowski Yes, this is exactly the type of merge commits that should be allowed. Not the one or two user PR commits that might be based on a weeks old tree, that a developer merges without rebasing. It is these merge commits which have caused all the grief we've experienced over merge commits. Merge commits should be used wisely and for larger branch merges like the kde, gnome team's development overlay merges to the main tree or similar larger one off project's like the one above. It is these larger commit branches that are much more difficult to "git pull --rebase && git push --signed" successfully without some other pushes in between causing a rejected non-fast forward push. -- Brian Dolbec pgpSUtzSFxJgr.pgp Description: OpenPGP digital signature
[gentoo-dev] New gen-b0rk repository specifically for Q/A tools testing
In order to further improve the chances of Q/A tools catching errors. I have created a new repo (overlay) which will contain minimal test case ebuilds. The idea is to have test case ebuilds to run repoman code against. The outcome of these runs should be comparable to pre-recorded output. In that way as more code changes are applied as part of the stage3 re-write as well as new test cases and checks to be added to it's capabilities. It should minimize the bugs introduced in releases. Repoman does have some unit tests, but it is far from 100% coverage. Also with the major structural changes that the code has been undergoing, it is not always possible for the unit tests to be compatible with the new code. This new repository is open to all Gentoo developers to contribute to. All we ask is that you follow some simple common sense rules for adding additional test ebuilds. The repo is located at: https://gitweb.gentoo.org/repo/proj/gen-b0rk.git/ Here is the README included in the base directory. This repository is for the primary purpose of testing Q/A tools like repoman. The ebuilds it contains are for testing specific areas of tests that are performed as part of the normal operation of that Q/A tool. This repository is open to all Gentoo developers under the following rules: 1) The master branch is to remain the stable Q/A testing branch. 2) All ebuilds are to be minimal test cases. 3) All ebuilds in it are to have no more than 3 or 4 flaws to detect. This makes it easier to spot errors during code development. Simply running repoman in a category should be enough to test everything the module tests. This excludes some commit only checks which can be run in a local only branch. 4) All category names are to represent the Q/A category being tested. ie: ebuild-test - tests various aspects of the ebuild repoman module eclass-test - various eclass module tests ... 5) like the category naming, the package naming will follow the test being performed. ie: eclass-test/live-keywords - test the eclass module LiveEclassChecks keywords check ebuild-test/invalid - test for invalid package name detection 6) Profiles ... Not sure about this one, but probaly will have masters=gentoo That should ensure it maintains co-ordination with the main gentoo repo. All new or modified eclasses that affect pkg metadata should be validated in a branch. 7) New module development and test ebuilds will be done in a branch or personal repo and submitted to the gentoo-portage-dev email list for review and approval to merge into master. NOTE: This rule is lifted for the initial creation and population of test ebuilds to use to test out the repoman code. An anouncemnt to the gentoo-project email list will be made when this initial population period is being ended. 8) Signed commits only, also signed-pushes are mandatory 9) The metadata category will get files of validated output that can be used to verify code changes in the various categories and repo wide runs. Diffing the output, should help to verify code changes did not break anything. 10) See rules 1-9 :-) -- Brian Dolbec pgpU8UI_wWO7k.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] metadata.dtd: Remove obsolete element per GLEP 68
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sun, 1 May 2016 18:42:54 -0400 Göktürk Yüksek wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Michał Górny: > > On Sat, 30 Apr 2016 02:36:18 -0400 Göktürk Yüksek > > wrote: > > > >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 > >> > >> Michał Górny: > >>> On Thu, 28 Apr 2016 19:41:06 -0400 Göktürk Yüksek > >>> wrote: > >>> > >>>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 > >>>> > >>>> Brian Dolbec: > >>>>> On Thu, 28 Apr 2016 15:39:05 -0400 Göktürk Yüksek > >>>>> wrote: > >>>>> > >>>>>> --- metadata.dtd | 5 + 1 file changed, 1 > >>>>>> insertion(+), 4 deletions(-) > >>>>>> > >>>>>> diff --git a/metadata.dtd b/metadata.dtd index > >>>>>> 7626a57..b608852 100644 --- a/metadata.dtd +++ > >>>>>> b/metadata.dtd @@ -3,7 +3,7 @@ >>>>>> pkgname CDATA ""> > >>>>>> > >>>>>> - >>>>>> > >>>>>> (maintainer|natural-name|longdescription|slots|use|upstream)* > >>>>>> )> + >>>>>> (maintainer|longdescription|slots|use|upstream)* )> > >>>>>> @@ > >>>>>> -13,9 +13,6 @@ explicit type) for Gentoo maintainers is > >>>>>> prohibited. --> >>>>>> (person|project|unknown) "unknown"> > >>>>>> > >>>>>> - - >>>>>> natural-name (#PCDATA) > >>>>>>> - > >>>>>>> > >>>>>> > >>>>> > >>>>> Isn't this almost obsolete? it's now xmlschema... And I > >>>>> hope to have the new repoman with it out this weekend :) > >>>> > >>>> Does GLEP 68 explicitly declare metadata.dtd obsolete? I see > >>>> that the example metadata.xml on the GLEP is missing DOCTYPE, > >>>> are we getting rid of those too? > >>> > >>> No, and I don't know. > >>> > >>> metadata.dtd is still required by many tools, and as such it > >>> makes sense to keep it. However, we may want to put some > >>> warning that it's not very strict, and allows major structural > >>> violations due to technical limitations. > >>> > >> After a discussion with ulm on IRC, we agreed that the following > >> makes sense: "the format of the metadata is defined in GLEP 68. > >> the syntax is defined in metadata.dtd. The xml-schema can be used > >> for stricter validation checks." If you have no objections, I > >> will update devmanual based on this description. > > > > What is the precise difference between 'format' and 'syntax' here? > > I'm no native English speaker, and I don't see any obvious split > > of responsibility between the two here, and I'm pretty sure this > > will be quite confusing for other people as well. > > > I admit that it is hard to make a clear distinction. When I look at > the GLEPs replaced by GLEP68, I see that they propose a change for > metadata.xml and explain how that affects metadata.dtd. GLEP34 has > "The DTD file would need to be updated to include the > element.", GLEP46 explicitly says "metadata.dtd should allow the use > of a upstream tag in metadata.xml.", GLEP56 points to #199788 which > required DTD to be patched. GLEP68 is rather vague as to how > metadata.dtd is affected. It doesn't say whether it should be updated > or if it has any role at all. > > GLEP68 provides a single human readable specification for the metadata > format. In that respect, however, the DTD along with the comments in > it is just as expressive, if not better: a developer can read through > the DTD and learn all the information contained in the GLEP, plus the > remote-id values which are not part of the specification for reasons > you stated earlier. And that was the reason why I used the term > "syntax": the DTD lists all the allowed elements, attributes, and > values for the metadata that should be used in conformance with the > GLEP . > > In the end, the DTD isn't much better than the GLEP as a human > readable document and does a worse job than the xsd as a machine
Re: [gentoo-dev] [PATCH] metadata.dtd: Remove obsolete element per GLEP 68
On Thu, 28 Apr 2016 15:39:05 -0400 Göktürk Yüksek wrote: > --- > metadata.dtd | 5 + > 1 file changed, 1 insertion(+), 4 deletions(-) > > diff --git a/metadata.dtd b/metadata.dtd > index 7626a57..b608852 100644 > --- a/metadata.dtd > +++ b/metadata.dtd > @@ -3,7 +3,7 @@ > > > > - ( (maintainer|natural-name|longdescription|slots|use|upstream)* )> > + ( (maintainer|longdescription|slots|use|upstream)* )> pkgmetadata pkgname CDATA ""> @@ -13,9 +13,6 @@ > explicit type) for Gentoo maintainers is prohibited. --> > > > - > - > - > > > Isn't this almost obsolete? it's now xmlschema... And I hope to have the new repoman with it out this weekend :) -- Brian Dolbec
Re: [gentoo-dev] Re: BROKEN: repository became broken!
On Wed, 30 Mar 2016 16:52:13 +0200 Patrick Lauer wrote: > On 03/30/2016 04:32 PM, mgo...@bonedaddy.net wrote: > > Looks like someone just broke Gentoo! > > > > New issues: > > https://qa-reports.gentoo.org/output/gentoo-ci/33f062a/output.html#dev-db/aerospike-server-community > > > > > > Introduced by commits: > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=54033c5 > > > > > > Changes since last check: > > https://gitweb.gentoo.org/repo/gentoo.git/log/?qt=range&q=0d2b3ad..54033c5 > > > > -- > > Gentoo repository CI > ... can you please either use repoman like everyone else, or fix > repoman to match the behaviour you like? > > 'cause it's annoying to have repoman say all is well and then get > such a nice response. Hard to comply with rules if there's no good > way to check the rules. > > Yeah, it would be nice to have a final resolution to the metadataDTD ==> xmlshema change so the repoman metadata module can get a proper re-write. In the meantime, repoman can not detect the recent change to the maintainer field. -- Brian Dolbec
Re: [gentoo-dev] Repoman rewrite stage3. Migrate check data to the tree
On Thu, 10 Mar 2016 18:40:31 -0800 Patrick McLean wrote: > On Thu, 10 Mar 2016 18:30:07 -0800 > Brian Dolbec wrote: > > > So, where do we place this directory and what rules do we > > establish about it's modifications? > > > >location? : in the metadata dir alongside the install-qa-check.d > >directory? > > That sounds reasonable to me, it is certainly metadata. > > > > >name of the directory? : repoman, qa-rules, qa-data, > > repo-qa-data, ... ideas? > > Something not project name specific, so nothing about repoman. Perhaps > something like "repo-checks", my personal vote would be make it a > directory with the contents being merged (so repo-checks.d maybe?) > > > > >data format? : json (my favorite) > > compatible with many lanquages/interfaces > > is flexible to match various data types > > ie: dictionaries, lists, strings... > > is human readable/editable > > can be validated > > > >xml (PLEASE NO!) > > > >native python file (too language dependant) > > > >ini style (python configparser compatible) meh :/ > > > >other ideas? > > YAML - like JSON but made to be edited/read by humans (comment support > is a big feature). Also valid JSON is valid YAML. Also can be > validated just like JSON can. OK, I just had a closer look at yaml. It does look easier for humans to edit and read. And seems to have the same data type flexibility. Maybe not quite as many languages have libs for it. But I don't think that is an issue for this data. I also want to separate the repoman release from the main portage release. This will have several advantages. 1) smaller portage install for installs that don't need repoman capabilities. 2) Repoman can add extra dependencies as needed for things like pyyaml and xmlschema. These deps would not be required for the base portage/emerge code. Keeping a base install stage3 lighter and not complicate bootstrapping a stage1, stage2. 3) They can be released indendant of each other as the need for a new release is desired/required. While repoman will still be tied to the portage codebase. Most of it's code use is via fairly stable API's. So only when those API's change will there need to be a simultaneos release. -- Brian Dolbec
[gentoo-dev] Repoman rewrite stage3. Migrate check data to the tree
With the repoman rewrite stage2 code about to be merged into master. And a release including it to be made soon. I am going to start on stage3 of the rewrite. So... It is time to start painting a bikeshed about moving all possible check data to the tree. In that way small changes to things like the deprecated eclasses to scan for can be added to/or removed and the updates will propagate to everyone as they git pull the gentoo repo. So, here is my initial thoughts so far. We (portage team) discussed the possibility of making the data available for download via api.gentoo.org. But we decided it would be much better if that data was included in the repository. In that way it makes off-line work easier without having to deal with having a live connection to fetch the latest version of the data. It also then matches your current tree checkout. It could also make it easier for alternate repositories to establish their own QA data files. I'm thinking that we should establish a directory for the files containing the data for the checks being run. With the module systems now in place with the stage2 rewrite code. I was thinking that we should break up the data into logical files to go with the different scan modules present in repoman. If a new module is created, then a new data file may be created for it's dynamically changeable QA data. This also has the advantage that if a new app comes along that performs these same types of checks. It should be able to make use of this same data. So, where do we place this directory and what rules do we establish about it's modifications? location? : in the metadata dir alongside the install-qa-check.d directory? name of the directory? : repoman, qa-rules, qa-data, repo-qa-data, ... ideas? data format? : json (my favorite) compatible with many lanquages/interfaces is flexible to match various data types ie: dictionaries, lists, strings... is human readable/editable can be validated xml (PLEASE NO!) native python file (too language dependant) ini style (python configparser compatible) meh :/ other ideas? editing rules? : Similar to eclass modifications... email to the gentoo-dev list for review, possible objections. The current releases of portage/repoman would continue to use internal data. But this new data would need to precede a repoman release that uses it. Initially this stage3 code will continue to be developed in the repoman branch of the portage repo. It is also possible to test this git checkout code by establishing a symlink to the checkouts repoman command somewhere in your users PATH. Personally I named mine repom, and lives in my ~/bin directory. In that way I can easily switch between an installed repoman and the developing code to compare results to aid in debugging. -- Brian Dolbec
Re: [gentoo-dev] Gentoo tree package moves updates.
On Tue, 8 Mar 2016 22:40:34 +0100 Ulrich Mueller wrote: > >>>>> On Tue, 8 Mar 2016, Brian Dolbec wrote: > > > As discussed a few years ago. We agreed to trim the package moves > > updates to maintain 4 years history active in the tree. It currently > > still goes back to include 2010. There was a recent edit to a 2010 > > file that triggered a full re-processing of those files. > > That's not correct. I had noticed reprocessing of all files already > around March 1st, definitely before the edit of the 1Q-2010 file. There has been at least one time recently that a change in the rsync tree generation scripts caused an massive download of files and re-processing of the updates. I believe that was the incident you were referring to. I saw chat (#gentoo-dev) a few days ago from dwfreed. He was testing out more changes to those scripts. So, it is possible that a script update once again caused the re-processing. I'm inquiring if that was indeed the reason. > > > Last night for me it was triggered again. I don't know the cause, > > but I really don't care enough to investigate. But it prompted bug > > 576752. > > > That said, being 2016, I am going to trim 2010 and 2011 files from > > the active tree in 48 hours unless anyone shows a valid and > > justifiable reason to keep them. > > That would (maybe) cure the symptoms, but don't you think that the > real bug should be found? I suggest that you wait with removal of the > files until then. > > Ulrich No, it won't cure the symptoms, just, shorten the number processed. Also it will eliminate a possible need to edit those old files like had been done recently. -- Brian Dolbec pgp3AUbJaRqtO.pgp Description: OpenPGP digital signature
[gentoo-dev] Gentoo tree package moves updates.
As discussed a few years ago. We agreed to trim the package moves updates to maintain 4 years history active in the tree. It currently still goes back to include 2010. There was a recent edit to a 2010 file that triggered a full re-processing of those files. Last night for me it was triggered again. I don't know the cause, but I really don't care enough to investigate. But it prompted bug 576752. That said, being 2016, I am going to trim 2010 and 2011 files from the active tree in 48 hours unless anyone shows a valid and justifiable reason to keep them. Unlike last time which I made the trimmed update files available for download. With the tree now being git based. They will be easily available in the git history. Thank you -- Brian Dolbec
Re: [gentoo-dev] Re: Bug #565566: Why is it still not fixed?
On Wed, 24 Feb 2016 21:16:13 +0100 Luis Ressel wrote: > On Wed, 24 Feb 2016 11:18:55 -0800 > Raymond Jennings wrote: > > > As far as changelog generation, what about causing the changelogs to > > be autogenerated by the end user's computer? Divide and conquer. > > That would require a local git clone. And that's exactly what those > who still want Changelogs are trying to avoid. > Not only that, but their generation along with thick manifests are already quite resource intensive and time consuming for a relatively high powered server (a big reason behind this thread). Now make some older users system or low powered arm system do that with much lower resources and you are talking about a long time for completion. -- Brian Dolbec pgpF8oAtbYAJh.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Changing order of default virtual/udev provider
On Tue, 16 Feb 2016 23:16:41 +0100 Michał Górny wrote: > On Tue, 16 Feb 2016 20:57:31 +0100 > Patrick Lauer wrote: > > > On 02/16/2016 08:33 PM, Michał Górny wrote: > > > This all is going into some bickering nonsense and noise made by > > > systemd haters just to feed their troll, FUD and whatever else > > > they made around here. > > You call it hate, I call it having a choice. > > You have a choice. This is trying to force your choice on everyone > else just because you hate the other option and don't want anybody to > be using it. > NOT EVERYONE, just make it the non-systemd default, htere is still choice to change to to whatever... > > > Because certainly > > > project that is created plainly for political reasons is better. > > > Because it will certainly be technically better if people have to > > > focus on copying regular udev maintainers and reworking their > > > changes to keep them working on forked codebase. > > > > > > And after all, as someone said, this will give eudev proper > > > testing. > > (1) It's already used by lots of people > > (2) 'proper' testing? As opposed to be the default in more than a > > dozen distros that have usecases you and I rarely think of? > > Are you really serious with those fringe distros? How many of them > have a dozen users that do not happen to be developers of the distro? > How many of them are actually used in production? How many of them > have diverse enough userbase to prove that eudev works in different > environments? Now you are starting to spout incomplete truths from being riled up, not thinking things through. Since you consider them to be just a dozen or so... In the 8 months where I am working now, they use eudev for all their installs. This includes more than 50 different server profiles and resulting images. Those are multiplied out into multiple instances in each rack and server clusters distributed in many places around the world. So a real world example puts it over a 1000 units (guesstimate) in daily production. Plus several hundred more on the development and testing clusters. Plus several hundred (minimum) workstation and developer vms. In that 8 months in the release engineering team, I've not seen one email or bug report that has been due to a problem with eudev. If there were I did not see it pass thru the group communications channels. So, there are lots more eudev users out there than the few dozen you seem to intimate to. Can we please put an end to this thread! ONE WAY OR THE OTHER!!! -- Brian Dolbec pgpFDfuOoylwW.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Changing order of default virtual/udev provider
On Tue, 16 Feb 2016 15:26:46 -0500 "Anthony G. Basile" wrote: > On 2/16/16 3:05 PM, Rich Freeman wrote: > > On Tue, Feb 16, 2016 at 2:57 PM, Patrick Lauer > > wrote: > >> The whole discussion, which seems to turn everyone into a raging > >> squirrel, is about changing the default provider of a virtual. All > >> other providers will continue being listed and available. The > >> change affects none of the current userbase (who seem to have a > >> preference for eudev if forums polls have any meaning). > > > > Why is it that anytime there is a great debate over something > > somebody says something like the following: > > https://www.youtube.com/watch?v=6rI8mDpnv7c > > > > > This decision is completely trivial and won't really change > > anything. That is why it is so critical that we make this decision > > right now! > > > > Either it matters or it doesn't... > > > > And I had resisted several times now of pasting in youtube links... :) time for some humor injection... OK, in this first link, the eudev people think the systemd people are the one migrating and the systemd people think the reverse... https://www.youtube.com/watch?v=AOOs8MaR1YM And from some people's comments in this thread... https://www.youtube.com/watch?v=dndAXxqJbc0 -- Brian Dolbec
Re: [gentoo-dev] Changing order of default virtual/udev provider
On Tue, 16 Feb 2016 19:53:48 +0100 Chí-Thanh Christopher Nguyễn wrote: > William Hubbs schrieb: > > Maybe FUD is the incorrect way to put it, but I think us doing > > something about it at this point is definitely premature since > > KDBUS is no where near ready to go -- they were forced to retract > > it a while back because they had to re-think the design. > > kdbus got sent for inclusion in the kernel, and they were sure ready > to pull off their plan back then if kdbus had been accepted. > > Whether switching to eudev now is premature is actually the central > issue of this whole discussion. Given that dropping support for udev > on non-systemd systems was narrowly avoided once, and upstream leaves > no doubt that they are ready to do so once their redesigned kernel > message bus goes upstream, I say describing such a move as > "definitely premature" is not warranted. > > > Best regards, > Chí-Thanh Christopher Nguyễn Thank you for bringing this information to the forefront of this debate. So, is it not better for us Gentoo-er's that wish to not install systemd, to set the default non-systemd udev to eudev. In that way, maybe eudev will get more contributed support and Anthony more eyes on things. It seems that unless kdbus is perpetually rejected by the kernel team... it is only a matter of time. So, I say, we've all had enough bickering about the subject. Time for a final vote! If we had all spent our time working on real problems as we've spent reading this never ending debate mail... but alas, this will be yet another item that must be decided by the council. -- Brian Dolbec
Re: [gentoo-dev] Changing order of default virtual/udev provider
On Sun, 14 Feb 2016 11:00:30 -0500 Rich Freeman wrote: > On Sun, Feb 14, 2016 at 10:14 AM, Patrick Lauer > wrote: > > If, for any reason, eudev should be abandoned - we can just change > > the virtual back. One-line change. > > Which is precisely the corresponding argument for not switching the > default to eudev in the first place. > OH, my, this is looking more like you are being paid by systemd peeps... THIS IS OPEN SOURCE, there is not a single project out there that might not become abandoned at some point in the future. Even Microsoft may eventually abandon their crappy windows, Apple abandon it's current platform, (wait they did that once or twice already)... You are just refusing to acknowledge these simple facts. systemd.: irrelevant to this decision standalone systemd-udev.: Vehemently unsupported, support for its capability to exist is planned to be punted in the future. eudev...: fully functional, actively developed, and fully supported, mature project, been around for years. Oh and here is one final piece that should blow your reason away https://github.com/gentoo/eudev <== NOTICE that it's upstream is within our gentoo domain. That means if Anthony (god forbid) were to be hit by that proverbial bus. The project can be easily assigned new developers. Not to mention the fact that with 14 downstream distributions using it as their udev implementation. That I am sure some downstream developers would step up and continue its development too. Need I go on to list examples of other current projects that have continued when their main developer had gone for one reason or another. HINT: they are current Gentoo defaults too. So PLEASE show us you are capable of seeing and acknoledging the above simple facts and give up these BS arguments. This whole BS over a simple decision is giving me flashbacks of jury duty I did. But at least then, it was over something serious. It was a murder trial. This is about a simple virtual and the default order of its providers!!! -- Brian Dolbec
Re: [gentoo-dev] Re: Changing order of default virtual/udev provider
On Wed, 10 Feb 2016 10:26:12 -0600 William Hubbs wrote: > > Often the decision to procrastinate is a decision that is rewarded. > > That should be considered carefully. > > + 1. > > I also saw another issue that made me shudder. If we change the > default to eudev, people who are running separate /usr are going to > think they can kill their initramfs's, because people in gentoo > conflated the separate /usr and initramfs issue with udev [1]. > > William > > [1] https://bugs.gentoo.org/show_bug.cgi?id=573760#C4 That isn't a worthwhile reason to procrastinate. IMO we're going to get those _ANYWAY_ no matter how long we wait, within reason of course. There will always be users that can't read/type/whatever and fail and file bugs. So if we have to wait for one (or more) users to forget about the initramfs crud & confusion, we'll be waiting 20 years. By then even systemd will have been replaced by something else... -- Brian Dolbec pgpBW0P78uAcI.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] python-exec2 C wrapper is looking for a new name!
On Tue, 9 Feb 2016 12:32:38 -0800 Brian Dolbec wrote: > On Tue, 9 Feb 2016 14:53:52 -0500 > Ian Stakenvicius wrote: > > > On 09/02/16 02:51 PM, Michał Górny wrote: > > > Hello, everyone. > > > > > > After all those boring, meaningless and violent mailing list > > > threads, here's something nice and simple. I'd like to find a new > > > nice name for the C wrapper part of python-exec2, and I would like > > > to ask you for ideas. > > > > > > For some explanation, python-exec2 consists of two wrappers. One > > > of them is the 'core' C wrapper that does most of the work. The > > > other is a Python script with special shebang that is used to keep > > > 'python /usr/bin/foo' working while deferring direct executions to > > > the C wrapper. > > > > > > The Python wrapper is installed > > > as /usr/lib/python-exec/python-exec2 and this can't change since > > > everything is symlinked to it. The C wrapper is named > > > python-exec2-c (which is an ugly name), and since it's used only > > > internally, I can safely change its name to something nicer. > > > > > > Any ideas? If possible, I'd like to avoid ambiguity between the > > > two wrappers, so the C counterpart would have to be highlighted > > > somehow. > > > > python-exec-cwrapper ? > > > > NO, No, you mistyped it... > > python-exec-crapper > > :O > > Sorry Michał, but Ian inadvertently set that one up to nicely to avoid a little humour injection. But for a real answer perhaps: python-cexec it's much simpler, less likely to get bastardized like I did above. -- Brian Dolbec
Re: [gentoo-dev] python-exec2 C wrapper is looking for a new name!
On Tue, 9 Feb 2016 14:53:52 -0500 Ian Stakenvicius wrote: > On 09/02/16 02:51 PM, Michał Górny wrote: > > Hello, everyone. > > > > After all those boring, meaningless and violent mailing list > > threads, here's something nice and simple. I'd like to find a new > > nice name for the C wrapper part of python-exec2, and I would like > > to ask you for ideas. > > > > For some explanation, python-exec2 consists of two wrappers. One of > > them is the 'core' C wrapper that does most of the work. The other > > is a Python script with special shebang that is used to keep > > 'python /usr/bin/foo' working while deferring direct executions to > > the C wrapper. > > > > The Python wrapper is installed as /usr/lib/python-exec/python-exec2 > > and this can't change since everything is symlinked to it. The C > > wrapper is named python-exec2-c (which is an ugly name), and since > > it's used only internally, I can safely change its name to > > something nicer. > > > > Any ideas? If possible, I'd like to avoid ambiguity between the two > > wrappers, so the C counterpart would have to be highlighted somehow. > > > > python-exec-cwrapper ? > NO, No, you mistyped it... python-exec-crapper :O -- Brian Dolbec P.S. just finning with you :)
Re: [gentoo-dev] Changing order of default virtual/udev provider
On Tue, 9 Feb 2016 08:44:03 -0500 Rich Freeman wrote: > I'll admit this has been a bit of an emotional thread for me. I think > my frustration comes from the fact that it seems like the whole reason > that eudev exists is because people really strongly believe that > systemd isn't the right way to go, and yet those same people don't > seem to realize that others might feel just as strongly that eudev > isn't the right way to go. > I started the replies with a simple +1, and that I had switched to eudev... No, "Down with the evil systemd.borg" comments As one of the few huge threads that I have been reading. It is you that has been taking this thread more in the direction of something akin to a preacher shouting we're all going to burn in hell for even considering switching the default. While you were obviously more emotional, Anthony was very calmly, and clearly refuting many of your statements. > Surely anybody suggesting switching to eudev as the default > virtual/udev provider had to have realized that this would create a > huge controversy. > BUT WHY DOES it have to be! Why can't we as a group simply respond to something like this with a simple +1, -1 and a few pros/cons Why must it become yet another shouting match. And I'm sorry to have to tell you this, but you have been leading the charge in that direction. > Even if standalone udev is a dead-end (something that is speculation > at this point), it isn't like the code that exists today will suddenly > stop working. Worst case we just have to change the default at a > later point in time. > > Even just kicking the can down the road has a lot of advantages: > 1. Everything works fine today. yes > 2. We don't know for sure that it will ever stop working. no, we don't > 3. Deferring a decision means we don't have to wage a huge battle > over which way the decision ought to go. As I pointed out above, you seem to be leading the battle charge. Why couldn't you have simply replied "-1 I use systemd like most other distros" and "It works for me as is" and leave it at that. > 4. If we do have to make a decision in the future, we'll have more > information to act on. > put off till tomorrow what you can avoid doing today... tsk, tsk, tsk IT IS A SIMPLE POLL of the possibility of switching the default VIRTUAL we were suppose to be talking about/voting on Sorry everyone for a little shouting of my own. -- Brian Dolbec
Re: [gentoo-dev] Changing order of default virtual/udev provider
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Mon, 8 Feb 2016 12:01:33 -0500 Ian Stakenvicius wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 08/02/16 11:18 AM, Rich Freeman wrote: > > However, I think we're actually missing the bigger issue here. > > Why is this virtual even in @system to begin with? When I set up > > a chroot or some kinds of containers I don't need udev, or > > sysvinit (or openssh - but let's set that one aside for now). > > > > We don't stick grub or genkernel or even gentoo-sources in our > > stage3s. Why stick (e)udev in there? > > > > It seems like this should just be another step in the handbook - > > pick your desired device manager. > > > > Obviously if we produce a boot CD it will need a device manager > > (and kernel and bootloader and network manager), and I don't care > > which one it is. > > > > This just seems more like the Gentoo way, and it completely > > sidesteps all the controversy over defaults. We're already > > working on fixing the few remaining functions.sh references so > > that openrc can be removed from the system set as well. > > > > I thought the point of this discussion had to do mostly with what > udev variant gets installed when a user doesn't specify one. And > AFAIK, since there are still plenty of packages that *DEPEND on > virtual/udev , the discussion's still worth having isn't it? > > Besides, if we just move the goal of this discussion from "order of > atoms in virtual/udev" to "order of items in this new Handbook > page", we still need to decide what the default is don't we? Yes, we do. Also, it is releng's intention to change to a stage4 for normal new install stages. It will contain the most needed pkgs for new installs, and allow the @system set to be trimmed down more. It is entirely possible, to at that point, then create smaller chroot/container images without undue hardships and complexities for new installs. But please let's not sidetrack this thread more with this tangent. That's a different bikeshed to paint. - -- Brian Dolbec -BEGIN PGP SIGNATURE- Version: GnuPG v2.1 iQJ8BAEBCgBmBQJWuNEMXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNUQ3Qzc0RTA4MUNDNzBEQjRBNEFBRjVG QkJEMDg3Mjc1ODIwRUQ4AAoJEPu9CHJ1gg7YTVQQAJhStpgaDT2pqMsVuTO3HZx6 XfaZoNtcN01nqOttBwQ4C+17n8Rv2/d52Zu6lc3YSrdPgHRGOVT0LU8CyzZlz8Rw rnFeo5oZAZheqlA/4UzRMOkhXbOvT4FRDL1bF/q5t00h+pADoPDSC3ZIyS8enkvr Evm3DYpDDT40pM5f7cwlAqRarJL604XDgFmU5Qhtmtnxw+TRIicGTwHoWe4fk77u PNm3ZrU+ea7b2XAwKH+oDVM0UDMfFLi37APGd4R2VC0jJmp0msPnNfKRvpURcNo5 3iZMMDuM7vqJergB2yCfiqaGdHmaEPX1PLpQEuhgLWS0b6lCN4JKenYpRdNVLjZG FqOEtSVUs9iNt++XmsZ6goLQAczePOxqR/aAJOMrXuhePiuXMRmm1MBQK2yRRo6q 6MU/lj+1YAzEWMyOZH9GNzQhCl1cBj+futm6mRTWYsNCaKOGi/ocnIHiQpXyKf/U dp/hlvx2rhqMz6eqO60OaJHaKzbCV6EbGb3kv0AsC4VGGFS+DpoUen21aetBh82O aE6c/hKNvsgARQl0mpwFDttSnB24oRr8E9pR5Rvf7iQJwL7h/5gHvs2YQRL9PxFR vSN1R67Sge9JrAzQ/OmEBbl5exO2a1/0HShfdfvU6oA/lDShFHyttJXYxGi0tDym A2Bo/b9FonL7aEmwilCH =PiEj -END PGP SIGNATURE-
Re: [gentoo-dev] Changing order of default virtual/udev provider
On Mon, 8 Feb 2016 10:08:22 +0100 Patrick Lauer wrote: > Ohey, > > I've opened a bug at: > https://bugs.gentoo.org/show_bug.cgi?id=573922 > > The idea here is to change the order of the providers of virtual/udev. > For existing installs this has zero impact. > For stage3 this would mean that eudev is pulled in instead of udev. > > The rationale behind this is: > > * eudev is an in-house fork, and there's more than a dozen distros > already using it by default that are not us. Which is a little bit > weird ... > > * Both udev and eudev have pretty much feature parity, so there won't > be any user-visible changes > > * udev upstream strongly discourages standalone udev (without systemd) > since at least 2012 > > (see for example: > https://lists.freedesktop.org/archives/systemd-devel/2012-June/005516.html > https://lkml.org/lkml/2012/10/3/618 > ) > > So it'd be (1) following upstreams recommendations and (2) dogfooding > our own tools. I don't see any downsides to this :) > +1 I switched to eudev a few years ago and glad I did. The non-systemd profiles should have eudev as default. -- Brian Dolbec
Re: [gentoo-dev] [PATCH v3 05/21] ebuild-writing/misc-files: replace the code for cvs commit with git #558642
On Wed, 3 Feb 2016 19:57:33 -0500 gokt...@binghamton.edu wrote: > From: Gokturk Yuksek > > Replace "cvs commit" with the equivalent "git add && git commit" > version. > > Gentoo-Bug: https://bugs.gentoo.org/show_bug.cgi?id=558642 > Signed-off-by: Gokturk Yuksek > --- > ebuild-writing/misc-files/metadata/text.xml | 16 +++- > 1 file changed, 15 insertions(+), 1 deletion(-) > > diff --git a/ebuild-writing/misc-files/metadata/text.xml > b/ebuild-writing/misc-files/metadata/text.xml index e506b1c..2de3cf5 > 100644 --- a/ebuild-writing/misc-files/metadata/text.xml > +++ b/ebuild-writing/misc-files/metadata/text.xml > @@ -532,7 +532,21 @@ is currently: > > xmllint --noout --valid metadata.xml > glep31check metadata.xml > -cvs commit -m "Adding category metadata.xml for my-category" > metadata.xml +git add metadata.xml > +git commit --gpg-sign > This should be repoman commit still, not git commit + > + > + > +The commit message should be formatted properly. > +A sample commit is shown below: > + > + > + > +commit db359439bcd52f5a7f20d2332ab62feb16657504 > +Author: Alexis Ballier <aball...@gentoo.org> > +Date: Tue Sep 22 10:47:49 2015 +0200 > + > + dev-ros: Add metadata.xml for the category. > > > -- Brian Dolbec
Re: [gentoo-dev] New schema language for metadata validation?
On Wed, 27 Jan 2016 14:39:02 +0100 Dirkjan Ochtman wrote: > On Wed, Jan 27, 2016 at 1:09 PM, Michał Górny > wrote: > > Could you post a generated .rng and XML Schema files for comparison? > > They don't have to be perfect conversions, just to see how different > > they are. > > Here's the RNG, generated with dev-python/rnc2rng: > > https://raw.githubusercontent.com/djc/gentoo-data-dtd/metadata-rnc/metadata.rng > > The best way to convert from RELAX NG to XML Schema seems to be with > trang; I downloaded an older binary and a JDK on my laptop, but > couldn't easily get it to run. I don't really have a Gentoo machine on > which I want to install the whole Java shebang, so maybe someone else > can run a quick conversion? > > Cheers, > > Dirkjan > that looks very easy to read and modify. -- Brian Dolbec
Re: [gentoo-dev] Re: Add sync-git-extra-opts or sync-git-pull-extra-opts to repos.conf
On Sun, 24 Jan 2016 16:46:41 +0800 konsolebox wrote: > On Sat, Jan 23, 2016 at 4:27 AM, Brian Dolbec > wrote: > > On Sat, 23 Jan 2016 03:45:14 +0800 > > konsolebox wrote: > > > >> On Sat, Jan 23, 2016 at 2:05 AM, Brian Dolbec > >> wrote: > >> > On Sat, 23 Jan 2016 01:05:12 +0800 > >> > konsolebox wrote: > >> > > >> >> On Fri, Jan 22, 2016 at 11:30 PM, Duncan <1i5t5.dun...@cox.net> > >> >> wrote: > >> >> > konsolebox posted on Fri, 22 Jan 2016 22:10:53 +0800 as > >> >> > excerpted: > >> >> >> Hi, I can't find a way to make `emerge --sync` add an option > >> >> >> like `-f` to `git pull` when it runs it. How about adding > >> >> >> sync-git-extra-opts or sync-git-pull-extra-opts to > >> >> >> repos.conf? We already have sync-rsync-extra-opts for rsync > >> >> >> so I think it's fair to add one for git. > >> >> > > >> >> > If you have layman installed, you can set repo sync-type to > >> >> > laymansync, and layman, in turn, has configuration options > >> >> > that allow you to set additional options for git as well as > >> >> > the other repo-type fetch commands (bzr, svn, etc). > >> >> > > >> >> > >> >> Unfortunately I need it for the `gentoo` repo itself. I do have > >> >> layman repos but I update them separately with `layman -S`, and > >> >> I don't want them to always get updated together with `gentoo` > >> >> everytime I run `emerge --sync`. > >> >> > >> > > >> > No, the portage sync system controls which repo(s) get synced via > >> > the auto-sync setting. So layman can git sync the gentoo repo > >> > like Duncan described without also syncing your manually synced > >> > layman repos. > >> > >> Ok I think I follow a bit, but wouldn't it be better to have that > >> feature without relying on layman? > >> > > > > Yes, it would be better. But there are only do many hours we each > > can spend on Gentoo. I have the repoman rewrite as my primary > > portage work in progress at the moment. And this feature is not > > something I am in need of... > > > > For those who may wish to add this and/or other features to the > > sync, The repos.conf repo definitions are now capable of extra > > options per sync type (They don't have to be common to all sync > > modules). So it is possible to add this to the git sync module and > > have specific repo settings. We are around and eager to help > > anyone wishing to contribute patches :) > > I made a pull request for it in github. Please check. Thanks. > > https://github.com/gentoo/portage/pull/23 > Thank you, the patch looks good. I'll post the patch to our development list for review before merge. It'll likely be included in the next release soon. -- Brian Dolbec
Re: [gentoo-dev] [PATCH v2 08/19] ebuild-maintenance: rewrite the text on adding binary files to the tree #558642
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sun, 24 Jan 2016 18:44:08 -0500 Göktürk Yüksek wrote: > Andrew Savchenko: > > On Sun, 24 Jan 2016 16:00:31 +0100 Patrice Clement wrote: > >> Sunday 24 Jan 2016 03:46:02, Gokturk Yuksek wrote : > >>> Remove the paragraph about adding binary files to CVS. Replace > >>> the instances of CVS with git. > >>> > >>> X-Gentoo-Bug-URL: > >>> https://bugs.gentoo.org/show_bug.cgi?id=558642 Signed-off-by: > >>> Gokturk Yuksek --- > >>> ebuild-maintenance/text.xml | 19 +++ 1 file > >>> changed, 3 insertions(+), 16 deletions(-) > >>> > >>> diff --git a/ebuild-maintenance/text.xml > >>> b/ebuild-maintenance/text.xml index ac68dcd..10709ea 100644 > >>> --- a/ebuild-maintenance/text.xml +++ > >>> b/ebuild-maintenance/text.xml @@ -42,22 +42,9 @@ above 20KB) > >>> which should be distributed as tarballs via the >>> link="::general-concepts/mirrors/#suitable-download-hosts">Gentoo > >>> > >>> > mirror system so that people do not waste excessive > >>> amounts of bandwidth and hard drive space. Also, you should > >>> not add binary (non-ASCII) files to the -Portage CVS tree. If > >>> you need to do this in another CVS tree, for -example, if you > >>> need to add a small PNG graphic for whatever reason, -be sure > >>> to add it to CVS by using the -kb option, like so: - > >>> - - -# cvs add > >>> -kb myphoto.png - - - -The -kb option tells > >>> CVS that myphoto.png is a binary -file and should > >>> be treated specially. For example, merging the -differences > >>> between two different versions of this file should not be > >>> -allowed to happen, for obvious reasons. Also, speaking of > >>> merging +git tree. Also, speaking of merging changes, any > >>> patches you add to Portage should generally not be > >>> -compressed. This will allow CVS to merge changes and > >>> correctly inform +compressed. This will allow git to merge > >>> changes and correctly inform developers of conflicts. > >>> > >>> @@ -149,7 +136,7 @@ simply, 1.0-gentoo.diff. > >>> Also note that the gentoo extension informs people > >>> that this patch was created by us, the Gentoo Linux > >>> developers, rather than having been grabbed from a mailing list > >>> or somewhere else. Again, you should not compress these > >>> -patches because CVS does not play well with binary files. > >>> +patches because git does not play well with binary files. > >>> > >>> > >>> -- 2.4.10 > >>> > >>> > >> > >> "Again you should not compress these patches because git does > >> not play well binary files". > >> > >> I'm not sure this statement still holds true with git. Does it? > > > > What about repoman checks? Will it still yell at >20 kB patches? > > > Yessir: > https://gitweb.gentoo.org/proj/portage.git/tree/pym/repoman/checks/ebuilds/fetches.py?h=v2.2.27#n104 > > Even though it's not an issue with the git tree, rsync users will > still suffer for >20kB patches. > > > Best regards, Andrew Savchenko > > > > - -- > gokturk > > just for future reference, here it is again in the repoman rewtire code waiting to be merged and likely be in the next release: https://gitweb.gentoo.org/proj/portage.git/tree/pym/repoman/modules/scan/fetch/fetches.py?h=repoman#n109 - -- Brian Dolbec -BEGIN PGP SIGNATURE- Version: GnuPG v2.1 iQJ8BAEBCgBmBQJWpXF6XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNUQ3Qzc0RTA4MUNDNzBEQjRBNEFBRjVG QkJEMDg3Mjc1ODIwRUQ4AAoJEPu9CHJ1gg7YV6IP/34NmzdtaMg4W471cXYn8pR0 8JdcHkC2YehpNNzSjDbWmI9pEArBS/3yWC8lfXMeu21GU66OUb6eKR5KMURg5OP9 FT4DJCHO9RWK31QEOD03PLZXhoaw6JgYQpvjbnWP1CN8mdWg7CeA0r0y4BPe63Kp FGpFZXjduszpT1ALIt86tN85pB9jmYdwDgj9vLWG6SyThFuA6aDeEHSaAB05blDU p6NVksGfSG6bbS+Kok1uRdF5vVqBQU+aSxNbZW9mpRtYDtdr5DoInbq/uXz/Dy1S Kp7iDg8+SW3nwA60vqss5SZmZDW3cnEH1XWIdEgDjH4NBvlaVnA9yxIa12MJ6qSy FZ+5F5HVAdRs8eLK0OsK/RbFm4gCEFxmhm6YJ2qXpIXuD/MM4GJXJa+O7qrURzqI td5rJNTHGbIBmwDjJwotwyuT+FgWajicbrnQpxgiLoNYcvvB7mihwT+DFKx4WxWm rw2O21fFaUD/OQp255y0OLyVfVC6SRk3UXXlDd9Pl+UYLLIyC6ibVI4dxDxp4hd2 DGUTQ2FFm3m4h5RTxeCJNJgTMlKSbCyDut6vM8mMyIzMxcD5nfWFv53KNIbOPfGH vmUbc5scrhKLiawzos2w+ChzGkzGParzCF7rZ1S2nOlJFt87qgVVs7JNVUJ0D1QX XlmqJV+fmRhaDLRXNVQA =gmwE -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Add sync-git-extra-opts or sync-git-pull-extra-opts to repos.conf
On Sat, 23 Jan 2016 03:45:14 +0800 konsolebox wrote: > On Sat, Jan 23, 2016 at 2:05 AM, Brian Dolbec > wrote: > > On Sat, 23 Jan 2016 01:05:12 +0800 > > konsolebox wrote: > > > >> On Fri, Jan 22, 2016 at 11:30 PM, Duncan <1i5t5.dun...@cox.net> > >> wrote: > >> > konsolebox posted on Fri, 22 Jan 2016 22:10:53 +0800 as > >> > excerpted: > >> >> Hi, I can't find a way to make `emerge --sync` add an option > >> >> like `-f` to `git pull` when it runs it. How about adding > >> >> sync-git-extra-opts or sync-git-pull-extra-opts to repos.conf? > >> >> We already have sync-rsync-extra-opts for rsync so I think it's > >> >> fair to add one for git. > >> > > >> > If you have layman installed, you can set repo sync-type to > >> > laymansync, and layman, in turn, has configuration options that > >> > allow you to set additional options for git as well as the other > >> > repo-type fetch commands (bzr, svn, etc). > >> > > >> > >> Unfortunately I need it for the `gentoo` repo itself. I do have > >> layman repos but I update them separately with `layman -S`, and I > >> don't want them to always get updated together with `gentoo` > >> everytime I run `emerge --sync`. > >> > > > > No, the portage sync system controls which repo(s) get synced via > > the auto-sync setting. So layman can git sync the gentoo repo like > > Duncan described without also syncing your manually synced layman > > repos. > > Ok I think I follow a bit, but wouldn't it be better to have that > feature without relying on layman? > Yes, it would be better. But there are only do many hours we each can spend on Gentoo. I have the repoman rewrite as my primary portage work in progress at the moment. And this feature is not something I am in need of... For those who may wish to add this and/or other features to the sync, The repos.conf repo definitions are now capable of extra options per sync type (They don't have to be common to all sync modules). So it is possible to add this to the git sync module and have specific repo settings. We are around and eager to help anyone wishing to contribute patches :) -- Brian Dolbec
Re: [gentoo-dev] Re: Add sync-git-extra-opts or sync-git-pull-extra-opts to repos.conf
On Sat, 23 Jan 2016 01:05:12 +0800 konsolebox wrote: > On Fri, Jan 22, 2016 at 11:30 PM, Duncan <1i5t5.dun...@cox.net> wrote: > > konsolebox posted on Fri, 22 Jan 2016 22:10:53 +0800 as excerpted: > > > >> Hi, I can't find a way to make `emerge --sync` add an option like > >> `-f` to `git pull` when it runs it. How about adding > >> sync-git-extra-opts or sync-git-pull-extra-opts to repos.conf? We > >> already have sync-rsync-extra-opts for rsync so I think it's fair > >> to add one for git. > > > > If you have layman installed, you can set repo sync-type to > > laymansync, and layman, in turn, has configuration options that > > allow you to set additional options for git as well as the other > > repo-type fetch commands (bzr, svn, etc). > > > > Unfortunately I need it for the `gentoo` repo itself. I do have > layman repos but I update them separately with `layman -S`, and I > don't want them to always get updated together with `gentoo` everytime > I run `emerge --sync`. > No, the portage sync system controls which repo(s) get synced via the auto-sync setting. So layman can git sync the gentoo repo like Duncan described without also syncing your manually synced layman repos. -- Brian Dolbec
