[gentoo-dev] I want to quit the mailing list, does anybody help?
I am only a user but not developers for gentoo. Now I want to quit the mailing list, does anybody help? Sorry to bother you if not related. Ando Yours Sincerely！
Re: [gentoo-dev] I want to quit the mailing list, does anybody help?
On Sat, Jan 09, 2021 at 09:08:12AM +, ZHUNG Andio wrote: > I am only a user but not developers for gentoo. Now I want to quit the > mailing list, does anybody help? > Sorry to bother you if not related. > > Ando > > Yours > Sincerely！ Hello Ando, There's a section about subscribing on the mailing list instructions page: https://www.gentoo.org/get-involved/mailing-lists/instructions.html To unsubscribe from a list, send an empty email to: listname+unsubscr...@lists.gentoo.org Sincerely, William Breathitt Gray signature.asc Description: PGP signature
[gentoo-dev] 回复: [gentoo-dev] I want to quit the mailing list, does anybody help?
Thanks. Yours Best wishes. -邮件原件- 发件人: William Breathitt Gray 发送时间: 2021-01-09 17:21 收件人: gentoo-dev@lists.gentoo.org 主题: Re: [gentoo-dev] I want to quit the mailing list, does anybody help? On Sat, Jan 09, 2021 at 09:08:12AM +, ZHUNG Andio wrote: > I am only a user but not developers for gentoo. Now I want to quit the > mailing list, does anybody help? > Sorry to bother you if not related. > > Ando > > Yours > Sincerely！ Hello Ando, There's a section about subscribing on the mailing list instructions page: https://www.gentoo.org/get-involved/mailing-lists/instructions.html To unsubscribe from a list, send an empty email to: listname+unsubscr...@lists.gentoo.org Sincerely, William Breathitt Gray
Re: [gentoo-dev] [PATCH 2/2] xorg-2.eclass: Remove XORG_STATIC
On Fri, 2021-01-08 at 23:16 -0500, Matt Turner wrote:
> Statically linking X libraries into your program is an extremely bad
> idea.
>
> Signed-off-by: Matt Turner
> ---
> eclass/xorg-2.eclass | 23 +--
> 1 file changed, 1 insertion(+), 22 deletions(-)
>
> diff --git a/eclass/xorg-2.eclass b/eclass/xorg-2.eclass
> index f3b282e1a11..f9a18b8ec26 100644
> --- a/eclass/xorg-2.eclass
> +++ b/eclass/xorg-2.eclass
> @@ -1,4 +1,4 @@
> -# Copyright 1999-2020 Gentoo Authors
> +# Copyright 1999-2021 Gentoo Authors
> # Distributed under the terms of the GNU General Public License v2
>
> # @ECLASS: xorg-2.eclass
> @@ -168,27 +168,6 @@ fi
> # If we're a driver package, then enable DRIVER case
> [[ ${PN} == xf86-video-* || ${PN} == xf86-input-* ]] && DRIVER="yes"
>
> -# @ECLASS-VARIABLE: XORG_STATIC
> -# @DESCRIPTION:
> -# Enables static-libs useflag. Set to no, if your package gets:
> -#
> -# QA: configure: WARNING: unrecognized options: --disable-static
> -: ${XORG_STATIC:="yes"}
> -
> -# Add static-libs useflag where useful.
> -if [[ ${XORG_STATIC} == yes \
> - && ${FONT} != yes \
> - && ${CATEGORY} != app-doc \
> - && ${CATEGORY} != x11-apps \
> - && ${CATEGORY} != x11-drivers \
> - && ${CATEGORY} != media-fonts \
> - && ${PN} != util-macros \
> - && ${PN} != xbitmaps \
> - && ${PN} != xorg-cf-files \
> - && ${PN/xcursor} = ${PN} ]]; then
> - IUSE+=" static-libs"
> -fi
> -
> DEPEND+=" virtual/pkgconfig"
>
> # @ECLASS-VARIABLE: XORG_DRI
+1 LGTM.
[gentoo-dev] last rite: media-libs/raul
# Miroslav Šulc (2021-01-09) # media-sound/patchage used to depend on it but the dependency # has been dropped in v1.0.0. There are no other packages in the tree # depending on it. Also having issues compiling it. Removal in 30 days. media-libs/raul
[gentoo-dev] migration of "default" folders and fixups of exitsing installed folders
Hi,
In some ways not unlike the discussion around users being installed and
later updated ... so I'm guessing I'm going to have varied opinions and
feedback on this potentially. Ironically, asterisk was one of those
users that had it's home folder (correctly) adjusted from
/var/lib/asterisk to /dev/null.
In this case:
1. I would like to update where asterisk stores astdb (partially for
security reasons);
2. And on existing installs, /var/{lib,spool}/asterisk may well have
what I consider to be insecure ownership and permissions.
I have some ideas about the former (below), the latter I have no ideas
about.
There used to be a "fix permissions" script in the asterisk init script
(that was considered to be a security vulnerability, and was removed,
not to mention that it didn't exactly set same to be as secure as it can
be, and there are legitimate reasons to not use the strictest possible
permissions on *some* of the folders beneath both these locations, but
most of them should be root:root, and root:asterisk in specific cases,
and only in a very few cases asterisk:root possibly). Suggestions on
fixing these permissions if (and only if) they were unmodified by the
user. And making sure the user is aware of these.
Re the former: https://bugs.gentoo.org/761442 relates.
History:
asterisk project simply used to install everything as
asterisk:asterisk. Config files, resource files, everything,
irrespective of whether or not runtime required write access or not (I
think the exception was the binary and module libraries). This was from
upstream project. Myself and a few others started upsetting the apple
cart with things like "why are audio files installed writeable by
asterisk?". Upstream caught onto this and started fixing some things up
(I don't have references, but things have definitely changed).
Bottom line:
/var/lib/asterisk used to be installed as asterisk:root, 750.
It's now being installed as root:root 755 (I'd prefer root:asterisk 750
personally)
There are only two pieces of information inside /var/lib/asterisk that
needs to (potentially) be writeable by asterisk.
1. astdb.sqlite3 (and it's -journal file which doesn't always exist)
2. coredump/ folder (only required if configured to core dump).
The latter is a non-issue since this folder is specifically installed
asterisk:root.
astdb is a problem, since in order to create the -journal file I need to
give write access to asterisk to the folder (which I'd prefer to not do).
Disclaimer: Depending on what you're doing there might be motivation to
have a few extra specific locations writeable by asterisk beneath
/var/lib/asterisk (we do have that, but this should be an explicit
action by the administrator in my opinion, if I could I'd install
everything there as root:root - which is just about the case currently).
What I'd rather prefer to do is to create an additional asterisk:root
astdb folder beneath /var/lib/asterisk and have asterisk use that for
astdb. This is easy enough to configure, and even to update the default
config files.
But what to do with existing installations? A person would need to "opt
in" to this change by way of etc-update I guess (I'll keep a ::gentoo
patch to basically enable the [directories] section, and to set astdbdir
= /var/lib/asterisk/astdb by default). But unless the person modified
asterisk.conf (entirely possible, generally you don't need to customize
this config file) that will auto update this file. And on next asterisk
restart the person will lose his existing astdb.sqlite3 file.
So ... I could check for /var/lib/asterisk/astdb.sqlite3 in init script
... but if the user opted out of te config update ... moving the file
here (which is a bad idea in my opinion anyway) is a terrible idea. Not
moving the file will simply result in asterisk creating a new
astdb.sqlite3 file in the new folder - which carries risk if (and only
if) the user cares about persistence in astdb (which my systems
specifically don't, but some others do). By *default* nothing that
asterisk itself stores into astdb requires persistence (but it is
preferred, for example, if I REGISTER to asterisk, it is nice that it
doesn't "forget" my registration over restarts or even reboots).
At this point I'm inclined to put a big ewarn in the updated ebuilds in
pkg_pretend, warning of this default config change (if you're updating
from an older asterisk where the default was /var/lib/asterisk),
installing the new folder and moving on with my life. Since all my
installs already has /var/lib/asterisk/astdb on a ramdisk, I'm not
affected, but I really would prefer to not catch users off guard.
Currently new installs of asterisk is semi broken by default, easy to
fix either by chown asterisk:root /var/lib/asterisk, or by install -d
-oasterisk -groot -m0750 /var/lib/asterisk/astdb and simple (2 lines)
config change to /etc/asterisk/asterisk.conf.
Just looking for other possible approaches here.
Migration is also easy enough: updat
[gentoo-dev] Packages up for grabs: app-mobilephone/adb-sync, app-office/homebank, dev-libs/libstroke, media-gfx/engauge, x11-misc/light-locker
Hello, The following packages are now up for grabs due to their maintainer retiring: app-mobilephone/adb-sync no bugs app-office/homebank QA bug, version bump pending dev-libs/libstroke build failure reported media-gfx/engauge multiple bugs, bump pending x11-misc/light-locker QA(?) bug -- Best regards, Michał Górny
[gentoo-dev] [PATCH] xorg-3.eclass: Call einstalldocs when not using XORG_MULTILIB
DOCS only got installed from the multilib-minimal_src_install call,
so they were missing from non-multilib packages. This corrects a
behavior difference from xorg-2.eclass where autotools-utils.eclass
installed DOCS for the non-multilib case.
Signed-off-by: David Michael
---
eclass/xorg-3.eclass | 1 +
1 file changed, 1 insertion(+)
diff --git a/eclass/xorg-3.eclass b/eclass/xorg-3.eclass
index 399fc8661f4..fcaeb84edca 100644
--- a/eclass/xorg-3.eclass
+++ b/eclass/xorg-3.eclass
@@ -424,6 +424,7 @@ xorg-3_src_install() {
multilib-minimal_src_install "$@"
else
emake DESTDIR="${D}" "${install_args[@]}" "$@" install || die
"emake install failed"
+ einstalldocs
fi
# Many X11 libraries unconditionally install developer documentation
--
2.26.2
Re: [gentoo-dev] Last-rites: sys-power/pm-utils, sys-power/pm-quirks, app-admin/cgmanager and sys-libs/libnih
On 1/8/2021 08:39, Andreas Sturmlechner wrote: > On Freitag, 8. Januar 2021 08:10:05 CET Jaco Kroon wrote: >> Would it be possible to point at alternatives? pm-utils worked well for >> me until now, and I'm fairly certain this won't be abandoned unless >> there are other (better?) alternatives available. >> > > It is replaced by elogind or systemd builtin functions. > > Regards sys-power/suspend seems to work for me on my system. Calling s2ram puts the machine into S3 state, and it resumes without issue thus far. pm-suspend --> s2ram pm-hibernate --> s2disk pm-suspend-hybrid --> s2both -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org rsa6144/5C63F4E3F5C6C943 2015-04-27 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic
[gentoo-dev] unsubscrbe conformation
Andio Yours Sincerely！
