[gentoo-dev] Last rites: app-cdr/backlite
# Daniel Pielmeier (7 May 2017) # Fails to build with ffmpeg-3. Dead upstream. # Masked for removal in 30 days. Bug #575824. app-cdr/backlite 0xC5E80123.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
[gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp
TL;DR ia64/ppc/sparc teams are pretty much dead. They have been for a long time and this won't change any time soon. Gentoo should focus its resources on archs that are important and has the manpower to support. Let us please drop these 3 archs to dev profiles to ease maintenance. Dear all, I'd like to request Council to consider my motion to drop the ia64/ppc/sparc profiles to dev (or exp). These arches are pretty much dead, minus the automated workflows of ago. Two months ago I have written to these 3 archs, and only received one reply from ppc agreeing with my sentiment, with no response from ia64 or sparc, which in itself is pretty telling. Currently, architecture projects think adding their keywords is a right, which I strongly disagree with. I believe being able to add (and stable) your keywords is a privilege - namely it carries with it the duty to react to keywording and stabilization requests in a timely manner. Let's compare the state of ia64/ppc/sparc to, say alpha: https://bugs.gentoo.org/show_bug.cgi?id=605278 alpha was keyworded within 6 hours. To date ia64/ppc/sparc are still not keyworded (the bot had some breakages due to jer again shifting around all the bugs). Within 4 months these arches have not managed to keyword those 4 packages. This is I believe the most striking example of how the only work done for these archs are ago's automated stablereq scripts. Why do I saw that keywording+stabling your arch is a privilege? Maintenance of packages is hampered by archs not stabling, because we cannot clean up broken packages. Adding keywords is a two- way street - if you don't act speedily, you're breaking part of the maintainer-arch social contract. Please don't turn this into a massive bikeshedding contest and just admit that it is extremely unlikely that these archs will see more activity in the near future. We should focus our resources on more important archs (arm64 maybe?) instead of these. I know you have that old Mac G4 or UltraSPARC sitting in your closet that you're 2 days away from installing Gentoo on, but the pain for maintainers and the rest of the community is just too great. If someone steps up to do the work, we can then move archs back to a stable profile, but so long as they linger in their present state, let's call a spade a spade. Anyhow, I formally request the Council to vote on dropping these archs to unstable/exp profiles for the next Council meeting, explicitly overriding any arch concerns that are likely to awake now and going to be running around like headless chicken. David
[gentoo-dev] Package up for grabs: net-vpn/libreswan
I used to use this package for an IPSec/L2TP VPN to my office, but we migrated onto Cisco AnyConnect. I now use net-vpn/openconnect regularly and have not been able to test libreswan since the switch. libreswan has no open bugs, but there is a pending version bump (3.20).
[gentoo-dev] Re: Package up for grabs: net-vpn/libreswan
On Sun, May 7, 2017 at 3:28 PM, Mike Gilbert wrote: > I used to use this package for an IPSec/L2TP VPN to my office, but we > migrated onto Cisco AnyConnect. I now use net-vpn/openconnect > regularly and have not been able to test libreswan since the switch. I also dropped net-dialup/xl2tpd if anyone wants it.
Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp
On Sun, May 7, 2017 at 9:23 PM, David Seifert wrote: > TL;DR > ia64/ppc/sparc teams are pretty much dead. They have been for a long > time and this won't change any time soon. Gentoo should focus its > resources on archs that are important and has the manpower to support. > Let us please drop these 3 archs to dev profiles to ease maintenance. +1 good idea. The slowest arches slow things down for everyone else. Cheers, Dirkjan
Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp
On nie, 2017-05-07 at 21:23 +0200, David Seifert wrote: > TL;DR > ia64/ppc/sparc teams are pretty much dead. They have been for a long > time and this won't change any time soon. Gentoo should focus its > resources on archs that are important and has the manpower to support. > Let us please drop these 3 archs to dev profiles to ease maintenance. > > Dear all, > I'd like to request Council to consider my motion to drop the > ia64/ppc/sparc profiles to dev (or exp). These arches are pretty much > dead, minus the automated workflows of ago. Two months ago I have > written to these 3 archs, and only received one reply from ppc agreeing > with my sentiment, with no response from ia64 or sparc, which in itself > is pretty telling. > > Currently, architecture projects think adding their keywords is a > right, which I strongly disagree with. I believe being able to add (and > stable) your keywords is a privilege - namely it carries with it the > duty to react to keywording and stabilization requests in a timely > manner. Let's compare the state of ia64/ppc/sparc to, say alpha: > > https://bugs.gentoo.org/show_bug.cgi?id=605278 > > alpha was keyworded within 6 hours. To date ia64/ppc/sparc are still > not keyworded (the bot had some breakages due to jer again shifting > around all the bugs). Within 4 months these arches have not managed to > keyword those 4 packages. This is I believe the most striking example > of how the only work done for these archs are ago's automated stablereq > scripts. Why do I saw that keywording+stabling your arch is a > privilege? Maintenance of packages is hampered by archs not stabling, > because we cannot clean up broken packages. Adding keywords is a two- > way street - if you don't act speedily, you're breaking part of the > maintainer-arch social contract. > > Please don't turn this into a massive bikeshedding contest and just > admit that it is extremely unlikely that these archs will see more > activity in the near future. We should focus our resources on more > important archs (arm64 maybe?) instead of these. I know you have that > old Mac G4 or UltraSPARC sitting in your closet that you're 2 days away > from installing Gentoo on, but the pain for maintainers and the rest of > the community is just too great. If someone steps up to do the work, we > can then move archs back to a stable profile, but so long as they > linger in their present state, let's call a spade a spade. > > Anyhow, I formally request the Council to vote on dropping these archs > to unstable/exp profiles for the next Council meeting, explicitly > overriding any arch concerns that are likely to awake now and going to > be running around like headless chicken. > I'm against. Turning more arches into dev/exp only introduces hidden depgraph breakages. I think it'd be better if we looked into the arch.desc proposal and just disabled stable keywords for those architectures. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp
Am Sonntag, 7. Mai 2017, 22:24:35 CEST schrieb Michał Górny: > > > Anyhow, I formally request the Council to vote on dropping these archs > > to unstable/exp profiles for the next Council meeting, explicitly > > overriding any arch concerns that are likely to awake now and going to > > be running around like headless chicken. > > I'm against. Turning more arches into dev/exp only introduces hidden > depgraph breakages. I think it'd be better if we looked into > the arch.desc proposal and just disabled stable keywords for those > architectures. That's also what I would prefer (this is exactly what arches.desc is good for). [I'm later going to make some updates over there taking the feedback into account.] -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp
On Sun, 2017-05-07 at 22:24 +0200, Michał Górny wrote: > I'm against. Turning more arches into dev/exp only introduces hidden > depgraph breakages. I think it'd be better if we looked into > the arch.desc proposal and just disabled stable keywords for those > architectures. > This is probably the smaller problem. The link shows a bug where none of the aforementioned arch teams have keyworded the requested packages in 4 months. How would the arches.desc proposal fix "dead arch teams"? Sure, it will make maintenance easier for pure stablereqs, but the other half of keywording does not happen. All the ia64/ppc/sparc KEYWORDREQs I have filed for sci-* packages I have closed and dekeyworded for revdeps. We have had KEYWORDREQs open for over a year with 0 activity. If the keywording inactivity continues, I will also continue to dekeyword packages.
Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp
On Sun, 07 May 2017 22:53:52 +0200 David Seifert wrote: > This is probably the smaller problem. The link shows a bug where none > of the aforementioned arch teams have keyworded the requested packages > in 4 months. How would the arches.desc proposal fix "dead arch teams"? > Sure, it will make maintenance easier for pure stablereqs, but the > other half of keywording does not happen. All the ia64/ppc/sparc > KEYWORDREQs I have filed for sci-* packages I have closed and > dekeyworded for revdeps. We have had KEYWORDREQs open for over a year > with 0 activity. If the keywording inactivity continues, I will also > continue to dekeyword packages I think its more "and" not "or", wherein arches.desc provides a pathway that makes dropping these profiles to exp less problematic. 1. Introduce arches.desc 2. Brand problem arches with the relevant flags 3. Drop problem arches to dev/exp That way we can still do some relevant keyword consistency checks while not holding back stable. Currently dropping arches to dev/exp tends to imply that *all* keywording consistency goes out the window into the EDONTCARE bucket, where the desired outcome may only be certain *types* of keywording consistency (namely: stable) is EDONTCARE but overall consistency (keywords being present) is still desired. pgpg4FsxL0Jzw.pgp Description: OpenPGP digital signature
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2017-05-07 23:59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2017-05-07 23:59 UTC. Removals: dev-libs/STLport 20170507-07:47 soap 967d0ecf3f1 net-misc/flexget 20170507-16:23 floppym faa11984b8c Additions: app-editors/vis 20170412-00:44 mgornyb25230c9155 app-emulation/nemu 20170507-21:58 monsieurp 10a139f721a dev-db/cockroach 20170504-22:40 williamh adcc810ebc8 dev-libs/atf 20170507-18:13 floppym 10a677ec452 dev-lua/lutok20170507-18:11 floppym 894bec61211 dev-python/betamax 20170501-14:24 mgornyc7373c5a479 dev-python/google-auth 20170504-03:15 zmedico af4cd2e469c dev-python/google-auth-httplib2 20170504-03:43 zmedico 069a239018b dev-python/mem_top 20170503-02:55 zmedico ed592803386 dev-python/namespace-zope20170504-16:30 mgornyd77fe6ac429 dev-python/pytest-subtesthack20170501-13:52 mgornyb79a44c86e2 dev-python/zope-deprecation 20170506-09:05 mgorny8c67507ecdb dev-python/zope-exceptions 20170429-09:24 mgorny54eb6222f3d dev-python/zope-testing 20170429-09:37 mgorny7137b61e91e dev-python/zope-testrunner 20170429-09:53 mgorny4b05eca45e2 dev-ros/media_export 20170504-09:00 aballier 9d4c29e0936 dev-ruby/activemodel-serializers-xml 20170507-06:00 graaff841d1d41fe3 dev-ruby/erubi 20170503-04:41 graafff6198c8da01 dev-util/kyua20170507-18:12 floppym 544befca3cb sys-firmware/edk2-ovmf 20170506-05:51 tamikocba60e1f979 www-client/vivaldi-snapshot 20170504-14:42 jer 003ff590fa9 -- 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: net-misc/flexget,removed,floppym,20170507-16:23,faa11984b8c dev-libs/STLport,removed,soap,20170507-07:47,967d0ecf3f1 Added Packages: app-emulation/nemu,added,monsieurp,20170507-21:58,10a139f721a dev-python/zope-deprecation,added,mgorny,20170506-09:05,8c67507ecdb dev-python/zope-testrunner,added,mgorny,20170429-09:53,4b05eca45e2 dev-python/zope-testing,added,mgorny,20170429-09:37,7137b61e91e dev-python/zope-exceptions,added,mgorny,20170429-09:24,54eb6222f3d dev-python/namespace-zope,added,mgorny,20170504-16:30,d77fe6ac429 dev-libs/atf,added,floppym,20170507-18:13,10a677ec452 dev-util/kyua,added,floppym,20170507-18:12,544befca3cb dev-lua/lutok,added,floppym,20170507-18:11,894bec61211 app-editors/vis,added,mgorny,20170412-00:44,b25230c9155 dev-ruby/activemodel-serializers-xml,added,graaff,20170507-06:00,841d1d41fe3 sys-firmware/edk2-ovmf,added,tamiko,20170506-05:51,cba60e1f979 dev-db/cockroach,added,williamh,20170504-22:40,adcc810ebc8 www-client/vivaldi-snapshot,added,jer,20170504-14:42,003ff590fa9 dev-ros/media_export,added,aballier,20170504-09:00,9d4c29e0936 dev-python/google-auth-httplib2,added,zmedico,20170504-03:43,069a239018b dev-python/google-auth,added,zmedico,20170504-03:15,af4cd2e469c dev-ruby/erubi,added,graaff,20170503-04:41,f6198c8da01 dev-python/mem_top,added,zmedico,20170503-02:55,ed592803386 dev-python/pytest-subtesthack,added,mgorny,20170501-13:52,b79a44c86e2 dev-python/betamax,added,mgorny,20170501-14:24,c7373c5a479 Done.
