[gentoo-dev] Re: gentoo-x86 commit in mail-filter/mailfilter: ChangeLog mailfilter-0.8.2.ebuild
EAPI=2
-
inherit eutils
DESCRIPTION=Mailfilter is a utility to get rid of unwanted spam mails
@@ -19,16 +18,16 @@
RDEPEND=
src_prepare() {
- epatch ${FILESDIR}/0.8.2-gcc44.patch
+ epatch ${FILESDIR}/0.8.2-gcc44.patch \
+ ${FILESDIR}/0.8.2-openssl-1.patch
}
src_compile() {
- # bug #281069
- emake -j1 || die emake failed
+ emake -j1 || die #281069
}
src_install() {
- emake DESTDIR=${D} install || die make install failed
+ emake DESTDIR=${D} install || die
dodoc INSTALL doc/FAQ ${FILESDIR}/rcfile.example{1,2} \
- README THANKS ChangeLog AUTHORS NEWS || die doc failed
+ README THANKS ChangeLog AUTHORS NEWS || die
}
Etiquette policy
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3chap=2:
| Respect developers' coding preferences. Unnecessarily changing the
| syntax of an ebuild increases the load on the CVS server and can cause
| complications for others. Syntax changes should only be done if there is
| a real benefit, such as faster compilation, improved information for the
| end user, or compliance to Gentoo policies.
If you are not the maintainer, don't quote any policy compliance in
ChangeLog, I think this is a breach of the etiquette policy.
Thanks
Re: [gentoo-dev] RFC: Reviving GLEP33
On Mon, 02 Aug 2010 23:47:01 +0200 Matti Bickel m...@gentoo.org wrote: What can you do with eblits you can't do with elibs? Define certain arbitrarily selected things that are legal in ebuilds and eclasses but not elibs. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Reviving GLEP33
On Mon, 02 Aug 2010 23:55:07 +0200 Matti Bickel m...@gentoo.org wrote: No, you can't make global scope changes just in an EAPI without screwing up user systems. You have to do the whole wait several years thing for them. Bad. So I guess it's back to ferring's use a new directory not readable by old PMs idea. GLEP55++, but having to wait several months for that and GLEP33 *on top* is not very motivation for me. Unlike the other ways of allowing new global scope functions, GLEP 55 doesn't require a wait, and it doesn't require mass fixing of existing packages. That's part of the point of it. GLEP 55 can be rolled out and used as quickly as the code to support it in Portage is unreverted. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in gnome-extra/nautilus-sendto: nautilus-sendto-2.28.4-r1.ebuild ChangeLog metadata.xml
Sending to herd since pacho reported afk for august.
Le lundi 21 juin 2010 à 18:48 +, Pacho Ramos (pacho) a écrit :
pacho 10/06/21 18:48:06
Modified: ChangeLog metadata.xml
Added:nautilus-sendto-2.28.4-r1.ebuild
Log:
Revision bump with upstream bugfixes that will allow us to re-enable mail
support
(Portage version: 2.1.8.3/cvs/Linux x86_64)
[...]
# Fix handling of shadowed mounts
epatch ${FILESDIR}/${P}-shadowed-mounts.patch
eautoreconf
}
missing intltoolize call
[...]
pkg_postinst() {
gnome2_pkg_postinst
if ! use mail; then
ewarn You have disabled mail support, this will remove support
for all mail clients
fi
}
Is there more than one mail backend enabled by this option, if no remove
the warning. If yes, do these actually depend on nothing more than eds ?
if so I suggest enabling eds support via an eds USE flag and make the
rest of the other mail backends build always.
Hopefully will be able to implement this myself once I get a schedule
for my gentoo activities :) but it the meantime, if you can do it, jump
on it. TIA.
--
Gilles Dartiguelongue e...@gentoo.org
Gentoo
[gentoo-dev] Package version in case of upstream patches from stable branch of development
Hi. How should we version our packages in case we've backported upstream patches from stable branch of development? Bug 330667 requests _p or _pre. I feel that _p|_pre versions should be left for VCS (read development) versions of the package, while during backports we have the best version with all important upstream+gentoo fixes available to the moment and I'd better avoid to call it development. If we decide to go with _p or _pre could we agree on answers for the following questions: - Does single patch from upstream's VCS justify _p$(date|rev) version? What if this is _the only_ patch in the upstream's VCS? - Now what about two patches? Three? N? When does few patches became pile? - What if I drop single patch from the upstream's patchset for stable branch, should we drop _pre _p version and add -rN? - What if there are two dependent patches, and first one fixes indentation? Should we spend time on backporting second patch (time consuming and error prone process) or use both and live closer to upstream? I think without exact answers on this questions I don't think this bug 330667 may request anything, only suggest... But what do you think? -- Peter.
Re: [gentoo-dev] New global use flag: vpx or vp8
On 07/31/2010 05:09 PM, Paweł Hajdan, Jr. wrote: On 7/31/10 4:37 AM, Hanno Böck wrote: vpx for supporting googles vp8 codec used in webm. No, vpx is for using libvpx. At the moment this is only mplayer and ffmpeg, but it's pretty obvious that apps supporting vp8 will start popping up everywhere (currently working on arista ebuild which will support it). Just verifying: does the vpx USE flag in ffmpeg control the support for encoding vp8, decoding it, or both? How should www-client/chromium depend on ffmpeg to make sure it will support vp8? it does trigger the use of libvpx, curreng ffvp8 (decoder) is faster than libvpx, libvpx is used for the encoding side for now. Though we might discuss if vpx is really a good name or it shouldn't be vp8. It might also be webm. Not sure what's more intuitive for people. Also, nteresting question would be whether to enable the flag by default an in which profiles (desktop?). vpx - you use libvpx vp8 - you want vp8 as for decoding ffmpeg is already a provider so application using it won't need additional useflag IMHO lu -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero
Re: [gentoo-dev] Package version in case of upstream patches from stable branch of development
On 08/03/2010 03:03 PM, Peter Volkov wrote: Hi. How should we version our packages in case we've backported upstream patches from stable branch of development? PV reflects the status of upstream that we base the ebuild on (usually a release) and then we apply individual reviewed patches on top of that in Gentoo revisions. Bug 330667 requests _p or _pre. I feel that _p|_pre versions should be left for VCS (read development) versions of the package, while during backports we have the best version with all important upstream+gentoo fixes available to the moment and I'd better avoid to call it development. If you read the bug you will see that our python has essentially been development versions so _p is in line with what you say above. If we decide to go with _p or _pre could we agree on answers for the following questions: - Does single patch from upstream's VCS justify _p$(date|rev) version? What if this is _the only_ patch in the upstream's VCS? No if the patch is small and can be reasonably understood. If the patch for example switches the used build system and I would think _p is called for. - Now what about two patches? Three? N? When does few patches became pile? You should ask upstream to make a release when they start to pile up. - What if I drop single patch from the upstream's patchset for stable branch, should we drop _pre _p version and add -rN? _p reflects upstream situation so dropping a patch from that is a Gentoo modification there so it would be _p12323-r1. - What if there are two dependent patches, and first one fixes indentation? Should we spend time on backporting second patch (time consuming and error prone process) or use both and live closer to upstream? I would leave this up to the maintainer. Depends on how much time backporting takes. Regards, Petteri signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: mail-client/drac
# Markos Chandras hwoar...@gentoo.org (03 Aug 2010) # Uses old portmap, installs # static library but not the header files. Last # release on 2007. Bug #280933 # Masked for removal in 30 days mail-client/drac -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org Key ID: 441AC410 Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410 pgpgrNEVk2TJM.pgp Description: PGP signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-zope/datetime: ChangeLog datetime-2.12.5.ebuild
On Thu, 29 Jul 2010 20:22:47 + (UTC), Arfrever Frehtes Taifersar
Arahesis (arfrever) arfre...@gentoo.org wrote:
snip
SRC_URI=http://pypi.python.org/packages/source/${MY_PN:0:1}/${MY_PN}/${MY_P}.tar.gz;
snip
This is a perfect example of over-complexification - Why didn't you
just use D instead of ${MY_PN:0:1} ?
While technically not /wrong/ - it is harder to read for no gain. I'm
confident that our fellow devs can read this but I think we should all
strive for being more user-friendly.
Thanks,
Jeremy
