nothing usable left in tree.
# Samuli Suominen ssuomi...@gentoo.org (26 Jun 2010)
# Masked for QA
#
# Fails to compile with stable xulrunner, see bug 317275
# Fails to compile with GTK+-2.20, see bug 325661
# Ignores LDFLAGS, see bug 268491
# Current stable is using vulnerable xulrunner, see bug
On Sat, Jun 26, 2010 at 11:35:29AM +0300, Samuli Suominen wrote:
nothing usable left in tree.
# Samuli Suominen ssuomi...@gentoo.org (26 Jun 2010)
# Masked for QA
#
# Fails to compile with stable xulrunner, see bug 317275
# Fails to compile with GTK+-2.20, see bug 325661
# Ignores
# Diego E. Pettenò flamee...@gentoo.org (26 Jun 2010)
# on behalf of QA team
#
# Debian-related package; no maintainer; no ebuild activity
# since 2005. Broken install phase as per bug #294975.
#
# Removal on 2010-08-25
dev-util/pbuilder
# Diego E. Pettenò flamee...@gentoo.org (26 Jun 2010)
# on behalf of QA team
#
# Fails to build since at least June 2009 (bug #274332). No
# activity since initial import in November 2008.
#
# Removal on 2010-08-25
app-i18n/adaptit
# Samuli Suominen ssuomi...@gentoo.org (26 Jun 2010)
# Vulnerable and now unused xulrunner-bin, support was dropped from
acroread.
#
# Masked for removal in 30 days, bug 324953.
net-libs/xulrunner-bin
Mask for source based xulrunner:1.8 soon to follow...
* Krzysztof Pawlik nelch...@gentoo.org schrieb:
Take a look at this page:
http://overlays.gentoo.org/proj/java/wiki/How_to_be_a_good_upstream - it is
Java
specific mostly, but some general points can be reused :)
Hmm, this document suggests something, I just forgot to prohibit:
Release the
* Alistair Bush ali_b...@gentoo.org schrieb:
Is this language specific?
I'll try to separate it into generic and language specific
rules step by step (same for various build systems, etc).
would you be interested in comments about java, ruby, python,
etc, etc, etc or are you only
* Petteri Räty betelge...@gentoo.org schrieb:
There should be useful stuff here:
http://video.fosdem.org/2010/devrooms/distributions/How_to_be_a_good_upstream.ogv
#1 he says nothing about that - if upstream has a VCS (and properly
uses it ;-o) - the distros should use it, so eg. set their
On Sat, 26 Jun 2010 21:39:15 +0200
Enrico Weigelt weig...@metux.de wrote:
#2 One point i don't agree is the dont add -Werror rule. actually,
i'm thinking of making -Wall and -Werror mandatory. if some
package doenst build fine, it's simply broken. period.
Uhm. No. Certain compilers will give
* Krzysztof Pawlik nelch...@gentoo.org schrieb:
Hmm, this document suggests something, I just forgot to prohibit:
Release the source archives along with whatever binary archives you may
have.
^
You intend to prohibit
On 06/26/2010 10:39 PM, Enrico Weigelt wrote:
* Petteri Rätybetelge...@gentoo.org schrieb:
There should be useful stuff here:
http://video.fosdem.org/2010/devrooms/distributions/How_to_be_a_good_upstream.ogv
[...[
#2 One point i don't agree is the dont add -Werror rule. actually,
i'm
On Sat, 26 Jun 2010 21:46:39 +0200
Enrico Weigelt weig...@metux.de wrote:
BTW: if upstream has an proper VCS and an canonical tagging
scheme, they don't actually have to create release tarballs,
just hack up a little script which creates them on-the-fly
from an canonical URL scheme (eg.
* Ciaran McCreesh ciaran.mccre...@googlemail.com schrieb:
On Sat, 26 Jun 2010 21:39:15 +0200
Enrico Weigelt weig...@metux.de wrote:
#2 One point i don't agree is the dont add -Werror rule. actually,
i'm thinking of making -Wall and -Werror mandatory. if some
package doenst build fine, it's
On 06/26/10 20:59, Ciaran McCreesh wrote:
On Sat, 26 Jun 2010 21:46:39 +0200
Enrico Weigelt weig...@metux.de wrote:
BTW: if upstream has an proper VCS and an canonical tagging
scheme, they don't actually have to create release tarballs,
just hack up a little script which creates them
On Sat, 26 Jun 2010 21:57:33 +0200
Enrico Weigelt weig...@metux.de wrote:
Uhm. No. Certain compilers will give you warnings for f(g(a), g(b))
if you -Wall.
Warn on what exactly ?
That f's arguments are evaluated in an unspecified order.
Which compilers do that ?
For all you know, gcc
* Krzysztof Pawlik nelch...@gentoo.org schrieb:
Down that path lies madness. There's no guarantee that you'll get the
same tarball if you request the same URL twice in a row, particularly
if you're using one of those new-fangled new compression schemes.
I agree with Ciaran here, to add
* Ciaran McCreesh ciaran.mccre...@googlemail.com schrieb:
On Sat, 26 Jun 2010 21:46:39 +0200
Enrico Weigelt weig...@metux.de wrote:
BTW: if upstream has an proper VCS and an canonical tagging
scheme, they don't actually have to create release tarballs,
just hack up a little script which
On Sat, 26 Jun 2010 22:09:09 +0200
Enrico Weigelt weig...@metux.de wrote:
Well, with git this works. (I'll yet have to run some automatic
stress tests, but at all my manual tests worked really fine).
You assume that, given the same input and program options, a
compression program will always
On Sun, Jun 27, 2010 at 1:29 AM, Ciaran McCreesh
ciaran.mccre...@googlemail.com wrote:
On Sat, 26 Jun 2010 21:46:39 +0200
Enrico Weigelt weig...@metux.de wrote:
BTW: if upstream has an proper VCS and an canonical tagging
scheme, they don't actually have to create release tarballs,
just hack
On Sunday 13 December 2009 22:44:05 Daniel Black wrote:
Recently this got produced as a draft license for parties distributing
CAcert's root certificate(s) (like us).
https://svn.cacert.org/CAcert/Policies/Agreements/3PVDisclaimerAndLicence.h
tml
This is still in draft hasn't been
On Sat, 2010-06-26 at 21:46 +0200, Enrico Weigelt wrote:
BTW: if upstream has an proper VCS and an canonical tagging
scheme, they don't actually have to create release tarballs,
just hack up a little script which creates them on-the-fly
from an canonical URL scheme (eg. oss-qm does exactly
On 06/26/2010 11:12 PM, Ciaran McCreesh wrote:
On Sat, 26 Jun 2010 21:57:33 +0200
Enrico Weigeltweig...@metux.de wrote:
Uhm. No. Certain compilers will give you warnings for f(g(a), g(b))
if you -Wall.
Warn on what exactly ?
That f's arguments are evaluated in an unspecified order.
Which
22 matches
Mail list logo
