Re: [gentoo-dev] Qt6RemoteObjects
On Fri, 27 Sep 2024, Ionen Wolkens wrote: Given there also was a user that wanted this, went added and packaged it as dev-qt/qtremoteobjects:6 Thank you very much! Maybe, I'll be able to package the amnezia vpn client (cannot guarantee it yet). Andrey
[gentoo-dev] libgssapi_krb5.so.2
The saga with the amnezia vpn client continues. I've failed to compile it because it needs QtRemoteObjects, and it is not packaged :-(. OK, I've downloaded the binary installer from amnezia.org. Trying to run it, I get ./AmneziaVPN_Linux_Installer.bin: error while loading shared libraries: libgssapi_krb5.so.2: cannot open shared object file: No such file or directory What is libgssapi_krb5.so? Thanks in advance, Andrey
[gentoo-dev] Qt6RemoteObjects
Hi *, I'm trying to compile amnezia client, and immediately get grozin@bilbo ~/amnezia-client/build $ cmake .. -- Could NOT find Qt6RemoteObjects (missing: Qt6RemoteObjects_DIR) CMake Error at client/CMakeLists.txt:41 (find_package): Found package configuration file: /usr/lib64/cmake/Qt6/Qt6Config.cmake but it set Qt6_FOUND to FALSE so package "Qt6" is considered to be NOT FOUND. Reason given by package: Failed to find required Qt component "RemoteObjects". Expected Config file at "/usr/lib64/cmake/Qt6RemoteObjects/Qt6RemoteObjectsConfig.cmake" does NOT exist What is the Qt component RemoteObjects? Does it exist in one of the dev-qt packages? Andrey
[gentoo-dev] sending emails from woodpecker.gentoo.org to q...@gentoo.org fails
Hello *, I use alpine at woodpecker to read and send gentoo-related mails (for example, gentoo-dev, including this email). Usually everything goes normally. However, the alias q...@gentoo.org contains bmangen...@gmail.com, and I get (expanded from ): host gmail-smtp-in.l.google.com[74.125.195.26] said: 550-5.7.26 Your email has been blocked because the sender is unauthenticated. 550-5.7.26 Gmail requires all senders to authenticate with either SPF or DKIM. 550-5.7.26 550-5.7.26 Authentication results: 550-5.7.26 DKIM = did not pass 550-5.7.26 SPF [woodpecker.gentoo.org] with ip: [140.211.166.183] = did not 550-5.7.26 pass 550-5.7.26 550-5.7.26 For instructions on setting up authentication, go to 550 5.7.26 https://support.google.com/mail/answer/81126#authentication 41be03b00d2f7-7db499b84f4si20987432a12.662 - gsmtp (in reply to end of DATA command) Is there some problem with email configuretion at woodpecker? Andrey
Re: [gentoo-dev] fricas[doc] now fails to emerge
On Sat, 17 Aug 2024, Paul Zander wrote:
Check the logfile at ${T}/Xvfb.log
It says
_XSERVTransSocketUNIXCreateListener: ...SocketCreateListener() failed
and then zillion times
libEGL warning: failed to open /dev/dri/card0: Permission denied
Recently I've upgraded mesa to 24.2.0. Can this problem be related to this
upgrade?
The day before yesterday, I've bumped clozurecl to 1.13. Naturally, I
decided to check that it can compile maxima and fricas, and that they
work. fricas emerged fine, with USE=doc. Then I started to emerge -auvND
@world, in particular, it was going to rebuild maxima and fricas again,
with sbcl (I normally use sbcl, not clozurecl). And energing fricas has
failed. The same day, maybe, an hour later. In between a number of
packaged were upgraded. The most suspicious one is mesa - it may be
somehow related to the behavior of Xvfb.
Can anybody with the current mesa try to emerge fricas[doc] and tell us if
it works (any lisp will do, probably, sbcl is the most reasonable one; by
the way, clozurecl compiles fricas very quickly).
Andrey
[gentoo-dev] fricas[doc] now fails to emerge
Hello *, Until recently, fricas[doc] used to emerge fine. Today, when trying to do so, I get zillion F: open_wr S: deny P: /dev/dri/card0 A: /dev/dri/card0 R: /dev/dri/card0 C: Xvfb -displayfd 1 -screen 0 1280x1024x24 +extension RANDR and the line virtx emake book in the ebuild fails. I don't know what has changed. Any ideas? Andrey
Re: [gentoo-dev] Handling optional, expensive variants of test suite
On Fri, 16 Aug 2024, Joonas Niilola wrote: On 9.8.2024 18.40, Sam James wrote: Some packages like libffi, gcc support extended, slower versions of their testsuites. In the past, I've seen both USE="expensive-tests" (I think) and USE="test-full" (used in a few places in-tree atm) for this. I sort of hate both suggestions but I'm open to what people think is best, with a view to then making it a global USE flag then? Thoughts? Count NSS in that list too! I've made a patch locally that uses "tests-full" use flag, so I guess I'd vote for "test-full" to stay consistent. Some tests of sympy take very long. They were commented out in the ebuild. I'd like to have an easy way to run all tests. Andrey
Re: [gentoo-dev] questions about wxwidgets.eclass
On Fri, 5 Jul 2024, Mike Gilbert wrote: It looks like you mass-filed a couple dozen bugs, but left them assigned to bug-wranglers. Please assign your own bug reports, especially when files en-masse. OK, I've assigned them to the corresponding maintainers. Except 2 ones which are maintainer-needed. To whom assign them? I've also filed a thacker bug https://bugs.gentoo.org/935668 to keep track on the progress. Andrey
Re: [gentoo-dev] questions about wxwidgets.eclass
On Wed, 3 Jul 2024, Eli Schwartz wrote: On 7/3/24 12:19 AM, Andrey Grozin wrote: 1. From which phase function should setup-wxwidgets be called? The current statistics of the packages in the tree is: src_configure 66 src_prepare 16 pkg_setup 6 pkg_prepare 1 Does this mean that one of these groups is right, and the other 3 ones are wrong and should be fixed? Well, the eclass docs *literally* state the answer: https://devmanual.gentoo.org/eclass-reference/wxwidgets.eclass/ """ Call this in your ebuild to set up the environment for wxGTK in src_configure. """ Thank you. I've fixed my packages, and filed bugs about other packages calling setup-wxwidgets from somewhere else. Andrey
[gentoo-dev] questions about wxwidgets.eclass
Hello *, 1. From which phase function should setup-wxwidgets be called? The current statistics of the packages in the tree is: src_configure 66 src_prepare 16 pkg_setup 6 pkg_prepare1 Does this mean that one of these groups is right, and the other 3 ones are wrong and should be fixed? 2. Suppose a user has 2 slots installed, 3.0-gtk3 and 3.2-gtk3. [S]he can eselect one of them. The slot used during emerging a package should depend only on WX_GTK_VER in the ebuild, and must not depend on which slot is currently eselected. Does wxwidgets.eclass guarantee this? Andrey
Re: [gentoo-dev] Mysterious behavior of app-text/qpdfview
On Sun, 12 May 2024, netfab wrote: View -> Convert to grayscale That's it! I'm absolutely sure that I never enabled this option on purpose. Probably, some accidental mouse click. Sorry for the noise, Andrey
[gentoo-dev] Mysterious behavior of app-text/qpdfview
Hello *, The behavior of app-text/qpdfview has changed recently (approx. durung the last week) in a mysterious way. qpdfview itself has not changed (the revent -0.5_p1 is irrelevant - I'm discussing the stable version 0.5). Until recently, qpdfview displayed color pdf files as expected - in color. Now it displays them as black-and-white (more exactly, as levels of grey). The source of qpdfview itself has not changed - it's the same version 0.5 which worked fine a week ago. So, it's the result of an upgrade of some library on which it depends. It depends on a number of Qt5 libraries (some of them were upgraded recently); on mesa (indirectly); on poppler; and on some things which don't seem relevant for the color/black-and-white issue. At the moment I have no idea where to start investigating the problem. Just to check: xpdf, mupdf, gv, zathura display these color pdf files correctly, in color. They depend on many of the same libraries; if some of the recently upgraded libraries suddently has become broken, this does not influence these other pdf viewers. Any ideas where to start investigating what has become broken? Thanks in advance, Andrey
[gentoo-dev] arb has been merged into flint
sci-mathematics/arb has been merged into sci-mathematics/flint, see https://github.com/flintlib/arb Is it time to last-rite sci-mathematics/arb? Andrey
[gentoo-dev] pkgcheck scan: error: failed running git log: fatal: unrecognized argument: --no-find-copies
I'm trying to bump master-pdf-editor and get grozin@bilbo /home/gentoo/app-text/master-pdf-editor $ pkgcheck scan pkgcheck scan: error: failed running git log: fatal: unrecognized argument: --no-find-copies grozin@bilbo /home/gentoo/app-text/master-pdf-editor $ pkgdev commit -m 'bump to 5.9.82' pkgdev commit: error: failed running git log: fatal: unrecognized argument: --no-find-copies grozin@bilbo /home/gentoo/app-text/master-pdf-editor $ What has happened with pkgcheck scan? Andrey
Re: [gentoo-dev] special small-files USE flag without effect on dependencies: [ unicode ]
On Sun, 11 Feb 2024, Sam James wrote: parona ended up messaging me and pointing out that https://pkgcore.github.io/pkgcheck/man/pkgcheck.html#useflagwithoutdeps already says... In cases where this USE flag is appropriate, you can silence this warning by adding a description to this USE flag in metadata.xml file and thus making it a local USE flag instead of global one. Thank you very much! Done. The problem solved. Andrey
[gentoo-dev] special small-files USE flag without effect on dependencies: [ unicode ]
Hello *, pkgcheck complains about each new version of dev-lisp/sbcl: UseFlagWithoutDeps: version 2.4.1: special small-files USE flag without effect on dependencies: [ unicode ] The USE flag "unicode" in the sbcl ebuild has nothing to do with installing / not installing any files, small or otherwise. It determins whether the produced lisp will support unicode internally: sbcl_feature "$(usep unicode)" ":sb-unicode" Usually this is desirable, so, in USE we have +unicode. Is there a way to silence these warnings? Andrey
[gentoo-dev] Last rites: app-text/coolreader
The upstream development has stopped. There is an active fork: coolreader-ng (https://gitlab.com/coolreader-ng). It consists of 3 packages: app-text/crengine-ng app-text/crqt-ng (Qt frontend) app-text/crwx-ng (wxGTK frontend) crqt-ng contains many new useful features as compared to coolreader. There is no reason to continue to use app-text/coolreader - please switch to these ng packages. Andrey
Re: [gentoo-dev] are there any lisps in the default/linux/amd64/17.0/musl profile?
On Sun, 23 Jul 2023, Ulrich Mueller wrote: I think what happens is this: sbcl is masked on musl, but it is the only version that is enabled in the ebuild by the IUSE="+sbcl" default. Therefore, none of the versions available on musl is enabled there, resulting in an unsatisfied REQUIRED_USE. Thank you. Probably, pkgcheck complains because of +sbcl, and sbcl is masked. sbcl is the best lisp for maxima on systems where it exists, therefore it is the default. If it does not exist, a user can try some other lisp. So, I'm going to continue to ignore this complaint. By the way, I've just found (and fixed) another minor problem. Due to some (uninteresting) technical reasons, clozurecl in maxima ebuild is controlled by the use flags clozurecl (on 32-bit arches) and clozurecl64 (on 64-bit arches). The clozurecl flag is masked in arch/base/use.mask and unmasked in arch/x86/use.mask (correctly). But clozurecl was not controlled in the same way. Now I mask it in arch/base/use.mask and unmask in arch/amd64/use.mask. Andrey
Re: [gentoo-dev] are there any lisps in the default/linux/amd64/17.0/musl profile?
On Sun, 23 Jul 2023, Ulrich Mueller wrote:
$ find . -name 'use.mask' -exec grep -E
'^(clisp|clozurecl|clozurecl64|cmucl|ecls|gcl|sbcl)\b' {} +
./features/musl/use.mask:sbcl
./arch/base/use.mask:clisp
./arch/base/use.mask:clozurecl
./arch/base/use.mask:cmucl
./arch/base/use.mask:ecls
./arch/base/use.mask:gcl
./arch/base/use.mask:sbcl
Yes, but the flags for lisps running on amd64 are unmasket in
profiles/arch/amd64/use.mask:
grozin@bilbo /home/gentoo/profiles/arch/amd64 $ grep -E
'^-(clisp|clozurecl|clozurecl64|cmucl|ecls|gcl|sbcl)' use.mask
-clisp
-ecls
-gcl
-sbcl
OK, sbcl is masked on musl. But why clisp, ecls, or gcl cannot be used in
the amd64 musl profile?
(I don't know if they actually work on amd64 musl systems, or if anybody
ever tried to do so. I just ask a formal question about Gentoo profiles
system.)
Andrey
[gentoo-dev] are there any lisps in the default/linux/amd64/17.0/musl profile?
Hello *, grozin@bilbo /home/gentoo/sci-mathematics/maxima $ pkgcheck scan gentoo -- updating git cache: commit date: 2023-07-23 sci-mathematics/maxima UnstableOnly: for arches: [ ppc, x86 ], all versions are unstable: [ 5.46.0-r1, 5.47.0 ] PotentialStable: version 5.46.0-r1: slot(0), stabled arch: [ amd64 ], potentials: [ ~ppc, ~x86 ] RequiredUseDefaults: version 5.46.0-r1: profile: 'default/linux/amd64/17.0/musl' (4 total) failed REQUIRED_USE: ( clisp || clozurecl || clozurecl64 || cmucl || ecls || gcl || sbcl ) RequiredUseDefaults: version 5.47.0: profile: 'default/linux/amd64/17.0/musl' (3 total) failed REQUIRED_USE: ( clisp || clozurecl || clozurecl64 || cmucl || ecls || gcl || sbcl ) It seems that there are no lisps in this profile. This may be correct. But where are all lisps masked? I see only grozin@bilbo /home/gentoo/profiles $ find -name package.mask | xargs fgrep lisp ./arch/powerpc/ppc64/package.mask:dev-lisp/sbcl ./arch/powerpc/ppc64/32ul/package.mask:-dev-lisp/sbcl ./arch/powerpc/ppc64/64le/package.mask:-dev-lisp/sbcl ./arch/sparc/64ul/package.mask:dev-lisp/sbcl sbcl is masked on arches to which it is not ported. Fine. But I don't see where lisps are masked specifically for musl. This may be correct. As far as I know, sbcl cannot work on musl systems; don't know about other lisps. If this is so, maxima should also be masked on musl. Andrey
[gentoo-dev] dev-lisp/gcl: more arches?
Hello *, I've just committed dev-lisp/gcl-2.6.15_pre3. It successfully compiles such highly non-trivial things as maxima and fricas (though compilation times are *very* long), and they work well. gcl is, probably, second to sbcl with respect to speed (I mean the speed of the result of compilation, naturally, not of the compilation process). gcl is supposed to be very portable. Currently in Gentoo it is ~amd64 ~arm ~ppc ~ppc64 ~x86 In Debian, gcl is supported on amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x plus inofficial ports to alpha hppa m68k ppc64 riscv64 sh4 sparc64 x32 Impressive. Maybe, somebody who has appropriate hardware can try to build gcl on arm64? Or on some other arch missing in the Gentoo list? Andrey
Re: [gentoo-dev] sci-mathematics/fricas ebuild
On Tue, 11 Jul 2023, Ulrich Mueller wrote: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4c6412ecf83a0465531c65b115b0e3ff8d875296 Thank you! Andrey
[gentoo-dev] sci-mathematics/fricas ebuild
Hello *,
Recently I've committed fricas-1.3.9.ebuild. The SRC_URI has suddenly
changed from .../${P}-full.tar.bz2 (as was the case in all previous
versions) to .../${P}.full.tar.bz2. I was surprised, but, of course, used
this SRC_URI with a dot in the 1.3.9 ebuild. But now the main fricas
author, after questions in the mailing list, has renamed (!) the
release tarball to the previous scheme with a dash. So, now the
fricas-1.3.9.ebuild in the tree is invalid.
The problem is that at the moment I'm at Teletskoye lake in wild Siberian
mountains. Of course, without my notebook from which I can commit ebuilds.
And I'll return to civilization only on next Tuesday.
Can somebody please edit the fricas-1.3.9.ebuild - replace the SRC_URI by
.../${P}-full.tar.bz2 and commit it to the tree?
Many thanks in advance,
Andrey
[gentoo-dev] A problem with updating my key (again)
Hi *, My key was going to expire soon. So, as usual, I have prolonged it for the next year (several days ago). I've sent it to the Gentoo keyserver. I've checked that the fingerpring of my key in LDAP coinsides with the fingerprint I see locally. Today I've tried to bump dev-lisp/sbcl to 2.3.5. But I got remote: *** None of your keys comply with GLEP 63. remote: Please update the keys into conformance if you wish to continue remote: using them. If not, please remove unused keys from LDAP. remote: FATAL: VREF/proj-gentoo-02-gpg: helper program exit status 256 remote: 53D4ABFA88DD61C4 [Andrey Grozin (science) ] [E] expire:short Expiration date is too close, please renew (is 2023-06-17 15:32:53, less than 14 days) remote: 53D4ABFA88DD61C4:3AFFCE974D34BD8C [Andrey Grozin (science) ] [E] expire:short Expiration date is too close, please renew (is 2023-06-17 15:34:59, less than 14 days) remote: error: hook declined to update refs/heads/master To git.gentoo.org:repo/gentoo.git ! [remote rejected] master -> master (hook declined) error: failed to push some refs to 'git.gentoo.org:repo/gentoo.git' It seems that the remote git has ignored the fact that my key has been prolonged about 3 days ago. One year ago I had the same situation. Is there any reliable way to inform this git hook about the prolongation of my key? Every year the same problem :-( Andrey
Re: [gentoo-dev] wxGTK:3.0-gtk3 vs wxGTK:3.2-gtk3
On Wed, 31 May 2023, Piotr Karbowski wrote: There's at least a few project that will not work with new wxGTK, out of what I know that is in tree the SuperSlicer and the PrusaSlicer that in the version currently in tree requires wxGTK 3.0. The newer version of PrusaSlicer actually requires wxGTK 3.1 and does not work well with 3.2, unless the wxGTK 3.2 is built with '--disable-glcanvasegl', but this is not interfaced as USE flag and I doubt ever will be. Yes, surely there are projects which work with 3.0 but not 3.2. But most projects will, probably, just work with 3.2. I've just switched 2 projects to 3.2 without negative consequences. Andrey
[gentoo-dev] wxGTK:3.0-gtk3 vs wxGTK:3.2-gtk3
Hello *, wxGTK:3.2-gtk3 is now stable. But there are 98 ebuilds depending on wxGTK:3.0-gtk3 and only 22 ebuilds depending on wxGTK:3.2-gtk3 in the tree. Probably, in a vast majority of cases 3.0 can be simply replaced by 3.2 without any negative consequences. What could be a reasonable way to organize the transition 3.0 -> 3.2 in the tree? File a zillion bugs? The fact that this dependence is written in a special syntax WX_GTK_VER="3.0-gtk3" makes such a transition more difficult. Unlike the normal dependency syntax, it is not possible to write something like x11-libs/wxGTK:*= This is unfortunate. The 3.0 -> 3.2 transition absolutely requires to edit ebuild texts, unlike :*= where the same ebuild can work with different slots (just a recompilation is sufficient for transition). This fact makes it impossible for an ebuild to work with both slots. In a majority of cases, I suppose, it would be desirable to allow an ebuild to work with any of these 2 slots, without a necessity to edit it. But, alas, this is not possible. Andrey
[gentoo-dev] all openrc messages look very strange after upgrading many packages yesterday
Hello *, Yesterday I upgraded a large number of packages (but not including openrc). After that all openrc messages look very strange. Many (null), colors are weird. Don't know which specific upgrade has led to this effect. This includes system boot messages and system poweroff messages (in text mode) as well as messages in the terminal in X, as illustrated in the screenshot. What has happened? Andrey
[gentoo-dev] sci-geosciences/routino: DISTUTILS_USE_SETUPTOOLS=no -> DISTUTILS_USE_PEP517=?
Hello *,
sci-geosciences/routino has the USE flag python.
I've just changed
PYTHON_COMPAT=( python3_{9..10} )
to
PYTHON_COMPAT=( python3_{9..11} )
in sci-geosciences/routino, routino[python] builds fine. The ebuild
contains the lines
DISTUTILS_USE_SETUPTOOLS=no
PYTHON_COMPAT=( python3_{9..11} )
inherit toolchain-funcs distutils-r1
and pkgcheck scan complains that it is not PEP517. I've tried to change
DISTUTILS_USE_SETUPTOOLS=no
to
DISTUTILS_USE_PEP517=setuptools
But then emerging routino[python] leads to lots of strange things:
* python3_9: running distutils-r1_run_phase python_install
python3.9 setup.py install
/usr/lib/python3.9/site-packages/setuptools/command/install.py:34:
SetuptoolsDeprecationWarning: setup.py install is deprecated. Use build
and pip and other standards-based tools.
warnings.warn(
/usr/lib/python3.9/site-packages/setuptools/command/easy_install.py:144:
EasyInstallDeprecationWarning: easy_install command is deprecated. Use
build and pip and other standards-based tools.
warnings.warn(
* ACCESS DENIED: open_wr:
/usr/lib/python3.9/site-packages/test-easy-install-190.write-test
error: can't create or remove files in install directory
The following error occurred while trying to add or remove files in the
installation directory:
[Errno 13] Permission denied:
'/usr/lib/python3.9/site-packages/test-easy-install-190.write-test'
The installation directory you specified (via --install-dir, --prefix, or
the distutils default setting) was:
/usr/lib/python3.9/site-packages/
Perhaps your account does not have write access to this directory? If the
installation directory is a system-owned directory, you may need to sign
in
as the administrator or "root" account. If you do not have administrative
access to this machine, you may wish to choose a different installation
directory, preferably one that is listed in your PYTHONPATH environment
variable.
For information on other options, you may wish to consult the
documentation at:
https://setuptools.pypa.io/en/latest/deprecated/easy_install.html
Please make the appropriate changes for your system and try again.
* ERROR: sci-geosciences/routino-3.3.3-r4::grozin failed (install phase):
* (no error message)
*
* Call stack:
* ebuild.sh, line 136: Called src_install
* environment, line 3349: Called distutils-r1_src_install
* environment, line 1553: Called _distutils-r1_run_foreach_impl
'python_install'
* environment, line 690: Called python_foreach_impl
'distutils-r1_run_phase' 'python_install'
* environment, line 3027: Called multibuild_foreach_variant
'_python_multibuild_wrapper' 'distutils-r1_run_phase' 'python_install'
* environment, line 2586: Called _multibuild_run
'_python_multibuild_wrapper' 'distutils-r1_run_phase' 'python_install'
* environment, line 2584: Called _python_multibuild_wrapper
'distutils-r1_run_phase' 'python_install'
* environment, line 1022: Called distutils-r1_run_phase
'python_install'
* environment, line 1511: Called python_install
* environment, line 3161: Called esetup.py 'install'
* environment, line 2118: Called die
* The specific snippet of code:
* "${@}" || die -n;
So,
setup.py install is deprecated
easy_install command is deprecated
and it tries to install test-easy-install-190.write-test to some strange
place. Any idea what I should use in DISTUTILS_USE_PEP517?
Andrey
Re: [gentoo-dev] sys-devel/make-4.4: https://savannah.gnu.org/bugs/?63552
On Fri, 20 Jan 2023, Sam James wrote: If you notice an issue in a package, please file a bug. If you do decide to post on the ML about it, please CC its maintainers. There was a problem with building sbcl head. They have added a workaround so that now it works with make 4.4. Anyway, in this case, make 4.4.1 is around the corner. 4.1.0.90 is already in tree as an unkeyworded prerelease. Good to know, thanks. Andrey
[gentoo-dev] sys-devel/make-4.4: https://savannah.gnu.org/bugs/?63552
There seems to be a regression in 4.4 which potentially can affect many packages. It is fixed upstream. Wouldn't it be good to include this fix in the Gentoo package? Andrey
Re: [gentoo-dev] How to add -std=c++14 to CXXFLAGS of a cmake.eclass based package?
On Sat, 17 Dec 2022, Arsen Arsenović wrote: audacity-2.4.2-r3.ebuild has something for this already: ``append-cxxflags -std=gnu++14'' Thanks, this works. Andrey
[gentoo-dev] How to add -std=c++14 to CXXFLAGS of a cmake.eclass based package?
Hello *,
I'm trying to package a new version of sci-visualization/gle which now
uses cmake. After some patching CMakeLists.txt, it configures
successfully. But at build time it spits zillion errors
error: ISO C++17 does not allow dynamic exception specifications
The natural thing to try is to add -std=c++14 to CXXFLAGS. So I tried
src_compile() {
CXXFLAGS="${CXXFLAGS} -std=c++14" cmake_src_compile
}
but this makes no difference, c++17 is still used. How to convince
cmake_src_compile to use -std=c++14?
Thanks in advance,
Andrey
Re: [gentoo-dev] musl, sbcl, and ros
On Sat, 3 Dec 2022, Haelwenn (lanodan) Monnier wrote: Well Alpine is using the ecl route: https://git.alpinelinux.org/aports/tree/community/sbcl/APKBUILD And GNU GuixSD is using the clisp route but per the comments ecl would be better: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/lisp.scm#n424 In principle, we can do something similar: 1. If elibc_musl, sbcl should BDEPEND on ecls (or maybe clisp) 2. In the same case, the build system should be patched to use another bootstrap lisp 3. For elibc_glibc nothing should change 4. All this should be tested on a computer running a musl profile Personally I can do nothing of this list. I have no computer with musl profile. Does any developer running such a system volunteer to do this work - to be a co-maintained of sbcl on musl? If not, I'll go forward and pmask all packages which unconditionally depend on sbcl (maybe via some intermediates) in profiles/features/musl/use.mask. Andrey
Re: [gentoo-dev] musl, sbcl, and ros
On Fri, 2 Dec 2022, Tom Gillespie wrote: For the record I've had sbcl building and running on musl for months without issue (at one point I even had static linking working). You have to cross compile a musl version and then side load the binary instead of using one of the distributed binaries. See https://github.com/tgbugs/dockerfiles/blob/master/source.org#sbcl-bootstrap for reference. See also https://hub.docker.com/r/tgbugs/musl/tags?page=1&name=sbcl. Yes. Either cross-compiling, or (with some luck) using some other lisp for bootstrap. Thus I'd very much appreciate if it sbcl were not masked on those profiles. The sbcl ebuild from the Gentoo tree is useless on musl. And hence it should be masked. Otherwise somebody would think that [s]he can simply emerge sbcl on a musl profile, and will be disappointed. Andrey
Re: [gentoo-dev] musl, sbcl, and ros
On Fri, 2 Dec 2022, Sam James wrote: If the dependencies are optional (at least for some), we should indeed (package.)use.mask sbcl on musl to reduce the damage, then package.mask the remaining unconditional reverse dependencies. But I cannot do these this myself. I use neither musl nor ros. I suppose ros developers should update their ebuilds to conditionalize as many uses of sbcl as possible. It would be good to call this USE flag "sbcl". 2 packages (sci-mathematics/maxima and sci-mathematics/fricas) already use this name, and I have included it in profiles/features/musl/use.mask. Thanks, Andrey
[gentoo-dev] musl, sbcl, and ros
Hello *,
The sbcl upstream only supports glibc Linux systems. Building sbcl uses
sbcl binary (which fails to run on musl) to compile sbcl sources.
In principle, one can try a workaround: use some other lisp (say, clisp or
ecl) as the bootstrap lisp. This way is at best brittle: there is no
guarantee that these external lisps will compile the sbcl sources
successfully. People say that sometimes this works.
No user of musl profiles could successfully emerge sbcl from time
-infinity to the present moment. The natural solution is to pmask sbcl in
musl profiles.
So I've done. But this leads to unexpected consequences. dev-ros/roslisp
hard depends on sbcl. ros-meta/ros_core hard depends on roslisp.
ros-meta/ros_base hard depends on ros_core.
ros-meta/{perception,robot,viz} hard depend on ros_core. Maybe, more
packages depend on {perception,robot,viz}, I haven't checked.
This means that no user of the musl profiles has ever been able to emerge
all these packages (because they did not have sbcl). And all these
packages should be pmasked in the musl profiles.
Before doing this drastic change I decided to ask for your advice. Should
I go forward and pmask them now? Or maybe for some of them the dependence
on sbcl can be made optional, and it would be sufficient to use.mask such
an option name? Or maybe roslisp can use some other lisp instead of sbcl?
Andrey
[gentoo-dev] setuptools problem
Hello *,
I'm trying to bump dev-python/rpyc to 5.2.3, and I get
Compiling source in
/var/tmp/portage/dev-python/rpyc-5.2.3/work/rpyc-5.2.3 ...
* python3_9: running distutils-r1_run_phase distutils-r1_python_compile
python3.9 -c from setuptools import setup; setup() build -j 6
configuration error: `project.license` must be valid exactly by one
definition (2 matches found):
- keys:
'file': {type: string}
required: ['file']
- keys:
'text': {type: string}
required: ['text']
DESCRIPTION:
`Project license
`_.
GIVEN VALUE:
"MIT"
OFFENDING RULE: 'oneOf'
DEFINITION:
{
"oneOf": [
{
"properties": {
"file": {
"type": "string",
"$$description": [
"Relative path to the file (UTF-8) which
contains the license for the",
"project."
]
}
},
"required": [
"file"
]
},
{
"properties": {
"text": {
"type": "string",
"$$description": [
"The license of the project whose meaning is
that of the",
"`License field from the core metadata",
"`_."
]
}
},
"required": [
"text"
]
}
]
}
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3.9/site-packages/setuptools/__init__.py", line 87,
in setup
return distutils.core.setup(**attrs)
File "/usr/lib/python3.9/distutils/core.py", line 121, in setup
dist.parse_config_files()
File "/usr/lib/python3.9/site-packages/setuptools/dist.py", line 868, in
parse_config_files
pyprojecttoml.apply_configuration(self, filename,
ignore_option_errors)
File
"/usr/lib/python3.9/site-packages/setuptools/config/pyprojecttoml.py",
line 62, in apply_configuration
config = read_configuration(filepath, True, ignore_option_errors,
dist)
File
"/usr/lib/python3.9/site-packages/setuptools/config/pyprojecttoml.py",
line 126, in read_configuration
validate(subset, filepath)
File
"/usr/lib/python3.9/site-packages/setuptools/config/pyprojecttoml.py",
line 51, in validate
raise ValueError(f"{error}\n{summary}") from None
ValueError: invalid pyproject.toml config: `project.license`.
configuration error: `project.license` must be valid exactly by one
definition (2 matches found):
- keys:
'file': {type: string}
required: ['file']
- keys:
'text': {type: string}
required: ['text']
Any idea what has gone wrong? By googling I've found
https://github.com/vanheeringen-lab/seq2science/issues/851
https://bytemeta.vip/repo/jdtuck/fdasrsf_python/issues/23
which seem similar.
Thanks in advance,
Andrey
Re: [gentoo-dev] pkgdev commit and gpg-agent
On Mon, 1 Aug 2022, Andrew Savchenko wrote: I have the same problem with pkgdev. It fails to run at least CLI/TUI pinentry when password is needed. To workaround I sign some dummy file with `gpg -s file`, then within cache period I can use it for commits using pkgdev. Thank you, this workaround works. Andrey
[gentoo-dev] pkgdev commit and gpg-agent
Hello *, Sorry for a very naive question. In the past, I used repoman commit to commit a new ebuild. I got a text screen in my terminal where I typed my passphraise (if I then committed something else within the timeout, I didn't have to re-type it). Now we are recommended to use pkgdev commit instead. But it does not ask for my passphraise, just writes an error message that it cannot sign my commit. If I commit something with repoman and then (within the timeout) commit something else with pkgdev, it works. My .gnupg/gpg-agent.conf is pinentry-program /usr/bin/pinentry-curses write-env-file default-cache-ttl 100 My .gnupg/gpg.conf includes the line use-agent I can, of course, continue to use repoman for committing. But now it does not add the Signed-off-by: automatically. I have to add it by hand, in nano. This is definitely the most convenient way. Thanks in advance, Andrey
Re: [gentoo-dev] Re: why doesn't readline-6 install libreadline.so symlink?
On Sat, 26 Sep 2009, Mike Frysinger wrote: so long as the linker looks at /usr/lib before /lib, which is usually the case, unless "-L/lib" is passed to ld (by way of gcc) incorrect -- link order doesnt matter here with readline-6 Here's a specific example: sci-mathematics/pari-2.3.4-r1. It has a hand-written Configure script (not configure). It searches for libreadline.so in a list of directories, and sees that it points to libreadline.so.5 (this is after libreadline-5 has been unmerged). So, it adds -l libreadline.so.5 to the linking flags. Clearly, this is not the desired behaviour. What can be done to avoid it? Andrey
[gentoo-dev] why doesn't readline-6 install libreadline.so symlink?
I'm using portage-2.2_pre*. After upgrading to sys-libs/readline-6.0, portage (naturally) kept /lib/libreadline.so.5 -> /lib/libreadline.so.5.2, because a lot of programs needed it. I did emerge @preserved-rebuild, and only one binary using libreadline.so.5.2 left: /usr/bin/gp, the interactive interpreter of sci-mathematics/pari. Re-emerging it does not help: headers from readline-6 are used, but the program links wirh libreadline.so.5.2. I thought something is wrong in the pari's configure. This package does not use autoconf, but a hand-written Configure script. It seems all right. Then I found that /lib/libreadline.so symlink still points to libreadline.so.5. This confuses the pari's Configure. I made it to point to libreadline.so.6 by hand, and re-emerged pari. OK, gp now links with libreadline.so.6.0. Why doesn't readline-6.0 ebuild install this symlink? After this re-emerging of pari, portage said !!! existing preserved libs: package: sys-libs/readline-6.0_p3 * - /lib/libreadline.so * used by /usr/bin/M2 (sci-mathematics/Macaulay2-1.2-r3) * used by /usr/bin/Singular-3-0-4 (sci-mathematics/singular-3.0.4.4) * used by /usr/bin/asy (media-gfx/asymptote-1.86) * used by 111 other files I already re-emerged these packages (at least, 3 shown) as a part of emerging @preserved-rebuild after upgrading readline, and they were not in the @preserved-rebuild set before I changed the libreadline.so symlink. Does this mean that all of these packages used libreadline.so -> libreadline.so.5? This is not good. I'm going to emerge @preserved-rebuild again, to be sure that my system is in a self-consistent state. It seems that keeping libreadline.so -> libreadline.so.5 after merging readline-6.0 and unmerging readline-5.2 is a bad idea. Andrey
Re: [gentoo-dev] repoman complains about a ebuild in the tree
Nirbheek Chauhan wrote:
That's because repoman is context-aware. When you use it, it'll look
"around" (../..) the current directory for the dependencies. If it
finds the deps, it'll check if the ebuilds. If can't find the
dependencies, it'll look in ${PORTDIR} for checking them.
Thanks. I really haven't updated the whole cvs tree (because it takes sooo
lng), only the category (sci-visualization). I thought that the main
(rsync) tree is used for dependences.
cvs-updating ~/gentoo-x86 solved the problem.
Andrey
Re: [gentoo-dev] repoman complains about a ebuild in the tree
Jorge Manuel B. S. Vicetto wrote: I just tried it here and I don't get any errors from repoman. I've run repoman full -d and it only complains about ebuild.allmasked. Have you synced the entire repo? In particular the profiles/* tree? Yes, of course I synced the tree. Now I see even a more strange thing. /me as root in /usr/portage/sci-visualization/mayavi/ gandalf mayavi # repoman full -d RepoMan scours the neighborhood... ebuild.allmasked 1 sci-visualization/mayavi RepoMan sez: "You're only giving me a partial QA payment? I'll take it this time, but I'm not happy." Everything's OK. /me as /me in ~/gentoo-x86/sci-visualization/mayavi/ gro...@gandalf ~/gentoo-x86/sci-visualization/mayavi $ cvs update Warning: untrusted X11 forwarding setup failed: xauth key data not generated Warning: No xauth data; using fake authentication data for X11 forwarding. gro...@gandalf ~/gentoo-x86/sci-visualization/mayavi $ repoman full -d RepoMan scours the neighborhood... ebuild.allmasked 1 sci-visualization/mayavi RDEPEND.badindev 12 sci-visualization/mayavi/mayavi-3.3.0.ebuild: ~amd64(selinux/v2refpolicy/amd64/server) ['>=dev-python/envisageplugins-3.1.1', '>=dev-python/apptools-3.3.0', '>=dev-python/envisagecore-3.1.1'] sci-visualization/mayavi/mayavi-3.3.0.ebuild: ~amd64(selinux/v2refpolicy/amd64/hardened) ['>=dev-python/envisageplugins-3.1.1', '>=dev-python/apptools-3.3.0', '>=dev-python/envisagecore-3.1.1'] sci-visualization/mayavi/mayavi-3.3.0.ebuild: ~amd64(selinux/v2refpolicy/amd64/developer) ['>=dev-python/envisageplugins-3.1.1', '>=dev-python/apptools-3.3.0', '>=dev-python/envisagecore-3.1.1'] sci-visualization/mayavi/mayavi-3.3.0.ebuild: ~amd64(selinux/v2refpolicy/amd64/desktop) ['>=dev-python/envisageplugins-3.1.1', '>=dev-python/apptools-3.3.0', '>=dev-python/envisagecore-3.1.1'] sci-visualization/mayavi/mayavi-3.3.0.ebuild: ~amd64(selinux/v2refpolicy/amd64) ['>=dev-python/envisageplugins-3.1.1', '>=dev-python/apptools-3.3.0', '>=dev-python/envisagecore-3.1.1'] sci-visualization/mayavi/mayavi-3.3.0.ebuild: ~amd64(default/linux/amd64/10.0/no-multilib) ['>=dev-python/envisageplugins-3.1.1', '>=dev-python/apptools-3.3.0', '>=dev-python/envisagecore-3.1.1'] sci-visualization/mayavi/mayavi-3.3.0.ebuild: ~amd64(default/linux/amd64/2008.0/no-multilib) ['>=dev-python/envisageplugins-3.1.1', '>=dev-python/apptools-3.3.0', '>=dev-python/envisagecore-3.1.1'] sci-visualization/mayavi/mayavi-3.3.0.ebuild: ~x86(selinux/v2refpolicy/x86/server) ['>=dev-python/envisageplugins-3.1.1', '>=dev-python/apptools-3.3.0', '>=dev-python/envisagecore-3.1.1'] sci-visualization/mayavi/mayavi-3.3.0.ebuild: ~x86(selinux/v2refpolicy/x86/hardened) ['>=dev-python/envisageplugins-3.1.1', '>=dev-python/apptools-3.3.0', '>=dev-python/envisagecore-3.1.1'] sci-visualization/mayavi/mayavi-3.3.0.ebuild: ~x86(selinux/v2refpolicy/x86/developer) ['>=dev-python/envisageplugins-3.1.1', '>=dev-python/apptools-3.3.0', '>=dev-python/envisagecore-3.1.1'] sci-visualization/mayavi/mayavi-3.3.0.ebuild: ~x86(selinux/v2refpolicy/x86/desktop) ['>=dev-python/envisageplugins-3.1.1', '>=dev-python/apptools-3.3.0', '>=dev-python/envisagecore-3.1.1'] sci-visualization/mayavi/mayavi-3.3.0.ebuild: ~x86(selinux/v2refpolicy/x86) ['>=dev-python/envisageplugins-3.1.1', '>=dev-python/apptools-3.3.0', '>=dev-python/envisagecore-3.1.1'] RDEPEND.bad 25 sci-visualization/mayavi/mayavi-3.3.0.ebuild: ~amd64(hardened/linux/amd64) ['>=dev-python/envisageplugins-3.1.1', '>=dev-python/apptools-3.3.0', '>=dev-python/envisagecore-3.1.1'] sci-visualization/mayavi/mayavi-3.3.0.ebuild: ~amd64(selinux/2007.0/amd64/hardened) ['>=dev-python/envisageplugins-3.1.1', '>=dev-python/apptools-3.3.0', '>=dev-python/envisagecore-3.1.1'] sci-visualization/mayavi/mayavi-3.3.0.ebuild: ~amd64(selinux/2007.0/amd64) ['>=dev-python/envisageplugins-3.1.1', '>=dev-python/apptools-3.3.0', '>=dev-python/envisagecore-3.1.1'] sci-visualization/mayavi/mayavi-3.3.0.ebuild: ~amd64(hardened/amd64/multilib) ['>=dev-python/envisageplugins-3.1.1', '>=dev-python/apptools-3.3.0', '>=dev-python/envisagecore-3.1.1'] sci-visualization/mayavi/mayavi-3.3.0.ebuild: ~amd64(hardened/amd64) ['>=dev-python/envisageplugins-3.1.1', '>=dev-python/apptools-3.3.0', '>=dev-python/envisagecore-3.1.1'] sci-visualization/mayavi/mayavi-3.3.0.ebuild: ~amd64(default/linux/amd64/10.0/server) ['>=dev-python/envisageplugins-3.1.1', '>=dev-python/apptools-3.3.0', '>=dev-python/envisagecore-3.1.1'] sci-visualization/mayavi/mayavi-3.3.0.ebuild: ~amd64(default/linux/amd64/10.0/developer) ['>=dev-python/envisageplugins-3.1.1', '>=dev-python/apptools-3.3.0', '>=dev-python/envisagecore-3.1.1'] sci-visualization/mayavi/mayavi-3.3.0.ebuild: ~amd64(default/linux/amd64/10.0/desktop) ['>=dev-python/envisageplugins-3.1.1', '>=dev-python/apptools-3.3.0',
[gentoo-dev] repoman complains about a ebuild in the tree
Hello *, I am fixing a bug (#284080) in a ebuild (sci-visualization/mayavi-3.3.0). I have a fix that installs on my box fine, all deps are satisfied. I try to commit it, but repoman issues a lot of errors like RDEPEND.bad 25 sci-visualization/mayavi/mayavi-3.3.0.ebuild: ~x86(default/linux/x86/10.0) ['>=dev-python/envisageplugins-3.1.1', '>=dev-python/apptools-3.3.0', '>=dev-python/envisagecore-3.1.1'] I cannot understand what's bad about these rdepends: the ebuild is "~amd64 ~x86" and all 3 deps are "~amd64 ~x86" too; they are not masked. OK, I want to understand what's happening. So, I copy the existing mayavi-3.3.0.ebuild from the tree and run repoman again. And I get the same error messages! I suppose this means that repoman has changed after mayavi-3.3.0.ebuild was committed (otherwise, how it got to the tree?). And I still don't understand how I can fix the bug. Confused, Andrey
Re: [gentoo-dev] Re: what happened to /etc/init.d/hal{d,daemon,whatever} script ?
On Wed, 24 Dec 2008, Petteri R?ty wrote: Who has been removing die statements? Is this a suggested way of action somewhere by someone? As recently discussed on the list, econf dies by itself, and || die should better be removed after econf. The same is true for, e.g., eqmake4. It was discussed (don't have a reference to the thread at hand) that it would be useful to have a table which shows which functions die by themselves, and which not. Andrey
Re: [gentoo-dev] /usr/share/texmf-site
On Fri, 28 Nov 2008, Ulrich Mueller wrote: We had similar code in app-emacs/auctex, but replaced it by hardcoded TEXMF="/usr/share/texmf-site" about one year ago. Tnanks, I'll do the same in maxima and asymptote. Andrey
[gentoo-dev] /usr/share/texmf-site
Hello *,
Some time ago, some Gentoo TeX guru (don't remember who) advised to
include the following code to the sci-mathematics/maxima ebuild:
# Calculating MAXIMA_TEXMFDIR
if use latex; then
local TEXMFPATH="$(kpsewhich -var-value=TEXMFSITE)"
local TEXMFCONFIGFILE="$(kpsewhich texmf.cnf)"
if [ -z "${TEXMFPATH}" ]; then
eerror "You haven't defined the TEXMFSITE variable in your
TeX config."
eerror "Please do so in the file
${TEXMFCONFIGFILE:-/var/lib/texmf/web2c/texmf.cnf}"
die "Define TEXMFSITE in TeX configuration!"
else
# go through the colon separated list of directories
# (maybe only one) provided in the variable
# TEXMFPATH (generated from TEXMFSITE from TeX's config)
# and choose only the first entry.
# All entries are separated by colons, even when defined
# with semi-colons, kpsewhich changes
# the output to a generic format, so IFS has to be
redefined.
local IFS="${IFS}:"
for strippedpath in ${TEXMFPATH}; do
if [ -d ${strippedpath} ]; then
MAXIMA_TEXMFDIR="${strippedpath}"
break
fi
done
# verify if an existing path was chosen to prevent from
# installing into the wrong directory
if [ -z ${MAXIMA_TEXMFDIR} ]; then
eerror "TEXMFSITE does not contain any existing
directory."
eerror "Please define an existing directory in your
TeX config file"
eerror
"${TEXMFCONFIGFILE:-/var/lib/texmf/web2c/texmf.cnf} or create at least one of the
there specified directories"
die "TEXMFSITE variable did not contain an existing
directory"
fi
fi
fi
It is absolutely clear, and should work for arbitrarily configured TeX.
Later, I copied it (practically verbatim) to the media-gfx/asymptote
ebuild.
With the default Gentoo configuration of either teTeX or TeXlive, this
code always produces
/usr/share/texmf-site
There are a lot of packages which have this path hard-coded:
app-emacs/auctex
app-emacs/bbdb
app-text/passivetex
app-text/xetex
dev-tex/culmus-latex
dev-tex/currvita
dev-tex/dot2texi
dev-tex/envlab
dev-tex/europecv
dev-tex/feynmf
dev-tex/g-brief
dev-tex/glossaries
dev-tex/herm-pic
dev-tex/latex2html
dev-tex/latex-beamer
dev-tex/leaflet
dev-tex/listings
dev-tex/mh
dev-tex/oesch
dev-tex/pgf
dev-tex/svninfo
dev-tex/texmfind
dev-tex/translator
dev-tex/xcolor
dev-tex/xkeyval
dev-tex/xmltex
sci-visualization/gnuplot
So, probably, this code is an unneeded over-generalization, and should be
simply replaced by the hard-coded /usr/share/texmf-site in both maxima and
asymptote. Alternatively, if anybody thinks that this generalization can
be useful (in what case?), we could include this code as a function into
latex-package.eclass, and fix all the ebuilds listed above to use it. The
current inconsistent situation is not good.
I think the first solution is simpler (and I can do it myself). But if
somebody thinks this generalization to the case of an arbitrary TEXMFSITE
in TEXMFCONFIGFILE is useful, then let's do it properly.
Andrey
Re: [gentoo-dev] Remove global USE flag tetex
On Wed, 3 Sep 2008, Christian Faulhammer wrote: there should be no more packages in the tree that have USE=tetex, so this global USE flag can be removed. Any opinions? Great. The following packages still depend on virtual/tetex: [EMAIL PROTECTED]: app-misc/tdl [EMAIL PROTECTED]: app-misc/fdutils [EMAIL PROTECTED]: app-misc/muttprint [EMAIL PROTECTED]: app-misc/chesstask dev-lang/mmix dev-util/ragel [EMAIL PROTECTED]: app-office/eqe app-text/passivetex [EMAIL PROTECTED]: app-office/kletterwizard [EMAIL PROTECTED], [EMAIL PROTECTED]: app-text/kbibtex [EMAIL PROTECTED], [EMAIL PROTECTED]: app-vim/latexsuite [EMAIL PROTECTED]: dev-lisp/cl-mcclim dev-lisp/cl-cgi-utils dev-lisp/cl-tclink dev-lisp/cl-cffi [EMAIL PROTECTED]: dev-perl/Template-Latex [EMAIL PROTECTED]: dev-python/pyx [EMAIL PROTECTED]: dev-tcltk/tkzinc [EMAIL PROTECTED]: dev-tinyos/tos [EMAIL PROTECTED], [EMAIL PROTECTED]: dev-haskell/lhs2tex [EMAIL PROTECTED]: games-board/freedoko [EMAIL PROTECTED], [EMAIL PROTECTED]: net-analyzer/ns [EMAIL PROTECTED]: sci-geosciences/gpsbabel sci-libs/libcore [EMAIL PROTECTED]: sys-block/btrace [EMAIL PROTECTED], [EMAIL PROTECTED]: sys-cluster/mpich2 [EMAIL PROTECTED], [EMAIL PROTECTED]: sys-power/apcupsd [EMAIL PROTECTED], [EMAIL PROTECTED]: sys-power/powersave [EMAIL PROTECTED]: x11-plugins/pidgin-latex Andrey
Re: [gentoo-dev] sci-libs/scipy -> dev-python/scipy ?
On Mon, 7 Jul 2008, Donnie Berkholz wrote: I actually object to having crap in dev-python, because things should be categorized functionally instead of by the language they're implemented in. 90% of the time you don't care about the language. But category moves are pretty much pointless, so I don't normally bring it up. Then this particular case belongs to the other 10% :-) It is not really important for a user if a library is written in C or fortran, because he can call it from his own programs written in any language. But python modules are only useful for somebody who is going to write his own python code and import them. sci-libs/scipi and dev-python/scientificpython are two competing projects which have practically identical aims and descriptions. Do you think this is logical? Andrey -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] sci-libs/scipy -> dev-python/scipy ?
Hello *, Wouldn't it be nice to move scipy from sci-libs to dev-python? All similar and related packages live in dev-python: numeric, scientificpython, matplotlib... I know that moving packages is a major pain in the #$$, but the present situation seems illogical (I would never guess to search for this package in sci-libs if I didn't know it's there). Andrey -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] new virtual/texi2dvi
On Sat, 5 Jul 2008, Ulrich Mueller wrote: sys-apps/texinfo installs scripts texi2dvi, texi2pdf etc. which are not functional because the necessary dependencies on TeX are missing. Therefore aballier and myself propose to introduce a new-style virtual which will pull in the necessary dependencies: - texi2dvi script -> sys-apps/texinfo - working TeX installation -> virtual/latex-base - texinfo.tex -> dev-texlive/texlive-texinfo, or one of the monolithic TeX packages See bug 230473 [1] for more details. If there are no major objections, I'll add the new virtual next week. This is a very good idea. Recently, several ebuilds mentioned in the bug #222501 have replaced the dependence on virtual/tetex by a rather complicated virtual/latex-base || ( dev-texlive/texlive-texinfo app-text/tetex app-text/ptex ) It is much easier and cleaner to have virtual/texinfo here (I hope the maintainers of these ebuilds will find time and energy to edit them once more, and to incorporate virtual/texinfo). Andrey -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Spring clean package.mask, please.
Samuli Suominen wrote: If you have a entry in package.mask for removal, please do so now. If you want treecleaners to handle it, please state so. Already cleaned up quite a bit today, and yeah.. it will surely look bad in GMN ;-) I'd propose to update dev-python/visual to the current beta (beta26) and remove it from package.mask: # Colin Kingsley <[EMAIL PROTECTED]> (24 Jun 2006) # Masked for testing It works fine. The ebuild is in the science overlay (essentially the same as _beta0 in the main tree, with minor cleanups). Andrey -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] LaTeX documentation
Alexis Ballier wrote: > These are (potentially) bombs waiting to blow up an unsuspecting > user. They should be carefully checked. Yeah or maybe they dont need any unusual fonts; its probably sane to set VARTEXFONTS regardless. If LaTeX has been never used on this particular computer (just installed as a dependency), even cmr10 will lead to sandbox violation. Andrey -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] [RFC] global useflags
Jan Kundr?t wrote: I don't see a reference to the "qt3support" flag in any of qtiplot ebuilds, could you please clarify what you mean? I see, this thing has disappeared in recent versions... Sorry. There was a period when qtiplot required qt4 emerged with qt3support USE flag. So, it had pkg_setup which checked this and produced an error it necessary. qt3support was not a USE flag of qtiplot. So, I agree, there seems to be no reasons to make it a global USE flag. Andrey -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] [RFC] global useflags
Jan Kundr?t wrote: Markus Meier wrote: > qt3support: Enable the Qt3Support libraries for Qt4 While it affects a few "packages", they all are parts of the Qt toolkit (which we previously shipped in one big package). I can't see a scenario where this flag might be used on a package not released by Trolltech. sci-visualization/qtiplot, for example Andrey -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] LaTeX documentation
Hello *,
Many packages have documentation in LaTeX, and latex is being run (often
when USE=doc). This may cause a sandbox violation, if a font not yet
generated on this particular computer is encountered: latex calls metafont
to generate it, and metafont wants to write it to /var/cache/fonts (and
its subdirectories). The worst thing is that this bug is unpredictable: if
only commonly-used fonts are encountered, they are already in
/var/cache/fonts, and everything is OK; on some other computer, the same
package can produce a sandbox violation.
There are two methods commonly used to fight against this situation in
ebuilds: using addwrite or setting VARTEXFONTS="${T}/fonts". The second
method is, probably, better. The packages still using addwrite are:
app-doc/doxygen
app-office/kletterwizard
app-text/noweb
dev-lisp/cl-mcclim
dev-python/pyopenssl
dev-tex/feynmf
dev-tex/memoir
media-gfx/asymptote
media-libs/t1lib
media-libs/allegro
sci-chemistry/moldy
sci-mathematics/pari
sci-visualization/pyxplot
Probably, it would be a good idea to change these ebuilds.
The packages using the VARTEXFONTS method are
app-emulation/wine
app-text/jadetex
app-text/linuxdoc-tools
dev-lang/R
dev-tex/listings
dev-tex/texpower
dev-tex/envlab
dev-tex/bibtex2html
dev-tex/xcolor
dev-tex/latex2rtf
dev-tex/mh
media-libs/libcaca
media-libs/libdvdcss
media-libs/aubio
media-libs/libfishsound
sci-mathematics/octave
sci-visualization/gnuplot
Two of them convertex just recently: app-text/jadetex between 3.13-r1 and
3.13-r2, and dev-tex/listings between 1.3 and 1.4. Good for them.
Most disturbingly, there are a number of packages which (probably) run
latex and do neither addwrite nor VARTEXFONTS. An incomplete list of such
suspect packages is (for now, I only considered packages not directly
related to TeX/LaTeX, i.e., not in dev-tex or dev-texlive and not
TeX/LaTeX packages in app-text):
app-backup/bacula
app-emacs/pymacs
app-emacs/slime
app-emulation/xen-tools
app-i18n/canna
app-misc/tdl
app-misc/fdutils
dev-ada/xmlada
dev-ada/asis-gcc
dev-ada/asis-gpl
dev-embedded/avrdude
dev-haskell/lhs2tex (*)
dev-lang/mlton
dev-lang/mmix
dev-libs/beecrypt
dev-libs/libtomcrypt
dev-lisp/gcl
dev-lisp/cl-cffi
dev-lisp/cl-cgi-utils
dev-lisp/cl-iterate/cl-iterate-1.4 (**)
dev-lisp/cl-tclink (***)
dev-lisp/cl-xml-psychiatrist
dev-lisp/clisp
dev-python/python-xlib
dev-python/pyx
dev-tcltk/tkzinc
dev-tinyos/tos
dev-util/bnfc
dev-util/ragel
dev-util/darcs
games-board/freedoko
media-gfx/sane-backends
media-sound/musescore ()
media-video/dirac
net-analyzer/ns
net-analyzer/sonar
net-dialup/mgetty
sci-biology/wise
sci-libs/netcdf
sci-libs/pgplot
sci-mathematics/axiom
sci-mathematics/ginac
sci-mathematics/nusmv
sci-misc/gri
sci-misc/nco
sys-block/btrace
sys-cluster/mpich2
sys-cluster/pvfs2
sys-cluster/charm
sys-power/apcupsd
sys-power/powersave
(*) By the way, here a .pdf file is installed using dodoc, and hence will
be bzip2ed - not a goog idea
(**) but not later versions
(***) The only place where the USE flag "doc" is used commented out???
() USE flag "doc" never used??
These are (potentially) bombs waiting to blow up an unsuspecting user.
They should be carefully checked.
By the way, while investigating this question, I found quite a few
packages which still depend on virtual/tetex, while, probably,
virtual/latex-base would be better (in some of them, the USE flag tetex
then should become latex). Some suspects are:
app-doc/doxygen
app-emacs/slime
app-misc/tdl
app-misc/fdutils
app-misc/muttprint
app-misc/chesstask
app-office/eqe
app-office/texmaker
app-office/grisbi
app-office/kletterwizard
app-text/a2ps
app-text/dvipdfmx
app-text/noweb
app-text/active-dvi
app-text/evince
app-text/pdfjam
app-text/passivetex
app-text/kbibtex
app-vim/latexsuite
dev-ada/asis-gpl
dev-embedded/avrdude
dev-haskell/lhs2tex
dev-lang/mmix
dev-libs/libtomcrypt
dev-lisp/cl-mcclim
dev-lisp/cl-cgi-utils
dev-lisp/cl-iterate
dev-lisp/clisp
dev-lisp/cl-tclink
dev-lisp/cl-cffi
dev-perl/Template-Latex
dev-python/pyx
dev-python/epydoc
dev-tcltk/tkzinc
dev-tinyos/tos
dev-util/bnfc
dev-util/ragel
dev-util/darcs
games-board/freedoko
kde-base/kdvi
kde-base/kopete
media-gfx/asymptote
media-libs/vflib
media-libs/allegro
media-sound/musescore
net-analyzer/ns
net-analyzer/sonar
net-dialup/mgetty
sci-biology/wise
sci-chemistry/moldy
sci-electronics/gnucap
sci-geosciences/gpsbabel
sci-libs/libcore
sci-libs/pgplot
sci-libs/itpp
sci-mathematics/pari
sci-mathematics/nusmv
sci-misc/gri
sci-physics/jaxodraw
sci-physics/paw
sci-physics/cernlib
sci-physics/cernlib-montecarlo
sci-physics/geant
sci-visualization/pyxplot
sys-block/btrace
sys-cluster/mpich2
sys-cluster/charm
sys-power/apcupsd
sys-power/powersave
www-apps/mediawiki
www-servers/boa
x11-plugins/pidgin-latex
(I have not checked in detail, maybe, some of them indeed need tetex).
What do you think?
Andrey
--
gentoo-dev@lists.gentoo.org mailing list
