[gentoo-dev] Last rites: app-admin/dxf, dev-python/fastparquet, dev-python/numba, dev-python/raven, dev-python/sphinxcontrib-documentedlist, dev-python/thriftpy, dev-python/toro
# Michał Górny (2020-05-31) # The following packages are either unmaintained, or their deps # are unmaintained. They are stuck on Python 3.6 and have no reverse # dependencies outside the list. # # app-admin/dxf: #718178 # dev-python/fastparquet: #718820 # dev-python/numba: #719286 # dev-python/raven: #719522 # dev-python/sphinxcontrib-documentedlist: #719564 # dev-python/thriftpy: #719590 # dev-python/toro: #719592 # # Removal in 30 days. app-admin/dxf dev-python/fastparquet dev-python/numba dev-python/raven dev-python/sphinxcontrib-documentedlist dev-python/thriftpy dev-python/toro -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Packages up for grabs
Hi, I'm stopping proxy maintenance of net-misc/youtube-viewer, as I stopped using it due to YouTube's new requirement of having a private developer's key for it to function. Shared developer key is not a possibility (i.e. setting up a Gentoo key for such packages) as YouTube rate limits the number of requests per developer product key, and also considers them ToS violation, which potentially leads to disabling them pretty fast. See more details on: https://github.com/trizen/youtube-viewer/issues/308 I'm putting up a PR and dropping it to maintainer needed. If no one wants to pick up the package maybe we should also consider last riting it after some months, since YouTube API moves fast and old versions tend to not function after some time. Cheers, Zoltan
[gentoo-dev] Last rites: media-libs/aldumb
# James Le Cuirot (2020-05-31) # Now merged into media-libs/dumb with the allegro USE flag. This # package was added before EAPI 2 and USE-dependencies. media-libs/aldumb pgp_vyqIs4GOF.pgp Description: OpenPGP digital signature
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] Value of Continuous integration vs Code Review / Pull Requests
On Fri, May 29, 2020 at 04:34:24PM -0700, Alec Warner wrote: > Another major issue is operating the software. I haven't found anyone to > *run* gitlab; I'm not eager to do it. Today Gentoo is mostly distributed, > bugs are in bugzilla, wiki is on mediawiki, code is on gitolite with N > mirrors, email and lists are separate, etc. In a world where bugs, wiki, > code, ci, containers, PRs, are all on gitlab and it breaks and we can't fix > it; it will be bad news for all of those things. If the bugzilla machine > breaks we lose bugzilla; if gitlab breaks we lose the ability to edit the > wiki, file bugs, commit, run CI, etc. Ping me sometime this week if I don't catch up with you first. I have some experience running gitlab, so I could help run it. Thanks, William signature.asc Description: PGP signature
[gentoo-dev] rfc: adding GOPATH to ENV_UNSET in base profile
All, The GOPATH variable has similar issues to GOBIN [1], so I would like to add it along side GOBIN to ENV_UNSET in the base profile. The message link below is only there for reference, but I see ebuilds unsetting GOPATH in the tree and this would take care of it across all of the tree. Thoughts? Thanks, William [1] https://archives.gentoo.org/gentoo-dev/message/163010f83ae7819d80c0cfdf797cbfe0 signature.asc Description: PGP signature
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2020-05-31 23:59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2020-05-31 23:59 UTC. Removals: app-laptop/batti 20200529-19:44 asturm f3470366927 app-misc/metromap20200529-19:45 asturm 54516f3baf0 app-mobilephone/ganyremote 20200531-00:03 asturm 4ba95898c09 app-office/pybliographer 20200531-00:02 asturm 6620383efa6 app-text/djvusmooth 20200531-10:11 mgorny 6dd499c09b4 dev-embedded/pk2-la 20200529-19:45 asturm f1f36259768 dev-go/go-crypto 20200531-10:24 mgorny 5b426ca4581 dev-go/go-net20200531-10:24 mgorny 9761dd993c7 dev-go/go-sys20200531-10:24 mgorny 16cb1381d8d dev-python/asynctest 20200531-10:26 mgorny e8edc616daf dev-python/dap 20200531-10:05 mgorny 1f8b027877c dev-python/flower20200531-10:26 mgorny 4e78f60eec4 dev-python/nose-descriptionfixer 20200531-10:09 mgorny 3c7caae43b6 dev-python/paramunittest 20200531-10:04 mgorny 5b948583b87 dev-python/parsley 20200531-10:05 mgorny 6a9a2798912 dev-python/pastescript 20200531-10:05 mgorny 991a4faf9c4 dev-python/patch 20200531-10:05 mgorny 80328fd5204 dev-python/pgpdump 20200531-10:06 mgorny fbc2bcab724 dev-python/pillowfight 20200531-10:06 mgorny 44bee57dbda dev-python/placefinder 20200531-10:09 mgorny 13fd291be70 dev-python/pyalsaaudio 20200531-10:09 mgorny 9b9eb2ecd72 dev-python/pyjade20200531-10:10 mgorny c84367122f4 dev-python/pyodbc20200531-10:11 mgorny c84aaacd065 dev-python/pyswisseph20200531-10:11 mgorny 6a8c83d1c5d dev-python/python-bibtex 20200531-00:02 asturm 6620383efa6 dev-python/python-djvulibre 20200531-10:11 mgorny e2c21bf91d4 dev-python/pythonmagick 20200531-10:11 mgorny b1095b04dfe dev-python/riak-python-client20200531-10:26 mgorny 70c95656a99 dev-python/scoop 20200531-10:14 mgorny a790f5c6ae1 dev-python/sdnotify 20200531-10:15 mgorny 9e771a69b86 dev-python/sphinxcontrib-googleanalytics 20200531-10:15 mgorny 261a043965e dev-python/utmp 20200531-10:15 mgorny 0b364503c16 dev-python/versiontools 20200531-10:15 mgorny b07bd54b4c5 dev-python/xstatic 20200531-10:21 mgorny dc98212d00b dev-python/xstatic-bootstrap-scss20200531-10:21 mgorny 3c9f9658bb7 dev-python/xstatic-datatables20200531-10:21 mgorny e30c84708a7 dev-python/xstatic-jquery20200531-10:21 mgorny 5eef33c8459 dev-python/xstatic-patternfly20200531-10:21 mgorny 04e4e25446c dev-python/xstatic-patternfly-bootstrap-treeview 20200531-10:21 mgorny a66b7ea7d39 games-action/rune20200531-10:02 mgorny a0881c57e89 net-firewall/ufw-frontends 20200529-19:48 asturm 3397c6c8e97 net-irc/quassel-irssi20200531-10:26 mgorny 9c4251f66f7 net-libs/quasselc20200531-10:27 mgorny c62bb6b2589 sys-auth/AusweisApp2 20200525-14:00 conikost f3d76e96e57 sys-cluster/openais 20200531-10:27 mgorny ab48cfb785a sys-fs/pysize20200529-19:43 asturm 5f8e0933bbb www-client/seamonkey-bin 20200531-10:25 mgorny 27c0d7e372a x11-misc/icewmcp 20200529-19:46 asturm a1344cc8721 x11-misc/obmenu 20200531-10:04 mgorny 488c0778b6a x11-misc/obtheme 20200531-10:03 mgorny 0ad950fbeb2 x11-misc/wbarconf20200529-19:47 asturm 7714018b8c4 x11-misc/wmakerconf 20200531-10:27 mgorny c0c8660b28a x11-plugins/fsviewer 20200531-10:27 mgorny f20ea9b282c Additions: acct-group/clair 20200530-20:01 williamh bc69dd0963b acct-user/clair 20200530-20:07 williamh b34524f app-metrics/fusioninventory-agent20200526-22
Re: [gentoo-dev] Value of Continuous integration vs Code Review / Pull Requests
On Fri, May 29, 2020 at 11:17 PM Michał Górny wrote: > On Fri, 2020-05-29 at 16:34 -0700, Alec Warner wrote: > > The pull-based mirroring is a bit sad, as it would be nice to auto-update > > some forks, but it's not a killer feature. > > Exactly. Especially that our push-based mirroring is better, > and I think that's how we want to populate it. > So you want to keep gitolite then? > > > I think our new SSO solution > > could potentially be a fix for the auth subsystems, but more work there > > will be needed. > > I think SSO should be the primary login to our GitLab, especially for > our users. GitHub login is a must. > I'm fairly sure both gitlab and gitea support this requirement. > > > Another major issue is operating the software. I haven't found anyone to > > *run* gitlab; I'm not eager to do it. Today Gentoo is mostly distributed, > > bugs are in bugzilla, wiki is on mediawiki, code is on gitolite with N > > mirrors, email and lists are separate, etc. In a world where bugs, wiki, > > code, ci, containers, PRs, are all on gitlab and it breaks and we can't > fix > > it; it will be bad news for all of those things. If the bugzilla machine > > breaks we lose bugzilla; if gitlab breaks we lose the ability to edit the > > wiki, file bugs, commit, run CI, etc. > > > > But who says we want to migrate them all into GitLab? I thought our > primary goal was to replace today's GitHub use, i.e. provide > an alternative pipeline for pull/merge requests. > Oh I don't, but we then need to disable all of them and restrict their usage. -A > > -- > Best regards, > Michał Górny > >
Re: [gentoo-dev] Value of Continuous integration vs Code Review / Pull Requests
On Sun, 2020-05-31 at 18:42 -0700, Alec Warner wrote: > On Fri, May 29, 2020 at 11:17 PM Michał Górny wrote: > > > On Fri, 2020-05-29 at 16:34 -0700, Alec Warner wrote: > > > The pull-based mirroring is a bit sad, as it would be nice to auto-update > > > some forks, but it's not a killer feature. > > > > Exactly. Especially that our push-based mirroring is better, > > and I think that's how we want to populate it. > > > > So you want to keep gitolite then? Yes. I don't think GitLab replaces all the features we use from it (does it?). Plus, it's been quite reliable so far and I don't think converting the configs is worth the effort. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
