Re: [gentoo-dev] [RFC PATCH 06/19] www-servers/nginx: add nginx-r2.service
В Сб, 20/07/2024 в 20:25 +0300, Alexander Tsoy пишет: > В Сб, 20/07/2024 в 13:15 -0400, Michael Orlitzky пишет: > > But so long as we're talking about it: what do the file names under > > /var/tmp/nginx look like? Hopefully they're random. Otherwise we > > have > > to worry about the bad guy pre-creating not only the directory, but > > also the files inside it. > > No, their names are predefined. For example with the current in-tree > nginx: > > $ sudo ls -1 /var/lib/nginx/tmp/ > client > fastcgi > proxy > scgi > uwsgi > Sorry, these are directories. I cannot check file names right now.
Re: [gentoo-dev] [RFC PATCH 06/19] www-servers/nginx: add nginx-r2.service
В Сб, 20/07/2024 в 13:15 -0400, Michael Orlitzky пишет: > But so long as we're talking about it: what do the file names under > /var/tmp/nginx look like? Hopefully they're random. Otherwise we have > to worry about the bad guy pre-creating not only the directory, but > also the files inside it. No, their names are predefined. For example with the current in-tree nginx: $ sudo ls -1 /var/lib/nginx/tmp/ client fastcgi proxy scgi uwsgi
Re: [gentoo-dev] [RFC PATCH 06/19] www-servers/nginx: add nginx-r2.service
В Ср, 17/07/2024 в 15:05 +0300, Zurab Kvachadze пишет:
> This is the second revision of the systemd service file for NGINX.
>
> This commit removes redundant Exec{Stop,Reload} lines that restate
> the
> systemd defaults and changes the ExecStartPre directive from "nginx -
> t"
> (testing the NGINX configuration that is done anyway by the main
> process, bug 481456) to "mkdir -p /var/tmp/nginx", making sure the
> required directory for the NGINX temp files is present. ExecStopPost
> has
> also been removed, since sleeping for 100 ms serves no purpose.
>
> The second revision also changes the Exec* directives to use the
> plain
> file names, instead of the absolute ones, per systemd.service(5)
> guidelines:
> > It is thus safe to use just the executable name in case of
> > executables
> > located in any of the "standard" directories, and an absolute path
> > must be used in other cases.
>
> Bug: https://bugs.gentoo.org/481456
> Signed-off-by: Zurab Kvachadze
> ---
> www-servers/nginx/files/nginx-r2.service | 12
> 1 file changed, 12 insertions(+)
> create mode 100644 www-servers/nginx/files/nginx-r2.service
>
> diff --git a/www-servers/nginx/files/nginx-r2.service b/www-
> servers/nginx/files/nginx-r2.service
> new file mode 100644
> index ..2916aba391a2
> --- /dev/null
> +++ b/www-servers/nginx/files/nginx-r2.service
> @@ -0,0 +1,12 @@
> +[Unit]
> +Description=The NGINX HTTP and reverse proxy server
> +After=network.target remote-fs.target nss-lookup.target
> +
> +[Service]
> +Type=forking
> +PIDFile=/run/nginx.pid
> +ExecStartPre=mkdir -p /var/tmp/nginx
Please note that systemd-tmpfiles can remove the whole /var/tmp/nginx
directory if it and its contents are not touched for a long time. And
then reload of nginx might fail. So it is better to create this
directory via tmpfiles.d.
> +ExecStart=nginx
> +
> +[Install]
> +WantedBy=multi-user.target
Re: [gentoo-dev] rfc: noarch keyword
В Сб, 21/03/2020 в 00:53 -0700, Matt Turner пишет: > On Fri, Mar 20, 2020 at 9:55 PM Kent Fredric > wrote: > > If X is "noarch" and its dependency Y is "amd64", then a user on > > "sparc" > > will be able to install "X", but not its dependency "Y". > > Thank you. This is a good explanation of the problem. > > How do other distributions handle this? Arch, Fedora, and Debian have > "noarch" packages. Surely they've found a reasonable way to make this > work. Binary distros usually have separate repositories for each architecture.
[gentoo-dev] Last rites: media-sound/gtklick & dep
# Alexander Tsoy (2020-03-10) # media-sound/gtklick: last commit in 2014, python 2 only, blocks # dev-python/pygtk removal. # Alternatives: media-sound/kmetronome, media-sound/gtick, # media-sound/klick (cli) # # media-libs/pyliblo: last commit in 2015, the only revdep is # media-sound/gtklick, there is an actively maintained fork named # pyliblo3. # # Removal in 30 days. Bug #708172. media-sound/gtklick media-libs/pyliblo
Re: [gentoo-dev] Last rites: sys-firmware/iwl6050-ucode
7 февраля 2020 г. 22:50:13 GMT+03:00, Matt Turner пишет: >On Fri, Feb 7, 2020 at 11:39 AM Ulrich Mueller wrote: >> >> >>>>> On Fri, 07 Feb 2020, Matt Turner wrote: >> >> > On Fri, Feb 7, 2020 at 9:10 AM Mike Pagano >wrote: >> >> >> >> # Mike Pagano (2020-02-07) >> >> # The standalone ebuild for this driver is made >> >> # unnecessary as it is included in the package: >> >> # sys-kernel/linux-firmware >> >> sys-firmware/iwl6050-ucode >> >> > How about all the others as well? >> >> > sys-firmware/iwl1000-ucode >> > sys-firmware/iwl3160-7260-bt-ucode >> > sys-firmware/iwl3160-ucode >> > sys-firmware/iwl6005-ucode >> > sys-firmware/iwl6030-ucode >> > sys-firmware/iwl7260-ucode >> > sys-firmware/iwl8000-ucode >> >> I had asked the same question back in November, but an argument >against >> it was that sys-kernel/linux-firmware is quite a monster. In the >default >> configuration, its installation footprint is 515 MiB. > >Oh yeah. The thread where the person arguing for keeping them didn't >know about USE=savedconfig :) USE=savedconfig is very inconvinient, especially for a package that can introduce new firmware files for the same hardware. Adding support for masks would improve that a bit. -- Alexander Tsoy
[gentoo-dev] [PATCH] cmake-utils.eclass: Fix BUILD_SHARED_LIBS variable type
This fixes the following warning:
CMake Warning (dev) at gentoo_common_config.cmake:8 (SET):
implicitly converting 'BOOLEAN' to 'STRING' type.
Signed-off-by: Alexander Tsoy
---
eclass/cmake-utils.eclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
index 109b584afb3..e7a48116da7 100644
--- a/eclass/cmake-utils.eclass
+++ b/eclass/cmake-utils.eclass
@@ -649,7 +649,7 @@ cmake-utils_src_configure() {
if [[ ${EAPI} != [56] ]]; then
cat >> "${common_config}" <<- _EOF_ || die
SET (CMAKE_INSTALL_DOCDIR
"${EPREFIX}/usr/share/doc/${PF}" CACHE PATH "")
- SET (BUILD_SHARED_LIBS ON CACHE BOOLEAN "")
+ SET (BUILD_SHARED_LIBS ON CACHE BOOL "")
_EOF_
fi
--
2.23.0
Re: [gentoo-dev] RFC: UID/GID assignment for dovecot (97)
В Ср, 07/08/2019 в 09:29 +0300, Eray Aslan пишет: > I would like to reserve UID/GID 97 for dovecot (net-mail/dovecot) This GID is currently used by the input group (sys-apps/baselayout and acct-group/input). https://bugs.gentoo.org/688390 > > This fixed ID is what we have provided historically and is the same > as > RedHat but differs from Arch (76). >
Re: [gentoo-dev] [PATCH 2/6] profiles: enable USE="split-usr" in base
В Пн, 15/07/2019 в 11:06 -0400, Mike Gilbert пишет: > On Mon, Jul 15, 2019 at 10:33 AM Michael Orlitzky > wrote: > > On 7/14/19 9:56 PM, William Hubbs wrote: > > > The ultimate goal is to turn this flag off in the 19.0 profiles, > > > we are > > > just preserving the current status in the earlier ones. > > > > > > > So, to be clear: the plan is to force a /usr merge after all? > > > > I don't anticipate that happening within 2019, so I doubt it would be > turned off in a "19.0" profile. > > I think Gentoo developers are rather split on the /usr merge, and I > suspect a council ruling will be necessary if the pro-usr-merge camp > wants to push it through. > A little offtop: is there a tracker bug for /usr merge related issues? I can't find one.
Re: [gentoo-dev] Packages up for grabs after proxied maintainer's retirement
В Вс, 07/04/2019 в 10:32 +0200, Michał Górny пишет: > The proxied maintainer has resigned, leaving the following packages > up > for grabs: > I'll take these: > media-libs/pyliblo > media-sound/gtklick > media-sound/klick https://github.com/gentoo/gentoo/pull/12066 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] State of elogind integration and the default +elogind local USE flag on xorg-server.
В Пт, 22/03/2019 в 23:56 +0300, Andrew Savchenko пишет: --->%--- > > - Making pambase always install the configuration for > > pam_elogind.so, > > the same way it does for pam_gnome_keyring.so at this very moment, > > effectively removing elogind USE flag from it. > > Maybe that's a good time to make USE flag for pam_gnome_keyring.so. > Really, we shouldn't force users with some crap just "because it > doesn't hurt (much)". There used to be a gnome-keyring USE flag that controlled auto- launching of gnome-keyring-daemon on user login. But now support for gnome-keyring in pambase is pretty minimal, clearly not deserving a USE flag: $ portageq match / pambase sys-auth/pambase-20150213-r2 $ portageq contents / sys-auth/pambase-20150213-r2 | xargs grep gnome_keyring 2>/dev/null /etc/pam.d/passwd:-password optionalpam_gnome_keyring.so use_authtok
Re: [gentoo-dev] util-linux build time increase?
В Пн, 25/02/2019 в 13:07 +0300, Alexander Tsoy пишет: > В Чт, 21/02/2019 в 04:36 -0500, Joshua Kinard пишет: > > Does anyone have an idea why util-linux's build time would go up > > significantly from 2.32.x to 2.33.x? It may be a MIPS thing, as my > > x86_64 > > box shows no discernible change in build times between the same > > versions. > > Can any other archs check w/ genlop to see if they see a large jump > > in build > > time? > > > > 'genlop -t util-linux' output on my SGI system (some entries > > removed > > for > > brevity): > > > > Thu Feb 1 11:26:33 2018 >>> sys-apps/util-linux-2.31.1 > >merge time: 27 minutes and 48 seconds. > > > > Sat Mar 31 08:07:20 2018 >>> sys-apps/util-linux-2.32 > >merge time: 28 minutes and 44 seconds. > > > > Mon Aug 27 06:21:30 2018 >>> sys-apps/util-linux-2.32.1 > >merge time: 32 minutes and 58 seconds. > > > > Tue Nov 13 10:03:58 2018 >>> sys-apps/util-linux-2.33 > >merge time: 1 hour, 19 minutes and 49 seconds. > > > > Fri Jan 11 09:20:21 2019 >>> sys-apps/util-linux-2.33.1 > >merge time: 1 hour, 23 minutes and 37 seconds. > > > > Thu Feb 21 04:14:33 2019 >>> sys-apps/util-linux-2.33.1 > >merge time: 1 hour, 25 minutes and 15 seconds. > > > > 2.33 was changed to use python-r1 eclass instead of python-single-r1 > eclass. And the increase of build time seems caused by an out-of- > source > build for each python implementation. Some libraries are built > several > times (for native abi + for each python implementation). And there is additional configure run for each python implementation.
Re: [gentoo-dev] util-linux build time increase?
В Чт, 21/02/2019 в 04:36 -0500, Joshua Kinard пишет: > Does anyone have an idea why util-linux's build time would go up > significantly from 2.32.x to 2.33.x? It may be a MIPS thing, as my > x86_64 > box shows no discernible change in build times between the same > versions. > Can any other archs check w/ genlop to see if they see a large jump > in build > time? > > 'genlop -t util-linux' output on my SGI system (some entries removed > for > brevity): > > Thu Feb 1 11:26:33 2018 >>> sys-apps/util-linux-2.31.1 >merge time: 27 minutes and 48 seconds. > > Sat Mar 31 08:07:20 2018 >>> sys-apps/util-linux-2.32 >merge time: 28 minutes and 44 seconds. > > Mon Aug 27 06:21:30 2018 >>> sys-apps/util-linux-2.32.1 >merge time: 32 minutes and 58 seconds. > > Tue Nov 13 10:03:58 2018 >>> sys-apps/util-linux-2.33 >merge time: 1 hour, 19 minutes and 49 seconds. > > Fri Jan 11 09:20:21 2019 >>> sys-apps/util-linux-2.33.1 >merge time: 1 hour, 23 minutes and 37 seconds. > > Thu Feb 21 04:14:33 2019 >>> sys-apps/util-linux-2.33.1 >merge time: 1 hour, 25 minutes and 15 seconds. > 2.33 was changed to use python-r1 eclass instead of python-single-r1 eclass. And the increase of build time seems caused by an out-of-source build for each python implementation. Some libraries are built several times (for native abi + for each python implementation).
Re: [gentoo-dev] [PATCH] eclass/linux-mod.eclass: add module signing support
В Чт, 20/09/2018 в 22:13 -0700, Georgy Yakovlev пишет:
> ->%---
> @@ -144,13 +158,16 @@ esac
> 0) die "EAPI=${EAPI} is not supported with
> MODULES_OPTIONAL_USE_IUSE_DEFAULT due to lack of IUSE defaults" ;;
> esac
>
> -IUSE="kernel_linux
> ${MODULES_OPTIONAL_USE:+${_modules_optional_use_iuse_default}}${MODUL
> ES_OPTIONAL_USE}"
> +IUSE="module-sign kernel_linux
> ${MODULES_OPTIONAL_USE:+${_modules_optional_use_iuse_default}}${MODUL
> ES_OPTIONAL_USE}"
> SLOT="0"
> RDEPEND="${MODULES_OPTIONAL_USE}${MODULES_OPTIONAL_USE:+? (}
> kernel_linux? ( virtual/modutils ) ${MODULES_OPTIONAL_USE:+)}"
> DEPEND="${RDEPEND}
> ${MODULES_OPTIONAL_USE}${MODULES_OPTIONAL_USE:+? (}
> sys-apps/sed
> - kernel_linux? ( virtual/linux-sources virtual/libelf )
> + kernel_linux? (
> + virtual/linux-sources virtual/libelf
> + module-sign? ( || ( dev-libs/openssl dev-
> libs/libressl ) )
> + )
It should depend on the proper openssl slot: dev-libs/openssl:0
> ${MODULES_OPTIONAL_USE:+)}"
>
> # eclass utilities
> @@ -352,6 +369,84 @@ get-KERNEL_CC() {
> echo "${kernel_cc}"
> }
>
> +# @FUNCTION: _check_sig_force
> +# @INTERNAL
> +# @DESCRIPTION:
> +# Check if kernel requires module signing and die
> +# if modules are not going to be signed.
> +_check_sig_force() {
> + debug-print-function ${FUNCNAME} "${@}"
> +
> + if linux_chkconfig_present MODULE_SIG_FORCE; then
> + if use !module-sign; then
> + eerror "kernel .config has
> MODULE_SIG_FORCE=y option set"
> + eerror "This means that kernel requires all
> modules"
> + eerror "to be signed and verified before
> loading"
> + eerror "please enable USE=\"module-sign\" or
> reconfigure your kernel"
> + eerror "otherwise loading the module will
> fail"
> + die "signature required"
> + fi
> + fi
> +}
> +
> +# @FUNCTION: _sign_module
> +# @INTERNAL
> +# @USAGE:
> +# @DESCRIPTION:
> +# Sign a kernel module
> +_sign_module() {
> + debug-print-function ${FUNCNAME} "${@}"
> +
> + local dotconfig_sig_hash dotconfig_sig_key
> + local sign_binary_path sig_key_path sig_x509_path
> + local module
> +
> + # extract values from kernel .config
> + # extracted key path is not full, e.g.
> "certs/signing_key.pem"
> + dotconfig_sig_hash="$(linux_chkconfig_string
> MODULE_SIG_HASH)"
> + dotconfig_sig_key="$(linux_chkconfig_string MODULE_SIG_KEY)"
> +
> + # sign-file binary chokes on double quotes
> + dotconfig_sig_hash=${dotconfig_sig_hash//\"/}
> + dotconfig_sig_key=${dotconfig_sig_key//\"/}
> +
> + sign_binary_path="${KV_OUT_DIR}/scripts/sign-file"
Yet another way to screw up modules building. It relies on some binary
in the kernel build dir that may break after openssl update (e.g.
soname change).
Re: [gentoo-dev] [arm17] [News] ARM 17.0 profile migration with CHOST change
В Ср, 25/07/2018 в 00:08 +0100, James Le Cuirot пишет: --->% > Otherwise, if you do wish to migrate then we have written a script to > do the necessary steps for you: > > https://gist.github.com/chewi/1601684ad8f3cf8de0b786c00fa09b3c Please replace "-execdir sh" with "-execdir bash", otherwise looks good to me.
Re: [gentoo-dev] Managing updates on many identical Gentoo systems
В Пт, 19/01/2018 в 01:30 +0300, Alexander Tsoy пишет:
> В Чт, 18/01/2018 в 06:46 -0500, Anthony G. Basile пишет:
> > Hi everyone,
> >
> > I'm trying to design an update system for many identical Gentoo
> > systems.
> > Using a binhost is obvious, but there are still problems with this
> > approach.
> >
> > Unless there's some magic I don't know about (and this is why I'm
> > sending this email) each machine still needs to have the portage
> > tree
> > installed locally (1.5 GB) or somehow mounted by a network
> > filesystem
> > (which is not practical if the machines are not on a local
> > network).
> > Furthermore, each machine would have to run emerge locally to do
> > the
> > calculation of what packages need updating.
>
> AFAIK each machine only needs "profiles" and "eclass" directories and
> not the full repo. eclass dir is needed because of the check below in
> ebuild.sh:
>
>
> inherit()
> ...
> [[ -z ${location} ]] && die "${1}.eclass could not be found by
> inherit()"
>
> And this check actually should be skipped for binary packages. They
> are
> already contain full environment.
Oops. Forget the last part about inherit(). You need only profiles dir.
I experimented on a host with local overlay thus I got inherit
errors. :)
Re: [gentoo-dev] Managing updates on many identical Gentoo systems
В Чт, 18/01/2018 в 06:46 -0500, Anthony G. Basile пишет:
> Hi everyone,
>
> I'm trying to design an update system for many identical Gentoo
> systems.
> Using a binhost is obvious, but there are still problems with this
> approach.
>
> Unless there's some magic I don't know about (and this is why I'm
> sending this email) each machine still needs to have the portage tree
> installed locally (1.5 GB) or somehow mounted by a network filesystem
> (which is not practical if the machines are not on a local network).
> Furthermore, each machine would have to run emerge locally to do the
> calculation of what packages need updating.
AFAIK each machine only needs "profiles" and "eclass" directories and
not the full repo. eclass dir is needed because of the check below in
ebuild.sh:
inherit()
...
[[ -z ${location} ]] && die "${1}.eclass could not be found by
inherit()"
And this check actually should be skipped for binary packages. They are
already contain full environment.
Re: [gentoo-dev] [PATCH] vim-plugin.eclass: fix eclass documentation tags
В Sat, 30 Jul 2016 01:32:16 +0300 Andrew Savchenko пишет: > Hello, > > vim-plugin.eclass is the only eclass in the tree now which fails > eclass manpage generation: emerge app-portage/eclass-manpages: > > vim-plugin.eclass: >error:13: vim-plugin.eclass: no @BLURB found > FAIL: /usr/portage/eclass/vim-plugin.eclass > > While proposed patch does not create full documentation for > vim-plugin.eclass, it fixes the problem above by adding @BLURB > description and adds proper tags for functions, where descriptive > comments already exist. > +# @FUNCTION: display_vim_afterscripts > +# @DESCRIPTION: > +# update_vim_afterscripts: create scripts in Copy-paste error: function name is "display_vim_plugin_help", 3rd string is not needed. -- Alexander Tsoy pgpopx4YytTDO.pgp Description: Цифровая подпись OpenPGP
Re: [gentoo-dev] ChangeLog - Infra Response; update 2015/11/11, potential impact to 30min rsync cycle
On Thu, 12 Nov 2015 13:57:58 +0300 Alexander Tsoy wrote: > On Thu, 12 Nov 2015 18:49:38 +0800 > Jason Zaman wrote: > > > On Thu, Nov 12, 2015 at 11:46:19AM +0100, Alexis Ballier wrote: > > > On Wed, 11 Nov 2015 23:11:48 + > > > "Robin H. Johnson" wrote: > > > > > > > On Thu, Nov 05, 2015 at 12:54:06PM +0100, Alexis Ballier wrote: > > > > > It's not perfectly clean but I don't see any problem here: > > > > > ChangeLog-2015 : all ChangeLog from CVS > > > > > ChangeLog: autogenerated from git > > > > FYI, this was implemented. > > > > > > > > > Thanks! > > > > > > How should one report bugs ? to infra or portage ? > > > From my just rsynced tree, I see changelogs in reverse order: oldest > > > come first, latest come last > > > > NOTABUG, it was changed because rsync can deal really well with > > appending to the end of files. rsyncing a file where things were things > > were added to the beginning of the file means rsync will copy the whole > > file from scratch which is pretty sub-optimal. > > > > PORTAGE_RSYNC_OPTS by default contains "--whole-file". So I guess > appending to the ChangeLog files doesn't really help. :) Additionally rsync module appends --whole-file to rsync_opts: https://gitweb.gentoo.org/proj/portage.git/tree/pym/portage/sync/modules/rsync/rsync.py#n361 -- Alexander Tsoy
Re: [gentoo-dev] ChangeLog - Infra Response; update 2015/11/11, potential impact to 30min rsync cycle
On Thu, 12 Nov 2015 18:49:38 +0800 Jason Zaman wrote: > On Thu, Nov 12, 2015 at 11:46:19AM +0100, Alexis Ballier wrote: > > On Wed, 11 Nov 2015 23:11:48 + > > "Robin H. Johnson" wrote: > > > > > On Thu, Nov 05, 2015 at 12:54:06PM +0100, Alexis Ballier wrote: > > > > It's not perfectly clean but I don't see any problem here: > > > > ChangeLog-2015 : all ChangeLog from CVS > > > > ChangeLog: autogenerated from git > > > FYI, this was implemented. > > > > > > Thanks! > > > > How should one report bugs ? to infra or portage ? > > From my just rsynced tree, I see changelogs in reverse order: oldest > > come first, latest come last > > NOTABUG, it was changed because rsync can deal really well with > appending to the end of files. rsyncing a file where things were things > were added to the beginning of the file means rsync will copy the whole > file from scratch which is pretty sub-optimal. > PORTAGE_RSYNC_OPTS by default contains "--whole-file". So I guess appending to the ChangeLog files doesn't really help. :) -- Alexander Tsoy
Re: [gentoo-dev] [rfc] enable USE=xattr by default
On Thu, 15 Oct 2015 14:58:01 +0300 Alexander Tsoy wrote: > On Thu, 15 Oct 2015 19:47:59 +0800 > Jason Zaman wrote: > > > On Thu, Oct 15, 2015 at 07:38:43AM -0400, Anthony G. Basile wrote: > > > On 10/15/15 7:24 AM, Rich Freeman wrote: > > > > On Thu, Oct 15, 2015 at 6:56 AM, Jason Zaman > > > > wrote: > > > >> Can you try this: > > > >> > > > >> # getfattr -d -m- /bin/ping > > > >> security.capability=0sAQAAAgAgAAA= > > > >> # setfattr -n user.test -v "foo" ./ping > > > >> # setfattr -n user.pax.flags -v "me" ./ping > > > >> # getfattr -d -m- /bin/ping > > > >> security.capability=0sAQAAAgAgAAA= > > > >> user.pax.flags="me" > > > >> user.test="foo" > > > >> > > > >> If this works then something else is causing those messages and > > > >> we should look into it further. > > > > This behaves exactly as described above for me on btrfs, but I > > > > still do get all the error messages whenever I install stuff. > > > > > > > > I assume the extra attributes are harmless and will get removed > > > > the next time I update ping? > > > > > > > okay its good to know that that this does work. something might > > > be misconfigured on tobias's box. > > > > > > let me know any problems with XATTR_PAX markings because that's > > > going to become the default soon and in the near future the only > > > option once we drop the PT_PAX patch from binutils. > > > > I seem to recall something about PaX enabling user.* xattrs on tmpfs > > and mainline kernel supports only security.* on tmpfs. Could that be > > the cause? If that is the case then what do we do about everyone > > that is using gentoo-sources? It probably doesnt matter so just > > silencing the errors is probably enough. > > > > I was wrong. This patch was not merged upstream. It is still needed > and included in latest genpatches for 4.2: > > $ tar tf genpatches-4.2-6.base.tar.xz | grep XATTR > ./1500_XATTR_USER_PREFIX.patch > Oops.. Sorry, I replied on the wrong message. This was intended for Tobias. -- Alexander Tsoy
Re: [gentoo-dev] [rfc] enable USE=xattr by default
On Thu, 15 Oct 2015 19:47:59 +0800 Jason Zaman wrote: > On Thu, Oct 15, 2015 at 07:38:43AM -0400, Anthony G. Basile wrote: > > On 10/15/15 7:24 AM, Rich Freeman wrote: > > > On Thu, Oct 15, 2015 at 6:56 AM, Jason Zaman > > > wrote: > > >> Can you try this: > > >> > > >> # getfattr -d -m- /bin/ping > > >> security.capability=0sAQAAAgAgAAA= > > >> # setfattr -n user.test -v "foo" ./ping > > >> # setfattr -n user.pax.flags -v "me" ./ping > > >> # getfattr -d -m- /bin/ping > > >> security.capability=0sAQAAAgAgAAA= > > >> user.pax.flags="me" > > >> user.test="foo" > > >> > > >> If this works then something else is causing those messages and > > >> we should look into it further. > > > This behaves exactly as described above for me on btrfs, but I > > > still do get all the error messages whenever I install stuff. > > > > > > I assume the extra attributes are harmless and will get removed > > > the next time I update ping? > > > > > okay its good to know that that this does work. something might be > > misconfigured on tobias's box. > > > > let me know any problems with XATTR_PAX markings because that's > > going to become the default soon and in the near future the only > > option once we drop the PT_PAX patch from binutils. > > I seem to recall something about PaX enabling user.* xattrs on tmpfs > and mainline kernel supports only security.* on tmpfs. Could that be > the cause? If that is the case then what do we do about everyone that > is using gentoo-sources? It probably doesnt matter so just silencing > the errors is probably enough. > I was wrong. This patch was not merged upstream. It is still needed and included in latest genpatches for 4.2: $ tar tf genpatches-4.2-6.base.tar.xz | grep XATTR ./1500_XATTR_USER_PREFIX.patch -- Alexander Tsoy
Re: [gentoo-dev] [rfc] enable USE=xattr by default
On Thu, 15 Oct 2015 18:56:28 +0800 Jason Zaman wrote: > On Thu, Oct 15, 2015 at 10:57:45AM +0200, Tobias Klausmann wrote: > > Hi! > > > > On Wed, 14 Oct 2015, Mike Frysinger wrote: > > > anyone opposed to flipping this flag on by default ? > > > > > > reference: > > > https://bugs.gentoo.org/506198 > > > https://bugs.gentoo.org/556408 > > > > No objection, but a bit of a datapoint. I use btrfs on one of my > > machines, and that filesystem (apparently) does not support > > XATTR_PAX markings. So on every update I get some packages with > > message like these: > > I used to run hardened on btrfs and it worked fine. pax xattrs are in > the user namespace (user.pax.flags) which isnt protected (unlike eg. > security.*). I dont remember doing anything special to enable xattrs > on btrfs, most of the newer FSs have them enabled by default. > > Can you try this: > > # getfattr -d -m- /bin/ping I think he should check xattr support in PORTAGE_TMPDIR in the first place. :) I suspect something like tmpfs mounted on it (and CONFIG_TMPFS_XATTR=n in the kernel config). -- Alexander Tsoy
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-ruby/metasm/
On Fri, 9 Oct 2015 17:48:08 +0200
Patrick Lauer wrote:
>
>
> On 10/09/15 17:42, Davide Pesavento wrote:
> > On Fri, Oct 9, 2015 at 5:35 PM, hasufell wrote:
> >> On 10/08/2015 11:04 PM, Richard Farina wrote:
> >>
> >> +all_ruby_prepare() {
> >> + [ -f Gemfile.lock ] && rm Gemfile.lock
> >> missing "|| die" afais, should probably be
> >>
> >> [ -f Gemfile.lock ] && { rm Gemfile.lock || die ; }
> >>
> > Or simply:
> >
> > rm -f Gemfile.lock || die
> >
> With -f it always succeeds, so the ||die is redundant ...
>
$ touch foo1
$ sudo chattr +i foo1
$ rm -f foo1 || echo FAIL
rm: cannot remove 'foo1': Operation not permitted
FAIL
--
Alexander Tsoy
Re: [gentoo-dev] Managing etc/* in an embbeded system
В Wed, 22 Jul 2015 13:20:10 +
Joakim Tjernlund пишет:
> On Wed, 2015-07-22 at 14:30 +0200, Michał Górny wrote:
> >
> > Joakim Tjernlund napisał:
> >
> > > We got an embedded gentoo system where we need to manage many conf
> > > files under /etc that we have
> > > modified and should be under our control when an SW upgrade is
> > > performed.
> > >
> > > Cloning every ebuild where we have modified its conf file(s) under /etc
> > > feels awkward so
> > > I am looking for some other way to do this automatically during SW
> > > upgrade and I figured
> > > this can not be an unique problem for us, so I wonder how other people
> > > have solved this problem?
> > > Our customers will not use emerge directly and we will provide binary
> > > pkgs.
> > >
> > > Any ideas welcome :)
> > >
> > > Jocke
> >
> > Maybe post-phase hooks would help you. Not around a PC right now but I
> > think they're described in portage.5.
> > Long story short, you create per-package env files in /etc/portage/env (you
> > can pin them generically or to a
> > specific version, or package spec via package.env) and declare
> > post_src_install() where you add your custom
> > config files atop the package.
> >
>
> hmm, that sounds interesting but I don't quite get what to do, you think I
> should copy over /etc/inittab after
> it has been installed by sys-apps/sysvinit with my own version(which is
> stored where?)
>
> This gave me an idea though:
> In /etc/portage/env/install-mask.conf I add
> INSTALL_MASK="${INSTALL_MASK} /etc/inittab /etc/xxx"
> then in /etc/portage/package.env/install-mask
> sys-apps/sysvinit install-mask.conf
> sys-apps/xxx install-mask.conf
> ...
> (Can I do this from my own custom profile instead? how?)
>
> This should prevent sys-apps/sysvinit to install conf files I want to manage,
> right?
>
> Then I create my own new ebuild holding all config files I have changed
> myself.
>
> Jocke
>
>
You can do much more in these environment files. Here is an ugly example from
my BeagleBone Black. Note that since I'm not declaring any functions here, all
this code is not saved in environment and as a result in binary package (except
_distcc_wrapper variable :) ). I'm not sure it is a good idea to declare
standard phase functions in env files.
$ cat /etc/portage/env/sys-devel/distcc
_distcc_wrapper=${CHOST}-wrapper
case "${EBUILD_PHASE}" in
postinst)
cd "${EROOT}usr/lib/distcc/bin" && {
cat < "${_distcc_wrapper}"
#!/bin/bash
exec ${EROOT}usr/lib/distcc/bin/${CHOST}-g\${0:\$[-2]} "\$@"
EOF
chmod 0755 "${_distcc_wrapper}"
rm -fv cc c++ gcc g++
ln -s "${_distcc_wrapper}" cc
ln -s "${_distcc_wrapper}" c++
ln -s "${_distcc_wrapper}" gcc
ln -s "${_distcc_wrapper}" g++
} ;;
prerm)
cd "${EROOT}usr/lib/distcc/bin" && {
rm -fv cc c++ gcc g++
rm -fv "${_distcc_wrapper}"
} ;;
esac
--
Alexander Tsoy
Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing
В Tue, 9 Dec 2014 17:21:22 +0100 Michał Górny пишет: > Dnia 2014-12-08, o godz. 09:56:11 > Alexis Ballier napisał(a): > > > On Sun, 7 Dec 2014 11:37:57 +0100 > > Michał Górny wrote: > > > > > 1. No cross-compilation support. If the project proves being a success > > > it will be readded at some point. However, I will likely fork glibc > > > first and work on a sane crossdev alternative. > > > > Could you please elaborate on this ? > > How and why this broke, what is wrong in glibc, what would be a "sane > > crossdev alternative" and how crossdev is not. > > 1. eblits are broken in glibc. Another case of incorrect interpretation > of code sharing with love for breaking stable ebuilds. Plus I'd love to > add multilib flags to it but we'll likely doing that to main glibc as > well soon, if eblits don't get into our way. Yeah. Stable glibc ebuild gets broken from time to time after changes in eblits. > > 2. crossdev is broken because it creates semi-random, unmaintained > ebuilds in randomly chosen overlay, those ebuilds relying on > toolchain.eclass behavior. > > 3. I don't have any real alternative design yet. However, one > of the first ideas of changing crossdev is to replace copying ebuilds > with symlinking gcc ebuild directory. This will at least ensure proper > sync between real ebuilds and cross-ebuilds. > crossdev already works that way for a long time (see -oO option in help): $ ls -l /var/cache/portage/repos/crossdev/cross-armv6j-hardfloat-linux-gnueabi/ total 0 lrwxrwxrwx 1 portage portage 42 Oct 23 22:24 binutils -> /var/cache/portage/tree/sys-devel/binutils lrwxrwxrwx 1 portage portage 37 Oct 23 22:24 gcc -> /var/cache/portage/tree/sys-devel/gcc lrwxrwxrwx 1 portage portage 37 Oct 23 22:24 gdb -> /var/cache/portage/tree/sys-devel/gdb lrwxrwxrwx 1 portage portage 38 Oct 23 22:24 glibc -> /var/cache/portage/tree/sys-libs/glibc lrwxrwxrwx 1 portage portage 48 Oct 23 22:24 linux-headers -> /var/cache/portage/tree/sys-kernel/linux-headers -- Alexander Tsoy
Re: [gentoo-dev] Unify keyring related USE flags
В Thu, 13 Nov 2014 11:53:56 +0100 Pacho Ramos пишет: > El dom, 12-10-2014 a las 10:38 +0200, Pacho Ramos escribió: > > El dom, 12-10-2014 a las 00:13 +0400, Alexander Tsoy escribió: > > [...] > > > > > > > > I think we should simply have a "keyring" USE flag to enable what most > > > > people will want -> keyring support. > > > > > > Some apps have optional support for both kwallet and gnome-keyring > > > (e.g. darktable, subversion). So I'm not sure you can leave a single > > > USE flag. > > > > > > > Maybe for them we could have an exception or review them as they also > > look to be a bit strange. For example, for concrete case of subversion > > looks like it's using gnome-keyring and "kde", that looks a bit > > inconsistent to me. We could use "gnome" and "kde" for example :/. Or > > have a "keyring" USE flag and, then "gnome" and "kde" behind that USE > > > > > > any updates on this? :) > I don't know anything about kwallet, but gnome-keyring is useful outside of GNOME. So I don't like the idea of hiding gnome-keyring behind "gnome" use flag. -- Alexander Tsoy
Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11
On Sun Oct 12 01:27:38 2014 Anthony G. Basile wrote: > On 10/11/14 16:28, Rich Freeman wrote: > > On Sat, Oct 11, 2014 at 4:07 PM, M. Ziebell > > wrote: > > > But if anyone would ask me to stabilize gcc-4.8 I would say "amd64 > > > ok". > > > > > If there is general consensus that this is going to be a stable target > > it might make sense to start running mixed stable+gcc-4.8 systems as > > widely as possible for feedback. > > > > -- > > Rich > > > > Looking at the following two trackers: > > #461954 - GCC 4.8 porting > > #516152 - sys-devel/gcc-4.8.? stabilization > > > I would say the following still should be fixed: > > #500944 - =media-libs/x264-0.0.20111220 segmentation faults during > initialization of x264 encoder in x264_cqm_init () from > /usr/lib/libx264.so.120 Most likely already fixed in current stable x264-0.0.20140308 > > #500966 - >=net-libs/webkit-gtk-2.2.4 USE=-webgl - > ./.libs/libwebkitgtk-1.0.so: undefined reference to > `_ZN3JSC21GenericTypedArrayViewINS_14Float32AdaptorEE6createEj' Not a blocker for gcc-4.8 stabilization - I can reproduce this bug with gcc-4.7. > > #513386 - net-libs/webkit-gtk-2.4.3 - ./.libs/libwebkitgtk-3.0.so: > undefined reference to `_ZNSt6chrono12steady_clock3nowEv@GLIBCXX_3.4.17' > Maybe documentation + news item would be enough? -- Alexander Tsoy
Re: [gentoo-dev] News item review: bash-completion-2.1-r90
On Tue Oct 14 03:32:32 2014 Peter Stuge wrote: > Rich Freeman wrote: > > > > the new framework is opt-out rather than opt-in. > > > > > > Why is it desirable to make that change? > > > > there is no longer a performance penalty > > There is a severe behavioral penalty! > > > > We think that most users will prefer to just leave everything enabled > > now. > > I really do not want that to be chosen for me. Given the amount of completions it's unmaintainable with opt-in: $ ls /usr/share/bash-completion/completions/ | wc -l 709 -- Alexander Tsoy
Re: [gentoo-dev] Unify keyring related USE flags
В Sat, 11 Oct 2014 17:02:20 +0200
Pacho Ramos пишет:
> Hello
>
> I am wondering about current status of keyring related USE flags:
> - gnome-keyring USE is listed as global USE
> - libsecret is a local USE
> - wallet is local (only used by one package now)
Err.. wallet USE flag is completely unrelated. This wallet is for
bitcoins, it's not a keyring for passwords. :)
There are also "gnome" and "kde" USE flags. Note that the following
command doesn't catch multiline USE-conditional dependencies.
$ find . -type f -name "*.ebuild" -exec egrep -e 'kde\?.*kwallet' -e
'gnome\?.*gnome-keyring' '{}' \+
./dev-vcs/subversion/subversion-1.8.9.ebuild: kde? ( kde-base/kwalletd )
./dev-vcs/subversion/subversion-1.8.10.ebuild: kde? ( kde-base/kwalletd )
./dev-vcs/subversion/subversion-1.7.18.ebuild: kde? ( kde-base/kwalletd )
./media-gfx/darktable/darktable-1.2.3.ebuild: kde? ( kde-base/kwalletd )"
./media-gfx/darktable/darktable-1.4.1-r1.ebuild:kde? (
kde-base/kwalletd )"
./media-gfx/darktable/darktable-1.4.2.ebuild: kde? ( kde-base/kwalletd )"
./media-gfx/darktable/darktable-1.4.ebuild: kde? ( kde-base/kwalletd )"
./media-gfx/darktable/darktable-.ebuild:kde? ( kde-base/kwalletd )"
./media-sound/cantata/cantata-1.3.3.ebuild: kde? ( $(add_kdebase_dep
kwalletd) )
./media-sound/cantata/cantata-1.3.4.ebuild: kde? ( $(add_kdebase_dep
kwalletd) )
./net-fs/smbnetfs/smbnetfs-0.5.3a.ebuild: gnome? (
gnome-base/gnome-keyring:= )"
./net-fs/smbnetfs/smbnetfs-0.5.3b.ebuild: gnome? (
gnome-base/gnome-keyring:= )"
./net-im/gajim/gajim-0.15.4.ebuild: gnome? ( gnome-keyring )"
./net-im/gajim/gajim-0.15.4.ebuild: kde? ( kde-base/kwalletmanager )
./net-im/gajim/gajim-0.16.ebuild: gnome? ( gnome-keyring )"
./net-im/gajim/gajim-0.16.ebuild: kde? ( kde-base/kwalletmanager )
./www-client/qupzilla/qupzilla-1.6.5.ebuild:kde? ( kde-base/kwalletd:4 )"
./www-client/qupzilla/qupzilla-1.6.6.ebuild:kde? ( kde-base/kwalletd:4 )"
./www-client/qupzilla/qupzilla-1.8.0.ebuild:kde? ( kde-base/kwalletd:4 )
>
> I think we should simply have a "keyring" USE flag to enable what most
> people will want -> keyring support.
Some apps have optional support for both kwallet and gnome-keyring
(e.g. darktable, subversion). So I'm not sure you can leave a single
USE flag.
>
> What do you think? I am not sure what kind of USE flags are other
> desktops but Gnome/MATE using :S
>
> Thanks a lot
>
--
Alexander Tsoy
Re: [gentoo-dev] Update to the pax-utils.eclass
On Tue Aug 26 22:27:36 2014 Anthony G. Basile wrote: > Hi everyone, > > I plan to update the pax-utils.eclass because of bug #520198. Can > people please review that bug and the latest suggestion for the eclass. > Since I'm inverting some if and for blocks, a diff isn't as useful as > just looking at the entire class. > What if scanelf will fail? Looks like pax-mark() will not report an error. And there are unused variables in pax-mark(): pt_fail* and xt_fail*. -- Alexander Tsoy
Re: [gentoo-dev] bash-completion-2.1-r1 once again
В Tue, 26 Aug 2014 12:51:22 +0200 Michał Górny пишет: > What needs to change? > - > > The major issue is how to switch the system properly -- preferably, > without forcing users to reinstall everything :). > > I think the best way forward is to: > > 1. Teach 'old' eselect-bashcomp to find files in the new $completionsdir > as well as the old location, and stabilize that soon. > > 2. Switch the eclass and ebuilds to use the new $completionsdir. While > at it, make sure that ebuilds install completion files whose names > conform to the new layout (portage QA check likely). > > 3. Do we need some specific documentation except for a regular news > item? Where? > > 4. Unmask the new bash-completion and eselect-bashcomp. Add a news item > explaining the sudden change :). > > Any comments? Doubts? Wishes? > Several packages install completions into compatdir (/etc/bash_completion.d) by default. And these completions are incompatible with autoloader, so they will not work if you simply install them into completionsdir and create necessary symlinks. One example is sys-boot/grub [1]. What do you plan to do with such packages? [1] https://bugs.gentoo.org/show_bug.cgi?id=477392 -- Alexander Tsoy
Re: [gentoo-dev] Re: don't rely on dynamic deps
В Sun, 27 Jul 2014 14:42:24 +0300 Samuli Suominen пишет: > > On 26/07/14 15:49, Ciaran McCreesh wrote: > > On Sat, 26 Jul 2014 12:41:16 + (UTC) > > Martin Vaeth wrote: > >> hasufell wrote: > >>> Dynamics deps are already broken, not consistently enabled (e.g. > >>> when subslots are in use) > >> Just to make it clear: No, dynamic deps are not broken. > > Yes they are. > > We just succesfully converted ~300 ebuilds in tree without revision > bumps from virtual/udev[gudev,introspection,static-libs] > to virtual/libudev and virtual/libgudev > Tested it on multiple boxes, went fine. Nobody has filed bugs at > http://bugs.gentoo.org/, nobody has filed a single forums post, > nobody has said anything at #gentoo, Freenode > Only one person said he had to manually build 2 GNOME related > packages, simple-scan and something else As Michał already noted in this thread, dynamic deps does not play nice with slot operators. So I had the same problem with "2 GNOME related packages": !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: virtual/udev:0 (virtual/udev-208-r2::gentoo, installed) pulled in by >=virtual/udev-171:0/0=[gudev] required by (media-video/cheese-3.12.2::gentoo, installed) virtual/udev:0/0=[gudev] required by (x11-misc/colord-1.2.1::gentoo, installed) (virtual/udev-215::gentoo, ebuild scheduled for merge) pulled in by =virtual/udev-215 required by (games-util/xboxdrv-0.8.5-r1::gentoo, installed) (and 22 more with the same problem) > > So, broken? Far from it. More like essential feature. > > People have just listed some known races dynamic deps have, and I take > those races anyday over an regression that causes > endless rebuilding... > > - Samuli > -- Alexander Tsoy
Re: [gentoo-dev] Anyone with access to genkernel repository? Or should genkernel be p.masked on amd64 profiles?
On Fri May 30 22:30:32 2014 Sven Vermeulen wrote: > On Fri, May 30, 2014 at 04:34:09PM +, hasufell wrote: > > Tom Wijsman: > > > > > > Please no p.mask for a single line being wrong... > > > > > > > That's nonsense. The amount of wrong lines doesn't matter. A single > > wrong line in the kernel can break your whole system as well. > > > > Please p.mask (or patch) immediately. There is no point in waiting. > > I'd appreciate any patch on the Gentoo Handbook to use another tool for > initramfs. I have some experience with dracut, but the last dracut > generated initramfs failed on my system, whereas genkernel's still goes > well. > Hmm.. You are the second person in this thread who experienced problems with latest dracut. I suspect this is due to hostonly-cmdline option, which is disabled by default. If this is really the case, we should either enable it in gentoo.conf or revert corresponding changes like in fedora [1]. And where are bug reports? :) Sorry for offtop. [1] http://pkgs.fedoraproject.org/cgit/dracut.git/commit/?id=2fa76e2882883ea64be6c3210c257cff4e4b641a > The last Dracut generated initramfs also failed on SELinux systems, but > that isn't something that cannot be worked around... > > Wkr, > Sven Vermeulen > -- Alexander Tsoy
Re: [gentoo-dev] Anyone with access to genkernel repository? Or should genkernel be p.masked on amd64 profiles?
В Fri, 30 May 2014 18:10:40 +0300 Samuli Suominen пишет: > I can't find anyone with access that actually replies to mails, pings, > ... to genkernel repository for: > > https://bugs.gentoo.org/show_bug.cgi?id=461828 > > I'll p.mask it on amd64 profiles if noone replies soon :( > > - Samuli > I guess openrc users does not have such problems with DM/LVM. From /etc/init.d/udev: echo "" >/proc/sys/kernel/hotplug -- Alexander Tsoy
Re: [gentoo-dev] RFC: using .xz for doc/man/info compression
В Mon, 12 May 2014 14:17:11 +0200
Tom Wijsman пишет:
> On Mon, 12 May 2014 14:47:36 +0400
> Alexander Tsoy wrote:
>
> > Here is my test results. xz options: "--lzma2=preset=6e,dict=4MiB".
> > Larger dictionary size does not improve compression ratio, I get
> > even worse results with just "-6e" or "-9e". man-bz2 is a full copy of
> > my /usr/share/man, man-xz is a recompressed one.
>
> Picking a random post to reply; if you don't already, please consider
> to do these tests in tmpfs to cancel out any fs / storage differences.
>
The same test in tmpfs.
$ time find man-bz2/ -type f -name "*.bz2" -exec bzcat '{}' > /dev/null \;
real0m35.895s
user0m14.232s
sys 0m14.121s
$ time find man-xz/ -type f -name "*.xz" -exec xzcat '{}' > /dev/null \;
real0m44.342s
user0m16.842s
sys 0m21.459s
And here is additional test. It shows where is actually a bottleneck.
xz is faster in decompression, but looks like it just has a slower
process initialization speed. So it's slower in decompressing of a single
little file.
$ time find man-bz2/ -type f -name "*.bz2" -exec bzcat '{}' > /dev/null \+
real0m10.096s
user0m9.000s
sys 0m0.787s
$ time find man-xz/ -type f -name "*.xz" -exec xzcat '{}' > /dev/null \+
real0m7.846s
user0m7.108s
sys 0m0.487s
--
Alexander Tsoy
Re: [gentoo-dev] RFC: using .xz for doc/man/info compression
В Mon, 12 May 2014 14:47:36 +0400 Alexander Tsoy пишет: > В Sun, 11 May 2014 18:26:32 -0500 > Gordon Pettey пишет: > > > A lot of small files (e.g. AUTHORS, ChangeLog > > > > FWIW: On my system, I have 59M of bz2 files in /usr/share/man and > > /usr/share/doc. A short script to decompress those and recompress with xz > > -6e reduced that to 36M. > > Very strange o_O > > Here is my test results. xz options: "--lzma2=preset=6e,dict=4MiB". > Larger dictionary size does not improve compression ratio, I get > even worse results with just "-6e" or "-9e". man-bz2 is a full copy of > my /usr/share/man, man-xz is a recompressed one. > > Size comparison: > > $ du -s man-bz2/ man-xz/ > 82032 man-bz2/ > 82308 man-xz/ Note that a lot of files in these directories are non-compressed text files or symlinks: $ find man-bz2/ \( ! -name "*.bz2" -o -type l \) -a ! -type d | wc -l 8434 $ find man-bz2/ -name "*.bz2" -type f | wc -l 11243 $ find man-xz/ \( ! -name "*.xz" -o -type l \) -a ! -type d | wc -l 8434 $ find man-xz/ -name "*.xz" -type f | wc -l 11243 After cleaning them and adding -b option: $ du -bs man-bz2/ man-xz/ 32158286man-bz2/ 32550305man-xz/ -- Alexander Tsoy
Re: [gentoo-dev] RFC: using .xz for doc/man/info compression
В Sun, 11 May 2014 18:26:32 -0500
Gordon Pettey пишет:
> A lot of small files (e.g. AUTHORS, ChangeLog
>
> FWIW: On my system, I have 59M of bz2 files in /usr/share/man and
> /usr/share/doc. A short script to decompress those and recompress with xz
> -6e reduced that to 36M.
Very strange o_O
Here is my test results. xz options: "--lzma2=preset=6e,dict=4MiB".
Larger dictionary size does not improve compression ratio, I get
even worse results with just "-6e" or "-9e". man-bz2 is a full copy of
my /usr/share/man, man-xz is a recompressed one.
Size comparison:
$ du -s man-bz2/ man-xz/
82032 man-bz2/
82308 man-xz/
Decompression speed:
$ time find man-bz2/ -type f -name "*.bz2" -exec bzcat '{}' > /dev/null \;
real0m35.110s
user0m14.509s
sys 0m15.227s
$ time find man-bz2/ -type f -name "*.bz2" -exec bzcat '{}' > /dev/null \;
real0m35.407s
user0m14.432s
sys 0m15.186s
$ time find man-xz/ -type f -name "*.xz" -exec xzcat '{}' > /dev/null \;
real0m46.571s
user0m17.077s
sys 0m23.906s
$ time find man-xz/ -type f -name "*.xz" -exec xzcat '{}' > /dev/null \;
real 0m46.137s
user0m17.276s
sys 0m23.426s
As you can see, xz is actually worse in speed and compression ratio.
--
Alexander Tsoy
Re: [gentoo-dev] RFC: using .xz for doc/man/info compression
В Sun, 11 May 2014 19:46:50 +0200 Michał Górny пишет: > Hello, developers. > > I'd like to raise the following item for discussion: making .xz > the default compressor used by portage for documentation, man pages > and info files. That is, the equivalent of: > > PORTAGE_COMPRESS=xz > > in make.globals. > > Rationale: xz-utils is quite widespread nowadays and it is a part > of @system set. It can achieve better compression ratio than bzip2, > and faster decompression at the same time. I tried it recently. Actually for doc/man/info and any other relatively small text files xz has worse compression ratio than bzip2. See also: https://bugs.gentoo.org/show_bug.cgi?id=372653 > > I have confirmed that both sys-apps/man and sys-apps/man-db can > handle .xz compressed man pages, and sys-apps/texinfo can handle .xz > compressed info pages. Major text editors and pagers support .xz > alike .bz2 (i.e. usually they support both or neither :)). > > The additional question is: what preset to use? To help discussing > this, I'd like to quote the tables from 'man xz': > > Preset DictSize CompCPU CompMem DecMem >-0 256 KiB 03 MiB1 MiB >-1 1 MiB 19 MiB2 MiB >-2 2 MiB 2 17 MiB3 MiB >-3 4 MiB 3 32 MiB5 MiB >-4 4 MiB 4 48 MiB5 MiB >-5 8 MiB 5 94 MiB9 MiB >-6 8 MiB 6 94 MiB9 MiB >-7 16 MiB 6 186 MiB 17 MiB >-8 32 MiB 6 370 MiB 33 MiB >-9 64 MiB 6 674 MiB 65 MiB > > Preset DictSize CompCPU CompMem DecMem > -0e 256 KiB 84 MiB1 MiB > -1e 1 MiB 8 13 MiB2 MiB > -2e 2 MiB 8 25 MiB3 MiB > -3e 4 MiB 7 48 MiB5 MiB > -4e 4 MiB 8 48 MiB5 MiB > -5e 8 MiB 7 94 MiB9 MiB > -6e 8 MiB 8 94 MiB9 MiB > -7e 16 MiB 8 186 MiB 17 MiB > -8e 32 MiB 8 370 MiB 33 MiB > -9e 64 MiB 8 674 MiB 65 MiB > > I'd like to note here that increasing dictionary size over file size > does not improve compression. However, the options involved in CompCPU > may. > > Depending on the expected amount of complexity, I'd either go for: > > 1) -6e (or -6, the default) -- max CompCPU, reasonable use of memory, > and dictionary larger than most (or all?) documents that are going to > be compressed, > > 2) -Ne with minimal 'N' for CompCPU==8 and DictSize > filesize -- > still max compression ratio while keeping lowest memory requirements > possible. > > Your thoughts? > -- Alexander Tsoy
Re: [gentoo-dev] [PATCH] fcaps.eclass: Group name portability
В Tue, 15 Apr 2014 12:06:44 +0400
Alexander Tsoy пишет:
> В Tue, 15 Apr 2014 11:11:53 +0900
> Naohiro Aota пишет:
>
> > Diego Elio Pettenò writes:
> >
> > > I'm pretty sure we have an eclass function to get the name of the
> > > 0 group.
> >
> > I can't find one... but found qmail.eclass is using exactly same
> > method.
> >
> > > export GROUP_ROOT="$(id -gn root)"
>
> "id -gn root" prints initial group name of the user root. This is
> exactly what you want in fcaps.eclass. In linux "id" accepts only
> username as argument, it doesn't support uid.
>
But if you really want to convert gid=0 to groupname, then use egetent()
as also noted by Cyprien:
inherit user
...
local group=$(egetent group 0)
group=${group%%:*}
--
Alexander Tsoy
Re: [gentoo-dev] [PATCH] fcaps.eclass: Group name portability
В Tue, 15 Apr 2014 11:11:53 +0900 Naohiro Aota пишет: > Diego Elio Pettenò writes: > > > I'm pretty sure we have an eclass function to get the name of the 0 > > group. > > I can't find one... but found qmail.eclass is using exactly same > method. > > > export GROUP_ROOT="$(id -gn root)" "id -gn root" prints initial group name of the user root. This is exactly what you want in fcaps.eclass. In linux "id" accepts only username as argument, it doesn't support uid. -- Alexander Tsoy
Re: [gentoo-dev] Handling /dev/rfkill, testers wanted
В Fri, 07 Mar 2014 21:17:20 +0200
Samuli Suominen пишет:
> - sys-apps/systemd has it's own service to handle /dev/rfkill from
> 99-systemd.rules we don't install with sys-fs/udev:
>
> SUBSYSTEM=="rfkill", TAG+="systemd", IMPORT{builtin}="path_id",
> ENV{SYSTEMD_WANTS}+="systemd-rfkill@$name.service"
>
The above rule from systemd just run a special unit which
saves/restores rfkill state across reboots. It has nothing to do
with permissions of device nodes and/or ACLs.
> - so this is about sys-fs/udev (and perhaps, sys-auth/consolekit for
> ACLs)
> - since the udev .rules are not application specific, we should
> control it from sys-fs/udev's /lib/udev/rules.d/40-gentoo.rules
> - sys-fs/udev leaves it to root:root as:
>
> KERNEL=="rfkill", MODE="0664"
>
> - third party packages like mate-bluetooth, gnome-bluetooth install
> both their own udev .rules to adjust /dev/rfkill to plugdev:
>
> KERNEL=="rfkill", GROUP="plugdev",MODE="0664"
>
> So I'd like to propose some unification:
>
> I don't have a system with /dev/rfkill unfortunately to test this,
> but I believe we should add this to 40-gentoo.rules and create group
> 'rfkill':
>
> SUBSYSTEM=="rfkill", GROUP="rfkill", MODE="0664"
>
> And this line would go as /lib/udev/rules.d/70-gentoo-acl.rules (as
> the original filename in upstream ConsoleKit is 70-udev-acl.rules):
>
> SUBSYSTEM=="rfkill", TAG+="udev-acl"
>
> So that it would then look like:
>
> $ ls -ld /dev/rfkill
> crw-rw+ 1 root rfkill 116, 1 Feb 21 16:27 /dev/rfkill
>
> Notice the "+" there for ACLs if user is active (logged in using
> ConsoleKit):
>
> $ getfacl -a /dev/rfkill
> # file: dev/rfkill
> # owner: root
> # group: rfkill
> user::rw-
> user:ssuominen:rw-
> group::rw-
> mask::rw-
> other::---
>
> I didn't actually run that just on /dev/rfkill, but I took an example
> from /dev/snd/seq, and edited those at this mail.
>
> I'd like someone with /dev/rfkill to test I'm right, if possible, and
> verify no other cruft is interfering with it (like those of installed
> by those apps I mentioned, `grep rfkill /lib/udev/rules.d/*`)
>
> Any thoughts?
>
--
Alexander Tsoy
Re: [gentoo-dev] Handling /dev/rfkill, testers wanted
В Fri, 07 Mar 2014 22:15:40 +0200 Samuli Suominen пишет: > > On 07/03/14 21:57, Samuli Suominen wrote: > > [ ... ] > > > > So, make sure only 50-udev-default.rules has it's rfkill line and > > create file 70-gentoo-acl.rules with content of: > > > > SUBSYSTEM=="rfkill", TAG+="udev-acl" > > > > This would make it work with ACLs "+" if user is viewed as 'active > > = TRUE' in `ck-list-sessions` > > > > Can someone confirm? > > > > > > I don't get why 99-systemd.rules uses SUBSYSTEM=="rfkill" but someone > just posted me this: > > $ udevadm info -a --name /dev/rfkill > > looking at device '/devices/virtual/misc/rfkill': > KERNEL=="rfkill" > SUBSYSTEM=="misc" > DRIVER=="" > > So it would have to be KERNEL=="rfkill" instead of > SUBSYSTEM=="rfkill"? Would be so much easier if I had a device that > created /dev/rfkill, I wonder if that can be simulated somehow sane. > $ sudo udevadm info -q all --path /sys/class/rfkill/rfkill0 P: /devices/pci:00/:00:04.0/:02:00.0/usb8/8-2/8-2.2/8-2.2:1.0/bluetooth/hci0/rfkill0 E: DEVPATH=/devices/pci:00/:00:04.0/:02:00.0/usb8/8-2/8-2.2/8-2.2:1.0/bluetooth/hci0/rfkill0 E: ID_PATH=pci-:02:00.0-usb-0:2.2:1.0 E: ID_PATH_TAG=pci-_02_00_0-usb-0_2_2_1_0 E: RFKILL_NAME=hci0 E: RFKILL_STATE=1 E: RFKILL_TYPE=bluetooth E: SUBSYSTEM=rfkill E: SYSTEMD_WANTS=systemd-rfkill@rfkill0.service E: TAGS=:systemd: E: USEC_INITIALIZED=59720 -- Alexander Tsoy
Re: [gentoo-dev] Recommend cronie instead of vixie-cron in handbook?
On Wed Dec 11 23:30:58 2013 Peter Stuge wrote: > Pacho Ramos wrote: > > Last time I checked, vixie-cron upstream was died while cronie > > forked it fixing some bugs :/ > > > > What do you think? > > I think that nobody who is not intimately familiar with the > development in both projects can think anything that is actionable. vixie-cron upstream is dead and this is a well-known fact. Example of "development" in vixie-cron project: https://bugs.gentoo.org/show_bug.cgi?id=308055 -- Alexander Tsoy
