[gentoo-dev] Re: A parting gift
Hi, Jacob Todd : > On Wed, Dec 02, 2009 at 09:15:10AM +0100, Gunnar Wrobel wrote: > > ... I did buy the rights to my book back. > Wait, you don't keep the 'rights' to *your* book when it's published? You sell the publishing rights for a period of time. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: openrc stabilization todo
Hi, Jeremy Olexa : > It makes it hard to triage the openrc bugs when when are on > openrc-0.5.3 and there are openrc-0.2* bugs in the bug tracking > system. Someone really knowing what he is doing is needed here. And with some time. Another thing needed is an init script for wpa_supplicant. > A big change, so prepare a news item? I think Fauli already did this > some time ago. Yes, but I haven't found time and desire to triage the bugs as I intended to. The news item is in the archives of -dev. Some of my todo items like a newer stable eselect are done. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: A parting gift
ons 2009-12-02 klockan 17:55 + skrev Jacob Todd: > On Wed, Dec 02, 2009 at 09:15:10AM +0100, Gunnar Wrobel wrote: > > ... I did buy the rights to my book back. > Wait, you don't keep the 'rights' to *your* book when it's published? > No this is a common thing with books. Remember some time ago in sweden some writers wanted to republish their book, but their current publisher did not want to. Created some spectacle when they did go to another publisher only to find out about this clause in the contract with their first publisher.
[gentoo-dev] Individual developer signing
* "Robin H. Johnson" : > The GLEP on Individual developer signing has not made it into a Draft > yet. > > But you can view the very brief version here: > http://sources.gentoo.org/viewcvs.py/gentoo/users/robbat2/tree-signing-gleps/02-developer-process-security?view=markup [...] > > 2. Every developer signs everything 100% of the time (make it a QA > > check). > +1 on this. In the GLEPs i missed the point where the signatures of Manifests are verified. Only the MetaManifest gets verified. So what's the advantage of individually signed Manifests? The only thing we can check: Is the key used for signing listed in ldap (and thus in "the keyring of automated Gentoo keys")? Are the keys in ldap really mine? Do I miss anything? BTW: About a third of the Manifests are signed [1]. We didn't improve since 2005/2006 [2]. The two parties are working hard against each other [3]. 55 Manifests are signed by revoked keys [4]. [1] http://dev.gentoo.org/~tove/stats/gentoo-x86/Manifest/Manifest.png [2] http://dev.gentoo.org/~tove/stats/gentoo-x86/Manifest/ratio_2005.png [3] http://dev.gentoo.org/~tove/stats/gentoo-x86/Manifest/Manifest2.png [4] http://dev.gentoo.org/~tove/stats/gentoo-x86/Manifest/signatures_by_revoked_keys.txt
Re: [gentoo-dev] Individual developer signing
> BTW: About a third of the Manifests are signed [1]. if we really want to get there, maybe repoman should give a _small_ warning, starting now. i dont sign my commits and have seen how my commits removed signatures of others. i am not proud of it - but given that these are apparently never checked in any way, then no harm is done... or what? Thilo signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] openrc stabilization todo
Le 03/12/2009 02:22, Jeremy Olexa a écrit : Can parallel init script startup be made the default yet? I've been running with it for months and never noticed a problem.. I've been running it for more than a year on half a dozen boxes, without any issues as well. +1 for making it the default. Thanks
Re: [gentoo-dev] Re: openrc stabilization todo
On Thu, Dec 03, 2009 at 09:16:30AM +0100, Christian Faulhammer wrote: > Hi, > > Jeremy Olexa : > > It makes it hard to triage the openrc bugs when when are on > > openrc-0.5.3 and there are openrc-0.2* bugs in the bug tracking > > system. > > Someone really knowing what he is doing is needed here. And with some > time. Well, I have some time, so I'll try to generate a list of bugs to start with and break them down into bugs against openrc itself and bugs against other packages (init scripts, etc) > Another thing needed is an init script for wpa_supplicant. The init script for wpa_supplicant is done, but the maintainer chose not to rev bump. http://bugs.gentoo.org/293443 > > A big change, so prepare a news item? I think Fauli already did this > > some time ago. > > Yes, but I haven't found time and desire to triage the bugs as I > intended to. The news item is in the archives of -dev. Some of my > todo items like a newer stable eselect are done. What other todo items do you have? -- William Hubbs gentoo accessibility team lead willi...@gentoo.org pgpFs6CqxIs9U.pgp Description: PGP signature
[gentoo-dev] Re: openrc stabilization todo
Hi, William Hubbs : > > Yes, but I haven't found time and desire to triage the bugs as I > > intended to. The news item is in the archives of -dev. Some of my > > todo items like a newer stable eselect are done. > > What other todo items do you have? Actually: * Doc updates, http://bugs.gentoo.org/213988 * Deprecated OpenRC http://bugs.gentoo.org/251730 The rest is done. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: qt4-r2.eclass - new eclass for Qt-based apps
On Sunday 29 November 2009 13:46:59 Dominik Kapusta wrote:
> Hello guys!
>
> We, the Qt team, would like to include a new eclass in the tree.
>
> The qt4-r2 eclass is meant to help with ebuilds for Qt-based (qmake-based,
> to be precise) applications.
>
> The eclass is attached, and here's a short comparison between qt4-r2 and
> qt4 (currently in tree) eclasses:
>
> Removed in qt4-r2:
> * obsolete QT4_BUILD_WITH_USE_CHECK and
> QT4_OPTIONAL_BUILD_WITH_USE_CHECK hacks.
>
> Improved in qt4-r2:
> * eqmake4 function now behaves similarly to qmake itself, i.e.:
> - doesn't assume ${PN}.pro, but searches for the project file if not
> specified, just like qmake does
> - in some cases is able to figure out the correct project file if there
> are several of them in one directory (rare case, but technically
> possible)
>
> New in qt4-r2:
> * automatic generation of "linguas_*" IUSE, based on LANGS and LANGSLONG
> variables,
> * automatic installation of documentation, based on DOCS and DOCSDIR
> variables,
> * exported src_configure(), src_compile() and src_install() functions
>
> The qt4-r2 eclass requires EAPI-2.
>
> We have been developing, testing and constantly improving qt4-r2 in
> qting-edge overlay for around a year already. It's working for us and we
> find it very handy compared to the old qt4.eclass.
>
> After pushing qt4-r2 to the tree, we're going to port Qt 4 apps' ebuilds to
> qt4-r2 and deprecate qt4.eclass.
>
>
> Thanks,
> Dominik
>
Hey,
I'm attaching:
* the eclass updated according to suggestion from scarabeus,
* the diff between the first revision and the current one.
Changes include:
* moving EAPI check to the global scope,
* moving documentation around,
* passing parameters to inner functions (inherited from base.eclass).
Please review this one, if there are no objections we'd like to introduce it
to the tree in about two weeks time starting from now.
Thanks a lot,
Dominik
--- qt4-r2.eclass.orig 2009-12-01 23:26:20.0 +0200
+++ qt4-r2.eclass 2009-12-03 20:36:47.0 +0200
@@ -8,39 +8,46 @@
# Markos Chandras ,
# Davide Pesavento ,
# Dominik Kapusta
-# @BLURB: Experimental eclass for Qt4 packages
+# @BLURB: Eclass for Qt4 packages, second edition
# @DESCRIPTION:
# This eclass contains various functions that may be useful when
# dealing with packages using Qt4 libraries. Requires EAPI=2.
+case ${EAPI} in
+ 2) : ;;
+ *) DEPEND="EAPI-INCOMPATIBLE" ;;
+esac
+
inherit base eutils multilib toolchain-funcs
export XDG_CONFIG_HOME="${T}"
-for x in ${LANGSLONG}; do
- IUSE="${IUSE} linguas_${x%_*}"
-done
-
+# @ECLASS-VARIABLE: LANGS
+# @DESCRIPTION:
+# In case your Qt4 application provides various translations, use this variable
+# to specify them in order to populate "linguas_*" IUSE automatically. Make sure
+# that you set this variable BEFORE inheriting qt4-r2 eclass.
+# example: LANGS="en el de"
for x in ${LANGS}; do
IUSE="${IUSE} linguas_${x}"
done
-qt4-r2_pkg_setup() {
- case ${EAPI} in
- 2) ;;
- *)
- eerror
- eerror "The ${ECLASS} eclass requires EAPI=2, but this ebuild does not"
- eerror "have EAPI=2 set. The ebuild author or editor failed. This ebuild needs"
- eerror "to be fixed. Using ${ECLASS} eclass without EAPI=2 will fail."
- eerror
- die "${ECLASS} eclass requires EAPI=2"
- ;;
- esac
-}
+# @ECLASS-VARIABLE: LANGSLONG
+# @DESCRIPTION:
+# Same as above, but this variable is for LINGUAS that must be in long format.
+# Remember to set this variable BEFORE inheriting qt4-r2 eclass.
+# Look at ${PORTDIR}/profiles/desc/linguas.desc for details.
+for x in ${LANGSLONG}; do
+ IUSE="${IUSE} linguas_${x%_*}"
+done
+# @FUNCTION: qt4-r2_src_unpack
+# @DESCRIPTION:
+# Default src_unpack function for packages that depend on qt4. If you have to
+# override src_unpack in your ebuild (probably you don't need to), call
+# qt4-r2_src_unpack in it.
qt4-r2_src_unpack() {
- base_src_unpack
+ debug-print-function $FUNCNAME "$@"
# Fallback to ${WORKDIR}/${MY_P} when ${WORKDIR}/${P} doesn't exist.
# Feel free to re-implement this
@@ -48,6 +55,8 @@
ewarn "Falling back to '${WORKDIR}/${MY_P}'"
S="${WORKDIR}/${MY_P}"
fi
+
+ base_src_unpack "$@"
}
# @ECLASS-VARIABLE: PATCHES
@@ -58,29 +67,6 @@
# PATCHES=( "${FILESDIR}"/mypatch.patch
# "${FILESDIR}"/mypatch2.patch )
#
-# @ECLASS-VARIABLE: LANGS
-# @DESCRIPTION:
-# In case your Qt4 application provides various translations, use this variable
-# to specify them in order to populate "linguas_*" IUSE automatically. Make sure
-# that you set this variable BEFORE inheriting qt4-r2 eclass.
-# example: LANGS="en el de"
-#
-# @ECLASS-VARIABLE: LANGSLONG
-# @DESCRIPTION:
-# Same as above, but this variable is for LINGUAS that must be in long format.
-# Remember to set this variable BEFORE inheriting qt4-r2 eclass.
-# Look at ${PORTDIR}/profiles/desc/linguas.desc for details.
-#
-# @ECLASS-VARIABLE: DOCS
-# @DESCRIPTION:
-# Use this variable if you want to ins
Re: [gentoo-dev] Individual developer signing
On Thu, Dec 03, 2009 at 11:32:42AM +0100, Torsten Veller wrote: > * "Robin H. Johnson" : > > The GLEP on Individual developer signing has not made it into a Draft > > yet. > > > > But you can view the very brief version here: > > http://sources.gentoo.org/viewcvs.py/gentoo/users/robbat2/tree-signing-gleps/02-developer-process-security?view=markup > > [...] > > > > 2. Every developer signs everything 100% of the time (make it a QA > > > check). > > +1 on this. > > In the GLEPs i missed the point where the signatures of Manifests are > verified. > Only the MetaManifest gets verified. GLEP58: under "Procedure for verifying an item in the MetaManifest" 4.2: "M2-verifying the contents of the Manifest." Where "M2-verify" is the verb describing the verification of a Manifest. It _may_ include signature validation. > So what's the advantage of individually signed Manifests? Basically making sure that your SSH keys weren't stolen. They explicitly protect the commit from the developer to infrastructure. MetaManifest protects the integrity of the contents from infrastructure out to the user. It does NOT validate the functionality of the tree or any prior injection. > The only thing we can check: Is the key used for signing listed in ldap > (and thus in "the keyring of automated Gentoo keys")? Are the keys in ldap > really mine? > Do I miss anything? Later on I'd like to REJECT unsigned commits. > BTW: About a third of the Manifests are signed [1]. We didn't improve > since 2005/2006 [2]. The two parties are working hard against each other [3]. > 55 Manifests are signed by revoked keys [4]. > [1] http://dev.gentoo.org/~tove/stats/gentoo-x86/Manifest/Manifest.png > [2] http://dev.gentoo.org/~tove/stats/gentoo-x86/Manifest/ratio_2005.png > [3] http://dev.gentoo.org/~tove/stats/gentoo-x86/Manifest/Manifest2.png > [4] > http://dev.gentoo.org/~tove/stats/gentoo-x86/Manifest/signatures_by_revoked_keys.txt Nice graphs. Can you show them over a larger timespan? -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
Re: [gentoo-dev] openrc stabilization todo
On Thursday 03 of December 2009 15:06:12 Rémi Cardona wrote: > Le 03/12/2009 02:22, Jeremy Olexa a écrit : > > Can parallel init script startup be made the default yet? I've been > > running with it for months and never noticed a problem.. > > I've been running it for more than a year on half a dozen boxes, without > any issues as well. > > +1 for making it the default. -1 from me (at least with <0.5.3, I'm following openrc Gentoo releases closely) *Very* occasionally, bud deadlocks used to happen here. I'll report it for 0.5.3 if I run into this again. -- regards MM
Re: [gentoo-dev] openrc stabilization todo
Joshua Saddler schrieb: > On Thu, 3 Dec 2009 02:44:47 + > Sylvain Alain wrote: >> Hi everyone, I think that the best should be to release a migration guide >> just before the official release and also a news on the first page of >> Gentoo.org > > You really should have checked our doc repo before sending your mail: > > http://www.gentoo.org/doc/en/openrc-migration.xml > > I, Cardoe, and Uberlord wrote it back in April 2008[1]. > > [1] > http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/en/openrc-migration.xml mentioning possible migration issues and pointing at the docs above: (AFAIK the only) documentation handling networking migration states: +-- | ... | Also, /etc/conf.d/net no longer uses bash-style arrays for | configuration. | Please review /usr/share/doc/openrc-/net.example | for configuration instructions. Conversion should be relatively | straight-forward, for example a static IP assignment would change | as follows: | ... +-- (and no - more complex examples are *not* described in /u/s/d/o/net.example as stated..) Apart from that, the newnet file will be /etc/conf.d/network .. Regarding USE=-oldnet migrations, that are actually *using* oldnet Bash arrays within /etc/conf.d/net (like me) are left alone and not even Funtoo has a porting guide.. my $0.02 Christian
RE: [gentoo-dev] openrc stabilization todo
Hi Christian, the guide back in 2008 and it's ok for the OpenRC stuff, but for the network part. maybe we could add some examples from this thread : http://forums.gentoo.org/viewtopic-t-796647-postdays-0-postorder-asc-highlight-openrc-start-0.html my $0.02 Sylvain > Date: Fri, 4 Dec 2009 00:03:52 +0100 > From: christ...@bricart.de > To: gentoo-dev@lists.gentoo.org > Subject: Re: [gentoo-dev] openrc stabilization todo > > Joshua Saddler schrieb: > > On Thu, 3 Dec 2009 02:44:47 + > > Sylvain Alain wrote: > >> Hi everyone, I think that the best should be to release a migration guide > >> just before the official release and also a news on the first page of > >> Gentoo.org > > > > You really should have checked our doc repo before sending your mail: > > > > http://www.gentoo.org/doc/en/openrc-migration.xml > > > > I, Cardoe, and Uberlord wrote it back in April 2008[1]. > > > > [1] > > http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/en/openrc-migration.xml > > mentioning possible migration issues and pointing at the docs above: > > (AFAIK the only) documentation handling networking migration states: > > +-- > | ... > | Also, /etc/conf.d/net no longer uses bash-style arrays for > | configuration. > | Please review /usr/share/doc/openrc-/net.example > | for configuration instructions. Conversion should be relatively > | straight-forward, for example a static IP assignment would change > | as follows: > | ... > +-- > (and no - more complex examples are *not* described > in /u/s/d/o/net.example as stated..) > > Apart from that, the newnet file will be /etc/conf.d/network .. > > Regarding USE=-oldnet migrations, that are actually *using* oldnet Bash > arrays within /etc/conf.d/net (like me) are left alone and not even > Funtoo has a porting guide.. > > my $0.02 > Christian > > > _ Windows Live: Friends get your Flickr, Yelp, and Digg updates when they e-mail you. http://go.microsoft.com/?linkid=9691817
