[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-admin/supervisor: ChangeLog supervisor-3.0_alpha9.ebuild
В Чтв, 23/09/2010 в 20:18 +, Arfrever Frehtes Taifersar Arahesis
(arfrever) пишет:
src_install() {
distutils_src_install
newinitd ${FILESDIR}/init.d supervisord
newconfd ${FILESDIR}/conf.d supervisord
|| die is necessary after newinitd/newconfd. This will prevent broken
package to be installed in case $FILESDIR/{init.d,conf.d} miss in users
portage tree.
--
Peter.
Re: [gentoo-dev] Lastrite: dev-tex/achemso
On Friday 01 October 2010 08:53:11 Thilo Bangert wrote: Andreas K. Huettel dilfri...@gentoo.org said: TexLive 2009 already contains achemso-3.0, and we have a separate ebuild for 1.0 ... I am probably missing somthing, but texlive-2009 is not stable yet, is it? True, and yes, I missed that point - it's not in stable 2008 yet and should not have been masked. Whether reverting the mask makes sense, that's something I'd like to debate. Each current document that I tried did not even compile with the old achemso version... Best, A -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/sympy/files: sympy-0.6.7-python-2.7.patch
В Птн, 24/09/2010 в 20:09 +, Arfrever Frehtes Taifersar Arahesis (arfrever) пишет: Added:sympy-0.6.7-python-2.7.patch Log: Fix majority of test failures with Python 2.7 (bug #330713). This patch fixes not test failure, but sympy's ability to work with python-2.7. Although python-2.7 is currently masked it will be unmasked soon and some users may have it installed already. Looks like revision bump to propagate this change in package on users is necessary in this case. Please, bump revision. Revision ChangesPath 1.1 dev-python/sympy/files/sympy-0.6.7-python-2.7.patch file : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/dev-python/sympy/files/sympy-0.6.7-python-2.7.patch?rev=1.1view=markup plain: http://sources.gentoo.org/viewvc.cgi/gentoo-x86/dev-python/sympy/files/sympy-0.6.7-python-2.7.patch?rev=1.1content-type=text/plain Index: sympy-0.6.7-python-2.7.patch === http://github.com/sympy/sympy/commit/717516b8ffae806cdfdea8141ceb839107d92431 --- sympy/printing/pretty/stringpict.py +++ sympy/printing/pretty/stringpict.py @@ -81,7 +81,7 @@ return '\n'.join(result), newBaseline def right(self, *args): -Put pictures next to this one. +rPut pictures next to this one. Returns string, baseline arguments for stringPict. (Multiline) strings are allowed, and are given a baseline of 0. from sympy.printing.pretty.stringpict import stringPict --- sympy/utilities/runtests.py +++ sympy/utilities/runtests.py @@ -778,7 +778,7 @@ def start(self): self.write_center(test process starts) executable = sys.executable -v = sys.version_info +v = tuple(sys.version_info) python_version = %s.%s.%s-%s-%s % v self.write(executable: %s (%s)\n\n % (executable, python_version)) self._t_start = clock() -- Peter.
[gentoo-dev] QA last rites for app-i18n/fcitx
# Diego E. Pettenò flamee...@gentoo.org (01 Oct 2010) # on behalf of QA team # # Overflows during build (bug #301795); need a new maintainer # at least, but there are a number of alternative IMEs that # shouldn't have these problems. # # Removal on 2010-11-30 app-i18n/fcitx
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/sympy/files: sympy-0.6.7-python-2.7.patch
Il giorno ven, 01/10/2010 alle 12.30 +0400, Peter Volkov ha scritto: This patch fixes not test failure, but sympy's ability to work with python-2.7. Although python-2.7 is currently masked it will be unmasked soon and some users may have it installed already. Looks like revision bump to propagate this change in package on users is necessary in this case. Please, bump revision. You still need to run python-updated (oh joy) so it probably isn't strictly required. -- Diego Elio Pettenò — “Flameeyes” http://blog.flameeyes.eu/ If you found a .asc file in this mail and know not what it is, it's a GnuPG digital signature: http://www.gnupg.org/
[gentoo-dev] .la files removal news item (GLEP 42)
Hi lads,
due to recent situation about .la files status we would like to inform
users about this situation. See attached file that we propose to be
included as news item.
Step 2 will be finding global policy how to get rid of them as fast as
possible without too much more hassle for our users :)
Tomáš Chvátal
Gentoo Linux Developer [Clustering/Council/KDE/QA/Sci/X11]
E-Mail : scarab...@gentoo.org
GnuPG FP: 94A4 5CCD 85D3 DE24 FE99 F924 1C1E 9CDE 0341 4587
GnuPG ID: 03414587
Title: Removal of .la files
Author: Diego Elio Pettenò flamee...@gentoo.org
Content-Type: text/plain
Posted: 2010-10-01
Revision: 1
News-Item-Format: 1.0
Some of you might have noticed, others might notice, a few would
probably not notice at all, that some Gentoo developers have started
removing the libtool archive files from packages that they maintain;
these changes have some times been applied to stable ebuilds as well,
but in all cases they won't be applied unless the package is re-emerged.
Removing .la files can cause, though, temporary disruption in the build
processes of libraries depending on those involved, because of the
transitive nature of .la files. For instance you could experiences
something like this:
libtool: link: `/usr/lib/libdbus-1.la' is not a valid libtool archive
with libdbus-1.la being replaced by other library names. If this is the
case, _do not panic_! Nothing is irremediably broken and nothing will
have to be rebuilt!
First of all, you should install lafilefixer and let it pass through the
currently-installed system:
# emerge lafilefixer
# lafilefixer --justfixit
This will convert the references to libtool archives to the -llibname
form, which works both with and without them.
Secondly, you can avoid any future requirement for this by sanitising
the newly installed .la files; this can be done either by using the
(currently testing) Portage 2.1.9 series, or by adding the following
snippet to your /etc/portage/bashrc:
post_src_install() {
lafilefixer ${D}
}
It's a one time process that _will_ save you from more breakage and work
to do in the future, so please bear with us.
We'll be looking forward to make this more widely available knowledge
and we hope to be able to provide a better experience for all of you at
the end of this (bumpy) journey.
For more informations please see post [1] to gentoo-user mailing list
that contain more detailed description.
[1]
http://archives.gentoo.org/gentoo-user/msg_b144a138af822433344f6064e2fa9c66.xml
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-libs/libproxy: ChangeLog libproxy-0.4.6.ebuild
В Срд, 29/09/2010 в 20:43 +, Pacho Ramos (pacho) пишет:
pkg_setup() {
if use python; then
python_set_active_version 2
fi
It's much shorter and clearer to write
use python python_set_active_version 2
--
Peter.
Re: [gentoo-dev] .la files removal news item (GLEP 42)
В Птн, 01/10/2010 в 12:27 +0200, Tomáš Chvátal пишет:
this can be done either by using the
(currently testing) Portage 2.1.9 series, or by adding the following
snippet to your /etc/portage/bashrc:
post_src_install() {
lafilefixer ${D}
}
It's better to avoid suggesting this as such things tend to stay for a
very long time on user's systems and since this'll became redundant once
portage 2.1.9 will go stable soon it'll la files will be fixed twice
for no reason.
--
Peter.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-misc/openvpn: ChangeLog openvpn-2.1.3.ebuild
Am 01.10.2010 15:07, schrieb Peter Volkov:
В Пнд, 27/09/2010 в 11:37 +, Dirkjan Ochtman (djc) пишет:
[[ ${i} == README || ${i} == examples || ${i} ==
defer ]] continue
[[ ${i} == auth-pam ]] ! use pam continue
einfo Building ${i} plugin
cd ${i}
emake CC=$(tc-getCC) || die make failed
cd ..
I think pushd/popd are better suited for this then cd ${dir} / cd ..
You can make it even shorter by using the -C switch of (e)make, so you dont
have to manually
enter/exit the dir.
--
Thomas Sachau
Gentoo Linux Developer
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] QA last rites for app-doc/heirloom-doctools
# Diego E. Pettenò flamee...@gentoo.org (01 Oct 2010) # on behalf of QA team # # Upstream seems to be dead, and keeping importing it from # OpenSolaris unlikely; too many man pages installed by our # packages are not compatible with it. # # Removal on 2010-11-30 app-doc/heirloom-doctools
[gentoo-dev] Re: .la files removal news item (GLEP 42)
Il giorno ven, 01/10/2010 alle 17.31 +0400, Peter Volkov ha scritto: It's better to avoid suggesting this as such things tend to stay for a very long time on user's systems and since this'll became redundant once portage 2.1.9 will go stable soon it'll la files will be fixed twice for no reason. It won't hurt anyway, and it'll definitely avoid people having to re-run lafilefixer manually from time to time. -- Diego Elio Pettenò — “Flameeyes” http://blog.flameeyes.eu/ If you found a .asc file in this mail and know not what it is, it's a GnuPG digital signature: http://www.gnupg.org/
Re: [gentoo-dev] .la files removal news item (GLEP 42)
2010/10/1 Tomáš Chvátal scarab...@gentoo.org: Hi lads, due to recent situation about .la files status we would like to inform users about this situation. See attached file that we propose to be included as news item. Step 2 will be finding global policy how to get rid of them as fast as possible without too much more hassle for our users :) Does lafilefixer fix binpkgs now? As well as the vdb manifests for the files? If it doesn't, I strongly object to having it as an official recommendation. A surprisingly large no. of people (at least on bugzilla) have FEATURES=buildpkg . -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-misc/openvpn: ChangeLog openvpn-2.1.3.ebuild
On Fri, Oct 1, 2010 at 6:37 PM, Peter Volkov p...@gentoo.org wrote:
В Пнд, 27/09/2010 в 11:37 +, Dirkjan Ochtman (djc) пишет:
src_compile() {
use static sed -i -e '/^LIBS/s/LIBS = /LIBS = -static /' Makefile
emake || die make failed
if ! use minimal ; then
cd plugin
for i in $( ls 2/dev/null ); do
This is bad construction:
http://mywiki.wooledge.org/BashPitfalls#for_i_in_.24.28ls_.2A.mp3.29
A nice way around this is to do the following:
ls -1 | while read i; do
`read` delimits on newline, so you're safe.
--
~Nirbheek Chauhan
Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] .la files removal news item (GLEP 42)
On 10/01/2010 08:13 AM, Nirbheek Chauhan wrote: Does lafilefixer fix binpkgs now? As well as the vdb manifests for the files? If it doesn't, I strongly object to having it as an official recommendation. A surprisingly large no. of people (at least on bugzilla) have FEATURES=buildpkg . It works if you run it on $D in post_src_install like the news item recommends. The binary package is created from $D after that. -- Thanks, Zac
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-libs/libproxy: ChangeLog libproxy-0.4.6.ebuild
2010-10-01 15:15:56 Peter Volkov napisał(a):
В Срд, 29/09/2010 в 20:43 +, Pacho Ramos (pacho) пишет:
pkg_setup() {
if use python; then
python_set_active_version 2
fi
It's much shorter and clearer to write
use python python_set_active_version 2
Calling python_pkg_setup() is required in EAPI =4, so I suggest:
pkg_setup() {
if use python; then
python_set_active_version 2
python_pkg_setup
fi
}
--
Arfrever Frehtes Taifersar Arahesis
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-libs/libproxy: ChangeLog libproxy-0.4.6.ebuild
El vie, 01-10-2010 a las 17:15 +0400, Peter Volkov escribió:
В Срд, 29/09/2010 в 20:43 +, Pacho Ramos (pacho) пишет:
pkg_setup() {
if use python; then
python_set_active_version 2
fi
It's much shorter and clearer to write
use python python_set_active_version 2
Well, I didn't make that change:
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-libs/libproxy/libproxy-0.4.2.ebuild?r1=1.1r2=1.2
but ok, I am sure it will be useful anyway for other similar cases :-)
Best regards
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] Re: .la files removal news item (GLEP 42)
Il giorno ven, 01/10/2010 alle 20.43 +0530, Nirbheek Chauhan ha scritto: Does lafilefixer fix binpkgs now? As well as the vdb manifests for the files? If it doesn't, I strongly object to having it as an official recommendation. A surprisingly large no. of people (at least on bugzilla) have FEATURES=buildpkg . And usually (even if not always) have one system where they build and one system where they install. The one where they install only, and not build, will do nothing with .la files, so fixed or not doesn't make any difference. The other, if they install back a built package might require another run of it, I don't think it makes much difference though to them — beside making you feel righteous at dragging your feet. Nice try. -- Diego Elio Pettenò — “Flameeyes” http://blog.flameeyes.eu/ If you found a .asc file in this mail and know not what it is, it's a GnuPG digital signature: http://www.gnupg.org/ signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: .la files removal news item (GLEP 42)
Il giorno ven, 01/10/2010 alle 18.42 +0300, Eray Aslan ha scritto: Why not push for stabilization of 2.1.9 and then do the news item? Am I missing something? Yah, the bickering of some people at having .la files disappear under their feet, probably because they are affectionate to them, or force them to consider dong a bit more cleanup work. But since the suggestions are already useful, I guess it would be a decent time to tell users about them; I have suggested doing so for a very long time already; it worked for all the people whom I know have been using it, it worked for me; heck it even avoided the tinderbox to stop when automagic dependencies over selinux where passing down. But it's trying to solve a problem that is at least three years old; it's a suggestion I made more over an year ago; and that people shot down many many times. Sincerely, the naysayers on the .la matter have already broken enough systems by not allowing .la files to die earlier, and now they are pretending that there is no problem in waiting another X years in planning a conversion that for what they are concerned is never going to happen. So basically, this is my token: we can tell users to do it this way and they won't feel pain at all; or we can't tell them, and when maintainers get pissed off by .la files enough they delete them, leaving users to Google their solution. I, sincerely, have poured enough effort in trying to solve the issue, discussing it, documenting it, showing how to deal with new packages, showing how to identify pointless .la files that only increase the number of them installed and cause false positives… and I'm still told that a) I haven't done _enough_, as I had to prepare a master plan of it and b) I'm too negative about stuff. -- Diego Elio Pettenò — “Flameeyes” http://blog.flameeyes.eu/ If you found a .asc file in this mail and know not what it is, it's a GnuPG digital signature: http://www.gnupg.org/ signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: Re: [gentoo-commits] gentoo-x86 commit in dev-python/sympy/files: sympy-0.6.7-python-2.7.patch
Il giorno ven, 01/10/2010 alle 15.32 +0400, Peter Volkov ha scritto: I was talking about case where python-2.7 it is already installed (although it is hard masked it is already in the tree). In such case python-updater will not be run. Ah sorry I misread that it as sympy, not Python… yes I guess you're right about that. -- Diego Elio Pettenò — “Flameeyes” http://blog.flameeyes.eu/ If you found a .asc file in this mail and know not what it is, it's a GnuPG digital signature: http://www.gnupg.org/ signature.asc Description: This is a digitally signed message part
[gentoo-dev] Help on f-spot-0.8 problem
Hello Since Calchan doesn't have much time for f-spot and dotnet team is conformed basically by me, I would welcome any help for trying to bump f-spot to its 0.8 version. The problem is that eautoreconf doesn't run, even running autoreconf on unpacked upstream sources fails with the following error: $ autoreconf /usr/share/aclocal/sigc++.m4:8: warning: underquoted definition of AM_PATH_SIGC /usr/share/aclocal/sigc++.m4:8: run info '(automake)Extending aclocal' /usr/share/aclocal/sigc++.m4:8: or see http://sources.redhat.com/automake/automake.html#Extending-aclocal help/Makefile.am:1: HAVE_GNOME_DOC_UTILS does not appear in AM_CONDITIONAL gnome-doc-utils.make:63: HAVE_GNOME_DOC_UTILS does not appear in AM_CONDITIONAL help/Makefile.am:2: `gnome-doc-utils.make' included from here gnome-doc-utils.make:143: ENABLE_SK does not appear in AM_CONDITIONAL help/Makefile.am:2: `gnome-doc-utils.make' included from here gnome-doc-utils.make:192: ENABLE_SK does not appear in AM_CONDITIONAL help/Makefile.am:2: `gnome-doc-utils.make' included from here build/build.rules.mk:32: ENABLE_TESTS does not appear in AM_CONDITIONAL lib/Hyena/Hyena.Data.Sqlite/Makefile.am:29: `build/build.mk' included from here build/build.mk:2: `build/build.rules.mk' included from here build/build.rules.mk:37: ENABLE_ATK does not appear in AM_CONDITIONAL lib/Hyena/Hyena.Data.Sqlite/Makefile.am:29: `build/build.mk' included from here build/build.mk:2: `build/build.rules.mk' included from here build/build.rules.mk:32: ENABLE_TESTS does not appear in AM_CONDITIONAL lib/Hyena/Hyena.Gui/Makefile.am:121: `build/build.mk' included from here build/build.mk:2: `build/build.rules.mk' included from here build/build.rules.mk:37: ENABLE_ATK does not appear in AM_CONDITIONAL lib/Hyena/Hyena.Gui/Makefile.am:121: `build/build.mk' included from here build/build.mk:2: `build/build.rules.mk' included from here ... I have already installed app-text/gnome-doc-utils-0.20.1, I have also verified /usr/share/gnome-doc-utils/gnome-doc-utils.make is the same as f-spot provided one, and that sources doesn't seem to be shipping any gnome-doc-utils.m4 file Thanks a lot for your help and ideas :-) signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/sympy/files: sympy-0.6.7-python-2.7.patch
2010-10-01 10:30:22 Peter Volkov napisał(a): В Птн, 24/09/2010 в 20:09 +, Arfrever Frehtes Taifersar Arahesis (arfrever) пишет: Added:sympy-0.6.7-python-2.7.patch Log: Fix majority of test failures with Python 2.7 (bug #330713). This patch fixes not test failure, but sympy's ability to work with python-2.7. I'm assuming that you mean the change in stringpict.py, not in runtests.py. The change in stringpict.py only fixes a doctest in a doc string. The doctest isn't shown in the patch, so I'm pasting the whole code of this function below: def right(self, *args): rPut pictures next to this one. Returns string, baseline arguments for stringPict. (Multiline) strings are allowed, and are given a baseline of 0. from sympy.printing.pretty.stringpict import stringPict print stringPict(10).right( + ,stringPict(1\r-\r2,1))[0] 1 10 + - 2 return stringPict.next(self, *args) http://docs.python.org/library/doctest.html Revision ChangesPath 1.1 dev-python/sympy/files/sympy-0.6.7-python-2.7.patch file : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/dev-python/sympy/files/sympy-0.6.7-python-2.7.patch?rev=1.1view=markup plain: http://sources.gentoo.org/viewvc.cgi/gentoo-x86/dev-python/sympy/files/sympy-0.6.7-python-2.7.patch?rev=1.1content-type=text/plain Index: sympy-0.6.7-python-2.7.patch === http://github.com/sympy/sympy/commit/717516b8ffae806cdfdea8141ceb839107d92431 --- sympy/printing/pretty/stringpict.py +++ sympy/printing/pretty/stringpict.py @@ -81,7 +81,7 @@ return '\n'.join(result), newBaseline def right(self, *args): -Put pictures next to this one. +rPut pictures next to this one. Returns string, baseline arguments for stringPict. (Multiline) strings are allowed, and are given a baseline of 0. from sympy.printing.pretty.stringpict import stringPict --- sympy/utilities/runtests.py +++ sympy/utilities/runtests.py @@ -778,7 +778,7 @@ def start(self): self.write_center(test process starts) executable = sys.executable -v = sys.version_info +v = tuple(sys.version_info) python_version = %s.%s.%s-%s-%s % v self.write(executable: %s (%s)\n\n % (executable, python_version)) self._t_start = clock() -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: .la files removal news item (GLEP 42)
On 10/01/2010 12:12 PM, Nirbheek Chauhan wrote: On Fri, Oct 1, 2010 at 11:24 PM, Diego Elio Pettenò flamee...@gmail.com wrote: Il giorno ven, 01/10/2010 alle 20.43 +0530, Nirbheek Chauhan ha scritto: Does lafilefixer fix binpkgs now? As well as the vdb manifests for the files? If it doesn't, I strongly object to having it as an official recommendation. A surprisingly large no. of people (at least on bugzilla) have FEATURES=buildpkg . And usually (even if not always) have one system where they build and one system where they install. The one where they install only, and not build, will do nothing with .la files, so fixed or not doesn't make any difference. Right, so a few weeks later when they re-merge a binpkg, they suddenly get build failures again. And that confuses them since it's unexpected. This is in general a bad experience for stable users who want to get work done, not baby-sit their system. Maybe advise them to use post_pkg_preinst instead of post_src_install, so it works even for binary packages. -- Thanks, Zac
Re: [gentoo-dev] Re: .la files removal news item (GLEP 42)
On Sat, Oct 2, 2010 at 1:08 AM, Zac Medico zmed...@gentoo.org wrote: On 10/01/2010 12:12 PM, Nirbheek Chauhan wrote: Right, so a few weeks later when they re-merge a binpkg, they suddenly get build failures again. And that confuses them since it's unexpected. This is in general a bad experience for stable users who want to get work done, not baby-sit their system. Maybe advise them to use post_pkg_preinst instead of post_src_install, so it works even for binary packages. If that won't cause problems with portage-2.1.9 (mtime/checksum messiness, for example; you're the best judge for this), then we should do it. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] .la files removal news item (GLEP 42)
Hi lads, due to recent situation about .la files status we would like to inform users about this situation. See attached file that we propose to be included as news item. Would it not be a better solution to have this information documented properly under Upgrade Guides or Gentoo System Documentation and then have this news item linked to it. What i'm concerned about is that this is not really a news item. From what I understand this issue could be with us for a rather long time (years even) so... How is this news item going to help ppl in a month from now (till the issue is solved in its entirety). Can we reasonably expect a new user to be aware of this. Do we expect users to read old ( and this could potentially become very old) news items. This is potentually a different situation from someone updating dbus (for example) from y.y.y to =y.y.y and having a once off (fire and forget) migration task. It is for this reason that I think this should be documented. Alistair. Step 2 will be finding global policy how to get rid of them as fast as possible without too much more hassle for our users :) Tomáš Chvátal Gentoo Linux Developer [Clustering/Council/KDE/QA/Sci/X11] E-Mail : scarab...@gentoo.org GnuPG FP: 94A4 5CCD 85D3 DE24 FE99 F924 1C1E 9CDE 0341 4587 GnuPG ID: 03414587
Re: [gentoo-dev] Re: .la files removal news item (GLEP 42)
On 10/01/2010 02:10 PM, Nirbheek Chauhan wrote: On Sat, Oct 2, 2010 at 1:08 AM, Zac Medico zmed...@gentoo.org wrote: On 10/01/2010 12:12 PM, Nirbheek Chauhan wrote: Right, so a few weeks later when they re-merge a binpkg, they suddenly get build failures again. And that confuses them since it's unexpected. This is in general a bad experience for stable users who want to get work done, not baby-sit their system. Maybe advise them to use post_pkg_preinst instead of post_src_install, so it works even for binary packages. If that won't cause problems with portage-2.1.9 (mtime/checksum messiness, for example; you're the best judge for this), then we should do it. It won't cause problems because the mtime/checksum stuff is all done after preinst, immediately as the files are being merged. -- Thanks, Zac
[gentoo-dev] Re: Re: .la files removal news item (GLEP 42)
Il giorno ven, 01/10/2010 alle 21.22 +0200, Enrico Weigelt ha scritto: Why not just introducing a FEAUTURE or USE flag which causes them not to be installed at all ? Because don't ask obvious questions unless you read the original references. Libtool archive files are used by ImageMagick, mpg123, libltdl itself, and a few more packages. Just removing all of them is not going to help. Plus at least one package install plugin files with .la extension even if they are not libtool archives. So please, we're not just avoiding the quick path out of spite, but because _it's not an accessible path at all_. -- Diego Elio Pettenò — “Flameeyes” http://blog.flameeyes.eu/ If you found a .asc file in this mail and know not what it is, it's a GnuPG digital signature: http://www.gnupg.org/
[gentoo-dev] Re: Re: .la files removal news item (GLEP 42)
Il giorno sab, 02/10/2010 alle 00.42 +0530, Nirbheek Chauhan ha scritto: Right, so a few weeks later when they re-merge a binpkg, they suddenly get build failures again. And that confuses them since it's unexpected. This is in general a bad experience for stable users who want to get work done, not baby-sit their system. Seriously, how many times do you re-install packages out of binpkgs on a _build_ system? I'll be honest: for me it's never. I reinstall them often on a _production_ system, but there, I mostly have INSTALL_MASK on .la files because _I don't build on those_. And in that situation, there is no breakage to begin with. Having said that, I was informed off-list that this is not meant to be *the* solution for la file removal breakage, but merely an informative notice to raise awareness for the (oft-useful) hammer that is lafilefixer. Which is going to cover their bases. *The* solution is to keep removing (in ~arch) everything else, and get it merged back into stable with time, which means that anything introduced _now_ should be stabled not before Portage 2.1.9.x is stabled, or can be a security stable; in that case users with lafilefixer set up will not even see it happening. I'm sorry, but I do not understand your hostility. Could you rephrase your objections with what I said in a way I can understand so that I can address them? I'm pretty sure I did that before, otherwise you might ask Remi, as he probably have more patience than me on the matter and is up-to-date with the situation last I knew. -- Diego Elio Pettenò — “Flameeyes” http://blog.flameeyes.eu/ If you found a .asc file in this mail and know not what it is, it's a GnuPG digital signature: http://www.gnupg.org/
[gentoo-dev] issue with gentoo-x86 cvs repo
hi, yesterday i was able to use the repo but now i get this error (for any cvs command): $ cvs rm -f apgdiff-2.0.2.ebuild Your account has expired; please contact your system administrator Connection closed by 81.93.255.6 cvs [remove aborted]: end of file from server (consult above messages if any) what does it exactly mean? fordfrog
Re: [gentoo-dev] issue with gentoo-x86 cvs repo
On Sat, Oct 02, 2010 at 03:19:42AM +0200, Miroslav ?ulc (fordfrog) wrote: hi, yesterday i was able to use the repo but now i get this error (for any cvs command): $ cvs rm -f apgdiff-2.0.2.ebuild Your account has expired; please contact your system administrator Connection closed by 81.93.255.6 cvs [remove aborted]: end of file from server (consult above messages if any) what does it exactly mean? It's fixed already. Some lovely lines from the old perl_ldap: === my $expiry = convertEpoch(0,0,0,1,9,2010); ... shadowExpire = $expiry, === Which is a date of 2010/10/02, that just rolled up a few hours ago. A constant value that was set 5 years ago come up :-). All LDAP and the script are fixed now. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
Re: [gentoo-dev] .la files removal news item (GLEP 42)
On 10:20 Sat 02 Oct , Alistair Bush wrote: Would it not be a better solution to have this information documented properly under Upgrade Guides or Gentoo System Documentation and then have this news item linked to it. This is a good point if it turns out that this isn't temporary. See below... How is this news item going to help ppl in a month from now (till the issue is solved in its entirety). Can we reasonably expect a new user to be aware of this. Do we expect users to read old ( and this could potentially become very old) news items. As soon as new stages get built with portage 2.1.9 (i.e., as soon as it goes stable, as I understand the autobuild process), it should no longer be a problem for fresh installations. It will of course remain a problem for people who wait forever to update their systems, but it will come in as a news item whenever they do update. It almost makes you wonder whether portage-2.1.9 should run lafilefixer itself in postinst, just to ensure everything's fixed on the system before it starts fixing individual new packages. -- Thanks, Donnie Donnie Berkholz Sr. Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpAinQyOQySc.pgp Description: PGP signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-misc/openvpn: ChangeLog openvpn-2.1.3.ebuild
On Fri, 1 Oct 2010 20:47:38 +0530
Nirbheek Chauhan nirbh...@gentoo.org wrote:
On Fri, Oct 1, 2010 at 6:37 PM, Peter Volkov p...@gentoo.org wrote:
В Пнд, 27/09/2010 в 11:37 +, Dirkjan Ochtman (djc) пишет:
src_compile() {
use static sed -i -e '/^LIBS/s/LIBS = /LIBS = -static /' Makefile
emake || die make failed
if ! use minimal ; then
cd plugin
for i in $( ls 2/dev/null ); do
This is bad construction:
http://mywiki.wooledge.org/BashPitfalls#for_i_in_.24.28ls_.2A.mp3.29
A nice way around this is to do the following:
ls -1 | while read i; do
`read` delimits on newline, so you're safe.
This strips leading and trailing whitespace.
$ touch test1
$ touch test2
$ touch test 3
$ touch test 4
$ ls -1 | while read i; do echo ###${i}###; done
###test2###
###test 3###
###test1###
###test 4###
instead use:
$ ls -1 | while IFS= read i; do echo ###${i}###; done
###test2 ###
###test 3###
### test1###
### test 4 ###
or recursively:
$ find . -type f -print0 \
| while IFS= read -d $'\0' i; do echo ###${i}###; done
###./ test1###
###./ test 4 ###
###./test 3###
###./test2 ###
or just make things simple on yourself :)
$ for i in *; do echo ###${i}###; done
### test1###
###test2 ###
###test 3###
### test 4 ###
--
fonts, gcc-porting, we hold our breath, we spin around the world
toolchain, wxwidgetsyou and me cling to the outside of the earth
@ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
signature.asc
Description: PGP signature
[gentoo-dev] Re: .la files removal news item (GLEP 42)
Diego Elio Pettenò posted on Sat, 02 Oct 2010 03:06:56 +0200 as excerpted: Il giorno sab, 02/10/2010 alle 00.42 +0530, Nirbheek Chauhan ha scritto: Right, so a few weeks later when they re-merge a binpkg, they suddenly get build failures again. And that confuses them since it's unexpected. This is in general a bad experience for stable users who want to get work done, not baby-sit their system. Seriously, how many times do you re-install packages out of binpkgs on a _build_ system? Frequently enough for it to be a consideration. Among other things, it's a fast way to roll-back to a working version when a new version goes haywire, for whatever reason. I strongly recommend that users enable FEATURES=buildpkg for a host of reasons, and having it break or cause additional complications for them is not a good thing. Of course I also strongly recommend lafilefixer (based on your blog, BTW), too, but yeah, people /do/ sometimes reinstall from binpkgs on a build system. Having binpkgs around for my build system has saved my behind a number of times! You can't simply ignore potential issues because they don't happen to fit your usage case. But is there anything wrong with Zac's suggestion to use post_pkg_preinst instead? (Better to reply to that under his post, just mentioning that there's a suggested solution.) [context reinserted] I don't think it makes much difference though to them — beside making you feel righteous at dragging your feet. Nice try. I'm sorry, but I do not understand your hostility. Could you rephrase your objections with what I said in a way I can understand so that I can address them? I'm pretty sure I did that before But even if that before included him, it is not yet part of the public record of this discussion. Perhaps a simple link to that previous discussion, for the public record in this one? The jab /was/ rather unnecessary and uncalled for, and would have been better not posted. Even if the subject had been dealt with before, the question raised was a legitimate one to be raised here as part of the public record of /this/ discussion (where it had yet to be raised), which is, after all, part of the reason for the policy to post such things to this (public) list before simply adding them to the tree. And, it would seem, Zac has a suggestion to help, again part of the reason for the policy, the end product ends up better for it. =:^) I realize there's a reason for your nick, but that doesn't mean you have to live up to it. =:^) Meanwhile, thanks for pushing the news item. The whole lafilefixer thing has been needed for some time, and now that it's available and quite well tested, getting the news out is a /good/ thing! =:^) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
