Re: [gentoo-dev] RFC: Setting default HOME_MODE in /etc/login.defs
Hi, the upstream PR was closed, this was the answer: > No - distros like debian may get caught off guard. There's nothing wrong with > downstreams patching their values in their deltas. We do not lightly make > changes which change defaults. https://github.com/shadow-maint/shadow/pull/946#issuecomment-1939667729 Have a nice day, Daniel Il giorno lun 12 feb 2024 alle ore 21:16 Michael Vetter ha scritto: > > Hello, > > In case this mail is weirdly formatted please let me know. And if yes, > please excuse me in advance.. > > On 2/11/24 11:10, Sam James wrote: > > Daniel Simionato writes: > > > >> Hello, > >> I'd like to start a discussion regarding setting HOME_MODE by default in > >> the /etc/login.defs file (owned by > >> sys-apps/shadow package). > >> > >> Upstream keeps HOME_MODE commented: > >> https://github.com/shadow-maint/shadow/blob/3e59e9613ec40c51c19c7bb5c28468e33a4529d5/etc/login.defs#L207 > >> > >> HOME_MODE affects only useradd and newuser commands: if HOME_MODE is set, > >> they will use the specified permission when > >> creating a user home directory, otherwise the default UMASK will be used. > >> Since the default umask is 022, keeping HOME_MODE unset will result in > >> home readable home directories created by useradd, > >> which goes against security best practices. > >> > >> The proposal is to set HOME_MODE to 0700, or at least 0750: RedHat and RH > >> based distros, OpenSuse, ArchLinux all set it > >> to 0700, Ubuntu has it at 0750. Debian and Gentoo are two exceptions, > >> keeping the upstream value of HOME_MODE (although > >> login.defs is changed in other ways). > >> > >> I previously made a PR on github where you can find more details > >> (https://github.com/gentoo/gentoo/pull/35231), but as > >> pointed in the comments this probably warrants some discussion beforehand. > >> > >> I can understand the argument against the change, which is keeping in sync > >> with upstream and don't risk changing the > >> historic default behaviour of tools some users might rely upon. > >> > >> I do believe though there's merit in providing safer and secure defaults, > >> so I would like HOME_MODE to have a safe > >> default value for Gentoo and Gentoo based distros. > > I'm in favour, although I'd be curious as to why upstream shadow don't > > just set it. It would be interesting to see if the discussion already > > happened there at some point (surely it has?) and find out their > > reasoning. (But that's not a blocker for proceeding.) > > > > I want to hear more opinions first though. Thanks for raising this, > > it's been in the back of my head. > > > I 'm in favour as well. And in openSUSE we did this as well. > > Honestly I don't remember any upstream discussion about this and have no > idea what it was done this way. > > I see Daniel already created > https://github.com/shadow-maint/shadow/pull/946 for upstream yesterday. > > > Best, > > Michael > >
Re: [gentoo-dev] RFC: Setting default HOME_MODE in /etc/login.defs
The only previous upstream discussion I was able to find was this on the pkg-shadow-devel: https://marc.info/?l=pkg-shadow-devel&m=167120074926229&w=2( (I don't think the unprivileged container limitation still applies, or at least it doesn't on my user with a 700 /home) I can see the argument for keeping the status quo, but I still think it's better to err on the side of caution with default settings. But I understand that my point of view might be skewed by personal preference or by professional experience, so I appreciate the everyone contributing their opinion. I have opened a PR upstream to start discussion there https://github.com/shadow-maint/shadow/pull/946 . For reference, the concrete use case that put me onto this ( https://github.com/flatcar/Flatcar/issues/1353): provisioning users in Flatcar through ignition (cloud-init like) at first boot time, even if in the same config /etc/login.defs is changed, results in 755 home directories. Some more comments in this PR https://github.com/kubernetes-sigs/image-builder/pull/1400 The original PR that added HOME_MODE also refers generically to user bug reports due to the many ways umask can be overriden: https://github.com/shadow-maint/shadow/pull/208#issue-546914572 Thanks, Daniel Il giorno dom 11 feb 2024 alle ore 11:53 Eray Aslan ha scritto: > On Sun, Feb 11, 2024 at 10:10:13AM +, Sam James wrote: > > I'm in favour, although I'd be curious as to why upstream shadow don't > > just set it. It would be interesting to see if the discussion already > > happened there at some point (surely it has?) and find out their > > reasoning. (But that's not a blocker for proceeding.) > > I believe it is for historical reasons. Computer networks and terminals > used to be much friendlier places. > > > I want to hear more opinions first though. Thanks for raising this, > > it's been in the back of my head. > > Even though I do not really care either way, what problem exactly are we > trying to solve? Better security is just too vague an argument. I can > see the argument if we were selling to business (*cough*red hat*cough*) > but on the other hand, an argument can also be made for keeping to the > roots of computer networks and their naivete (keep information free and > all that stuff). In this regard, it is telling that only debian and > gentoo keep 022. > > Consider taking it upstream as someone else (ulm?) already mentioned in > the discussion. > > Thanks > -- > Eray > >
[gentoo-dev] RFC: Setting default HOME_MODE in /etc/login.defs
Hello, I'd like to start a discussion regarding setting HOME_MODE by default in the /etc/login.defs file (owned by sys-apps/shadow package). Upstream keeps HOME_MODE commented: https://github.com/shadow-maint/shadow/blob/3e59e9613ec40c51c19c7bb5c28468e33a4529d5/etc/login.defs#L207 HOME_MODE affects only useradd and newuser commands: if HOME_MODE is set, they will use the specified permission when creating a user home directory, otherwise the default UMASK will be used. Since the default umask is 022, keeping HOME_MODE unset will result in home readable home directories created by useradd, which goes against security best practices. The proposal is to set HOME_MODE to 0700, or at least 0750: RedHat and RH based distros, OpenSuse, ArchLinux all set it to 0700, Ubuntu has it at 0750. Debian and Gentoo are two exceptions, keeping the upstream value of HOME_MODE (although login.defs is changed in other ways). I previously made a PR on github where you can find more details ( https://github.com/gentoo/gentoo/pull/35231), but as pointed in the comments this probably warrants some discussion beforehand. I can understand the argument against the change, which is keeping in sync with upstream and don't risk changing the historic default behaviour of tools some users might rely upon. I do believe though there's merit in providing safer and secure defaults, so I would like HOME_MODE to have a safe default value for Gentoo and Gentoo based distros. Have a nice day, Daniel
[gentoo-dev] Announcement: PFL is looking for a new maintainer
Hello All! I am posting this here (gentoo-dev, gentoo-user) at the request of the upstream maintainer to reach a larger audience. PFL upstream will stop working on the project and is looking for a new maintainer. For those who don't know what PFL is. It is basically a database that allows users to search for packages that provide a file. Say you want to run a command/program, but you don't know which package provides it. This is where PFL can help. The database itself is populated by users. When you install app-app-portage/pfl [1], there's a script that sends a list of installed packages and their contents to the server. A second script is used to query for packages that owe a file. There is also a web interface [2] which provides similar functionality. I believe a similar feature is also available for Ubuntu (maybe other distributions too, not sure if this is Ubuntu specific). If you type a command on the command line that is not available, you get suggestions for packages that contain the program. I now see two possibilities. Either another user takes over the project or Gentoo itself takes over the maintenance. But someone has to do the work and further maintenance. Otherwise the project will be terminated. If you are interested or have something to share, please join the discussion in the forum [3] to keep everything in one central place. Thanks! [1] https://packages.gentoo.org/packages/app-portage/pfl [2] https://portagefilelist.de/ [3] https://forums.gentoo.org/viewtopic-t-1163382.html -- Best Regards Daniel
Re: [gentoo-dev] Last rites: sys-cluster/slurm
On 8/15/22 09:48, David Palao wrote: Oh! That's a pity! I need that package... Is there anything I can do to keep using slurm with my gentoo box? Best I just added an updated ebuild in my junkdrawer overlay. I would be willing to proxy maintain the package in gentoo. -- Daniel M. Weeks
Re: [gentoo-dev] [PATCH 0/4] Eclass for single-impl Lua ebuilds
Marek Szuba schrieb am 01.10.20 um 22:24: > On 2020-10-01 20:31, Daniel Pielmeier wrote: > >> I already had slotted lua 5.1 and 5.3 installed and the modified ebuild >> built fine with lua-5.3 as before. However when I tried setting >> LUA_SINGLE_TARGET="lua5-2", lua-5.2 was pulled in as a dependency but >> conky still built against lua-5.3. The temporary pkg-config environment >> was set correct but somehow it seems not used. Conky uses cmake and >> pkg_search_module [1] to detect lua preferring 5.3 over 5.2. >> >> Am I doing something wrong using the eclass or is there an issue with >> the lua detection in conky or maybe the the eclass? > > I noticed the same thing while adapting x11-wm/awesome, it's caused by > how the CMake module FindLua works. You will have to make sure that > cmake looks for a specific version. > Thanks Marek! Probably the easiest solution is to pin it to 5.3 then. -- Best Regards Daniel
Re: [gentoo-dev] [PATCH 0/4] Eclass for single-impl Lua ebuilds
Marek Szuba schrieb am 30.09.20 um 18:23:
> Same as lua.eclass and python-r1, this is a Lua version of
> python-single-r1. Setting LUA_SINGLE_TARGETS allows one to choose the
> (slotted) Lua implementation to build your ebuild against, optionally
> including both single- and multi-implementation Lua packages as
> dependencies.
>
Hello Marek!
First of all thank you very much for your work on the eclasses
supporting slotted lua. It is very much appreciated.
As I am not really capable of doing a review I took your eclasses and
tried to use it for app-admin/conky (using lua-single) where new
versions already need at least lua-5.2. See the changes below.
I already had slotted lua 5.1 and 5.3 installed and the modified ebuild
built fine with lua-5.3 as before. However when I tried setting
LUA_SINGLE_TARGET="lua5-2", lua-5.2 was pulled in as a dependency but
conky still built against lua-5.3. The temporary pkg-config environment
was set correct but somehow it seems not used. Conky uses cmake and
pkg_search_module [1] to detect lua preferring 5.3 over 5.2.
Am I doing something wrong using the eclass or is there an issue with
the lua detection in conky or maybe the the eclass?
[1]
https://github.com/brndnmtthws/conky/blob/master/cmake/ConkyPlatformChecks.cmake
--- conky-1.11.6.ebuild 2020-09-21 12:32:10.180949870 +0200
+++ conky-1.11.6-r1.ebuild 2020-10-01 00:04:13.099147223 +0200
@@ -3,7 +3,9 @@
EAPI=7
-inherit cmake linux-info readme.gentoo-r1 xdg
+LUA_COMPAT=( lua5-{2..3} )
+
+inherit cmake linux-info lua-single readme.gentoo-r1 xdg
DESCRIPTION="An advanced, highly configurable system monitor for X"
HOMEPAGE="https://github.com/brndnmtthws/conky";
@@ -45,7 +47,7 @@
weather-metar? ( net-misc/curl )
webserver? ( net-libs/libmicrohttpd )
xmms2? ( media-sound/xmms2 )
- || ( dev-lang/lua:5.3 dev-lang/lua:5.2 )
+ ${LUA_DEPS}
"
RDEPEND="
${COMMON_DEPEND}
@@ -85,6 +87,8 @@
pkg_setup() {
use ipv6 && linux-info_pkg_setup
+
+ lua-single_pkg_setup
}
src_prepare() {
--
--
Daniel Pielmeier
Re: [gentoo-dev] RFC: packages.g.o: new features available
Am July 8, 2020 2:57:57 AM UTC schrieb Max Magorsch : >Hi all, > >I am glad to announce further progress at packages.gentoo.org (pgo in >the following). Compared to previous work during the last months, >which mostly addressed the back end, the new changes are rather >comprehensive. That's why I am looking forward to feedback here. > >So the tl;dr is that the new pgo version now displays: > - dependencies > - reverse dependencies > - pkgcheck results > - repology.org data > - github pull requests > - stabilization bugs > - keywording bugs > - security bugs > - general bugs >for each package. > >Additionally, there are new sites for all package maintainers, that is: > - Gentoo Projects (e.g. pyt...@gentoo.org) > - Gentoo Developers (e.g. la...@gentoo.org > - Proxied Maintainers (e.g. la...@the-cow.de) > >The maintainer's sites contain: > - all packages of the maintainer > - all outdated packages (according to repology) > - all related pull requests > - all related bugs (general, keywording and stabilization) > - all security bugs > - the changelog of all maintained packages >You will find the new sites under the 'Maintainers' tab. > >The overall appearance of the site has also slightly changed to >display all of the new information. > >Currently, the new version is deployed to: > > https://packagestest.gentoo.org/ > >Everyone is welcome to take a look around and tell me whether you >consider the new information as useful for your workflow and/or what >you would still change. > >I'm looking forward to your feedback. > >-M Hey Max! Thank you very much for your work on p.g.o. I really like it, especially all this nice information for package maintainers. One thing I noticed when searching for the packages of a certain maintainer. It always lists some packages first which are not related to that maintainer. I tried a few different searches and this seems to happen all the time. Probably it is due @gentoo.org as all the unrelated packages contain gentoo in their names. However this differs from search to search. Ignoring this false positives the actual matching results seem complete. Omitting the domain also does not work and only lists unrelated packages in my case. When navigating to the maintained packages using the maintainer tab the list is correct. Just want to let you know and thanks again! -- Best regards Daniel
Re: [gentoo-dev] speeding up usage of portage in e-file / portage file list
Sending from the proper address so this mail also reaches the list! Daniel Buschke schrieb am 24.05.20 um 18:40: > Oh dear! I readded the database index for file names. Now the data query > takes ~0.3 seconds *insert self slapping image here* Good to hear! Now it's way quicker! > Anyway, for some strange reason I cannot reproduce the slothy behaviour > of portage, too. I'm 100% sure the bash version took 1 second while the > python version took 3 seconds. Strange. Me too. The bash version queries another URL than the python version. Could this make a difference? However as of today it does not seem so! > @Zac: Did you add some performance optimizations in the last 30 days? > Maybe Caching? No? Then you fixed this by pure imagination :) Don't think so, as it was the bash version that became slower :-) -- Best Regards Daniel signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] speeding up usage of portage in e-file / portage file list
Am 24.05.2020 um 14:10 schrieb Daniel Pielmeier: Here the bash version takes around 2.9 seconds while the python version takes 3.2 seconds. Excluding the portage API it takes 2.8 seconds and also excluding the data query it takes 0.3 seconds. So in the python version the data query takes 2.5 seconds (probably this is similar for the bash version) while all the rest takes 0.7 seconds My initial tests showed that the bash version is a lot quicker than the python version. Somehow I can not reproduce this any more. As mentioned previously the data query is the most time consuming part in both the bash and the python version. Oh dear! I readded the database index for file names. Now the data query takes ~0.3 seconds *insert self slapping image here* Anyway, for some strange reason I cannot reproduce the slothy behaviour of portage, too. I'm 100% sure the bash version took 1 second while the python version took 3 seconds. Strange. @Zac: Did you add some performance optimizations in the last 30 days? Maybe Caching? No? Then you fixed this by pure imagination :) I will try again later. But currently I broke my system and am unable to install termcolor 'cause of some python3_7 vs python3_6 f*%§up
Re: [gentoo-dev] speeding up usage of portage in e-file / portage file list
Daniel Buschke schrieb am 24.05.20 um 00:05: > Am 23.05.2020 um 23:46 schrieb Daniel Pielmeier: >> Hm correct me if I am wrong, but from looking at the patch Zac >> provided I think he meant that the time portage consumes is only one >> second while the "rest" is 3.2 seconds. So there is probably a >> potential in improving the "rest" somehow. > > Yes and no. The difference between the python and bash version is > roughly 2 seconds. One second for importing portage (which Zac patched > away) and another second for the rest of the portage stuff. So using the > portage API adds two additional seconds. > > The python version needs 3.2 seconds on my system. As said the portage > API (or better calling the portage API) consumes ~2 seconds. As this is > the most time intense part the question is if there is a way to optimize > this. > I did run some tests comparing the run time of the bash version, the python version, the python version excluding the portage API and the python version excluding the portage API AND the data query. I run all the commands multiple times for multiple search strings (dropping caches in between) and compared the average times excluding min/max values to account for network hiccups. Here the bash version takes around 2.9 seconds while the python version takes 3.2 seconds. Excluding the portage API it takes 2.8 seconds and also excluding the data query it takes 0.3 seconds. So in the python version the data query takes 2.5 seconds (probably this is similar for the bash version) while all the rest takes 0.7 seconds My initial tests showed that the bash version is a lot quicker than the python version. Somehow I can not reproduce this any more. As mentioned previously the data query is the most time consuming part in both the bash and the python version. So I think the python version can compete with the bash version and it should be okay to switch to it in upcoming pfl releases. -- Best Regards Daniel P :-) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] speeding up usage of portage in e-file / portage file list
Am 23.05.2020 um 23:46 schrieb Daniel Pielmeier: Hm correct me if I am wrong, but from looking at the patch Zac provided I think he meant that the time portage consumes is only one second while the "rest" is 3.2 seconds. So there is probably a potential in improving the "rest" somehow. Yes and no. The difference between the python and bash version is roughly 2 seconds. One second for importing portage (which Zac patched away) and another second for the rest of the portage stuff. So using the portage API adds two additional seconds. The python version needs 3.2 seconds on my system. As said the portage API (or better calling the portage API) consumes ~2 seconds. As this is the most time intense part the question is if there is a way to optimize this. Hope this is more clearly. I had fun anyway :) regards Daniel
Re: [gentoo-dev] speeding up usage of portage in e-file / portage file list
Am May 23, 2020 9:17:46 PM UTC schrieb Daniel Buschke : >Am 23.05.2020 um 22:55 schrieb Zac Medico: >> Since the portage API only added about 1 second to the python script >> time, I guess it's on par with your bash implementation. ;-P > >Yeah, if you substract the second for loading and the second for doing >queries, then yes, it's pretty par with the bash implementation :D Hm correct me if I am wrong, but from looking at the patch Zac provided I think he meant that the time portage consumes is only one second while the "rest" is 3.2 seconds. So there is probably a potential in improving the "rest" somehow. You see he exits after line 35 and until that not a lot happens besides all other imports, the argument parsing and the querying of the data. -- Best regards Daniel
Re: [gentoo-dev] speeding up usage of portage in e-file / portage file list
Am 23.05.2020 um 22:55 schrieb Zac Medico: Since the portage API only added about 1 second to the python script time, I guess it's on par with your bash implementation. ;-P Yeah, if you substract the second for loading and the second for doing queries, then yes, it's pretty par with the bash implementation :D Let me answer this with a meme ;) https://damage.devloop.de/zac_makes_runtime_equal.jpg Thanks Daniel
Re: [gentoo-dev] [RFC] Ideas for gentoostats implementation
Am May 5, 2020 7:31:34 PM UTC schrieb "Toralf Förster" : >On 4/26/20 10:08 AM, Michał Górny wrote: >> I don't think we really want to try to investigate >> which files are actually used but focus on what's installed. >Hi, > >I do wonder if the http://www.portagefilelist.de/site/start (package >app-portage/pfl) would be part of that or not? >The maintainer of the pfl stopped the import of new data last year due >to lack fo time to maintain that project and is looking for a >usccessor. Actually the maintainer decided to continue the project. The code is now hosted at Github [1]. The site moved to a new server and the upload is working again. [1] https://github.com/portagefilelist -- Best regards Daniel
[gentoo-dev] Last rites: media-sound/puddletag
# Daniel Pielmeier (8 June 2018) # Does not support PyQt5 as well as python 3. Upstream unresponsive. # Masked for removal in 30 days. Bug #649112. media-sound/puddletag -- Daniel Pielmeier
[gentoo-dev] Packages up for grabs
The following packages are in need of a maintainer: dev-util/astyle net-im/toxic x11-misc/alock x11-misc/ktsuss x11-misc/spacefm -- Daniel Campbell OpenPGP Fingerprint: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 Found on hkp://keys.gnupg.net and other keyservers signature.asc Description: Digital signature
Re: That's all folks. (Re: OT Re: [gentoo-dev] Re: [gentoo-project] [RFC] Splitting developer-oriented and expert user mailing lists)
On Sat, Dec 09, 2017 at 08:13:18PM -0500, Rich Freeman wrote: > On Sat, Dec 9, 2017 at 7:29 PM, Daniel Campbell wrote: > > > > Other developers are required to subscribe to -dev, and are > > expected to follow it so they stay informed. > > Developers are not required to subscribe to -dev. > > > If they missed something covered on the list, they are directed to the > > archives and (usually) laughed at. > > Correct. While nobody is required to follow the lists, acting out of > ignorance usually doesn't impress others. Devs are expected to be > adults and figure out what they need to follow based on what they > intend to contribute to. -core and -dev-announce are the only > required subscriptions. > > > > > Great things coming from Gentoo "leadership" here. What will you do when > > mgorny starts targeting developers and pitching tantrums over them, too? > > You act as if this was the only reason that comrel took action. In > the cases of appeals I've seen I've yet to see a case where there > wasn't something else going on behind the scene that wasn't reasonably > severe when they've taken action. I can't vouch for their reasons in > this case as I'm not privy to them, and I imagine they're not going to > be made public. Well, let's consider the order of events here: 1. wltjr and others appear on the ML 2. Drama 3. mgorny suggests some change in structure to avoid dealing with said people. 4. more drama 5. mgorny publicly insults comrel, accusing them of doing nothing 6. mgorny publishes formal plan to reform our mailing lists 7. more drama 8. comrel bans wltjr 9. mgorny's plan is put on Council agenda 10. comrel *mails to let everyone know wltjr was banned*, despite prior claims of valuing privacy and secrecy 11. you are here This looks awfully clear to me. I'm pointing out behavior that looks a lot like one person twisting the social structure to suit their desires. This concerns me because our community will be damaged by his plan, and it is only the first step. In the second step, he will turn against developers as well. But not you and his other buddies. Just the ones *he* thinks are a problem. > > > This is precisely why we have unmotivated developers > > and a bevy of unmaintained packages; nobody wants to contribute to a > > distro that treats its users (and developers) so poorly. > > Go ahead and cite the list of people who have been banned in the last > decade. You won't run out of fingers on one hand. Some might cry > about it for months, but good luck finding another distro that hasn't > banned twice as many in the same span of years. > > And keep in mind that failing to take action isn't without > consequences. When somebody is harassing somebody else (and sometimes > more than one other) you don't really get a choice about whether > somebody is going to end up leaving, whether of their own accord or > not. That is a situation I've seen happen more than once around here > behind the scenes. Again, I have no specific knowledge about this > particular comrel action - I'm talking about situations I've seen in > the past. I'm not focused on the ban, or whether it was deserved. That's a separate subject. I'm pointing out behaviors that damage our image, our credibility, and morale. I'm calling out unequal enforcement and favoritism; these are things that you won't find in any records, because the existence of such records would damn those culpable. The fact that comrel has never acted against mgorny strongly indicates that they do not care about the way he treats others. He is kept because of his technical skill. Others do not get this convenience; we are accountable for the code *and* the words that we write. You're blind if you don't see this. > > > A distro should never bend its entire social structure to protect the > > feelings of one surly developer (or his/her entourage), > > Certainly, and that works both ways. > > > but naturally > > since every council member is friends with mgorny and comrel is afraid > > to take any action against him, they'll make exceptions to established > > procedures and ignore any complaints about the way he treats others. > > Considering that he won a significantly contested election to Council, > I suspect that more people around here approve of mgorny than just the > members of the council. And I can certainly vouch that not all > council members are necessarily fans of some of his actions, though I > suspect that his technical contributions are praised by just about all > (rightly, IMO). > > I've yet to see a discussion between Council me
Re: That's all folks. (Re: OT Re: [gentoo-dev] Re: [gentoo-project] [RFC] Splitting developer-oriented and expert user mailing lists)
On Fri, Dec 08, 2017 at 09:22:32PM +0100, Andreas K. Huettel wrote: > Am Donnerstag, 7. Dezember 2017, 19:06:36 CET schrieb William L. Thomson Jr.: > > > > The day everyone wanted has come, after this message. I will > > unsubscribe not to return. You all won in 2008, and again in 2017. > > Though this time I will not be back. I tried more than most anyone else > > would for a very long time. Gentoo wins I lose, I am fine with that. > > > > Please do not contact me off list in IRC or at all. I am done with the > > Gentoo community! > > > Independent of whether William now unsubscribed or not, he's now enjoying a > lengthy (1 year until review) vacation from all Gentoo communication channels. > > > -- > Andreas K. Hüttel > dilfri...@gentoo.org > Gentoo Linux developer (council, perl, libreoffice) So, mgorny threatened to leave if something wasn't done, right? I saw the IRC conversation about unsubscribing from gentoo-dev, as well. IRC is not private, for the record. Other developers are required to subscribe to -dev, and are expected to follow it so they stay informed. If they missed something covered on the list, they are directed to the archives and (usually) laughed at. I see no reason for this expectation to be waived for any single developer. Do I get a free pass if I don't like what someone says? It's not enough to let wltjr leave on his own; you had to create a ban and add a smug, tongue-in-cheek mail to it to maintain the image of doing something. Quite hypocritical of comrel's attitude of secrecy to suddenly announce a ban. It seems to me that secrecy is only adopted when it suits those who stand to benefit from it. Great things coming from Gentoo "leadership" here. What will you do when mgorny starts targeting developers and pitching tantrums over them, too? Are we going to stratify developership further, too? It seems rather clear to me that a few individuals see themselves as the owners of this distro and bend it to suit their whims, using bureacracy to obscure their actions and motivations, segment the community, and block those less experienced. This is precisely why we have unmotivated developers and a bevy of unmaintained packages; nobody wants to contribute to a distro that treats its users (and developers) so poorly. A distro should never bend its entire social structure to protect the feelings of one surly developer (or his/her entourage), but naturally since every council member is friends with mgorny and comrel is afraid to take any action against him, they'll make exceptions to established procedures and ignore any complaints about the way he treats others. Software cannot fix wetware. Plenty of developers get to deal with mgorny's aggressive and insulting tone, yet nothing happens. Gee... I wonder why. Maybe because the upper parts of Gentoo are riddled with cronyism. "Rules for thee, not for me." It's clear to anyone with eyeballs that there is preferential treatment and inconsistent enforcement of rules in this community, and the people in a position to fix it, won't, because they in fact benefit from this. Unfortunately, GLEP 39 does not have a section on recalling or impeachment... This whole situation highlights why the Council has no business sticking its head into non-technical matters. It's clearly not up to the task. It's no surprise, since technical skill does not guarantee or even imply social skill. (or vice-versa) I'm tired of people beating around the bush and the facile attempts of tact: why do you give special treatment to certain members of this community? Would you have done anything different if it were me or some other developer who was proposing this change? It wouldn't have made it to the Council agenda if he didn't write it, period. Everyone else would've been told to suck it up and deal with it. And knowing how the Council is, in a few days we'll all get to deal with the churn of mailing lists to protect one person's ego. Sad. ~zlg -- Daniel Campbell - Gentoo Developer, Trustee, Treasurer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: Digital signature
Re: [gentoo-dev] [RFC] Splitting developer-oriented and expert user mailing lists
On Tue, Dec 05, 2017 at 08:59:40AM +, Peter Stuge wrote: > Daniel Campbell wrote: > > On Sun, Dec 03, 2017 at 12:18:04AM +0100, Michał Górny wrote: > > > I'd like to establish the following changes to the mailing lists: > > > > > > 1. Posting to gentoo-dev@ and gentoo-project@ mailing lists will be > > > initially restricted to active Gentoo developers. > > > > I don't think this plan will have the effect you're going for, > > I agree, and I'll double down on my previous comment on this proposal: > > I consider the proposal to be the wrong solution. > > > > but let's be honest here: the "RFC" is just a formality; the decision's > > already been made. > > I hope that a mere proposal doesn't automatically mean policy change. > If proposals come from a select couple of people, there are high odds that it's been discussed privately and the relevant people've been convinced or otherwise pushed to implement the change. By the time it hits the list, any cricitism is met with "too bad, we're doing it anyway". I'm not sure how new you are to Gentoo, but it's been this way since at least 2012. > > > If the "real leaders" of Gentoo want to divide and fragment the > > community, it's their prerogative. > > When there is a request for comments, there should also be comments. :) > > Far too many fall into the simple trap that is tribalism, and I'd like > to encourage everyone on this list to not be that kind of person, > because there really is no "us and them", there is only "us". > I think the plan to split mailing lists serves as a way to insulate developers from the effects of their decisions. Anyone with an incongenial tone will have their voice bit revoked and their mail will be dropped or rejected. It will likely be a silent rejection, so the fallout is minimal. The plan itself is a manifestation of tribalism. The "us" is a select group of people who've been blessed by mgorny and friends. Everyone else is deemed a "do nothing" or some other insult, regardless of their history or efforts with the distribution. Yes, talking about that is ugly, but it's the truth. I've been on the receiving end of it multiple times and have been witness to it many others. It shows up in just about every corner of Gentoo. Creating a technical schism won't fix it. > > > As we tell users who do something they're not supposed to: You get > > to keep the pieces. > > Well, let's see what happens, now that both developers and > non-developers have clearly spoken out *against* this proposal. > I'm not holding my breath on any positive change, but we'll see. It's not like we have a choice in the matter. I guess we'll have to subscribe to yet another mailing list if we want to stay informed. Maybe in a year's time, we'll have gentoo-dev-expert as well, so the Chosen Ones don't have to deal with developers they don't like. This is my last mail in this thread. I've made my points and know they will fall on deaf ears. You're not wrong in your approach; I don't share that faith, is all. So I hope you don't interpret this as me yelling at you. > > Kind regards > > //Peter > -- Daniel Campbell - Gentoo Developer, Trustee, Treasurer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: Digital signature
Re: [gentoo-dev] [RFC] Splitting developer-oriented and expert user mailing lists
However, Infrastructure has replied already that we > can't deploy effective moderation with the current mailing list software > and I'm not aware of anyone willing to undergo all the necessary work to > change that. > > Even if we were able to overcome that and be able to find a good > moderation team that can effectively and fairly moderate e-mails without > causing huge delays, moderation has a number of own problems: > > α) the delays will make discussions more cumbersome, and render posting > confusing to users, > > β) they will implicitly cause some overlap of replies (e.g. when N > different people answer the same question because they don't see earlier > replies until they're past moderation), > > γ) the problem will be solved only partially -- what if a reply contains > both valuable info and personal attack? > > > Seeing that no other effort so far has succeeded in solving the problem, > splitting the mailing lists seems the best solution so far. Most > notably: > > а. Developer mailing lists are restored to their original purpose. > > б. It is 'fair'. Unlike with disciplinary actions, there is no judgment > problem, just a clear split between 'developers' and 'non-developers'. > > в. 'Expert users' are still provided with a mailing list where they can > discuss Gentoo without being pushed down into 'user support' channels. > > г. Active contributors (in particular recruits) can still obtain posting > access to the mailing lists, much like they do obtain it to #gentoo-dev > right now. However, if they start misbehaving we can just remove that > without the risk of evasion. > > -- > Best regards, > Michał Górny > > I don't think this plan will have the effect you're going for, but let's be honest here: the "RFC" is just a formality; the decision's already been made. If the "real leaders" of Gentoo want to divide and fragment the community, it's their prerogative. As we tell users who do something they're not supposed to: You get to keep the pieces. ~zlg -- Daniel Campbell - Gentoo Developer, Trustee, Treasurer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: Digital signature
Re: [gentoo-dev] NEWS item for games destabling
On Mon, Nov 20, 2017 at 11:36:33AM +0100, Róbert Čerňanský wrote: > On Mon, 20 Nov 2017 10:26:29 +0100 > David Seifert wrote: > > > Round 2 (with correct whitespace this time): > > > > Title: No stable KEYWORDS for Gentoo Games > > Author: David Seifert > > Content-Type: text/plain > > Posted: 2017-11-20 > > Revision: 1 > > News-Item-Format: 1.0 > > Display-If-Keyword: amd64 x86 > > > > As the Games team does not have enough manpower to keep tabs on all > > games packages, we have dropped all ebuilds maintained by the games > > project to unstable KEYWORDS (without those required by other stable > > packages). If you have any of these stable games packages installed, > > you will have to add them to /etc/portage/package.accept_keywords/ > > manually. Failures related to missing stable KEYWORDS will show up as > > > > The following keyword changes are necessary to proceed: > >(see "package.accept_keywords" in the portage(5) man page for more > > details) > > # required by @selected > > # required by @world (argument) > > =games-action/0verkill-0.16-r4 ~amd64 > > > > While we accept that this will cause some irritation for the > > community, pretending we have a well supported games collection by > > having a wealth of stable games packages is misleading at best. We > > welcome contributions from outsiders willing to polish up the games > > landscape in Gentoo via the Proxy Maintainers. > > What does it mean for the future? Should not users bother to test & > write stabilization request bugs for games anymore? Or stabi > requests will still be accepted? > > Robert > > > -- > Róbert Čerňanský > E-mail: ope...@tightmail.com > Jabber: h...@jabber.sk > If I may take a stab at this (correct me if I'm wrong, soap): It only means games are being dropped to ~arch (testing) until other maintainers (proxy or otherwise) step up to make sure the games really are stable. Packages that rarely get attention but are still marked "stable" dilutes the meaning of "stable", especially if you get installation or runtime problems that a proper testing of the package would have caught. This results in bugs that should've been caught in the testing phase, confuses users (and developers), and redundant or obvious bugs being reported. This reads like a "fresh slate" for games, allowing them to start from ~arch and ensure that stabilization procedures are correctly followed by those who step up. While this will create more stabilization bugs, it should, in theory, result in better ebuilds (which makes Gentoo maintenance better/easier) and games that have *actually* been tested. I hope this explanation is both accurate and helpful. ~zlg -- Daniel Campbell - Gentoo Developer, Trustee, Treasurer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: Digital signature
Re: [gentoo-dev] [PATCH] fdo-mime.eclass: Mark the eclass as deprecated
On Mon, Nov 13, 2017 at 03:30:11AM +0100, Jonas Stein wrote: > On 19/06/17 15:20, Michał Górny wrote: > > The GNOME team has committed the xdg-utils.eclass serving exactly > > the same purpose as fdo-mime.eclass, supposedly with the goal of > > replacing it. However, it seems that they have never bothered to > > actually hint the deprecation in the fdo-mime.eclass in any way. > > As a result, developers are still adding references to this eclass > > instead of using xdg-utils or xdg, and/or not working towards replacing > > them. > > > > Add an explicit deprecation notice to the fdo-mime.eclass to make it > > clear that the eclass should not be used in new packages, and what > > the replacement eclasses are. > > Packages and Ebuilds which are still using the fdo-mime are listed here: > > Packages: > https://qa-reports.gentoo.org/output/eclass-usage/fdo-mime.txt > > Ebuilds sorted by Maintainer or Package > http://gentoo.levelnine.at/simplechecks/fdo-mime-check/ > > If you see your name in the list, you find a list of your packages with > inherit fdo-mime. > > Thanks to Michael. For his script. > > -- > Best, > Jonas > Great tool! Super easy for maintainers to check their packages. I have fixes ready for x11-misc/spacefm, but I could not find a bug number to reference. Are we tracking this on bugzy or just pushing everyone to go ahead and update their ebuilds? I searched bugzy for 'fdo-mime' and the only relevant bug is 621914 [1], which I assume was the original discussion to get us onto xdg-utils since it's newer. If there's no tracker bug I need to reference, that's fine. Just wanted to be sure I'm not missing anything before pushing. [1]: https://bugs.gentoo.org/621914 -- Daniel Campbell - Gentoo Developer, Trustee, Treasurer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: Digital signature
Re: [gentoo-dev] [RFC] GLEP 74 post-Council review update
nel
> from a trusted source for comparison.
"a more complete protection"; should probably drop the "a".
>
> Strictly speaking, this information is already provided by the various
> ``metadata/timestamp*`` files that are already present. However,
> including the value in the Manifest itself has a little cost
> and provides the ability to perform the verification stand-alone.
>
> Furthermore, some of the timestamp files are added very late
> in the distribution process, past the Manifest generation phase. Those
> files will most likely receive ``IGNORE`` entries and therefore
> be not suitable to safe use.
Looks like a few extra words in the last sentence. Here's my attempt:
"These files will likely receive ``IGNORE`` entries and therefore be
unsafe to use."
("unsuitable" may replace "unsafe", up to you)
>
> The specification permits additional timestamps in sub-Manifest files
> for local use. A generic testing tool should ignore them.
>
>
> New vs deprecated tags
> --
>
> Out of the four types defined by Manifest2, only one is reused
> and the remaining three is replaced by a single, universal ``DATA``
> type.
"the remaining three is" -> "the remaining three are"
> [snip]
> Injecting ChangeLogs into the checkout
> --
>
> One of the problems considered in the new Manifest format was that
> of injecting historical and autogenerated ChangeLog into the repository.
> Normally we are not including those files to reduce the checkout size.
> However, some users have shown interest in them and Infra is working
> on providing them via an additional rsync module.
"that of" is extraneous here.
The second sentence should read something like "We normally don't
include these files, to reduce checkout size."
>
> [snip]
> Hash algorithms
> ---
>
> While maintaining a consistent supported hash set is important
> for interoperability, it is no good fit for the generic layout of this
> GLEP. Furthermore, it would require updating the GLEP in the future
> every time the used algorithms change.
"it is no good fit" -> "it is not a good fit"
>
> [snip]
> The compression of top-level Manifest file has been prohibited
> as the specification currently does not provide any means of verifying
> the file prior to decompression. This would make it possibly for
> a malicious third party to provide a compressed Manifest exposing
> decompressor vulnerabilities, or being a zip bomb, and the tooling
> would have to unpack it before being able to verify the contents.
The latter half of the paragraph is a little scattered. Here's my
attempt, after the first sentence:
"If the top-level Manifest is compressed, tooling will have to unpack
the file before being able to verify the contents. This makes it
possible for a malicious third party to attack a system by providing a
compressed Manifest that exposes decompressor vulnerabilities, or a zip
bomb."
(Maybe 'zip bomb' should be a link or a footnote, describing what it
is.)
> [snip]
>
> The existence of additional entries for uncompressed Manifest checksums
> was debated. However, plain entries for the uncompressed file would
> be confusing if only compressed file existed, and conflicting if both
"only compressed" -> "only the compressed"
> uncompressed and compressed variants existed. Furthermore, it has been
> pointed out that ``DIST`` entries do not have uncompressed variant
"uncompressed variant" -> "an uncompressed variant"
> either.
>
>
> Performance considerations
> --
>
> Performing a full-tree verification on every sync raises some
> performance concerns for end-user systems. The initial testing has shown
> that a cold-cache verification on a btrfs file system can take up around
> 4 minutes, with the process being mostly I/O bound. On the other hand,
> it can be expected that the verification will be performed directly
> after syncing, taking advantage of warm filesystem cache.
"warm" -> "a warm"
>
> [snip]
> Thanks to all the people whose contributions were invaluable
> to the creation of this GLEP. This includes but is not limited to:
>
> - Robin Hugh Johnson,
> - Ulrich Müller.
>
> Additionally, thanks to Robin Hugh Johnson for the original
> MataManifest GLEP series which served both as inspiration and source
"MataManifest" -> "MetaManifest"
>
> [snip]
>
Aside from the few nitpicks this looks good. Hope this helps.
--
Daniel Campbell - Gentoo Developer, Trustee, Treasurer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6
signature.asc
Description: Digital signature
Re: [gentoo-dev] Providing a `service` scripts that speaks OpenRC and systemd
On 09/29/2017 04:53 AM, Rich Freeman wrote: > On Thu, Sep 28, 2017 at 11:32 PM, Ulrich Mueller wrote: >>>>>>> On Thu, 28 Sep 2017, Austin English wrote: >> >>> Talking with Whubbs about it, I found that our service script only >>> supports OpenRC, via rc-service. I looked around, and from what I >>> can tell, most distros ship a service tool for all supported init >>> systems. I.e., Debian/Ubuntu: supports sysvinit and systemd via >>> init-system-helpers CentOS/Fedora: provides support for systemd via >>> initscripts OpenSUSE: has a working service binary for systemd >>> (according to #suse) >> >> There is "eselect rc" which could be easily extended to support >> systemd. Patches are welcome. :) >> > > ++ > > Honestly, I could see the argument for having a generic "service" > command because that is what everybody else does, but there is little > point in arguing about the name of the file when nobody has bothered > to write it yet. > > If somebody writes such a tool and it proves useful, we can always > have the discussion about refactoring. > > To minimize list replies I'll tackle one of Duncan's points - he was > debating whether you really need this vs just using systemctl. The > obvious use case is scripts that are intended to support multiple init > systems - it makes far more sense to put the logic to figure out which > one to run in one place than many. If the runit users want to add > their own logic they could. IMO it would be potentially useful, even > if you and I don't personally have much use for it. > > That said, the sorts of people most likely to benefit probably don't > use Gentoo in the first place. > > In any case, arguing over whether it is useful is putting the cart > before the horse. It doesn't matter if it is useful if nobody bothers > to build it. If nobody has that much of an itch to scratch then how > useful could it be? > Great points. It'll be much easier to decide on something when/if there is something concrete to work with. There isn't much stopping a package from making it into Gentoo. If there is demand, it'll be written. -- Daniel Campbell - Gentoo Developer, Trustee, Treasurer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Reinstating old-school GLEPs masterplan
On 09/11/2017 01:56 PM, Michał Górny wrote: > W dniu pon, 11.09.2017 o godzinie 13∶29 -0400, użytkownik Michael > Orlitzky napisał: >> On 09/11/2017 01:08 PM, Michał Górny wrote: >>> Hi, >>> >>> TL;DR: I'd like to reinstate the old-school GLEPs in .rst files rather >>> than Wiki, put in a nice git repo. >>> >> >> I generally agree with you that wiki markup is terrible and that a text >> editor and a git repo is The Right Way to do things (with Jekyll or >> whatever to push it to the web). But in my experience, crappy and easy >> is a better way to get people to contribute. When I've taken wiki >> documents and moved them into git repos, more often than not I become >> the sole contributor, and otherwise-technical people just start emailing >> me their contributions (which decrease greatly in frequency). > > Rich already answered this in detail, so I'll skip it. > >> Will it be possible to build the GLEP rst files locally, and view the >> output exactly as it would appear on the website? I ask because, so long >> as you don't want to be able to preview the result, you can already >> write MediaWiki markup into a text file locally. The offline "live >> preview" ability is the killer feature of RST as I see it. > > Of course yes. However, the exactness of result depends on how much > effort you put into it. > > The 'easy way' is rst2html.py (dev-python/docutils). It will give you > a rough rendering with a standard style, i.e. kinda ugly but enough to > see if everything works as expected. You'll also see the preamble as big > mumbo-jumbo on top. > > Then, there's glep.py (dev-python/docutils-glep) which adds preamble > parsing, table of contents and some styling. AFAICS it needs a bit > handiwork (copying a stylesheet to a relative directory) but it gives > nice old-school rendering. > > Then, you can just take www.gentoo.org and run it locally. It takes > a little more effort but jekyll is really trivial to set up and run > locally. Then you see it exactly how it's gonna look on g.o. > > As a side note, we may also rename GLEPs to .rst. Then, GitHub will also > provide out-of-the-box rendering of them. > To preface, I really like the idea to do this in Git. Much as I appreciate what the wiki team has done, collaboration isn't quite as smooth on it and as another person mentioned, it's hard to get reviews, so you get to choose to leave something in your userspace (I liked your Drafts namespace idea, fwiw) or edit a page anyway and hope for the best. That said... Is it wise to rely on Ruby (via Jekyll) for critical reference documents, given how often minor version bumps in Ruby disrupt its ecosystem? Do we really need the entire www.gentoo.org repository in order to view and hack on GLEPs? I see little reason for GLEPs to not be in their own repository, depending on something more stable than Jekyll and Ruby. Given that the doc tools themselves are written in Python, it makes more sense (imo) to leverage Gentoo's existing technical investment in Python and use something like app-text/pelican, which is equally, if not more capable than Jekyll and will not require pulling in Ruby just to hack on and preview some text. Every Gentoo system comes with Python unless you go off the beaten path and know what you're doing, so that's a bonus, too. Of course, this changes if we need some extremely advanced behavior. I'm not sure how easy it is to build a Pelican plugin, but there's an entire repo full of them. [1] Pelican also uses a Makefile you can hack on (even multiple publishing targets), and supports GNU gettext for translations. Or is Jekyll chosen purely because the current website is built with it? In that case, it at least makes sense despite the heavyweight dependencies. If anyone's interested in seeing a mockup of a few GLEPs in Pelican, I can get that started. Whether or not the structure works on GitHub is orthogonal to the decision. Still, put me down in favor of switching to Git. Thanks for putting together the proposal. [1]: https://github.com/getpelican/pelican-plugins -- Daniel Campbell - Gentoo Developer, Trustee, Treasurer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow
On 09/10/2017 02:34 AM, Michał Górny wrote:
> W dniu nie, 10.09.2017 o godzinie 00∶39 -0700, użytkownik Daniel
> Campbell napisał:
>> On 09/09/2017 12:47 AM, Michał Górny wrote:
>>> W dniu pią, 08.09.2017 o godzinie 17∶19 -0400, użytkownik Rich Freeman
>>> napisał:
>>>> On Tue, Jul 25, 2017 at 4:05 AM, Michał Górny wrote:
>>>>>
>>>>> What do you think about it? Is there anything else that needs being
>>>>> covered?
>>>>>
>>>>
>>>> FYI - if anybody does want to make any comments on the proposed
>>>> devmanual changes to implement the new tags please comment at:
>>>>
>>>> https://github.com/gentoo/devmanual.gentoo.org/pull/72
>>>>
>>>> For that matter, if you want to even know what the proposed changes
>>>> are you should also visit the link.
>>>>
>>>> List replies seem to be discouraged.
>>>>
>>>> I realize that some prefer to limit comments to media that are purely
>>>> open source. I guess the FOSS Linux kernel provided /dev/null still
>>>> exists as an alternative. Honestly, I'm not sure which of the options
>>>> are more likely to get read.
>>>>
>>>
>>> TL;DR: Rich, I would really appreciate if you stopped the flamebaits.
>>> I understand that you think you're doing Gentoo a favor but you're not.
>>>
>>> The footers were discussed to death in this very thread. I've heard your
>>> opinions. However, as far as I'm concerned (and as I've pointed out) you
>>> did literally *nothing* to push your ideas forward for 2+ years.
>>>
>>> Since I've done all the work, I've did it my way and for the reasons
>>> I've explained multiple times. If you disagree, them I'm sorry but
>>> in life you don't get to have everything your way. Especially if all you
>>> do is complain and expect others to do the work for you.
>>>
>>> I understand that you're unhappy and since you have no valid arguments,
>>> all you can do is try to get more people to support you and shout.
>>> Revive the bikeshed as many times as possible, try to make a lot of
>>> noise and block changes. Worst case, you've blocked something you didn't
>>> like. Best case, you're finally get others so discouraged that they'll
>>> do things your way just so that you stop.
>>>
>>> Rich, this is not a kindergarten. It's time you learn to lose,
>>> and accept the consequences. If you can't do that, the door out is open,
>>> and you're free to leave anytime you want.
>>>
>>
>> This behavior is not befitting Gentoo leadership. Limiting commentary to
>> a walled garden outside Gentoo control violates one of our goals
>> (independence), and the incendiary retorts are no more mature than the
>> behavior you're criticizing. Nothing will change in the way people
>> respond to you until you learn how to treat others.
>>
>> By all means, I'm glad we're seeing some action on which tags to settle
>> with. It's been a mess of confusion ("which tags do I use? Will this
>> tick someone off?", etc), and will be easier to build on once we figure
>> out the tags that'll work best. It'll be awesome to get automatic bug
>> closing from a commit, and I suspect it'll bring a lot of good. Settling
>> on tags allows us to automate more. However, as a Council member, the
>> Gentoo community looks to you and your behavior as an example. Is this
>> the example you want to set for our community?
>>
>> On the GitHub Issue, you called this mailing list "completely useless"
>> [1], and then you sent your message above a little later. Would you want
>> to work with someone who talks to you the way you treated Rich?
>
> Yes, I did call it useless *multiple times*, and I've pointed out
> the problems. Considering they were ignored and the quality of
> the mailing list hasn't improved, this statement still stands.
>
> Rich should have talked to me if he had problems with understanding my
> comment or missed the context to it. What he did instead is beginning
> a public stone throwing session. This is not a kind of behavior I am
> going to accept, or respond kindly to.
>
> It's elementary. If you have a problem with me, talk to me first. Not go
> pointing fingers and shouting 'this person is bad'.
That's a good policy, one most of us can agree with I think. Sarcasm
Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow
On 09/09/2017 12:47 AM, Michał Górny wrote:
> W dniu pią, 08.09.2017 o godzinie 17∶19 -0400, użytkownik Rich Freeman
> napisał:
>> On Tue, Jul 25, 2017 at 4:05 AM, Michał Górny wrote:
>>>
>>> What do you think about it? Is there anything else that needs being
>>> covered?
>>>
>>
>> FYI - if anybody does want to make any comments on the proposed
>> devmanual changes to implement the new tags please comment at:
>>
>> https://github.com/gentoo/devmanual.gentoo.org/pull/72
>>
>> For that matter, if you want to even know what the proposed changes
>> are you should also visit the link.
>>
>> List replies seem to be discouraged.
>>
>> I realize that some prefer to limit comments to media that are purely
>> open source. I guess the FOSS Linux kernel provided /dev/null still
>> exists as an alternative. Honestly, I'm not sure which of the options
>> are more likely to get read.
>>
>
> TL;DR: Rich, I would really appreciate if you stopped the flamebaits.
> I understand that you think you're doing Gentoo a favor but you're not.
>
> The footers were discussed to death in this very thread. I've heard your
> opinions. However, as far as I'm concerned (and as I've pointed out) you
> did literally *nothing* to push your ideas forward for 2+ years.
>
> Since I've done all the work, I've did it my way and for the reasons
> I've explained multiple times. If you disagree, them I'm sorry but
> in life you don't get to have everything your way. Especially if all you
> do is complain and expect others to do the work for you.
>
> I understand that you're unhappy and since you have no valid arguments,
> all you can do is try to get more people to support you and shout.
> Revive the bikeshed as many times as possible, try to make a lot of
> noise and block changes. Worst case, you've blocked something you didn't
> like. Best case, you're finally get others so discouraged that they'll
> do things your way just so that you stop.
>
> Rich, this is not a kindergarten. It's time you learn to lose,
> and accept the consequences. If you can't do that, the door out is open,
> and you're free to leave anytime you want.
>
This behavior is not befitting Gentoo leadership. Limiting commentary to
a walled garden outside Gentoo control violates one of our goals
(independence), and the incendiary retorts are no more mature than the
behavior you're criticizing. Nothing will change in the way people
respond to you until you learn how to treat others.
By all means, I'm glad we're seeing some action on which tags to settle
with. It's been a mess of confusion ("which tags do I use? Will this
tick someone off?", etc), and will be easier to build on once we figure
out the tags that'll work best. It'll be awesome to get automatic bug
closing from a commit, and I suspect it'll bring a lot of good. Settling
on tags allows us to automate more. However, as a Council member, the
Gentoo community looks to you and your behavior as an example. Is this
the example you want to set for our community?
On the GitHub Issue, you called this mailing list "completely useless"
[1], and then you sent your message above a little later. Would you want
to work with someone who talks to you the way you treated Rich?
None of this bickering is motivating or inspiring to those who read it,
and leadership should know better than to stoop to this level publicly.
You will not get more developer activity, agreement, cooperation, or
contribution by berating your fellow developers. In fact, Gentoo is
known for its bickering developer community. You are in a position to
change that. You asserted in #gentoo-trustees that the Council *is*
Gentoo's leadership.
Is this your brand of leadership?
~zlg
[1] https://dev.gentoo.org/~zlg/useless.png
(screenshotted since GitHub conversations can be curated.)
--
Daniel Campbell - Gentoo Developer, Trustee, Treasurer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] New package neomutt
On 08/17/2017 12:48 AM, Michał Górny wrote: > W dniu śro, 16.08.2017 o godzinie 22∶07 -0700, użytkownik Daniel > Campbell napisał: >> On 08/10/2017 01:10 AM, Michał Górny wrote: >>> On czw, 2017-08-10 at 09:54 +0200, Fabian Groffen wrote: >>>> On 10-08-2017 09:40:30 +0200, Michał Górny wrote: >>>>> On czw, 2017-08-10 at 06:58 +0200, Nicolas Bock wrote: >>>>>> On Mon, Jul 31, 2017 at 09:11:19AM +0200, Nicolas Bock wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I would like to add neomutt to the tree. This new package is meant as >>>>>>> an alternative and not a replacement of the existing mutt package. >>>>>> >>>>>> Thanks for all of the great suggestions and feedback! >>>>>> >>>>>> This is round two. I have update the ebuild with all your >>>>>> suggestions. I have also added support for eselecting between mutt >>>>>> and neomutt. Before the eselect ebuild can land though, we need to >>>>>> rename the mutt binary so that the managed link can be called >>>>>> mutt. >>>>> >>>>> What for? How many people are exactly in the dire need of having both >>>>> installed simultaneously and switching between them? If you really can't >>>>> learn to type the new command, add IUSE=symlink blocking original mutt >>>>> and be done with it. Don't add more unowned files to /usr by another >>>>> poorly written eselect module. >>>> >>>> Be nice! No need to be bitchy here (and in the rest of your review). >>>> Nicolas is just trying. >>>> >>>> Me, as maintainer of Mutt, thought it was a good idea, because it allows >>>> people to easily have both installed at the same time, which in this >>>> interesting time for both projects is not a weird thing to have. >>> >>> I don't see how eselect helps that. People can just run neomutt by >>> typing... neomutt, right? It works without the symlink, right? >>> >>>> If there is a policy/move to get rid of eselect, then sorry, I am not >>>> aware of that. I can live with a symlink USE-flag. It doesn't seem >>>> very elegant to me, but it would work for this scenario. >>>> >>> >>> The move is against orphaned files in /usr that are randomly changed by >>> runtime tools rather than the package manager. >>> >> >> Then how do we explain the reasoning for the other 50 or so eselect >> modules? No doubt at least a handful of them modify symlinks in /usr, >> and have similarly few options to choose from, such as eselect-vi. >> Should we remove those as well? >> > > Mistakes of the past are no excuse to commit more mistakes. You should > know that because I had to repeat this many times. Some of the eselect > modules have been fixed since then giving major improvements (see: > eselect-opengl). > I can agree with that, but you seemed opposed to the entire idea of an eselect module for upstreams that own the same file; e.g. neomutt being a drop-in replacement for mutt. Are you instead opposing a cobbled-together eselect module? What would it take to ensure the RO /usr use-case could be supported while simultaneously allowing easy switching? Does eselect-opengl support RO /usr? If not, then it's a little unreasonable to expect other modules to do it since you pointed to it as a good example. What is your true opinion? -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New package neomutt
On 08/10/2017 01:10 AM, Michał Górny wrote: > On czw, 2017-08-10 at 09:54 +0200, Fabian Groffen wrote: >> On 10-08-2017 09:40:30 +0200, Michał Górny wrote: >>> On czw, 2017-08-10 at 06:58 +0200, Nicolas Bock wrote: >>>> On Mon, Jul 31, 2017 at 09:11:19AM +0200, Nicolas Bock wrote: >>>>> Hi, >>>>> >>>>> I would like to add neomutt to the tree. This new package is meant as >>>>> an alternative and not a replacement of the existing mutt package. >>>> >>>> Thanks for all of the great suggestions and feedback! >>>> >>>> This is round two. I have update the ebuild with all your >>>> suggestions. I have also added support for eselecting between mutt >>>> and neomutt. Before the eselect ebuild can land though, we need to >>>> rename the mutt binary so that the managed link can be called >>>> mutt. >>> >>> What for? How many people are exactly in the dire need of having both >>> installed simultaneously and switching between them? If you really can't >>> learn to type the new command, add IUSE=symlink blocking original mutt >>> and be done with it. Don't add more unowned files to /usr by another >>> poorly written eselect module. >> >> Be nice! No need to be bitchy here (and in the rest of your review). >> Nicolas is just trying. >> >> Me, as maintainer of Mutt, thought it was a good idea, because it allows >> people to easily have both installed at the same time, which in this >> interesting time for both projects is not a weird thing to have. > > I don't see how eselect helps that. People can just run neomutt by > typing... neomutt, right? It works without the symlink, right? > >> If there is a policy/move to get rid of eselect, then sorry, I am not >> aware of that. I can live with a symlink USE-flag. It doesn't seem >> very elegant to me, but it would work for this scenario. >> > > The move is against orphaned files in /usr that are randomly changed by > runtime tools rather than the package manager. > Then how do we explain the reasoning for the other 50 or so eselect modules? No doubt at least a handful of them modify symlinks in /usr, and have similarly few options to choose from, such as eselect-vi. Should we remove those as well? -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Changing PMS to Portage Manager Specification
On 08/14/2017 03:39 PM, William L. Thomson Jr. wrote: > On Mon, 14 Aug 2017 15:20:26 -0700 > Rich Freeman wrote: > >> On Mon, Aug 14, 2017 at 5:26 PM, William L. Thomson Jr. >> wrote: >>> >>> Portage supports sets, but the PMS has no mention. Then there is >>> debate on what they are. Creating so much noise it drowns the bug >>> request and makes it invalid. Despite the need still existing, and >>> PMS lacking anything on sets. >>> https://bugs.gentoo.org/show_bug.cgi?id=624300 >>> >>> Just the needs I have with portage are stalled, marked as invalid. >>> No discussion for inclusion in PMS. Like documenting sets. >> >> Ah, well, that's the main mystery of this thread solved. Thanks. > > That is the tip of the iceberg, not the main problem itself. I have > never been a fan of EAPI, or the resulting PMS, etc. Having been around > before such existed, I do not believe it has helped Gentoo and in fact > maybe the opposite. Why EAPI 0 stuff is in tree, or very old EAPIs. > > Now becoming more real issues rather than just a dislike of EAPI. > I'm unaware of any other way to introduce progressive changes to an API without literally rewriting every ebuild. Versioned APIs are good APIs, and give developers (both inside and outside Gentoo) something they can depend on and, most importantly, predict. If there was just one EAPI, you'd need to consult git log or some other construct to figure out the API version an ebuild was written against. The fact we still have older EAPI ebuilds is one of manpower and (dis)interest. I don't see anyone trying to prevent (or encourage) EAPI upgrading across the tree. Generally, we wait until a package needs a revbump/version bump and/or has serious breakage (and thus needing a rewrite) before bumping EAPI. Some jumps in EAPI, for simple packages, are painless. Others are a nightmare. I see no other way to support the 1m+ ebuilds that have been written since Gentoo's inception in an unambiguous, reference-able way. In fact, I'd argue if you don't version your APIs, you're not designing them correctly. APIs *will* change; building a version number into the API ensures the consumers of said API are aware of changes. That said, yes, it'd be nice if every ebuild was EAPI 6, but that is a hge amount of work that nobody seems interested in, for questionable gain. The work would just be repeated when the next EAPI is approved. The way it works now is more organic and better representative of the state of Gentoo development, for better or worse. It's good to see you taking part in constructive discussions! That's not intended as sarcasm. I mean it. Thanks for taking part. ~zlg -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Revisions for USE flag changes
On 08/13/2017 03:11 AM, Michael Orlitzky wrote: > On 08/12/2017 10:52 PM, Duncan wrote: >> >> How so? Are you arguing that deciding to system-wide switch to/from >> pulseaudio, systemd, or gstreamer is nonsense? >> > > The meaning of any one USE flag varies widely across packages. I could > never say "I want to enable USE=gstreamer" for every package in the > tree, because I have no idea what it does for most of them. Setting > USE=whatever globally essentially means "make random changes to my > system" -- hence my wording. > > The meaning of a USE flag is per-package, so per-package is the only > meaningful way to set them. > There are USE flag situations that are relevant at the global level. systemd, pulseaudio, alsa, gstreamer, openssl/libressl, libav/ffmpeg, vim-syntax, and so on. Then there's USE_EXPAND variables, which might mean different things in different packages and yet I see nothing in your argument covering them. These flags make perfect sense at the global level, because users generally want support for the choices they make, and they make choices on that *general* level first, before diving into package-specific USE flags. It's a monumental waste of developer and user time to manually set major USE flags in every relevant package. Some people are picky and will still do that, but global USE ensures that certain assumptions are made about your system. If you don't want assumptions, don't use global USE. There's no reason to deprive others of functionality you don't personally agree with or use. Granted, some flags don't belong in make.conf. But part of Gentoo's beauty is that we *do* let users proverbially saw their leg off, if that's what they really want. There are lots of use cases that would be made ridiculous in scope if we got rid of global USE. Is your only answer a megabyte-long p.use file? That said, I like your idea of clearing up revbump decisions and the angle of reducing development burden. This particular idea comes at too high a cost for my taste, as we stand to lose functionality rather than improve or gain it. ~zlg -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Package up for grabs
On 08/06/2017 02:27 AM, tom...@gentoo.org wrote: > Quoting Daniel Campbell (2017-07-31 04:16:30) >> On 07/19/2017 02:33 AM, Amy Liffey wrote: >>> The following package is up for grabs: >>> >>> dev-lang/gforth >>> >>> Best regards, >>> Amy Liffey >>> >> I can take this one; I'd hate to see Forth support go missing on Gentoo. >> I'm open to co-maintainers as well. >> > Ok, as I have done some quite Forth programming in the past, let me step in. > > Thomas > >> ~zlg >> >> -- >> Daniel Campbell - Gentoo Developer >> OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net >> fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 >> > > Sounds great. Would you like me to do the honors of updating metadata.xml later tonight? -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Package up for grabs
On 07/19/2017 02:33 AM, Amy Liffey wrote: > The following package is up for grabs: > > dev-lang/gforth > > Best regards, > Amy Liffey > I can take this one; I'd hate to see Forth support go missing on Gentoo. I'm open to co-maintainers as well. ~zlg -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Package up for grabs
On 07/23/2017 07:13 AM, Manuel Rüger wrote: > The following packages are up for grabs: > > app-admin/gixy > app-admin/mei-amt-check > app-admin/ngxtop > app-admin/passwordsafe > app-arch/lz5 > app-crypt/acme > app-crypt/certbot > app-crypt/certbot-apache > app-crypt/certbot-nginx > app-crypt/easy-rsa > app-crypt/libmd > app-crypt/manuale > app-crypt/pgpdump > app-emulation/docker-gc > app-misc/jira-cli > app-misc/pdfpc > app-text/blahtexml > app-text/itex2mml > app-text/mathtex > dev-go/cli > dev-go/delve > dev-go/go-gitlab-client > dev-go/glide > dev-go/toml > dev-python/parsley > dev-python/safety > dev-python/txsocksx > dev-python/vcversioner > dev-libs/libgit2 > dev-lua/luadbi > dev-lua/luasocket > dev-lua/lua-zlib > dev-util/bloaty > dev-util/cookiecutter > net-analyzer/linkchecker > net-libs/libssh2 > net-misc/kafkacat > x11-misc/flow-pomodoro > x11-plugins/pidgin-opensteamworks > x11-plugins/pidgin-xmpp-receipts > > There is another set of packages, which have a backup project > maintaining it. Please talk to the respective project if you're > interested in maintaining those: > > app-office/texstudio > dev-python/cookies > dev-python/freezegun > dev-python/future > dev-python/hiro > dev-python/hvac > dev-python/parsedatetime > dev-python/parsley > dev-python/pyhcl > dev-python/pykka > dev-python/pyrfc3339 > dev-python/pytest-capturelog > dev-python/pytest-localserver > dev-python/responses > dev-python/vcrpy > dev-python/zope-component > dev-python/zope-event > net-firewall/nftables > net-libs/libnftnl > > Best regards, > Manuel Rüger > > I have a machine using certbot (Rpi 3 Model B) now that I might be switching to Gentoo in the future. I'd be willing to co-maintain app-crypt/certbot with other interested developers. The catch is I don't use Apache or nginx; others would need to maintain certbot-apache and certbot-nginx. Anyone interested? -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?
On 07/28/2017 12:44 PM, Alec Warner wrote: > > > On Fri, Jul 28, 2017 at 3:44 AM, Andreas K. Huettel > mailto:dilfri...@gentoo.org>> wrote: > > Am Dienstag, 25. Juli 2017, 01:22:44 CEST schrieb Peter Stuge: > > > > I hold a perhaps radical view: I would like to simply remove stable. > > > > I continue to feel that maintaining two worlds (stable+unstable) > > carries with it an unneccessary cost. > > > > That's not feasible. It would kill off any semi-professional or > professional > Gentoo use, where a minimum of stability is required. > > > So my argument (for years) has been that this is the right thing all along. > > If people want a stable Gentoo, fork it and maintain it downstream of > the rambunctious rolling distro. > > > > (Try keeping ~10 machines on stable running without automation. > That's already > quite some work. Now try the same with ~arch. Now imagine you're > talking about > 100 or 1000 machines.) > > -- > Andreas K. Hüttel > dilfri...@gentoo.org <mailto:dilfri...@gentoo.org> > Gentoo Linux developer (council, perl, libreoffice) > > Why would we replicate that when Arch has been in that cavalier role for over a decade? Stability is important to all users; some simply have a lower tolerance for faults. It also gives us a reliable "product" for others to rely on or even dogfood. I personally run on ~arch, but if I were to put a friend on Gentoo, I'd want something that will be pretty easy-going until they learn the skills to take on ~arch, bug reports, etc. For many -- especially developers -- stable is only a letter away from "stale", and that's fine. Some run mixed keywords, or go full ~arch. One of the core values of Gentoo is choice; why take away the stable choice? -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [RFC pre-GLEP] Gentoo Git Workflow
On 07/26/2017 10:05 AM, Kristian Fiskerstrand wrote: > On 07/25/2017 02:28 PM, Michael Palimaka wrote: >> Does a bug # really need to always be in the summary line? It can eat >> valuable characters and tags which are pretty popular are equally valid IMO. > > I would prefer the summary to be informative without having bug ID at > all. Summary should describe the change ,not only "fixes XXX", the bug > reference belongs in body (tags) > +1. I tend to add bug numbers in my summary, but it makes it very challenging to put something meaningful into the remaining characters. We already put 'category/pkg:' or 'dir/file:' for a prefix. Adding 6 or 7 characters to that already considerable deficit cuts ~15% of git's recommended 50 characters, or 10% of our proposed 70. Pushing this out to a tag -- and standardizing it -- will only improve maintenance and speed up our onboarding process. "Bug: xx" isn't my favorite since it requires tooling to actually visit said bug (and doesn't clarify which bug platform to reference), but a URL uses more bytes and infra may change. It's a tough choice, but if we can find something that fits enough use cases, tooling shouldn't be too difficult to write to make up for it. I already use a `bgo` keyworded shortcut in Pale Moon to make bug searching faster; adding another to navigate straight to a bug wouldn't be much trouble. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?
On 07/25/2017 06:22 AM, Rich Freeman wrote: > On Tue, Jul 25, 2017 at 9:10 AM, Michael Palimaka > wrote: >> >> The 30 day waiting period is useful for smoking out major upstream bugs, >> but can't replace stabilisation integration testing. For example, >> package foobar may build fine in ~arch but fails in stable because it >> needs a newer libbaz. >> > > I think this is a good reason why everything should be at least > build-tested on a stable tree before getting stabilized. Now, that > might not be on each arch if it is truly arch-independent (and if > arches keep the dependencies reasonably in sync). > > This might be a situation where a compromise could exist. Have some > kind of flag (in metadata, or maybe the ebuild) that indicates that > the maintainer believes the package is low-risk to stabilize purely on > a build test. Then after 30 days in testing a tinderbox could > build-test the package and stabilize it automatically. > > If the package is considered at-risk then it goes through manual > testing, either by the maintainer or an arch team. > > This will also encourage the teams doing testing to actually do more > testing on the packages that would benefit from it. > > We wouldn't set hard criteria but leave it up to maintainer > discretion, with a guideline being that past performance is probably a > good predictor of future results. > This reads like a practical use of both developer time and machine time. Build testing at a minimum, imo, is necessary if the word "stable" is going to mean anything for us. So +1. Since there are bound to be fewer manually tested packages than automatic "it builds, ship it" packages, I think it would make a bit more sense to add a "manually test this please" tag to metadata.xml, rather than expect auto-stabilizers to have additional tags, which will outnumber the manual packages and inflate the size of the tree (albeit slightly). Since maintainers also manage their packages in various ways, could we extend this to a general element? Maintainers can specify how they'd prefer bugs or commits to be done, and an additional element to indicate hand-testing. This would solve two problems instead of just one: indicate a package is ready for auto-stabilization, and give a single, canonical location for a maintainer to put maintenance policy. Just my 2¢, ~zlg -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] vim-syntax USE flag
On 07/22/2017 01:27 PM, Mike Gilbert wrote: > Packages currently handle installation of vim syntax support files > inconsistently. Some builds install the files if the "vim-syntax" USE > flag is enabled, while others install them unconditionally. > > Do these files fall into the "small text files" category for > unconditional installation? If so, we should probably phase out the > vim-syntax USE flag. > > If we want to keep the USE flag, I would suggest documenting a global > policy regarding its use. Should that live in the devmanual? Or maybe > the Vim project page? > I agree, a global policy should be established; whether it's "install unconditionally" like we do with systemd units, openrc daemons, etc, or a global USE. I'm unaware of any way to misinterpret what "vim-syntax" means, and Vim itself already has a place it expects such files to go. Installing a package without this USE flag requires a rebuild to get the syntax file(s), so that's another reason to go unconditional. I have the USE flag set globally and it hasn't created any blockers, so maybe it's safe. As for where documentation goes, I would expect a brief paragraph in the devmanual mentioning the USE flag and linking to the Vim project page that better explains usage and expectations. That way, changes in the Vim project's way of development wouldn't require big rewrites in the devmanual. If we're shipping syntax for other editors as well, perhaps it's deserving of its own devmanual page. Do we have a problem with developers not shipping syntax files? (vim or otherwise) --semi-offtopic-- When I first began using Gentoo in 2012, I was annoyed that Vim remembered my cursor position for every file I opened. It took some hunting to locate where this was set (/etc/vim/vimrc, owned by app-editors/vim-core for the curious) and correct it with g:leave_my_cursor_position_alone = 1 in my vimrc. If we could document Gentoo-added Vim features like that, it'd be less trouble for our newer users to configure Vim to their tastes. I understand we're not a newbie distro, but unexpected behavior can be a PITA to track down without documentation or trawling through `:script` output. Searching the Web, our wiki, and even our GitHub account turned up zero helpful results for this particular thing. If the Vim team needs the help, I'd be glad to lend a hand where needed. (also cc'ing vim@ to get an official opinion) -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] libva/libva-intel-driver/libva-utils ebuild relocation
On Wed, Jul 12, 2017 at 10:15 AM, Michał Górny wrote: > On śro, 2017-07-12 at 10:12 -0700, Daniel Charles wrote: >> Hello gentoo-dev's >> >> Checking on how gentoo is locating ebuild for these 3 packages I found >> that they're using different folders and overriding driver's name >> >> x11-libs/libva >> x11-libs/libva-intel-driver (overriding package name: intel-vaapi-driver) >> media-video/libva-utils >> >> Since the project moved to github.com/01org, could it possible to >> relocate all the ebuilds starting with version 1.8.x to a common >> folder? >> >> This would be my proposal >> >> media-video/libva >> media-video/intel-vaapi-driver >> media-video/libva-utils >> >> Driver changed package name when transitioning to the new repository >> and although that is handled in the current ebuild, a new ebuild name >> might be helpful here. >> >> Let me know your thoughts >> > > Please file a bug mentioning all three (current) packages. We'll assign > it to the right people. Submitted here: https://bugs.gentoo.org/show_bug.cgi?id=624724 Thanks -- Daniel. > > -- > Best regards, > Michał Górny
[gentoo-dev] libva/libva-intel-driver/libva-utils ebuild relocation
Hello gentoo-dev's Checking on how gentoo is locating ebuild for these 3 packages I found that they're using different folders and overriding driver's name x11-libs/libva x11-libs/libva-intel-driver (overriding package name: intel-vaapi-driver) media-video/libva-utils Since the project moved to github.com/01org, could it possible to relocate all the ebuilds starting with version 1.8.x to a common folder? This would be my proposal media-video/libva media-video/intel-vaapi-driver media-video/libva-utils Driver changed package name when transitioning to the new repository and although that is handled in the current ebuild, a new ebuild name might be helpful here. Let me know your thoughts Thanks. -- Daniel
Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds
On 07/11/2017 01:57 PM, William L. Thomson Jr. wrote: > On Tue, 11 Jul 2017 13:27:57 -0700 > Daniel Campbell wrote: > >> On 07/10/2017 04:37 PM, William L. Thomson Jr. wrote: >>> On Mon, 10 Jul 2017 19:22:47 -0400 >> >>> A rule for portage could be; >>> >>> - If the package is not in world and already installed. Do not add >>> the package to world. If you are re-emerging a package already >>>installed. You do not have to use the -1 option. >>> >>> I have polluted so many world files with system packages and/or >>> dependencies I re-emerged directly without -1. Those IMHO should >>> never have been recorded to that file. They were brought in by >>> other things. Only things in my world should be packages merged >>> directly, not from profile, set, or a dep. > >> Portage's fault. If you don't want a package added to a set or world, >> you'll need to use the -1 (--oneshot) option. > > Did you even read above? I clearly state WITHOUT -1 option > >> I added it to my default >> emerge options in make.conf for exactly that reason (clean world); > > The point is people should not have to do such. Or remember to always > use -1 when re-emerging a dep, system, world, or set package. > >> though, I have to be careful and make sure packages I care about are >> in a set somewhere or --depclean will wipe'em out. In short, Portage >> won't stop you from shooting yourself in the foot. > > If those package are in your world file portage will not remove on > depclean. > >> If you decide you want to add a package to world without re-merging >> it, -n (--noreplace) will do the job. > > Or you can add it to the world file, or your profile/packages > in /etc/portage, etc. There are other places, one does not have to > emerge every package then want in world. Just the same it should not > add stuff just the same from system, world, sets, or deps of any of > those 3. > >> That said, having helpful messages is a good addition, but needs to be >> done in a way that is unambiguous and gives the user a clear solution. > > So now it must be clear to the user? That is the entire point I am > making. The output now is not clear... But in improving such now there > is concern over something no one cares about now Funny stuff!!! > I understand where you're coming from, I just thought to give a few tips to make life a bit easier for you since it works out pretty well for myself. I think your idea has merit, just unsure of where the functionality goes, since I'm not a Portage developer. I think the hard part of implementing this will be detecting whether a command-line-given package is (a) in a set/profile/world and (b) part of a dependency tree (i.e. shouldn't be removed). -c already traverses the dependency tree. This one message may mean iterating through the list of candidate packages and comparing them against a set/profile/world *per package*, unless the vdb/cache makes this lookup cheap in terms of cycles. The message would be helpful, though again, eix-test-obsolete might be the right tool to build that feature into. I'd be interested in following the bug discussion, if you've already filed it. If you're really interested in the message from -C, it could be done by checking the argument list for packages in sets or profiles. But it's going to incur similar overhead that -c has because it necessarily has to check some sort of list before producing the message. I do not think this message belongs in -C output, however; -C is intentionally meant for operations where you don't care what happens to the dependency tree. Sometimes that's good (resolving a blocker the hard way), sometimes it's bad (removing gcc on a whim). Warnings won't stop a user doing that, because --unmerge is already documented with the caveat. There must be a certain point where we as developers have to say "You're on your own," or there will be so many rails and training wheels that it loses value for the more experienced users, or a bunch of bugs filed over failing to heed documentation, i.e. PEBKAC. I think -C is a great place to draw that line. The best way to get the ball rolling is file a feature request against Portage and see what 'upstream' has to say. In the meantime, maybe try your hand at hacking it. I've found people are a lot more receptive to suggestions when you've already attempted to provide it. Even if the solution is crap, people seem willing to help those who have the gumption to help themselves. Please don't interpret this e-mail as aggressive or dismissive. I'm simply trying to offer explanation and guidance to help you make this happen. It's clear that you care about it, so I'm sure there's a way for this to go forward. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds
On 07/11/2017 01:27 PM, Daniel Campbell wrote: > On 07/10/2017 04:37 PM, William L. Thomson Jr. wrote: >> On Mon, 10 Jul 2017 19:22:47 -0400 >> "William L. Thomson Jr." wrote: >>> >>> That part does not require it to resolve deps. Just check world file, >>> assuming its correct. Though could be thrown off if say gcc, or >>> another was in the world file. I think the profile or set would catch >>> that as it does now and generate a warning, regardless. >> >> Speaking of gcc in the world file. I think portage should STOP adding >> packages that are in the profile or a dep to world. If you merge a >> package as part of a set, I am pretty sure it does not get recorded to >> world, need to confirm, could be wrong. >> >> A rule for portage could be; >> >> - If the package is not in world and already installed. Do not add the >>package to world. If you are re-emerging a package already >>installed. You do not have to use the -1 option. >> >> I have polluted so many world files with system packages and/or >> dependencies I re-emerged directly without -1. Those IMHO should never >> have been recorded to that file. They were brought in by other things. >> Only things in my world should be packages merged directly, not from >> profile, set, or a dep. >> >> I will file a bug on that as well. >> > Whether Portage adds a package to a set or world file is dependent on > how you invoke emerge. Some people (like me) include sets as part of > their world, via /var/lib/portage/world_sets . At that point, sets added > to that file are basically treated as the world package list. > > If gcc or other @system packages end up in your world, it's not > Portage's fault. If you don't want a package added to a set or world, > you'll need to use the -1 (--oneshot) option. I added it to my default > emerge options in make.conf for exactly that reason (clean world); > though, I have to be careful and make sure packages I care about are in > a set somewhere or --depclean will wipe'em out. In short, Portage won't > stop you from shooting yourself in the foot. > > If you decide you want to add a package to world without re-merging it, > -n (--noreplace) will do the job. > > I'm not sure if eix-test-obsolete (from app-portage/gentoolkit) will > catch a @system atom inside a set/world file, but that's where I'd > expect such a notification to come from. The tool can help clean up > unneeded entries in /etc/portage files, and would be a good fit for this > particular issue. > > That said, having helpful messages is a good addition, but needs to be > done in a way that is unambiguous and gives the user a clear solution. > > Hope this helps, > > zlg > Whoops. s/gentoolkit/eix/ Sorry for the spam. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds
On 07/10/2017 04:37 PM, William L. Thomson Jr. wrote: > On Mon, 10 Jul 2017 19:22:47 -0400 > "William L. Thomson Jr." wrote: >> >> That part does not require it to resolve deps. Just check world file, >> assuming its correct. Though could be thrown off if say gcc, or >> another was in the world file. I think the profile or set would catch >> that as it does now and generate a warning, regardless. > > Speaking of gcc in the world file. I think portage should STOP adding > packages that are in the profile or a dep to world. If you merge a > package as part of a set, I am pretty sure it does not get recorded to > world, need to confirm, could be wrong. > > A rule for portage could be; > > - If the package is not in world and already installed. Do not add the >package to world. If you are re-emerging a package already >installed. You do not have to use the -1 option. > > I have polluted so many world files with system packages and/or > dependencies I re-emerged directly without -1. Those IMHO should never > have been recorded to that file. They were brought in by other things. > Only things in my world should be packages merged directly, not from > profile, set, or a dep. > > I will file a bug on that as well. > Whether Portage adds a package to a set or world file is dependent on how you invoke emerge. Some people (like me) include sets as part of their world, via /var/lib/portage/world_sets . At that point, sets added to that file are basically treated as the world package list. If gcc or other @system packages end up in your world, it's not Portage's fault. If you don't want a package added to a set or world, you'll need to use the -1 (--oneshot) option. I added it to my default emerge options in make.conf for exactly that reason (clean world); though, I have to be careful and make sure packages I care about are in a set somewhere or --depclean will wipe'em out. In short, Portage won't stop you from shooting yourself in the foot. If you decide you want to add a package to world without re-merging it, -n (--noreplace) will do the job. I'm not sure if eix-test-obsolete (from app-portage/gentoolkit) will catch a @system atom inside a set/world file, but that's where I'd expect such a notification to come from. The tool can help clean up unneeded entries in /etc/portage files, and would be a good fit for this particular issue. That said, having helpful messages is a good addition, but needs to be done in a way that is unambiguous and gives the user a clear solution. Hope this helps, zlg -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] taking a break from arches stabilization
On 07/10/2017 10:22 AM, Agostino Sarubbo wrote: > Hi all. > > every time that I attach my tmux session to see what happens on irc, I always > see the same discussion about the 'minor' arches status. > Since I joined gentoo(2011) I worked on all arches except hppa, I put more > effort in amd64 and less where I saw other people work on it (arm,alpha) > But every time the magic phrase is that those arches are unmaintained. > > Now, since I work on these arches just to help, i.e. I don't have any > business > and I do non have any installation of those arches and the work I'm doing is > not appreciated at all I decided to stop for now. > If your dream is to put sparc and ia64 to ~arch, go ahead, I have no > objections. > I will take a break also from amd64 and x86...let's see how things will > change. > Thanks for your efforts in stabilization. I try to make it a point to thank people like you and Toralf since stabilization and arch testing are both time-consuming, and probably frustrating to get the tooling correct. Take some time off! I'm sure Gentoo won't implode. :) -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Sets vs Meta ebuilds
On 07/09/2017 06:53 AM, William L. Thomson Jr. wrote: > On Sun, 9 Jul 2017 00:42:46 -0700 > Daniel Campbell wrote: > >>> - Sets used in profiles cannot have use expansion, versions or >>> anything beyond cat/pkg. >> This would break some set behavior, at least in Portage. Specifying a >> single version (or better, a slot) in a set is less work than adding >> lines to p.mask *and* the set file(s), and p.mask doesn't appear to >> support "!=cat/pkg-1.0" syntax to mimic the same functionality >> achieved by a versioned atom in a set. It also makes sense to put >> packages you want in a set instead of a mask. ">=" or "<=" may be >> adequate if you only want one slot or version installed, but the >> entire point of slots is to allow multiple versions to be installed >> simultaneously. Versioned package names in sets achieve this. > > Valid point, and along those lines to make the rules for sets in > profiles easier. > > - Sets in profiles can contain anything that is valid in a > profile/packages file, less the * symbol. > > I think that addresses both versions and slots. The rest, like use > expansion I believe is handled via package.use in profiles and not in > packages. > Yeah, that could work. As convenient as it is to mix USE flags with sets, there's a better place to put it and I'm unsure of any situation that would require more than two lines (one in the set, one in p.use) to achieve a given USE constraint. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Sets vs Meta ebuilds
On 07/08/2017 06:23 PM, William L. Thomson Jr. wrote: > On Sun, 9 Jul 2017 01:10:11 +0100 > Ciaran McCreesh wrote: > >> On Sat, 8 Jul 2017 19:58:13 -0400 >> "William L. Thomson Jr." wrote: >>> On Sun, 9 Jul 2017 00:49:57 +0100 >>> Ciaran McCreesh wrote: >>>> On Sat, 8 Jul 2017 19:39:33 -0400 >>>> "William L. Thomson Jr." wrote: >>>>> The two ways are not the same, and there is a reason sets exist >>>>> in the first place. People seem to be over looking that fact. I >>>>> did not add sets. They are not new. I am simply trying to >>>>> expand their use. >>>> >>>> Sets exist because people keep saying "let's have sets!" without >>>> agreeing on what sets actually are or how they are to be used. >>> >>> Do they need to agree? Isn't Gentoo about choice? Maybe your use of >>> sets is different from mine. Is that not acceptable to have >>> choice? >> >> Well yes, they do need to agree, because otherwise when two different >> developers put sets in a profile expecting different effects, then at >> least two developers are going to end up confused, disappointed, and >> quite probably breaking user systems. > > Valid points, so basically need a set of guidelines or rules for sets > used in profiles. Which should not be that complex, as usage is minimal. > Offhand, likely could be more; > > - Sets used in profiles are "lists of packages" for users to > emerge/re-emerge, and as such should be minimal list only. Similar to > the contents of a profile/packages, less the * symbol. > > - Sets used in profiles cannot have use expansion, versions or anything >beyond cat/pkg. This would break some set behavior, at least in Portage. Specifying a single version (or better, a slot) in a set is less work than adding lines to p.mask *and* the set file(s), and p.mask doesn't appear to support "!=cat/pkg-1.0" syntax to mimic the same functionality achieved by a versioned atom in a set. It also makes sense to put packages you want in a set instead of a mask. ">=" or "<=" may be adequate if you only want one slot or version installed, but the entire point of slots is to allow multiple versions to be installed simultaneously. Versioned package names in sets achieve this. > > - Sets should not have the same file listed, in that case inherit the > other set if using overlapping packages or split into smaller > -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Pre-GLEP RFC: Automated enforcing of REQUIRED_USE constraints
On 07/08/2017 03:29 PM, Michał Górny wrote: > On sob, 2017-07-08 at 15:21 -0700, Daniel Campbell wrote: >> On 07/08/2017 02:43 AM, Michał Górny wrote: >>> Hi, everyone. >>> >>> I think the affairs have settled enough and I've finished filling >>> in the pre-GLEP for REQUIRED_USE auto-enforcing. It's got all >>> the algorithms, rationale and separated reference implementation. >>> >>> If there are no major concerns raised, I will soon start working >>> on writing an optimized implementation for pkgcore/pkgcheck >>> and integrating the verification algos with the CI. >>> >>> The pre-GLEP for review is here: >>> >>> https://wiki.gentoo.org/wiki/User:MGorny/GLEP:ReqUse >>> >>> TIA. >>> >> >> This has grown quite a bit since first recommended! Great job so far. >> Forgive me if I missed something, but wouldn't it be helpful to the user >> to let them know when automatically choosing for them? A single line in >> a logfile, einfo output, whatever, would be useful for people wondering >> how certain packages got pulled in. Users will continue to get errors if >> the constraints aren't met (or are wrong), but where will information go >> that indicates the automatic solver's choice? You and I can read an >> ebuild and guess from the dep spec, but what will a user look at? >> >> I searched the GLEP page for "log", "einfo", and "output" with no >> results. If I've missed something please let me know. >> >> Thanks for the work that's been put into this so far. >> > > Indeed I have entirely skipped the user output problem, and left it > purely for package manager's design choice. Do you really feel like we > need to explicitly specify it? I think it's best if package manager > authors decide how to best fit it into whatever output the PMs already > have. > > I just considered it helpful, that's all. I hadn't considered the PMS vs. PM devs perspective. Do we plan to support some way for users to get such output from Portage? Thanks for clarifying. It does make more sense to leave it to PM devs. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Pre-GLEP RFC: Automated enforcing of REQUIRED_USE constraints
On 07/08/2017 02:43 AM, Michał Górny wrote: > Hi, everyone. > > I think the affairs have settled enough and I've finished filling > in the pre-GLEP for REQUIRED_USE auto-enforcing. It's got all > the algorithms, rationale and separated reference implementation. > > If there are no major concerns raised, I will soon start working > on writing an optimized implementation for pkgcore/pkgcheck > and integrating the verification algos with the CI. > > The pre-GLEP for review is here: > > https://wiki.gentoo.org/wiki/User:MGorny/GLEP:ReqUse > > TIA. > This has grown quite a bit since first recommended! Great job so far. Forgive me if I missed something, but wouldn't it be helpful to the user to let them know when automatically choosing for them? A single line in a logfile, einfo output, whatever, would be useful for people wondering how certain packages got pulled in. Users will continue to get errors if the constraints aren't met (or are wrong), but where will information go that indicates the automatic solver's choice? You and I can read an ebuild and guess from the dep spec, but what will a user look at? I searched the GLEP page for "log", "einfo", and "output" with no results. If I've missed something please let me know. Thanks for the work that's been put into this so far. ~zlg -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] The status of grsecurity upstream and hardened-sources downstream
On 06/23/2017 09:28 AM, Anthony G. Basile wrote: > Hi everyone, > > Since late April, grsecurity upstream has stop making their patches > available publicly. Without going into details, the reason for their > decision revolves around disputes about how their patches were being > (ab)used. > > Since the grsecurity patch formed the main core of our hardened-sources > kernel, their decision has serious repercussions for the Hardened Gentoo > project. I will no longer be able to support hardened-sources and will > have to eventually mask and remove it from the tree. > > Hardened Gentoo has two sides to it, kernel hardening (done via > hardened-sources) and toolchain/executable hardening. The two are > interrelated but independent enough that toolchain hardening can > continue on its own. The hardened kernel, however, provided PaX > protection for executables and this will be lost. We did a lot of work > to properly maintain PaX markings in our package management system and > there was no part of Gentoo that wasn't touched by issues stemming from > PaX support. > > I waited two months before saying anything because the reasons were more > of a political nature than some technical issue. At this point, I think > its time to let the community know about the state of affairs with > hardened-sources. > > I can no longer get into the #grsecurity/OFTC channel (nothing personal, > they kicked everyone), and so I have not spoken to spengler or pipacs. > I don't know if they will ever release grsecurity patches again. > > My plan then is as follows. I'll wait one more month and then send out > a news item and later mask hardened-sources for removal. I don't > recommend we remove any of the machinery from Gentoo that deals with PaX > markings. > > I welcome feedback. > Thanks for taking the time to let the greater Gentoo community know. It's a shame things took this turn... Is there any hope of a fork emerging from the drama? Why would a security-conscious group take their toys and go home? Regardless, this is a loss for Linux as a whole. I hope something springs up in its place. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Packages up for grabs
On 06/20/2017 05:53 AM, Pacho Ramos wrote: > This packages are now up for grabs: > dev-ml/fort > media-libs/embree > x11-wm/i3 > > I use i3-gaps these days, but if no-one else is willing, I'll take up i3 since it's close enough to i3-gaps to be considered mostly the same. Dual maintainership is preferred. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] fdo-mime.eclass: Mark the eclass as deprecated
On 06/19/2017 06:20 AM, Michał Górny wrote: > The GNOME team has committed the xdg-utils.eclass serving exactly > the same purpose as fdo-mime.eclass, supposedly with the goal of > replacing it. However, it seems that they have never bothered to > actually hint the deprecation in the fdo-mime.eclass in any way. > As a result, developers are still adding references to this eclass > instead of using xdg-utils or xdg, and/or not working towards replacing > them. > > Add an explicit deprecation notice to the fdo-mime.eclass to make it > clear that the eclass should not be used in new packages, and what > the replacement eclasses are. > --- > eclass/fdo-mime.eclass | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/eclass/fdo-mime.eclass b/eclass/fdo-mime.eclass > index b3b096d154e7..8e51d8a69df1 100644 > --- a/eclass/fdo-mime.eclass > +++ b/eclass/fdo-mime.eclass > @@ -1,4 +1,4 @@ > -# Copyright 1999-2011 Gentoo Foundation > +# Copyright 1999-2017 Gentoo Foundation > # Distributed under the terms of the GNU General Public License v2 > > # @ECLASS: fdo-mime.eclass > @@ -7,6 +7,8 @@ > # @AUTHOR: > # Original author: foser > # @BLURB: Utility eclass to update the desktop mime info as laid out in the > freedesktop specs & implementations > +# @DESCRIPTION: > +# This eclass is DEPRECATED. Please use xdg-utils or xdg instead. > > # @FUNCTION: fdo-mime_desktop_database_update > # @DESCRIPTION: > Looks good to me. Thanks for looking out for stuff like this. That aside, isn't this supposed to be standard operating procedure if a developer is deprecating an eclass? And similarly with the removal of an eclass, all ebuilds getting updated by the developer or team that prompted the removal of the eclass? My apologies if this is answered elsewhere. I want to be sure what's expected, just in case I need to touch an eclass. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Addition of a new field to metadata.xml
On 06/01/2017 11:59 PM, Kent Fredric wrote: > On Thu, 1 Jun 2017 18:36:24 -0700 > Daniel Campbell wrote: > >> +1. Otherwise sounds good. But if we do this for Debian, will there be >> movement to add in package names for rpm-based distros? Arch? BSD? >> Slackware? Where do we draw the line? > > I'd say "as need be". Here we have a few extra benefits from using a > debian identifier that aren't strictly related to "package mapping". > > Its also easier for third party services to use our use of debian > identifiers to produce the other mappings for us where known ( that is, > non-gentoo entities can maintain a mapping of debian-to-foo, and we can > trivially hook into that by using the debian-id as the identifer ) > >> Will developers be expected to treat this like a mandated element? > > I'd imagine not, given not everything in debian exists in gentoo, or > vice versa. > > Similarly, I don't think there are any mandates that the other values > of remote-id be populated, only that its *encouraged* because that data > provides utility to an end user. > >> If >> not, which team will have authority to touch package metadata to make >> this change? > > I'd suggest it should stay within the controls of the package > maintainer for starters, where individual maintainers can provision it > as they feel fit, and we can review our stance on this later if we want > to make it a tree wide consistent thing. > > Partly because individual maintainers are more likely to understand > correctly how equivalent their dists are to the referenced debian one, > and be more equipped to decide whether to include/exclude a given ref. > That sounds very reasonable to me. Thanks for clarifying. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Addition of a new field to metadata.xml
On 06/01/2017 06:09 PM, Kent Fredric wrote: > On Thu, 1 Jun 2017 23:18:22 +0200 > Jonas Stein wrote: > >> A space separated list of the corresponding debian packages should be >> written in the field >> > > Why space separated? > > Its already legal to specify the field multiple times, and it should > work better that way for consistency with things that can already parse > XML. > > That way there's no need to put an additional parser inside our XML > extraction. > > libfoo > libfoo-debug > > No? > > It also means general purpose XML formatting tools can keep it tidy, > _and_ sorted, without having to reinvent new tools. > +1. Otherwise sounds good. But if we do this for Debian, will there be movement to add in package names for rpm-based distros? Arch? BSD? Slackware? Where do we draw the line? Will developers be expected to treat this like a mandated element? If not, which team will have authority to touch package metadata to make this change? -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] NeoVim and vim-syntax
On 05/31/2017 03:54 PM, Ciaran McCreesh wrote: > On Thu, 01 Jun 2017 02:32:24 +0700 > "Vadim A. Misbakh-Soloviov" wrote: >> - implementing "nvim-syntax" (and `app-nvim/*`?) and duplicate all >> the installed files >> >> - patching NeoVim source to include Vim's runtimedirs (incl. "after" >> dir), // NeoVim upstream highly disagree with such way, if any >> >> - patching VIMRUNTIME environment variable, >> >> - making a wrapper, >> >> - rewrite all the existing ebuilds to take nvim into account and >> force all newcomers to also take it, >> >> - symlinking a directory, >> // mostly bad way, since opposite plugin compatibility is not >> garanteed and users can install nvim-only plugins in the future >> >> - making postinst hook to regenerate content of NeoVim's >> site-directory (maybe, by symlinking installed vim modules there) >> >> or even: >> >> - making eselect module for user to rule that. > > - Have a separate anyvimishthing directory, and make both vim and > neovim look there, and only make plugins that have been tested to work > with both install to that directory. > +1, though it's still important to keep nvim- and vim-specific dirs. A third, common dir cuts down on the work that other solutions would need. It would also give users a way to check which plugins will work with 'the other one' too and can use that to decide whether they want to make the switch. This information can probably be gleaned on their own with some detective work on the Web, but choosing this path gives the accidental feature for free. ~zlg -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCHES] python-r1.eclass: any-of dep API support
On 05/20/2017 06:30 AM, Michał Górny wrote: > > > Please review. > > -- > Best regards, > Michał Górny > > It looks much as you mentioned it'd be: moving code around and cutting down duplication. Looks good to me. I really appreciate the example in patch 7, which makes it a little more clear how to use it. Thanks for putting all of this together. I'm not sure how to express this because I don't know which question to ask. Is there anything I can help with once this gets committed? -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Restricted version of gentoo-dev mailing list
On 05/23/2017 12:31 PM, Michał Górny wrote: > [snip] > Your comments? > Since it's adding a list instead of warping an existing one, I say go ahead on the condition that everything important finds its way to a more open list. I'm subscribed to enough as it is. I am skeptical that it will lead to an improved social experience among Gentoo developers, but also willing to be proven wrong. Personally, there's nothing that attracts me to the idea. I don't really like the concept of curating a mailing list. But seeing as the point of the list is to lessen the volume of messages, it will likely succeed. ~zlg -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Should Sphinx really depends on PYTHON_COMPAT/PYTHON_USEDEP for `dev-python/*` ebuilds?
On 05/18/2017 03:30 PM, Michał Górny wrote:
> On czw, 2017-05-18 at 15:07 -0700, Daniel Campbell wrote:
>> On Fri, May 12, 2017 at 08:32:53PM +0200, Michał Górny wrote:
>>> On czw, 2017-05-11 at 11:47 +0700, Alex Turbov wrote:
>>>> DEPEND=( doc?
>>>> || (
>>>> (
>>>> dev-python/sphinx[python_targets_python2_7]
>>>> # NOTE This packages provide extensions for Sphinx
>>>> dev-python/rst-linker[python_targets_python2_7]
>>>> dev-python/jaraco-packaging[python_targets_python2_7]
>>>> )
>>>> (
>>>> dev-python/sphinx[python_targets_python3_5]
>>>> dev-python/rst-linker[python_targets_python3_5]
>>>> dev-python/jaraco-packaging[python_targets_python3_5]
>>>> )
>>>> (
>>>> dev-python/sphinx[python_targets_python3_6]
>>>> dev-python/rst-linker[python_targets_python3_6]
>>>> dev-python/jaraco-packaging[python_targets_python3_6]
>>>> )
>>>> )
>>>> )
>>>>
>>>
>>> One more thing I've missed in my initial mail. The other problem with
>>> this solution (alone) is that it doesn't enforce the implementation that
>>> satisfied the dependency.
>>>
>>> Let's take a simple example. You've built sphinx for 2.7+3.5 but rst-
>>> linker and jaraco-packaging for 3.5 only. The dependency is satisfied
>>> because the 3.5 branch matches. However, you have no rule to enforce
>>> 3.5, so sphinx could be actually called with 2.7 and fail.
>>>
>>> This is a generic problem that was pretty much solved by python-any-r1.
>>> I think we should be able to copy the most important pieces of the API
>>> to python-r1 to achieve something similar, i.e. add python_gen_any_dep
>>> to generate the depstrings and make python_setup aware of
>>> python_check_deps(). Then the above would be written alike:
>>>
>>> DEPEND="doc? ( $(python_gen_any_dep '
>>> dev-python/sphinx[${PYTHON_USEDEP}]
>>> dev-python/rst-linker[${PYTHON_USEDEP}]
>>> dev-python/jaraco-packaging[${PYTHON_USEDEP}]
>>> ') )"
>>>
>>> python_check_deps() {
>>> has_version "dev-python/sphinx[${PYTHON_USEDEP}]" &&
>>> has_version "dev-python/rst-linker[${PYTHON_USEDEP}]" &&
>>> has_version "dev-python/jaraco-packaging[${PYTHON_USEDEP}]"
>>> }
>>>
>>> python_setup would verify which implementation has the dependencies
>>> satisfied, and set it for the common code building docs.
>>>
>>> However:
>>>
>>> 1. I think it would work. However, I can't be sure until I implement it,
>>> and even then I might miss something.
>>>
>>> 2. It's a significant extension to the API, and kinda goes against
>>> the goal of making the eclass simpler. However, it mostly fits what is
>>> in python-any-r1 already, so at least it doesn't introduce a new API.
>>>
>>> So I'd like others to chime in and let me know whether they consider
>>> this a worthwhile addition before I start working on it.
>>>
>>> --
>>> Best regards,
>>> Michał Górny
>>
>> Would this bloat python-r1 too much? I understand the need to keep
>> eclasses small and efficient. This looks like it might work, and I'm
>> willing to test it, though I'd need some time to learn how to properly
>> test Python packages. Is #gentoo-python a good place to seek guidance,
>> after looking through docs?
>
> That's the problem I'm most worried of. On the other hand, it's pretty
> much what we have in python-any-r1 already, so expect for physical code
> increase, we're mostly just extending an existing API into additional
> eclass.
>
>> Is this a unique-enough case to justify a python-doc eclass? It looks
>> like it would depend on python-any* or python-r* anyway, so maybe it's a
>> bit redundant. It's an option, though.
>
> I don't think so. It's a complex problem with many different
> implementation details. Even if we wrote an eclass, it would either do
> confusingly little, or have more conditionals than code.
>
>>
>> I hadn't considered the dependency <-> implementation relationship; nice
>> catch! If what you wrote above is as clean as we can get it, I'm
>> willing to help you on it. I'm just not sure how I'd be most helpful
>> since I've never written an eclass.
>
> No need to do that. As I said, it's mostly copy-paste from python-any-r1
> with little changes. I'll get to that soon enough.
>
>
Sounds great; given its simplicity I'm sure we can wait a little while.
Thanks for reconsidering. If there's anything I can do to help, please
let me know.
--
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Should Sphinx really depends on PYTHON_COMPAT/PYTHON_USEDEP for `dev-python/*` ebuilds?
On Fri, May 12, 2017 at 08:32:53PM +0200, Michał Górny wrote:
> On czw, 2017-05-11 at 11:47 +0700, Alex Turbov wrote:
> > DEPEND=( doc?
> > || (
> > (
> > dev-python/sphinx[python_targets_python2_7]
> > # NOTE This packages provide extensions for Sphinx
> > dev-python/rst-linker[python_targets_python2_7]
> > dev-python/jaraco-packaging[python_targets_python2_7]
> > )
> > (
> > dev-python/sphinx[python_targets_python3_5]
> > dev-python/rst-linker[python_targets_python3_5]
> > dev-python/jaraco-packaging[python_targets_python3_5]
> > )
> > (
> > dev-python/sphinx[python_targets_python3_6]
> > dev-python/rst-linker[python_targets_python3_6]
> > dev-python/jaraco-packaging[python_targets_python3_6]
> > )
> > )
> > )
> >
>
> One more thing I've missed in my initial mail. The other problem with
> this solution (alone) is that it doesn't enforce the implementation that
> satisfied the dependency.
>
> Let's take a simple example. You've built sphinx for 2.7+3.5 but rst-
> linker and jaraco-packaging for 3.5 only. The dependency is satisfied
> because the 3.5 branch matches. However, you have no rule to enforce
> 3.5, so sphinx could be actually called with 2.7 and fail.
>
> This is a generic problem that was pretty much solved by python-any-r1.
> I think we should be able to copy the most important pieces of the API
> to python-r1 to achieve something similar, i.e. add python_gen_any_dep
> to generate the depstrings and make python_setup aware of
> python_check_deps(). Then the above would be written alike:
>
> DEPEND="doc? ( $(python_gen_any_dep '
> dev-python/sphinx[${PYTHON_USEDEP}]
> dev-python/rst-linker[${PYTHON_USEDEP}]
> dev-python/jaraco-packaging[${PYTHON_USEDEP}]
> ') )"
>
> python_check_deps() {
> has_version "dev-python/sphinx[${PYTHON_USEDEP}]" &&
> has_version "dev-python/rst-linker[${PYTHON_USEDEP}]" &&
> has_version "dev-python/jaraco-packaging[${PYTHON_USEDEP}]"
> }
>
> python_setup would verify which implementation has the dependencies
> satisfied, and set it for the common code building docs.
>
> However:
>
> 1. I think it would work. However, I can't be sure until I implement it,
> and even then I might miss something.
>
> 2. It's a significant extension to the API, and kinda goes against
> the goal of making the eclass simpler. However, it mostly fits what is
> in python-any-r1 already, so at least it doesn't introduce a new API.
>
> So I'd like others to chime in and let me know whether they consider
> this a worthwhile addition before I start working on it.
>
> --
> Best regards,
> Michał Górny
Would this bloat python-r1 too much? I understand the need to keep
eclasses small and efficient. This looks like it might work, and I'm
willing to test it, though I'd need some time to learn how to properly
test Python packages. Is #gentoo-python a good place to seek guidance,
after looking through docs?
Is this a unique-enough case to justify a python-doc eclass? It looks
like it would depend on python-any* or python-r* anyway, so maybe it's a
bit redundant. It's an option, though.
I hadn't considered the dependency <-> implementation relationship; nice
catch! If what you wrote above is as clean as we can get it, I'm
willing to help you on it. I'm just not sure how I'd be most helpful
since I've never written an eclass.
signature.asc
Description: Digital signature
Re: [gentoo-dev] Should Sphinx really depends on PYTHON_COMPAT/PYTHON_USEDEP for `dev-python/*` ebuilds?
On Sat, May 13, 2017 at 09:32:46AM +0200, Michał Górny wrote: > On pią, 2017-05-12 at 17:42 -0700, Daniel Campbell wrote: > > On 05/11/2017 12:51 AM, Michał Górny wrote: > > > In fact, I'm personally leaning towards not building docs at all > > > in ebuilds. It's practically a wasted effort since most of the time > > > users read docs online anyway. > > > > I believe that's a little myopic; a user (or even developer) may not > > have Internet access all the time, or may not have it in their primary > > development environment. Having a copy of the docs locally (the entire > > point of USE="doc") is super valuable to have when you're away from the > > network. I'm sure I'm not alone as one of the people who uses the flag > > and appreciates the work that goes into making sure said flag works. > > > > Sure, we could yank out every single USE="doc", but then we lose a nice > > feature of the tree and users are back to either (a) trawling the Web to > > find the project site, then hope they have docs in a separate download, > > or (b) we end up with foo+1 packages, one extra for any package that has > > documentation. Neither are particularly good solutions; Debian has done > > the latter and it results in a huge number of packages for little gain. > > The Python team mostly focuses on providing packages for dependencies of > other Gentoo packages, not direct Python development. We do not have > the manpower to go above that. > > -- > Best regards, > Michał Górny Ah, well that at least explains why you're not interested in it. Dependency management alone can be tough; I've not noticed any Python issues, so it seems like you guys do well. :) If you don't mind me asking, what would it take to solve the USE="doc" issue to the Python team's standard? I have some personal interest in Python and wouldn't mind adding 'doc' support for Python packages that users request docs for. Maybe others are willing to join me on this. Is that something we can make happen without getting in anyone's hair? ~zlg signature.asc Description: Digital signature
Re: [gentoo-dev] Should Sphinx really depends on PYTHON_COMPAT/PYTHON_USEDEP for `dev-python/*` ebuilds?
On 05/11/2017 12:51 AM, Michał Górny wrote: > In fact, I'm personally leaning towards not building docs at all > in ebuilds. It's practically a wasted effort since most of the time > users read docs online anyway. I believe that's a little myopic; a user (or even developer) may not have Internet access all the time, or may not have it in their primary development environment. Having a copy of the docs locally (the entire point of USE="doc") is super valuable to have when you're away from the network. I'm sure I'm not alone as one of the people who uses the flag and appreciates the work that goes into making sure said flag works. Sure, we could yank out every single USE="doc", but then we lose a nice feature of the tree and users are back to either (a) trawling the Web to find the project site, then hope they have docs in a separate download, or (b) we end up with foo+1 packages, one extra for any package that has documentation. Neither are particularly good solutions; Debian has done the latter and it results in a huge number of packages for little gain. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Removal of rxvt
On 05/11/2017 08:57 AM, Jason A. Donenfeld wrote: > Hi folks, > > Rxvt is ancient. It's been replace by rxvt-unicode. Rxvt hasn't seen > updates in years. Recently it's been the subject of a security > vulnerability, and I suspect it's filled with other potential > vulnerabilities. Rxvt has no upstream. I tried reaching out to the > former upstream, and it's evident everybody has moved on and has no > interest in further maintenance. It doesn't even have a Gentoo > maintainer! > > Given this, I'd like to remove rxvt from Gentoo, with the usual > mask-for-30-days process. > > Does anybody have any objections to me doing this? (I'll wait a week > from now before taking any actions.) > > Regards, > Jason > Sounds sane to me. It might be helpful to ask if anyone in gentoo-user is interested in proxying, but as far as I know anyone who used rxvt migrated to rxvt-unicode once it was stable. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
[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
Re: [gentoo-dev] [PATCH 1/2] app-portage/eclass-manpages: Add @SUPPORTED_EAPIS tag for eclass
On 04/28/2017 07:06 AM, Michał Górny wrote:
> Add a @SUPPORTED_EAPIS tag that can be used to explicitly provide a list
> of EAPIs that are supported by the eclass. The main goal is to make it
> possible to extract this list with relative ease, for scripting
> purposes. It is not included explicitly in the manpages at the moment.
>
> The first use case is to make it possible to explicitly distinguish
> eclasses that do not support a specific EAPI from eclasses that are not
> used by any ebuilds using a specific EAPI. Therefore, it will make it
> possible to easily detect when we can deprecate old EAPIs from eclasses.
> ---
> app-portage/eclass-manpages/files/eclass-to-manpage.awk | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/app-portage/eclass-manpages/files/eclass-to-manpage.awk
> b/app-portage/eclass-manpages/files/eclass-to-manpage.awk
> index 0b65162c04ec..fe7e9c12d8f5 100644
> --- a/app-portage/eclass-manpages/files/eclass-to-manpage.awk
> +++ b/app-portage/eclass-manpages/files/eclass-to-manpage.awk
> @@ -18,6 +18,7 @@
> # # default: tell people to use bugs.gentoo.org>
> # @VCSURL: https://gitweb.gentoo.org/repo/gentoo.git/log/eclass/@ECLASS@>
> +# @SUPPORTED_EAPIS:
> # @BLURB:
> # @DESCRIPTION:
> #
> @@ -147,6 +148,7 @@ function handle_eclass() {
> eclass = $3
> eclass_maintainer = ""
> eclass_author = ""
> + supported_eapis = ""
> blurb = ""
> desc = ""
> example = ""
> @@ -176,6 +178,8 @@ function handle_eclass() {
> reporting_bugs = eat_paragraph()
> if ($2 == "@VCSURL:")
> vcs_url = eat_line()
> + if ($2 == "@SUPPORTED_EAPIS:")
> + supported_eapis = eat_line()
> if ($2 == "@BLURB:")
> blurb = eat_line()
> if ($2 == "@DESCRIPTION:")
>
Looks like something eclass developers could really use. I say go for
it! I'm not sure what you're talking about regarding _ vs. -; do you
mean the variable name? I think _ makes a bit more sense there since we
use INSTALL_MASK, PYTHON_SINGLE_TARGET, or other variable names with
underscores. Using a hyphen would make it stick out from other similarly
structured variable names.
--
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Suggested sync method/Portage config for devs on ~arch?
Ever since we switched to Git, I've tried to use gentoo.git (or a mirror) to sync from. I later found a configuration that hasufell used at the time. [1] It works well so far, but I wanted to ask the greater developer community what method(s) they employ to sync from our repositories and why it's a good fit for them. I'm hoping that this discussion may lead to suggestions we can put in the devmanual or other documentation to make the "transition" to a developer smoother for new staff, or simply make it easier for our users to be close to the bleeding edge, if that's what they desire. So, for a developer/user using ~arch, what do you use and/or recommend for Portage configuration? Thanks for reading. [1]: https://github.com/hasufell/portage-gentoo-git-config -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] ABI Navigator — a project to search for binary symbols
On 02/23/2017 06:36 PM, Andrey Ponomarenko wrote: > Hello, > > I'd like to present a new project called "ABI Navigator" for searching binary > symbols (functions, methods, global data, etc.) in open-source libraries: > https://abi-laboratory.pro/index.php?view=navigator > > The project allows to find out in which versions of libraries some symbol is > defined, added, removed or changed. The data is taken from the ABI Tracker > project (238 libraries and 0.9 million symbols currently): > https://abi-laboratory.pro/tracker/ > > Example for symbol dwelf_strtab_add from libdw.so (elfutils): > https://abi-laboratory.pro/index.php?view=navigator&selected=dwelf_strtab_add%40%40ELFUTILS_0.167#result > > The project aims to help Linux developers and maintainers to resolve issues > with missed symbols and navigate through the reports in the ABI Tracker. > > Have you ever encountered the "undefined reference" error or want to know > whether the symbol is _stable_ enough to use in your code? Try to find it in > the ABI Navigator! > > Enjoy! > This tool didn't return anything on a quick test (TOX_CONFERENCE_TYPE, part of net-libs/tox, TokTok/toxcore on GitHub), but it did it quickly and it has a clean interface. I'll definitely try using this when I find myself stumped on something. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Package up for grabs: x11-misc/ktsuss
On 01/25/2017 01:17 PM, Gokturk Yuksek wrote: > The following package is up for grabs: > > x11-misc/ktsuss > I can take this; I use it with SpaceFM to do things as root. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Guidelines for IUSE defaults
On 02/09/2017 12:59 PM, Michael Orlitzky wrote: > On 02/09/2017 03:41 PM, Daniel Campbell wrote: >> That's a great question. Based on a cursory look at make.conf's manpage, >> USE_ORDER without 'pkginternal' will ignore IUSE defaults as intended. >> > > This has already been suggested like five times =P > > So long as people insist on using IUSE defaults for flags that are > critical to the package and to satisfy REQUIRED_USE (sprinkled liberally > throughout the tree), this won't work. You'll turn off the defaults that > are critical, too, and throw a wrench into dependency resolution. > > (Just noticed that after I finished reading the thread; d'oh) Hm, good point. A good number of us are against REQUIRED_USE (I don't feel strongly either way), and I'm really not sure why we have packages that won't work at all without specific USE flags. Now that I've read the entire thread I see someone mentioned different arches may need different USE flags, but that seems like something that belongs in the profile, *if* it's a profile problem. I'd be happy if REQUIRED_USE conflicts were handled in one of two ways: 1. emerge throws it up in your face and suggests a change (defaulting to whichever IUSE has a +), which can then be handled with etc-update or 2. emerge prompts you to choose a flag from the ones listed in REQUIRED_USE, obeys it, then does #1 so you can etc-update after merging. The downside to this is it's yet another function to add to emerge. I'm not sure how else we can make use of REQUIRED_USE while simultaneously allowing people the choice to not care. Could an eclass do this reliably? -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Guidelines for IUSE defaults
On 02/09/2017 12:25 PM, Ben Kohler wrote: > > > On Thu, Feb 9, 2017 at 2:18 PM, Daniel Campbell <mailto:z...@gentoo.org>> wrote: > > I support the idea of a profile-set variable that determines whether or > not IUSE is respected. Minimalists get their systems faster, we get > something that adds to Gentoo's versatility and an additional profile. > Of course, we should be asking the anti-IUSE people if that would be > good enough to make the profiles/systems they want possible. > > -- > Daniel Campbell - Gentoo Developer > OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net <http://keys.gnupg.net> > fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 > > Can't this already be accomplished by modifying the USE_ORDER variable? > > -Ben That's a great question. Based on a cursory look at make.conf's manpage, USE_ORDER without 'pkginternal' will ignore IUSE defaults as intended. So if we change that from what I assume to be the default (found in the manpage), a minimalist profile (or system) should be using: USE_ORDER = "env:pkg:conf:defaults:repo:env.d" If that gets combined with a profile meant explicitly for this bare-bones use case, then I don't see why we can't make that happen. It just requires someone who knows the use case to build the profile. Thanks for pointing this out! -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Guidelines for IUSE defaults
On 02/03/2017 02:09 PM, William L. Thomson Jr. wrote: > On Friday, February 3, 2017 2:53:59 PM EST Michael Orlitzky wrote: >> On 02/03/2017 01:33 PM, Patrick McLean wrote: >>> We might as well go back to before IUSE defaults then. Part of the >>> advantage of IUSE defaults is maintainers don't all have to fiddle with >>> the profiles, everything can be self-contained in the ebuild. This >>> drastically complicates maintenance, having two locations to track and >>> change rather than just one. >> >> You still retain the benefit for IUSE defaults that actually belong in >> the base profile, just not for upstream defaults or the ones that you >> personally prefer. > > That is a side effect, as it is more about the package maintainer choosing > the > defaults. They are not messing with profiles. That base ends up with it is > indirect. Otherwise IUSE default flags would have to be per profile rather > than > in the package. Which would create more work for package maintainers. > >>> I suspect that there is a small subset >>> of people interested in this, and perhaps those people could maintain a >>> "minimal" profile that unsets IUSE defaults. >> >> Then every IUSE default gets recorded twice: once when the maintainer >> puts it in the ebuild, and once when I add it (negated) to the minimal >> profile. That's a bad design even if we pretend that I can solve the >> problem of tracking every IUSE change in the tree. > > Sorry if its been suggested, I haven't followed every comment. What about > some > global env variable that could override all default IUSE. That can set in > base, and set what ever minimal IUSE flags that are needed. > I support the idea of a profile-set variable that determines whether or not IUSE is respected. Minimalists get their systems faster, we get something that adds to Gentoo's versatility and an additional profile. Of course, we should be asking the anti-IUSE people if that would be good enough to make the profiles/systems they want possible. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Guidelines for IUSE defaults
On 02/04/2017 01:05 PM, William L. Thomson Jr. wrote: >[snip] >> Maintainers of individual packages have the most knowledge about how to >> best deliver that specific package, but maintainers of profiles have >> the best understanding of what people want to see. > > Yes has to be a balance. I do not believe package maintainers will always > share the vision of the profiles. > > Said another way, if defaults were sane enough, would profiles be necessary? > > Profiles are kind of an extra added benefit to the end user, and those making > the profiles. Mostly a benefit for the end user. There isn't much benefit to > the > package maintainer. I could not really see anything that would give them > reason to spend their time on something that would not benefit them. > I can't speak for other maintainers but generally if there's an issue in an ebuild I maintain, I try to figure out a) the specific problem, and b) the simplest and most-effective solution. If an ebuild I maintain is broken on arm64, for example, it's still my responsibility to figure out how to get it working, assuming the software was written in a way to allow for that build anyway. Since I don't run anything other than amd64 right now, I have to depend on others to find issues for other arches. Generally I'll accept any change as long as it meets our ebuild standards and doesn't exchange one problem for another. One could argue "of course it benefits you", but I don't do it because it benefits me. I do it because a) it fixes a problem I probably didn't know about and b) it's how we make Gentoo better. I don't have an opinion on profiles. I like the idea of them and respect the work that goes into them. If maintainers need to make small changes here or there so their packages work on specific profiles, I don't see the problem. We do commit+push over typos; a profile is more important than that, so naturally we should have little issue ironing out support when the errant wrinkle comes up. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Guidelines for IUSE defaults
. Their was a GSoC project > last summer to work on organizing gentooish kernel builds, but that is a > very big topic. Perhaps the profiles will have to be proposed but not > formalized until folks go out and do some kernel builds and testing > associated with a proposed profile organization? afaik building the kernel is completely outside of Portage's reach. It merely installs the source files needed to build it. Everything else is up to you and/or genkernel. A special kernel fork designed for embedded sounds good, though. I'm sure we've got something like that in the tree (or an overlay) somewhere. > > >> In the same way, we shouldn't be too quick to deviate from upstream >> defaults ourselves (#4 in your example), beyond actual integration >> work. > >> I'll admit the current state is a bit of a compromise, but I don't >> think we should change it unless we're changing it to something >> significantly better. This is a pretty big-impact change. > > > Just formalize some new parts of the profile tree to not be required to > be upstream compliant. Isn't that part of being a 'meta-distribution'? Don't we already do that? KDE, GNOME, and XFCE aren't "upstream" compliant because there *isn't* a single, default upstream DE, so we have profiles for that. If you or others would like to create or improve existing profiles, then that's awesome and you should try to put together some patches or a pull request so we can take a look. > > In my future (and the future of many others) there will be minimalistic > builds on clusters where any number to constructs including > compatibility which will all be solved, at the framework level, not the > base distro level, to the extent possible. Folks are now running a > myriad of windows OS versions on linux (&clusters), so I have just read > about a few days ago. So I'm proposing and working on gentoo > heterogeneous cluster where one can partition part to be for systemd > stuffage, part to be HPC, part to be extraordinarily secure, part to be > aligned with a particularly commercial linux distro, and many other > differing needs based frameworks. > > > The minimal (lowest level) should be clear of all of those distro > encumbrances. CoreOS is taking this approach, as their bare metal > bootstrapping occurs completely and well before systemd or any other > PID1 schema is invoked or becomes a defacto requirement. Gentoo is all > about freedom, right? If we need a new profile, then certainly those who are going to use it should be best equipped to know what needs to be in it, right? This is a great case for building what you need and then sharing it so everyone can benefit. I don't do embedded (though I might tinker with it some day), so I'm definitely not able to know what needs to be in such a profile. We need people who actually work in that sort of stuff to do the work, because if someone like me does it, then it may have too many packages in it, or it won't account for X or Y use case that's super common in embedded, etc. Embedded is an itch, and non-embedded Gentoo people can't scratch it for you because we aren't qualified. If you or others ever manage to make that profile, please share it so others can benefit too. :) > > > hth, > James > Thanks for reading, zlg -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites: leechcraft
On 01/31/2017 09:08 AM, David Seifert wrote: > On Tue, 2017-01-31 at 17:34 +0100, Kristian Fiskerstrand wrote: >> On 01/31/2017 03:50 PM, Georg Rudoy wrote: >>> I'll make a new release of leechcraft itself and bump the version >>> to >>> that new one, so they'll naturally be dropped to unstable, 0.6.70 >>> and >>> earlier (if any) indeed could be removed. Most of the bugs, as I >>> saw >>> them, are due to the current last released version being 2.5 years >>> old >>> and obviously bitrotten somewhat since then. >> >> I'd still recommend spending a bit of time to consider whether this >> doesn't fit better in an overlay, which would also make it easier to >> maintain without overburdening proxy maint given the number of >> packages >> involved. >> > > I really second this - we can ask infra to get you an overlay. Should > it turn out that you are truly maintaining stuff, we can then merge it > into the tree. > I'd like to third it. Overlays are a great way for people (users and devs alike) to try their hand maintaining their own Portage tree. It's great practice and it gives you a single place to reference for people who are using your ebuilds. If it gets formally into layman, I believe our bugzy will cover you, too, in case you don't want to use github. I'd ask infra just to be sure. Overlays for Gentoo are comparable to Debian's and Ubuntu's PPAs and are similarly simple to install/use/delete. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] REQUIRED_USE, global USE flags, user-friendliness...
o this, we'd need a) a message to prompt the user with, b) a way to convey and listen to choices, and c) a way to default to one of the given choices in "automatic" or unattended merges. A good portion of the information is already in the ebuilds. We have IUSE for default flag state and REQUIRED_USE to show us which flags are conflicting. The description for the USE flags can be gleaned from metadata.xml or the profile's package.use.desc. So the hard part is: how do we glue this together? -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Unused profiles
On 01/19/2017 05:25 PM, Anthony G. Basile wrote: > [snip] > > Also, we should just drop a deprecated file into these profiles for now > and wait a year before removing them from the tree. > Agreed. Some sort of deprecation notice would make sense and give people time to figure out a way forward with their machines. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Last-rites: www-plugins/pipelight
On 01/10/2017 11:29 AM, NP-Hardass wrote: > # NP-Hardass (19 Jan 2017) > # Upstream has discontinued Pipelight and Firefox is in the process > # of removing NPAPI support (which Pipelight relies upon), making > # this obsolete. > # Masked for removal in 30 days. > www-plugins/pipelight > > Would this work for Pale Moon by any chance? -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)
On 01/06/2017 12:46 PM, William L. Thomson Jr. wrote: > On Friday, January 6, 2017 9:14:54 AM EST Alec Warner wrote: >> >> The nice thing about ::graveyard or similar is that its a clear demarcation >> between maintained (in tree) and unmaintained (graveyard.) It also means >> that people doing actual maintenance work can basically ignore the >> graveyard as a matter of policy. The ebuilds are archived there (for users) >> but since they are unmaintained they may not work correctly. > > This is what the Java team used to do. There was a java-graveyard-overlay. I > do not believe any package ever moved there came back into the tree. It did > result in a pretty messed up overlay, but makes it a user problem. > > At the same time, something could always be restored from VC. Not like > removal > is removing all history and traces. Thus not sure such overlay is really even > beneficial. Using it could cause lots of problems if they just care about 1 > package or a few. > There's a nice trick around that, actually: let's assume the overlay is called "foo-overlay". In package.mask: */*::foo-overlay will mask all packages in the overlay. You can then add packages to package.unmask: pkg-cat/foobar::foo-overlay That should alleviate most issues, though it can make dependencies a PITA if those deps are also in the overlay. In that case, emerge should yell at you and suggest adding lines to package.unmask. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] bzipped manpages
On 01/10/2017 05:16 AM, Fabian Groffen wrote: > On 09-01-2017 09:08:22 +0100, Jan Stary wrote: >> The particular problem I am having is that http://mdocml.bsd.lv/ , >> my manpage formatter of choice, does deliberately not support bzip >> (or any other outside decompressors for that matter). > > Attached patch works for me. XZ should be a similar exercise, a little > cleanup would be nice then though. > > Fabian > This is awesome; has upstream been sent this yet, by any chance? -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] bzipped manpages
, or whatever the designer has in mind. > > > So hopefully, I have articulated the fact that an 'embedded system' is > determined by the designer, not the underlying hardware from a vendor. > Robust embedded system design, regardless of VHDL or C or ? codes > are more of an art-form than a technical expose on software development. > I know embedded designers that have created thousands of products some > in a matter of weeks, and other teams that fail to produce a single > robust product, in their entire lifetime. The most prolific designer of > them all, is simple referred to as 'doctor bitch' by her subordinates > and friends. Some, more respectfully refer to her as the queen of > assembler, as she has fixed thousands of compiler bugs from a myriad of > compiler vendors, not for compensation, but because the bugs got in her > way... > > > > hth, > James > Whoa, quite a post there! It was a good read. Is this coworker looking for any volunteer distro work by any chance? *wink wink* :P -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New Project: Gentoostats
On 01/06/2017 08:08 AM, Gokturk Yuksek wrote:
> Hi,
>
> Daniel Campbell:
>> On 01/02/2017 09:27 AM, Gokturk Yuksek wrote:
>>> Alexander Shorin:
>>>> Hi!
>>>>
>>>> Thanks for sharing. Would be nice see updated README file (it contains
>>>> outdated links to Not Found pages) and add few notes about comparison
>>>> of your solution with collectd, ussd and the rest modern stats
>>>> collecting tools.
>>>> How better it suites Gentoo machines and why to use it today instead
>>>> of any existed and mature tool?
>>>
>>> We are interested in different kinds of stats with gentoostats. The main
>>> purpose of gentoostats is to collect package statistics, and currently
>>> it does so by utilizing the Portage API. Here's a sample output from the
>>> gentoostats-cli tool that may give you a better idea:
>>>
>>> $ gentoostats-cli search --c sys-apps --p portage --v 2.3.0 --r gentoo
>>> --min_hosts 4
>>> Search results
>>> [{'CAT': 'sys-apps',
>>> 'HOSTS': 5,
>>> 'PKG': 'portage',
>>> 'REPO': 'gentoo',
>>> 'VER': '2.3.0'}]
>>>
>>> There is also other Gentoo-specific information it collects such as this:
>>>
>>> $ gentoostats-cli list arch
>>> Arch
>>> {'amd64': {'HOSTS': 4}, 'x86': {'HOSTS': 1}}
>>>
>>>> --
>>>> ,,,^..^,,,
>>>>
>>>>
>>>
>>> --
>>> gokturk
>>>
>>>
>> Is it too late to suggest more standard flags? `--c` for example doesn't
>> make sense to me since '--' is used more for GNU long options. So it
>> should be '--category' and '-c' instead. Of course that's just my
>> opinion, so take it with salt as usual. :)
>>
>
> That's a typo on my part, thanks for pointing it out :) It's
> '-c/--category', '-p/--package', '-v/--version' and '-r/--repo'. I used
> the long options, then decided to go with the short ones to increase
> readability, forgot to remove extra '-'.
>
>> Still, interesting project and I might run it on a machine if it can
>> help us out.
>>
>
>
I guess we can ignore that little nitpick then. :P
I'll check it out when I get some time to spare.
--
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] New Project: Gentoostats
On 01/02/2017 09:27 AM, Gokturk Yuksek wrote:
> Alexander Shorin:
>> Hi!
>>
>> Thanks for sharing. Would be nice see updated README file (it contains
>> outdated links to Not Found pages) and add few notes about comparison
>> of your solution with collectd, ussd and the rest modern stats
>> collecting tools.
>> How better it suites Gentoo machines and why to use it today instead
>> of any existed and mature tool?
>
> We are interested in different kinds of stats with gentoostats. The main
> purpose of gentoostats is to collect package statistics, and currently
> it does so by utilizing the Portage API. Here's a sample output from the
> gentoostats-cli tool that may give you a better idea:
>
> $ gentoostats-cli search --c sys-apps --p portage --v 2.3.0 --r gentoo
> --min_hosts 4
> Search results
> [{'CAT': 'sys-apps',
> 'HOSTS': 5,
> 'PKG': 'portage',
> 'REPO': 'gentoo',
> 'VER': '2.3.0'}]
>
> There is also other Gentoo-specific information it collects such as this:
>
> $ gentoostats-cli list arch
> Arch
> {'amd64': {'HOSTS': 4}, 'x86': {'HOSTS': 1}}
>
>> --
>> ,,,^..^,,,
>>
>>
>
> --
> gokturk
>
>
Is it too late to suggest more standard flags? `--c` for example doesn't
make sense to me since '--' is used more for GNU long options. So it
should be '--category' and '-c' instead. Of course that's just my
opinion, so take it with salt as usual. :)
Still, interesting project and I might run it on a machine if it can
help us out.
--
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Global USE cuda
On 01/03/2017 06:18 PM, Mart Raudsepp wrote: > Ühel kenal päeval, T, 03.01.2017 kell 11:02, kirjutas Andrew Savchenko: >> Hi, >> >> On Mon, 2 Jan 2017 21:37:43 + Justin wrote: >>> >>> Hi all >>> >>> How about making USE=cuda a global USE? >>> >>> Description: Enable support for nVidia CUDA >> >> Sounds reasonable. > > If this gets implemented, just please make sure to not wipe too much fo > the local descriptions. I see many of them specifying things in detail, > which is very useful to keep around as a description "override" and I > very much appreciate and encourage that. > > >>> >>> Current Situation: >>> dev-lang/pgi: Install PGI's CUDA components (e.g. for OpenACC) >>> dev-libs/libflatarray: Enables plugins for NVIDIA GPUs (e.g. >>> dev-util/VampirTrace: Enable tracing of CUDA calls and GPU >>> kernels. >>> sci-chemistry/ball: Include cuda support >>> sci-chemistry/nwchem: Enable CUDA GPU support for the Tensor >>> sci-libs/arrayfire: Build CUDA backend. >>> sci-libs/bigdft-abi: Enable support for nVidia CUDA >>> sci-libs/libgeodecomp: Enables plugins for NVIDIA GPUs (e.g. >>> sci-libs/trilinos: Add support for cuda (dev-util/nvidia-cuda- >>> toolkit) >>> sci-misc/kaldi: Build with CUDA support. >>> sci-physics/abinit: Enable support for nVidia CUDA >>> sci-physics/bigdft: Enable support for nVidia CUDA GPU >>> acceleration >>> sys-cluster/openmpi: Add GPU direct support >>> app-crypt/johntheripper: Use nvidia cuda toolkit for speeding >>> up >>> dev-libs/libdynd: Enable NVIDIA CUDA toolkit support >>> dev-libs/libflatarray: Enables plugins for NVIDIA GPUs (e.g. >>> dev-libs/starpu: Enable NVIDIA CUDA toolkit support >>> dev-util/nvidia-cuda-sdk: Build CUDA binaries. >>> media-gfx/blender: Build cycles renderer with nVidia CUDA >>> support. >>> media-gfx/k3d: Use nvidia cuda toolkit for speeding up >>> computations >>> media-gfx/nvidia-texture-tools: Enable NVIDIA CUDA toolkit >>> support >>> media-libs/opencv: Enable NVIDIA Cuda computations support >>> media-libs/opensubdiv: Enable NVIDIA CUDA Toolkit support >>> through >>> net-analyzer/suricata: Enable NVIDIA Cuda computations support >>> net-wireless/pyrit: Enable CUDA support via net- >>> wireless/cpyrit-cuda >>> sci-chemistry/ball: Include cuda support >>> sci-chemistry/gromacs: Enable cuda non-bonded kernels >>> sci-chemistry/vmd: Use nvidia cuda toolkit for speeding up >>> sci-libs/cholmod: Use nvidia cuda toolkit for speeding up >>> computations >>> sci-libs/flann: Enable support for nVidia CUDA >>> sci-libs/pcl: Adds support for NVIDIA CUDA. >>> sci-libs/suitesparse: Enable nvidia cuda toolkit for speeding >>> up >>> sci-misc/boinc: Use nvidia cuda toolkit for speeding up >>> computations. >>> sci-physics/espresso: Enable cuda support >>> sci-physics/hoomd-blue: Enable cuda non-bonded kernels >>> sys-apps/hwloc: Enable CUDA device discovery >>> sys-cluster/openmpi: Add GPU direct support >>> >>> More or less consistent in enabling CUDA support. >>> >>> Best, >>> Justin >>> >> >> >> Best regards, >> Andrew Savchenko > +1 -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Packages up for grabs due to retirement
On 01/03/2017 06:31 AM, M. J. Everitt wrote: > On 03/01/17 11:05, Michał Górny wrote: >> On Tue, 3 Jan 2017 16:00:52 +0700 (+07) >> gro...@gentoo.org wrote: >> >>> On Mon, 2 Jan 2017, Brian Evans wrote: >>>> IMO, this one should be given last-rites as upstream is dead and it >>>> heavily depends on wireless-tools and WEXT. >>> I use it on 2 notebooks. It works fine, and is (from my point of view) the >>> most convenient tool to control ethernet and wifi connections on a >>> notebook. Why lastrite it when it works? >> This is the Gentoo Way™. Having a working software is not a goal. >> Gentoo focuses on the best bleeding edge experience and therefore >> highly relies on software packages that are under active development >> and require active maintenance. The packages in early stages of >> development are especially interesting since they can supply users >> and developers with variety of interesting bugs and unpredictable >> issues. >> > From your response I infer the following, please discuss: > 1) "working software is not a goal" .. so we can have a tree full of > broken and/or unstable packages. What is the point of any QA/CI system > if this is applicable? > 2) "require active maintainance" .. by whom exactly? Where are the flood > of keen developers bringing their bleeding edge code (with their > ludicrous packaging requirements and language demands) to Gentoo? > 3) "interesting bugs and unpredictable isssue" .. WTF? > > Michal .. are you (once again...) High .. or is your email (once again) > so soaked in sarcasm we can't tell any useful content from the complete > drivel ... > Maybe I'm weird but I thought it was funny... I'm in favor of keeping software around until it breaks. When there's a non-existent upstream and nobody's willing to take up the helm themselves, it's a clear indication that it's in danger of being treecleaned. In some cases that's good; some packages get left behind and never updated, CVEs get released, nobody cares about the package and it sits masked for a while. Those are the packages we should consider for treecleaning, not just "oh it's been 2 years since a release" or "upstream website troubles". On the latter count, does anyone attempt to reach upstream before suggesting we get rid of the package(s)? Is there not some forum we can use to reach users who may be interested in proxy-maintaining it? This discussion makes me wonder if we need (more) formal guidelines for treecleaning. I think we've got a few people who are eager to clean the tree -- and their goal is admirable -- but until we can get metrics on who's using what, it's hard to say how much damage removing a package will do for users. A thread on gentoo-user re: lastrites might not be a bad idea. Thanks for the laugh Michał. :) -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 1/1] kernel-2.eclass: Point user to additional kernel removal, instructions. See bug #581522.
On 12/27/2016 04:52 PM, Mike Pagano wrote:
> This addresses concerns that users might not realize that after an
> unmerge of kernel sources some files will need to be removed manually.
> The particular concern was specific to the files in /lib/modules/. I
> liked this solution, since it does not require a wordy explanation to be
> written in the eclass.
>
> ---
> eclass/kernel-2.eclass | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
> index 520a4c1..29b2987 100644
> --- a/eclass/kernel-2.eclass
> +++ b/eclass/kernel-2.eclass
> @@ -1619,4 +1619,7 @@ kernel-2_pkg_postrm() {
> ewarn "with modified files will remain behind. By design, package
> managers"
> ewarn "will not remove these modified files and the directories they
> reside in."
> echo
> + ewarn "For more detailed kernel removal instructions, please see: "
> + ewarn "https://wiki.gentoo.org/wiki/Kernel/Removal";
> + echo
> }
>
+1
--
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] toolchain.eclass: set CHOST for gcc-config calls
On 12/26/2016 12:22 PM, Mike Gilbert wrote:
> Bug: https://bugs.gentoo.org/603776
> ---
> eclass/toolchain.eclass | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
> index 55249b00249b..97511ee12440 100644
> --- a/eclass/toolchain.eclass
> +++ b/eclass/toolchain.eclass
> @@ -2119,13 +2119,13 @@
>
> do_gcc_config() {
> if ! should_we_gcc_config ; then
> - env -i ROOT="${ROOT}" gcc-config --use-old --force
> + env -i CHOST="${CHOST}" ROOT="${ROOT}" gcc-config --use-old
> --force
> return 0
> fi
>
> local current_gcc_config target
>
> - current_gcc_config=$(env -i ROOT="${ROOT}" gcc-config -c ${CTARGET}
> 2>/dev/null)
> + current_gcc_config=$(env -i CHOST="${CHOST}" ROOT="${ROOT}" gcc-config
> -c ${CTARGET} 2>/dev/null)
> if [[ -n ${current_gcc_config} ]] ; then
> local current_specs use_specs
> # figure out which specs-specific config is active
> @@ -2159,12 +2159,12 @@ should_we_gcc_config() {
> # if the current config is invalid, we definitely want a new one
> # Note: due to bash quirkiness, the following must not be 1 line
> local curr_config
> - curr_config=$(env -i ROOT="${ROOT}" gcc-config -c ${CTARGET} 2>&1) ||
> return 0
> + curr_config=$(env -i CHOST="${CHOST}" ROOT="${ROOT}" gcc-config -c
> ${CTARGET} 2>&1) || return 0
>
> # if the previously selected config has the same major.minor (branch) as
> # the version we are installing, then it will probably be uninstalled
> # for being in the same SLOT, make sure we run gcc-config.
> - local curr_config_ver=$(env -i ROOT="${ROOT}" gcc-config -S
> ${curr_config} | awk '{print $2}')
> + local curr_config_ver=$(env -i CHOST="${CHOST}" ROOT="${ROOT}"
> gcc-config -S ${curr_config} | awk '{print $2}')
>
> local curr_branch_ver=$(get_version_component_range 1-2
> ${curr_config_ver})
>
>
Seems like an obvious bug and fix; is there any reason passing CHOST
around might be a bad idea? It seems to me that it enforces the behavior
it's meant to have to begin with and makes it more obvious that CHOST is
used.
--
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] [rfc] New global USE flag: rbd
On 12/25/2016 11:45 PM, Andrew Savchenko wrote: > Hi all, > > 8 packages are using either rbd or rados USE flag for Rados > Block Device support: > > use.local.desc:app-backup/bareos:rados - Enable rados storage backend > use.local.desc:app-emulation/ganeti:rbd - Enable rados block device support > via sys-cluster/ceph > use.local.desc:app-emulation/libvirt:rbd - Enable rados block device support > via sys-cluster/ceph > use.local.desc:app-emulation/qemu:rbd - Enable rados block device backend > support, see http://ceph.newdream.net/wiki/QEMU-RBD > use.local.desc:net-analyzer/rrdtool:rados - Enable support for librados from > sys-cluster/ceph > use.local.desc:net-libs/xrootd:rbd - Enable rados block device support via > sys-cluster/ceph > use.local.desc:sys-block/fio:rbd - Enable Rados block device support via > sys-cluster/ceph > use.local.desc:sys-block/tgt:rbd - Add support for ceph block devices > > Suggested description: > rbd - Enable rados block device support via sys-cluster/ceph > > Best regards, > Andrew Savchenko > Do we expect the list of packages using RBD to grow? If so then sure, if for no other reason than to give a consistent description. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Google Code shutdown requires 524 ebuilds to be fixed before end of 2016
On 12/24/2016 05:13 PM, Gokturk Yuksek wrote: > On 11/04/2016 09:36 PM, Jonas Stein wrote: >>>> If you maintain one of these packages, please fix the SRC_URI >>>> and HOMEPAGE variables. >> >>> It would probably be better if the output included the >>> maintainer. >> >> Yes, that is a good idea. >> >> cat googlecode-shutdown.txt | cut -f1 -d":" | xargs equery meta -mH >> | grep "\@" | sort | uniq | sed "s/@/__/g" >> >> I prefer to protect the list at least by substitution. It will not >> help much, but makes me happier ;-) >> > > I've hacked up a portageq-like script [0] to list > ebuilds/packages/maintainers for anyone who is interested. > > [0] https://github.com/gktrk/gentoo-scripts/blob/master/googlecode-uri.py > > -- > gokturk > > Hey, thanks for that script; it helped me find the one package I needed to sort out my gcode stuff. I had a feeling there was at least one I needed to take care of. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2016-12-18 23:59 UTC
On 12/18/2016 11:02 PM, Kent Fredric wrote: > On Sun, 18 Dec 2016 21:08:09 -0500 > Michael Orlitzky wrote: > >> dev-php/ca-bundle20161124-07:43 mjo[1] 7597666 >> dev-php/cli-prompt 20161124-07:21 mjo[1] d3bd351 >> dev-php/composer 20161124-08:09 mjo[1] d273046 >> ... >> >> [1] Author: Guillaume Seren > > +1 > Agreed. Easy to read and credits the appropriate people. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Cross Post due to technical component - Thanks for all the fish
On 12/13/2016 10:47 AM, Christopher Head wrote: > On December 9, 2016 10:12:54 PM PST, "A. Wilcox" > wrote: >> 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. > > You’re right, I took the word “run” in the sense of “execute” (the OS), not > in the sense of “manage” (the organization). If forks are a way to develop > work destined for upstream, they’re great. It’s when they become a tool for > fragmenting the community (of both users and developers) without any hope of > work being recombined that they become a problem. > Sometimes people don't get along or play politics to fight within an organization. At that point, one is forced to route around the social damage and branch off. It's at the "host"'s discretion whether they want to pull from the fork, and I don't think pressuring or forcing either of those groups to work together would be a good idea. I'm applying this in a general sense, to clarify. It's true that it can create a maintenance burden and sometimes even confusion, but what else can you do about volunteers that can't agree on a way forward for a given project? -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] tinfo flag
On 12/07/2016 07:27 AM, Ian Stakenvicius wrote: > On 07/12/16 05:40 AM, konsolebox wrote: >> On Wed, Dec 7, 2016 at 5:16 PM, Michał Górny wrote: >>> On Wed, 7 Dec 2016 16:16:45 +0800 >>> konsolebox wrote: >>> >>>> On Wed, Dec 7, 2016 at 1:23 PM, Michał Górny wrote: >>>>> On Tue, 6 Dec 2016 20:11:34 -0600 >>>>> William Hubbs wrote: >>>>> >>>>>> On Tue, Dec 06, 2016 at 05:26:19PM -0500, Mike Gilbert wrote: >>>>>>> On Tue, Dec 6, 2016 at 4:15 PM, Michał Górny wrote: >>>>>>>> On Tue, 6 Dec 2016 12:54:26 -0500 >>>>>>>> Mike Gilbert wrote: >>>>>>>> >>>>>>>>> On Mon, Dec 5, 2016 at 6:13 AM, konsolebox >>>>>>>>> wrote: >>>>>>>>>> Please consider promoting the use of tinfo flag in packages that >>>>>>>>>> depend on sys-libs/ncurses so that they would synchronize properly >>>>>>>>>> with sys-libs/ncurses[tinfo]. >>>>>>>>> >>>>>>>>> I would rather see the tinfo USE flag removed from ncurses. >>>>>>>> >>>>>>>> vapier doesn't consider this QA violation a QA violation. >>>>>>>> >>>>>>>> https://bugs.gentoo.org/487844 >>>>>>> >>>>>>> Perhaps QA could take some action then? >>>>>>> >>>>>>> Updating ~1500 ebuilds with a [tinfo=] use-dep seems like a poor >>>>>>> solution. >>>>>> >>>>>> >>>>>> Our policies are in the dev manual, so please cite the violation there. >>>>>> If you can't, this is not a qa violation, so please don't call it one. >>>>>> >>>>>> >>>>>> I don't see a problem with the use flag and suggest updating the other >>>>>> ebuilds. >>>>> >>>>> The flag randomly changes ABI, breaking all reverse dependencies. >>>>> Please tell me this is a good practice. >>>> >>>> And there you had just proven that the ncurses package is installed in >>>> two modes, showing that a flag like tinfo is needed to represent them. >>>> It's not the ncurses package's fault. It's the depending packages' >>>> responsibility to properly adapt to it. >>> >>> Packages are not intelligent beings, so they can't have responsibility. >> >> Of course. >> >>> Package maintainers have. You can't expect people to spend a lot of >>> time updating a lot of packages every time a new ABI-breaking flag is >>> suddenly introduced in a core package, if it's not even clear if it >>> going to stay long-term. >> >> So you're suggesting to wait and keep things [partly] broken until >> then. Why not fix things first then remove the [-tinfo] feature when >> everything no longer needs it instead. This is even just a one-time >> solution, and is not much different with the massive number of >> pkg-config patches currently being implemented among ebuilds. (Again, >> I'm not exactly liking the use of pkg-config. I'd rather have a >> simple export since it's good enough, easier to implement, less >> compromising with the source, and is more universal.) >> > > Here's the thing -- ncurses provides all functionality regardless of > whether it's split into two libs (libncurses+libtinfo) or not. So > what this flag is really doing is providing the capability of linking > to just part of ncurses instead of all of it, if a project desires. > And projects(binary ones at that) are doing this, which is why we have > some deps that require the tinfo flag to be enabled currently. > > There is only one instance of a dependency atom that requires the > tinfo flag to be disabled, and that package is an old game whos build > system and ebuild is flawed in this regard. All others are fine with > the flag being enabled so far as I can tell (and if they're not then > it's a bug that needs to be addressed anyhow). > > SO, in summary, it would seem to make sense (since anything prebuilt > will work as-is, and anything compiled will be built to work with it) > to remove the tinfo flag but force libtinfo to be built and installed > -- simply make it non-optional. Additionally, we can set > SLOT="0/6tinfo" which will trigger subslot rebuil
Re: [gentoo-dev] rdp vs rdesktop vs freerdp USE flags
On 12/08/2016 06:10 AM, Doug Freed wrote: > On Thu, Dec 8, 2016 at 7:38 AM, Andrew Savchenko wrote: >> Hi, >> >> On Thu, 08 Dec 2016 11:29:51 +0100 Pacho Ramos wrote: >>> When looking at freerdp reverse deps I noticed we are using three different >>> names for USE flags enabling freerdp support: rdp, rdesktop and freerdp >>> >>> rdesktop is the only one that is a global USE flag, even if it's used only >>> by >>> two packages, the others are local USE flags that are enabling similar >>> supports. >>> >>> What should we do? Move all to rdesktop? >> >> Move everything to rdp, since this one is most common; add it to >> global flags and remove rdesktop from the list. > > +1; RDP is the protocol, whereas freerdp/rdesktop is the > implementation. This allows one to later replace the dependency with > an any-of or virtual, without needing to change the useflag. > > -Doug > dwfreed > +1 here. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Cross Post due to technical component - Thanks for all the fish
On 12/11/2016 02:00 AM, Markos Chandras wrote: > On 12/11/2016 08:05 AM, Daniel Campbell wrote: >> On 12/07/2016 07:36 AM, Jorge Manuel B. S. Vicetto wrote: >>> On Wed, 7 Dec 2016, Jorge Manuel B. S. Vicetto wrote: >>> >>> >>> >>>> I'm asking recuiters directly, but unless someone changed the rules >>>> and I was distracted, irc is not mandatory. >>> >>> I've got confirmation that nothing has changed, so irc is not mandatory. >>> I hope this clears any misunderstandings and puts an end to any >>> speculation. >>> >>> Best regards, >>> Jorge Manuel B. S. Vicetto >>> Gentoo Developer >>> >> Would you mind telling us who told you that? I don't disagree or >> anything, but if others have further questions, we should route them to >> the person you spoke with. >> > > I did. No, do not redirect them to me. If the wiki does not clarify > that, then fix the wiki. > > But seriously, are we arguing here about connecting to IRC for a few > hours in your entire dev-hood? Is this really *that* hard? Or is it just > another excuse to complain about the whole process? > > Anyway, nobody (to my knowledge) ever got rejected because he/she did > not have IRC access so please stop speculating and throwing flamebaits > here and there. We have more than enough already. > I think maybe you're mixing me up with someone else. That said, editing the wiki sounds good since it'll save developer time. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Cross Post due to technical component - Thanks for all the fish
On 12/09/2016 09:46 PM, Christopher Head wrote: > On Wed, 7 Dec 2016 12:15:06 -0500 > james wrote: > >> Being able to use stage-4 or stage-5 (G. forums) installs to rapidly >> provision a collection of bare-metal systems [BGO-593218] into a wide >> variety of hardened clusters is my passion. Unikernels as stage 4 >> packages can then very easily be targeted for very specific needs: VM >> or container or bare-metal. 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? Not unlike competing >> micro_breweries, it make the entire craft much stronger and better >> for all. >> >> >> 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. >> Isn't that pretty much what Google and CoreOS do now, as well as the >> gentoo derivative OS? Why not accelerate what has worked, for the >> few, to emancipate those of us still chained into user-land servitude. > > 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. > > As an ordinary user, what I *want*, is to install one OS and not think > about it again. Ideally, Gentoo. When I want to do embedded > development, I just emerge dev-embedded/thingy. When I want to do some > math, I just emerge sci-mathematics/octave. Most things that most > people care about in the main tree. Breaking things up into overlays or > different OSs or whatever just means adding more hoops that I have to > jump through before I can start working on a new topic. > Unfortunately even with a rich technical foundation (like Gentoo's) can't ensure that happens. Forks are patches around social problems or (sometimes, but rarely) technical disagreements. As much as some would insist that libre software is purely technical, there's an important and prevalent social component that influences the technical side. At some point or another, people can't work together and as a result the ebuilds scatter. Adding overlays via layman is dead-simple, and iirc you can use bugzie to file bugs against any official layman overlay. There *are* ways to deal with overlays in a mostly centralized manner. The layman list and bugzilla support goes a long way to making that possible, and the guys behind it did a great job. One Size Fits All is a dream. It sounds great on paper, but when it comes time to Just Do It™, you get all the messiness that comes with wetware and the disagreements on software. I see where you're coming from and yes, it'd be nice if we could all just use Gentoo. But reality (read: volunteering) doesn't work that way. If you have any issues with overlays, please, use the ML or #gentoo so somebody can help you out. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Cross Post due to technical component - Thanks for all the fish
On 12/07/2016 07:36 AM, Jorge Manuel B. S. Vicetto wrote: > On Wed, 7 Dec 2016, Jorge Manuel B. S. Vicetto wrote: > > > >> I'm asking recuiters directly, but unless someone changed the rules >> and I was distracted, irc is not mandatory. > > I've got confirmation that nothing has changed, so irc is not mandatory. > I hope this clears any misunderstandings and puts an end to any > speculation. > > Best regards, > Jorge Manuel B. S. Vicetto > Gentoo Developer > Would you mind telling us who told you that? I don't disagree or anything, but if others have further questions, we should route them to the person you spoke with. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] tinfo flag
On 12/06/2016 06:44 PM, Mike Gilbert wrote: > On Tue, Dec 6, 2016 at 9:11 PM, William Hubbs wrote: >> On Tue, Dec 06, 2016 at 05:26:19PM -0500, Mike Gilbert wrote: >>> On Tue, Dec 6, 2016 at 4:15 PM, Michał Górny wrote: >>>> On Tue, 6 Dec 2016 12:54:26 -0500 >>>> Mike Gilbert wrote: >>>> >>>>> On Mon, Dec 5, 2016 at 6:13 AM, konsolebox wrote: >>>>>> Please consider promoting the use of tinfo flag in packages that >>>>>> depend on sys-libs/ncurses so that they would synchronize properly >>>>>> with sys-libs/ncurses[tinfo]. >>>>> >>>>> I would rather see the tinfo USE flag removed from ncurses. >>>> >>>> vapier doesn't consider this QA violation a QA violation. >>>> >>>> https://bugs.gentoo.org/487844 >>> >>> Perhaps QA could take some action then? >>> >>> Updating ~1500 ebuilds with a [tinfo=] use-dep seems like a poor solution. >> >> >> Our policies are in the dev manual, so please cite the violation there. >> If you can't, this is not a qa violation, so please don't call it one. >> >> >> I don't see a problem with the use flag and suggest updating the other >> ebuilds. > > The USE flag introduces needless complexity for zero benefit. Please > explain to me why this is a good idea. > As an onlooker, I don't see anything in favor of getting rid of it, and otherwise it seems like a normal USE flag. All that's been said in favor of removing it is just statements that tell me it's more complex or that it's a QA violation. Could you explain so other people (and myself) understand what you're talking about? -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Proposal for addition of distribution variables
On 12/05/2016 03:49 AM, Rich Freeman wrote: > Here is a separate thought. Would it make sense in any way to try to > have a more established way to communicate with our downstream distros > about stuff like this, like a gentoo-derivatives mailing list or such? > I wouldn't restrict access or anything like that, but participants > would be expected to stay on-topic (it isn't another gentoo-dev or > gentoo-user/project). Changes could still make their way onto the > main lists. I was just thinking that we don't really have any > official way to notify downstream distros of changes like these. Sounds like a good idea to me. We could even allow technical support there ala -user, but with a focus on 'remixing' or otherwise forking/copying Gentoo. It makes sense for a meta distro to assist in the 'meta' part, if only for informational reasons. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Proposal for addition of distribution variables
On 12/04/2016 07:20 PM, Sam Jorna wrote: > On Sun, Dec 04, 2016 at 09:13:23PM -0600, A. Wilcox wrote: >> to read over it. (Would it be more desirable to have all changes in a >> single large commit, or one commit per package?) > > I'd think this is one of those cases best suited to a branch and merge > commit - best of both worlds. > > But that's just my two cents. :) > Yeah. Small, but numerous changes in many different locations aren't really suited to our usual one-commit-per-logical change bit. It might be better to branch off, run the sed call or whatever will be used to update the entire tree, then submit a PR. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Proposal for addition of distribution variables
On 12/04/2016 06:58 PM, 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. > 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? 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. 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). 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. 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. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] (OT) Accounting systems: Ledger-CLI vs GNUcash
On 12/04/2016 04:03 PM, M. J. Everitt wrote: > On 04/12/16 23:49, Robin H. Johnson wrote: >> On Sun, Dec 04, 2016 at 11:07:59PM +, M. J. Everitt wrote: >>> I gather both Quickbooks and Sage have a more modular approach to >>> "proper" accounting software applicable to small and large businesses. I >>> know my mother used Quickbooks in the past with good success and the >>> support of her accountant, but Sage is known to be equally accessible. I >>> would imagine there is an appropriate version for not-for-profit or >>> charities, perhaps you can seek advice with the person(s) already >>> contacted for accounting/finance purposes?! >> Our CPA (Yes, we do have one) only recommends QuickBooks, but has used a >> variety of other proprietary systems (none of which he recommends at >> all!). >> >> The catch is that either Quickbooks or Sage would be a violation of the >> social contract's libre-licence dependence clause. >> >> Ledger HAS filled most of our needs thus far, but lacks in reporting and >> some automation: >> - I'd love to automatically generate lots of depreciation >> entries, but can't yet. >> - Something to anonymize private information in some entries, so that >> the actual Ledgers can be published for transparency. >> > Thanks for the clarification, Robin. It may be worth reviewing that > social contract to allow us better compliance if deemed worthwhile! > > :] > Compliance with what? If others desire Quickbook support, they can make a tool to convert from ledger. There's no good reason for a non-profit, libre software organization to use and depend on proprietary software. Did nobody learn a lesson from BitKeeper? -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] OT Who runs Gentoo was -> RFC: Userkit.eclass
On 12/04/2016 10:10 AM, james wrote: > On 12/04/2016 02:22 AM, Robin H. Johnson wrote: >> On Sat, Dec 03, 2016 at 06:30:29PM -0500, William L. Thomson Jr. wrote: >>>> >>>> Net Total: $50,924.19 >>>> >>> So from 09-16 avg of ~$4.6k per year over 11 years. >> 10 years of participation, 9 of which we got paid for. So ~$5.7k/year. >> If we got paid for 2013: ~$5.4k/year over 10 years. >> >>> With that really being earned by people doing GSoC. Not the same as if >>> Google donated a lump sum of money to further development per say the >>> Councils plans. Only 1 hardware donation. >> That's the payment to the organization for mentoring and managing the >> students, separate from what the students doing GSoC earned. >> >> If the student's work was of use to Gentoo, then it's ALSO $5000-$5500 >> per student that we've had in man-hours. I do use that disclaimer, >> because I know the integration rate for Gentoo students much lower than >> it should be. >> >> 2006: 10 students >> 2007: 8 students >> 2008: 5 students >> 2009: 6 students >> 2010: 16 students >> 2011: 14 students >> 2012: 8 students >> 2013: 6 students >> 2014: 3 students >> 2016: 5 students >> >> Total: 81 students. >> Assuming $5k/student: $405,000 in student payments, over 11 years. >> >> I don't know how many students we've failed: I do know it's been at >> least one (I failed them. Their original mentor had medical issues, I >> took over, and they provided a mocked video of their work and no code by >> midterm). >> >>> I believe past sponsors such as GNi incurred costs in the ~$5k range >>> monthly. >>> I would assume some hosting sponsors to be averaging a few thousand >>> at minimum >>> per year. >> The cost to GNi was much closer to $1k/month, mostly in potential lost >> revenue if the hardware COULD be used for income (it was already a sunk >> cost, and didn't have other users). For our present major hosting >> sponsors, I believe we're more in line with $250-$400/month, but again >> mostly older hardware that isn't of much other salable use. >> >>> Just as an example. FreeBSD is seeking $1.25 Million in a fundraiser >>> with >>> $882k thus far. >>> https://www.freebsdfoundation.org/ >> $1.25M is their annual fund-raising target for this year and last. Not a >> specific fund-raiser, but their annual target. >> For 2016 Q1-Q3, on the $1.25M, they report $293k in contributions. >> For 2015, on a $1.25M target, they reported $657k in contributions. >> For 2014, on a $1M target, they reported $2.4M in contributions. >> >>> They seem to average in the hundreds of thousands every year in >>> contributions >>> https://www.freebsdfoundation.org/about/financials/ >> They're also got a good few years on us (as do Apache). >> >>> Always looked at FreeBSD when I was a Gentoo Trustee. Great >>> foundation! Passed >>> the 5 year probation period with IRS, and other stuff. >> The Apache Foundation was very beneficial to look at I found, because >> they kept superb public records, but also were not hampered by some of >> our restrictions about depending on non-open software (they & the perl >> foundation BOTH use QuickBooks on Windows for their accounting). > > > GNUcash is superior to Quickbooks, as it is a 'double entry' accounting > system. Last time I check Quickbooks was not 'double entry' and that is > a big deal in accounting. There is a module that allows entries via > Android now with GNUcash, but is not an official part of GNUcash.org. I > use GNUcash with my company, but not the Android smartphone module. > > > http://gnucash.org > > http://www.techrepublic.com/article/gnucash-a-powerful-mobile-financial-tool-for-android/ > > > > Serious inquires could be directed to 'gnucash-u...@gnucash.org' as this > accounting software is robust, under active development and even the > devs 'chime in' on routine basis. All in all, gnucash is an > outstanding piece of FOSS software; much better than Quickbooks as many > on the discussion lists attest to on a routine basis. It is in portage > and it runs on windows and other platforms. > > > hth, > James > > >> https://www.apache.org/foundation/records/ >> >> I draw your attention to their last 990 filing: >> https://www.apache.org/foundation/records/990-2014.pdf >> - $1.2M in annual income >> - $858k spend on infrastructure, >> of which >$400k was marked directly as IT spending. >> - $1.8M in net assets >> > > iirc, we're using Ledger (http://ledger-cli.org), which is also double-entry accounting. It uses a text file for its information, and has a ton of reporting features that make it trivial to produce reports. I use it to manage my personal finances, as well. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
