[gentoo-dev] Last rites: media-fonts/culmus-ancient
# Ben de Groot (21 Feb 2015) # Duplicates media-fonts/culmus[ancient] (bug #486814). # Masked for removal in 30 days. media-fonts/culmus-ancient -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Policies for games dirs, new group "gamestat" for sgid binaries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/19/2015 06:19 AM, Ulrich Mueller wrote: > Hi all, As decided by the Council in its 20140812 meeting [1], > every developer is allowed to commit and maintain games ebuilds. > Furthermore: > > | There is consensus amongst council members that specific > policies | (e.g., games group, /usr/games hierarchy, and > games.eclass) should | be settled by the QA team. > > In yesterday's meeting the QA team has unanimously accepted the > following policies (see bug 537580 for details): > > 1. Directories /usr/games, /usr/games/bin, /usr/games/lib*, > /usr/share/games, /var/games, /etc/games, and /opt must be owned by > root:root and have permissions 755 (i.e. the default). > > This will require a small change in games.eclass, because > currently prepgamesdirs() changes ownership of these directories to > root:games and mode to 0750, so they are readable only by users > that are members of the "games" group. With attached patch, > games.eclass will no longer change permissions of the top-level > directories (mostly, these are identical to the FHS locations). > > If a package needs access control, it can still change ownership > and permissions of individual files, or of a subdir that it uses > exclusively. Owner and permission bits of directories that are > shared by multiple packages should be left alone, though. > > 2. A new group to allow setgid binaries to access shared > score/state files will be created. The name of this group will be > "gamestat". > > It is quite common for upstream packages to save shared scores or > other state files under /var/games, and access them with the > program (or a special helper) setgid to a low privilege group. In > most distros, that group is called "games" (see for example > Debian's policy in [2]). > > Unfortunately, the "games" group (gid 35) cannot be used for that > purpose in Gentoo, because by the long-standing games.eclass policy > it was/is used to control access to games. Therefore, regular users > on many Gentoo systems will be in this group. > > Gid 36 is available and can be used for the new "gamestat" group. I > don't think that we need a new eclass for this; creation of the > group would be simply one line in pkg_setup(): > > enewgroup gamestat 36 > > Ulrich > > [1] > http://www.gentoo.org/proj/en/council/meeting-logs/20140812-summary.txt > > [2] https://www.debian.org/doc/debian-policy/ch-customized-programs.html#s11.11 > When this becomes more widespread, what action are users urged to take in order to "migrate" to the new system? Should our everyday user account be removed from the `games` group, and the group should be removed altogether? -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJU5/muAAoJEJUrb08JgYgHSMMH/i6WPhk4gsQlFlMZVarsXrne /uyiFJ/IdQZUOWwgBH1Vl0WI55hPaqYKY2Myxv3tzFv2TDvAPa4NCZNZUBC1mPU0 d/JMhtPRTb74e3S/xy9yurwtprSIY1T843MO3/TUfEg6WS+oJnht4CqniZfYuMyl 9pqIW3XT+225TUnWSzsoaKcxGcORRtTBibUqNadDzCgkOfbtXrPx/FldwDySGAkW rNm0Q6yRbnZX+drwZbQAr33LjtfjkJKE52mRciO7UzHeRT8jECX3pdnQ+4eNxRsW +voNagAeqvisdi/zz6iKLaeUUb9TMhTnsk+5QK2TTP6kdMJeTByJXjHYGVMzZlQ= =M4Fe -END PGP SIGNATURE-
[gentoo-dev] [RFC] please review ebuilds for neovim and deps
At the suggestion of radhermit, I'm putting my neovim & deps ebuilds up here for review, before I commit them to the official tree. Do you see any possible improvements? Right now the neovim ebuild does not install any global default nvimrc like we do with vim. We should probably consider doing so. Also, I'm looking for the best way to let neovim use the vim plugins we install in $VIMRUNTIME (such as gentoo-syntax). The ebuilds are available in my personal dev overlay, and I'm attaching them to this mail. -- Cheers, Ben | yngwin Gentoo developer neovim-0.0.0_pre20150220.ebuild Description: Binary data libtermkey-0.17.ebuild Description: Binary data msgpack-0.6.0_pre20150220.ebuild Description: Binary data unibilium-1.1.1.ebuild Description: Binary data lua-MessagePack-0.3.2.ebuild Description: Binary data neovim-python-client-0.0.28.ebuild Description: Binary data trollius-1.0.4.ebuild Description: Binary data
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: fcaps.eclass
20.02.2015 11:32, Alexis Ballier пишет: > Unless I missed something, QA is not the deciding power, council as a > last resort representation of the dev community is; I guess that's why > we're still having this conversation on gentoo-dev ml. But until you have decision from Council, overriding our decision - you should stick to it as per our GLEP. Moreover, this is not suddenly created bound to developers, that popped out from nowhere. This is justification of our current policy that is forgotten by some of the developers - no more, no less. As said before - you can either provide other solution yourself or appeal to Council. -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Quality Assurance project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Call for help: app-admin/chef
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello, as app-admin/chef is still missing a dedicated maintainer and the outdated version depends on a vulnerable library [1] plus being still ruby19-only, we are going to treeclean it soonish. If you want to help out here, feel free to ask in #gentoo-ruby. Cheers, Manuel [1] https://bugs.gentoo.org/show_bug.cgi?id=540254 On 27.07.2014 21:33, Matthew Thode wrote: > On 07/26/2014 08:38 AM, Manuel Rüger wrote: >> Hello, >> >> app-admin/chef and its related packages are currently >> maintainer-needed. >> >> So if you're using chef on Gentoo, this is your chance to step >> up! >> >> These packages have some restricting dependencies (e.g. >> > Currently two version bumps (one major, one minor) are missing >> [1]. >> >> Ruby herd is willing to assist and help to work with ruby >> eclasses. >> >> Feel free to ping me on IRC (#gentoo-ruby) if you want to help >> out, otherwise we will have to treeclean it sooner or later. >> >> Cheers, >> >> Manuel >> >> >> [1] >> https://bugs.gentoo.org/buglist.cgi?quicksearch=app-admin%2Fchef&list_id=2433248 >> > >> I'm going to be working on app-admin/chef (client), might make a package > for omnibus-install type thing from the deb they provide for the > server. > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0 iQJ8BAEBCgBmBQJU58fJXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4MDA1RERERkM0ODM2QkE4MEY3NzY0N0M1 OEZCQTM2QzhEOUQ2MzVDAAoJEFj7o2yNnWNclGgQAL1TuC0kw7RMLeitgtRXRD0G vWlE+WA6/+669NzSQkL54hJTORSo/3TBCitNIgVU9i0Iv5Sg+h5wHfsfaBuXC6Cr cz3GzDmMrD1vvzwNZlT656Ax4qptElR1806hpxKrThdk02d1Jd6oajL9YO8GVe+J ttIAVUlGOi17bd7wFatpSbBi+VNjX1+UKD9Frc+lLamCQqugigGbpX5cYaAa/5cb cQlsRiKEaYmnnW4V4SUxVT+mVn8NHnR++q/88sNWZNyO2iwS2+18P1XkU1PANBaT LixIBhKMS0LUXEJ4x0CRUlIPusBig31jk/JbeIDwZfLfUuweXjHFKj+YIeGtiPAY TIeByho32u63xc7DO3EAfpDN0Ueag12hP1BHE1k9mh1xwZpXYsOBYdbwc9yOV1dt +dvIUwEBSozKOKXkBcO76ulSHTMBM704+RkUWNaS47Gh1OBuLHU60HTwZvZ07fDw rs3IpKp1iqvNKqO767FvKwl1L2jOtBIC+jJq6KBXOcqyUzZ2UGZWfqv6JLtuOZIY /Hk4xJvWK2eX5vGaN3+y52N7jq3SvgS2IJymRaooiGn0Dbv/MVHMd9wIB010zIHJ qPK2SAAQqULnwIsWiKu3t2p35/8gvBKcJiav+bv/elsPS7++FmDWjy69Cq9tK/IZ H56WJGj1fVqwo+4h5E8E =y+5N -END PGP SIGNATURE-
[gentoo-dev] [RFC] Make "seccomp" USE flag global
Hello, at this moment 8 packages uses "seccomp" flag: app-admin/clsync app-emulation/qemu app-emulation/lxc net-dns/bind net-misc/tlsdate net-misc/tor net-misc/lldpd sys-apps/systemd for the very same reason: enable seccomp filtering to improve security. Some of them use seccomp directly via system calls, while other rely on sys-libs/libseccomp, but this should have no difference for users. I propose to add global "seccomp" USE flag as follows: seccomp - Enable seccomp for system call filtering and remove local descriptions for affected packages. Comments? Best regards, Andrew Savchenko pgpcA_5pO8deF.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: fcaps.eclass
On Thu, 19 Feb 2015 09:42:27 -0500 "Rick \"Zero_Chaos\" Farina" wrote: [...] > >> We've had this discussion before ... so ... > > > > > > what i remember of it is someone adding a ChangeLog file to eclass/ > > and sending an email to ask people to fill it. Mind sharing a link ? > > > > I think I'll add ChangeLog to every category and ask people to fill > > it whenever they make changes to a package in that category. This > > would have the same level of usefulness as a ChangeLog in eclass/. > > This kind of comment isn't productive, let's stick to being > productive. That's because I haven't given the reasons: per-category changelogs would give long-term tracking with bug references and credits for package additions and removals. > If you feel that the commit log is "good enough" then open a bug > assigned to QA to remove the existing Changelog. If the existing > Changelog is removed then our policy would be that it doesn't need to > be updated anymore. Not sure how many people would need to sign off > on that idea, but that would be the process. Unless I missed something, QA is not the deciding power, council as a last resort representation of the dev community is; I guess that's why we're still having this conversation on gentoo-dev ml. Alexis.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: fcaps.eclass
On Thu, 19 Feb 2015 14:39:28 +0200 Markos Chandras wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 02/19/15 13:38, Alexis Ballier wrote: > > On Thu, 19 Feb 2015 19:34:28 +0800 Patrick Lauer > > wrote: > > > >> On Thursday 19 February 2015 12:31:27 Alexis Ballier wrote: > >>> On Wed, 18 Feb 2015 22:48:27 +0100 > >>> > >>> Michał Górny wrote: > Dnia 2015-02-18, o godz. 16:11:53 > > "Mike Frysinger (vapier)" napisał(a): > > vapier 15/02/18 16:11:53 > > > > Modified: fcaps.eclass Log: clarify > > USE=filecaps intention #540430 > > > > Revision ChangesPath 1.11 > > eclass/fcaps.eclass > > Please commit the missing ChangeLog update and remember to > update the ChangeLog after changing any eclass in any way. > This is an official policy for any commits to the Gentoo > repository [1] and a lack of consistency in entries to the > ChangeLog is confusing to our developers and users. > > [1]:http://devmanual.gentoo.org/ebuild-writing/misc-files/changelog/index. > > > html > >>> this policy is about packages; cvs log is *mch* better than > >>> any global changelog for eclasses: who will dig into a > >>> thousand changelog entries to find what changed in fcaps.eclass > >>> ? > >>> > >>> if you want changelogs in eclass/, make it per-eclass, like it > >>> is already per-package. > >>> > >> > >> We've had this discussion before ... so ... > > > > > > what i remember of it is someone adding a ChangeLog file to eclass/ > > and sending an email to ask people to fill it. Mind sharing a link > > ? > > > > I think I'll add ChangeLog to every category and ask people to fill > > it whenever they make changes to a package in that category. This > > would have the same level of usefulness as a ChangeLog in eclass/. > > > > Alexis. > > > We had the same discussion again in the past > > http://archives.gentoo.org/gentoo-dev/msg_51d268a7757fd90fbda77d373a2664f8.xml > > and again > > http://www.gossamer-threads.com/lists/gentoo/dev/262085 > > we can't keep having the same discussion. Funny I didn't remember this one. Guess my opinion hasn't changed since then. > The original changelog discussion is here > > http://archives.gentoo.org/gentoo-dev/msg_c3436497e445eaf86deea08772e5.xml > > There were no objections so we started using it > > http://archives.gentoo.org/gentoo-dev/msg_72fafb93225c9f5559415356eb093f44.xml > > Can we please bookmark them for future reference? From the first link above, I see a proposal and a few agreements. Unless I missed something, there is no mention of making it a policy, and even less a policy that should be blindly followed and enforced without thinking about its usefulness. From the very first link in your reply, I see a proposal to auto-generate the ChangeLog and stop annoying people for filling it. I understand from the fact that people really needing a ChangeLog there haven't made it happen as either nobody needs a ChangeLog there, or nobody cares enough. However, we still continue to see people being picky and asking people to fill ChangeLogs. How fun. Alexis.
Re: [gentoo-dev] arm64 update
On 19/02/15 01:05, Anthony G. Basile wrote: I have about $1000 in grant money. Want to recommend some equipment? The dragonboard might be good BUT there are doubts on software availability. lu
Re: [gentoo-dev] About reducing or even removing stable tree for some arches
On Mon, 16 Feb 2015 10:59:06 -0500 Joshua Kinard wrote: > Once we complete the git migration, why not take a second look on > using a stable/testing/unstable (or -RELEASE/-STABLE/-CURRENT) system > used by Debian and FreeBSD? That should be entirely doable under a > git tree versus CVS. It would require beefing releng up again and a > whole host of other issues. > > Keep the core git tree constantly rolling forward, have a dedicated > branch get cut say, once a year (or less -- Debian is ~18mo?), > another group of devs works on stabilizing that (and periodically > cherrypicking from the master branch), and when the time comes, > totally freeze that for security revs only by a smaller group of devs? Personally, one of the things that I love about Gentoo is that I never have to deal with EVERYTHING changing all at once. Sure, things may change more often through the year than they do with staged releases, but it’s all spread out over the year, so that in any given week, what changes is a nice, bite-sized chunk of my system, so that I can easily isolate and deal with any problems—rather than a staged release that upgrades 150 packages, leaving a dozen things broken and no idea where to start looking. Also, from a more pragmatic point of view, I don’t particularly want to have to *compile* a year’s worth of new packages at one moment in time—better to spend an hour here, an hour there, spread out over the weeks. -- Christopher Head signature.asc Description: PGP signature
[gentoo-dev] Fwd: Last rites: media-plugins/vdr-setup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - Weitergeleitete Nachricht Betreff: Last rites: media-plugins/vdr-setup Datum: Fri, 20 Feb 2015 14:17:43 +0100 Von: Joerg Bornkessel An: gentoo-dev-annou...@lists.gentoo.org Masked for removal around 20/Mar/2015 dead on upstream since any years we don't support this plugin with media-video/vdr's extpng (Extensions Patch) anymore no other package depends on this. wrt bug 540788 we suggest to use media-plugins/vdr-menuorg as alternative -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: added by hd_bru...@gentoo.org iD8DBQFU554ydn07HTTCgIoRAoB5AKC5CMdY2BrlXd32JS+yUxtvB8bNwACbBnoE V+khjd70YWa8wTfgeR4MtVI= =3GJl -END PGP SIGNATURE-
Re: [gentoo-dev] Re: vmware team needs help
On Sun, 15 Feb 2015 11:36:50 +0200 Markos Chandras wrote: > > No one is going to boot you for inactivity if you have nothing to > > do. You might get an "are you alive?" email, but assuming you > > answer within a few weeks, "all my work is done" is the best reason > > to be doing nothing. > > > > > That is true yes. There is a difference between "I have nothing to do" > and "I am not interested in doing anything anymore". If you only > maintain one package and you commit once a year so be it :) It's a > volunteering project so nobody can actually force you to maintain a > certain rate of commits per $time. > In case you appear inactive, people will send you a fair amount of > emails over a significant period of time before they start the > retirement process OK, thanks for the clarification—I was honestly under the impression that, to be a dev, one was *expected* to pick up a lot of packages and spend a lot of time. Good to know that’s not the case. -- Christopher Head signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/watchdog: watchdog-0.8.3.ebuild ChangeLog
On Thu, Feb 19, 2015 at 8:07 PM, hasufell wrote: >> Devs should be communicating with maintainers when they touch their >> packages. > > That's basically all I said. > > The rest looks like imagination and flame about elephants and the end of > the world while I clearly didn't refer to any of that. > > This isn't about "protocol", it's about trust. I agree with you that Justin should have pinged you before bumping; I also happen to think the way you phrase your email is not really conducive to a conversation. I think you could have started by asking Justin privately to next time please ping you (if it was his first "offense"), and only raise a stink (your email was pretty matter of fact -- which also makes it look quite hardass -- I think softening your tone could help quite a bit) after repeated offense. Cheers, Dirkjan
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: fcaps.eclass
On Fri, 20 Feb 2015 16:23:41 +0300 Sergey Popov wrote: > As said before - you can either provide other solution yourself or > appeal to Council. sadly, things I have no need for get at the bottom of my TODO list, if at all, and usually never get done.
[gentoo-dev] Policies for games dirs, new group "gamestat" for sgid binaries
Hi all,
As decided by the Council in its 20140812 meeting [1], every developer
is allowed to commit and maintain games ebuilds. Furthermore:
| There is consensus amongst council members that specific policies
| (e.g., games group, /usr/games hierarchy, and games.eclass) should
| be settled by the QA team.
In yesterday's meeting the QA team has unanimously accepted the
following policies (see bug 537580 for details):
1. Directories /usr/games, /usr/games/bin, /usr/games/lib*,
/usr/share/games, /var/games, /etc/games, and /opt must be owned
by root:root and have permissions 755 (i.e. the default).
This will require a small change in games.eclass, because currently
prepgamesdirs() changes ownership of these directories to root:games
and mode to 0750, so they are readable only by users that are members
of the "games" group. With attached patch, games.eclass will no longer
change permissions of the top-level directories (mostly, these are
identical to the FHS locations).
If a package needs access control, it can still change ownership
and permissions of individual files, or of a subdir that it uses
exclusively. Owner and permission bits of directories that are shared
by multiple packages should be left alone, though.
2. A new group to allow setgid binaries to access shared score/state
files will be created. The name of this group will be "gamestat".
It is quite common for upstream packages to save shared scores or
other state files under /var/games, and access them with the program
(or a special helper) setgid to a low privilege group. In most
distros, that group is called "games" (see for example Debian's policy
in [2]).
Unfortunately, the "games" group (gid 35) cannot be used for that
purpose in Gentoo, because by the long-standing games.eclass policy it
was/is used to control access to games. Therefore, regular users on
many Gentoo systems will be in this group.
Gid 36 is available and can be used for the new "gamestat" group.
I don't think that we need a new eclass for this; creation of the
group would be simply one line in pkg_setup():
enewgroup gamestat 36
Ulrich
[1] http://www.gentoo.org/proj/en/council/meeting-logs/20140812-summary.txt
[2] https://www.debian.org/doc/debian-policy/ch-customized-programs.html#s11.11
--- games.eclass21 Nov 2014 21:47:16 - 1.159
+++ games.eclass24 Jan 2015 19:26:16 -
@@ -246,10 +246,11 @@
[[ ${dir} = ${GAMES_STATEDIR} ]] && mode=o-rwx,g+r
find "${D}/${dir}" -type f -print0 | xargs -0 chmod
$mode
- # common trees should not be games owned #264872
- if [[ ${dir} == "${GAMES_PREFIX_OPT}" ]] ; then
- fowners root:root "${dir}"
- fperms 755 "${dir}"
+ # common trees should not be games owned #264872 #537580
+ fowners root:root "${dir}"
+ fperms 755 "${dir}"
+ if [[ ${dir} == "${GAMES_PREFIX}" \
+ || ${dir} ==
"${GAMES_PREFIX_OPT}" ]] ; then
for d in $(get_libdir) bin ; do
# check if dirs exist to avoid
"nonfatal" option
if [[ -e ${D}/${dir}/${d} ]] ; then
pgpGeMiB3rnBM.pgp
Description: PGP signature
[gentoo-dev] Re: Policies for games dirs, new group "gamestat" for sgid binaries
> On Thu, 19 Feb 2015, Ulrich Mueller wrote: > In yesterday's meeting the QA team has unanimously accepted the > following policies (see bug 537580 for details): > 1. Directories /usr/games, /usr/games/bin, /usr/games/lib*, >/usr/share/games, /var/games, /etc/games, and /opt must be owned >by root:root and have permissions 755 (i.e. the default). > This will require a small change in games.eclass, because currently > prepgamesdirs() changes ownership of these directories to root:games > and mode to 0750, so they are readable only by users that are members > of the "games" group. With attached patch, games.eclass will no longer > change permissions of the top-level directories (mostly, these are > identical to the FHS locations). > [...] > 2. A new group to allow setgid binaries to access shared score/state >files will be created. The name of this group will be "gamestat". The change to games.eclass has been committed now, and the policy is documented here: https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies#Games Ulrich pgpOf2Zmie4Ff.pgp Description: PGP signature
