[gentoo-dev] [PATCH v1] eclass/savedconfig.eclass: rewrite the ROFF macros
man2html cannot cope with multi-character number-register names and also doesn't recognize the square brackets in the '\n' escape sequence. This breaks the autogenerated HTML output. Rename the number-register from "step" to "R" and get rid of the square brackets. Closes: https://bugs.gentoo.org/699476 Signed-off-by: Göktürk Yüksek --- eclass/savedconfig.eclass | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/eclass/savedconfig.eclass b/eclass/savedconfig.eclass index dab2283fe0f..8f64c5b8edd 100644 --- a/eclass/savedconfig.eclass +++ b/eclass/savedconfig.eclass @@ -14,20 +14,20 @@ # so users can modify these config files and the ebuild will take it # into account as needed. # -# @ROFF .nr step 1 1 +# @ROFF .nr R 1 1 # Typically you can create your own configuration files quickly by # doing: -# @ROFF .IP \n[step] 3 +# @ROFF .IP \nR 3 # Build the package with FEATURES=noclean USE=savedconfig. -# @ROFF .IP \n+[step] +# @ROFF .IP \n+R # Go into the build dir and edit the relevant configuration system # (e.g. `make menuconfig` or `nano config-header.h`). You can look # at the files in /etc/portage/savedconfig/ to see what files get # loaded/restored. -# @ROFF .IP \n+[step] +# @ROFF .IP \n+R # Copy the modified configuration files out of the workdir and to # the paths in /etc/portage/savedconfig/. -# @ROFF .IP \n+[step] +# @ROFF .IP \n+R # Emerge the package with just USE=savedconfig to get the custom build. inherit portability -- 2.24.0
Re: [gentoo-dev] RFC: kernel-2.eclass Prefix support
Benda Xu:
> Hi Fellows,
>
> This is a trivial patch for kernel-2.eclass to support Prefix. Does it
> look good to be commited?
>
> Thanks,
> Benda
>
> Bug: 478436
> --- kernel-2.eclass 2016-02-17 22:46:25.235543840 +0900
> +++ kernel-2.eclass 2016-05-24 01:14:22.246809021 +0900
> @@ -539,8 +522,8 @@
> #==
> kernel_header_destdir() {
> [[ ${CTARGET} == ${CHOST} ]] \
> - && echo /usr/include \
> - || echo /usr/${CTARGET}/usr/include
> + && echo "${EPREFIX}"/usr/include \
> + || echo "${EPREFIX}"/usr/${CTARGET}/usr/include
> }
>
> cross_pre_c_headers() {
> @@ -667,7 +650,7 @@
>
> # autoconf.h isnt generated unless it already exists. plus, we
> have
> # no guarantee that any headers are installed on the system...
> - [[ -f ${ROOT}/usr/include/linux/autoconf.h ]] \
> + [[ -f ${EROOT}/usr/include/linux/autoconf.h ]] \
EROOT already ends with a trailing slash.
Also there are inconsistencies in the rest of the patch w.r.t. quoting
EROOT and EPREFIX.
> || touch include/linux/autoconf.h
>
> # if K_DEFCONFIG isn't set, force to "defconfig"
> @@ -741,15 +724,15 @@
> # Do not use "linux/*" as that can cause problems with very long
> # $S values where the cmdline to cp is too long
> pushd "${S}" >/dev/null
> - dodir ${ddir}/linux
> + dodir ${ddir#${EPREFIX}}/linux
> cp -pPR "${S}"/include/linux "${D}"/${ddir}/ || die
> rm -rf "${D}"/${ddir}/linux/modules
>
> - dodir ${ddir}/asm
> - cp -pPR "${S}"/include/asm/* "${D}"/${ddir}/asm
> + dodir ${ddir#${EPREFIX}}/asm
> + cp -pPR "${S}"/include/asm/* "${ED}"/${ddir}/asm
>
> if kernel_is 2 6 ; then
> - dodir ${ddir}/asm-generic
> + dodir ${ddir#${EPREFIX}}/asm-generic
> cp -pPR "${S}"/include/asm-generic/* "${D}"/${ddir}/asm-generic
> fi
>
> @@ -784,7 +767,7 @@
> > "${S}"/patches.txt
> fi
>
> - mv ${WORKDIR}/linux* "${D}"/usr/src
> + mv ${WORKDIR}/linux* "${ED}"/usr/src
>
> if [[ -n "${UNIPATCH_DOCS}" ]] ; then
> for i in ${UNIPATCH_DOCS}; do
> @@ -819,22 +799,22 @@
>
> # if we are to forcably symlink, delete it if it already exists first.
> if [[ ${K_SYMLINK} > 0 ]]; then
> - [[ -h ${ROOT}usr/src/linux ]] && rm ${ROOT}usr/src/linux
> + [[ -h ${EROOT}usr/src/linux ]] && rm ${EROOT}usr/src/linux
> MAKELINK=1
> fi
>
> # if the link doesnt exist, lets create it
> - [[ ! -h ${ROOT}usr/src/linux ]] && MAKELINK=1
> + [[ ! -h ${EROOT}usr/src/linux ]] && MAKELINK=1
>
> if [[ ${MAKELINK} == 1 ]]; then
> - cd "${ROOT}"usr/src
> + cd "${EROOT}"usr/src
> ln -sf linux-${KV_FULL} linux
> cd ${OLDPWD}
> fi
>
> # Don't forget to make directory for sysfs
> - [[ ! -d ${ROOT}sys ]] && kernel_is 2 6 && mkdir ${ROOT}sys
> + [[ ! -d ${EROOT}sys ]] && kernel_is 2 6 && mkdir ${EROOT}sys
>
> echo
> elog "If you are upgrading from a previous kernel, you may be
> interested"
> elog "in the following document:"
> @@ -1353,11 +1310,11 @@
> [[ ${ETYPE} == headers ]] && return 0
>
> # If there isn't anything left behind, then don't complain.
> - [[ -e ${ROOT}usr/src/linux-${KV_FULL} ]] || return 0
> + [[ -e ${EROOT}usr/src/linux-${KV_FULL} ]] || return 0
> echo
> ewarn "Note: Even though you have successfully unmerged "
> ewarn "your kernel package, directories in kernel source location: "
> - ewarn "${ROOT}usr/src/linux-${KV_FULL}"
> + ewarn "${EROOT}usr/src/linux-${KV_FULL}"
> ewarn "with modified files will remain behind. By design, package
> managers"
> ewarn "will not remove these modified files and the directories they
> reside in."
> echo
>
[gentoo-dev] last rites: app-admin/lastpass
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 # Göktürk Yüksek (23 May 2016) # Replaced by app-admin/lastpass-binary-component. # Masked for removal in 30 days. app-admin/lastpass -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJXQpMvAAoJEIT4AuXAiM4zU/oH/iVspOTvdR3g7BZs3enwu9zx hw1mtqD+Zck2rUWmJFDVZTDrhQnyFaeOIJ1dWro2ID7WcEetUHH99Tmro0dxRBMq bW1xmeSBXVd4T5Qi8YcHJn8heywyL7G2eIzvVf76lbjwpJzu3mFIlrpvhzowVHa9 5rCFMVgJAI5i5Hf6kETrH+Qf/ac/MvWqSPmbVWmZWSNuIimBAxkBH2Lydu2Dz073 UsmpNv81g2Sm+3GdQ4+VF/S+5CvBggg/q73Uz+hR6ce6dcK7Pr0p9yt9aiISPX+N BfGtrDeCavOXRb+cVDzk+vsaRqRSiWk4iEAeK7lL2ejkLHQ0dvl8kD+iIgv3jN8= =AaLD -END PGP SIGNATURE-
[gentoo-dev] News Item: LastPass package migration - v2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Here's the version 2 with the fixed author information. I forgot to send the initial email to the PR team, so doing that now. Will commit in 72 hours if there are no objections. - -- Title: LastPass package migration Author: Göktürk Yüksek Author: Robin H. Johnson Content-Type: text/plain Posted: 2016-05-15 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: app-admin/lastpass LastPass-3 and earlier versions installed browser extensions along with the necessary binary components. LastPass-4 and later versions install only the binary components and leave installing the browser extensions to the user. Furthermore, LastPass-3 is not available anymore, it will be removed soon and users are required to upgrade. A transparent package move is not possible due to the mentioned changes and a manual migration is required. The currently installed package must be removed before proceeding with the migration: emerge --unmerge --ask app-admin/lastpass LastPass for Firefox users can safely upgrade to version 4 by visiting the official LastPass website and following the download instructions. The browser extension already contains the required binary components. No packages need to be installed. Users of Chrome/Chromium and Opera browsers need to switch to app-admin/lastpass-binary-features and follow the instructions displayed on the screen after the installation to complete the process. -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJXPpz0AAoJEIT4AuXAiM4zZyMH/RX2ISvUhW4DRE0Ntq+k4CHY Oe7NNvNprEPxECkn1TiD/NsP0jEGjXS5SFA3jvu11c9dalnXtQ/SrBiTOI24NPj4 74/2gDzgJEYvDxIc2USCOxs2QXaB9L08n1MIFu4fACkqSR4wnJrR+ggq6BkMrY/J ga9XIVEOjbA9XfcHplBLZ+1vlcZCB6rYK5i8EyB/Slp6lDw4MZ1M63aF3O2nON8W B7EmZ4EjR7sWjnWnHevvwXJ82xpGlYr4bgJhITJ55s9wbohcavsDyFZTj/GudZDl NUytv8UVPtZp6PWqfBhPpLmts3SQFzhGNunHCm8Gmurcv7paQJgF1MApM9NZ4Fg= =bSjH -END PGP SIGNATURE-
Re: [gentoo-dev] [PATCH] eutils.eclass: Add awk wrapper - eawk - edit file in place
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Mart Raudsepp: > Ühel kenal päeval, K, 18.05.2016 kell 22:25, kirjutas > aide...@gentoo.org: >> From: Amadeusz Żołnowski >> >> awk doesn't have the -i option like sed and if editing file in >> place is desired, additional steps are required. eawk uses tmp >> file to make it look to the caller editing happens in place. --- >> eclass/eutils.eclass | 13 + 1 file changed, 13 >> insertions(+) >> >> diff --git a/eclass/eutils.eclass b/eclass/eutils.eclass index >> dbedffe..e331f1b 100644 --- a/eclass/eutils.eclass +++ >> b/eclass/eutils.eclass @@ -20,6 +20,19 @@ _EUTILS_ECLASS=1 >> >> inherit multilib toolchain-funcs >> >> +# @FUNCTION: eawk +# @USAGE: +# @DESCRIPTION: +# >> Edit file in place with awk. Pass all arguments following >> to +# awk. >> > > I would like if such a function would explicitly document that > calling this function means the caller should DEPEND on an awk > provider. Similarly, I would like that all ebuild that call 'sed' > actually DEPEND on sed, not just half of them. According to PMS, sed is guaranteed to be present[0]. > I would also like that no ebuild would assume packages in @system > to be present, beyond those dictated by PMS (unpackers and such). > Quoting PMS [1]: "[...] in most cases this means that the only packages that can be assumed to be present are those listed in the base profile or equivalent [...]" Implicit system dependencies are documented in devmanual as well. May I ask why you are against it? > Mart > [0] https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-12700011.3.1.1 [1] https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-12600011.3.1 -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJXPkxQAAoJEIT4AuXAiM4zH/gH/2KJIdAbL1x8TfvWIeOnjQ4E IatAXY9DentQgGVFHU+bwOj+bdgMfaU3QACjDAD/GOPYTwrOSlHD2dK7spkou7RS VY3voejyvK1tHASooMvEaaH8VQ9HMe82JDS64YTfxMLFb8FcwJOYde3plVSFPArA UGhNCzEpgMJBkd89lS/BsmtHqS0czuAO+VJdVttMo1EyW8CR1s6ou+FVzymgJM/+ P8Zg6eVIcyJOQqQcnpRbDPvSw2lGNP7BofZjFng578DNz3F1LAtdBFBujNNT3kUW FgbifW7Y53hnx3nYjjBigBp8ERm3HuhDXQiQMNEOsFlfIWKarp4017NC8BmH9i4= =jHCS -END PGP SIGNATURE-
Re: [gentoo-dev] [PATCH] eutils.eclass: Add awk wrapper - eawk - edit file in place
Jeroen Roovers: > On Wed, 18 May 2016 19:31:38 -0400 > Göktürk Yüksek wrote: > >> There could be some performance implications. cat will usually do >> slow, buffered I/O. cp tries to be smarter with allocation, i.e. it >> may take advantage of the btrfs specific clone to do a O(1) copy. > > Really? We're talking about editing streams of usually a couple of > kilobytes and performance is what you're worried about? Because of > not using one particular filesystem maybe? Really? > > I wasn't against the use of redirection, just wondering if there was a reason to prefer that over cp. To me, an extra dup2() in redirection seems useless. You can also argue that an extra syscall() has no visible impact and I wouldn't object. cp should work as efficient as shell redirection and potentially better in some cases. Sure, it won't make a noticeable difference with such small files. > jer >
Re: [gentoo-dev] [PATCH] eutils.eclass: Add awk wrapper - eawk - edit file in place
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Amadeusz Żołnowski:
> Göktürk Yüksek writes:
>>> + cat "${f}" >"${tmpf}" || return 1
>> Why shell redirection with cat instead of cp? both are in
>> coreutils.
>
> I thought cp could overwrite file mode of already existing tmp
> file, but actually it doesn't, so cp can be here as well. Is there
> actual benefit of using cp here?
>
There could be some performance implications. cat will usually do
slow, buffered I/O. cp tries to be smarter with allocation, i.e. it
may take advantage of the btrfs specific clone to do a O(1) copy.
>> Also, wouldn't the absence of 'die' cause silent breakages?
>
> I want to caller decide whether die or not and what error messge
> to give.
>
Maybe that should be part of the documentation. People are more likely
to assume that it will die on its own, I think. Is there a case in
which you would not want to die?
> Cheers,
>
-BEGIN PGP SIGNATURE-
iQEcBAEBCgAGBQJXPPtVAAoJEIT4AuXAiM4zhX4H+gNivSvNvQzf3tsjmbVatGWB
DLIvIxUY7h79c0YDTXnaU+4LLf7CvED26XT9QNWp297OfNpsXKWGTR5GbdG+w0ab
SR490l9Uh/qn8HBKvh1hmPTEyeRHXm0ZoQ6/jrgwlz7ehSawQlzGRUPqFOHj88Fc
qwWhKk1p2fc7TUnRO0SUY/xcRyZeEyUqEG3ueVYfPlTo10rC5+B20IFjnO09vwbT
INV27KHqjLnpRT4xGWvCyCiEfw6DDypxZ/PKfr4c7omHF8OF+5GGnf+FFZ8UJFkt
93TVIPDeUC9XeAsmqirgN5LuYWsNNUwTEdiDfjglLrTb6OgXA0eIIwXsGH/G3d4=
=J3uT
-END PGP SIGNATURE-
Re: [gentoo-dev] [PATCH] eutils.eclass: Add awk wrapper - eawk - edit file in place
aide...@gentoo.org:
> From: Amadeusz Żołnowski
>
> awk doesn't have the -i option like sed and if editing file in place is
> desired, additional steps are required. eawk uses tmp file to make it
> look to the caller editing happens in place.
> ---
> eclass/eutils.eclass | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/eclass/eutils.eclass b/eclass/eutils.eclass
> index dbedffe..e331f1b 100644
> --- a/eclass/eutils.eclass
> +++ b/eclass/eutils.eclass
> @@ -20,6 +20,19 @@ _EUTILS_ECLASS=1
>
> inherit multilib toolchain-funcs
>
> +# @FUNCTION: eawk
> +# @USAGE:
> +# @DESCRIPTION:
> +# Edit file in place with awk. Pass all arguments following to
> +# awk.
> +eawk() {
> + local f="$1"; shift
> + local tmpf="$(emktemp)"
> +
> + cat "${f}" >"${tmpf}" || return 1
Why shell redirection with cat instead of cp? both are in coreutils.
Also, wouldn't the absence of 'die' cause silent breakages?
> + awk "$@" "${tmpf}" >"${f}"
> +}
> +
> # @FUNCTION: eqawarn
> # @USAGE: [message]
> # @DESCRIPTION:
>
Re: [gentoo-dev] [PATCH v2 2/4] ebuild-writing/misc-files/metadata: rewrite the section per GLEP 67 #572144
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Michał Górny: > On Sat, 14 May 2016 20:57:48 -0400 Göktürk Yüksek > wrote: > >> @@ -244,12 +221,7 @@ optional: without this attribute must also >> exist. That tag without the restrict attribute will serve as the >> default. The format of the restrict attribute is that of the >> DEPEND flag, except that "<" and -">" need to be >> specified by < and >. - -For >> example, in the sys-libs/db package, - >> restrict=">=sys-libs/db-3.2.9-r5" on the - >> maintainer tag shows that I'm currently >> maintaining all -versions greater then 3.2.9-r5. +">" >> need to be specified by "<" and ">". >> > > I'm sorry for coming late to the party but could you mention that > it must be an EAPI 0 package dependency? There were more than a > few packages where people put slot- or USE-dependencies there. > The purpose of this change was to remove the example inside the table since I've added a complete example with restrict under the metadata examples section. PATCH 3/4 accomplishes what you ask: +the restrict attribute serves as the default. The format of the +restrict attribute is that of a EAPI=0 package dependency +specification. Due to the limitations of XML, the "<" and -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJXOS8RAAoJEIT4AuXAiM4z21sH+wWVlhYAZpGTIaBJydWWnynI zuF1CmHxb4dlLh9zbwMcMuRavbxYbKsI3P0D2p4h1kNI6a9jZzAAvHF99eTC6o54 +PjwgxroxtTHKrp147Jmubrj+u70EWvj2JGxIprRkS5A0ZW+zE24n37IA/8AtwEL XV24dB1HSs98WkfJbnhYmS6nxyQHz0fiFRM4o1syxtHyu9bS1zXE+fEevqeTOo4i PlqJCgyepvyPdcYeDHVOz7b9MqXy19+GTPFxHzfoHMBWB4/X/6umYE+1n9CRIjeX THhiCZ/6uXVvXJgUcaoLlWE984wbgEzt9j4zp2CJqG0FgyndtCuW9QZrY8gWW4I= =kmMC -END PGP SIGNATURE-
[gentoo-dev] [PATCH] ebuild-writing/variables: add a section to explain the ROOT variable #144332
The text is originally based on the patch provided by Thilo Bangert
in the bug. It is revised and expanded to
mention the use of ROOT in cross-compiling environments as explained
in PMS Table 11.1.
Gentoo-Bug: https://bugs.gentoo.org/144332
Signed-off-by: Göktürk Yüksek
---
ebuild-writing/variables/text.xml | 55 +--
1 file changed, 53 insertions(+), 2 deletions(-)
diff --git a/ebuild-writing/variables/text.xml
b/ebuild-writing/variables/text.xml
index 9027cad..dc152e1 100644
--- a/ebuild-writing/variables/text.xml
+++ b/ebuild-writing/variables/text.xml
@@ -101,8 +101,8 @@ them.
ROOT
The absolute path to the root directory into which the package is to be
- merged. Use this when referring to installed files in pkg_*
- functions. Never use this in src_* functions.
+ merged. Only allowed in pkg_* phases. See
+
@@ -393,6 +393,57 @@ GLEP 23 for details.
+ROOT
+
+
+
+The idea behind ROOT is that one can build a system with
+ROOT=/somewhere and then chroot into it or tar up
+/somewhere as a system image. It is not designed to allow the
+user to run /somewhere/usr/bin/foo.
+
+
+
+Ebuilds may reference ROOT only during pkg_* phases. It
+can't be used correctly in src_* phases, since ROOT may
+be different when merging a binary package. For example, a binary
+package may be built with ROOT=/ and then installed onto a
+system using ROOT=/somewhere.
+
+
+
+When building a package, ROOT should not be used to satisfy the
+required dependencies on libraries, headers files etc. Instead, the
+files on the build system should be specified using /.
+
+
+
+In a cross compiling environment, ebuilds must not call any of the
+binaries inside ROOT since they may not be executable on the
+build system.
+
+
+
+Below is an example of an ebuild that uses ROOT in
+pkg_postinst() to conditionally print an error message if an
+old and obsolete configuration file still exists:
+
+
+pkg_postinst() {
+ if [[ -e "${ROOT}/etc/oldconfig" ]]; then
+ ewarn "You still have the obsolete config file "
+ ewarn "${ROOT}/etc/oldconfig."
+ ewarn "Please migrate your settings to ${ROOT}/etc/newconfig"
+ ewarn "and remove ${ROOT}/etc/oldconfig."
+ fi
+}
+
+
+
+
+
+
+
Version and Name Formatting Issues
--
2.7.3
[gentoo-dev] [PATCH v2 2/4] ebuild-writing/misc-files/metadata: rewrite the section per GLEP 67 #572144
A major rewrite of the section. Here is a brief summary of changes: - Remove the information about the tag per GLEP 67 - Restructure the section in the following order: - metadata.xml syntax - package metadata - metadata examples - maintainer-needed - category metadata - Update the tables for metadata.xml syntax per GLEP 67 - Rewrite the package metadata examples to reflect better on GLEP 67 and enhance with more explanations - Assign meaningful titles to package metadata examples instead of using "First Example", "Second Example" etc. - Add a subsection for handling maintainer-needed in metadata.xml per GLEP 67 and provide an example This commit also makes #545272 obsolete. Gentoo-Bug: https://bugs.gentoo.org/show_bug.cgi?id=572144 Gentoo-Bug: https://bugs.gentoo.org/show_bug.cgi?id=545272 Signed-off-by: Göktürk Yüksek --- ebuild-writing/misc-files/metadata/text.xml | 418 1 file changed, 238 insertions(+), 180 deletions(-) diff --git a/ebuild-writing/misc-files/metadata/text.xml b/ebuild-writing/misc-files/metadata/text.xml index 2324f53..31ec926 100644 --- a/ebuild-writing/misc-files/metadata/text.xml +++ b/ebuild-writing/misc-files/metadata/text.xml @@ -10,16 +10,7 @@ package or category. -Package Metadata - - -For packages, metadata.xml can specify a long description and -maintainer information. If a long description in any language is -provided, an English long description must be present. A typical -example might look like: - - - +Syntax @@ -39,13 +30,10 @@ A metadata.xml file can contain a number of tags: This is the root element of the metadata.xml file for packages. It has no attributes. The following subtags are allowed: -<herd>, <maintainer>, <longdescription>, <use>, and <upstream>. -There should be at least one <herd> or -<maintainer> subtag. @@ -62,26 +50,16 @@ A metadata.xml file can contain a number of tags: -<herd> - - -If a package is maintained by one or more herds, names of these herds -can be specified with the <herd> tag. The names -used in this tag must be the same as specified in the https://sources.gentoo.org/viewcvs.py/*checkout*/gentoo/xml/htdocs/proj/en/metastructure/herds/herds.xml?content-type=text/plain&rev=HEAD";>herds.xml -file. - - - - <maintainer> -Besides being part of a herd, a package can also be maintained directly. -The maintainers of a package can be specified with the -<maintainer> tag. This tag has one required subtag: +This tag specifies the persons and/or projects responsible for +the maintenance of a package. The type attribute must +be specified and can be either "person" or +"project". There is one required subtag: <email>. It has two optional subtags: -<name>, and <description>. +<name> and +<description>. @@ -207,8 +185,7 @@ A metadata.xml file can contain a number of tags: -There are also some attributes that can be used with these tags. They are all -optional: +There are also some attributes that can be used with these tags: @@ -235,7 +212,7 @@ optional: restrict -<herd>, <maintainer>, +<maintainer>, <longdescription>, <flag> @@ -244,12 +221,7 @@ optional: without this attribute must also exist. That tag without the restrict attribute will serve as the default. The format of the restrict attribute is that of the DEPEND flag, except that "<" and -">" need to be specified by < and >. - -For example, in the sys-libs/db package, -restrict=">=sys-libs/db-3.2.9-r5" on the -maintainer tag shows that I'm currently maintaining all -versions greater then 3.2.9-r5. +">" need to be specified by "<" and ">". @@ -282,212 +254,298 @@ optional: <remote-id> -A string identifying the type of upstream source. A list of valid strings are kept in metadata.dtd. +A string identifying the type of upstream source. A list of valid strings are kept in +https://www.gentoo.org/dtd/metadata.dtd";>metadata.dtd. Developers should email the gentoo-dev mailing list before using a new type value. + + type + +<maintainer> + + +Defines the type of the maintainer for a package. There are only +two valid values: "person" and "project". The latter +denotes an official + +Gentoo project. + + - - - - -Metadata Examples - -First Example +Package Metadata - -In this first example we provide you with the metadata.xml for -OpenOffice of which the ebuilds are
[gentoo-dev] [PATCH v2 3/4] ebuild-writing/misc-files/metadata: update wrt slotting and per GLEP 68
Add information about specifying slots and subslots in the metadata. Also, update the section according to the specifications in GLEP 68, clarify some of the tags better, and reorder the tags to improve the flow of the text. Signed-off-by: Göktürk Yüksek --- ebuild-writing/misc-files/metadata/text.xml | 140 ++-- 1 file changed, 93 insertions(+), 47 deletions(-) diff --git a/ebuild-writing/misc-files/metadata/text.xml b/ebuild-writing/misc-files/metadata/text.xml index 31ec926..3d135a6 100644 --- a/ebuild-writing/misc-files/metadata/text.xml +++ b/ebuild-writing/misc-files/metadata/text.xml @@ -14,7 +14,15 @@ package or category. -A metadata.xml file can contain a number of tags: +A metadata file follows the syntax defined in +https://wiki.gentoo.org/wiki/GLEP:68";>GLEP 68. +The character set must be UTF-8 as specified by +https://wiki.gentoo.org/wiki/GLEP:31";>GLEP 31. + + + +The following table summarizes the tags that may appear in a +metadata.xml: @@ -24,28 +32,41 @@ A metadata.xml file can contain a number of tags: +<catmetadata> + + +This is the root element of the metadata.xml file for +categories. It has no attributes. It contains a number of +<longdescription> tags, each for a different +language. + + + + <pkgmetadata> This is the root element of the metadata.xml file for packages. It has no attributes. The following subtags are allowed: -<maintainer>, <longdescription>, +<maintainer>, +<slots>, <use>, and <upstream>. +While all the subtags are optional, <upstream> may +appear at most once. + <longdescription> -<catmetadata> - - -This is the root element of the metadata.xml file for -categories as per https://wiki.gentoo.org/wiki/GLEP:34";>GLEP 34. -It has no attributes. It contains a number of -<longdescription> tags, each for a different -language. +This tag contains a description for a category or a package. For +packages, it is used to augment the + +DESCRIPTION field in the ebuilds themselves. This tag has +two optional subtags: <pkg> and +<cat>. @@ -83,11 +104,25 @@ A metadata.xml file can contain a number of tags: - <longdescription> + <slots> + +This tag describes the +slots of a package. +It has two optional subtags: <slot> and <subslots>. + + + + <slot> + +This contains information for a particular slot. The name +attribute is mandatory and specifies the name of the slot. + + + + <subslots> -This tag contains a description of the package. This is to augment the -DESCRIPTION field in the ebuilds themselves. This tag has two optional -subtags: <pkg> and <cat>. +Describes the meaning of subslots for the whole package. This +tag may appear at most once. @@ -113,25 +148,30 @@ A metadata.xml file can contain a number of tags: <upstream> This tag contains information about the upstream developers/project. +It supports multiple optional subtags: <maintainer>, +<changelog>, <doc>, <bugs-to>, +and <remote-id>. <maintainer> -Name and e-mail of an upstream maintainer. May appear more than once. +Provides information about the upstream maintainer. It requires a +<name> subtag to be specified, supports an optional +<email> subtag and an optional status attribute. - <email> + <name> -The email address of an upstream may appear only once and must appear in first place. +The name of an upstream maintainer should contain a block of text with upstream's name. +This element is mandatory for an upstream maintainer and must appear exactly once. - <name> + <email> -The name of an upstream maintainer should contain a block of text with upstream's name. -This element is mandatory for an upstream maintainer and must appear only once. +The email address of an upstream maintainer. May appear only once. @@ -141,7 +181,7 @@ A metadata.xml file can contain a number of tags: The URL must be version independent and must point to a changelog which is only updated on new releases of the corresponding package. (This also implies that one can link to an automatically updated changelog in case of vcs snapshots -only.) +only). May appear at most once. @@ -151,14 +191,14 @@ A metadata.xml file can contain a number of tags: found. The link must not point to any third party documentation and must be version independent. If the documentation is available in more than one language, a lang attribute can be used which follows th
[gentoo-dev] [PATCH v2 4/4] ebuild-writing/misc-files/metadata: add an example for slots and subslots
Signed-off-by: Göktürk Yüksek --- ebuild-writing/misc-files/metadata/text.xml | 50 + 1 file changed, 50 insertions(+) diff --git a/ebuild-writing/misc-files/metadata/text.xml b/ebuild-writing/misc-files/metadata/text.xml index 3d135a6..486af11 100644 --- a/ebuild-writing/misc-files/metadata/text.xml +++ b/ebuild-writing/misc-files/metadata/text.xml @@ -549,6 +549,56 @@ is demonstrated. + +Slots and Subslots + + + +The main focus of this example is to demonstrate how slots and +subslots are specified, by examining the metadata of +media-libs/libpng. There may be multiple reasons for +slotting depending on the nature of the package. For this particular +package, it can be seen that the slots are used to provide different +versions of the library with varying binary compatibility and that +developers are advised to build against the slot 0. Furthermore, +different versions of this package with the same subslot provide the +same Application Binary Interface (ABI), according to the description +specified in the <subslots> tag. + + + +<?xml version="1.0" encoding="UTF-8"?> +<!DOCTYPE pkgmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd">; +<pkgmetadata> + <maintainer type="project"> +<email>base-sys...@gentoo.org</email> +<name>Gentoo Base System</name> + </maintainer> + <use> +<flag name="apng">support unofficial APNG (Animated PNG) spec</flag> + </use> + <upstream> +<remote-id type="cpe">cpe:/a:libpng:libpng</remote-id> +<remote-id type="sourceforge">apng</remote-id> + </upstream> + <slots> +<slot name="0"> + For building against. This is the only slot + that provides headers and command line tools. +</slot> +<slot name="1.2"> + For binary compatibility, provides libpng12.so.0 only. +</slot> +<slot name="1.5"> + For binary compatibility, provides libpng15.so.15 only. +</slot> +<subslots>Reflect ABI compatibility for libpng.so.</subslots> + </slots> +</pkgmetadata> + + + + -- 2.7.3
[gentoo-dev] [PATCH v2 1/4] general-concepts/herds-and-projects: update per GLEP 67 #572144 #549490
The changes are: - Rename the title to "Projects and Herds" to put the emphasis on projects - Explain projects and subprojects in a new "Projects" section - Add a subsection for starting new projects - Add a subsection for joining/leaving a project - Put a warning label at the beginning of the "Herds" section, declare it obsolete, and preserve it for historical reasons Gentoo-Bug: https://bugs.gentoo.org/show_bug.cgi?id=572144 Gentoo-Bug: https://bugs.gentoo.org/show_bug.cgi?id=549490 Signed-off-by: Göktürk Yüksek --- general-concepts/herds-and-projects/text.xml | 101 ++- 1 file changed, 100 insertions(+), 1 deletion(-) diff --git a/general-concepts/herds-and-projects/text.xml b/general-concepts/herds-and-projects/text.xml index e030150..81b1885 100644 --- a/general-concepts/herds-and-projects/text.xml +++ b/general-concepts/herds-and-projects/text.xml @@ -1,10 +1,106 @@ -Herds and Projects +Projects and Herds + +Projects + + + +The management structure of Gentoo, called the "metastructure", is +defined in +https://wiki.gentoo.org/wiki/GLEP:39#Specification";> +GLEP 39. In Gentoo, a project is a group of developers working +towards a common goal in various different areas. For example, the +https://wiki.gentoo.org/wiki/Project:Devmanual";> +Devmanual project focuses on maintaining this document. Many +others are responsible for maintaining packages. Projects spanning a +large area of topics can have multiple subprojects specializing in +particular fields within the domain of the parent project and thus +form a project hierarchy. + + + +A package maintained by a project needs to have the +project explicitly listed as a maintainer in its +metadata.xml. +The full listing of all the projects can be found on +https://api.gentoo.org/metastructure/projects.xml";> +api.gentoo.org or on the +https://wiki.gentoo.org/wiki/Project:Gentoo";>wiki. + + + +Starting New Projects + + + +According to the metastructure any developer may create a new +project. There are two procedures involved in starting a new project: + + + +Create a new project page https://wiki.gentoo.org/wiki/Gentoo_Wiki:Developer_Central/Project_pages";> +through the wiki. + + +Post a Request For Comments (RFC) email to the gentoo-dev +mailing list. + + + +There is no approval required for the RFC and negative comments do not +block a developer from creating a project. Competing projects are +allowed to co-exist in Gentoo; existence of another project with +similar goals do not block another developer from starting a new +project with the same goals. + + + + + +Joining and Leaving a Project + + + +Members of a project are managed through the project's page on the +Gentoo Wiki. Each page has a "Project" template in its source which +lists the members of the project. Simply modifying the list is +sufficient for adding or removing a developer. Note that different +projects have different requirements and procedures for recruiting +developers, which may require prior arrangements to be made before +modifying the member list. + + + +Developers should remember to add themselves to the alias by editing +/var/mail/alias/misc/<alias name> on +dev.gentoo.org. For example, the alias for the Devmanual project is +located at /var/mail/alias/misc/devmanual, which corresponds to +the project's email address devman...@gentoo.org. + + + + + + + + + +Herds + + + +Herds have been declared obsolete as per the Gentoo Council's https://projects.gentoo.org/council/meeting-logs/20160110-summary.txt";> +decision on January 10, 2016. The following section is preserved +for historical purposes. + + A herd is a collection of packages with an associated set of maintainers. It can happen for example because of retirement that a herd has no developers @@ -27,6 +123,9 @@ as the silo bootloader). This is not always the case. + + + -- 2.7.3
[gentoo-dev] [PATCH v2 0/4] devmanual: update the docs per GLEP 67 and 68
This is the second iteration of the GLEP 67 and GLEP 68 combined changeset. It also adds documentation about slotting in metadata.xml. The changes compared to the previous iteration are: - GLEP 34 reference removed as suggested by ulm - The proper term "slot dependency specifier" is used instead of "slot operator" as suggested by ulm - Clarified that may appear at most once - Clarified that may appear at most once - Clarified that may appear at most once - Minor cosmetic fixes The previous iteration of the changeset can be found here: https://archives.gentoo.org/gentoo-dev/message/54918d35b9ffe3751abd45e48dbb3da0 You can review the changes on Github for your own convenience: https://github.com/gktrk/devmanual.gentoo.org/compare/master...gktrk:glep67_68-v2 The HTML version of the devmanual with the proposed changes can be found at: http://devmanual.qui-gon.org/ Göktürk Yüksek (4): general-concepts/herds-and-projects: update per GLEP 67 #572144 #549490 ebuild-writing/misc-files/metadata: rewrite the section per GLEP 67 #572144 ebuild-writing/misc-files/metadata: update wrt slotting and per GLEP 68 ebuild-writing/misc-files/metadata: add an example for slots and subslots ebuild-writing/misc-files/metadata/text.xml | 588 +-- general-concepts/herds-and-projects/text.xml | 101 - 2 files changed, 471 insertions(+), 218 deletions(-) -- 2.7.3
Re: [gentoo-dev] [PATCH] ebuild-writing/variables: better describe ROOT
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Mike Gilbert:
> The current description of ROOT makes no sense and just confuses
> people. The new description is paraphrased from PMS. ---
> ebuild-writing/variables/text.xml | 5 +++-- 1 file changed, 3
> insertions(+), 2 deletions(-)
>
> diff --git a/ebuild-writing/variables/text.xml
> b/ebuild-writing/variables/text.xml index ef15347..6ba6379 100644
> --- a/ebuild-writing/variables/text.xml +++
> b/ebuild-writing/variables/text.xml @@ -100,8 +100,9 @@ them.
> ROOT - Path to the root directory. When
> not using ${D}, - always prepend ${ROOT} to the
> path. + The absolute path to the root directory into which the
> package is to be merged. + Use this when refering to installed
> files in pkg_* functions. + Never use this in
> src_* functions.
>
Sorry for the late reply. There is actually a bug for this issue [0].
I'll rebase the patch attached to the bug on top of yours if you have
no technical objections to the content.
[0] https://bugs.gentoo.org/show_bug.cgi?id=144332
-BEGIN PGP SIGNATURE-
iQEcBAEBCgAGBQJXN5oEAAoJEIT4AuXAiM4zCBoIAJb45hK2TtB4CpPMDC474XBc
sLk7H+2dDf4mFIkpqr6sTQlW4p/B+qNf/ov/RPC6/Rq3paDNsM9vZYa793pnVk0N
VjJo7iUA5Nmyv7mvgurMNFuiM5VjE3+64QGyTdw5Z9bBDYkWdK4bklZT1lCfIgcQ
OPpuLmuv80QpqUPyEqViqrmLaX9ajogGzeRlUxqUZJtNypNNJxSJ6xtUoLv/aEu5
htixSAMgUl25f+Xz6VY8GY/bhChx6gnEnzMolWQTJqiwfNgYCiRKLtZhAi0AkUwt
37xkVmjM48j9c0x5Dd5Wdk/nNKECatP0FthXcbzzHcNv46XXa9cNre6+8OcVzKc=
=fyKs
-END PGP SIGNATURE-
Re: [gentoo-dev] News Item: LastPass package migration
Andrew Udvare: > On 08/05/16 16:56, Andrew Udvare wrote: >> On 07/05/16 22:25, Göktürk Yüksek wrote: >>> Users of Chrome/Chromium and Opera browsers need to switch to >>> app-admin/lastpass-binary-features and follow the instructions >>> displayed on the screen after the installation to complete the process. >>> >> For Chromium, is there supposed to be a plugin listed in >> chrome://plugins after installation? Supposedly I enabled native >> messaging for the plugin but nothing for LastPass is listed at >> chrome://plugins. >> >> Andrew >> > Actually I think I got it. Once you do everything correctly, and you go to > > chrome://extensions/?options=hdokiejnpimakedhajhdlcegeplioahd (LastPass > extension options) > > under 'Advanced', you will not see a link to install the binary > component anymore. > Right. You can find the list by listing the contents of '/etc/chromium/native-messaging-hosts/'. For LastPass, we install a file named 'com.lastpass.nplastpass.json' that defines which extensions are allowed to talk to the binary component. > Andrew > -- gokturk
[gentoo-dev] Re: [PATCH v1 4/5] ebuild-writing/misc-files/metadata: move the GLEP 31 reference to the top
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Ulrich Mueller: >>>>>> On Mon, 2 May 2016, Göktürk Yüksek wrote: > >> @@ -602,9 +603,7 @@ part of the QA reports. For categories, >> metadata.xml specifies a long description (in English and >> optionally in other languages). The format is specified formally >> in https://wiki.gentoo.org/wiki/GLEP:34";> -GLEP >> 34, and the character set must be UTF-8 as specified >> -by https://wiki.gentoo.org/wiki/GLEP:31";>GLEP >> -31. A typical example: +GLEP 34. A typical example: > > The reference to GLEP 34 should be replaced by GLEP 68 which > supersedes it. > I'll remove the reference altogether since GLEP 68 is mentioned at the beginning of the Syntax section and the table clearly lists in there. > Ulrich > -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJXL1ulAAoJEIT4AuXAiM4zeeUH/jrBuiIKDveFMtKwa55RD7Z9 o4JixDmN1vIU2nHppjAaJE8O8IhSTKStt2fWrpQoUsTlCRYrjVjcD9SUuF4hpdCN hFoLizYXaPc1rAnPOciwLeJuvPutFZfi6/pwWJcZ1u3yJwa+A5hyVCpye4c1fiJ0 QtZSGRhrfVHmhKkprXIwwKRefjh7X8HwGCJS/VyVGYLonfgd8hPWJLRD2iEQOEHG 2JQCYQqGwPPQogLy9E0WmzUPCBt8j/Ifh29y9tpz92FjfEpwFkLa4a2TkbgictPG r0u6xMk5MbgRZtoywUQVUC0+i8ryTidR4AVw3kgfsfmfN2hMR8FY8hPKl5oO8AU= =41M0 -END PGP SIGNATURE-
[gentoo-dev] Re: [PATCH v1 5/5] ebuild-writing/misc-files/metadata: add an example for slots and subslots
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, Ulrich Mueller: >>>>>> On Mon, 2 May 2016, Göktürk Yüksek wrote: > >> -descriptions. Slot operators are not allowed inside >> <pkg>, +descriptions. Slot operators are not preferred >> inside <pkg>, > > A "slot operator" (like :* or :=) is not what is meant here, but a > "slot dependency". These terms are defined in PMS: > https://projects.gentoo.org/pms/6/pms.html#x1-860008.2.6.3 > Thanks for the clarification in terminology, I'll update accordingly. > Also I think that the previous wording was more accurate here. Slot > dependencies are not allowed inside . > Thanks for pointing out. I was a bit confused when I first read in the GLEP: "it is recommended to move the slot specifiers out of element." The specification clearly says "must contain a valid qualified package name" however. Will revert back to the original. > Ulrich > -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJXL1s/AAoJEIT4AuXAiM4z6eEIAOey+sMcvU58U+NTmJjS9RpB cAkvLLCGOOda3jr9Aceoa1eFX6rSAume7TbT3XfjrywgHoApmUVJPkBtAl+a4WK/ ll+BZ2uk9Ao5mqqX2S93UappSUqrbEMqQXFwT9YBoRM/2w1Tcd4YVcyuUaQXkwOM wvhCTgX6kKn+9GXNKkO2lf1KL7xBVyHS/WpMvrEaClH91exllPEGHM1k9Rj2Fd0C yDCLICQ+UW5KkKEVc/E6drVYmtmW1YR7jL2sMXQmHfbPS/8F1egg6bk1hNSHWxNh sH/1gizrRN+ofIrTYic0G4z8Np/vCNcS6OwGaS/Rz8klGc9tzQEyhoUXPTISMxQ= =iKO+ -END PGP SIGNATURE-
[gentoo-dev] News Item: LastPass package migration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Title: LastPass package migration Author: Robin H. Johnson Content-Type: text/plain Posted: 2016-05-08 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: app-admin/lastpass LastPass-3 and earlier versions installed browser extensions along with the necessary binary components. LastPass-4 and later versions install only the binary components and leave installing the browser extensions to the user. Furthermore, LastPass-3 is not available anymore, it will be removed soon and users are required to upgrade. A transparent package move is not possible due to the mentioned changes and a manual migration is required. The currently installed package must be removed before proceeding with the migration: emerge --unmerge --ask app-admin/lastpass LastPass for Firefox users can safely upgrade to version 4 by visiting the official LastPass website and following the download instructions. The browser extension already contains the required binary components. No packages need to be installed. Users of Chrome/Chromium and Opera browsers need to switch to app-admin/lastpass-binary-features and follow the instructions displayed on the screen after the installation to complete the process. -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJXLs3gAAoJEIT4AuXAiM4z/iEIAJruR3u6HFEZHbSBofYc8N6M 2eMvqdU7qlP9Ye9RSNGh58KLcHJR1EdnsxNcfgVCYJTx2FLJJJ8pNYLg2S9gVzY9 lqTJKaGELrJlC2aRy2nBx9/e0Jyy20uA+mUV4kl/jsspxriQs3eJP8vaIvF4fyQR 5Pnzet0FlSaO0z8GdCf22nlY5KsrtMFV+83Sgp+/UqBa0tPU53166+eZ06wAwuyZ K7kMEb7hsFBMichPzrxeadYqvBJoWxpDooBRkolQI3rEt7VYhkTMI6StlZlytkJ0 aTZiZrHmZt57TlHrzU/bOHzhaw/itqUFqoUaLA1MUrbleS9ID1lgGk5FCghgBXw= =cI1z -END PGP SIGNATURE-
Re: [gentoo-dev] [PATCH] metadata.xsd: upstream maintainer must have exactly one element
Dirkjan Ochtman: > On Fri, May 6, 2016 at 1:16 AM, Göktürk Yüksek wrote: >> Signed-off-by: Göktürk Yüksek >> --- >> metadata.xsd | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/metadata.xsd b/metadata.xsd >> index 8bc6a4e..fe2c5d2 100644 >> --- a/metadata.xsd >> +++ b/metadata.xsd >> @@ -137,7 +137,7 @@ >> > minOccurs='0'/> >> > - minOccurs='0'/> >> + minOccurs='1'/> >> >> > type='upstreamMaintainerStatusAttrType' >> default='unknown'/> > > IMO this patch could do with a bit more rationale. Personally, I don't > like this change, as it seems enough in many cases to just add an > email address for an upstream maintainer (for example, maybe the > upstream maintainer is a mailing list?). > The change only reflects what's already in GLEP 68 [0] which itself derives this condition from GLEP 46 [1] which has the following clause: """ name should contain a block of text with upstream's name, is mandatory and can only appear once. """ It has been this way since ~2008 according to the GLEP bug [2]. > Cheers, > > Dirkjan > [0] https://wiki.gentoo.org/wiki/GLEP:68#Upstream_maintainer_descriptions [1] https://wiki.gentoo.org/wiki/GLEP:46 [2] https://bugs.gentoo.org/show_bug.cgi?id=234730 -- gokturk
[gentoo-dev] [PATCH] metadata.xsd: upstream maintainer must have exactly one element
Signed-off-by: Göktürk Yüksek --- metadata.xsd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/metadata.xsd b/metadata.xsd index 8bc6a4e..fe2c5d2 100644 --- a/metadata.xsd +++ b/metadata.xsd @@ -137,7 +137,7 @@ + minOccurs='1'/> -- 2.7.3
[gentoo-dev] [PATCH v1 3/5] ebuild-writing/misc-files/metadata: update wrt slotting and per GLEP 68
Add information about specifying slots and subslots in the metadata. Also, update the section according to the specifications in GLEP 68, clarify some of the tags better, and reorder the tags to improve the flow of the text. Signed-off-by: Göktürk Yüksek --- ebuild-writing/misc-files/metadata/text.xml | 120 +++- 1 file changed, 83 insertions(+), 37 deletions(-) diff --git a/ebuild-writing/misc-files/metadata/text.xml b/ebuild-writing/misc-files/metadata/text.xml index 1d26ede..12a9dc1 100644 --- a/ebuild-writing/misc-files/metadata/text.xml +++ b/ebuild-writing/misc-files/metadata/text.xml @@ -14,7 +14,14 @@ package or category. -A metadata.xml file can contain a number of tags: +A metadata file follows the syntax defined in +https://wiki.gentoo.org/wiki/GLEP:68";> +GLEP 68. + + + +The following table summarizes the tags that may appear in a +metadata.xml: @@ -24,28 +31,37 @@ A metadata.xml file can contain a number of tags: +<catmetadata> + + +This is the root element of the metadata.xml file for +categories. It has no attributes. It contains a number of +<longdescription> tags, each for a different +language. + + + + <pkgmetadata> This is the root element of the metadata.xml file for packages. It has no attributes. The following subtags are allowed: -<maintainer>, <longdescription>, +<maintainer>, +<slots>, <use>, and <upstream>. + <longdescription> -<catmetadata> - - -This is the root element of the metadata.xml file for -categories as per https://wiki.gentoo.org/wiki/GLEP:34";>GLEP 34. -It has no attributes. It contains a number of -<longdescription> tags, each for a different -language. +This tag contains a description for a category or a package. For +packages, it is used to augment the DESCRIPTION field in the +ebuilds themselves. This tag has two optional subtags: +<pkg> and <cat>. @@ -84,11 +100,25 @@ A metadata.xml file can contain a number of tags: - <longdescription> + <slots> + +This optional tag describes the +slots of a package. +It has two optional subtags: <slot> and <subslots>. + + + + <slot> + +This contains information for a particular slot. The name +attribute is mandatory and specifies the name of the slot. + + + + <subslots> -This tag contains a description of the package. This is to augment the -DESCRIPTION field in the ebuilds themselves. This tag has two optional -subtags: <pkg> and <cat>. +Describes the meaning of subslots for the whole package. This +tag may appear only once. @@ -114,25 +144,31 @@ A metadata.xml file can contain a number of tags: <upstream> This tag contains information about the upstream developers/project. +It supports multiple subtags: <maintainer>, +<changelog>, <doc>, <bugs-to>, +and <remote-id>. <maintainer> -Name and e-mail of an upstream maintainer. May appear more than once. +Provides information about the upstream maintainer. May appear +more than once. It requires a <name> subtag to be +specified, supports an optional <email> subtag and +an optional status attribute. - <email> + <name> -The email address of an upstream may appear only once and must appear in first place. +The name of an upstream maintainer should contain a block of text with upstream's name. +This element is mandatory for an upstream maintainer and must appear only once. - <name> + <email> -The name of an upstream maintainer should contain a block of text with upstream's name. -This element is mandatory for an upstream maintainer and must appear only once. +The email address of an upstream maintainer. May appear only once. @@ -159,7 +195,7 @@ A metadata.xml file can contain a number of tags: <bugs-to> Should contain a place where bugs can be filed, a URL or an e-mail address prefixed -with mailto:. +with mailto:. @@ -168,12 +204,14 @@ A metadata.xml file can contain a number of tags: Should specify a type of package identification tracker and the identification that corresponds to the package in question. remote-id should make it easier to index information such as its Freshmeat ID or its CPAN name. +It has a mandatory attribute type which identifies the type +of upstream source. <pkg> -This tag contains a valid package name in the format of a DEPEND. +This tag contains a valid qualified package name. @@ -199,6 +237,7 @@ There are also some attrib
[gentoo-dev] [PATCH v1 1/5] general-concepts/herds-and-projects: update per GLEP 67 #572144 #549490
The changes are: - Rename the title to "Projects and Herds" to put the emphasis on projects - Explain projects and subprojects in a new "Projects" section - Add a subsection for starting new projects - Add a subsection for joining/leaving a project - Put a warning label at the beginning of the "Herds" section, declare it obsolete, and preserve it for historical reasons Gentoo-Bug: https://bugs.gentoo.org/show_bug.cgi?id=572144 Gentoo-Bug: https://bugs.gentoo.org/show_bug.cgi?id=549490 Signed-off-by: Göktürk Yüksek --- general-concepts/herds-and-projects/text.xml | 101 ++- 1 file changed, 100 insertions(+), 1 deletion(-) diff --git a/general-concepts/herds-and-projects/text.xml b/general-concepts/herds-and-projects/text.xml index e030150..e05cb81 100644 --- a/general-concepts/herds-and-projects/text.xml +++ b/general-concepts/herds-and-projects/text.xml @@ -1,10 +1,106 @@ -Herds and Projects +Projects and Herds + +Projects + + + +The management structure of Gentoo, called the "metastructure", is +defined in +https://wiki.gentoo.org/wiki/GLEP:39#Specification";> +GLEP 39. In Gentoo, a project is a group of developers working +towards a common goal in various different areas. For example, the +https://wiki.gentoo.org/wiki/Project:Devmanual";> +Devmanual project focuses on maintaining this document. Many +others are responsible for maintaining packages. Projects spanning a +large area of topics can have multiple subprojects specializing in +particular fields within the domain of the parent project and thus +form a project hierarchy. + + + +A package maintained by a project needs to have the +project explicitly listed as a maintainer in its +metadata.xml. +The full listing of all the projects can be found on +https://api.gentoo.org/metastructure/projects.xml";> +api.gentoo.org or on the +https://wiki.gentoo.org/wiki/Project:Gentoo";>wiki. + + + +Starting New Projects + + + +According to the metastructure any developer may create a new +project. There are two procedures involved in starting a new project: + + + +Create a new project page https://wiki.gentoo.org/wiki/Gentoo_Wiki:Developer_Central/Project_pages";> +through the wiki. + + +Post a Request For Comments (RFC) email to the gentoo-dev +mailing list. + + + +There is no approval required for the RFC and negative comments do not +block a developer from creating a project. Competing projects are +allowed to co-exist in Gentoo; existence of another project with +similar goals do not block another developer from starting a new +project with the same goals. + + + + + +Joining and Leaving a Project + + + +Members of a project are managed through the project's page on the +Gentoo Wiki. Each page has a "Project" template in its source which +lists the members of the project. Simply modifying the list is +sufficient for adding or removing a developer. Note that different +projects have different requirements and procedures for recruiting +developers, which may require prior arrangements to be made before +modifying the member list. + + + +Developers should remember to add themselves to the alias by editing +/var/mail/alias/misc/<alias name> on +dev.gentoo.org. For example, the alias for the Devmanual project is +located at /var/mail/alias/misc/devmanual, which corresponds to +the project email address devman...@gentoo.org. + + + + + + + + + +Herds + + + +Herds have been declared obsolete as per the Gentoo Council's https://projects.gentoo.org/council/meeting-logs/20160110-summary.txt";> +decision on January 10, 2016. The following section is preserved +for historical purposes. + + A herd is a collection of packages with an associated set of maintainers. It can happen for example because of retirement that a herd has no developers @@ -27,6 +123,9 @@ as the silo bootloader). This is not always the case. + + + -- 2.7.3
[gentoo-dev] [PATCH v1 5/5] ebuild-writing/misc-files/metadata: add an example for slots and subslots
Signed-off-by: Göktürk Yüksek --- ebuild-writing/misc-files/metadata/text.xml | 52 - 1 file changed, 51 insertions(+), 1 deletion(-) diff --git a/ebuild-writing/misc-files/metadata/text.xml b/ebuild-writing/misc-files/metadata/text.xml index a0946e8..66da375 100644 --- a/ebuild-writing/misc-files/metadata/text.xml +++ b/ebuild-writing/misc-files/metadata/text.xml @@ -494,7 +494,7 @@ project. Note the use of ">" as opposed to ">" in The example also uses the <pkg> tag in USE flag -descriptions. Slot operators are not allowed inside <pkg>, +descriptions. Slot operators are not preferred inside <pkg>, therefore the notation <pkg>sys-boot/grub</pkg>:2 is adopted as opposed to <pkg>sys-boot/grub:2</pkg>. @@ -547,6 +547,56 @@ is demonstrated. + +Slots and Subslots + + + +The main focus of this example is to demonstrate how slots and +subslots are specified, by examining the metadata of +media-libs/libpng. There may be multiple reasons for +slotting depending on the nature of the package. For this particular +package, it can be seen that the slots are used to provide different +versions of the library with varying binary compatibility and that +developers are advised to build against the slot 0. Furthermore, +different versions of this package with the same subslot provide the +same Application Binary Interface (ABI), according to the description +specified in the <subslots> tag. + + + +<?xml version="1.0" encoding="UTF-8"?> +<!DOCTYPE pkgmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd">; +<pkgmetadata> + <maintainer type="project"> +<email>base-sys...@gentoo.org</email> +<name>Gentoo Base System</name> + </maintainer> + <use> +<flag name="apng">support unofficial APNG (Animated PNG) spec</flag> + </use> + <upstream> +<remote-id type="cpe">cpe:/a:libpng:libpng</remote-id> +<remote-id type="sourceforge">apng</remote-id> + </upstream> + <slots> +<slot name="0"> + For building against. This is the only slot + that provides headers and command line tools. +</slot> +<slot name="1.2"> + For binary compatibility, provides libpng12.so.0 only. +</slot> +<slot name="1.5"> + For binary compatibility, provides libpng15.so.15 only. +</slot> +<subslots>Reflect ABI compatibility for libpng.so.</subslots> + </slots> +</pkgmetadata> + + + + -- 2.7.3
[gentoo-dev] [PATCH v1 4/5] ebuild-writing/misc-files/metadata: move the GLEP 31 reference to the top
GLEP 31 applies to both package and category metadata. Instead of referencing it in the "Category Metadata" subsection, reference it at the beginning of the section. Signed-off-by: Göktürk Yüksek --- ebuild-writing/misc-files/metadata/text.xml | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/ebuild-writing/misc-files/metadata/text.xml b/ebuild-writing/misc-files/metadata/text.xml index 12a9dc1..a0946e8 100644 --- a/ebuild-writing/misc-files/metadata/text.xml +++ b/ebuild-writing/misc-files/metadata/text.xml @@ -16,7 +16,8 @@ package or category. A metadata file follows the syntax defined in https://wiki.gentoo.org/wiki/GLEP:68";> -GLEP 68. +GLEP 68. The character set must be UTF-8 as specified by +https://wiki.gentoo.org/wiki/GLEP:31";>GLEP 31. @@ -602,9 +603,7 @@ part of the QA reports. For categories, metadata.xml specifies a long description (in English and optionally in other languages). The format is specified formally in https://wiki.gentoo.org/wiki/GLEP:34";> -GLEP 34, and the character set must be UTF-8 as specified -by https://wiki.gentoo.org/wiki/GLEP:31";>GLEP -31. A typical example: +GLEP 34. A typical example: -- 2.7.3
[gentoo-dev] [PATCH v1 0/5] devmanual: update the docs per GLEP 67 and 68
This is the second iteration of the GLEP 67 changeset combined with the first attempt at documenting GLEP 68 for devmanual. It also adds documentation about slotting in metadata.xml. The first iteration of the GLEP 67 changeset can be found here: https://archives.gentoo.org/gentoo-dev/message/f32960eaf345d07576210f91e98533da You can review the changes on Github for your own convenience: https://github.com/gktrk/devmanual.gentoo.org/compare/master...gktrk:glep67_68-v1 The HTML version of the devmanual with the proposed changes can be found at: http://devmanual.qui-gon.org/ Göktürk Yüksek (5): general-concepts/herds-and-projects: update per GLEP 67 #572144 #549490 ebuild-writing/misc-files/metadata: rewrite the section per GLEP 67 #572144 ebuild-writing/misc-files/metadata: update wrt slotting and per GLEP 68 ebuild-writing/misc-files/metadata: move the GLEP 31 reference to the top ebuild-writing/misc-files/metadata: add an example for slots and subslots ebuild-writing/misc-files/metadata/text.xml | 580 +-- general-concepts/herds-and-projects/text.xml | 101 - 2 files changed, 467 insertions(+), 214 deletions(-) -- 2.7.3
[gentoo-dev] [PATCH v1 2/5] ebuild-writing/misc-files/metadata: rewrite the section per GLEP 67 #572144
A major rewrite of the section. Here is a brief summary of changes: - Remove the information about the tag per GLEP 67 - Restructure the section in the following order: - metadata.xml syntax - package metadata - metadata examples - maintainer-needed - category metadata - Update the tables for metadata.xml syntax per GLEP 67 - Rewrite the package metadata examples to reflect better on GLEP 67 and enhance with more explanations - Assign meaningful titles to package metadata examples instead of using "First Example", "Second Example" etc. - Add a subsection for handling maintainer-needed in metadata.xml per GLEP 67 and provide an example This commit also makes #545272 obsolete. Gentoo-Bug: https://bugs.gentoo.org/show_bug.cgi?id=572144 Gentoo-Bug: https://bugs.gentoo.org/show_bug.cgi?id=545272 Signed-off-by: Göktürk Yüksek --- ebuild-writing/misc-files/metadata/text.xml | 419 1 file changed, 239 insertions(+), 180 deletions(-) diff --git a/ebuild-writing/misc-files/metadata/text.xml b/ebuild-writing/misc-files/metadata/text.xml index 2324f53..1d26ede 100644 --- a/ebuild-writing/misc-files/metadata/text.xml +++ b/ebuild-writing/misc-files/metadata/text.xml @@ -10,16 +10,7 @@ package or category. -Package Metadata - - -For packages, metadata.xml can specify a long description and -maintainer information. If a long description in any language is -provided, an English long description must be present. A typical -example might look like: - - - +Syntax @@ -39,13 +30,10 @@ A metadata.xml file can contain a number of tags: This is the root element of the metadata.xml file for packages. It has no attributes. The following subtags are allowed: -<herd>, <maintainer>, <longdescription>, <use>, and <upstream>. -There should be at least one <herd> or -<maintainer> subtag. @@ -62,26 +50,17 @@ A metadata.xml file can contain a number of tags: -<herd> - - -If a package is maintained by one or more herds, names of these herds -can be specified with the <herd> tag. The names -used in this tag must be the same as specified in the https://sources.gentoo.org/viewcvs.py/*checkout*/gentoo/xml/htdocs/proj/en/metastructure/herds/herds.xml?content-type=text/plain&rev=HEAD";>herds.xml -file. - - - - <maintainer> -Besides being part of a herd, a package can also be maintained directly. -The maintainers of a package can be specified with the -<maintainer> tag. This tag has one required subtag: +This tag specifies the persons and/or projects responsible for +the maintenance of a package. A package may contain zero or more +<maintainer> tags. The type attribute must +be specified and can be either "person" or +"project". There is one required subtag: <email>. It has two optional subtags: -<name>, and <description>. +<name> and +<description>. @@ -207,8 +186,7 @@ A metadata.xml file can contain a number of tags: -There are also some attributes that can be used with these tags. They are all -optional: +There are also some attributes that can be used with these tags: @@ -235,7 +213,7 @@ optional: restrict -<herd>, <maintainer>, +<maintainer>, <longdescription>, <flag> @@ -244,12 +222,7 @@ optional: without this attribute must also exist. That tag without the restrict attribute will serve as the default. The format of the restrict attribute is that of the DEPEND flag, except that "<" and -">" need to be specified by < and >. - -For example, in the sys-libs/db package, -restrict=">=sys-libs/db-3.2.9-r5" on the -maintainer tag shows that I'm currently maintaining all -versions greater then 3.2.9-r5. +">" need to be specified by "<" and ">". @@ -282,212 +255,298 @@ optional: <remote-id> -A string identifying the type of upstream source. A list of valid strings are kept in metadata.dtd. +A string identifying the type of upstream source. A list of valid strings are kept in +https://www.gentoo.org/dtd/metadata.dtd";>metadata.dtd. Developers should email the gentoo-dev mailing list before using a new type value. + + type + +<maintainer> + + +Defines the type of the maintainer for a package. There are only +two valid values: "person" and "project". The latter +denotes an official + +Gentoo project. + + - - - - -Metadata Examples - -First Example +Package Metadata - -In this first example we provide yo
Re: [gentoo-dev] [PATCH] metadata.dtd: Remove obsolete element per GLEP 68
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Michał Górny: > On Sat, 30 Apr 2016 02:36:18 -0400 Göktürk Yüksek > wrote: > >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 >> >> Michał Górny: >>> On Thu, 28 Apr 2016 19:41:06 -0400 Göktürk Yüksek >>> wrote: >>> >>>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 >>>> >>>> Brian Dolbec: >>>>> On Thu, 28 Apr 2016 15:39:05 -0400 Göktürk Yüksek >>>>> wrote: >>>>> >>>>>> --- metadata.dtd | 5 + 1 file changed, 1 >>>>>> insertion(+), 4 deletions(-) >>>>>> >>>>>> diff --git a/metadata.dtd b/metadata.dtd index >>>>>> 7626a57..b608852 100644 --- a/metadata.dtd +++ >>>>>> b/metadata.dtd @@ -3,7 +3,7 @@ >>>>> pkgname CDATA ""> >>>>>> >>>>>> ->>>>> >>>>>> (maintainer|natural-name|longdescription|slots|use|upstream)* >>>>>> )> +>>>>> (maintainer|longdescription|slots|use|upstream)* )> >>>>>> @@ >>>>>> -13,9 +13,6 @@ explicit type) for Gentoo maintainers is >>>>>> prohibited. --> >>>>> (person|project|unknown) "unknown"> >>>>>> >>>>>> - - >>>>> natural-name (#PCDATA) >>>>>>> - >>>>>>> >>>>>> >>>>> >>>>> Isn't this almost obsolete? it's now xmlschema... And I >>>>> hope to have the new repoman with it out this weekend :) >>>> >>>> Does GLEP 68 explicitly declare metadata.dtd obsolete? I see >>>> that the example metadata.xml on the GLEP is missing DOCTYPE, >>>> are we getting rid of those too? >>> >>> No, and I don't know. >>> >>> metadata.dtd is still required by many tools, and as such it >>> makes sense to keep it. However, we may want to put some >>> warning that it's not very strict, and allows major structural >>> violations due to technical limitations. >>> >> After a discussion with ulm on IRC, we agreed that the following >> makes sense: "the format of the metadata is defined in GLEP 68. >> the syntax is defined in metadata.dtd. The xml-schema can be used >> for stricter validation checks." If you have no objections, I >> will update devmanual based on this description. > > What is the precise difference between 'format' and 'syntax' here? > I'm no native English speaker, and I don't see any obvious split > of responsibility between the two here, and I'm pretty sure this > will be quite confusing for other people as well. > I admit that it is hard to make a clear distinction. When I look at the GLEPs replaced by GLEP68, I see that they propose a change for metadata.xml and explain how that affects metadata.dtd. GLEP34 has "The DTD file would need to be updated to include the element.", GLEP46 explicitly says "metadata.dtd should allow the use of a upstream tag in metadata.xml.", GLEP56 points to #199788 which required DTD to be patched. GLEP68 is rather vague as to how metadata.dtd is affected. It doesn't say whether it should be updated or if it has any role at all. GLEP68 provides a single human readable specification for the metadata format. In that respect, however, the DTD along with the comments in it is just as expressive, if not better: a developer can read through the DTD and learn all the information contained in the GLEP, plus the remote-id values which are not part of the specification for reasons you stated earlier. And that was the reason why I used the term "syntax": the DTD lists all the allowed elements, attributes, and values for the metadata that should be used in conformance with the GLEP . In the end, the DTD isn't much better than the GLEP as a human readable document and does a worse job than the xsd as a machine readable document for validation purposes. Once repoman switches to the xml-schema, there would be no good use for it and I don't know what should be done about the DTD. I think that until we figure it out, we should keep it in sync with the GLEP and xsd. -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJXJoZnAAoJEIT4AuXAiM4z1tsIAKj7/dBAQcsttsMxJbOlM4Ew GMiS4LK3/QZqlEM8ixL3otKptbWDhyJiB+c7cafyAamgFKGprWYnk2X+zFEfgmRw adjWjH4fwtS/AW/VFU4aeE4cYVOGF0ju0dh6ZO6bAYl4MJtcS5xVtRdDkIm3eacX OMjdzvuKgwYKiYxRu2AmCLS2+jExEj48mDEa9jPZMOb14xEljsRNjF76kPr6o8eG /XJ6t5o4+Ckkpwx4kckBUDtSj6ipuPz0SqwVrYLxhogwDas6E0h9BovGuaeLmgVM GYCXJzsetuWIvbRxJJhH9cTADjCwAt7SYGfdA72fknnmf0QZgScPjBnLUQSn2G4= =/CcU -END PGP SIGNATURE-
[gentoo-dev] [PATCH v1 3/4] metadata.dtd: update the restrict attribute explanation per GLEP 68
Signed-off-by: Göktürk Yüksek --- metadata.dtd | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/metadata.dtd b/metadata.dtd index a3c06ff..8ef1396 100644 --- a/metadata.dtd +++ b/metadata.dtd @@ -68,9 +68,10 @@ -- 2.7.3
[gentoo-dev] [PATCH v1 4/4] metadata: update the slot element name attribute explanation per GLEP 68
Signed-off-by: Göktürk Yüksek --- metadata.dtd | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/metadata.dtd b/metadata.dtd index 8ef1396..6d38729 100644 --- a/metadata.dtd +++ b/metadata.dtd @@ -20,7 +20,10 @@ - + -- 2.7.3
[gentoo-dev] [PATCH v1 2/4] metadata.dtd: set the lang attribute default value to "en" per GLEP 68
Also mention that the attribute value must be a valid ISO 639-1 language code. Signed-off-by: Göktürk Yüksek --- metadata.dtd | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/metadata.dtd b/metadata.dtd index b608852..a3c06ff 100644 --- a/metadata.dtd +++ b/metadata.dtd @@ -42,7 +42,7 @@ - + @@ -57,14 +57,14 @@ - - - - - + + + + +
[gentoo-dev] [PATCH v1 1/4] metadata.dtd: Remove obsolete element per GLEP 68
Signed-off-by: Göktürk Yüksek --- metadata.dtd | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/metadata.dtd b/metadata.dtd index 7626a57..b608852 100644 --- a/metadata.dtd +++ b/metadata.dtd @@ -3,7 +3,7 @@ - + @@ -13,9 +13,6 @@ explicit type) for Gentoo maintainers is prohibited. --> - - - -- 2.7.3
Re: [gentoo-dev] [PATCH] metadata.dtd: Remove obsolete element per GLEP 68
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Michał Górny: > On Thu, 28 Apr 2016 19:41:06 -0400 Göktürk Yüksek > wrote: > >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 >> >> Brian Dolbec: >>> On Thu, 28 Apr 2016 15:39:05 -0400 Göktürk Yüksek >>> wrote: >>> >>>> --- metadata.dtd | 5 + 1 file changed, 1 insertion(+), 4 >>>> deletions(-) >>>> >>>> diff --git a/metadata.dtd b/metadata.dtd index >>>> 7626a57..b608852 100644 --- a/metadata.dtd +++ b/metadata.dtd >>>> @@ -3,7 +3,7 @@ >>>> >>>> ->>> (maintainer|natural-name|longdescription|slots|use|upstream)* >>>> )> +>>> (maintainer|longdescription|slots|use|upstream)* )> >>> pkgmetadata pkgname CDATA ""> @@ -13,9 +13,6 >>>> @@ explicit type) for Gentoo maintainers is prohibited. --> >>>> >>> "unknown"> >>>> >>>> - - >>> (#PCDATA) >>>>> - >>>> >>> >>> Isn't this almost obsolete? it's now xmlschema... And I hope >>> to have the new repoman with it out this weekend :) >> >> Does GLEP 68 explicitly declare metadata.dtd obsolete? I see that >> the example metadata.xml on the GLEP is missing DOCTYPE, are we >> getting rid of those too? > > No, and I don't know. > > metadata.dtd is still required by many tools, and as such it makes > sense to keep it. However, we may want to put some warning that > it's not very strict, and allows major structural violations due > to technical limitations. > After a discussion with ulm on IRC, we agreed that the following makes sense: "the format of the metadata is defined in GLEP 68. the syntax is defined in metadata.dtd. The xml-schema can be used for stricter validation checks." If you have no objections, I will update devmanual based on this description. > As for DOCTYPE, there was no formal decision on that. It's not > technically required, so the GLEP doesn't enforce it. However, I > don't expect it being gone anytime soon. One of the reasons behind > it is that repoman enforces it as part of metadata.xml validation. > If it is to be gone, stable repoman needs to accept it missing at > least for some time. > > There was a proposal to link new/additional schemas in > metadata.xml files. However, I personally don't think we should go > this way. DOCTYPE already proved troublesome (when we switched to > https), and maintaining any kind of schema reference in XML files > doesn't give us any real benefit (we don't enforce any hard > defaults besides languages there, and I don't think many XML > parsers would respect that anyway). > >> I understand that the DTD is more like a super-set, so anything >> that complies with GLEP 68 will comply with the DTD as well. >> However, there is a caveat here: for example the GLEP dismisses >> the list of possible values for by saying "The list >> of available trackers and their specific identifiers are outside >> scope of this specification." but does not mention where these >> values shall be kept either. The moment we add a new remote-id, >> the xmlschema diverges from the DTD and stops being a subset. > > Well, there is good reason for not hardcoding the list in the > GLEP, and this obviously is to avoid updating the GLEP for every > single change. And yes, as you can see, I didn't point out a > specific location where remote-ids are to be defined to avoid > problems like the one noted below. > > As I see it, we can defer it to some project / wiki page, or > simply keep it in either of the schemas. Either way, we should keep > both schemas reasonably up-to-date. > >> Besides, the PMS says the format of metadata.xml is described in >> DTD. Even if we move to something else, doesn't metadata.dtd need >> to be kept around until the PMS is amended? > > The key point PMS is making is 'outside the scope'. The specific > location is just a minor problem, and it should be updated. I'll > take a look at it. > > Oh, and +1 for the patch. If nobody complains and nobody beats me > up to it, I'll commit it this weekend. > Please hold off the merge. I have found a few more things that require fixing. I'll send a new patch series for review. -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJXJFJcAAoJEIT4AuXAiM4zcTMH+wcmYptb9MPo+7oSRx9ViS22 RVwUKiwdb55JmMHLXWu7ATQS+X1Jb5LqlNxIdpUz77zfP9+WFJJagJI9F1oi7a4s e9wi7a1J3H812Xo2JcRZGnp95OX2O/c7dyXCcG5VMwB8kqW8JMykb+QmI0opm9s7 ePX0e1lQ3mhaMy8thTRBZK9a1cA+B86PWBtQRtQtb3leotD06DDnO0sZchLYsDYZ A0qTDOZ+V5t9qJ0EtNJ8jb9T/7dz971noZUwdUDgkveU1Q+3o/IWBzZD765WaPYs dSlWhn8linRLk3UhHe95+vCL0NAuLLdEEPIiNNrLRG3orz/gfbz7kl0E8+JNW58= =DLlT -END PGP SIGNATURE-
Re: [gentoo-dev] [PATCH] metadata.dtd: Remove obsolete element per GLEP 68
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Brian Dolbec: > On Thu, 28 Apr 2016 15:39:05 -0400 Göktürk Yüksek > wrote: > >> --- metadata.dtd | 5 + 1 file changed, 1 insertion(+), 4 >> deletions(-) >> >> diff --git a/metadata.dtd b/metadata.dtd index 7626a57..b608852 >> 100644 --- a/metadata.dtd +++ b/metadata.dtd @@ -3,7 +3,7 @@ >> >> >> -> (maintainer|natural-name|longdescription|slots|use|upstream)* )> >> +> (maintainer|longdescription|slots|use|upstream)* )> > pkgmetadata pkgname CDATA ""> @@ -13,9 +13,6 @@ explicit type) >> for Gentoo maintainers is prohibited. --> > type (person|project|unknown) "unknown"> >> >> - - > > - >> >> > > > Isn't this almost obsolete? it's now xmlschema... And I hope to > have the new repoman with it out this weekend :) > Does GLEP 68 explicitly declare metadata.dtd obsolete? I see that the example metadata.xml on the GLEP is missing DOCTYPE, are we getting rid of those too? I understand that the DTD is more like a super-set, so anything that complies with GLEP 68 will comply with the DTD as well. However, there is a caveat here: for example the GLEP dismisses the list of possible values for by saying "The list of available trackers and their specific identifiers are outside scope of this specification." but does not mention where these values shall be kept either. The moment we add a new remote-id, the xmlschema diverges from the DTD and stops being a subset. Besides, the PMS says the format of metadata.xml is described in DTD. Even if we move to something else, doesn't metadata.dtd need to be kept around until the PMS is amended? - -- gokturk -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJXIp+LAAoJEIT4AuXAiM4zszAIAI8GPcE8Ap3b652DYWRX/THb IeRBMGyTsgu8s0GB5i7Qfy94uKMxc1+9SCipEK0GoBq7Vkeils8SHdSNCt2TPE6t Hzh4UG6lI7qebMVrsRi85GDZr1l4HA5/Co54lizMlFW7uO8vgRRU2Cj7AfPt/BFQ zan7+yQv+zLv0OVxb2XPAnbCMn0cL5PIzSBXN4aN+p58FVOwJlUs/tEQbNOKjRWK v6J4ejz4QA8Sy6Gx7aAupBzT+8YhtU9BLMWzbSf4VEMBELD8ZrzYfZtxZQNcpkFV INef3hFcpM+5whHTDQ0QfAbVXEyRRVoMo1W87yZLUT7qUrlRcMhbjopT6+e+ZCs= =HDEG -END PGP SIGNATURE-
[gentoo-dev] [PATCH] metadata.dtd: Remove obsolete element per GLEP 68
--- metadata.dtd | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/metadata.dtd b/metadata.dtd index 7626a57..b608852 100644 --- a/metadata.dtd +++ b/metadata.dtd @@ -3,7 +3,7 @@ - + @@ -13,9 +13,6 @@ explicit type) for Gentoo maintainers is prohibited. --> - - - -- 2.7.3
Re: [gentoo-dev] [PATCH v1 3/3] ebuild-writing/misc-files/metadata: rewrite the section per GLEP 67 #572144
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Göktürk Yüksek: > +<flag name="multislot"> + Allow concurrent > installation of <pkg>sys-boot/grub:0</pkg> and + > <pkg>sys-boot/grub:2</pkg> by renaming all programs. + > </flag> Please do not merge. I just realized that the slot operators should be outside the tag as in "sys-boot/grub:2". Will fix and resubmi t. - -- gokturk -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJXF/SvAAoJEIT4AuXAiM4z7EUH/R+QfIIOZljx4Pf7/093zhAF jOjV689/UYDW8ZPvOCJA2JPg+UJMhqr2mBaflIcztO/SxGNPeeIlGXip3D7gCb5h jcv4uyprJ7kWtbNcEOmvL3TwqjDiuHAwZtpVHUFnrryIGT8uv3kE6d5aUK1SHUQG X0/fl/40QmlNHwFhpPsHa5aQbe1eLNCozI3DjzejbC3fBa3uc+15xow+G2Ox2tfz EGlsYs3/nUVyW10mlJUBnx23agvZMQStnzwnmzYzgHjOvVSr7gXlWJkMqL7o3i1U 1PRrUooZCZTn0oejC4GC07wTiv+41mDnHtYMrBLJooArfGNWrRCICMpKARlSggM= =Vcqu -END PGP SIGNATURE-
[gentoo-dev] [PATCH] ebuild-maintenance: information for updating metadata on package move/removal
The dtd for metadata.xml supports referencing other packages using the tag. It also allows package atoms to be specified as part of the "restrict" attribute for various tags. These references should be properly updated/removed upon package moves and removals. Reported-by: NP-Hardass Signed-off-by: Göktürk Yüksek --- ebuild-maintenance/text.xml | 19 +-- 1 file changed, 17 insertions(+), 2 deletions(-) diff --git a/ebuild-maintenance/text.xml b/ebuild-maintenance/text.xml index 66d736f..7cbe755 100644 --- a/ebuild-maintenance/text.xml +++ b/ebuild-maintenance/text.xml @@ -441,8 +441,12 @@ Next is checking the files under profiles/ such as profiles/package.mask and update them to reflect the ebuild move. Various eclasses automatically provide some of the dependencies upon inherit, so the files under eclass/ should be checked and updated -properly as well. Lastly, the titles of the open bugs related to the package -should be updated. +properly. If the package metadata.xml has tags with restrict +attribute, they should be updated to reflect the move. The +metadata.xml for various packages may contain references to the +package being moved using the <pkg> tag which need to be +updated accordingly as well. Lastly, the titles of the open bugs +related to the package should be updated. @@ -467,6 +471,12 @@ Here is an example where the package Check the eclasses that may be referencing the package +Update all the +metadata.xml +files which contain a reference to this package using the +<pkg> tag or the restrict attribute. + + Stage all the changed files using git add. For example: git add profiles/package.mask @@ -554,6 +564,11 @@ When removing packages follow these steps: Wait 30 days (or more) Remove from the git tree unless the reason for removal has been fixed Remove package.mask entry + +Remove the <pkg> tags referencing this package in the +metadata.xml +files of other packages. + Close open bugs as WONTFIX -- 2.7.3
Re: [gentoo-dev] [PATCH v1 1/3] general-concepts/herds-and-projects: update per GLEP 67 #572144 #549490
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Andreas K. Huettel: > On Monday 04 April 2016 06:57:51 NP-Hardass wrote: >> On 04/04/2016 12:34 AM, Göktürk Yüksek wrote: >>> +sufficient for adding or removing a developer. Note that >>> different +projects have different requirements and procedures >>> for recruiting +developers, which may require prior >>> arrangements to be made before +modifying the member list. > >> I'm not particularly fond of this statement. The implication is >> that most projects require permission, whereas I believe that the >> opposite is true. To the best of my knowledge, most projects are >> open, and ones that have special requirements almost always list >> them explicitly on their project pages. > > It's true that most projects are happy to accept new members, but > usually you're expected to talk at least to some team member > first. > > (Hi I'd like to join... Sure, just add yourself!) > > More of a courtesy, really... and also a good way to find out *if* > there are any rules/restrictions. > > My intention was to document only the mechanics involved in the process and sidestep the permission discussion as much as possible. Frankly, I have no experience in joining/leaving projects. I understand that some projects are happy with people just adding themselves without permission whereas others, like the security team, are stricter with their requirements. Either way, the wiki will need to be modified and possibly the alias file too. Maybe we are better off without the last sentence, so it's less controversial? - -- gokturk -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJXCSDrAAoJEIT4AuXAiM4zTgkIAJpoyFylEAaYzpZLiBoNw/UD AiBpbaJUtwtfgrIs11PCKORJfsJXRd4WxuNdh05NWxsmKRht1IESoE9RokCT2eQA NbS/GUS6r7DZEifBjAtIbgykhvzWGgq4uybxUaktp9tOn+t+/zg3rvh/1316udTR R4eXB5n9YumUrLuvVdbeQUz/bxJ1/0mKyebrKpeci+brDPjO7xpXV2xfRimZ9msP 9R2ceDzMlEYX0V1kwe/Q+Zc9fnGw+C0Z8FXZf9fgbr/bjYDL3ROPQSvjIyiVq9zF 8aCbMIS5+ZvwbkhJJ3mnChiCkH1pujMiqlgr3dqi1XdbMjL/rsphElorQt5pbSc= =xz02 -END PGP SIGNATURE-
[gentoo-dev] [PATCH v1 1/3] general-concepts/herds-and-projects: update per GLEP 67 #572144 #549490
The changes are: - Rename the title to "Projects and Herds" to put the emphasis on projects - Explain projects and subprojects in a new "Projects" section - Add a subsection for starting new projects - Add a subsection for joining/leaving a project - Put a warning label at the beginning of the "Herds" section, declare it obsolete, and preserve it for historical reasons Gentoo-Bug: https://bugs.gentoo.org/show_bug.cgi?id=572144 Gentoo-Bug: https://bugs.gentoo.org/show_bug.cgi?id=549490 Signed-off-by: Göktürk Yüksek --- general-concepts/herds-and-projects/text.xml | 128 ++- 1 file changed, 127 insertions(+), 1 deletion(-) diff --git a/general-concepts/herds-and-projects/text.xml b/general-concepts/herds-and-projects/text.xml index e030150..39813c8 100644 --- a/general-concepts/herds-and-projects/text.xml +++ b/general-concepts/herds-and-projects/text.xml @@ -1,10 +1,133 @@ -Herds and Projects +Projects and Herds + +Projects + + + +The management structure of Gentoo, called the "metastructure", +is defined in +https://wiki.gentoo.org/wiki/GLEP:39#Specification";> +GLEP 39. In Gentoo, a project is a group of developers working +towards a common goal in various different areas. For example, the +https://wiki.gentoo.org/wiki/Project:Metastructure";> +Gentoo Metastructure Project oversees the developments +regarding the metastructure. There are other projects such as the +https://wiki.gentoo.org/wiki/Project:Bug-wranglers";> +Bug Wranglers which works on assigning bugs reported on Gentoo +Bugzilla to the responsible developers/projects, or, the +https://wiki.gentoo.org/wiki/Project:Devmanual";> +Devmanual which focuses on maintaining this document. Many +others are responsible for maintaining packages in the tree: the +https://wiki.gentoo.org/wiki/Project:Base";> +Base-System focuses on compilers, toolchains and various other +system software; the +https://wiki.gentoo.org/wiki/Project:Portage";> +Portage Development Project specializes in the development of +sys-apps/portage; the +https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers";> +Proxy Maintainers allows keen users to assume responsibility for +various packages in the official tree under the guidance of Gentoo +developers. A package maintained by a project needs to have the +project explicitly listed as a maintainer in its +metadata.xml. +The full listing of all the projects can be found on +https://api.gentoo.org/metastructure/projects.xml";> +api.gentoo.org or on the +https://wiki.gentoo.org/wiki/Project:Gentoo";>wiki. + + + +Projects spanning a large area of topics can have multiple subprojects +specializing in particular fields within the domain of the parent +project and thus form a project hierarchy. For example, +https://wiki.gentoo.org/wiki/Project:ComRel";> +Community Relations project mainly concerns itself with +inter-developer and user-developer relationships as well as upholding +the Gentoo Code of Conduct. +https://wiki.gentoo.org/wiki/Project:Recruiters";> +Recruiters project, on the other hand, is tasked with +orchestrating the process of recruiting developers for Gentoo. Both +projects tackle different problems, yet, at the same time work towards +the common goal of improving and maintaining good relations in the +community. As such, both of these are subprojects of +https://wiki.gentoo.org/wiki/Project:ComRes";> +Community Resources project. + + + +Starting New Projects + + + +According to the metastructure any developer may create a new +project. There are two procedures involved in starting a new project: + + + +Create a new project page https://wiki.gentoo.org/wiki/Gentoo_Wiki:Developer_Central/Project_pages";> +through the wiki. + + +Post a Request For Comments (RFC) email to the gentoo-dev +mailing list. + + + +There is no approval required for the RFC and negative comments do not +block a developer from creating a project. Competing projects are +allowed to co-exist in Gentoo; existence of another project with +similar goals do not block another developer from starting a new +project with the same goals. + + + + + +Joining and Leaving a Project + + + +Members of a project are managed through the project's page on the +Gentoo Wiki. Each page has a "Project" template in its source which +lists the members of the project. Simply modifying the list is +sufficient for adding or removing a developer. Note that different +projects have different requirements and procedures for recruiting +developers, which may require prior arrangements to be made before +modifying the member list. + + + +Developers should remember to add themselves to the alias by editing +/var/mail/alias/misc/<alias name> on +dev.gentoo.org. For example, the alias for the Devmanual project is +located at /var/mail/alias/misc/devmanual
[gentoo-dev] [PATCH v1 3/3] ebuild-writing/misc-files/metadata: rewrite the section per GLEP 67 #572144
A major rewrite of the section. Here is a brief summary of changes: - Remove the information about the tag per GLEP 67 - Restructure the section in the following order: - metadata.xml syntax - package metadata - metadata examples - maintainer-needed - category metadata - Update the tables for metadata.xml syntax per GLEP 67 - Rewrite the package metadata examples to reflect better on GLEP 67 and enhance with more explanations - Assign meaningful titles to package metadata examples instead of using "First Example", "Second Example" etc. - Add a subsection for handling maintainer-needed in metadata.xml per GLEP 67 and provide an example This commit also makes #549490 obsolete. Gentoo-Bug: https://bugs.gentoo.org/show_bug.cgi?id=572144 Gentoo-Bug: https://bugs.gentoo.org/show_bug.cgi?id=549490 Signed-off-by: Göktürk Yüksek --- ebuild-writing/misc-files/metadata/text.xml | 408 1 file changed, 227 insertions(+), 181 deletions(-) diff --git a/ebuild-writing/misc-files/metadata/text.xml b/ebuild-writing/misc-files/metadata/text.xml index 2324f53..9d0dc19 100644 --- a/ebuild-writing/misc-files/metadata/text.xml +++ b/ebuild-writing/misc-files/metadata/text.xml @@ -10,20 +10,13 @@ package or category. -Package Metadata - - -For packages, metadata.xml can specify a long description and -maintainer information. If a long description in any language is -provided, an English long description must be present. A typical -example might look like: - - - +Syntax -A metadata.xml file can contain a number of tags: +A metadata file follows the syntax defined in +https://www.gentoo.org/dtd/metadata.dtd";> +metadata.dtd and can contain a number of tags: @@ -39,13 +32,10 @@ A metadata.xml file can contain a number of tags: This is the root element of the metadata.xml file for packages. It has no attributes. The following subtags are allowed: -<herd>, <maintainer>, <longdescription>, <use>, and <upstream>. -There should be at least one <herd> or -<maintainer> subtag. @@ -62,26 +52,21 @@ A metadata.xml file can contain a number of tags: -<herd> - - -If a package is maintained by one or more herds, names of these herds -can be specified with the <herd> tag. The names -used in this tag must be the same as specified in the https://sources.gentoo.org/viewcvs.py/*checkout*/gentoo/xml/htdocs/proj/en/metastructure/herds/herds.xml?content-type=text/plain&rev=HEAD";>herds.xml -file. - - - - <maintainer> -Besides being part of a herd, a package can also be maintained directly. -The maintainers of a package can be specified with the -<maintainer> tag. This tag has one required subtag: +This tag specifies the persons and/or projects responsible for +the maintenance of a package. A package may contain zero or more +<maintainer> tags. The type attribute must +be specified and can be either "person" or +"project". There is one required subtag: <email>. It has two optional subtags: -<name>, and <description>. +<name> and +<description>. Unless specified otherwise, the +maintainer who is listed in the metadata first shall be the +assignee for the bugs for that package as per +https://wiki.gentoo.org/wiki/GLEP:67#Bug_assignment";> +GLEP 67. @@ -108,7 +93,9 @@ A metadata.xml file can contain a number of tags: <longdescription> This tag contains a description of the package. This is to augment the -DESCRIPTION field in the ebuilds themselves. This tag has two optional +DESCRIPTION field in the ebuilds themselves. If a long description +in any language is provided, an English long description must be +present. This tag has two optional subtags: <pkg> and <cat>. @@ -207,8 +194,7 @@ A metadata.xml file can contain a number of tags: -There are also some attributes that can be used with these tags. They are all -optional: +There are also some attributes that can be used with these tags: @@ -235,7 +221,7 @@ optional: restrict -<herd>, <maintainer>, +<maintainer>, <longdescription>, <flag> @@ -244,12 +230,7 @@ optional: without this attribute must also exist. That tag without the restrict attribute will serve as the default. The format of the restrict attribute is that of the DEPEND flag, except that "<" and -">" need to be specified by < and >. - -For example, in the sys-libs/db package, -restrict=">=sys-libs/db-3.2.9-r5" on the -maintainer tag shows that I'm currently maintaining all -versions greate
[gentoo-dev] [PATCH v1 2/3] ebuild-maintenance: s/herd/project/ per GLEP 67 #572144
Gentoo-Bug: https://bugs.gentoo.org/show_bug.cgi?id=572144 Signed-off-by: Göktürk Yüksek --- ebuild-maintenance/text.xml | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/ebuild-maintenance/text.xml b/ebuild-maintenance/text.xml index 5b2abee..a299bf2 100644 --- a/ebuild-maintenance/text.xml +++ b/ebuild-maintenance/text.xml @@ -281,7 +281,18 @@ which is often more convenient. Touching other developers ebuilds -Usually you don't just change other developers ebuilds without permission unless you know that developer does not mind or if you are part of the herd involved in maintenance (this information can typically be found in metadata.xml). Start with filing a bug or trying to catch them on IRC or via email. Sometimes you cannot reach them, or there is no response to your bug. It's a good idea to consult other developers on how to handle the situation, especially if it's a critical issue that needs to be handled ASAP. Otherwise a soft limit of 2 to 4 weeks depending on the severity of the bug is an acceptable time frame before you go ahead and fix it yourself. + +Usually you don't just change other developers ebuilds without +permission unless you know that developer does not mind or if you are +part of the project involved in maintenance (this information can +typically be found in metadata.xml). Start with filing a bug or trying +to catch them on IRC or via email. Sometimes you cannot reach them, or +there is no response to your bug. It's a good idea to consult other +developers on how to handle the situation, especially if it's a +critical issue that needs to be handled ASAP. Otherwise a soft limit +of 2 to 4 weeks depending on the severity of the bug is an acceptable +time frame before you go ahead and fix it yourself. + Common sense dictates to us that toolchain/base-system/core packages and eclasses or anything else which is delicate (e.g. glibc) or widely used (e.g. gtk+) should usually be left to those maintainers. If in doubt, don't touch it. -- 2.7.3
[gentoo-dev] [PATCH v1 0/3] devmanual: update the docs per GLEP 67
Hi, This is the first iteration of the patch series for updating devmanual per GLEP 67. It replaces any reference to herds, includes a major rewrite of the section that explains the metadata.xml file, and talks about how projects are created and managed through the wiki. The section about herds is currently preserved but deprecated. It may be useful to keep it around for a while before removing it. You can review the changes on Github for your own convenience: https://github.com/gktrk/devmanual.gentoo.org/compare/master...gktrk:glep67-v1 The HTML version of the devmanual with the proposed changes can be found at: http://devmanual.qui-gon.org/ Göktürk Yüksek (3): general-concepts/herds-and-projects: update per GLEP 67 #572144 #549490 ebuild-maintenance: s/herd/project/ per GLEP 67 #572144 ebuild-writing/misc-files/metadata: rewrite the section per GLEP 67 #572144 ebuild-maintenance/text.xml | 13 +- ebuild-writing/misc-files/metadata/text.xml | 408 +++ general-concepts/herds-and-projects/text.xml | 129 - 3 files changed, 367 insertions(+), 183 deletions(-) -- 2.7.3
[gentoo-dev] [PATCH] bin/portageq: add a matcher to match the orphaned (maintainer-needed) packages
Per GLEP 67, orphaned packages do not have a in metadata.xml.
They can't be matched using '--maintainer-email=maintainer-nee...@gentoo.org'
anymore. Add a new command line argument '--orphaned' to match the orphaned
packages.
Signed-off-by: Göktürk Yüksek
---
bin/portageq | 13 +
1 file changed, 13 insertions(+)
diff --git a/bin/portageq b/bin/portageq
index 925640b..8ec81ea 100755
--- a/bin/portageq
+++ b/bin/portageq
@@ -1028,6 +1028,12 @@ class HerdMatcher(object):
herds = self._herds
return any(x in herds for x in metadata_xml.herds())
+class OrphanedMatcher(object):
+ def __call__(self, metadata_xml):
+ if not metadata_xml.maintainers():
+ return True
+ else:
+ return False
def pquery(parser, opts, args):
portdb = portage.db[portage.root]['porttree'].dbapi
@@ -1090,6 +1096,8 @@ def pquery(parser, opts, args):
for x in opts.herd:
herds.extend(x.split(","))
xml_matchers.append(HerdMatcher(herds))
+ if opts.orphaned:
+ xml_matchers.append(OrphanedMatcher())
if opts.repo is not None:
repos = [portdb.repositories[opts.repo]]
@@ -1248,6 +1256,11 @@ def add_pquery_arguments(parser):
"longopt": "--maintainer-email",
"action": "append",
"help": "comma-separated list of
maintainer email regexes to search for"
+ },
+ {
+ "longopt": "--orphaned",
+ "action": "store_true",
+ "help": "match only orphaned
(maintainer-needed) packages"
}
)
),
--
2.4.10
Re: [gentoo-dev] [PATCH v3 05/21] ebuild-writing/misc-files: replace the code for cvs commit with git #558642
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Ulrich Mueller:
>> On Wed, 3 Feb 2016, Brian Dolbec wrote:
>
>>> --- a/ebuild-writing/misc-files/metadata/text.xml +++
>>> b/ebuild-writing/misc-files/metadata/text.xml @@ -532,7
>>> +532,21 @@ is currently: xmllint --noout --valid
>>> metadata.xml glep31check metadata.xml -cvs commit -m "Adding
>>> category metadata.xml for my-category" metadata.xml +git add
>>> metadata.xml +git commit --gpg-sign
>>>
>
>> This should be repoman commit still, not git commit
>
> This is about the last section, namely adding category metadata.
> IMHO using "git commit" is perfectly fine here. ("repoman commit"
> would do much more, e.g. regenerate Manifests in all package
> subdirectories, which may not be wanted.)
>
> However, I wonder about the "glep31check" line above, since I have
> never heard of that. Also "e-file glep31check" returns no hits.
> Maybe we shouldn't recommend a tool that isn't even in the tree?
>
I've already created a bug for this 3 weeks ago:
https://bugs.gentoo.org/show_bug.cgi?id=572156
The source used to be hosted here:
http://dev.gentoo.org/~ciaranm/toys/glep31check-0.3.3.tar.bz2
Should we get rid of it?
> Ulrich
>
- --
gokturk
-BEGIN PGP SIGNATURE-
iQEcBAEBCgAGBQJWtEZyAAoJEIT4AuXAiM4zQ3cH/i1cpHRjzcywCFPJpgm4pqk2
q08aezx37k546aLL5vgHR7raY6AGwN9/fWKhGtiwESg4KSwM32fVUO57NO2XiJcM
cQ9iSAczorD3kdX+t4dnSKCsgdD3ZuOWmCN7KZqpTH4FIKuFTzlbWIbaJip28TQ8
7Vj1FnfN+bLQqcU7v3VnxvbMGlNP1kemQLFgpdr95ippWqznzG8ztWuRwWQO99Th
w76xe0XWl69eKHc3NGHFGEkRjI7XahDl+tLxSusgZCXKofADj/s1UuTJ7XuPQTem
iXLYPmzxGyeSQ7Xr7bSlYtvBCDdQYq9MKJHDIqswJ3fnt0qPwxLemcR1AvRLeYg=
=Xx//
-END PGP SIGNATURE-
Re: [gentoo-dev] [PATCH v3 00/21] devmanual: update the docs for post git-migration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Daniel Campbell: > On 02/03/2016 04:57 PM, gokt...@binghamton.edu wrote: >> From: Gokturk Yuksek > >> Hi, > > [...] > > This isn't related to what you're doing but I felt it was a good > place to ask: > > How are you and other developers creating these series of e-mails? > It seems really handy and I'd like to know what it is, in the > event that I need to do the same. > > Here's how I do it: Make your commits on a separate branch as if you'd push them directly to the repo. Use 'git format-patch' to generate patch files and use 'git send-email' to send them. You can skip format-patch and just use send-email but for a changeset of 21 commits I'd like to take another look. git format-patch --stat --summary -o bug558642_v3/ -n -v3 - --cover-letter master..devmanual-git-migration-v3 Creates the patches. '--cover-letter' creates a special patch file that requires editing which becomes the first email in the series, which is the one you replied to. Once satisfied, I sent it with: git send-email * Keep in mind that git will CC authors of the patches and yourself to the email. So you may have to adjust those. Don't forget to edit your .gitconfig and set proper SMTP options in the [sendemail] section. - -- gokturk -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJWsq3CAAoJEIT4AuXAiM4zuIEH/AvY3LYbcPMONlA5KuXTYTBG 8AtgqynEmQ0Qt1XujbC8W2bsKRMiUi8Xbtttnm/urfVCzCDKVQrzIkIA4x4kqIxA HKYgLuqE2zLxfLrbJkB0W3F1ogNOt1fuxzR9HSlasgqOSh13tpexINvI77iC4U0T 7ZlUeRv5R7AqvObEZO+2hY3JkHCELgD4lwRkNwjzqNVqJLJOVUev3wXid38GBPf2 qQUEUdZw5XuM5ygFM0r5ZgP2X8HEs5FfB9ouAHGuw7d/Kr+R3L+vH1v5g4+D+n1f iink8nR2LMrcBRiQ4/tbXyBgBiu/jZeG5UTJfQte3jyOuP4kf65SFADW+3B4+cc= =46ba -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [PATCH v2 17/19] ebuild-writing/misc-files: remove ChangeLog section #485314
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Ulrich Mueller: >> On Sun, 24 Jan 2016, Michael Orlitzky wrote: > >> The ChangeLog page is nonsense as-is, and removing it makes the >> devmanual better. Afterwards, if someone wants to take the commit >> message guidelines from the wiki and merge them with the old >> ChangeLog tips, great. There's only two things worth salvaging >> from the ChangeLog page. Here's the combined list: > >> 1. Everything from the Git workflow wiki page "Commit message >> format" section. > > I would say not only that section, but most of the page. The > devmanual is the one central place where our development workflow > should be documented, not some random wiki page. > If the most up-to-date information is on the wiki, constantly updating devmanual to match the wiki creates unnecessary maintenance burden. >> 2. Mention the "Gentoo-Bug:" identifier. > > Right. (But had we settled for "Gentoo-Bug:"? IIRC, last time this > was discussed there was no consensus.) > Related to my point above, looks like the git workflow is still in the process of making. I expect that some discussion will continue to take place in the future. We can always fix the other parts of the devmanual and come back to this. Is it possible to merge this changeset as is while the workflow matures, or should I go for a round 3? >> Using "bug #12345" in the commit message itself causes trouble. >> If you word-wrap on the "#12345", it will silently clobber the >> message. > > That's one of the reasons why I have 'commentchar = ";"' in my > .gitconfig file. (Not sure if that option would be worth mentioning > in our documentation, though.) > >> [...] > > Ulrich > - -- gokturk -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJWqEU2AAoJEIT4AuXAiM4zwCAH/3q8FQB+zX0q1kuXjJfYnF3j IvJ2uKjuHMfbSAoGy2bUGEEhsvXGpNTmLv7vDIiHILCeLR0mD1eAmWHuJjjUSmJx PyK6kAPaXX++E5aZ9gRuXqNFSGqiNx3oPvzQs0SH6vXgVec8fpmRk6y/Dg2r20Am hfJLPIeD8Z9Vf/0wM7EcjiS3eVYrTnYCX+aGAKpgk74zKHcnHTL9S77no0Lemby1 vlCK9ceouVd6OYdDcvjNg73umlci7JIenCZCU3nagloGwvH6XDFWdGkWSRLQ0G7T DoZlysM2Litafjr7NgyQ7R8xp1HnR+tmWfY26urIPd4rKU+aA05kPnQiTjgKTHo= =UDYD -END PGP SIGNATURE-
Re: [gentoo-dev] [PATCH] skel.metadata.xml: update for GLEP 67
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Michael Palimaka: > I tried to tidy it up a bit too. Any ideas on how to improve > further are appreciated. > I think we use very frequently these days. Maybe have something about that too? > Michael Palimaka (1): skel.metadata.xml: update for GLEP 67 > > skel.metadata.xml | 35 +-- 1 file > changed, 17 insertions(+), 18 deletions(-) > - -- gokturk -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJWpjslAAoJEIT4AuXAiM4zeTkH/2AHbL8MgznqRktZAYWQDlry U8cYVR1rAhMr0urPIrSEFsO8+n4VfK/+GgKRH084fq39AAnVUXZQK9E/t+Njjb39 J2e8kDtrfbF5KYAjuMBuHngvi1/RVHHcepa4qP3bIFeh/Hsdw5nXVClLLs3Wuqln d0KgW+6OQBFlhV30eVPY2pTiQ8/mw+8bMpIvyXlF+Z/jpXsxoSA229eNImsV/mvW /b4dF0DZYQuJkQBuqpAP50N0Z/JWKbsk3C0ymuqygbwo71u7m3bkgK849Vh9Xya6 KoPLOG04yZ0fOr727Vwhrq7YHIYJtR+zGrGUgyNcemQ19VM08ZlzN5PVr+r5irA= =6W7T -END PGP SIGNATURE-
[gentoo-dev] Re: [PATCH v2 17/19] ebuild-writing/misc-files: remove ChangeLog section #485314
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Ulrich Mueller: >> On Sun, 24 Jan 2016, Gokturk Yuksek wrote: > >> From: Michael Orlitzky > >> The ChangeLog section under misc-files is misleading now that >> our main repository has been switched to git (and we no longer >> have ChangeLogs). Remove the ebuild-writing/misc-files/changelog >> page. > > Most of that section contains information that will still apply, > even if it no longer goes into a ChangeLog but a into a git commit > message. > > Therefore the section shouldn't be removed, but rather be updated. > What if we extract the information regarding writing good commit messages and move it under ebuild-maintenance, possibly as a new subsection or under the subsection "Git Commit Policy"? I agree that the information there is valuable but a better documentation is available on the git workflow wiki[1]. We can alternatively insert a link to the wiki page instead or import the same information. But keeping the two in sync will be problematic. > Ulrich > [1] https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Commit_message_form at - -- gokturk -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJWpXQZAAoJEIT4AuXAiM4zgxIH/AwU3j8TMpYB7m+1Eeyg19wL nuY2YwDaev2KnEN8tmhqksCjyRJM9MvZpPXUfIvtaQBAFknYKPP3cI7leLQaQvUD pu0bMjfv3NIEM8Ux9tuWfeTYaBmnqOi1k9aFkCwIrpktDDjgz90KBq9ua40V1gEz aSAjaMZEs4YCZY/lTsgudPYCEQIiOkNfeC0riSSPnvG4Mp+LxZr3wcaudlFE57FZ hkNkjsTsLCqjmNCxI8FNYDiWqA+uueSkEWan3xjJV3bl8iJc82lcZoRayO5cwuDU CNNpDBABw9YDA6IrBNxpq/MxunKhdc2RuUFQmsw9I69WIWxwS555sxlMGugQGQ8= =9AN4 -END PGP SIGNATURE-
Re: [gentoo-dev] New packages up for grabs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Michał Górny: > Hello, everyone. > > As a result of disbanding a few herds, we some new > maintainer-needed packages. > > Here's the complete list: > > app-benchmarks/bonnie++ app-benchmarks/filebench If these haven't been taken already, I can proxy them. > > Please note that some of those packages may already have proposed > maintainers who did not update metadata.xml on time. > - -- gokturk -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJWpWW/AAoJEIT4AuXAiM4z2mcH/2+mcWXYuSH3o6HTvX8Xkstv y7Bvp0Qc1T+qhkY/PLiAQn8mQE8fc7dWE2ZkJQVQlkvJHtUxnle4zM9mdrQLaiph jdM65ip6oBQrBq0RcFygZKTywxMMGvX6ZiY7BW7KYu3j8Hem9t6briafVSMAlc18 BxXU1ECsx8BriKGmKsByk8zcLYlrz/oglKGV+GyS2xV/YCL6XO4koVw4b8HiOQuO OSu/CgdR5qnmFx6y9eDjqkruMB2oVaOwvrDluqKRBY14Z3mtQCBSh2DrljMVYJ6H 6pHgii2bSvbZh09eSZCHkToEhmparSbM+pmmMYmdPvd66ybjTPcOuITRjw2lQLk= =qNRM -END PGP SIGNATURE-
Re: [gentoo-dev] [PATCH v2 08/19] ebuild-maintenance: rewrite the text on adding binary files to the tree #558642
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Andrew Savchenko: > On Sun, 24 Jan 2016 16:00:31 +0100 Patrice Clement wrote: >> Sunday 24 Jan 2016 03:46:02, Gokturk Yuksek wrote : >>> Remove the paragraph about adding binary files to CVS. Replace >>> the instances of CVS with git. >>> >>> X-Gentoo-Bug-URL: >>> https://bugs.gentoo.org/show_bug.cgi?id=558642 Signed-off-by: >>> Gokturk Yuksek --- >>> ebuild-maintenance/text.xml | 19 +++ 1 file >>> changed, 3 insertions(+), 16 deletions(-) >>> >>> diff --git a/ebuild-maintenance/text.xml >>> b/ebuild-maintenance/text.xml index ac68dcd..10709ea 100644 >>> --- a/ebuild-maintenance/text.xml +++ >>> b/ebuild-maintenance/text.xml @@ -42,22 +42,9 @@ above 20KB) >>> which should be distributed as tarballs via the >> link="::general-concepts/mirrors/#suitable-download-hosts">Gentoo >>> >>> mirror system so that people do not waste excessive >>> amounts of bandwidth and hard drive space. Also, you should >>> not add binary (non-ASCII) files to the -Portage CVS tree. If >>> you need to do this in another CVS tree, for -example, if you >>> need to add a small PNG graphic for whatever reason, -be sure >>> to add it to CVS by using the -kb option, like so: - >>> - - -# cvs add >>> -kb myphoto.png - - - -The -kb option tells >>> CVS that myphoto.png is a binary -file and should >>> be treated specially. For example, merging the -differences >>> between two different versions of this file should not be >>> -allowed to happen, for obvious reasons. Also, speaking of >>> merging +git tree. Also, speaking of merging changes, any >>> patches you add to Portage should generally not be >>> -compressed. This will allow CVS to merge changes and >>> correctly inform +compressed. This will allow git to merge >>> changes and correctly inform developers of conflicts. >>> >>> @@ -149,7 +136,7 @@ simply, 1.0-gentoo.diff. >>> Also note that the gentoo extension informs people >>> that this patch was created by us, the Gentoo Linux >>> developers, rather than having been grabbed from a mailing list >>> or somewhere else. Again, you should not compress these >>> -patches because CVS does not play well with binary files. >>> +patches because git does not play well with binary files. >>> >>> >>> -- 2.4.10 >>> >>> >> >> "Again you should not compress these patches because git does >> not play well binary files". >> >> I'm not sure this statement still holds true with git. Does it? > > What about repoman checks? Will it still yell at >20 kB patches? > Yessir: https://gitweb.gentoo.org/proj/portage.git/tree/pym/repoman/checks/ebuilds/fetches.py?h=v2.2.27#n104 Even though it's not an issue with the git tree, rsync users will still suffer for >20kB patches. > Best regards, Andrew Savchenko > - -- gokturk -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJWpWG/AAoJEIT4AuXAiM4zL4kIAJOQXCo2veG56lBhFjbYcusi KZwJUbSpzLW6liZYlVYE6lYLsi7m/AW0jNhTWHt4P6vqsyhSzvS+GzchZbPzmzel j9dSurvwVEtrAucLbinQ95Ym8biRVREw6ieC3D+cMZbsd9+yvLdA9vWvIDneOA09 BsTmibtNHXg3xusDhuAK3hl8lxZhu5dK0n733Mm/S3gnDJ952dGyQjIMxZhxdwSd QOK2VTRfUJx0hAoNUPNqd0flOCBfijdOR7qFDZuVNsyqZwTW7Du+k8uz8uRV+hKp 4dktGALgDh4tTd6O8kCrQBTBQ2IVC03Fvs3xvAYFV84WNug3tEYRB2mDUpGBzck= =bpVR -END PGP SIGNATURE-
Re: [gentoo-dev] [PATCH v2 08/19] ebuild-maintenance: rewrite the text on adding binary files to the tree #558642
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Patrice Clement: > Sunday 24 Jan 2016 03:46:02, Gokturk Yuksek wrote : >> Remove the paragraph about adding binary files to CVS. Replace >> the instances of CVS with git. >> >> X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=558642 >> Signed-off-by: Gokturk Yuksek --- >> ebuild-maintenance/text.xml | 19 +++ 1 file >> changed, 3 insertions(+), 16 deletions(-) >> >> diff --git a/ebuild-maintenance/text.xml >> b/ebuild-maintenance/text.xml index ac68dcd..10709ea 100644 --- >> a/ebuild-maintenance/text.xml +++ b/ebuild-maintenance/text.xml >> @@ -42,22 +42,9 @@ above 20KB) which should be distributed as >> tarballs via the > link="::general-concepts/mirrors/#suitable-download-hosts">Gentoo >> mirror system so that people do not waste excessive amounts >> of bandwidth and hard drive space. Also, you should not add >> binary (non-ASCII) files to the -Portage CVS tree. If you need to >> do this in another CVS tree, for -example, if you need to add a >> small PNG graphic for whatever reason, -be sure to add it to CVS >> by using the -kb option, like so: - - -> caption="Adding binary files to CVS"> -# cvs add -kb >> myphoto.png - - - -The -kb option tells CVS >> that myphoto.png is a binary -file and should be >> treated specially. For example, merging the -differences between >> two different versions of this file should not be -allowed to >> happen, for obvious reasons. Also, speaking of merging +git >> tree. Also, speaking of merging changes, any patches you add to >> Portage should generally not be -compressed. This will >> allow CVS to merge changes and correctly inform +compressed. >> This will allow git to merge changes and correctly inform >> developers of conflicts. >> >> @@ -149,7 +136,7 @@ simply, 1.0-gentoo.diff. Also >> note that the gentoo extension informs people that >> this patch was created by us, the Gentoo Linux developers, rather >> than having been grabbed from a mailing list or somewhere else. >> Again, you should not compress these -patches because CVS does >> not play well with binary files. +patches because git does not >> play well with binary files. >> >> -- 2.4.10 >> >> > > "Again you should not compress these patches because git does not > play well binary files". > > I'm not sure this statement still holds true with git. Does it? > It should be possible to compress the patches and use gitattributes[1] to tell git to decompress them before diffing. But doing so is not needed since git compresses its objects in the first place. Maybe we can rewrite this as "You should not compress these patches because git compresses them upon commit transparently." With that being said, git may in fact not play well with binary files given that there is an extension to handle binary files[2]. [1] https://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes#Binary-Files [2] http://www.infoq.com/news/2015/04/github-large-file-storage - -- gokturk -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJWpP4NAAoJEIT4AuXAiM4zhNkH/jcQBQG/omfDSjbE/zBYjm+E L6omW3vmaSHUwAt7YG62Nmnp2dh3s7xBIl09f1VhAEDxvj9lQR+VtyWZhQFMEnQ8 OZb4o97h/PWUsI4qEuWRENGEzhI3vQDGDIRJhvxDlzgwTXUtMS89PvPIducc/HUf 9a81AHc8a7kRKFNmaaQj2pxuf1zQ6K7tZh9SMvZh31bqkPDgLNHVy1eJregB5IM/ 0lzZuODsXDuWMBE2awP9Y02MUEspjPt2RaAhSXa2StCaUcCmd6RmX+aSaQxb3C05 tXXNadXyws5Lg6HvtnQq6Xb1Sz/G5gUJRnJ9IFIK8B8fGYuqaJgb+uUqIAGboFY= =xn2m -END PGP SIGNATURE-
Re: [gentoo-dev] [RFD] Adopt-a-package, proxy-maintenance, and other musings
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Ian Delaney: > > 5. At the risk of sounding like Patrick, gentoo lacks some forms > of documentation pertaining to established proxy maintainers and to > forms of stats analysis. In discussions, points were raised > regarding the gathering of stats data re packages' tally of > downloads and instances of emerging into a gentoo system. Most of > the desired stats appear to lack any form of tools available to > gather and report data that would prove helpful in evaluating > packages of either the m-w or m-n lists. > > The topic of recruitment and recruiting are tied, but imo, quite > disparate. > > I don't want to go off-topic here too much but this is more than a missing tools issue. There are privacy concerns regarding the collection of such information. I recall this proposed idea from Google Summer of Code: https://wiki.gentoo.org/wiki/Google_Summer_of_Code/2012/Ideas#Package_statistics_reporting_tool > - -- gokturk -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJWpPLJAAoJEIT4AuXAiM4zoJUIAKU2HiHPp+zH6vsieBRzz0It ZgW66aiI7KWeTRlE0kPy+HHIHNG85M4686pgStHYnlJwAOEWej4aujYfWVKMXB/4 ty1511Pgb0o9yQuZLDV+5rprhcUyRggqu+dLQ16tjYRNuIHOGdZ+A0FM+H2E5Ty5 Ca4ab8wLq1TiV4oEbVst1b/z8tt1JAtBpjS0i4G9+sd80YA8wS2jG6NwgBqPB/2r VqKT7hR2RXVZodz1d+rQZUhF5GP7kABvNnY332Vzt8yjEAAMIOWeltnRdkL58R2C wzs34/rEAtWkn49EK6qw8/PFe2VA4U9XHqCSIbbJyTPxgIyZXnC3uWJpp4qIaz8= =0G0w -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [RFD] Adopt-a-package, proxy-maintenance, and other musings
Duncan: > NP-Hardass posted on Tue, 19 Jan 2016 00:44:49 -0500 as excerpted: > >> "adopt-a-package" type program. In functionality, this is no different >> than proxy-maintenance, however, this codifies it into an explicit >> policy whereby users are encouraged to step and take over a package. >> This obviously requires a greater developer presence in the proxy-maint >> project (or something similar), >> but, personally, I think that a stronger dev presence in proxy-maint >> would be better for Gentoo as a whole. > > That gave me the idea of a maintainer-needed eclass. When packages are > set to maintainer-needed, they can simply inherit this eclass and add > whatever function to the pkg_postinst, that will add a message that will > in effect say "adopt-me please", probably printing a proxy-maintainer > invitation URL to go to for more information. > > Talking about pkg_postinst messages, unless I missed it there's no simple > way to add a one ATM, without coding up the whole function, making it > problematic for eclasses, etc. For EAPI-7, what about either a helper > function that can be called, or an array variable that can be simply > added to, that simply adds the supplied message to a list of messages > printed at pkg_postinst time, and of course an appropriate > default_pkg_postinst to go along with it? Then ebuilds and eclasses can > call this helper or set this var in whatever phase they need to, and the > message will be printed at pkg_postinst time without having to worry > about setting up your own pkg_postinst or stepping on anything > pkg_postinst related setup elsewhere. > See: sys-apps/portage: show an elog message when merged package is maintained by maintainer-needed https://bugs.gentoo.org/show_bug.cgi?id=398633 Can we reconsider implementing this idea perhaps? -- gokturk
Re: [gentoo-dev] [PATCH 00/16] devmanual: update the docs for post git-migration #558642
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Justin Lecher (jlec): > On 17/01/16 08:55, Gokturk Yuksek wrote: >> Hi, > >> The following patch series attempt to update devmanual to >> replace the instances of CVS with their git equivalents. I tried >> to keep the changes small in favor of updating the docs over >> multiple iterations of patch series. The intention is to get the >> bare bone changes in so that the quiz questions can be answered. > >> Currently not included in the series are: - References to CVS in >> sections about herds since they will have to be rewritten per >> GLEP 67 soon anyway. See: >> https://bugs.gentoo.org/show_bug.cgi?id=572144 - I am not sure >> about what to do with the subsection Ebuild >> Functions/Miscellaneous Files/ChangeLog. The ChangeLog files >> still exist in the rsync tree, however they are of little >> importance in terms of development. > > > Thanks a bunch for all your work. > > Please direct the mail to devman...@gentoo.org. That alias takes > care of the devmanual changes. > I accidentally assumed it belongs to gentoo-doc, thanks for the heads up. In the following weeks, I would like to follow up with GLEP 67 and EAPI6 patches for devmanual and I can benefit from the review on gentoo-dev. Is it OK to send the email to devmanual@g.o and CC gentoo-dev@lists.g.o? > Justin > > - -- gokturk -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJWnBZUAAoJEIT4AuXAiM4zoBwIAMzOyqoykAUJhHIoQGY7IoqF bAys2BdJwv4UKL+Umt35IYgJDCN8GMklkwMToJ6flzRWMzcwCr2NN0yVXTSln3vz 1tdGxtv2w8afsbVgeE9eL7ZaBz9Zp/sdBwvMV6VMptC1esrLL2CqK7nx4s8x76UU k1B6cyJBQKjyFB843fP7Z4NNIVHELkpGVf7RXD2SUeS0gtnpxveqwR0GghYYfSI1 RTXNtVTwbve97C3ewxv4hGNs8WKEoWdt8pNDBU7YT+CwIB6+YiGJcEDeogL6SK/7 TpckdS6i329o9gxWLJlt4tz+DjNUErb0TMJVTVBnla/6ohDHEIhW0za/46M9O8E= =QGFi -END PGP SIGNATURE-
Re: [gentoo-dev] [PATCH 00/16] devmanual: update the docs for post git-migration #558642
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Michael Orlitzky: > On 01/17/2016 02:55 AM, Gokturk Yuksek wrote: >> Hi, >> >> The following patch series attempt to update devmanual to replace >> the instances of CVS with their git equivalents. > > Thank you! > >> - I am not sure about what to do with the subsection Ebuild >> Functions/Miscellaneous Files/ChangeLog. The ChangeLog files >> still exist in the rsync tree, however they are of little >> importance in terms of development. >> > > I should probably update the summary, but I looked at this as part > of, > > https://bugs.gentoo.org/show_bug.cgi?id=485314 > > and decided to get rid of it. Any mention of echangelog can go, > too. > > Thanks for pointing this out to me. I will include your patches in the v2 of the patchset and remove ChangeLog and echangelog unless there are objections. - -- gokturk -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJWnBWXAAoJEIT4AuXAiM4zY2YH/RfE1deC6cHJy1TDUu4LG6WW 1MmrKS6PO7TJ5YNDENToprqg2n/YaP4yAf7jd6KOFDZ/KnXoal2h0L6pUW55TDCZ TsanPjNLWkkICfZ33msB5jbqYU6jrcoQhqQK7to1J9CgHfQyVcBlDrxpHzYnMFO7 8nUZ1LTluroN1bXCiKljN41c6gFYM02hMep97RcxYR3KEiQSuiC9Ja4UA1SYHnjq jSmgbWo31IJUUV3K9VSIM4ZzcbNyB5U+rBKmoH7V/UzLqnW8AJWLJ21mAcHwZkSA iiuWuxqyltLZb/TXibRDnBu2cr8RXG6jx2EIzd3wu1QNwGWRbX6wfWLKFNmgKCI= =5LoC -END PGP SIGNATURE-
Re: [gentoo-dev] [PATCH 05/16] ebuild-writing/misc-files: replace the code for cvs commit with git #558642
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Manuel Rüger: > On 17.01.2016 08:55, Gokturk Yuksek wrote: >> Replace "cvs commit" with the equivalent "git add && git commit" >> version. >> >> X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=558642 >> Signed-off-by: Gokturk Yuksek >> >> diff --git a/ebuild-writing/misc-files/metadata/text.xml >> b/ebuild-writing/misc-files/metadata/text.xml index >> e506b1c..a8beacc 100644 --- >> a/ebuild-writing/misc-files/metadata/text.xml +++ >> b/ebuild-writing/misc-files/metadata/text.xml @@ -532,7 +532,8 @@ >> is currently: xmllint --noout --valid metadata.xml >> glep31check metadata.xml -cvs commit -m "Adding category >> metadata.xml for my-category" metadata.xml +git add metadata.xml >> +git commit --gpg-sign -m "Adding category metadata.xml for >> my-category" >> >> >> > > Can we discourage to use "-m" and prefer to open up an editor > instead? > I think the purpose of "-m" is only to illustrate the example of adding a category with a proper message rather than suggesting a workflow. Note that the section for committing packages suggests "repoman commit" which opens up an editor by default. Is there a particular reason why we should discourage the use of "-m"? > Cheers, > > Manuel > - -- gokturk -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJWnBQ3AAoJEIT4AuXAiM4zkeUH/AuswPQV3Fw+aeuI08l8xjpx q+BVZ8c7/5RNqgsQGF/0uKnkZI70WwbkLQwsk2nlHKXjuL5qUWmQ16YBC+fF03SG JD5eiFhqnzUK79Y5i2Rnfoc2o6DlcLzBSXHXMjtVldg4ufsq+v7mP+Jw901MyJu+ VBY6gkjmkqsahXeaPqmuoXslcr3yQtDHKVU4m9YOptZ/0jTDg4asnvhpv6ERwdNL uSrO4hzdbh314/o/R/4TWhGV56wlRVUaelzaVwDaBt2wxY5gYyKWhRizN5Exu8/w BlWSDqwfpKbvHMS2ArrDh0PvvWqEZAMhNuXX2hateO2wQIJlrWZ5KSId5ioW0fw= =s7Dj -END PGP SIGNATURE-
[gentoo-dev] Re: [PATCH 05/16] ebuild-writing/misc-files: replace the code for cvs commit with git #558642
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Michael Palimaka: > On 01/17/2016 06:55 PM, Gokturk Yuksek wrote: >> Replace "cvs commit" with the equivalent "git add && git commit" >> version. >> >> X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=558642 >> Signed-off-by: Gokturk Yuksek >> >> diff --git a/ebuild-writing/misc-files/metadata/text.xml >> b/ebuild-writing/misc-files/metadata/text.xml index >> e506b1c..a8beacc 100644 --- >> a/ebuild-writing/misc-files/metadata/text.xml +++ >> b/ebuild-writing/misc-files/metadata/text.xml @@ -532,7 +532,8 @@ >> is currently: xmllint --noout --valid metadata.xml >> glep31check metadata.xml -cvs commit -m "Adding category >> metadata.xml for my-category" metadata.xml +git add metadata.xml >> +git commit --gpg-sign -m "Adding category metadata.xml for >> my-category" >> >> >> > > I would suggest a commit message of something like: "my-category: > adding category metadata.xml". > I have seen its use in the git logs. If nobody has objections, I'll include it in that format for v2 of the patch series. - -- gokturk -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJWnBIHAAoJEIT4AuXAiM4zsgQH/30nRVmRzOnzXwXgpRlQcvcC kiFy3uAcYApzl69rDkK3ybz2MG6K3W5PCQjyzUXn99WeNefiysr+5ufPQka65Ytt QKQ8RfIOXOVW8t4rvQF/G018NMAUKq6qk9gEwvrs9SkuJ93x/r8D20d78Q5ZPALi OaKlIpmj4HUZ1nG+MeY+wazTqMDZrs/ArWVv/q4UGGa/M3IhG2qN8cClv3h/rdKJ nxl4+QGsDQlVJjw1hFPF0NXPq8LQhg2OluVuYy0DnZ70FGTqIOodnB/znaVGZI6o z7A/FV3RVV03wLYS6zqo5c/yPmcatGDo2Rk/4rLybG41qqy9NKZXLjZhk+L9loo= =olHD -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [PATCH 11/16] ebuild-maintenance: rewrite the subsection on moving ebuilds for git #558642
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Michael Palimaka: > On 01/17/2016 06:55 PM, Gokturk Yuksek wrote: >> Substitute the mentions of CVS with git. Rewrite CVS commands >> with their git equivalents. Remove the paragraph about deleting >> directories in CVS. >> >> X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=558642 >> Signed-off-by: Gokturk Yuksek >> >> diff --git a/ebuild-maintenance/text.xml >> b/ebuild-maintenance/text.xml index a1d92a1..8c542d0 100644 --- >> a/ebuild-maintenance/text.xml +++ b/ebuild-maintenance/text.xml >> @@ -298,7 +298,7 @@ Moving ebuilds is a two-step process: >> >> -Firstly, you need to move the ebuild in CVS. To do this, you >> should +Firstly, you need to move the ebuild in the git tree. To >> do this, you should copy the ebuild to its new location and >> commit that as you would with a > link="#adding-a-new-ebuild">new ebuild. @@ -323,23 >> +323,17 @@ for net-firewall/fwbuilder when they are >> available. >> >> Once this step is concluded, you are allowed to remove the >> old package. -Simply issue a cvs remove -Rf $PN in the >> package category and commit +Simply issue a git rm -rf $PN >> in the package category and commit the changes afterwards with a >> meaningful commit message. Don't forget to update entries in >> files such as profiles/package.mask to reflect the new category. >> Finally remember to change the title to open bugs related to this >> package if needed. >> >> -net-misc # cvs rm -Rf >> fwbuilder -cvs remove: use `cvs commit' to remove these files >> permanently -net-misc # cvs ci -m "Moving net-misc/fwbuilder to >> net-firewall/fwbuilder." +net-misc # git rm -rf fwbuilder >> +net-misc # git commit --gpg-sign -m "Moving net-misc/fwbuilder >> to net-firewall/fwbuilder." >> >> - -CVS cannot destroy directories: it will simply not >> re-create them if -they are blank, providing you use CVS with the >> -P flag. - - >> >> > > How about git mv instead? > > The workflow in the devmanual is: copy-mask-remove. Git mv workflow is similar to: copy-remove-mask. If encapsulated in a single commit, the atomicity is preserved and it shouldn't violate anything. I actually wrote it using git mv first and rewrote to match the current workflow of devmanual. If there is no objection to this, I'll rewrite it with git mv. - -- gokturk -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJWnBBbAAoJEIT4AuXAiM4zD0YIAM3oUGd5woCtq4/Xou5+R86D 6ofPQQTsjZ7C/GE9dImmch0Mn1iG2Pt8kxP1G/M9br0Vs8D7qPQFO+5Xmm+SBhO7 8s0KSwYnipWqzEKuDtbNwBXJ2mj9eG/0NQKdOXbxKWWk/QMewy+DSqZekiQaL512 JmacEPm/TzAukYQqpwx8rGw3kp+Nz7v+TTQ47epElQ/wnRPZyU05JPyeYFbsV97y aG17JIRx+FnL6rOKJJE/pyZ3Bbqu1autkgw0cL9Wk5EdxVm3WeR/nHj847EcziTd Ws312So+GEhb2smFdLxXBN6y/tiTb1xeeNds2sMsSu2KNfNN3E7VWOXSsjK8mMI= =SuBZ -END PGP SIGNATURE-
Re: [gentoo-dev] packages to grab
Hi, > > I will move all packages I maintain [1] to the associated projects if > possible. All devs are free to take what ever you are interested in. I > am also happy to proxy contributors if they like to maintain a package. > I would like to proxy-maintain dev-vcs/gitstats if possible. > > Cheers, > Justin > > 1) > http://euscan.gentooexperimental.org/maintainers/jlec%40gentoo.org/ Thanks, -- gokturk
