[gentoo-dev] Re: RFC: enabling ipc-sandbox & network-sandbox by default
On Sun, 11 May 2014 23:42:38 +0200 Michał Górny wrote: > Hi, everyone. > > Almost 9 months ago I've committed three new FEATURES for portage: > cgroup, ipc-sandbox and network-sandbox. Today I'd like to propose > enabling at least the latter two by default. > > > Firstly, I'd like to shortly remind you what they do: > > 1. cgroup -- puts all processes spawned by ebuild to cgroup, and kills > all of them once phase exits (prevents leaving orphans), > > 2. ipc-sandbox -- puts all processes spawned by ebuild to a separate > IPC namespace, preventing them from interfacing other system services > via IPC (message queues, semaphores, shared memory), > > 3. network-sandbox -- puts all processes spawned by ebuild to > a separate network namespace with a private loopback interface, > preventing them from interfacing other system services, local network > and the Internet. [snip] All three of these require kernel support. It might be a good idea to add the needed options to that Gentoo Linux menu we have in gentoo-sources and enable them by default. I think it would be non-obvious to a new user that they would have to enable network and ipc namespaces for portage to work properly out of the box (and if they disable the latter they get a bunch of cryptic "Unable to unshare: EINVAL" messages every time they build something which isn't very helpful). Do we know of any packages broken by these features? Maybe we can add them to the dev profiles for a while before we dump it on everyone. Otherwise +1. -- Ryan Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: enabling ipc-sandbox & network-sandbox by default
On 12/05/14 02:18, Davide Pesavento wrote: > On Sun, May 11, 2014 at 11:42 PM, Michał Górny wrote: >> Hi, everyone. >> >> Almost 9 months ago I've committed three new FEATURES for portage: >> cgroup, ipc-sandbox and network-sandbox. Today I'd like to propose >> enabling at least the latter two by default. >> > > +1 > > I've been using all three of them since their introduction, without > any problems. > > Thanks, > Davide > Same here. No Problems ever. Only if packages try to access the net, which we don't want anyway, you will have problems. Jusitn signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New category lxqt-base
On 12 May 2014 03:28, Jauhien Piatlicki wrote: > Hi all, > > LXQt 0.7.0 has been released [1]. > > As it is project different from LXDE That is debatable. LXQt is released by the merged LXDE and Razor-Qt upstreams. One could say there are simply two expressions of LXDE now: one in GTK+ and one in Qt. > and will be supported in parallel > with it, it seems like a good idea add a new category lxqt-base. Personally I don't see a need for this. All the Qt-specific packages are named accordingly, and should not confuse anyone installing anything from the lxde-base category. I would like to see that latter category re-used for this. But I know the maintainers of LXDE herd do not support this view, and since at this point I don't have the time to maintain LXQt, I will leave the decision up to you guys. > compton-conf > libqtxdg > qt-gtk-engine > libfm > libsysstat > obconf-qt > pcmanfm-qt I think these packages could be placed in the relevant x11-* categories, as they are perfectly usable in other environments as well, tho for ease of maintenance you could stick them with the LXQt packages. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] RFC: using .xz for doc/man/info compression
On 11/05/14 20:46, Michał Górny wrote: > 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. > > I like it, I've been using it myself from make.conf with the current install on this machine. But no, I don't have size or speed comparison to give :/ - Samuli
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2014-05-11 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2014-05-11 23h59 UTC. Removals: kde-base/kdeartwork-sounds 2014-05-09 22:29:08 johu kde-base/kdnssd 2014-05-09 22:30:55 johu kde-base/kwallet2014-05-09 22:32:07 johu games-puzzle/krosswordpuzzle2014-05-10 00:19:05 johu app-portage/udept 2014-05-11 07:58:56 pacho media-libs/libj2k 2014-05-11 08:00:32 pacho media-gfx/cfe 2014-05-11 08:01:14 pacho media-gfx/yablex2014-05-11 08:01:59 pacho app-admin/osiris2014-05-11 08:04:15 pacho sys-power/cpufreqd 2014-05-11 08:05:25 pacho net-irc/ctrlproxy 2014-05-11 08:07:17 pacho x11-misc/pogo 2014-05-11 08:08:30 pacho sci-geosciences/openstreetmap-icons 2014-05-11 08:09:03 pacho dev-python/telepathy-python 2014-05-11 08:15:27 pacho media-tv/huludesktop2014-05-11 08:16:01 pacho app-admin/lcap 2014-05-11 08:16:30 pacho www-apache/mod_chroot 2014-05-11 08:17:31 pacho dev-util/dissy 2014-05-11 08:19:01 pacho Additions: dev-ruby/descendants_tracker2014-05-05 18:03:56 graaff gnome-extra/cinnamon-desktop2014-05-06 03:07:43 tetromino gnome-extra/cinnamon-settings-daemon2014-05-06 03:08:29 tetromino gnome-extra/cinnamon-session2014-05-06 03:09:08 tetromino app-i18n/tagainijisho 2014-05-06 17:37:49 calchan dev-ruby/nio4r 2014-05-07 01:04:50 mrueg gnome-extra/cjs 2014-05-07 03:44:14 tetromino gnome-extra/cinnamon-menus 2014-05-07 03:44:57 tetromino app-crypt/paperkey 2014-05-07 21:56:58 mrueg dev-ruby/rinku 2014-05-07 22:10:12 mrueg gnome-extra/cinnamon-control-center 2014-05-08 02:55:25 tetromino net-wireless/cinnamon-bluetooth 2014-05-08 03:08:23 tetromino dev-python/aniso86012014-05-08 18:08:21 radhermit dev-python/flask-restful2014-05-08 18:19:24 radhermit dev-python/polib2014-05-09 03:41:48 tetromino dev-db/soci 2014-05-09 22:06:24 jauhien dev-db/cppdb2014-05-09 22:51:07 jauhien dev-python/sexpdata 2014-05-10 02:25:22 jauhien gnome-extra/cinnamon-screensaver2014-05-10 18:21:06 tetromino sys-block/zram-init 2014-05-10 22:45:39 jauhien sci-chemistry/propka2014-05-11 10:44:32 jlec dev-python/oslo-vmware 2014-05-11 11:36:58 vadimk sys-boot/winusb 2014-05-11 14:29:45 yac app-arch/xarchiver 2014-05-11 17:57:05 ssuominen dev-util/android-studio 2014-05-11 21:14:32 jauhien dev-ruby/fssm 2014-05-11 22:20:35 vikraman dev-ruby/compass2014-05-11 22:23:10 vikraman -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: kde-base/kdeartwork-sounds,removed,johu,2014-05-09 22:29:08 kde-base/kdnssd,removed,johu,2014-05-09 22:30:55 kde-base/kwallet,removed,johu,2014-05-09 22:32:07 games-puzzle/krosswordpuzzle,removed,johu,2014-05-10 00:19:05 app-portage/udept,removed,pacho,2014-05-11 07:58:56 media-libs/libj2k,removed,pacho,2014-05-11 08:00:32 media-gfx/cfe,removed,pacho,2014-05-11 08:01:14 media-gfx/yablex,removed,pacho,2014-05-11 08:01:59 app-admin/osiris,removed,pacho,2014-05-11 08:04:15 sys-power/cpufreqd,removed,pacho,2014-05-11 08:05:25 net-irc/ctrlproxy,removed,pacho,2014-05-11 08:07:17 x11-misc/pogo,removed,pacho,2014-05-11 08:08:30 sci-geosciences/openstreetmap-icons,removed,pacho,2014-05-11 08:09:03 dev-python/telepathy-python,removed,pacho,2014-05-11 08:15:27 media-tv/huludesktop,removed,pacho,2014-05-11 08:16:01 app-admin/lcap,removed,pacho,2014-05-11 08:16:30 www-apache/mod_chroot,removed,pacho,2014-05-11 08:17:31 dev-util/dissy,removed,pacho,2014-05-11 08:19:01 Added Packages: dev-ruby/descendants_tracker,added,graaff,2014-05-05 18:03:56 gnome-extra/cinnamon-desktop,added,tetromino,2014-05-06 03:07:43 gnome-extra/cinnamon-settings-daemon,added,tetromino,2014-05-06 03:08:29 gnome-extra/cinnamon-session,added,tetromino,2014-05-06 03:09:08 app-i18n/tagainijisho,added,calchan,2014-05-06 17:37:49 dev-ruby/nio4r,added,mrueg,2014-05-07 01:04:50 gnome-extra/cjs,added,tetromino,2014-05-07 03:44:14 gnome-extra/cinnamon-menus,added,tetromino,2014-05-07 03:44:57 app-crypt
Re: [gentoo-dev] RFC: enabling ipc-sandbox & network-sandbox by default
On Sun, May 11, 2014 at 11:42 PM, Michał Górny wrote: > Hi, everyone. > > Almost 9 months ago I've committed three new FEATURES for portage: > cgroup, ipc-sandbox and network-sandbox. Today I'd like to propose > enabling at least the latter two by default. > +1 I've been using all three of them since their introduction, without any problems. Thanks, Davide
Re: [gentoo-dev] RFC: using .xz for doc/man/info compression
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. I don't have a comparison for individual file differences. I posted the short bash scripts at https://gist.github.com/petteyg/96c71fa3c4680552f5c4 On Sun, May 11, 2014 at 4:27 PM, Pacho Ramos wrote: > El dom, 11-05-2014 a las 19:46 +0200, Michał Górny escribió: > > 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 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? > > > > Per: > https://bugs.gentoo.org/show_bug.cgi?id=372653 > > Looks like bzip2 was still better for small files :/ > > >
[gentoo-dev] RFC: enabling ipc-sandbox & network-sandbox by default
Hi, everyone. Almost 9 months ago I've committed three new FEATURES for portage: cgroup, ipc-sandbox and network-sandbox. Today I'd like to propose enabling at least the latter two by default. Firstly, I'd like to shortly remind you what they do: 1. cgroup -- puts all processes spawned by ebuild to cgroup, and kills all of them once phase exits (prevents leaving orphans), 2. ipc-sandbox -- puts all processes spawned by ebuild to a separate IPC namespace, preventing them from interfacing other system services via IPC (message queues, semaphores, shared memory), 3. network-sandbox -- puts all processes spawned by ebuild to a separate network namespace with a private loopback interface, preventing them from interfacing other system services, local network and the Internet. Secondly, the benefits of using the latter two include: 1. improved tree quality through more complete testing In the past, usually users with no or shoddy Internet access were the first to notice ebuilds breaking with no Internet access. With network-sandbox, the ebuilds fail consistently for everyone including developers. They can notice the issues first hand and fix them before committing the ebuild to the tree. 2. protection of user privacy (and security) Currently, programs spawned by ebuilds can submit any data to the Internet, often unnoticed. While committing ebuild performing malicious activity is unlikely, such uses as test suites sending pre-defined data and possibly some system-specific data to remote services happen. This affects user's privacy and we should prevent ebuilds from doing that without user's approval. 3. preventing unsolicited (and possibly costly) Internet access Bear that Gentoo can be run on a machine with byte-paid or otherwise shoddy Internet access (possibly with local distfile host or alike). Ebuilds using network unwisely can reduce throughput of other local services or even cause higher Internet bill. 4. improving security through preventing unsolicited access The build process (and especially tests) can spawn daemons and bind them to network interfaces. Without network sandbox, other processes (or systems if 0.0.0.0/:: is used) can access the spawned services and possibly perform malicious operations. With network-sandbox, even local users can't access the spawned daemons (due to private loopback interface). 5. preventing data loss through thoughtless access to local services I have seen test suites that used production database servers running on the host. You can imagine how much damage such a test suite could cause by mistake. network-sandbox prevents the ebuild from accessing local services, requiring it to run a safe, separate instance. What do you think? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: using .xz for doc/man/info compression
El dom, 11-05-2014 a las 19:46 +0200, Michał Górny escribió: > 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 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? > Per: https://bugs.gentoo.org/show_bug.cgi?id=372653 Looks like bzip2 was still better for small files :/
Re: [gentoo-dev] New category lxqt-base
On Sun, 11 May 2014 21:28:44 +0200 Jauhien Piatlicki wrote: > Hi all, > > LXQt 0.7.0 has been released [1]. If you want us to review and test, feel free to ping when it is ready. > As it is project different from LXDE and will be supported in parallel > with it, it seems like a good idea add a new category lxqt-base. For > previous discussion see [2] and [3]. +1 as this naming is consistent with other desktop environments. > The packages that will go into this category are: > > [...] Consider if you really want all these packages there; some desktop environments get some packages in other categories, this is especially the case when these packages can be used on other desktop environments than the desktop environment itself. This logically categorizing these packages according to their functionality (eg. a dev-util); which limits the desktop environment base effectively to the base of the desktop environment. For example, you can check out what GNOME and MATE do for instance: grep -rl --include=*.ebuild HOMEPAGE.*gnome.org /usr/portage/ | \ sed 's:/usr/portage/\(.*\)/.*.ebuild:\1:' | sort -u grep -rl --include=*.ebuild HOMEPAGE.*mate-desktop /usr/portage/ | \ sed 's:/usr/portage/\(.*\)/.*.ebuild:\1:' | sort -u Another example, using metadata.xml; is to check out what KDE does: grep -rl --include=metadata.xml herd.*kde /usr/portage/ | \ sed 's:/usr/portage/\(.*\)/metadata.xml:\1:' | sort -u Also, here is XFCE; a bit less, but still some packages here and there: grep -rl --include=*.ebuild HOMEPAGE.*xfce /usr/portage/ | \ sed 's:/usr/portage/\(.*\)/.*.ebuild:\1:' | sort -u I'm not sure about other desktop environment; but I think that the general idea is to consider to use other categories when that would be more appropriate for a package in question, so, please consider it. > If there are no objections I'll proceed with adding new category when > ebuilds for 0.7.0 release will be ready (~ in week or two). Make sure to read the following two devmanual documentation pages: http://devmanual.gentoo.org/profiles/categories/ http://devmanual.gentoo.org/ebuild-writing/misc-files/metadata/#category-metadata In summary; first add the category alphabetically to profiles/categories and commit, then create the directory including a metadata.xml that is XML and GLEP 31 validated and commit, then add your packages to it. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Banning modification of pkg-config files
Sure, this is a more complex problem. My point is, for pkg-config files it is relatively easy to fix stuff that depends on non-standard files (I can write a devmanual section about that, but err... this is really trivial). The amount of these downstream pkg-config files is not as big as you might think (yet). So just saying "no" to all new downstream additions will not cause a big explosion and thousands of packages failing to build. Look at the tracker, it's just a few we know of. Cmake is mostly not affected, autotools is often complex enough to still find the libs, Makefiles need a one-line patch. And, by the time we discover more, we can work towards removing them. It will raise awareness about this problem and about the fact that distros like debian tend to do it the lazy way. So it is a pretty easy way to improve portability across distros and so on. We shouldn't do things wrong just because they didn't blow up in our face yet. I am confused why this gets so much attention. The additional workload is really minor. So, not allowing this makes sense to me. For exotic exceptions and corner cases, we can still bend the rules. But, "debian does it too" is not one.
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
[gentoo-dev] New category lxqt-base
Hi all, LXQt 0.7.0 has been released [1]. As it is project different from LXDE and will be supported in parallel with it, it seems like a good idea add a new category lxqt-base. For previous discussion see [2] and [3]. The packages that will go into this category are: compton-conf libqtxdg lxqt-about lxqt-config-randr lxqt-notificationd lxqt-power lxqt-session qt-gtk-engine libfm libsysstat lxqt-appswitcher lxqt-globalkeys lxqt-openssh-askpass lxqt-powermanagement liblxqt lximage-qt lxqt-common lxqt-lightdm-greeter lxqt-panel lxqt-qtplugin obconf-qt liblxqt-mount lxqt-config lxqt-meta lxqt-policykit lxqt-runner pcmanfm-qt If there are no objections I'll proceed with adding new category when ebuilds for 0.7.0 release will be ready (~ in week or two). [1] http://sourceforge.net/p/lxde/mailman/message/32310545/ [2] https://bugs.gentoo.org/show_bug.cgi?id=501606 [3] https://github.com/gentoo/qt/pull/26 Regards, Jauhien signature.asc Description: OpenPGP digital signature
[gentoo-dev] The gx86-multilib project needs your help! (+ roadmap reminder)
Hello, developers and users. The gx86-multilib project is working hard to bring our users a better experience in multilib support. Eventually, we would like to phase out emul-linux and replace it with less flawed multilib-build solution. However, that requires a lot of work and we need your help. One of the major flaws of the emul-linux solution was that a single package corresponded to multiple libraries. For proper multilib support, we need to unbundle those and replace the dependencies on emul-linux with detailed library dependencies. Doing this properly often requires access to the executables. The issue is that many involved packages are proprietary and fetch- -restricted. The multilib team is unable to reach the executables for most of this software, and that's why we would really appreciate help from developers and users that have got the relevant packages installed. Before I get into the fine details, I'd like to explain a bit the roadmap for multilib support in Gentoo. It comprises of three stages: stage I -- gx86-multilib in testing, emul-linux in stable - Until all packages are updated properly, we prefer our stable users using emul-linux. While gx86-multilib is slowly getting in shape, issues can still occur -- most importantly, remaining pre-built emul-linux libraries can depend on different SONAMEs of multilib libraries. In this stage, we'd like to focus on: 1. converting end-user packages to depend on || ( emul-linux-x86-* ( multilib-packages... ) ), 2. converting end-user package dependencies to multilib. The abi_x86_32 support code in emul-linux is mostly meant for testing convenience and we don't really want new packages to depend on that. stage II -- gx86-multilib and emul-linux in stable -- Once we fix all the dependencies and stabilize the revbumps, we can focus on moving gx86-multilib to stable. This involves three steps: 1. removing IUSE=abi_x86_32 hacks from emul-linux -- those should no longer be necessary, and will make switching more painful, 2. removing package.use.stable.mask on abi_x86_32, 3. releasing a news item about the new flags. stage III -- emul-linux phased out -- Once we are sure that everything works fine, we start package.masking emul-linux for removal. We need the most help with updating pre-built package dependencies. Since with many proprietary software we can't access the actual executables to read their dependencies, we'd really appreciate developers helping us by either updating the package dependencies themselves, submitting patches to us or at least submitting 'readelf -d' results for all installed executables. A proper dependency string (during stages I and II above) for a pre-built software looks like: RDEPEND=" || ( ( emul-linux-x86-baselibs[-abi_x86_32(-)] emul-linux-x86-xlibs[-abi_x86_32(-)] ) ( >=sys-apps/util-linux-2.24.1-r3:0[abi_x86_32(-)] dev-libs/libgcrypt:0/20[abi_x86_32(-)] x11-libs/libX11:0/0[abi_x86_32(-)] ) ) " Few things worth noticing: 1. the use of '|| ()' allows us to support both emul-linux and multilib packages during migration period, 2. [-abi_x86_32(-)] on emul-linux is not strictly necessary but will help portage 'switch' to multilib deps once multilib is enabled on the system rather than keeping emul-linux compat metapackages, 3. USE dependencies against EAPI<5 ebuilds are a mess, so it's recommended to depend on version of ebuild that is at least EAPI=5, e.g. via >= dependency or new enough subslot, 4. whenever possible, depend on the specific subslot that is known to provide SONAME equal to the required by your package, e.g. for libgcrypt.so.20 you depend on libgcrypt:0/20, 5. please remember to revbump your package after updating the dependencies. Dynamic dependencies in portage are fragile and sometimes do not work. Reinstalling a binary package shouldn't be a major pain to users, and will guarantee proper dependencies in vardb. We really appreciate all the help we can get, and we'd like to thank all the developers and users that are helping us already. In case of any questions, please do not hesitate to reply to this mail or contact us directly. -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] RFC: using .xz for doc/man/info compression
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 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? -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] Lastrites: media-video/y4mscaler
# Pacho Ramos (11 May 2014) # Dead for ages, now in mjpegtools, bug #492886 # Removal in a month. media-video/y4mscaler
