[gentoo-dev] lastrite: www-client/kazehakase
nothing usable left in tree. # Samuli Suominen (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 324953 # # Removal in 30 days www-client/kazehakase
Re: [gentoo-dev] lastrite: www-client/kazehakase
On Sat, Jun 26, 2010 at 11:35:29AM +0300, Samuli Suominen wrote: > nothing usable left in tree. > > # Samuli Suominen (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 324953 > # > # Removal in 30 days > www-client/kazehakase In case anyone is interested in picking this up, I've attached the patches from upstream for xulrunner and gtk+ to their bugs. With those, it's at least possible to get kazehakase to build, run, and display web pages.
[gentoo-dev] QA last rites for dev-util/pbuilder
# Diego E. Pettenò (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
[gentoo-dev] QA last rites for app-i18n/adaptit
# Diego E. Pettenò (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
[gentoo-dev] Lastrite: xulrunner-bin
# Samuli Suominen (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...
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
* Krzysztof Pawlik 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 source archives along with whatever binary archives you may have." ^ cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ -
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
* Alistair Bush 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 interested in good old C/C++, etc Just give me everything you've got :) cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ -
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
On 06/26/10 19:51, Enrico Weigelt wrote: > * Krzysztof Pawlik 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 source archives along with whatever binary archives you may > have." > ^ You intend to "prohibit" releasing binary packages for upstream? Thats... something you don't see everyday. Why would you do that? It's quite common for Java projects to release pre-built JAR files or for C/C++ (or other) based projects to release debs or rpms - it's standard practice. What's important in quoted sentence is: "Release the source archives along with binary archives" - the "with" is very important - in short: don't release only binary versions and force us to grab them from VCS. -- Krzysztof Pawlikkey id: 0xF6A80E46 desktop-misc, java, apache, ppc, vim, kernel, python... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
* Petteri Räty 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 branches ontop the upstream's release tags instead of manually maintaining patches against tarballs ... #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. #3 When he's talking about "disabling dependencies", he most likely has the totally wrong concept in mind (as probably most Gentoo folks ;-p): you naturally dont want to enable/disable dependencies, but features (which then imply certain dependencies). Once you use terms like "zlib support", you're already on the wrong path. #4 The discussion about "how to be a good downstream" (started by the ffmpeg guy) is quite interesting ... that's exactly the kind of situations what the OSS-QM (see my recent posts) is for. (and all goes sooo easy w/ tools like git ;-p) cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ -
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
On Sat, 26 Jun 2010 21:39:15 +0200 Enrico Weigelt 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 you warnings for f(g(a), g(b)) if you -Wall. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
* Krzysztof Pawlik 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" releasing binary packages for upstream? No, I'm talking about precompiled stuff within the source tree. Such things should _never ever_ happen. In Java world it seems to be quite common to bundle precompiled imported libraries within the source tree. Needless to say that this can easily get hell for any package-based distro. (actually, that mostly comes from the windows front, where concepts like package management are quite unknown ... ;-o) > What's important in quoted sentence is: "Release the source archives along > with > binary archives" - the "with" is very important - in short: don't release only > binary versions and force us to grab them from VCS. Okay, perhaps I misunderstood this sentence. 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 that). cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ -
[gentoo-dev] Re: FYI: Rules for distro-friendly packages
On 06/26/2010 10:39 PM, Enrico Weigelt wrote: * Petteri Räty 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 thinking of making -Wall and -Werror mandatory. if some package doenst build fine, it's simply broken. period. That's the most hilarious thing I've read in ages. xD
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
On Sat, 26 Jun 2010 21:46:39 +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 that). 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. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
* Ciaran McCreesh schrieb: > On Sat, 26 Jun 2010 21:39:15 +0200 > Enrico Weigelt 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 you warnings for f(g(a), g(b)) if > you -Wall. Warn on what exactly ? Which compilers do that ? cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ -
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
On 06/26/10 20:59, Ciaran McCreesh wrote: > On Sat, 26 Jun 2010 21:46:39 +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 that). > > 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 one more thing: tags can be mutable. -- Krzysztof Pawlikkey id: 0xF6A80E46 desktop-misc, java, apache, ppc, vim, kernel, python... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
On Sat, 26 Jun 2010 21:57:33 +0200 Enrico Weigelt 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 4.7. New gcc releases regularly issue lots of new warnings for correct code, particularly with -Wall. Other compilers are even worse. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
* Krzysztof Pawlik 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 one more thing: tags can be mutable. Thats a matter of proper VCS configuration (hooks, etc) cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ -
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
* Ciaran McCreesh schrieb: > On Sat, 26 Jun 2010 21:46:39 +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 that). > > 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. Well, with git this works. (I'll yet have to run some automatic stress tests, but at all my manual tests worked really fine). *If* this might not work somewhere, the little generator script could create the tarball only once (on first request) and use it all the time. Or add some commit/push hook, etc, etc. cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ -
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
On Sat, 26 Jun 2010 22:09:09 +0200 Enrico Weigelt 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 produce the same output. This is not the case. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
On Sun, Jun 27, 2010 at 1:29 AM, Ciaran McCreesh wrote: > On Sat, 26 Jun 2010 21:46:39 +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 that). > > 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. > Or if they generate the tarball on-the-fly with no caching, which results in differing timestamps each time. Hence, each time you fetch it, you get a tarball with a different hash. No, don't ask where I saw such a thing :p -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
[gentoo-dev] Re: CAcert certificate distribution license to third parties (i.e. distributors like gentoo)
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 discussed in CAcert's policy group yet. > > If you want to follow/contribute to this discussion look for a post to the > policy list soon. > https://lists.cacert.org/wws/info/cacert-policy > > I make no inferences good or bad about this. Mainly because I'm writing > this with a headache. > > Cheers, > > Daniel Recently Sasha from Fedora has proposed CAcert's root distribution license as CC-ND. This avoids many complications of the draft proposal above. By joining the list you can vote for it. the proposal: https://lists.cacert.org/wws/arc/cacert-policy/2010-06/msg00151.html Once registered on this site there is a "send to (your email)" link on the top right to preserve threading. ref: http://spreitzer.name/set-the-cacert-root-certificates-free Daniel signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
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 that). This breaks badly when the upstream tarball generation is changed. This happened to github a few months ago and broke all our manifests. To their credit they quickly reverted what turned out to be a gratuitous change, but if they ever need to make a real change we get to redigest everything. Kind regards, Hans signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: FYI: Rules for distro-friendly packages
On 06/26/2010 11:12 PM, Ciaran McCreesh wrote: On Sat, 26 Jun 2010 21:57:33 +0200 Enrico Weigelt 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 4.7. New gcc releases regularly issue lots of new warnings for correct code, particularly with -Wall. Other compilers are even worse. Did it actually occur to anyone that warnings are not errors? You can have them for correct code. A warning means you might want to look at the code to check whether there's some real error there. It doesn't mean the code is broken.
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
On Sat, 26 Jun 2010 21:57:33 +0200 Enrico Weigelt 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 you warnings for f(g(a), g(b)) if > > you -Wall. > > Warn on what exactly ? Which compilers do that ? I suggest you to try latest available dev-lang/icc (11.1.072). This thing is really paranoid: remark #2259: non-pointer conversion from "int" to "unsigned char" may lose significant bits unsigned char BlinkerPhase = 0; ... BlinkerPhase = (BlinkerPhase + 1) & 3; remark #981: operands are evaluated in unspecified order (tons of them) return strcmp( left.c_str(), right.c_str() ) > 0; -- Sergei
