Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 28/07/17 15:10, William L. Thomson Jr. wrote: > Gentoo is as stable as YOU make it And by "YOU", that would be the people writing ebuilds and committing them without test suites or integration testing of any kind. The devs who yell and complain all day about "standards" and "not breaking the tree" then go and break the tree and violate any standard ever set. With the possible exception of mgorny and pacho, I'm not sure if I have any faith in anyone left in Gentoo. I knew the political climate in Gentoo was always yearning for better days, but I could never have foreseen how bad the technical aspects could become. This attitude of "the user is to blame" is the reason I moved Adélie's upstream elsewhere. I am still running Gentoo on a few production servers, but this whole thread and /especially/ this message has made me realise I'm probably better off with Fedora until Adélie is ready. At least I have a good reason to unsubscribe now. Farewell, - --arw - -- A. Wilcox (awilfox) Project Lead, Adélie Linux http://adelielinux.org -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJZe6i2AAoJEMspy1GSK50U9MYP/2RhhrDBTaOa11DE5IC5rkSj 1iDYX8m3hr4kFgbHMTtIf+crYaELnZXr5uR5rFTb56q2vgrTs7xHN802W9a8GJV/ uRH1R/FzT3nZ3X0tS5Yz2wq+H7SICd5WQ8241BrkPyXgXcHy7/s2ubmewKnwoQHv sdUlA0/XCHItTApItmhOosCxaHcuAhQhbynfbSDKW5gN4dtxrnZq03xzNZL3dazh j23gNjUEaefLb9NlxbEZIxeOqrBbeaMnKjIMjPbPdV4RUqoQup43fognKJ2TPij3 LnN52HmY/ZLgD8RYQwyBui/WuqV62i/vdi/Iy4uPNDZnOMr1va2Wscj5mawnOXcB hpOEYrhSNykiGT1hyg1LPZqgjfw8ovAuwNU84An9vVAPkvqVGS0fCGN0W2lCT/oV o2SYJy2IKhkxTay7R2wklCeKTmXqo1yoQjp/zuGMD/pzAgln2h5Pc/9KjiDSo6pn mPsHOeWINjHqsUHdPeJAGjMkJaksA/my0tpzWyxkCmpxc/CVNa7HDt0HWWd5KkIO SFv33Cyj7NYVVs+E6c8+C7BCh7XgIB1DoexicFT9vDR7ThiTNU3PJMoYjxv+t3Tp Z7mUK19z/TQZNVst396AcujrhvyQC2zLbg03sGwRZR6m2GjlcYLeuIbZL6eS43Mc Pf2A1DrXM6tr4MMtOQXn =i0I9 -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01/06/17 20:28, Rich Freeman wrote: > On Thu, Jun 1, 2017 at 9:17 PM, A. Wilcox > wrote: >> >> just have users of a *source based distro* where the emphasis is >> *choice* actually choose what they want? >> >> What is the big deal with the way REQUIRED_USE works now? "Users >> have to do something". > > This is pretty analogous to the current situation with USE flags. > I have wine installed. Therefore I am constantly having portage > add 32-bit ABI flags to my use config, even though I really don't > do anything other than merge its suggestions. If I had ever put > anything in the config file that wasn't there just to make packages > like wine happy I'd never know as the file is insane now. Maybe > some of those use dependencies no longer apply - doesn't matter, > portage will keep building those packages 32-bit because it thinks > I actually care about that. hmm, good point. I hadn't considered abi_x86_32 since I gave up on WINE and Skype. The motivation section that started this thread especially called out the openssl/libressl thing as the terrible thing and that's why I thought this would be much easier to just solve with virtuals. Thinking harder about things like python_targets_python2_7 (trying to go py3 clean except on packages that won't is a *drag*) and abi_x86_32, this thread has a point. Carry on! Sorry for the noise. - --arw - -- A. Wilcox (awilfox) Project Lead, Adélie Linux http://adelielinux.org -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJZMMBXAAoJEMspy1GSK50UFLsP/3jxN3s/iXOy1DfzUt5eUnUS rvv5yc46bDW54x6gWf76+nJjbAaoJOgeBmHIapo2tytxEXJM/NlEuyQiLWoypziz sgm/vwLfBGQlXU9EVNzP7CusTH1CLz5qj4mtuhE5iCRh8Ktj8EnU3byI1unaA2yt TtkR5z1ojwdzulwg/opxnJcxmZtxE1DjJMuP6xMJVKY5D5jH487JKKzKWttLJ70f 0Kds4Pxa8Lfek/ItynKsoVAEbnjPl26bDQ4gA3gVM0MsKIuJnsrIpzPUKQFIUz2a jg81pJRk7d1NTlzCF+BDWpCDnsIgSdN2xWh9/fBkiQH1htxoBT5wy9sg+LZe/Z5u er77ScIYGoOu1lH3kVWLOivTYxFyEJ5NXVHfDN8DQaHdM2wGl6C3gRqg3u/qAj+m jGY8Tdj/pYFaHL6+l1gR6ViF562K3HKhAd+zjLPk3vWxO7j6SMRCelukmKy0G8yg +k1S5MTjOW3rPZXAcoGoVj3mMqoRzIzs2OXcuAWAZNZu7lSGQ+TIkEOXqzQ41ZUz z+yjiq2HjuIy+xVhXmcnYTurJi41F6DAQyz172btNstlk2gtget4iqEP85DDv3kF GxoriSEmtTvfLyYS2PpzpaaPhUISysrjtOryhN13CpZ6sCcBbfRGVZGu8X2/TRNg EHuak23KYEtGWdnyXe+D =wbnO -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 unpopular, unwanted opinion: just have users of a *source based distro* where the emphasis is *choice* actually choose what they want? What is the big deal with the way REQUIRED_USE works now? "Users have to do something". You always have to do something when you run source-based distros. If they don't want to do something, don't run a distro that is source-based. Gentoo being about choice necessitates knowledge about the choices you make before you make them. It will never be truly "user friendly" for the noob set. And that's fine, and that's where "friendly" forks like Sabayon and CoreOS and Adélie come in . I don't really want to see Portage's code base bloated with even another solver that is poorly defined (and worse, this one would make it in to PMS) just because users want to be lazy and Gentoo devs want to enable laziness. For the SSL/provider thing, I suggest just doing a DEPEND=ssl? ( virtual/ssl ) where that is provided by openssl or libressl. If a package doesn't support both, just DEPEND=ssl? ( whichever one it does support ). [I actually suggested this some time ago, but was ignored there, too.] But hey, I'm not a Gentoo dev, so I really don't have a voice here. :) - --arw - -- A. Wilcox (awilfox) Project Lead, Adélie Linux http://adelielinux.org -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJZMLy/AAoJEMspy1GSK50Uxd4QAIgieHNztCMC0R4z4++QGDO5 8j6uITVKoCP7wKpVZ2Dm8r0g2EbVBH+zy+Kz3Mbum8agaosoG6oW1mj66S2TjpX8 C8OokXVjhQuuddiDiZo2jXN5SABs/LLvkrElDVNdiGSluyfz/0V2I+OcXz40CrQv KjZA4LWIavOK8FhX8PzPydwtDbS9YPBuDKE2vdK9A5+raleKZvjlhLw3PF1yDqlc k1slBy20Wg5WtA0L1lo+ugZbLSrR5wmzBqji24Vh7pTariSV8nMhbAKiEVOY3PZ8 bEJdCahSO45Z9HJHfW6rxfVHPDWwCXw2JRjL4H9ixY3m96Za6KRNc1K/2KOOgI9D 0zyI2O+vtBrHmQJ9QiXsQ8c11MwYqz//2APCTuIwV8qjvKQTQBvQQRibYlZCRGJ7 8pBMrryd8TmtVcbN+aLzZcn1Z0K1lmM42zZxg1070C72VidJJOi4WqfO7/vWoMzQ m5TlUqd/vFLB5UidCND5KD9GDhiVQBl8DSJlENwaPGLgIqxGbzx6A/gxh80+TC4Q +SiKiQ/et87WVbZxNwx7/j5RATAlfZwMLvMVibjcwc+RKbx4JrOI2eaj/IOEMM8T suYiHN2Q63HWjZXj59o9Jo/5uzhE2Ygd6VlyCQPvAgbfe8gWOTsXtMat03FSkkb0 2Z1+N5nnCdWSMLLSvNBN =Rxfe -END PGP SIGNATURE-
Re: [gentoo-dev] Requirements for UID/GID management
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 29/01/17 11:05, Michael Orlitzky wrote: > On 01/29/2017 03:26 AM, Alan McKinnon wrote: >>> >>> Can anyone think of an upgrade path for fixed UIDs? That issue >>> aside, I may have convinced myself that fixed UIDs are better. >> >> The general process I would recommend is that if the ebuild finds >> the user already exists, leave it, it's UID and it's file >> ownerships alone, and keep them as they are. If the user does not >> exist then create it. > > That's what I've got it doing now... > > >> Preferably use a pre-assigned UID/GID so there is some >> consistency with most other Gentoo things out there. > > This is the only point we have left to consider. To recap, there > are three approaches to try: > > 1 Truly fixed IDs. Every user gets the UID it wants, or it doesn't > get created. The UIDs are all determined beforehand. > > 2 Mostly random UIDs, and the few packages that need to specify > one can do so. Usually installation will never fail, but if some > user specifies a particular UID and doesn't get it, we die(). > > 3 Mostly fixed UIDs, but with a fallback to random ones if you > don't get the UID you want. Here, everyone specifies their > "preferred" UID, and we try that first. If it doesn't work, you get > the random assignment. You could easily start with #3, and after some years, move to #1. Anyone with a 20 year old Gentoo install (by that time) should expect to have to do very heavy lifting. I for one am more than willing to do whatever shell commands necessary to make all my Gentoo installs agree on UIDs and get #1 now, but I realise most people are not. - --arw - -- A. Wilcox (awilfox) Project Lead, Adélie Linux http://adelielinux.org -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJYjiTOAAoJEMspy1GSK50UCgYP/j7zBRAiL6w7fACER+A+J/3x keXe4OsBzlNsUxqC+BrQ/Y9tCSJnIHRIs6ozQCgEdfAKJfkLqkSmKAY3O3RT+mho VzjUCibftf/UNGOnFf6BqXCeBEjtV1YA7URlYumNyHxdG/AFIICWYFSSTLwzJoR1 91wqJmbcUI3LtQXoXodaYC2nbUWvcbO8RyxpDmxZ33L8xj1lAgpuFNcdEs+Rscxp oDK4zJC/K8wUYTUR2YO1Lb3lPF6qgJbMcX0YpQaXIGeYA2PXf4O+LqTXmGNr4O9r DFM3dbPgq2YPuHORACUY5YsmPBjHiaJlgzJo2WrhnIc2D1MPhA430Xlloiua3kF9 G7yqkz7mhBtJFrExoQ2MrtXMB5vwDUZ+3qrBzx/cKfxpSzsRck5NZ27eWK0oEpg2 fAUFJT7iIwSD3WyLkQbc2HHQ5nnTlnrBHM56YgCIPgz1Y4aNSB7hA+tCfQj4CNZC Y25d9VzBM2KclASiH6ROQLK5EyU0joMtZvTRx89b8SJV+AebLeaWtCsGe41KeF/W iDSnPGXtKRLYZtdebxGCXZwbaUVCRu/cIH2TXMpWDjm0iw3GoFZ6jiLveRCns59U UecZNQph5tPc/HBX2zCTTmH3jNfifSfb525aHVnUSVlyTWa8SQzw2jlnOuAkI33q 8MY5++CHplEPGVCvYMrc =99NE -END PGP SIGNATURE-
Re: [gentoo-dev] Requirements for UID/GID management
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 28/01/17 13:32, James Le Cuirot wrote: > On Sat, 28 Jan 2017 12:13:53 -0600 "A. Wilcox" > wrote: > >> Having a file that user.eclass would use to map new users/groups >> to IDs would be extremely beneficial to me. I was thinking about >> diving in to that some time later, after the GLEP 70 work I'm >> doing, but if someone else wants to take it - please! That would >> greatly ease the pain of not only NFS, but swapping data disks >> around between different / . >> >> Consider, for example, one of my use cases for this: I have a >> LibreSSL / that I use solely for testing ebuilds against it, and >> my regular / with OpenSSL. I share /home and /srv between these >> two, but the apache, nginx, and charybdis users have different >> UIDs between them. Therefore I have to chown -R each time I test >> LibreSSL. >> >> I could use a different /home and /srv, or make two copies, but >> it's much easier for me to test these apps having my entire >> normal environment available to me. > > As mentioned in my other post, why are you not using idmapd? It's > trivial to set up on top of NFSv4. > I think you have missed the point. This is not on a network and this has nothing to do with NFS of any version. This is two LVM volumes, /dev/ciall/libressl and /dev/ciall/root, mounting /dev/ciall/home and /dev/ciall/srv where they belong. The kernel is started with different root=, or sometimes I just bind mount and chroot if I want to run both at the same time. Nothing to do with networking, just two parallel Gentoo installs on the same machine that can't agree worth a darn on UIDs/GIDs. I like the pre_pkg_setup idea spouted elsewhere in this thread and will likely start using this myself until Gentoo figures out how to guarantee stability with UIDs. Regards, - --arw - -- A. Wilcox (awilfox) Project Lead, Adélie Linux http://adelielinux.org -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJYjiOAAAoJEMspy1GSK50UWrAQAIq0fz+oxA2SWCEBNdKKZgRN gNJOcnEj9lWSiE4bXA4C4diFj38GD5HhTK6awwNjEJ2e3S/+IvJvy97RcUjzpP09 iE+77p3YyZeVxywONJ+BK0gSWc3pJrYzzZWMmHMhIhA5TW78OPKFgP4q+FT8Ruwu TdYL4/cH6shcELacsgLq+0fBxgT8xkl5LA0OWdW5g2lVFzcnZ7sM/qX7WMlksaVY o4fPBc10hNwrAW5HsSBOw6tZsf+8CtaBaYVub1DfgWSLxmE70+9pX+4VCObvuc9m CZ1u3tvcus7xBbpIDxD9M6yC7Jkj250Gr0IAJol2y8JJY5EyCu/iNtUbHT3lgb+F qRKLbMDp91F9jzHmup04UuJdVkcDaxA4nfb7RWGOnH4U5BmmCdHkxUMtSA2vPNAh 9m7dwn+Yb6OjHKvB/gswbRfT4vV6bn0a07/J72GBgoWvEvGZ/rj9mO5O7gu/k9eQ zXc3eSWWmi6S3FtDHKNP7U+CrBGOu6DN79GGDO4zzGpl8aWGFm8ol3qW5jtWKdsP y0K1n2erH1Xfj5CoXzcbm3s7EQxiB3hEHlfv2gYYMrZZuqKgrVXQ5krvNApbsiQo dVmGOugfIUnVcv/o6rpwtCzNnyGahq6PISkJbRwzh3irA7fsZjYYZITnN6Ba0jIU EVO3/JgkJDAvyn+ZWQ8O =aaA7 -END PGP SIGNATURE-
Re: [gentoo-dev] Requirements for UID/GID management
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 27/01/17 20:37, Patrick McLean wrote: > I don't think we need to have stable UIDs/GIDs in the "normal" case > of standalone users with a single Gentoo system at home. The people > who need predictable UIDs/GIDs are the "enterprise" users or the > home users who use things such as NFS. I work for a company that > uses Gentoo, we have a bunch of workarounds to make sure that UIDs > and GIDs are stable. To make something to solve our problem (and I > suspect everyone else who cares about this), it would be sufficient > to have a mechanism to override the default random assignment with > a fixed UID/GID. Possibly some file in /etc/portage or in the > profile (or both) that allows one to configure what UID/GID a user > will get when the user is being created. One advantage of this is > that user.eclass could be modified to support it, so we don't have > to wait for a new EAPI before taking advantage of it. > Having a file that user.eclass would use to map new users/groups to IDs would be extremely beneficial to me. I was thinking about diving in to that some time later, after the GLEP 70 work I'm doing, but if someone else wants to take it - please! That would greatly ease the pain of not only NFS, but swapping data disks around between different / . Consider, for example, one of my use cases for this: I have a LibreSSL / that I use solely for testing ebuilds against it, and my regular / with OpenSSL. I share /home and /srv between these two, but the apache, nginx, and charybdis users have different UIDs between them. Therefore I have to chown -R each time I test LibreSSL. I could use a different /home and /srv, or make two copies, but it's much easier for me to test these apps having my entire normal environment available to me. Best, - --arw - -- A. Wilcox (awilfox) Project Lead, Adélie Linux http://adelielinux.org -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJYjN9aAAoJEMspy1GSK50UD3YQAI/ImKKEoTdEu9B3woyDsbcz 4QElt5OsaiOFcT9f30/rI/8G5NQ9JYbh/XvvS7JlPllhCu+xV+BQhGznH7C+w7sf 0m/9HJbJLLDXcpP1gB9lUTn1JhKN6Vp19UhTi5upXIhTK5yTeUAxG/VhpucfMnml QsC7DOg584nL47/w2jc/IWqZLIJ/SVbWcYBpjbfelCRHetuR/cXLdpe4EhqnwcVx EhVh1zUJYDMDwFK5OYCrwHFvp2PUy7d1qiWOJZ5dGvw+SuG2/Xd2hcwgwFf6X3EK 8cxWPc3xrbmmtxKTatkKB/pOGn1rj/bm4JD0XxjzPJUWJ28eZ06LDZ2lszm7xse5 KUg0cgT4AwER0K1G7bqFfntdDNii6qjs/B5oBY9Jr/SC0YGDvcbh2bMYKDRTDRqN Qu9zzk5MndkoIOQUFt5ccRYoXftDBKofmqWYhqjxo/LUcnvpF9w1nacsGIkkFWE6 64Y80yIr1A++WQGasd2U1SAbDFFHaXdv5YSENRTGo19I/QWVO1L70M3KRh7YIgz/ Nx7aWH3ir9BGFqi/plqSfbr30m85EA1LMnc8iPfe/HcnyOZgrZkdNzmENoeudqGU SAe5AeAimoYbmJfJAv4ou4aOnKtNi4tZQVTkYi4Y9SvkRLHU7lquPDre92f9WWOx jMHKVwcPi3BGtladWZM1 =Ufwn -END PGP SIGNATURE-
Re: [gentoo-dev] [PATCH] toolchain.eclass: set CHOST for gcc-config calls
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 27/12/16 11:04, Mike Gilbert wrote: > What I'm very unsure of is cross-compiling a cross-compiler CBUILD > != CHOST != CTARGET. That requires a bit of thought. I'm not sure > we even really support that in toolchain.eclass though. > Having tried this before, it doesn't work with Portage (at least as of Sep 2015). Then again, it barely works hand-hacking it manually. :) - -- A. Wilcox (awilfox) Project Lead, Adélie Linux http://adelielinux.org -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJYYuVnAAoJEMspy1GSK50ULqUP/jotFE2oN+fYDsp5fuFhWJg/ GFk7lj/oHa2tnQ3JqzHQ+H0/uFG98U8+fPiswCuRweJUXO1P2hbRao8EGVxYw8Xt f+FporNTQg8jGkMRXzISKBAboqpCEOgLH3p8WYaGs6qmFIidHm3r6H7gg7y/bTf+ zKDUtlnEYAmwDV6zGF74d/lTBox3rbJqkZVAKkVZbzc8Y83tod9mNZL1goTBSfkF z1AcSKsNtNYlQmTe7x/0LZXZ33Wi0mEqD65TaJK5aaU7l3Hu9W6DUAcZQaPlql4u k7LkZZO2MQ+cLp68kDwxEae8ZRs/9S3bBNNH5IaI7ASdkJmPnanR22jODuQkR6C8 GNG0jJemozyTVONVAUs2FWslTxXJ/Pgdu12SnfydUci42KVvXyOtXBB7ICmo4yfN yF4p6XXeHbmlvi8xoBLxnOxSUvrtorFzqZLK/YeiUMuSbknKDhDFL9fD+gFIBZlm ABdiK5Z1AewrYf9WBmqj80u40bcYTU2SVN6xKgKoqYPkvfPEk+W93wmWaq0+6VX6 m+JV9UT+Jt1umY2WW0oDVlwW85QhXQPKFUTdByx2E6++iY3CiSXn6i+uDpwJt+0b ShS6E7rQgBxfH2rwJ0sgtBgDoqYegUgrgRDgMfvO7wfjOZsF04qH/tOYz0UGuyAV 5yubToZyJRT49dRHbv91 =hkcP -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: Proposal for addition of distribution variables
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 15/12/16 17:03, Michał Górny wrote: > On Thu, 15 Dec 2016 21:49:15 + "Robin H. Johnson" > wrote: >> 1. ebuilds: Add eclass to export all variables from >> /etc/os-release with a prefix: OS_RELEASE_ID OS_RELEASE_NAME >> OS_RELEASE_PRETTY_NAME OS_RELEASE_BUG_REPORT_URL etc (I'm happy >> to bikeshed the name of the variable prefix). > > I'm not really into exporting a not-well-defined set of variables. > This would mean that e.g. OS_RELEASE_FOO would be explicitly > exported if os-release specifies FOO=, and otherwise it would leak > from the parent environment. > > I think it'd be better to bind it to specific variables (possibly > all defined os-release vars atm) and clear those that are not > specified. I hadn't realised the wording of this sentence when I replied. Yes, that seems like a bad way to go; it should have a set of variables that will be exported to ebuilds. And perhaps fall back to the profile for anything not provided. >> 1.1. Upstream packages that natively read from /etc/os-release >> will automatically be supported. 1.2. Could potentially be in >> base.eclass. > > base.eclass is in process of being nuked, so please don't > reintroduce that horrible creation. Separate eclasses for specific > purposes are the way to go, not huge monsters that do everything. As I said in last email, I plan to make 'branding.eclass'. No base. >> 2. Introduce a new virtual: virtual/os-branding. > > I don't mind having a virtual for this but tbh I don't see much of > the point in it. Are we going to allow users to switch branding at > runtime? ;-) > > Or is this purely because you find overriding virtual in subdistro > cleaner than overriding a package? On one hand, I would agree with > that. On the other, that would mean that users will find eternally > uninstallable packages due to blockers -- i.e. redundant. As someone who is running a subdistro: virtuals cause me even more pain than real packages, as I have to constantly chase || dep list, and when it is updated, normally there is no version bump (it is eternally virtual/whatever-0 or virtual/whatever-1) so I have to go in and change again. I agreed simply because package.provided exists. But I already have to 'override' sys-apps/baselayout, due partially to licensing concerns and partially to the fact it has Gentoo branding everywhere. >> 4. sys-apps/baselayout: 4.1. Move all branding pieces OUT of >> sys-apps/baselayout, into per-distro packages, that satisfy >> virtual/os-branding. 4.2. Depend on virtual/os-branding (maybe >> implicit via the eclass above?) > > Wouldn't it be better to put it into @system? And possibly engage > some releng quirks. @system has no guaranteed merge order. It would be better to make it implicit via eclass, for two reasons I can think of: 1) It will pull in the package before it is needed. Guaranteed. 2) On embedded/crossdev, the only package in @system is busybox. So there is no branding present. That means that virtual/os-branding would be useless bloat, unless and until a package that uses it is installed (at which case it could be installed anyway). Just my two cents. Thank you. Best, - --arw - -- A. Wilcox (awilfox) Project Lead, Adélie Linux http://adelielinux.org -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJYU0FUAAoJEMspy1GSK50UWvoP/AiNspWMoqTz9WXEDOhSWdPe XEMSvjnMHoDvc7ETpKWiCPHx6bOB+S/B/sGwdSU4H7hHCg5a5JukzHToXwaVZRgm pO+W5084kJIRSMDsOo5xRN8B9tQqfBdmZwvsJHJ7pGHrP38m6iLm04FTbn1kbc/Q CyCAStRmTs0NROcJFXEIZAyDJohdvhWBk2CLKcou2zhcLmZDwMuOJaHM85FK+7fg 9+DDrehBfbIM+YuSKz52A++sUwRTofnkGPzGycfL+UGmbEB6JrU6tSem5YyQpxe2 UZzsmJUzvY75hh1yvqeh7Ye6DPY2l0UYFkY24SVO/QlSkqXr9qJNYo8gJ7Un7y/4 aGpQnbNgus/dioHvTLcQnWeipBiGCal3EBJEkh9hKzPrJsLmpn2Ogh/+OJsxdw4S qMQCgqA3vB9wDig5JatSootGSPyAOAEOyQ3I8fkpj96bz2T7pgxX9wvGnkfKXIVY CTqdYJjQCAnxfFBujoN6AUiTMVaXBhewS7O6TOLJiszVqhlAsjbLeza/xY4vrpgG VzmakLygqkmY3+xgqLcgqFOkazAr6ZldxaDERVV0lvRcs8sr+3ycXTRnpudB8EdT x5rvwsUaLqn0OWjTGnPdsmkt/WgWw2vEfCdnMqjW84VeQCjMHBbikLJmj+oVaqoB q7MlTp0uHpQQ51X4ESy/ =lGeb -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: Proposal for addition of distribution variables
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 15/12/16 15:49, Robin H. Johnson wrote:
> I do really agree that how we offer branding should be covered in
> a GLEP, and be very easy for downstream offshoots of Gentoo to
> follow. This would prevent future concerns like the Ubuntu branding
> / modified VM spats.
>
> [snip awilfox's superb proposal; I agree with all of the reasons
> and outcomes, but think a little bit more structure & flexibility
> are needed].
I posted it to the list with the express intent that I welcomed
improvements. I'm glad that the community seems to agree this needs
to be done, and that we want to get it right the first time.
> 0. This proposal is centered around using os-release, as a
> cross-distribution model.
I am interested how this will work :)
> 1. ebuilds: Add eclass to export all variables from /etc/os-release
> with a prefix: OS_RELEASE_ID OS_RELEASE_NAME
> OS_RELEASE_PRETTY_NAME OS_RELEASE_BUG_REPORT_URL etc (I'm happy to
> bikeshed the name of the variable prefix).
OS_RELEASE_* seems fine to me.
> 1.1. Upstream packages that natively read from /etc/os-release
> will automatically be supported.
Yes, this thankfully includes most modern KDE 5 and XFCE packages.
Still, KDE 4 needs to be told in configure/CMake.
> 1.2. Could potentially be in base.eclass.
What does it do when /etc/os-release doesn't exist? Would Portage
still be usable? I am imagining such a thing as: "I accidentally
deleted /etc! I can recreate most of it using emerge -e world
though." Also, crossdev / embedded images.
> 2. Introduce a new virtual: virtual/os-branding.
This is an interesting idea.
> 3. The distro branding package (v1) (providers of
> virtual/os-branding): - MUST have NO build dependencies that
> require execution (this could be the very first package in a
> bootstrap).
Ah, I see now. That would make much sense. Since it would likely be
static files anyway, it would probably need no DEPEND= at all, I would
hope.
> - MUST install /etc/os-release - /etc/os-release MUST provide the
> following values - NAME, ID, PRETTY_NAME, HOME_URL,
Where does OS_RELEASE_BUG_REPORT_URL come from? Does it use HOME_URL
if BUG_REPORT_URL is not set? I suppose that would be acceptable.
> - /etc/os-release MAY provide other values. - MAY provide hardcoded
> values for /etc/os-release - MAY read values from profiles for
> /etc/os-release - MAY install any other branding files (logos,
> artwork, trademark, notices, etc)
It could RDEPEND on sys-boot/ logos and such. Not sure that large
desktop backgrounds and the like should be required on small embedded
images that have no displays though. Perhaps artwork could be in IUSE.
> 4. sys-apps/baselayout: 4.1. Move all branding pieces OUT of
> sys-apps/baselayout, into per-distro packages, that satisfy
> virtual/os-branding.
That is also interesting. So other distros could then use the Gentoo
baselayout package without having /etc/gentoo-release files and so on.
Good idea.
> 4.2. Depend on virtual/os-branding (maybe implicit via the eclass
> above?)
>
Hmm. If it goes in base.eclass, everything would depend on it.
Including virtual/os-branding itself? Not sure how Portage
could/would handle such a thing.
If there were to be a branding.eclass, it would certainly make things
much easier. It would also give more explicit knowledge of what
packages were using it, instead of grepping the tree for ${DISTRO} and
the like, you could simply see what packages inherit branding.
If work lightens up I will try to get something hammered out by
Friday. Otherwise, I will probably have something by the weekend.
Thanks!
Warm regards,
- --arw
- --
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQIcBAEBCAAGBQJYUx3sAAoJEMspy1GSK50UFF0QAMOxiiqwX0uR5Ubx7ZHQj5qL
5iHK/KPQW9tR4vumtCRy/xppK2xvQ7uQbyZWsVekfUmqji/YH3+KoKyy0ffuFryA
DpEQ7Gar/J1dXLainriTxfpFxuDHMO2OEzcUxpYD7PJ5snj9I7ED1e5KtxZnW3XQ
lpccCBKbtcmiEum3bODGwFr3PI7awpiZZBRZZgDpP+Am8ibnMeYuST4ROcem58RO
7b8TQIcVMQmtJLpZSc64WFwOZ22SRRBz4TXkaWrUC+6+swhSXqWuMkMwSYYZVmBt
8HIMKBOrS25bi4BEIft/+p68DVeYJLGp3d2SAM3DBlkgDV2FsicHp9+m/DTZXPYA
4JUvv+n/sROudEeUj2MP9j5XMarSl2uZHoNeBKIM64AtxL05hdXKj+bXofCEIgXh
4/TPq275cMIMfWFHuNy1/zh/DYJ0emE5RekFx1oCj4i37+HU72moft6Ndtdkxz/p
FlwRonpouE4mBQ8H4wPkJ3wWPaVpL6k33adPRKnycjid1JhA+a9Qnsr1ZoILzfc6
6ieNEtSHiX6C5CbrEIlkaiAhzgGwUlq+dkjakIWBibPHUSJgg8tU2fyzaIO+o90A
Z2Y5uikUFW5GCRLTAPC5e7Tfx0yfGhyR5CSWkkyexAE86YDj/72BU967UfnQznEp
rQkL+Ax+1C1FJSj5JIa2
=7adt
-END PGP SIGNATURE-
Re: [gentoo-dev] Gcc 6 and Gcc 5 update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/12/16 11:59, Magnus Granberg wrote: > Hi > > Gcc 6.X update: Gcc 6.3 will soon get released in one or two weeks > on that the pie use flag will get unmasked and gcj will be masked > for java is removed in gcc 7 Package that fail with the pie flag > needed to get fixed upstream for we are not the only dist that use > it now days. > > Gcc 5.X update Time to start fixing bugs [1] for it is time to mark > it stable. it will be 5.4 or 5.5. Any more bugs that need fixing > that not in the gcc 5 porting? [1] > https://bugs.gentoo.org/show_bug.cgi?id=536984 > > Yes. https://bugs.gentoo.org/show_bug.cgi?id=590098 The patch works on glibc systems too, and is important for correctness. But ICE on a (nominally) supported libc is never okay. - --arw - -- A. Wilcox (awilfox) Project Lead, Adélie Linux http://adelielinux.org -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJYTb9jAAoJEMspy1GSK50U758P/1d2LhcEVfEiSGTLuxEej/e+ xp2xdvaPVqhXWioXO3wghm7THDJGHoGMYSNl4WXzv7mkYX0xPuNyx1t1g6xsnIt5 R2TloaQnxpKUUqfFph/Z5Hyhu0IOYFV54G8aPuBAbdVVG5FoVjm5lHMKeQVh/YAz vM0IjOhJtwHgdmExFLpxLYk1ZRlNI+PrGN+D7iyd8oo2SY1oVh6ryLKWtPJBgvKW tkdNY6Ab7rBbfmJOGN2/KsUbhXWF3Sbh7Sgk878qTwyMlEZb53akZsMQ4+c7cq+p Ttarlt0VsoT0RU9Z6dNPTBjjYMx2rPmUbzSrgrlSaBjTeO+eoKXaKlqABXiREsQB jr98UWYbnhITpLNVBTBVD78v91QncfQs9ybaP9GMFEhv0t3mXIyQaevz2hCGSwJl CIp38Ip0bGeVWaAYQj3qrluSPa1sJyNsCjih3pIXryJjUymVGMQtQEGfmDAXf8Um KkJLdzw5a7PClwvktK4iV4fhTg+77asnoztSbHTJv8koiR8dG9Zv6ll4WPClcWlc ArIf8mk8mhIvG4GCmAVj/9CDpspAhphjh6iWHLZeMdPvRuB3cITdO7A4pAbFS2Hb ucoL7sWnI42ZI/PwDEpXyfY8esV01RCef+ZNbECbaTK6k0Ht3OdiW4Wmo2wy5fQi gMSG21iJl7mAYQAMtob2 =NLJE -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Cross Post due to technical component - Thanks for all the fish
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/12/16 23:46, Christopher Head wrote: > On Wed, 7 Dec 2016 12:15:06 -0500 james > wrote: > >> Gentoo-proper is has too much political baggage to encourage >> folks to innovate, imho. So, I really hope the gentoo dev >> community gets behind the Anna Wilcox idea of streamlining Gentoo >> into the most fork-able distro on the planet. WE could all be one >> happy family and yet be very competitive with our ideas, trials >> and published results? Surely a few eggheads >> (academcis/pedantics) see the wisdom of competing micro_distros? >> Then there can be peace and harmony as everybody can do exactly >> as they please with their little cluster of gentoo and their very >> own portage-tree. And then folks running gentoo-proper now can >> pick and choose which innovations they want to include in the >> master tree. > > As an ordinary user, this sounds pretty bad. Forking is great for > developers, but bad for users. I don’t *want* 27 different > Gentoo-derived fork distributions, each of which is great at one > thing. I don’t want to have to reinstall a different OS just > because I switch from writing embedded code to running Octave. > Honestly, I don’t even want to go out and find other OS’s repos, > add them as overlays, and hope the inter-OS dependencies work. I think James has perhaps spoken ambiguously, or at least I hope that you have misunderstood his proposal. (If you haven't, then he's misunderstood mine.) The point of making it easier to fork is not only for the benefit of developers. As James says: > And then folks running gentoo-proper now can pick and choose which > innovations they want to include in the master tree. The idea being the people who "run" Gentoo, that being the developers of Gentoo, can pick what they want from the forks and derivatives, and include those improvements in the master tree. Then all Gentoo users, and all derivatives of Gentoo, can benefit from those improvements. Consider the relationship between Fedora and CentOS/RHEL. Fedora is released rapidly, compared to RHEL. It is where innovation and development happen for them. Then RHEL picks the best bits from them and ships it in their product. You don't have to run Fedora to be able to use the work they produce. (Though sometimes you have to wait a while!) So for one example, at Adélie we are focusing hard on the musl libc. At some point in the future, when we have things looking good, we can contribute that back to the official Gentoo musl overlay. Ideally, that would be the main Gentoo package tree... but at least the overlay. We have also packaged some great open fonts that we've found. We can easily send our ebuilds to Gentoo's media team and they could put it right in to the tree. (Right now, I'm still working out the best ways to use the fonts eclass... hence there is no upstreaming yet.) Forks and derivatives allow a much wider community the ability to experiment with the powerful Gentoo system without fear of "breaking" the "real" Gentoo tree. Things like my APK BINPKG_FORMAT patch may never make it upstream, which is fine. However, overall the goal is to enrich the broader Gentoo userbase. After all, isn't that the idea behind open source in the first place? You have the freedom to take the code, do what you want with it, and then contribute your changes back when you're sure they're good. Forking Gentoo allows people to try out more wide-sweeping or drastic changes without any danger. The future can be cool and groovy if we have the freedom to tinker :) - --arw - -- A. Wilcox (awilfox) Project Lead, Adélie Linux http://adelielinux.org -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJYS5zfAAoJEMspy1GSK50UjiYQALxqN9b3UG04ioErJ/fyBoaK qSZjyCw7xXK+SaiNXyfDQPPmoTMxdNgog74awEwM4bGVYplMECeIf8JLcyDpRzol fBbnhucckeLAYM+n4RNv/eozjRtg7qc5SgnkIL0mihDkzEVgAX5d5pUS4V4ZIoe5 P8Q3fMsxdOFomBetLG3pKBpO980xylf2xy/6EoZVAbeR0kIqw4NecskTe+by4toz vJbrvKX4ht+yhNPGw+QfKY+oM3KEzc8VsjcDI53OzFL4CuNm43CkAECExhcl1pXi 4VbmENP5M1omP5AhAJiEsev3ORhzXKFX+9Zs8Z/WQYi+Osnzw3I2HxX5FK7g8J9K DNprGIrjnoazwKVMaBapK8qEmI8r8xYQVqKq6s8wzWbTa8k1FYA0H8A/pCbeQmjz o/TdE8oc5py426T7CThxFVsRdLiq0q8werEJ4Zql1nFBNYu34Us15i8MIkujHu25 mrByesaeuTM25TfHzRV0A7LCte8vvGJkwZ6Z9ndokJdSIn9Xjw4sUgGRjT5SKsu4 KKN4UDTpATSX5jRmCfVeREHWyPuVJermeX/2BRVmH1EbQ4KgqPetLMm19SBzKxEs dOLLlPRj4lsh9s7Z/J9nkzKUGWsNBUGbM9+iMOF5/e8CgT4eLIcmHsmFeqxJsylk IrzjcKTPHvEeM4oP+Yfm =2Y0G -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: Proposal for addition of distribution variables
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/12/16 21:28, Michael Orlitzky wrote: > Maybe a GLEP with the contents of your first mail? If there's > consensus for the premise and the implementation, it's easy to add > the variables. Then it's only a matter of updating ebuilds. I've tweaked some of the wording and changed to Wiki format from rST to conform to GLEP 2, and filed bug #602202 [1] to have this formally added as a GLEP. Comments are definitely still welcome, either to this list/thread or my personal email. I didn't find any reference in GLEP 1 to how changes can be made to GLEPs already posted on Bugzilla, but I am definitely open to hearing any that the community has to suggest. - --arw [1]: Bug 602202: https://bugs.gentoo.org/602202 - -- A. Wilcox (awilfox) Project Lead, Adélie Linux http://adelielinux.org -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJYS1jDAAoJEMspy1GSK50UXN8P/09uND1/3WMFDT/sn+/gvooR nFd0V3FHmljoy4EOOTUceYQQBtAPuzRLy8rfNIOtXGyxfx/oHrH1zgqrfugQwl86 KwuXh5t4v5dUQB12TjKtTItITWx48KoedcXM4Pxu73nKo1L7r/jySFFAgOvqDf/P vdrGOsa1R4uyg/XvC8fDojL5m9SAF60vloHUhQChIp9vhTzxs8PRVi8gIffuZGTq zrHczroutx4FA0LdsPosEQs9ClO3rbBk/JTuG6WAkgqTeMWDXXAxOyNYMdiQworA cuO0eU0S3pJcIE6NsbKmZ0qbcJbsgekv/UyBy08r06maOnEt3LbzPRVcOSc50qN8 qQ39DPHnda1bQXINwzeTKq7/2Oly9TjJi4P9c4mUNTeAayRwcvfo/8G16E96/eyj z2YHYbJytl945S9B1W7fGCzEuCEVOZiXXBvMpu1bO+B0Oonp3zOhwKgqBE/dRZvl 8dAGQzA7LMXb2i1OUTUdtTdbY3cju0t+yYITJ64LKdLWYWgY/m90vttkYE7CHyJO U33pShFVQuVkHjccT+oWCtI9anZ6Lnjr75PKbi7GlMihQ2hocxH6dmnUZksquLcx HWE1OZSESVqBUH5PHlBQuJsjVwkrKEdv9Yqtlr0mfk7BYFw9r/5b//pnXzjCqO5e y+zanHProXl06FjtA9nd =1NJI -END PGP SIGNATURE-
Re: [gentoo-dev] Adelie Linux disambiguation request: not the same Adelie Linux from 2003.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/12/16 15:38, Robin H. Johnson wrote: > Hi, > > I'm wondering if your Adelie Linux is related at all to the older > Gentoo derivative from 2003-2008, from Montreal: > https://web.archive.org/web/20070221042454/http://www.adelielinux.ca/ > > > > I know that they rebranded to "Calcul Linux" somewhat, but then > it dropped off. (Also NOT the same as the Russian "Calculate Linux" > Gentoo derivative). > > Yes, I'm aware that it's missing from the "family tree" that > Daniel Robbins has: http://www.funtoo.org/Gentoo_Ecosystem That > tree is also missing some of the other derivatives & forks, such as > Zynot. > No, this is a different distribution. We are creating a binary Linux distribution from ebuilds with a focus on POSIX compliance, ease of use, porting to alternative platforms (x86_32, ppc, arm64), and speed. This project rose out of simple desire to have a way to use Gentoo binpkgs with the apk package manager (from Alpine Linux, not the Android app distribution format). I was bouncing the idea around in the -portage IRC channel around December 2014 and a few users and devs (including ryao) encouraged me to continue seeing if it would be feasible. As I found success, some people asked me if I was considering distributing the APKs I was making, and it turned into a distribution fairly organically. The domain was registered mid-2015. I named it Adélie because the Adélie penguin is the closest living relative to the Gentoo penguin (along with the Chinstrap; Chinstrap Linux is a consultancy firm), and I personally feel that Adélie is the closest binary relative to Gentoo's technical goals. If you have any further questions, go ahead and ask (on or off list). Regards, - --arw - -- A. Wilcox (awilfox) Project Lead, Adélie Linux http://adelielinux.org -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJYReaWAAoJEMspy1GSK50UwP0P/2U7sgwfYiYbHIxO8YPLDfM5 itxo032I/QQN0PinWoOFlwZJOnk2maAGfEJ1wEQFlYqtqkCs9KE9I8iGF+P0+DpP IknLwp4lgH1XTiCA1s5QH7KlyZmRFNQH7sZww2U0R6NdlDh4XffoVgBxgURjDCM9 RvKuaZMYLbKwQmZ3RV0VYJGRkYJRD0Szm8fSo5cxfTNfcbF9rWsmo2uglr/Re/5w Cxo2Y+weDkhIpXWW32Z2FN9ytTipPItYSCWzlH9Y50X1YkgyeaFXwFCr4RiLubau OtLw4wmWw216uksFG8n181jQtqmqawylSQYrm6G+Rp4VQvwCaFx8TEcaMnrwHUhW uDC1cN5IT+4MqAMocV9pw4b/AxdGfZxdrBSgnEvp9iZzxPdY/AS7w73zS/luT7tn qfklMNCG/wmK/fIfSZt0doLf4NcKFojaByApdq8qdQ6dD1KJS7MskvSuxV4Rj52n jVq/y5RzvJU3oa1ZQJaxh/JKz8dftRWVSP2g5khjAXbZri3AgXsyhxK4/NHAPEr3 PmqKGLXu7pVfJcVQ8sLQI32agWFqYyu+/VgfPYqDqLfTOXFAw01H5WPEEXtQrFJ5 UWpE5Gx5iC5csvfcxxn83AHO7GQPT/z7pz98u5XPr2EcwcumRIadBoFkHlLd3dV5 gKitQY2GwjZXv8nLvxRm =/u8W -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: Proposal for addition of distribution variables
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/12/16 21:21, Daniel Campbell wrote: > How would we ensure (or encourage) that other distros based on > Gentoo would follow this practice? Adding things to PMS isn't a > panacea, sure, but from what I can tell it seems the goal here is > to allow distros based on us to correctly *show* that without > changing hundreds of lines in the package tree. Maybe that's > outside of PMS; if so, where does this belong? I would hope people would consult base/make.defaults and write their own, which would lead them towards the variables they need to set. However, there was a fair amount of legwork I had to do and find out with good old trial-by-error when I was writing one. > Of course, this solution requires action/patching on our behalf as > well, but it seems like a long-term goal that, when completed, may > be suitable for addition in some sort of standard document, even if > it's a wiki page on how to roll your own distro based on us. I have plenty of experience with that and I would be more than willing to help write such a page if that is desired. > It didn't seem to me that there was any intention to automatically > guess which distro it is; the people in charge of each distro's > package tree should be setting those variables to the correct > value, and it should be accessible throughout the tree(s). The original intention wasn't to guess, but I see how PMS is more for things that are determined at run-time by the package manager rather than static variables. > As OP mentioned, at worst it does nothing until it 'spreads' > throughout the tree. The end result is anyone could fork us, change > DISTRO and DISTRO_BUG_URL, and instantly have a starting point for > their new distro. I'm not aware of any other distro that would make > forking or spinning off _this_ easy. That could turn into renewed > interest in Gentoo or possibly even better inter-distro relations, > since bugs would be going to the correct places. That is one of the main goals of the proposal. I feel that Gentoo is missing out on major contributions because it's so difficult for people in other distros to provide the patches they write. Making spins easier is a definite bonus, and results in more contributions. > To OP: This idea looks good to me; do you have any proofs of > concept for use in common places like ebuilds, metadata.xml (if you > intend for it to be used there), etc? If we had a more visual idea > of how it worked, maybe more people would understand and have an > idea of where to put it if it doesn't fit in with PMS's scope. I have some basic stuff that showed this idea was feasible before I sent it on, but I don't have anything public yet. I can start with a branch (as mentioned in thread) and go from there. Best, - --arw - -- A. Wilcox (awilfox) Project Lead, Adélie Linux http://adelielinux.org -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJYROwTAAoJEMspy1GSK50U6ZEP/2fFOOc1TsABI0lMjE8RFbgM Jl6c9GGfQJokCQHTTHVOGyUhtDzRztcj3RSOtC5Xopshhj73kPZ+uLkMAhL5jl+6 hQbC6tTYdu6Jqw6ompvqNuaWONnyYfEY8j/fkkop+8YCKZ12rOXD/LtLwaXUMANr OZP5RDX889q7ZYuel8P7TuyYWK4/F+oVc3T7AOzlPNy68sEAi/L4sGMLupr/geR/ dhPYrC/OSAx2A5zhKfpZCbmm+7fHm0tS3r2SpirTJz2+2fYzbrNbVIE2k5TvMUK3 /dJFzw41W1S8xhebqJoHxslXW5NU6Sj1i7rTMPRHD1jEeuN/nhh29eVt33XIOexi 8G957fie/g5EM3+zcxUCgn+8CSzcCmfgAwUA4MmXgMhqBibk9ZXt7ZlA85WjCQFP fojVOCgWaNJn9RZjIL9V3UiN4Qjv5kv/m8wjfsH7vwb6DlZ4Kc9NUOVhe2wogNyw W6WOmnOepolhOlmtB8j9fgKRui9aTU9NO6fhSOXqwvTDn0RzHrELsiGUUNFqjvr2 LE74uJcy7qDtVgCHS6ZRV6YMm9V3L2jPmafS3JfOcY9mA7sZHqR9cW1EF4wpMIAC eUKDRAG6SwyshZzDJL7V2RmQt64M51diujOQn5M12U8ByQhA5aFnpddIBo+Vbk01 Vg2w69y3HcV4HLU5/2zC =g8bj -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: Proposal for addition of distribution variables
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/12/16 20:58, Mike Gilbert wrote: > On Sun, Dec 4, 2016 at 6:31 PM, A. Wilcox > wrote: >> 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. > > It's not clear to me why this should be defined in PMS, especially > if this is going to be a profile variable in make.defaults. > > I think we would only need to add it to PMS if you need to package > manager to compute the value based on the running system. Is that > what you had in mind here? If so, you will need to include that > algorithm in your patch. > Thinking on it a little more, that wouldn't be a good way to go. We can't really rely on lsb_release being present, especially if Portage is being run on FreeBSD or a more exotic prefix; sys-apps/lsb-release isn't even installed on my relatively 'normal' amd64 Gentoo Linux machine. Additionally, it wouldn't have the bug URL even if it were present. We can therefore strike the PMS bits and the patch from the proposal. If there are no other objections to this proposal, would a PR that implements this against the Gentoo tree be the best way forward? If so, I can start work on that now while giving more people the chance to read over it. (Would it be more desirable to have all changes in a single large commit, or one commit per package?) Best, - --arw - -- A. Wilcox (awilfox) Project Lead, Adélie Linux http://adelielinux.org -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJYRNtLAAoJEMspy1GSK50UyUAQAJy7whGkLxhjnUR04hT/k0uY B69MCu3do0TqlAYkpQU/DiCuseeD0UUpXwcUS30RGVUBd6gKsq9vTzAMhvVFEqVM 9wZ+4Gs2yWkMbQ9tOy8rK29fW7M7M4yLcZet6q+7UyieaxFqgpbxGBOZzZC7mlKj RKDFZdVrE9gMv+zPvKT/MZtYHJouwHcnOC8DD5HN7hvq6HQ5fRdvpd2pIoAKIw9U d+s8/rIPi2xnFetrF1A3qndHyGhRGqqhXdmff7PIAlZoimVRMXL3jyV+f/W0crDs J5sq3uzcwqa5Q5ZU9fvRdHGeBVLJQeoej6vtN5uBKinHT9zlCaiJ8kTAt+N7kjz/ QahHh4vrsotBT70/IIIXNRaX5UFoIA9HWQEb84HJROcqj1qodvd3oIoZk18e4HIK mg+1v0lKuBF9HLPYHjwqUMEgoiMlikCHcTqVUqNsyPRSNnTMz3aPISUwaGVIkVBQ sQVllCOBEfKp2THbg3OrZfoMpp8nXlJMZBwhElDFUK8leDth8riB4WRw2pdJQYlT nR1WMimCoUwKxMvsl9RA2O/oix7dmZiAzui3Fe7eoqxVkvL9jWlPXYi0f9acrJmz uwq4Q/k5bt8WwI9uUlxe5SqR6LTUG0tVfZYk7RB7qZD+yPwwrXA0VLZ8PVm/yJ7j Qxm6u41m9Ru67XBk49a3 =507s -END PGP SIGNATURE-
[gentoo-dev] RFC: Proposal for addition of distribution variables
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
===
Proposal for addition of distribution variables
===
:Author:
A. Wilcox (Adélie Linux)
:Date:
2016-12-04
:Status:
Request for Comment
Introduction
-
This proposal outlines the addition of environment variables to a
future EAPI for the purposes of identifying the builder of packages,
and a route for their more immediate addition to the Gentoo package
tree before the next EAPI is published.
Background
- --
The Gentoo package repository is used not only by thousands of users,
but also used by other distributions and organisations, such as
Funtoo, CoreOS, and Google ChromeOS. From the Gentoo Foundation's own
charter, it self-describes in the following way: "Gentoo is a
metadistribution". That allows users to make their own flavours of
Gentoo themselves. Several forks already exist, including Exherbo,
Funtoo, Sabayon, Galapagos, Vida, and Calculate. Google also
maintains a fork, ChromeOS, for their Chromebook laptops. CoreOS also
uses Gentoo's repository for their distribution. In addition, there
are also binary distributions such as Pentoo and Adélie that provide
additional value but are not, in so many words, a 'fork' of Gentoo.
Current Situation
- -
Currently, forks and derivatives of Gentoo are required to choose one
of only two options. They can either use the tree as is, which causes
packages to identify as being built for Gentoo and causes most
autoconf -based packages (and some CMake packages in KDE) to have
their bug report URLs to point to bugs.g.o. Alternatively, they can
fork the Git repository, requiring the need of manual merges when
conflicts arise, and additional wasted effort when upstreams release
new versions of software.
Deficiencies
-
If a fork or derivative of Gentoo does not have the manpower or
resources to modify all ebuilds that mention the Gentoo name / bug URL
(about 1500 at my last count), then both distributions suffer. Users
of the fork will file bugs with Gentoo that are not bugs in Gentoo.
Developers of the fork will not know about said bugs, and be unable to
fix them. Gentoo bug-wranglers and devs will have to waste time and
resources testing bugs, finding out they are not even Gentoo bugs, and
closing them as WONTFIX or WORKSFORME.
If they choose the alternative of forking the repository and changing
these parameters in ebuilds, then it makes upstreaming their
improvements much more difficult. Sabayon has a repository on GitHub
specifically for this, and Adélie wastes continual effort applying
patches against the tree as it evolves.
Solution Objectives
- ---
* Protect Gentoo's name, trademark, and reputation by avoiding any
appearance that derivative distributions are associated with Gentoo.
* Lessen number of inappropriate bugs filed on bugs.g.o due to forks and
derivatives.
* Foster better collaboration and sharing of improvements between
Gentoo and its forks/derivatives.
* Future potential changes to the bug report URL, while exceedingly
unlikely, is additionally made easier.
Solution Vision
- ---
I hereby propose adding the following two variables to the src_*
phases. None of these variables will have a default specified in PMS
if they are added.
:``${DISTRO}``:
The name of the distribution. This would be set in
``profiles/base/make.defaults`` on Gentoo to "Gentoo".
:``${DISTRO_BUG_URL}``:
The URL to use to report bugs with software on the distribution.
This would be set to "https://bugs.gentoo.org/"; on Gentoo.
By replacing references to 'Gentoo' passed to ./configure, make, etc
with ``${DISTRO}``, distributions like Sabayon, Calculate, and Adélie
will be able to notate their name as the distributor on packages.
This will affect packages such as LibreOffice, OpenRC, X.Org, and KDE,
which are all compiled with the name of the distribution internally.
They use this for bug information, and having the proper distribution
name will allow for more proper bug handling and ensure less
inappropriate blame is assigned to Gentoo. This also ensures that the
fork or derivative's own mailing lists, forums, and so on are searched
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 th
