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 <birc...@gentoo.org> пишет: > 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 18:49:38 +0800 Jason Zaman <perfin...@gentoo.org> 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" <robb...@gentoo.org> 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] ChangeLog - Infra Response; update 2015/11/11, potential impact to 30min rsync cycle
On Thu, 12 Nov 2015 13:57:58 +0300 Alexander Tsoy <alexan...@tsoy.me> wrote: > On Thu, 12 Nov 2015 18:49:38 +0800 > Jason Zaman <perfin...@gentoo.org> 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" <robb...@gentoo.org> 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] [rfc] enable USE=xattr by default
On Thu, 15 Oct 2015 19:47:59 +0800 Jason Zaman <perfin...@gentoo.org> 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 > > > <perfin...@gentoo.org> 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 <perfin...@gentoo.org> 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] [rfc] enable USE=xattr by default
On Thu, 15 Oct 2015 14:58:01 +0300 Alexander Tsoy <alexan...@tsoy.me> wrote: > On Thu, 15 Oct 2015 19:47:59 +0800 > Jason Zaman <perfin...@gentoo.org> 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 > > > > <perfin...@gentoo.org> 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] Re: [gentoo-commits] repo/gentoo:master commit in: dev-ruby/metasm/
On Fri, 9 Oct 2015 17:48:08 +0200
Patrick Lauer <patr...@gentoo.org> wrote:
>
>
> On 10/09/15 17:42, Davide Pesavento wrote:
> > On Fri, Oct 9, 2015 at 5:35 PM, hasufell <hasuf...@gentoo.org> 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 joakim.tjernl...@transmode.se пишет:
On Wed, 2015-07-22 at 14:30 +0200, Michał Górny wrote:
Joakim Tjernlund joakim.tjernl...@transmode.se 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 EOF ${_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 mgo...@gentoo.org пишет: Dnia 2014-12-08, o godz. 09:56:11 Alexis Ballier aball...@gentoo.org napisał(a): On Sun, 7 Dec 2014 11:37:57 +0100 Michał Górny mgo...@gentoo.org 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 pa...@gentoo.org пишет: 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 bluen...@gentoo.org wrote: On 10/11/14 16:28, Rich Freeman wrote: On Sat, Oct 11, 2014 at 4:07 PM, M. Ziebell ziebell_ma...@posteo.de 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: snip #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 pe...@stuge.se 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 pa...@gentoo.org пишет:
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] bash-completion-2.1-r1 once again
В Tue, 26 Aug 2014 12:51:22 +0200 Michał Górny mgo...@gentoo.org пишет: 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] Update to the pax-utils.eclass
On Tue Aug 26 22:27:36 2014 Anthony G. Basile bluen...@gentoo.org 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] Re: don't rely on dynamic deps
В Sun, 27 Jul 2014 14:42:24 +0300 Samuli Suominen ssuomi...@gentoo.org пишет: On 26/07/14 15:49, Ciaran McCreesh wrote: On Sat, 26 Jul 2014 12:41:16 + (UTC) Martin Vaeth mar...@mvath.de wrote: hasufell hasuf...@gentoo.org 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?
В Fri, 30 May 2014 18:10:40 +0300 Samuli Suominen ssuomi...@gentoo.org пишет: 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] 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 sw...@gentoo.org 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] RFC: using .xz for doc/man/info compression
В Sun, 11 May 2014 18:26:32 -0500
Gordon Pettey petteyg...@gmail.com пишет:
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 \;
real0m46.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
В Mon, 12 May 2014 14:47:36 +0400 Alexander Tsoy alexan...@tsoy.me пишет: В Sun, 11 May 2014 18:26:32 -0500 Gordon Pettey petteyg...@gmail.com пишет: 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
В Mon, 12 May 2014 14:17:11 +0200
Tom Wijsman tom...@gentoo.org пишет:
On Mon, 12 May 2014 14:47:36 +0400
Alexander Tsoy alexan...@tsoy.me 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
В Sun, 11 May 2014 19:46:50 +0200 Michał Górny mgo...@gentoo.org пишет: 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 11:11:53 +0900 Naohiro Aota na...@gentoo.org пишет: Diego Elio Pettenò flamee...@flameeyes.eu 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] [PATCH] fcaps.eclass: Group name portability
В Tue, 15 Apr 2014 12:06:44 +0400
Alexander Tsoy alexan...@tsoy.me пишет:
В Tue, 15 Apr 2014 11:11:53 +0900
Naohiro Aota na...@gentoo.org пишет:
Diego Elio Pettenò flamee...@flameeyes.eu 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] Handling /dev/rfkill, testers wanted
В Fri, 07 Mar 2014 22:15:40 +0200 Samuli Suominen ssuomi...@gentoo.org пишет: 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] Handling /dev/rfkill, testers wanted
В Fri, 07 Mar 2014 21:17:20 +0200
Samuli Suominen ssuomi...@gentoo.org пишет:
- 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] Recommend cronie instead of vixie-cron in handbook?
On Wed Dec 11 23:30:58 2013 Peter Stuge pe...@stuge.se 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
