[gentoo-dev] Last rites: x11-apps/{ttmkfdir,xfs,xfsinfo}
# Rémi Cardona r...@gentoo.org (13 Dec 2009) # ttmkfdir had multiple QA issues and bugs (bugs #209616, #235354 and #262945) # xfs is completely useless, even on thin clients # and xfsinfo is useless if xfs goes x11-apps/ttmkfdir x11-apps/xfs x11-apps/xfsinfo Cheers, Rémi
[gentoo-dev] QA last rites for media-gfx/giram
# Diego E. Pettenò flamee...@gentoo.org (14 Dec 2009) # on behalf of QA team # # Fails to build since October 2008 (bug #239811). Multiple # QA concerns. # # Removal on 2010-02-12 media-gfx/giram
Re: [gentoo-dev] CAcert certificate distribution license to third parties (i.e. distributors like gentoo)
On 12/13/2009 02:49 PM, Robin H. Johnson wrote: On Sun, Dec 13, 2009 at 10:44:05PM +1100, 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.html That's a pretty dense license. I can see why you had a headache. I believe that in it's current form, we will have to make sure we have a liability disclaimer to users for the license, but that should be about it. First, I am not a lawyer. The 3PV license does require that the user be presented with: http://www.cacert.org/policy/NRPDisclaimerAndLicence.php I'm not sure that simply posting the link in an einfo would satisfy the requirements. We might need to post the full text to qualify as having presented it to the user - not sure about that. I don't see anything in there that requires interaction though (hitting a yes button or anything like that). The license itself is fairly short - we only need to post the NRP and not the 3PV license. The 3PV is a license for Gentoo to distribute content to users under the NRP. Users who don't redistribute the key don't need to worry about it. An option would be to RESTRICT=mirror their root key, and install it directly from their site, assuming they don't start messing with the URL. Then we can just put the license in the ebuild like any other. Since we don't redistribute anything copyrighted, Gentoo itself doesn't enter into any license agreement. Only issue with that is that it is often bundled with a bunch of others and I don't know that you can restrict only one URL in the ebuild.
Re: [gentoo-dev] Heads up: cmake-utils.eclass changes
On 12/13/2009 04:28 PM, Jonathan Callen wrote:
Recently a change was made to cmake-utils.eclass, changing the
mycmakeargs parameter from a flat string to an array. This change was
also made to kde4-{base,meta}.eclass. The primary reason for this
change was to allow parameters passed to cmake to contain spaces (such
as ${S} or ${EPREFIX}). Currently, there is code in these eclasses
to properly convert a string to an array, keeping the previous behavior.
This code works in almost every case *except* if you want to change
mycmakeargs in src_test and call cmake-utils_src_configure again. The
few instances of this in the tree have been fixed to use arrays, as
should all new ebuilds.
The plan is to eventually remove this backwards-compatibility code, once
all usages in the tree have been converted.
The policy has been to not change the API of eclasses because you can
have user written ebuilds in overlays expecting certain behavior.
Regards,
Petteri
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Last rites: =app-crypt/qca-1*, app-crypt/qca-tls
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 # Jonathan Callen a...@gentoo.org (14 Dec 2009) # Old Qt3-only version of qca, unused in tree # Removal on 2010-01-14 =app-crypt/qca-1* app-crypt/qca-tls -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.13 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksmatIACgkQOypDUo0oQOoslQCeKROyiPJbjAUf3apnc7hHtJUp fUsAoKsaZLzUUp4xFm3xoXSuZyMQxhpL =Fpwj -END PGP SIGNATURE-
[gentoo-dev] News item for Paludis kdebuild-1 removal
Since kdebuild-1 is to be removed from PMS immediately, it's going to go from Paludis in the next release too. We need to warn users about this, since they'll no longer be able to uninstall kdebuild-1 packages they have installed. Please review the following GLEP 42 news item for this: Title: Paludis kdebuild-1 Removal Author: Ciaran McCreesh ciaran.mccre...@googlemail.com Content-Type: text/plain Posted: 2009-12-14 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: sys-apps/paludis-0.44_alpha kdebuild-1 was an EAPI used by the Gentoo KDE team and the Genkdesvn project for various live ebuilds in overlays. The Gentoo Council has decided that all mention of the kdebuild-1 EAPI is to be removed from the Package Manager Specification immediately. As such, support for this EAPI, including support for uninstalling packages with that EAPI, will be removed from Paludis in version 0.44. Users should verify that they have no kdebuild-1 packages installed. If Paludis was built with the 'inquisitio' use flag enabled, you can use: $ inquisitio -K installed -k EAPI kdebuild-1 Otherwise, use: $ paludis -q '*/*::/[.EAPI=kdebuild-1]' and, if any such packages are installed, they must be uninstalled before Paludis is upgraded. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] News item for Paludis kdebuild-1 removal
On Mon, Dec 14, 2009 at 07:54:25PM +, Ciaran McCreesh wrote: Since kdebuild-1 is to be removed from PMS immediately, it's going to go from Paludis in the next release too. We need to warn users about this, since they'll no longer be able to uninstall kdebuild-1 packages they have installed. Please review the following GLEP 42 news item for this: Title: Paludis kdebuild-1 Removal Author: Ciaran McCreesh ciaran.mccre...@googlemail.com Content-Type: text/plain Posted: 2009-12-14 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: sys-apps/paludis-0.44_alpha kdebuild-1 was an EAPI used by the Gentoo KDE team and the Genkdesvn project for various live ebuilds in overlays. The Gentoo Council has decided that all mention of the kdebuild-1 EAPI is to be removed from the Package Manager Specification immediately. As such, support for this EAPI, including support for uninstalling packages with that EAPI, will be removed from Paludis in version 0.44. KDEBUILD is no longer in use by any developers, as such paludis will be removing support for it is factually more accurate. Council doesn't care if you leave KDEBUILD support in your PM- considering you've been claiming leaving it in PMS was needed for users (and that one must always think of the users), the wording implying blaim on the council is rather unnecessary. Jam it in your NEWS/RELEASE notes if you want to slant it, basically. Users should verify that they have no kdebuild-1 packages installed. If Paludis was built with the 'inquisitio' use flag enabled, you can use: $ inquisitio -K installed -k EAPI kdebuild-1 Otherwise, use: $ paludis -q '*/*::/[.EAPI=kdebuild-1]' and, if any such packages are installed, they must be uninstalled before Paludis is upgraded. This seems like this news item should be hitting gentoo-kde's overlay on a sidenote- yes, the news item is about paludis, but the folk affected are the ones who daftly used KDEBUILD eapis out of that overlay. Either this, or a seperate NEWS item added to that overlay stating KDEBUILD is dead, remove those merged pkgs would be wise. ~harring pgpP121IrhB7f.pgp Description: PGP signature
Re: [gentoo-dev] News item for Paludis kdebuild-1 removal
On Mon, 14 Dec 2009, Ciaran McCreesh wrote: Please review the following GLEP 42 news item for this: CC p...@gentoo.org please (as GLEP 42 requires). Display-If-Installed: sys-apps/paludis-0.44_alpha I think you should rather list the affected ebuilds here, i.e. the ones that were using EAPI=kdebuild-1. Ulrich
Re: [gentoo-council] Re: [gentoo-dev] News item for Paludis kdebuild-1 removal
On Mon, 14 Dec 2009 22:31:11 +0100 Ulrich Mueller u...@gentoo.org wrote: On Mon, 14 Dec 2009, Ciaran McCreesh wrote: Please review the following GLEP 42 news item for this: CC p...@gentoo.org please (as GLEP 42 requires). Oops. Sent. Display-If-Installed: sys-apps/paludis-0.44_alpha I think you should rather list the affected ebuilds here, i.e. the ones that were using EAPI=kdebuild-1. There's no way to match such packages using EAPI 0 deps (or any other EAPI for that matter). Most of them were scm packages, but not everything or whatever is kdebuild. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: QA last rites for x11-wm/ion
On Sun, 13 Dec 2009 20:46:18 +0100 Diego E. Pettenò flamee...@gmail.com wrote: # Diego E. Pettenò flamee...@gentoo.org (13 Dec 2009) # on behalf of QA team # # Pre-strip files (bug #241534), ignore flags (bug #241556), # misplaces documentation (bug #241560), bump request open # since August 2008 (bug #235888). # # Removal on 2010-02-11 x11-wm/ion Really? Does it not build or something? That's pretty weak. -- fonts,looks like Christmas at 55 degrees gcc-porting, this latitude weakens my knees wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: QA last rites for x11-wm/ion
On Monday 14 December 2009 18:38:36 Ryan Hill wrote: On Sun, 13 Dec 2009 20:46:18 +0100 Diego E. Pettenò wrote: # Diego E. Pettenò flamee...@gentoo.org (13 Dec 2009) # on behalf of QA team # # Pre-strip files (bug #241534), ignore flags (bug #241556), # misplaces documentation (bug #241560), bump request open # since August 2008 (bug #235888). # # Removal on 2010-02-11 x11-wm/ion Really? Does it not build or something? That's pretty weak. yeah, not clean enough doesnt really imply pmask+punt. if it build fails, that's a different story. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] CAcert certificate distribution license to third parties (i.e. distributors like gentoo)
On 12/14/2009 03:10 PM, Robin H. Johnson wrote: 1.4 Vendor's Agreement with End-User Vendor agrees 1. to distribute both the NRP-DaL and this present agreement to end-user, Ah, this was my mistake. I read that as to distribute both the NRP-DaL and present this agreement to [the] end-user, Funny how swapping the order of two words changes an adjective to a verb... :)
