Re: [gentoo-dev] issue with gentoo-x86 cvs repo
Dne 2.10.2010 03:35, Robin H. Johnson napsal(a): 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. Thanks :-)
Re: [gentoo-dev] Re: .la files removal news item (GLEP 42)
Duncan wrote: 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! Same here. That has saved me a lot of time and frustration in the past as well. I have had buildpkg set in make.conf for ages. I use it regularly and would not want to have that messed up. I recently used it when a KDE upgrade went bust. Without being able to go back to the old binaries, I would have had almost a day of compiling and no GUI at all. With it, just a hour or so for it to unpack and put it back. Some people may not have it set or use it but there are people that do. Dale :-) :-)
Re: [gentoo-dev] .la files removal news item (GLEP 42)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02-10-2010 03:01, Donnie Berkholz wrote: On 10:20 Sat 02 Oct , Alistair Bush wrote: 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. You're correct. The weekly stages are built from the latest stable revisions of packages in the tree. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJMpy6tAAoJEC8ZTXQF1qEP20MQAJpCm+GfPvg/K2JEyXLvPkHu 7lRDM6rojOtH2nSxFW+WElGM0ly6CWj6xvm5vfPRD7dIisihrVPxDStOUI5hM3uV I1+IBecRyNlc7DPDBCOtMDbrzFpVlFTKM0p20eIIL5inimtfoVO6Iowps97KoW3M zmO0gTKdqWbBKmDzsAb/8seAWDNm0oKGURDL1gaYjQGUO3vckk7Ft2JBsQVg8Qy3 XLfjv9ft12TKUo/DFwowIf0IsFQooHWbrN77jDM9BjlzyTtrVFi3anZF5SdkLMYR I7VpKxhKEWaCJcyjyRZzo1QbvcvLAunPTbXZ2gwImisCzxp5gfRod3RwQpT8QGVb QlQeNo6PfaLlipA3EB17ZFVD5pU33YCGrbgLAOOe5a5bTWy1LK4NDdPmbW7cUL5d 9XpiADNlXP6gD1tDcqMHwo0zZa7F5YW/dwKGo/F3A296gD6l0zqIxp+AL6Rk7Awy W18YxFNPly6pFgktaJLicE1nPOKfbqvI7Dwcu534untfZUWSS1XQBCkRRW8Gtq+i jX41YWatE0cltKd7uBEyuc6fVAR3rAtHzpXHgNrh+04dVFrkJcUeJun+JiIAE1WU j+mN/NMD4ylqvzgQyS/YTMOBSVQW3EvFnq+p7H8OxHoH7XzQNSQkLsrAOBFcnPn6 3c6pxdEd9ZCzDi4y9fuj =hm// -END PGP SIGNATURE-
Re: [gentoo-dev] Re: .la files removal news item (GLEP 42)
В Птн, 01/10/2010 в 20:02 +0200, Diego Elio Pettenò пишет: 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, I guess that you were told that... is due to the way you've tried to reach developer's community. Actually I failed to find any mails on '.la files removal' subject in gentoo-dev-announce or gentoo-dev mailing lists. Now I assume that by efforts you mean blog posts and bug reports. Both of this medias are targeted on small subgroup of Gentoo developers: blogs contain only personal opinion and no Gentoo developer supposed to read blogs (btw, I'm not reading all blog entries); bug reports are really better but again only small fraction of developers is informed (only 10 bugs is currently opened). Yea, there were some discussions on -dev mailing list: first discussion I found was Removing .la files... where we discussed _problems_ such removal may cause with no clear resolution. After that 'la file' substring matches thread about libpng (again problems) and some even shorter threads. So every developer knew that we should remove .la files but also we knew that inconsistent removal (like currently happened again) causes problems for users and nobody ever announced any distro-wide guidelines. It is obvious that to avoid useless rebuild we should have been started from most popular leaf packages like gnome/xfce/X11 and only then move on dependent libraries but nobody told: please, start now from here and here. Currently it'll be great if you could point on relevant information so we could continue to remove .la files without mess (e.g. altering stable packages). But looks like before such plan could be announced we really need to discuss how we handle stable packages (heh, again). So I'll end with bottom line: please, post really important distribution wide things to appropriate media (gentoo-dev-announce mailing list)! -- Peter.
Re: [gentoo-dev] Re: .la files removal news item (GLEP 42)
В Птн, 01/10/2010 в 12:38 -0700, Zac Medico пишет: Maybe advise them to use post_pkg_preinst instead of post_src_install, so it works even for binary packages. Is it possible for portage-2.1.8.x to depend on lafilefixer and add run lafilefixer (if installed) from base profile bashrc? -- Peter.
[gentoo-dev] QA last rites for net-nntp/nntpswitch
# Diego E. Pettenò flamee...@gentoo.org (02 Oct 2010) # on behalf of QA team # # Violate sandbox at least since July 2009 (bug #279090) # thus cannot install; ignores flags (bug #241090). # # Removal on 2010-12-01 net-nntp/nntpswitch
Re: [gentoo-dev] Re: .la files removal news item (GLEP 42)
On 10/01/2010 09:12 PM, Nirbheek Chauhan wrote: 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? During the past discussions you were somehow overly conservative, taking issue of corner cases and overall on the aggressive stance. I know that you had a rough week but others do as well, Diego among them. lu -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero
Re: [gentoo-dev] Re: .la files removal news item (GLEP 42)
On Sat, Oct 2, 2010 at 9:21 PM, Luca Barbato lu_z...@gentoo.org wrote: On 10/01/2010 09:12 PM, Nirbheek Chauhan wrote: 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? During the past discussions you were somehow overly conservative, taking issue of corner cases and overall on the aggressive stance. My opinions haven't changed one bit in the past week. I don't see how not breaking the stable tree can be called being overly conservative. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
[gentoo-dev] Last rites: sci-chemistry/validation
# Andreas K. Huettel dilfri...@gentoo.org (02 Oct 2010) # Masking for removal in 30 days # Upstream is dead, does not build, would need massive work for current # gcc. Seems like nobody has missed it for some time. Bug 296651. sci-chemistry/validation -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Help on f-spot-0.8 problem
Hi, Pacho. В Птн, 01/10/2010 в 20:14 +0200, Pacho Ramos пишет: 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 $ cd f-spot-0.8.0 $ grep -r HAVE_GNOME_DOC_UTILS . | grep m4 will help you to see that this conditional is defined in ./build/m4/shamrock/gnome-doc.m4. build/build.rules.mk:37: ENABLE_ATK does not appear in AM_CONDITIONAL this on is defined in ./build/m4/f-spot/gtk-sharp.m4. This problem can be fixed with correct include pathes: autoreconf -f -I build/m4/shamrock/ -I build/m4/f-spot/ thus I think AT_M4DIR=-I build/m4/shamrock/ -I build/m4/f-spot/ eautoreconf should work. 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 :-) Thank you for taking care about this package! I really appreciate f-spot version bump :) -- Peter.
Re: [gentoo-dev] Re: .la files removal news item (GLEP 42)
On 10/02/2010 05:21 AM, Peter Volkov wrote: В Птн, 01/10/2010 в 12:38 -0700, Zac Medico пишет: Maybe advise them to use post_pkg_preinst instead of post_src_install, so it works even for binary packages. Is it possible for portage-2.1.8.x to depend on lafilefixer and add run lafilefixer (if installed) from base profile bashrc? The profile bashrc may not be a very good place for this since it's executed by all versions of portage, and thus would be redundant for =portage-2.1.9. We can do a portage-2.1.8.4 version bump with support for running lafilefixer, but this is a questionable move given that this version bump will be eligible for stabilization at about the same time as portage-2.1.9.13. -- Thanks, Zac
Re: [gentoo-dev] Re: .la files removal news item (GLEP 42)
В Сбт, 02/10/2010 в 10:43 -0700, Zac Medico пишет: On 10/02/2010 05:21 AM, Peter Volkov wrote: Is it possible for portage-2.1.8.x to depend on lafilefixer and add run lafilefixer (if installed) from base profile bashrc? We can do a portage-2.1.8.4 version bump with support for running lafilefixer, but this is a questionable move given that this version bump will be eligible for stabilization at about the same time as portage-2.1.9.13. This looks like the good case for fast stabilization so I'd better went this way. Any objections? -- Peter.
[gentoo-dev] .la files and their future on Gentoo
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello. Given the recent activity around .la files and conflict about how to deal with them, I propose we discuss this issue in this mailing list, and take this issue to the council. That way, we can make a global decision, taking into account all the arguments for and against, find a balance, opt for a policy, inform users and developers about it and move on. With that goal in mind, I'd like to ask anyone with arguments about this issue to present them as a reply to this thread. I'll present some arguments and some of the issues being raised on a latter mail. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJMp438AAoJEC8ZTXQF1qEPGzkQAMGg9x20PtHZ3KOlWwMwBf68 /mPUjmHYMFJmh/TVJniBdF7GWB4U+2pFmRYrbGixfglmSNtT6aohycFmvcZdrGmY GUZUbZnl4FvXnVp+XAYxu21Zzy/+NxwDiZchBXXjL6lLAWUnPiP0nEwNkB5yTOZS IPirLQ9wIqT2tb1KS1JNvas858qHAFJUt8yDd5Iv58rqDyPsLHrhJM8fdohMn3R0 8+aV9U4M3OpXpS0F53heJr3dYQB9Onw8HwUmQ1dcxfBtda7V29kQC24Eyr62LVcP Ajpjp0DroYOUTSaz2tOkReILDPOr3XFxCFdNYKtq9wh+Pq2fqdi0hZl/cfgTWFGW 0938sE/HA5rqnyHiSqqpYndywrH8YCUMovwti5/NSOSrGzaC7Jia5QpTpWZi8KJ4 FP7vtdG7BdKGEb2mQiDOQ7AHP6J8qWa6adpMAShjDndLwqftuRi9eRWL5WqVFqq3 25RgTCaRXPrzJYdJ35pirjK7ZrXx4M8KQ3Jd4Ljq7FTCB11V8J35itrC9hTKdLSI 3U8LrwDju9U1KixBvAdsxjHfolSjmaKGj+t1dcBocVjHFD2dBPSZf5JVwnNgNTcu r8G5799k6VFkWIdOoIylg8HUuHs5SlmSn9EZmiaSP/atwEAQDzhy1Nbj7b0qnPRY pbbu82EiSwyZHwpDRcpS =MFGl -END PGP SIGNATURE-
Re: [gentoo-dev] .la files and their future on Gentoo
Le 02/10/2010 21:54, Jorge Manuel B. S. Vicetto a écrit : With that goal in mind, I'd like to ask anyone with arguments about this issue to present them as a reply to this thread. [putting on my X11 cap] As far as X11 packages are concerned (libX11, libXext, cairo, etc), we can remove .la files now since upstream only supports linking through pkg-config (static linking included). So X11 can remove them any time, I was just waiting for a flag-day to do it. Cheers, Rémi
