[gentoo-dev] Last rites: dev-python/pygtkglext
# Andreas Sturmlechner (2020-02-02) # Ancient, dead, py27-only, all revdeps masked for removal, bugs 651346, 696974 # Masked for removal in 30 days. dev-python/pygtkglext signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] GSoC 2020: Call for mentors and project ideas
Dear Fellows, alicef writes: > As always, Gentoo plans to participate in the Google Summer of Code > 2020. We are looking for new project ideas and are always open for > new mentors. > Google Summer of Code is a big opportunity for making Gentoo project more > visible and get more people interested to join Gentoo and helping out. > > [...] This year's GSoC organization application deadline is on Feb 5. The more project ideas, the better Gentoo will show itself to be prepared. If you have been thinking of adding projects to our GSoC 2020 list, this is a good chance to do so. Cheers, Benda signature.asc Description: PGP signature
Re: [gentoo-dev] GSoC 2020: Call for mentors and project ideas
Am Sonntag, 2. Februar 2020, 12:47:55 CET schrieb Benda Xu: > Dear Fellows, > > alicef writes: > > > As always, Gentoo plans to participate in the Google Summer of Code > > 2020. We are looking for new project ideas and are always open for > > new mentors. > > Google Summer of Code is a big opportunity for making Gentoo project more > > visible and get more people interested to join Gentoo and helping out. > > > > [...] > > This year's GSoC organization application deadline is on Feb 5. The > more project ideas, the better Gentoo will show itself to be prepared. > If you have been thinking of adding projects to our GSoC 2020 list, this > is a good chance to do so. > > Cheers, > Benda > Hi, I saw the idea „Big Data Infrastructure by Gentoo“ and found it kind of interesting. However, I have a little bit the fear that a full automation won't be possible and the whole project becomes a little bit like g-sorcery (gs-pypi, gs-elpa) or g-octave: a really cool project but not used at a large scale. What do you think of the idea to not do this fully automated but supervised by a maintainer? With that I mean an ebuild generator that generates only the parts of the ebuild that it can easily parse and then present the ebuild draft to a maintainer who completes it to an full ebuild. As far a I know no tool like this exists. I think the focus shift helps a lot: Developing a tool for the Gentoo maintainer not the Gentoo user. I'm only "maintaining" an overlay so maybe I'm missing experience but I often have wished a tool that automatically parses the language specific packaging files and is able to generate a primitive ebuild out of that. Maybe it even can do this in an interactive way: "Hey, upstream needs the dependency 'foo'. In the Gentoo packages I have found 'dev-bar/foo' and 'dev-util/foo'. What is the correct one?" With a not fully automatic tool also packages can be parsed that are not in a complete closed ecosystem, like a 'meson.build' file or cmake files for C++/C programs. But of course package databases like Maven/Cargo/Pypi are also candidates. Unfortunately, I have no time currently to participate in the GSOC. I just want to mention this here as an idea. Please comment or correct me, if such a tool already exists. Best, Gerion signature.asc Description: This is a digitally signed message part.
[gentoo-dev] binutils-2.34 breakage
Yesterday binutils-2.34 / binutils-libs-2.34 landed into gentoo. binutils-2.34 should generally be fine. binutils-libs-2.34 caused a bit of breakage like "undefined reference to bfd_get_section_flags" These are trivial to fix either via conditional patching (API usage is usually tiny) or via a bit of #ifdef-ery. Tracker bug: https://bugs.gentoo.org/707898 Tips to fix your packages: https://wiki.gentoo.org/wiki/Project:Toolchain#binutils-2.34 -- Sergei
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2020-02-02 23:59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2020-02-02 23:59 UTC. Removals: media-plugins/vdr-skinenigmang 20200202-19:29 hd_brummy b4faedf6d4a x11-themes/skinenigmang-logos 20200202-19:29 hd_brummy b4faedf6d4a Additions: acct-group/davfs2 20200128-01:48 gokturk 4e4609d8ce5 acct-group/gerbera 20200129-20:58 thev00d00 d4139ee67e3 acct-group/netbox 20200127-00:37 williamh 07aee2a96b9 acct-group/prometheus 20200127-21:46 williamh 9cafefcd37d acct-group/squid 20200127-18:50 zlogene 665bc29c144 acct-user/davfs2 20200128-02:20 gokturk 7e46cff4393 acct-user/gerbera 20200129-20:58 thev00d00 3e3e3229d34 acct-user/netbox 20200127-00:38 williamh 5a875bc4707 acct-user/prometheus 20200127-21:47 williamh 41baf3efb78 acct-user/squid20200127-18:50 zlogene b8660c1a83f app-metrics/prometheus-bin 20200127-22:34 williamh 7642d025441 dev-libs/avro-c20200131-18:03 williamh a79e35ebcb4 dev-libs/kuserfeedback 20200128-15:35 asturmeb53b0fadcc dev-libs/libserdes 20200131-21:46 williamh b3a8d3c8b3d dev-python/matplotlib-python2 20200128-19:05 mgorny5ce6e9f145b dev-python/pytest-lazy-fixture 20200127-20:46 juippis daded882bc3 media-libs/pulseaudio-qt 20200129-19:06 asturm6cf252f6fa5 sci-libs/scipy-python2 20200128-20:46 mgorny0f29cb1a064 sci-mathematics/cliquer20200130-21:19 mjo daa32852c89 sci-mathematics/planarity 20200129-22:49 mjo 153d3a3b7e4 -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: media-plugins/vdr-skinenigmang,removed,hd_brummy,20200202-19:29,b4faedf6d4a x11-themes/skinenigmang-logos,removed,hd_brummy,20200202-19:29,b4faedf6d4a Added Packages: dev-libs/libserdes,added,williamh,20200131-21:46,b3a8d3c8b3d dev-libs/avro-c,added,williamh,20200131-18:03,a79e35ebcb4 sci-mathematics/cliquer,added,mjo,20200130-21:19,daa32852c89 sci-mathematics/planarity,added,mjo,20200129-22:49,153d3a3b7e4 acct-user/gerbera,added,thev00d00,20200129-20:58,3e3e3229d34 acct-group/gerbera,added,thev00d00,20200129-20:58,d4139ee67e3 media-libs/pulseaudio-qt,added,asturm,20200129-19:06,6cf252f6fa5 sci-libs/scipy-python2,added,mgorny,20200128-20:46,0f29cb1a064 dev-python/matplotlib-python2,added,mgorny,20200128-19:05,5ce6e9f145b dev-libs/kuserfeedback,added,asturm,20200128-15:35,eb53b0fadcc dev-python/pytest-lazy-fixture,added,juippis,20200127-20:46,daded882bc3 acct-user/davfs2,added,gokturk,20200128-02:20,7e46cff4393 acct-group/davfs2,added,gokturk,20200128-01:48,4e4609d8ce5 app-metrics/prometheus-bin,added,williamh,20200127-22:34,7642d025441 acct-user/prometheus,added,williamh,20200127-21:47,41baf3efb78 acct-group/prometheus,added,williamh,20200127-21:46,9cafefcd37d acct-user/squid,added,zlogene,20200127-18:50,b8660c1a83f acct-group/squid,added,zlogene,20200127-18:50,665bc29c144 acct-user/netbox,added,williamh,20200127-00:38,5a875bc4707 acct-group/netbox,added,williamh,20200127-00:37,07aee2a96b9 Done.
[gentoo-dev] Ebuild Generators (Was: GSoC 2020: Call for mentors and project ideas)
Hi Gerion, Gerion Entrup writes: > I saw the idea „Big Data Infrastructure by Gentoo“ and found it kind of > interesting. However, I have a little bit the fear that a full automation > won't be possible and the whole project becomes a little bit like g-sorcery > (gs-pypi, gs-elpa) or g-octave: a really cool project but not used at a > large scale. Yes, that's true. I share the same observation and concern with you. This is one exception: the CRAN ebuild generator powered R overlay has been running well for 8 years. https://wiki.gentoo.org/wiki/Project:Science/Overlay/R > What do you think of the idea to not do this fully automated but supervised > by a maintainer? With that I mean an ebuild generator that generates only > the parts of the ebuild that it can easily parse and then present the ebuild > draft to a maintainer who completes it to an full ebuild. As far a I know no > tool like this exists. I think the focus shift helps a lot: > Developing a tool for the Gentoo maintainer not the Gentoo user. Yes, that makes a lot of sense. The R overlay follows this model. Most of the ebuilds are automated. When an ebuild generation fails, we add the ebuild manually, understand it and then update the generator to cover it in the future. > I'm only "maintaining" an overlay so maybe I'm missing experience > but I often have wished a tool that automatically parses the language specific > packaging files and is able to generate a primitive ebuild out of that. > Maybe it even can do this in an interactive way: > "Hey, upstream needs the dependency 'foo'. In the Gentoo packages I have found > 'dev-bar/foo' and 'dev-util/foo'. What is the correct one?" Yes, that's the way R overlay is working. And I have a similar plan and proof-of-concept solution for the Java Maven overlay. > With a not fully automatic tool also packages can be parsed that are not > in a complete closed ecosystem, like a 'meson.build' file or cmake files for > C++/C programs. But of course package databases like Maven/Cargo/Pypi are > also candidates. > > Unfortunately, I have no time currently to participate in the GSOC. I just > want to mention this here as an idea. Please comment or correct me, if > such a tool already exists. Thank you! Your input is really valuable. Yours, Benda signature.asc Description: PGP signature
