[gentoo-dev] packages up for grab
Packages I'm no longer interested in: app-text/doconce(needs bump) app-text/getxbook (1 bug) dev-util/diffoscope (needs bump) getxbook seems dead, no new releases after 2015. Andrey
[gentoo-dev] dev-lisp/clozurtecl and the 17.0 profile, was: Re: [gentoo-project] Re: [gentoo-dev-announce] Call for agenda items - Council meeting 2018-12-09
(Moving to gentoo-dev) On Sun, 2 Dec 2018, Michał Górny wrote: I think that if there's one package that doesn't work with profiles (compared to the very large number of packages which just work fine), it's not the profiles but the package being broken (read: doing silly assumptions). Therefore, it's not 17.0 profiles being the problem but the package in question. Claiming that people doing any change to Gentoo are required to fix all the problematic packages is just silly. This is basically saying that it's fine to add bad quality packages and then demand others to fix them for you. People who worked on the profile can fix bugs in the profile. Don't expect them to pursue whatever broken packages you like just because they happened to change the fragile conditions under which they worked. See bug #672454. clozurecl compiles and works fine with the upstream-provided compilation flags. So, we cannot ask the upstream to solve our problems for us. clozurecl compiles and works fine (for me this means that it can compile maxima and fricas, and they work) in the 13.0 profile. In the 17.0 one, its compilation loops forever on ~x86; on ~amd64 it compiles, but does not work properly (cannot compile maxima, bug #665364). So, the reason is in the new compilation or linking flags introduced in 17.0. Is it possible to compile one specific package with compilation/linking flags closely following the 13.0 ones? How? That said, if you insist I'll fix this package. But I'm pretty sure you won't like my fix. If after this fix it will be able to compile maxima and fricas, and they will work, that would be sufficient for me. Andrey
[gentoo-dev] Last rites: sci-mathematics/reduce
# Andrey Grozin (03 Dec 2018) # Masked since 2016. # Removal in 30 days. Bug #671242. =sci-mathematics/reduce-20110414-r1
Re: [gentoo-dev] Packages up for grabs from xmw@g.o
On Sun, 25 Nov 2018, Michał Górny wrote: dev-util/pycharm-community I'll take this one. Andrey
Re: [gentoo-dev] rfc: why are we still distributing the portage tree via rsync?
On Tue, 3 Jul 2018, Matt Turner wrote: On Tue, Jul 3, 2018 at 11:38 AM Rich Freeman wrote: 4. by default git tends to accumulate history, which can eat up disk space. I imagine this could be automatically trimmed if users wanted, though during syncing it would at least need to store all the commits between the last fetched and next-fetched, and that means fetching things that might have been subsequently removed/changed This is why I have not switched to git. I have /usr/portage on a separate 1GB partition (with distfiles and packages stored elsewhere). The ebuild tree is 600MB with rsync and cannot fit on the partition with git. I'd be happy to switch if the space requirements were similar. Same here. One cannot avoid 3 things: death, taxes and insufficient hard-disk space. Andrey
[gentoo-dev] xdg-utils.eclass and EAPI 7
Does anybody plan to add EAPI 7 support to this eclass anytime soon? It must be trivial. There are 857 ebuilds inheriting this eclass in the tree, and they cannot be bumped to EAPI 7 now. Andrey
[gentoo-dev] make boehm-gc USE flag global
There are 4 packages with the USE flag boehm-gc: dev-embedded/sdcc gnustep-base/libobjc2 media-gfx/asymptote net-libs/onion plus 3 packages with the USE flag gc having the same meaning: sci-mathematics/flint sys-apps/nix www-client/elinks I think it would be reasonable to rename the flag gc to boehm-gc in these 3 packages, and make boehm-gc global. The description can be something like Enable garbage collection using dev-libs/boehm-gc Andrey
Re: [gentoo-dev] LINGUAS to be removed from USE_EXPAND
On Thu, 28 Dec 2017, Ulrich Mueller wrote: Last year we had announced introduction of a new L10N variable intended to replace LINGUAS as a USE_EXPAND variable [1]. Since then, many packages have been converted to the new variable. The next step in the conversion will be removal of LINGUAS from USE_EXPAND, which means that LINGUAS will become a normal variable, maintaining the standard gettext behaviour. For a transition time, all linguas_* flags currently existing in packages' IUSE will be added to use.desc, but will be removed again when conversion of the remaining packages is complete. The package sci-mathematics/maxima for ages uses linguas_* flags for installing translated documentation, the possible values of * are de es pt pt_BR This usage is, I suppose, wrong. I tried simply to replace all linguas_ to l10n_ in the ebuild, but repoman complains about pt_BR. What is the correct mechanism to install translated documentation depending on the user's wishes? Andrey
[gentoo-dev] packages up for grab
Packages I'm no longer interested in: media-gfx/fotoxx sci-libs/arprec sci-libs/mathgl sci-libs/qd sci-mathematics/genius sci-mathematics/gsl-shell sci-mathematics/mathmod sci-mathematics/reduce fotoxx is now maintainer-needed. If anybody is interested, welcome. The upstream releases very often, a bump is needed. All the other packages are now maintained by sci or sci-mathematics projects. If anybody is interested, please add yoursels as a maintainer. Maybe, gsl-shell and mathmod can be last-rited if nowbody takes them - I experimented with them a little but did not find them useful. reduce is a very old version, hard-masked, non-working. reduce is a powerful and efficient CAS comparable with maxima. I use it quite often, but I compile new versions by hand, outside portage. The build system is terrible. If somebody could bump it to a modern version (an essential rewrite of the ebuild is needed), it would be excellent. Otherwise, we'll have to remove it :-( One more appeal to the community. wxmaxima is used by many maxima users. I was not its formal maintainer, but in the past I did much work bumping it. The version in the tree is old (though working). The bump is urgently needed. The upstream has switched to cmake, and a nearly complete rewrite of the ebuild is needed. Andrey Grozin
[gentoo-dev] Last rites: dev-python/{dreampie,pydb,pygui}
# Andrey Grozin <gro...@gentoo.org> (15 Dec 2017) # Dead upstream. Removal in 30 days. Use bpython or ptpython instead. dev-python/dreampie # Andrey Grozin <gro...@gentoo.org> (15 Dec 2017) # Dead upstream. Removal in 30 days. dev-python/pydb # Andrey Grozin <gro...@gentoo.org> (15 Dec 2017) # Dead upstream, unclear license. Removal in 30 days. dev-python/pygui
Re: [gentoo-dev] Re: repo/gentoo:master commit in: dev-libs/libunibreak/
On Thu, 14 Dec 2017, Michał Górny wrote: f7329bef1eb169d3363f040cefcc323cfd0a0bc53290a35a395e1d1adc849539 SHA512 43da73f66fabd8fdef444c5a06ad1800464a0aeab590938522d6c19973950a242f2ccc0575a93d10d87bdcf82610452117ac081ddb73f47271a8c2a65897e11c WHIRLPOOL ad71bc5910ca3dff994651022a5a6c6093cd4023852270fa243848f7576287b7cec4ad02a6b27686149491cb52824a93fdb6a6dac4c878d67db2f4041282d300 Those are not correct checksums for a newly added distfile. I have portage-2.3.18 (python-3.6.3) and repoman-2.3.6 (pyblake2-1.1.0 installed). When I do ebuild libunibreak-4.0.ebuild manifest or repoman manifest a Manifest file with SHA256, SHA512 and WHIRLPOOL is generated. What should I change to generate BLAKE2B and SHA512? Andrey
Re: [gentoo-dev] Re: repo/gentoo:master commit in: dev-libs/libunibreak/
On Thu, 14 Dec 2017, Chí-Thanh Christopher Nguyễn wrote: I think you could alternatively have used a pkgmove from liblinebreak to libunibreak, then do the bump. This would break the old liblinebreak-2.1.ebuild which is stable on 3 arches. Andrey
Re: [gentoo-dev] Re: repo/gentoo:master commit in: dev-libs/libunibreak/
If the developers of liblinebreak had not decided to rename their library, I could safely bump it from 2.1 to 4.0, in spite of the fact that it is maintainer-needed, right? Am I personally responsible for their decision to use the new name libunibreak? If there are QA problems in libunibreak-4.0.ebuild, they are surely shared by liblinebreak-2.1.ebuild (which is stable on amd64, ppc and x86, and ~arm). Why these problems were not cought for many years liblinebreak-2.1.ebuild is in the tree? (it is there from before the git migration, git log only shows trivial commits not changing its functionality) Andrey
Re: [gentoo-dev] Re: repo/gentoo:master commit in: dev-libs/libunibreak/
This is in fact a newer version of liblinebreak (under a new name). liblinebreak is m-n. The ebuild is just a slightly improved liblinebreak-2.1. This new version improves the functionality of fbreader (the new revision -r4 depends on libunibreak). Removing libunibreak would require also removing the improved fbreader-0.99.4-r4. libunibreak allows fbreader to correctly hyphenate words in languages other than English (I am now reading a Russian book in this new revision of fbreader, and it is substantially better than doing the same in the previous version). I am definitely against removing libunibreak and fbreader-0.99.4-r4, and returning to the old no-hyphenation-in-non-English-books behaviour. Andrey
Re: [gentoo-dev] Re: gcc-6.x status inquiry
On Wed, 3 May 2017, Ian Stakenvicius wrote: On 03/05/17 01:58 PM, Luca Barbato wrote: As I said few times, we should dump gcc-5 sooner than later and any software that does not build with gcc-6 should be p.masked and dropped from the tree if there isn't a nice fix for it. Just a heads-up, that p.mask list would happen to include firefox and thunderbird right now. And pdftk. It needs gcj, and has no usable alternatives. What should I keep in my system to continue to use (and maybe recompile) pdftk? Andrey
[gentoo-dev] Re: [gentoo-python] Updates from Python team: python.eclass gone, gpyutils updates, incoming PYTHON_SINGLE_TARGET change
Many thanks to the python team for good work. In some cases a package installs some script(s) which run python interpreter. I mean IDE-like packages, e.g., spyder, bpython, ptpython, etc. A user may want to run either python2 or python3 using such IDE. The "standard" behaviour is to install a single script which runs python2 or python3 depending on eselect python. In the case of spyder, there was a user who insisted that he wants to use spyder for python2 *and* python3, without changing the global eselect python setting. I've changed the ebuild to install 3 scripts: spyder (behaves as above), spyder2, and spyder3. The same may be useful for bpython, ptpython, and, maybe, some other packages. Are there plans to make this task easy and systematic, without re-inventing the wheel in each ebuild? Andrey
Re: [gentoo-dev] Packages up for grabs due to retirement
On Mon, 2 Jan 2017, Brian Evans wrote: IMO, this one should be given last-rites as upstream is dead and it heavily depends on wireless-tools and WEXT. I use it on 2 notebooks. It works fine, and is (from my point of view) the most convenient tool to control ethernet and wifi connections on a notebook. Why lastrite it when it works? Andrey
[gentoo-dev] Signature found, but from unknown key (see push-cert)
Happy new year to *, Yesterday I've changed expiration dates of my gpg key and its subkeys. And today I cannot push to Gentoo repo: remote: Signature found, but from unknown key (see push-cert) remote: Your push was not signed with a known key. remote: You MUST use git push --signed with a known key. remote: If you just updated your key, please wait 15 minutes for sync. remote: git-receive-pack variables: remote: GIT_PUSH_CERT='ef16430106a13fa3758d2211100be5b9f2bd88d8' remote: GIT_PUSH_CERT_KEY='' remote: GIT_PUSH_CERT_NONCE='1483268914-e0cd9c07e06304c00a64' remote: GIT_PUSH_CERT_NONCE_SLOP='' remote: GIT_PUSH_CERT_NONCE_STATUS='OK' remote: GIT_PUSH_CERT_SIGNER='' remote: GIT_PUSH_CERT_STATUS='N' remote: A push-cert was found, and follows: remote: = remote: certificate version 0.1 remote: pusher 0x3AFFCE974D34BD8C 1483268914 +0700 remote: pushee git+ssh://git.gentoo.org/repo/gentoo.git remote: nonce 1483268914-e0cd9c07e06304c00a64 remote: remote: 49db3be908c03b9b9346490c9a6ba639a910e32d f6339d7e027335688c7f5906ff63c563ceca9c58 refs/heads/master remote: -BEGIN PGP SIGNATURE- remote: Version: GnuPG v2 remote: remote: iQKTBAABCgB9FiEECMTt9mnFpjD+feuUOv/Ol000vYwFAlho4zJfFIAALgAo remote: aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDA4 remote: QzRFREY2NjlDNUE2MzBGRTdERUI5NDNBRkZDRTk3NEQzNEJEOEMACgkQOv/Ol000 remote: vYzlmQ//euQcx5CtvprpeDD//D/p2csBbxE8YtTdIARtGKXcGzjOFgP7AGWP5VVW remote: A14zJpVDsmm9orVT/3vvZ10OlrWqqoChbrS1fFa2sjK06uhw6cHdW3xFtx+eccnS remote: VgFqOR/OLksWFqYwv0Vz3/vF34QFj84pMcMjgju3rI9/q6rmQ0dbfnJODk5ncrmp remote: zDwRcgQ9BINd58RweKLraep4o+Jp8vthEjgnT5T9U2eqfKniUWCoCKj8rxtfv84s remote: TLboiCRgYu6CaPGlSli+Ro4KQYjS8i/gbyCA0znREydy6u3vQYJP0d4Uv2WwCS3a remote: YPgopzfV1XCmV5R/dfl/HuqVm1IbVBdXmuh/8BPsIlCiZ5x5nWKkdv+aAtOLlc24 remote: SlG9wimv5tJ9p0KB8TY0/HSJuL8mKHD0IJ68WLtMXlyIGQ1dQQBlbwYwvHhrhdY4 remote: 1C6FLAQD/rdAk+uXLBSu/BVWc0gDZWTCmbCBk6wV3Np7Nboiek8D3VxSceJRCLSO remote: Xa5h01tK1mYFlm35KLpZKO5b9T2oRfswxMqWtZYkQmhwFc/k8tXfNGn/2tRqEnXz remote: Qhcay6WgsXC3PnMI3oYR/1hPIo8ZAxR3nfZXoo+jwSUP+Sdxyq07//z+EwsZqs5V remote: 6Pm7bchI0n/J/Ly2mjr2WS7vS+8M5KgavofoJ0iTtDqnthtzsVE= remote: =Yxfy remote: -END PGP SIGNATURE- remote: = To git+ssh://git.gentoo.org/repo/gentoo.git ! [remote rejected] master -> master (pre-receive hook declined) error: failed to push some refs to 'git+ssh://g...@git.gentoo.org/repo/gentoo.git' What should I do to be able to push to Gentoo? Andrey
Re: [gentoo-dev] Gcc 6 and Gcc 5 update
On Sun, 11 Dec 2016, Magnus Granberg wrote: Gcc 6.X update: Gcc 6.3 will soon get released in one or two weeks on that the pie use flag will get unmasked and gcj will be masked for java is removed in gcc 7 I hope gcj will remain in use not very often but regularly). There are no real alternatived: pdfshuffle fails on many (otherwise normal) pdf files. Andrey
Re: [gentoo-dev] gpg: signing failed: Inappropriate ioctl for device
On Sun, 11 Dec 2016, Kristian Fiskerstrand wrote: On 12/11/2016 03:13 PM, gro...@gentoo.org wrote: gpg: signing failed: Inappropriate ioctl for device this might indicate a want for export GPG_TTY=$(tty) I don't understand what has really happened. I removed my last commit, an attempt to commit it again failed with gpg: signing failed. Then I logged out of the box on which I have the git tree (I log in this box via ssh), and logged in again. After that the commit succeeded. Thanks, Andrey
[gentoo-dev] gpg: signing failed: Inappropriate ioctl for device
Hello *, Today, when trying to push my commit to the repo, I got gpg: signing failed: Inappropriate ioctl for device gpg: signing failed: Inappropriate ioctl for device error: gpg failed to sign the data fatal: failed to sign the push certificate fatal: The remote end hung up unexpectedly When I did repoman commit, it did not ask me to type my passphraise, because I did another commit not so long ago (and successfully pushed it to Gentoo). But this commit sits in my copy of the tree, and I cannot push it. What can I do? Thanks in advance, Andrey
Re: [gentoo-dev] Gentoo-specific breakage when building dev-lisp/gcl
On Tue, 1 Nov 2016, Zac Medico wrote: Does FEATURES="-sandbox -usersandox" help? Yes. I've filed the bug #598752 about this problem. Thanks, Andrey
[gentoo-dev] Gentoo-specific breakage when building dev-lisp/gcl
Hello *, For quite some time I cannot build gcl-2.6.12 on my ~amd64 box. The last successful build was on February 17 this year, the first failure on May 4. Nothing changed in gcl-2.6.12.ebuild. Now raw_gcl segfaults when called from make. When I go to /var/tmp/portage/dev-lisp/gcl-2.6.12/work/gcl/unixport/ and run raw_gcl with *exactly the same parameters* from the command line, it succeeds and produces saved_gcl. I've modified unixport/makefile to run raw_gcl under gdb and produce backtrace. This is the result: (gdb) Starting program: /var/tmp/portage/dev-lisp/gcl-2.6.12/work/gcl/unixport/raw_gcl /var/tmp/portage/dev-lisp/gcl-2.6.12/work/gcl/unixport/ -libdir /var/tmp/portage/dev-lisp/gcl-2.6.12/work/gcl/ < foo [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x00367ee0 in calloc () (gdb) #0 0x00367ee0 in calloc () #1 0x7737f687 in ?? () from /lib64/libdl.so.2 #2 0x7737f158 in dlsym () from /lib64/libdl.so.2 #3 0x77bc2fc8 in ?? () from /usr/lib64/libsandbox.so #4 0x77bc1e4e in ?? () from /usr/lib64/libsandbox.so #5 0x77bc802b in ?? () from /usr/lib64/libsandbox.so #6 0x77bc08a7 in ?? () from /usr/lib64/libsandbox.so #7 0x77bc0c98 in ?? () from /usr/lib64/libsandbox.so #8 0x77bc5b9c in open () from /usr/lib64/libsandbox.so #9 0x00312a89 in get_phys_pages_no_malloc () #10 0x00312c08 in update_real_maxpage () #11 0x00365aea in gcl_init_alloc () #12 0x00366ba2 in malloc () #13 0x00367ed0 in calloc () #14 0x7737f687 in ?? () from /lib64/libdl.so.2 #15 0x7737f158 in dlsym () from /lib64/libdl.so.2 #16 0x77bc2fc8 in ?? () from /usr/lib64/libsandbox.so #17 0x77bc1e4e in ?? () from /usr/lib64/libsandbox.so #18 0x77bc802b in ?? () from /usr/lib64/libsandbox.so #19 0x77bc08a7 in ?? () from /usr/lib64/libsandbox.so #20 0x77bbfa26 in ?? () from /usr/lib64/libsandbox.so #21 0x77de82da in ?? () from /lib64/ld-linux-x86-64.so.2 #22 0x77de83eb in ?? () from /lib64/ld-linux-x86-64.so.2 ---Type to continue, or q to quit---Quit The problem is somehow related to the sandbox. As I said, everything was OK on February 17; I suppose sandbox has changed between this date and May 4. FEATURES=-sandbox emerge gcl does not solve the problem. Any hints please? Andrey
Re: [gentoo-dev] The future of the Sunrise project
On Tue, 7 Jun 2016, M. J. Everitt wrote: My concern is for those people using sunrise packages (in whatever broken state) who might suddenly discover they have completly lost access to the overlay 'overnight'. Whilst I'm not expecting the server/repo suddenly to disappear .. there should be a planned migration path for any users lingering on packages in this overlay to get the package into maintainership of some form if at all possible. As such it remains a semi-official Gentoo repository .. One example: I have 1 package installed from sunrise, app-misc/gpspoint. I used it regularly until recently (after buying a good android phone, I use osmand on it instead of my old garmin navigator; but this navigator is still working, and I might want to download some track from it, in which case I'll need gpspoint). OK, I can commit it to the main tree. But I'm sure there are other working packages in sunrise, too. Andrey
[gentoo-dev] ChangeLogs: Digest verification failed
After rsyncing /usr/portage, I get errors like Verifying ebuild manifests !!! Digest verification failed: !!! /usr/portage/dev-libs/libxml2/ChangeLog !!! Reason: Filesize does not match recorded size !!! Got: 5221 !!! Expected: 5038
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-lisp/sbcl/
On Sat, 10 Oct 2015, hasufell wrote: I am a bit confused how this is a bump to "1.2.16". Is just the commit message wrong or what happened here? There was a bump in c473e4fcbe3a17d7bc98d3fa1c19624687774165 afais. And why was BV_X64_MACOS changed? Sorry for the confusion. When I did it, I haven't noticed that 1.2.16 was already committed to the tree. I've just reversed BV_X64_MACOS to the newer version 1.2.11. Sorry, Andrey
Re: [gentoo-dev] Python 3.5 is in, Python 3.3 deprecation
On Sun, 4 Oct 2015, Mike Gilbert wrote: Python 3.5 has been added to ~arch this morning. Please feel free to test and add python3_5 to PYTHON_COMPAT as appropriate. And where's python-docs:3.5? Andrey
[gentoo-dev] how to add a new package with git?
This case is not discussed in https://wiki.gentoo.org/wiki/Gentoo_git_workflow I've added sci-geosciences/qmapshack to my local git tree. But grozin@elrond /home/gentoo/sci-geosciences/qmapshack $ git push --signed origin master Warning: untrusted X11 forwarding setup failed: xauth key data not generated Warning: No xauth data; using fake authentication data for X11 forwarding. X11 forwarding request failed on channel 0 -- WARNING: previous mirror push to host 'ituri.gentoo.org' failed, status is: 2015-09-03.16:57:50 962 ssh: connect to host ituri.gentoo.org port 22: Connection timed out 2015-09-03.16:57:50 962 fatal: Could not read from remote repository. 2015-09-03.16:57:50 962 2015-09-03.16:57:50 962 Please make sure you have the correct access rights 2015-09-03.16:57:50 962 and the repository exists. -- To git+ssh://g...@git.gentoo.org/repo/gentoo.git ! [rejected]master -> master (fetch first) error: failed to push some refs to 'git+ssh://g...@git.gentoo.org/repo/gentoo.git' hint: Updates were rejected because the remote contains work that you do hint: not have locally. This is usually caused by another repository pushing hint: to the same ref. You may want to first integrate the remote changes hint: (e.g., 'git pull ...') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details. grozin@elrond /home/gentoo/sci-geosciences/qmapshack $ git pull --rebase=preserve origin master Warning: untrusted X11 forwarding setup failed: xauth key data not generated Warning: No xauth data; using fake authentication data for X11 forwarding. X11 forwarding request failed on channel 0 -- WARNING: previous mirror push to host 'ituri.gentoo.org' failed, status is: 2015-09-03.16:57:50 962 ssh: connect to host ituri.gentoo.org port 22: Connection timed out 2015-09-03.16:57:50 962 fatal: Could not read from remote repository. 2015-09-03.16:57:50 962 2015-09-03.16:57:50 962 Please make sure you have the correct access rights 2015-09-03.16:57:50 962 and the repository exists. -- remote: Counting objects: 6, done. remote: Compressing objects: 100% (6/6), done. remote: Total 6 (delta 4), reused 0 (delta 0) Unpacking objects: 100% (6/6), done. From git+ssh://git.gentoo.org/repo/gentoo * branchmaster -> FETCH_HEAD 2ac41e1..ed56295 master -> origin/master Successfully rebased and updated refs/heads/master. grozin@elrond /home/gentoo/sci-geosciences/qmapshack $ git push --signed origin master fatal: Unable to read current working directory: No such file or directory So, where am I? grozin@elrond /home/gentoo/sci-geosciences/qmapshack $ pwd /home/gentoo/sci-geosciences/qmapshack grozin@elrond /home/gentoo/sci-geosciences/qmapshack $ ls No files here?? grozin@elrond /home/gentoo/sci-geosciences/qmapshack $ cd .. grozin@elrond /home/gentoo/sci-geosciences $ ls bt747/ gpsd/mapnik-world-boundaries/ opencpn-plugin-ocpndebugger/ qmapshack/ cdat-lite/ gpx-viewer/ mapserver/ opencpn-plugin-statusbar/readosm/ congen/gpxpy/ mc2bsbh/ opencpn-plugin-weather_routing/ seawater/ foxtrotgps/grass/ merkaartor/ opencpn-plugin-weatherfax/ swmm/ gdal-grass/gshhs/ metadata.xml opencpn-plugin-wmm/ tappy/ gebabbel/ gshhs-data/ mkgmap/ osgearth/tcd-utils/ geocode-glib/ gtk-g-rays2/ mtkbabel/ osm-gps-map/ tilecache/ gmapcatcher/ harmonics-dwf-free/ opencpn/ osm2mp/ viking/ gmt/ harmonics-dwf-free-noncomm/ opencpn-plugin-br24radar/ osm2pgsql/ xtide/ gnome-maps/josm/opencpn-plugin-climatology/ osmosis/ googleearth/ josm-plugins/opencpn-plugin-launcher/ qgis/ gpsbabel/ libtcd/ opencpn-plugin-logbookkonni/ qlandkartegt/ gpscorrelate/ mapnik/ opencpn-plugin-objsearch/ qlandkartegt-garmindev/ grozin@elrond /home/gentoo/sci-geosciences $ cd qmapshack/ grozin@elrond /home/gentoo/sci-geosciences/qmapshack $ ls Manifest metadata.xml qmapshack-1.3.0.ebuild Files are still here. Now if I again try git push --signed origin master, the whole story repeats exactly. I cannot find a way to push this new package to origin. Any help please? Andrey
Re: [gentoo-dev] how to add a new package with git?
On Thu, 3 Sep 2015, James Le Cuirot wrote: It will probably work if you just cd to the parent directory before you pull or push. Thanks, this have worked. Andrey
[gentoo-dev] git.gentoo.org: Could not read from remote repository
I'm trying to follow https://wiki.gentoo.org/wiki/Gentoo_git_workflow: grozin@elrond ~ $ git clone --depth=50 git+ssh://g...@git.gentoo.org/repo/gentoo.git Cloning into 'gentoo'... Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. What am I doing wrong? Andrey
[gentoo-dev] Should this be considered a gcc bug?
Hello *,
There was a bug #526194 - dev-lisp/sbcl does not respect CFLAGS. It was
fixed by Mark Wright gie...@gentoo.org on Jan 31 - Feb 1. However,
after this fix the upstream CFLAGS were appended to the user-supplyed
${CFLAGS}. And the upstream CFLAGS contain -O3. So, is a user has, e.g.,
-O2 in his/her ${CFLAGS}, it was silently replaced by -O3. For some time,
nobody noticed this: gcc-4.8 happily compiled the C stuff in sbcl with
-O3.
However, after the upgrade to gcc-4.9 problems began (bug #544070). On
amd64, gcc is still happy co compile sbcl with -O3. However, on x86 this
leads to a crash of a freshly compiled sbcl runtime. Namely, the
combinations
-O2 -march=something
-O3
behave correctly, and produce a working sbcl; but
-O3 -march=something
lead to the crush. I have changed the above fix in sbcl-1.2.10 in such a
way that now it appends only -g -Wall -Wsign-compare to ${CFLAGS}, but
not -O3. This resolves the bug #544070, unless a user has -O3
-march=something in his/her ${CFLAGS}.
Shouldn't gcc-4.9 on x86 produce with -O3 something functionally
equivalent to the -O2 case, only more optimized? Should this be considered
a gcc-4.9 bug?
Andrey
[gentoo-dev] why is a line in /usr/portage/profiles/base/package.use.mask ignored?
Hello *, dev-lisp/ecls-15.2.21 does not compiled with USE=cpu_flags_x86_sse. So, I've added the line =dev-lisp/ecls-15.2.21 cpu_flags_x86_sse to .../profiles/base/package.use.mask. But I still see dns ~ # emerge -pv dev-lisp/ecls [ebuild R] dev-lisp/ecls-15.2.21:0/15.2.21::gentoo [15.2.21:0/15.2.21::grozin] USE=X emacs libatomic%* threads unicode -debug -gengc -precisegc CPU_FLAGS_X86=sse* 0 KiB Why isn't sse masked? Andrey
Re: [gentoo-dev] Packages up for grabs
On Mon, 24 Nov 2014, hasufell wrote: net-misc/dropbox-cli I use it every day, works fine. No bugs. I take it. I'd like to add a bash-completion file for dropbox-cli. Andrey
Re: [gentoo-dev] packages masked for removal in 30 days
On Fri, 23 May 2014, Rick Zero_Chaos Farina wrote: s/worthy of/required to cc/ Additionally, why mask and remove instead of just doing a pkgmove? I've sent this to gentoo-dev-annou...@lists.gentoo.org, but it never appeared. I'm subscribed to gentoo-dev-announce; don't know what's the matter. Andrey # Andrey Grozin gro...@gentoo.org (23 May 2014) # Google closed free usage of the translate api # Masked for removal in 30 days app-text/qgoogletranslator # openmcl has been renamed to clozurecl # Masked for removal in 30 days dev-lisp/openmcl dev-lisp/openmcl-build-tools The hopelessly outdated openmcl in the tree is ~ppc; clozurecl in the tree is ~amd64 ~x86. There is a bug #506890 requesting ~ppc and ~ppc64 keywords for clozurecl; no replies so far. If any ppc user wants clozurecl, please ping #506890. Andrey
[gentoo-dev] packages masked for removal in 30 days
# Google closed free usage of the translate api # Masked for removal in 30 days app-text/qgoogletranslator # openmcl has been renamed to clozurecl # Masked for removal in 30 days dev-lisp/openmcl dev-lisp/openmcl-build-tools Andrey Grozin
Re: [gentoo-dev] Packages up for grabs
On Mon, 14 Apr 2014, Alexey Shvetsov wrote: There are a list of packages up for grabs. I cannnot test anymore some of them, or i stopped use them. app-text/fbreader I use it very often. I'll take it. Andrey
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Fri, 17 Jan 2014, Tom Wijsman wrote: On Fri, 17 Jan 2014 16:31:54 +0100 Ulrich Mueller u...@gentoo.org wrote: On Fri, 17 Jan 2014, grozin wrote: Maybe, a good solution is to introduce a special arch, noarch, for such packages (similar to what's done in the rpm world). Then, if a package is ~noarch, it is automatically considered ~arch for all arches. Similar for stable. The maintainer should be able to keyword ~noarch and to stabilize noarch. Comments? How would you handle dependencies in such a scenario? All dependencies must be keyworded or stable on all architectures, before the package can be keyworded or stabilised on noarch? Maybe we can let the package managers only perceive it as keyworded or stable if all of its dependencies are keyworded or stable on the architecture that the user runs. Then we can have repoman just ignore checking dependencies' keywords when we keyword or stabilize them. Very reasonable. Andrey
noarch packages, was Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Fri, 17 Jan 2014, Ulrich Mueller wrote: On Fri, 17 Jan 2014, grozin wrote: Maybe, a good solution is to introduce a special arch, noarch, for such packages (similar to what's done in the rpm world). Then, if a package is ~noarch, it is automatically considered ~arch for all arches. Similar for stable. The maintainer should be able to keyword ~noarch and to stabilize noarch. Comments? How would you handle dependencies in such a scenario? All dependencies must be keyworded or stable on all architectures, before the package can be keyworded or stabilised on noarch? Many pure data packages don't depend on anything. Pure TeX/LaTeX packages should be keyworded ~noarch only if a suitable binary TeX is keyworded for each arch. Hmm, this, probably, means that they can never be stabilized as noarch. Pure python scripts (without library dependencies) should become ~noarch if some suitable python binary is keyworded for each arch. Similarly for perl, ruby. Python is installed on each Gentoo box anyway, so, in this case it is less problematic. Andrey
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Thu, 16 Jan 2014, Sergey Popov wrote: 3. Also, another interesting question has come up in this thread, that of non-binary packages. Should we give maintainers the option of stabilizing them on all arch's themselves? 3. If code is interpreted rather then compiled, it does not matter that it is properly ported on minor arches. I knew dozens of examples with Perl and Python packages(not sure about Ruby, but Hans said that it happens with it too). So, i would not treat such packages differently. OK, let's be conservative. Python and Perl scripts may break on some arches (I'd say it's a rare exception, perhaps 1%, but still). But what about dev-java/java-sdk-docs dev-db/postgresql-docs sys-kernel/linux-docs dev-dotnet/gtk-sharp-docs app-xemacs/general-docs dev-util/kdevelop-php-docs dev-util/gnome-devel-docs app-vim/phpdocs gnome-extra/gnome-user-docs gnome-extra/gnome-getting-started-docs dev-php/smarty-docs dev-python/python-docs dev-python/cheetah-docs app-doc/php-docs app-doc/root-docs app-doc/geant-docs app-doc/blas-docs app-doc/lapack-docs app-doc/gnucash-docs app-office/abiword-docs dev-lisp/hyperspec sys-apps/man-pages[-*] and maybe others? They contain no scripts which can possibly break. I'd say they should be keyworded on all arches as soon as they are keyworded on the first arch; the same goes for stabilization. I'd include also packages containing only TeX/LaTeX code - TeX behaves identically on all arches, this was and is its main strength. Also, probably, python/perl/ruby interpreted scripts *which don't load extra libraries* work identically on all arches not in 99% of cases but in 99.99% (0.01% is for cases when the interpreter is broken on a given arch). Andrey
Re: [gentoo-dev] rfc: revisiting our stabilization policy
Sorry for following up myself, On Fri, 17 Jan 2014, gro...@gentoo.org wrote: OK, let's be conservative. Python and Perl scripts may break on some arches (I'd say it's a rare exception, perhaps 1%, but still). But what about dev-java/java-sdk-docs dev-db/postgresql-docs sys-kernel/linux-docs dev-dotnet/gtk-sharp-docs app-xemacs/general-docs dev-util/kdevelop-php-docs dev-util/gnome-devel-docs app-vim/phpdocs gnome-extra/gnome-user-docs gnome-extra/gnome-getting-started-docs dev-php/smarty-docs dev-python/python-docs dev-python/cheetah-docs app-doc/php-docs app-doc/root-docs app-doc/geant-docs app-doc/blas-docs app-doc/lapack-docs app-doc/gnucash-docs app-office/abiword-docs dev-lisp/hyperspec sys-apps/man-pages[-*] and maybe others? They contain no scripts which can possibly break. I'd say they should be keyworded on all arches as soon as they are keyworded on the first arch; the same goes for stabilization. I'd include also packages containing only TeX/LaTeX code - TeX behaves identically on all arches, this was and is its main strength. Also, probably, python/perl/ruby interpreted scripts *which don't load extra libraries* work identically on all arches not in 99% of cases but in 99.99% (0.01% is for cases when the interpreter is broken on a given arch). Maybe, a good solution is to introduce a special arch, noarch, for such packages (similar to what's done in the rpm world). Then, if a package is ~noarch, it is automatically considered ~arch for all arches. Similar for stable. The maintainer should be able to keyword ~noarch and to stabilize noarch. Comments? Andrey
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Tue, 14 Jan 2014, William Hubbs wrote: 1. I think maintainers should be able to stabilize their packages on arch's they have access to. I think this is allowed by some arch teams, but I think it would be good to formalize it. +1 Also, there is a substantial number of packages which contain only python code (or perl, ruby), or only LaTeX classes, or only documentation. It makes no sense to test them on each arch separately. I think maintainers should be allowed to stabilize such packages (with no compiled code) on all arches. Andrey
Re: [gentoo-dev] RFC: Gentoo GPG key policies
Sorry to bother you again, but I still cannot do signed commits. I don't
know what else to try.
On Thu, 14 Mar 2013, Robin H. Johnson wrote:
On Thu, Mar 14, 2013 at 10:50:00AM +0700, gro...@gentoo.org wrote:
But my first attempt to do a signed commit has failed:
Your GPG agent is broken/missing.
These are steps I have done:
elrond ~ # eselect pinentry list
Available pinentry binary implementations:
[1] pinentry-gtk-2
[2] pinentry-qt4 *
[3] pinentry-curses
In /etc/kde/startup/agent-startup.sh:
if [ -x /usr/bin/gpg-agent ]; then
eval $(/usr/bin/gpg-agent --daemon)
fi
In /etc/kde/shutdown/agent-shutdown.sh:
if [ -n ${GPG_AGENT_INFO} ]; then
kill $(echo ${GPG_AGENT_INFO} | cut -d':' -f 2) /dev/null 21
fi
grozin@elrond ~/.gnupg $ cat gpg-agent.conf
pinentry-program /usr/bin/pinentry-qt4
no-grab
default-cache-ttl 10
In ~/.gnupg/gpg.conf:
use-agent
Then I exited a kde session, and said startx again. Now
grozin@elrond ~ $ echo ${GPG_AGENT_INFO}
/tmp/gpg-oJuN4k/S.gpg-agent:14103:1
Looks like gpg-agent is running. Now an attempt to commit:
grozin@elrond /home/gentoo-x86/media-gfx/fotoxx $ repoman commit -m 'Fix
linking with gold (bug #462286), thanks to adrian.bass...@hotmail.co.uk'
RepoMan scours the neighborhood...
Creating Manifest for /home/gentoo-x86/media-gfx/fotoxx
Note: use --include-dev (-d) to check dependencies for 'dev' profiles
* 2 files being committed... 1 have headers that will change.
* Files with headers will cause the manifests to be changed and committed
separately.
Using commit message:
--
Fix linking with gold (bug #462286), thanks to
adrian.bass...@hotmail.co.uk
(Portage version: 2.2.0_alpha169/cvs/Linux i686, signed Manifest commit
with key 00C6DAB1!)
--
Warning: untrusted X11 forwarding setup failed: xauth key data not
generated
Warning: No xauth data; using fake authentication data for X11 forwarding.
X11 forwarding request failed on channel 0
/var/cvsroot/gentoo-x86/media-gfx/fotoxx/ChangeLog,v -- ChangeLog
new revision: 1.49; previous revision: 1.48
/var/cvsroot/gentoo-x86/media-gfx/fotoxx/files/fotoxx-13.03.patch,v --
files/fotoxx-13.03.patch
new revision: 1.2; previous revision: 1.1
Creating Manifest for /home/gentoo-x86/media-gfx/fotoxx
gpg: no default secret key: No secret key
gpg: /home/gentoo-x86/media-gfx/fotoxx/Manifest: clearsign failed: No
secret key
!!! !!! gpg exited with '2' status
!!! Disabled FEATURES='sign'
Warning: untrusted X11 forwarding setup failed: xauth key data not
generated
Warning: No xauth data; using fake authentication data for X11 forwarding.
X11 forwarding request failed on channel 0
/var/cvsroot/gentoo-x86/media-gfx/fotoxx/Manifest,v -- Manifest
new revision: 1.50; previous revision: 1.49
Commit complete.
RepoMan sez: If everyone were like you, I'd be out of business!
grozin@elrond /home/gentoo-x86/media-gfx/fotoxx $
My understanding was that I'll be asked for the pass phrase. But this does
not happen. And I don't know what else I have to configure.
Desperate,
Andrey
Re: [gentoo-dev] RFC: Gentoo GPG key policies
On Fri, 22 Mar 2013, Panagiotis Christopoulos wrote: I'm not sure if it's related, but have you set PORTAGE_GPG_DIR and/or PORTAGE_GPG_KEY in your make.conf? Sure: PORTAGE_GPG_DIR=/home/grozin/.gnupg PORTAGE_GPG_KEY=00C6DAB1! Even if I'll be able to configer gpg-agent properly, this will solve only a small part of the problem. I always do commits from elrond.inp.nsk.su, it is in my office at Budker Institute of Nuclear Physics. When I'm in my office, I'm logged in, and there's kde session. gpg-agent should ask for my pass phrase, and things should work. OK. When I'm at home, I log in elrond via ssh. As a rule, there's still a kde session at the console (why should I start emacs, firefox, etc., again next morning?). Hence there's gpg-agent running. As far as I can understand, it will ask for my pass phrase on the switched off monitor in my locked office. Not very useful. When I'm somewhere else (in Karlsruhe, for example), elrond is always switched on, but there is no session on the console. I log in via ssh. There is no gpg-agent running. How do I commit stuff? Thanks in advance, Andrey
Re: [gentoo-dev] RFC: Gentoo GPG key policies
Hello *, I've followed all the instructions successfully (I think). By the way, the following lines need a small correction: perl_ldap -b user -M gpgkey gpg-id user perl_ldap -b user -M gpgfingerprint gpg-fingerprint user perl_ldap says that attributes of type multiple cannot be modified. I had to delete these attributes and then create the new ones. But my first attempt to do a signed commit has failed: Using commit message: -- Version bump (Portage version: 2.2.0_alpha166/cvs/Linux i686, signed Manifest commit with key 00C6DAB1!) -- Warning: untrusted X11 forwarding setup failed: xauth key data not generated Warning: No xauth data; using fake authentication data for X11 forwarding. X11 forwarding request failed on channel 0 /var/cvsroot/gentoo-x86/dev-lisp/clozurecl/ChangeLog,v -- ChangeLog new revision: 1.9; previous revision: 1.8 /var/cvsroot/gentoo-x86/dev-lisp/clozurecl/clozurecl-1.9.ebuild,v -- clozurecl-1.9.ebuild initial revision: 1.1 /var/cvsroot/gentoo-x86/dev-lisp/clozurecl/clozurecl-1.7.ebuild,v -- clozurecl-1.7.ebuild new revision: delete; previous revision: 1.3 Creating Manifest for /home/gentoo-x86/dev-lisp/clozurecl gpg: no default secret key: No secret key gpg: /home/gentoo-x86/dev-lisp/clozurecl/Manifest: clearsign failed: No secret key !!! !!! gpg exited with '2' status !!! Disabled FEATURES='sign' Warning: untrusted X11 forwarding setup failed: xauth key data not generated Warning: No xauth data; using fake authentication data for X11 forwarding. X11 forwarding request failed on channel 0 /var/cvsroot/gentoo-x86/dev-lisp/clozurecl/Manifest,v -- Manifest new revision: 1.10; previous revision: 1.9 Commit complete. RepoMan sez: If everyone were like you, I'd be out of business! What else should I do? Andrey
Re: [gentoo-dev] RFC: Gentoo GPG key policies
Hello *, I am stuck and have many questions. [In the process of becoming a dev, I've generated a gpg key, of course. It vwas on an old notebook. When I switched to a newer notebook, I forgot to copy it, because I don't use gpg regularly. No risk that it became known - the disk was re-partitioned and re-formatted. Probably, that key has expired anyway.] 1. So, I start gpg --gen-key It creates ~/.gnupg/ and some files in it. Should I press ctrl-C, then edit ~/.gnupg/gpg.conf, and then re-start gpg --gen-key? Or editing gpg.conf can be done later? 2. Then I choose 1, 3y, y, then my name and the @gentoo.org email address. After that, gpg --list-keys says /home/username/.gnupg/pubring.gpg --- pub 4096R/0x16_hex_digits_1 2013-02-26 [expires: 2016-02-26] uid [ultimate] my_name my_gentoo_email_address sub 4096R/0x16_hex_digits_2 2013-02-26 [expires: 2016-02-26] So, my key id is 0x16_hex_digits_1, right? 3. Now I do gpg --edit-key 0x16_hex_digits_1 addkey Then I choose (4) RSA (sign only) right? Then I choose 4096, 1y, y, y, save. Now gpg --list-keys gives /home/username/.gnupg/pubring.gpg --- pub 4096R/0x16_hex_digits_1 2013-02-26 [expires: 2016-02-26] uid [ultimate] my_name my_gentoo_email_address sub 4096R/0x16_hex_digits_2 2013-02-26 [expires: 2016-02-26] sub 4096R/0x16_hex_digits_3 2013-02-26 [expires: 2014-02-26] 4. I do gpg --output revoke.asc --gen-revoke 0x16_hex_digits_1 and choose 1. 6. Encrypted backup of your secret keys. I don't understand this. 7. In your gpg.conf: # include an unambiguous indicator of which key made a signature: # (see http://thread.gmane.org/gmane.mail.notmuch.general/3721/focus=7234) sig-notation issuer-...@notations.openpgp.fifthhorseman.net=%g I don't understand this. 5. I do gpg --keyserver subkeys.pgp.net --send-key 0x16_hex_digits_1 6. On dev.gentoo.org, I am supposed to do perl_ldap -b user -M gpgkey gpg-id user perl_ldap -b user -M gpgfingerprint gpg-fingerprint user Is gpg-id 0x16_hex_digits_1? Or 0x16_hex_digits_3? What is gpg-fingerprint and how do I get it? Is user my username on dev.gentoo.org? What's even more important, perl_ldap asks my ldap password. I suppose I haven't got one. My usual Gentoo password (used in bugzilla, forums) does not work. How do I get an ldap password? 7. If I'll ever complete all the above, I'll add sign to FEATURES in /etc/portage/make.conf, and PORTAGE_GPG_DIR=/home/username/.gnupg and also PORTAGE_GPG_KEY=0x16_hex_digits_3! Is this correct? Is it 16_hex_digits_3, and not, say, 16_hex_digits_1? Should I add ! at the end, as suggested by mgorny? During the time I'm reading all these instructions, I could bump 10 packages. Very complicated for a person who does not use gpg and knows next to nothing about it. Andrey Grozin
[gentoo-dev] Re: [gentoo-dev-announce] Last rites: app-text/epdfview
On Tue, 7 Aug 2012, Andreas K. Huettel wrote: # Andreas K. Huettel dilfri...@gentoo.org (7 Aug 2012) # Many display bugs and compatibility problems, does not build with cups-1.6. # Upstream is dead. There's no real way to support this anymore. Masked for # removal in 30 days. Unfortunately the best lightweight replacement I can # recommend is app-text/apvlv, otherwise you can go for app-text/acroread # (huge, closed source), kde-base/okular (KDE), or app-text/evince (Gnome). app-text/epdfview app-text/qpdfview is not bad (though I prefer okular). Andrey
Re: [gentoo-dev] Packages up for grabs due loki_val retirement
On Thu, 24 Nov 2011, Pacho Ramos wrote: app-text/pdfshuffler I'll take this one 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 nirbh...@gentoo.org 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
[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] repoman complains about a ebuild in the tree
Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org 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', '=dev-python/envisagecore-3.1.1']
[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] /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
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
[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] 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
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
[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
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
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
