[gentoo-dev] packages up for grab

2020-02-28 Thread grozin

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

2018-12-03 Thread grozin

(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

2018-12-03 Thread grozin

# 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

2018-11-25 Thread grozin

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?

2018-07-03 Thread grozin

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

2018-06-14 Thread grozin
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

2018-03-20 Thread grozin

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

2017-12-30 Thread grozin

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

2017-12-15 Thread grozin

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}

2017-12-15 Thread grozin

# 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/

2017-12-14 Thread grozin

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/

2017-12-14 Thread grozin

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/

2017-12-14 Thread grozin
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/

2017-12-14 Thread grozin
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

2017-05-04 Thread grozin

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

2017-04-20 Thread grozin

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

2017-01-03 Thread grozin

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)

2017-01-01 Thread grozin

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

2016-12-11 Thread grozin

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

2016-12-11 Thread grozin

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

2016-12-11 Thread grozin

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

2016-11-02 Thread grozin

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

2016-11-01 Thread grozin

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

2016-06-07 Thread grozin

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

2015-11-12 Thread grozin

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/

2015-10-12 Thread grozin

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

2015-10-05 Thread grozin

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?

2015-09-03 Thread grozin
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?

2015-09-03 Thread grozin

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

2015-08-12 Thread grozin

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?

2015-04-20 Thread grozin

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?

2015-02-25 Thread grozin

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

2014-11-24 Thread grozin

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

2014-05-24 Thread grozin

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

2014-05-23 Thread grozin

# 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

2014-04-14 Thread grozin

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

2014-01-17 Thread grozin

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

2014-01-17 Thread grozin

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

2014-01-16 Thread grozin

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

2014-01-16 Thread grozin

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

2014-01-14 Thread grozin

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

2013-03-22 Thread grozin
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

2013-03-22 Thread grozin

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

2013-03-13 Thread grozin

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

2013-02-26 Thread grozin

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

2012-08-07 Thread grozin

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

2011-11-24 Thread grozin

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?

2009-09-26 Thread Andrey Grozin

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?

2009-09-25 Thread Andrey Grozin
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

2009-09-14 Thread Andrey Grozin

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

2009-09-13 Thread Andrey Grozin

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

2009-09-13 Thread Andrey Grozin

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

2008-11-27 Thread Andrey Grozin

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

2008-11-27 Thread Andrey Grozin

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

2008-09-02 Thread Andrey Grozin

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 ?

2008-07-07 Thread Andrey Grozin

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 ?

2008-07-07 Thread Andrey Grozin

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

2008-07-06 Thread Andrey Grozin

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.

2008-05-15 Thread Andrey Grozin

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

2008-05-13 Thread Andrey Grozin

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

2008-05-12 Thread Andrey Grozin

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

2008-05-12 Thread Andrey Grozin

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

2008-05-12 Thread Andrey Grozin

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