[gentoo-dev] [PATCHES] kernel-2.eclass: Various changes requested by users. + [STABLEREQ?] sys-kernel/gentoo-sources-3.8.7: Any objections against stabilizing?

[gentoo-dev] [PATCHES] kernel-2.eclass: Various changes requested by users. + [STABLEREQ?] sys-kernel/gentoo-sources-3.8.7: Any objections against stabilizing?

[Tom Wijsman]

[-- Attachment #1.1: Type: text/plain, Size: 2656 bytes --]

Hello everyone


Attached you will find the various changes I plan to apply to
kernel-2.eclass after a week if there are no objections, feel free to
take a look at them. A summary of the changes:

- Added a warning after the variables that modifying other variables in
  the eclass is not supported, there is a chance that we will not fix
  resulting bugs. Fixes bug #421721.

- Make use of readme.gentoo.eclass to make the user aware of the Gentoo
  Linux Kernel Upgrade Guide only the first time he emerges the
  package. Fixes bug #457598.

- Clarify the default DESCRIPTION and make it not use versions, a
  directory with ebuilds that inherit this eclass may contain multiple
  versions and we also don't want to give the impression that a new
  directory needs to made if that's not the case. Fixes bug #445110.

- Clarified which patch depths are used in the normal output and error
  output when applying patches. Fixes bug #436402.

- Made sure .tmp_gas_check is created inside the temp folder, it
  accidentally created temp.tmp_gas_check instead. Fixes bug #336732.

- Make UNIPATCH_DOCS work again, install 0000_README document when
  using genpatches. Fixes bug #301478.

Since these are quite a few changes, it doesn't hurt posting them here.

I'll also summarize the past commits I made, for those who missed them:

- Kernel sources and (gen)patches now use xz instead of bz2. Fixes bug
  #421721.

- Added sys-devel/bc as a RDEPEND to kernel-2.eclass. Fixes bug
  #461848.

- Use UID 0 instead of root to assign permissions to super user. Fixes
  bug #315807.

The commit diffs can be obtained at http://sources.gentoo.org/

There is a guideline that reporting small changes to barely used
eclasses here is not required, but that made some out-of-tree users
unhappy; sorry for that, I'll try to get every eclass change reviewed
in the future to avoid these issues. Small changes, like the above, I
will try to combine together to avoid unnecessary mail and commit spam.

That being said, since 3.8.7 has landed upstream we would like to hear
about any issues we don't know about yet that would block stabilization;
if we can, I plan to start stabilization in less than two weeks. Unless
there are valid reasons for this to be done earlier/later.

I'll add 3.2.43 and 3.8.7 to the tree in a moment, as it is late 3.0.73
and 3.4.40 will be for tomorrow...

Have a nice day. :)

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #1.2: kernel-2.eclass.patches --]
[-- Type: application/octet-stream, Size: 8385 bytes --]

commit 3e92b0b08438d7cf66d325cfc7bbe38bec6b0800
Author: Tom Wijsman <TomWij@live.com>
Date:   Fri Apr 12 15:25:01 2013 +0200

    Added a warning after the variables that modifying other variables in the eclass is not supported, there is a chance that we will not fix resulting bugs. Fixes bug #421721.

diff --git a/kernel-2.eclass b/kernel-2.eclass
index 1e6db22..22be9ed 100644
--- a/kernel-2.eclass
+++ b/kernel-2.eclass
@@ -69,6 +69,10 @@
 # UNIPATCH_STRICTORDER	- if this is set places patches into directories of
 #						  order, so they are applied in the order passed
 
+# Changing any other variable in this eclass is not supported; you can request
+# for additional variables to be added by contacting the current maintainer.
+# If you do change them, there is a chance that we will not fix resulting bugs.
+
 inherit eutils toolchain-funcs versionator multilib
 EXPORT_FUNCTIONS pkg_setup src_unpack src_compile src_test src_install pkg_preinst pkg_postinst pkg_postrm
 

commit ccf6386791e8420269799c219518f42f01103810
Author: Tom Wijsman <TomWij@live.com>
Date:   Fri Apr 12 16:40:56 2013 +0200

    Make use of readme.gentoo.eclass to make the user aware of the Gentoo Linux Kernel Upgrade Guide only the first time he emerges the package. Fixes bug #457598.

diff --git a/kernel-2.eclass b/kernel-2.eclass
index 22be9ed..dc480fb 100644
--- a/kernel-2.eclass
+++ b/kernel-2.eclass
@@ -73,7 +73,7 @@
 # for additional variables to be added by contacting the current maintainer.
 # If you do change them, there is a chance that we will not fix resulting bugs.
 
-inherit eutils toolchain-funcs versionator multilib
+inherit eutils toolchain-funcs versionator multilib readme.gentoo
 EXPORT_FUNCTIONS pkg_setup src_unpack src_compile src_test src_install pkg_preinst pkg_postinst pkg_postrm
 
 # Added by Daniel Ostrow <dostrow@gentoo.org>
@@ -100,6 +100,13 @@ RESTRICT="binchecks strip"
 # set LINUX_HOSTCFLAGS if not already set
 : ${LINUX_HOSTCFLAGS:="-Wall -Wstrict-prototypes -Os -fomit-frame-pointer -I${S}/include"}
 
+# Kernel upgrade documentation
+#==============================================================
+DISABLE_AUTOFORMATTING="yes"
+DOC_CONTENTS="
+When you plan to upgrade the kernel, you may be interested in the Gentoo Linux
+Kernel Upgrade Guide: http://www.gentoo.org/doc/en/kernel-upgrade.xml"
+
 # debugging functions
 #==============================================================
 # this function exists only to help debug kernel-2.eclass
@@ -781,12 +788,6 @@ postinst_sources() {
 	# Don't forget to make directory for sysfs
 	[[ ! -d ${ROOT}sys ]] && kernel_is 2 6 && mkdir ${ROOT}sys
 
-	echo
-	elog "If you are upgrading from a previous kernel, you may be interested"
-	elog "in the following document:"
-	elog "  - General upgrade guide: http://www.gentoo.org/doc/en/kernel-upgrade.xml"
-	echo
-
 	# if K_EXTRAEINFO is set then lets display it now
 	if [[ -n ${K_EXTRAEINFO} ]]; then
 		echo ${K_EXTRAEINFO} | fmt |
@@ -1191,10 +1192,12 @@ kernel-2_src_install() {
 	install_universal
 	[[ ${ETYPE} == headers ]] && install_headers
 	[[ ${ETYPE} == sources ]] && install_sources
+	readme.gentoo_create_doc
 }
 
 kernel-2_pkg_postinst() {
 	[[ ${ETYPE} == sources ]] && postinst_sources
+	readme.gentoo_print_elog
 }
 
 kernel-2_pkg_setup() {

commit ce71bc155415849dbee18a142459f8ed6296df22
Author: Tom Wijsman <TomWij@live.com>
Date:   Fri Apr 12 17:06:24 2013 +0200

    Clarify the default DESCRIPTION and make it not use versions, a directory with ebuilds that inherit this eclass may contain multiple versions and we also don't want to give the impression that a new directory needs to made if that's not the case. Fixes bug #445110.

diff --git a/kernel-2.eclass b/kernel-2.eclass
index dc480fb..195fd7f 100644
--- a/kernel-2.eclass
+++ b/kernel-2.eclass
@@ -432,7 +432,7 @@ if [[ ${ETYPE} == sources ]]; then
 	PDEPEND="!build? ( virtual/dev-manager )"
 
 	SLOT="${PVR}"
-	DESCRIPTION="Sources for the ${KV_MAJOR}.${KV_MINOR:-$KV_PATCH} linux kernel"
+	DESCRIPTION="Sources based on the Linux Kernel."
 	IUSE="symlink build"
 
 	# Bug #266157, deblob for libre support

commit b0d6bbe5804383549974592e10833678562ceb83
Author: Tom Wijsman <TomWij@live.com>
Date:   Fri Apr 12 17:52:02 2013 +0200

    Clarified which patch depths are used in the normal output and error output when applying patches. Fixes bug #436402.

diff --git a/kernel-2.eclass b/kernel-2.eclass
index 195fd7f..d00f9e8 100644
--- a/kernel-2.eclass
+++ b/kernel-2.eclass
@@ -990,12 +990,12 @@ unipatch() {
 
 			if [ -z "${PATCH_DEPTH}" ]; then PATCH_DEPTH=0; fi
 
-			ebegin "Applying ${i/*\//} (-p${PATCH_DEPTH}+)"
 			while [ ${PATCH_DEPTH} -lt 5 ]; do
 				echo "Attempting Dry-run:" >> ${STDERR_T}
 				echo "cmd: patch -p${PATCH_DEPTH} --no-backup-if-mismatch --dry-run -f < ${i}" >> ${STDERR_T}
 				echo "=======================================================" >> ${STDERR_T}
 				if [ $(patch -p${PATCH_DEPTH} --no-backup-if-mismatch --dry-run -f < ${i} >> ${STDERR_T}) $? -eq 0 ]; then
+					ebegin "Applying ${i/*\//} (-p${PATCH_DEPTH})"
 					echo "Attempting patch:" > ${STDERR_T}
 					echo "cmd: patch -p${PATCH_DEPTH} --no-backup-if-mismatch -f < ${i}" >> ${STDERR_T}
 					echo "=======================================================" >> ${STDERR_T}
@@ -1008,17 +1008,17 @@ unipatch() {
 						eerror "Failed to apply patch ${i/*\//}"
 						eerror "Please attach ${STDERR_T} to any bug you may post."
 						eshopts_pop
-						die "Failed to apply ${i/*\//}"
+						die "Failed to apply ${i/*\//} on patch depth ${PATCH_DEPTH}."
 					fi
 				else
 					PATCH_DEPTH=$((${PATCH_DEPTH} + 1))
 				fi
 			done
 			if [ ${PATCH_DEPTH} -eq 5 ]; then
-				eend 1
+				eerror "Failed to dry-run patch ${i/*\//}"
 				eerror "Please attach ${STDERR_T} to any bug you may post."
 				eshopts_pop
-				die "Unable to dry-run patch."
+				die "Unable to dry-run patch on any patch depth lower than 5."
 			fi
 		done
 	done

commit bedaf8052261a1889d7125683ee0f1acfc561579
Author: Tom Wijsman <TomWij@live.com>
Date:   Fri Apr 12 18:36:04 2013 +0200

    Made sure .tmp_gas_check is created inside the temp folder, it accidentally created temp.tmp_gas_check instead. Fixes bug #336732.

diff --git a/kernel-2.eclass b/kernel-2.eclass
index d00f9e8..c77e7e3 100644
--- a/kernel-2.eclass
+++ b/kernel-2.eclass
@@ -1157,11 +1157,11 @@ kernel-2_src_unpack() {
 	if [[ -n ${KV_MINOR} &&  ${KV_MAJOR}.${KV_MINOR}.${KV_PATCH} < 2.6.27 ]]
 	then
 		sed -i \
-			-e 's|TOUT	:= .tmp_gas_check|TOUT	:= $(T).tmp_gas_check|' \
+			-e "s|TOUT	:= .tmp_gas_check|TOUT	:= \"${T}\"/.tmp_gas_check|" \
 			"${S}"/arch/ppc/Makefile
 	else
 		sed -i \
-			-e 's|TOUT	:= .tmp_gas_check|TOUT	:= $(T).tmp_gas_check|' \
+			-e "s|TOUT	:= .tmp_gas_check|TOUT	:= \"${T}\"/.tmp_gas_check|" \
 			"${S}"/arch/powerpc/Makefile
 	fi
 }

commit 6fc0d0fe5636313555f087105ad6b048f876c6fb
Author: Tom Wijsman <TomWij@live.com>
Date:   Fri Apr 12 20:01:46 2013 +0200

    Make UNIPATCH_DOCS work again, install 0000_README document when using genpatches. Fixes bug #301478.

diff --git a/kernel-2.eclass b/kernel-2.eclass
index c77e7e3..c0dc87b 100644
--- a/kernel-2.eclass
+++ b/kernel-2.eclass
@@ -747,6 +747,10 @@ install_sources() {
 	fi
 
 	mv ${WORKDIR}/linux* "${D}"/usr/src
+
+	if [[ -z ${UNIPATCH_DOCS} ]] ; then
+		dodoc ${UNIPATCH_DOCS}
+	fi
 }
 
 # pkg_preinst functions
@@ -1023,13 +1027,23 @@ unipatch() {
 		done
 	done
 
-	# This is a quick, and kind of nasty hack to deal with UNIPATCH_DOCS which
-	# sit in KPATCH_DIR's. This is handled properly in the unipatch rewrite,
-	# which is why I'm not taking too much time over this.
+	# When genpatches is used, we want to install 0000_README which documents
+	# the patches that were used; such that the user can see them, bug #301478.
+	if [[ ! -z ${K_WANT_GENPATCHES} ]] ; then
+		UNIPATCH_DOCS="${UNIPATCH_DOCS} 0000_README"
+	fi
+
+	# When files listed in UNIPATCH_DOCS are found in KPATCH_DIR's, we copy it
+	# to the temporary directory and remember them in UNIPATCH_DOCS to install
+	# them during the install phase.
 	local tmp
-	for i in ${UNIPATCH_DOCS}; do
-		tmp="${tmp} ${i//*\/}"
-		cp -f ${i} "${T}"/
+	for x in ${KPATCH_DIR}; do
+		for i in ${UNIPATCH_DOCS}; do
+			if [[ -f "${x}/${i}" ]] ; then
+				tmp="${tmp} \"${T}/${i}\""
+				cp -f "${x}/${i}" "${T}"/
+			fi
+		done
 	done
 	UNIPATCH_DOCS="${tmp}"
 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] [PATCHES] kernel-2.eclass: Various changes requested by users. + [STABLEREQ?] sys-kernel/gentoo-sources-3.8.7: Any objections against stabilizing?

[Fabio Erculiani]

On Fri, Apr 12, 2013 at 10:41 PM, Tom Wijsman <TomWij@gentoo.org> wrote:
> Hello everyone
>
>
> Attached you will find the various changes I plan to apply to
> kernel-2.eclass after a week if there are no objections, feel free to
> take a look at them. A summary of the changes:
>
> - Added a warning after the variables that modifying other variables in
>   the eclass is not supported, there is a chance that we will not fix
>   resulting bugs. Fixes bug #421721.

Why?
Just to annoy people who have successfully used kernel-2.eclass until
now, and in my case for half a decade (or even more)?
If you need help with maintaining the current eclass functionality,
I'd be more than happy. I don't really want to fork it myself :-).

>
[..]
>
> - Kernel sources and (gen)patches now use xz instead of bz2. Fixes bug
>   #421721.

As I said in the bug, next time you plan a migration like that, it
would be nice to send an heads up on the ML beforehand.
Like you did in this case, but actually, _beforehand_ and not ~one month later.

[...]

>
> Have a nice day. :)
>
> --
> With kind regards,
>
> Tom Wijsman (TomWij)
> Gentoo Developer
>
> E-mail address  : TomWij@gentoo.org
> GPG Public Key  : 6D34E57D
> GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D



-- 
Fabio Erculiani

Re: [gentoo-dev] [PATCHES] kernel-2.eclass: Various changes requested by users. + [STABLEREQ?] sys-kernel/gentoo-sources-3.8.7: Any objections against stabilizing?

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 2688 bytes --]

On Sat, 13 Apr 2013 08:03:22 +0100
Fabio Erculiani <lxnay@gentoo.org> wrote:

> Why?

Because people (eg. you) use the undocumented variable KERNEL_BASE_URI.

> Just to annoy people who have successfully used kernel-2.eclass until
> now, and in my case for half a decade (or even more)?

If you use an undocumented variable, it is bound to fail at some point;
this comment clarifies that we are not bound to fix resulting bugs,
that of course does not mean we're not willing to help.

As shown on the bug, it's quite the opposite, I've shown for multiple
comments that I am willing to collaborate if you state me what the
problem is. If I then get no answer to that, please don't feel annoyed;
I may have came over as annoyed myself near the end, sorry for that.

Your problem wasn't clear before I found above undocumented change;
because as I said so on the bug, I covered the whole migration and am
willing to convert still missing genpatches files and put them on the
mirror right away.

A change in KERNEL_BASE_URI is something which you can not cover in
advance, because I do not know which changes are out there it is
impossible for me to contact them all; the MLs target the wrong people.

We're sorry this broke it for you and will use these lists from now on.

> If you need help with maintaining the current eclass functionality,
> I'd be more than happy. I don't really want to fork it myself :-).

You'll want to ask Mike Pagano about that, not my take; he's both the
lead of the kernel team and has been my mentor, he acknowledged the
commit we are discussing here too without prior mails.

Your suggested patch likely does not work with genpatches, since I don't
think that the infra team will want to host files for forks of
Gentoo; if they do, please let them tell me that, IRC or GPG signed.

You will either want to fork this yourself or request the genpatches
URI to become a documented variable such that you can host your own
genpatches, either way I think you will need to convert them yourself.

> As I said in the bug, next time you plan a migration like that, it
> would be nice to send an heads up on the ML beforehand.

Everything in the Portage tree was migrated just fine, there is also no
certainty I will reach all people outside of the tree by this. But as
said on that same bug, along a sorry, I will do so in the future...

Happy to help, you may see me contribute to Sabayon/systemd-love. :-)

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

[gentoo-dev] Re: [PATCHES] kernel-2.eclass: Various changes requested by users. + [STABLEREQ?] sys-kernel/gentoo-sources-3.8.7: Any objections against stabilizing?

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 426 bytes --]

On Fri, 12 Apr 2013 23:41:05 +0200
Tom Wijsman <TomWij@gentoo.org> wrote:

> - Make use of readme.gentoo.eclass to make the user aware of the Gentoo
>   Linux Kernel Upgrade Guide only the first time he emerges the
>   package. Fixes bug #457598.

Call me crazy, but upgrade guides seem like something you might want to tell the
user about during an upgrade.


-- 
gcc-porting
toolchain, wxwidgets
@ gentoo.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: [PATCHES] kernel-2.eclass: Various changes requested by users. + [STABLEREQ?] sys-kernel/gentoo-sources-3.8.7: Any objections against stabilizing?

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1748 bytes --]

On Sat, 13 Apr 2013 23:09:05 -0600
Ryan Hill <dirtyepic@gentoo.org> wrote:
>
> > - Make use of readme.gentoo.eclass to make the user aware of the
> >   Gentoo Linux Kernel Upgrade Guide only the first time he emerges
> >   the package. Fixes bug #457598.
>
> Call me crazy, but upgrade guides seem like something you might want
> to tell the user about during an upgrade.

True, I was wondering if there is a way to show it on their first
upgrade instead; most users would indeed not be able or forget to
bookmark this during their handbook install.

Therefore, I won't commit this patch.

I wonder if Pacho can adapt the eclass to allow us to do this on the
first upgrade, I have explicitly put him in CC so he can consider that.
Perhaps he can also explain why he wanted to see this change happen.

I thought the goal of this eclass is to get rid of repeating messages
that are not that important from the elog. After you have installed the
kernel twice you should be able to do it a third time. People that
really still need the link have it either bookmarked or can look into
that file, another concern here is that nothing mentions its existence.
The user would have to spot it in the list of installed files, strange.

If I misunderstood the goal of this eclass, sorry, it's not documented.
I thought people were against these kind of repeating messages in elog.

 - http://devmanual.gentoo.org/eclass-reference/readme.gentoo.eclass

 - Bug in discussion: https://bugs.gentoo.org/show_bug.cgi?id=457598

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: [PATCHES] kernel-2.eclass: Various changes requested by users. + [STABLEREQ?] sys-kernel/gentoo-sources-3.8.7: Any objections against stabilizing?

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 545 bytes --]

Am Sonntag, 14. April 2013, 10:24:18 schrieb Ryan Hill:
>
> Personally I think that the entire idea of only displaying messages on the
> first install is completely asinine.  What exactly is the benefit?  Were
> users complaining that we were being too helpful and they'd like us to
> hide important messages in random places?

No. They are just not reading it when the only new and relevant message is 
drowned in repetitive spam.

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

[gentoo-dev] Re: [PATCHES] kernel-2.eclass: Various changes requested by users. + [STABLEREQ?] sys-kernel/gentoo-sources-3.8.7: Any objections against stabilizing?

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 2011 bytes --]

On Sun, 14 Apr 2013 08:55:39 +0200
Tom Wijsman <TomWij@gentoo.org> wrote:

> On Sat, 13 Apr 2013 23:09:05 -0600
> Ryan Hill <dirtyepic@gentoo.org> wrote:
> >
> > > - Make use of readme.gentoo.eclass to make the user aware of the
> > >   Gentoo Linux Kernel Upgrade Guide only the first time he emerges
> > >   the package. Fixes bug #457598.
> >
> > Call me crazy, but upgrade guides seem like something you might want
> > to tell the user about during an upgrade.
> 
> True, I was wondering if there is a way to show it on their first
> upgrade instead; most users would indeed not be able or forget to
> bookmark this during their handbook install.
> 
> Therefore, I won't commit this patch.
> 
> I wonder if Pacho can adapt the eclass to allow us to do this on the
> first upgrade, I have explicitly put him in CC so he can consider that.
> Perhaps he can also explain why he wanted to see this change happen.
> 
> I thought the goal of this eclass is to get rid of repeating messages
> that are not that important from the elog. After you have installed the
> kernel twice you should be able to do it a third time. People that
> really still need the link have it either bookmarked or can look into
> that file, another concern here is that nothing mentions its existence.
> The user would have to spot it in the list of installed files, strange.
> 
> If I misunderstood the goal of this eclass, sorry, it's not documented.
> I thought people were against these kind of repeating messages in elog.
> 
>  - http://devmanual.gentoo.org/eclass-reference/readme.gentoo.eclass
> 
>  - Bug in discussion: https://bugs.gentoo.org/show_bug.cgi?id=457598

Personally I think that the entire idea of only displaying messages on the
first install is completely asinine.  What exactly is the benefit?  Were users
complaining that we were being too helpful and they'd like us to hide important
messages in random places?


-- 
gcc-porting
toolchain, wxwidgets
@ gentoo.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: [PATCHES] kernel-2.eclass: Various changes requested by users. + [STABLEREQ?] sys-kernel/gentoo-sources-3.8.7: Any objections against stabilizing?

[Pacho Ramos]

El dom, 14-04-2013 a las 08:55 +0200, Tom Wijsman escribió:
> On Sat, 13 Apr 2013 23:09:05 -0600
> Ryan Hill <dirtyepic@gentoo.org> wrote:
> >
> > > - Make use of readme.gentoo.eclass to make the user aware of the
> > >   Gentoo Linux Kernel Upgrade Guide only the first time he emerges
> > >   the package. Fixes bug #457598.
> >
> > Call me crazy, but upgrade guides seem like something you might want
> > to tell the user about during an upgrade.
> 
> True, I was wondering if there is a way to show it on their first
> upgrade instead; most users would indeed not be able or forget to
> bookmark this during their handbook install.
> 
> Therefore, I won't commit this patch.
> 
> I wonder if Pacho can adapt the eclass to allow us to do this on the
> first upgrade,

If I were able to know how to detect only "first update" that would be
nice, but I don't have any idea to achieve that for now :(

>  I have explicitly put him in CC so he can consider that.
> Perhaps he can also explain why he wanted to see this change happen.
> 

Because I see no gain on getting the link to the same upgrade guide on
every update: some times after you upgrade the kernel, I think we all
are able to remember how to upgrade kernels . Maybe one option could
even add a link pointing to the kernel upgrade guide from Handbook in
its kernel section. That way, people could see they will need to follow
some steps to upgrade kernels when an update for them arrives and, then,
visit it in next kernel update (but, once they update the kernel, they
won't need to revisit it on every update as they will likely remember
how to do that)



> I thought the goal of this eclass is to get rid of repeating messages
> that are not that important from the elog. After you have installed the
> kernel twice you should be able to do it a third time. People that
> really still need the link have it either bookmarked or can look into
> that file, 

Yes, that was my point

Re: [gentoo-dev] Re: [PATCHES] kernel-2.eclass: Various changes requested by users. + [STABLEREQ?] sys-kernel/gentoo-sources-3.8.7: Any objections against stabilizing?

[Pacho Ramos]

El dom, 14-04-2013 a las 02:24 -0600, Ryan Hill escribió:
> On Sun, 14 Apr 2013 08:55:39 +0200
> Tom Wijsman <TomWij@gentoo.org> wrote:
> 
> > On Sat, 13 Apr 2013 23:09:05 -0600
> > Ryan Hill <dirtyepic@gentoo.org> wrote:
> > >
> > > > - Make use of readme.gentoo.eclass to make the user aware of the
> > > >   Gentoo Linux Kernel Upgrade Guide only the first time he emerges
> > > >   the package. Fixes bug #457598.
> > >
> > > Call me crazy, but upgrade guides seem like something you might want
> > > to tell the user about during an upgrade.
> > 
> > True, I was wondering if there is a way to show it on their first
> > upgrade instead; most users would indeed not be able or forget to
> > bookmark this during their handbook install.
> > 
> > Therefore, I won't commit this patch.
> > 
> > I wonder if Pacho can adapt the eclass to allow us to do this on the
> > first upgrade, I have explicitly put him in CC so he can consider that.
> > Perhaps he can also explain why he wanted to see this change happen.
> > 
> > I thought the goal of this eclass is to get rid of repeating messages
> > that are not that important from the elog. After you have installed the
> > kernel twice you should be able to do it a third time. People that
> > really still need the link have it either bookmarked or can look into
> > that file, another concern here is that nothing mentions its existence.
> > The user would have to spot it in the list of installed files, strange.
> > 
> > If I misunderstood the goal of this eclass, sorry, it's not documented.
> > I thought people were against these kind of repeating messages in elog.
> > 
> >  - http://devmanual.gentoo.org/eclass-reference/readme.gentoo.eclass
> > 
> >  - Bug in discussion: https://bugs.gentoo.org/show_bug.cgi?id=457598
> 
> Personally I think that the entire idea of only displaying messages on the
> first install is completely asinine.  What exactly is the benefit?  Were users
> complaining that we were being too helpful and they'd like us to hide important
> messages in random places?
> 

When you get tons of messages in summary.log, there are times that is
easier to ignore important messages over all the less important ones

Re: [gentoo-dev] Re: [PATCHES] kernel-2.eclass: Various changes requested by users. + [STABLEREQ?] sys-kernel/gentoo-sources-3.8.7: Any objections against stabilizing?

[Pacho Ramos]

El dom, 14-04-2013 a las 04:08 -0600, Ryan Hill escribió:
> On Sun, 14 Apr 2013 10:23:00 +0200
> "Andreas K. Huettel" <dilfridge@gentoo.org> wrote:
> 
> > Am Sonntag, 14. April 2013, 10:24:18 schrieb Ryan Hill:
> > >
> > > Personally I think that the entire idea of only displaying messages on the
> > > first install is completely asinine.  What exactly is the benefit?  Were
> > > users complaining that we were being too helpful and they'd like us to
> > > hide important messages in random places?
> > 
> > No. They are just not reading it when the only new and relevant message is 
> > drowned in repetitive spam.
> 
> So the solution is to not display them at all?  New messages won't be printed
> unless the maintainer uses REPLACING_VERSIONS, in which case you get exactly
> the same behaviour as now, ie. "drowned in repetitive spam".  All this does is
> reduce the chance of the user ever seeing important information.  If they
> happen to miss it the first time they're SOL.  Are cosmetics really a bigger
> concern than keeping users informed?
> 
> 

The messages are shown the first time by elog *and* saved
in /usr/share/doc/*/README.gentoo, adding the advantage of users having
that docs always present without needing to re-emerge the package or
manually read ebuilds

[gentoo-dev] Re: [PATCHES] kernel-2.eclass: Various changes requested by users. + [STABLEREQ?] sys-kernel/gentoo-sources-3.8.7: Any objections against stabilizing?

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1037 bytes --]

On Sun, 14 Apr 2013 10:23:00 +0200
"Andreas K. Huettel" <dilfridge@gentoo.org> wrote:

> Am Sonntag, 14. April 2013, 10:24:18 schrieb Ryan Hill:
> >
> > Personally I think that the entire idea of only displaying messages on the
> > first install is completely asinine.  What exactly is the benefit?  Were
> > users complaining that we were being too helpful and they'd like us to
> > hide important messages in random places?
> 
> No. They are just not reading it when the only new and relevant message is 
> drowned in repetitive spam.

So the solution is to not display them at all?  New messages won't be printed
unless the maintainer uses REPLACING_VERSIONS, in which case you get exactly
the same behaviour as now, ie. "drowned in repetitive spam".  All this does is
reduce the chance of the user ever seeing important information.  If they
happen to miss it the first time they're SOL.  Are cosmetics really a bigger
concern than keeping users informed?


-- 
gcc-porting
toolchain, wxwidgets
@ gentoo.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: [PATCHES] kernel-2.eclass: Various changes requested by users. + [STABLEREQ?] sys-kernel/gentoo-sources-3.8.7: Any objections against stabilizing?

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1633 bytes --]

On Sun, 14 Apr 2013 12:06:48 +0200
Pacho Ramos <pacho@gentoo.org> wrote:

> The messages are shown the first time by elog *and* saved
> in /usr/share/doc/*/README.gentoo, adding the advantage of users
> having that docs always present without needing to re-emerge the
> package or manually read ebuilds

How are users aware that such file is installed?

It's hidden in front of the huge list (since 'src' comes after
'share'); so, they won't see it in there unless they have a huge
scroll back buffer or look into the log. Or look into the directory
although they may assume there to be no such thing and not even look.

Can we please make the users aware of it being installed?

if ! [[ -n "${HIDE_INFO_MSG}" ]] ; then 
    einfo "Useful documentation can be found in /usr/share/doc/${PF}"
fi

May not be the exact wording one would want, but at least people
are then aware where they need to look for more information.

The use of "einfo" should give the advantage of not filling the elog
file, while still appearing for the user upon an emerge.

If people don't agree with this apporach, we may want to solve the
actual problem in a different manner; one could write `eselect elog`
just like we have `eselect news`, that would force them to process
through the log messages and just not simply ignore them. Listing that
there are unread elog messages upon the next emerge may be interesting.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: [PATCHES] kernel-2.eclass: Various changes requested by users. + [STABLEREQ?] sys-kernel/gentoo-sources-3.8.7: Any objections against stabilizing?

[Alan McKinnon]

On 14/04/2013 12:52, Tom Wijsman wrote:
> If people don't agree with this apporach, we may want to solve the
> actual problem in a different manner; one could write `eselect elog`
> just like we have `eselect news`, that would force them to process
> through the log messages and just not simply ignore them. Listing that
> there are unread elog messages upon the next emerge may be interesting.

Speaking as a long time Gentoo user:

I like this idea of displaying an elog summary reminder at the end of
emerge. It's analogous to the preserved-rebuild, blocker, and failed
emerge notices that are already there. There are insanely useful -
emerge inside screen, reconnect later and just know the important stuff
I need to tend to is right there on the screen.

If possible I'd like to see categories of messages; some are pointless
to me now like the mention of the kernel upgraded guide after installing
kernel sources. I'd like to filter those out whilst keeping important
stuff in (like all the recent udev spam)



-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-dev] Re: [PATCHES] kernel-2.eclass: Various changes requested by users. + [STABLEREQ?] sys-kernel/gentoo-sources-3.8.7: Any objections against stabilizing?

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 609 bytes --]

Am Sonntag, 14. April 2013, 12:06:48 schrieb Pacho Ramos:
> 
> The messages are shown the first time by elog *and* saved
> in /usr/share/doc/*/README.gentoo, adding the advantage of users having
> that docs always present without needing to re-emerge the package or
> manually read ebuilds

How about adding an additional short message at the end of an emerge, for 
example: 

The following packages have installed a README.gentoo file in /usr/share/doc:
  app-office/bla, app-text/fnord, ...

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] Re: [PATCHES] kernel-2.eclass: Various changes requested by users. + [STABLEREQ?] sys-kernel/gentoo-sources-3.8.7: Any objections against stabilizing?

[Pacho Ramos]

El dom, 14-04-2013 a las 19:15 +0200, Andreas K. Huettel escribió:
> Am Sonntag, 14. April 2013, 12:06:48 schrieb Pacho Ramos:
> > 
> > The messages are shown the first time by elog *and* saved
> > in /usr/share/doc/*/README.gentoo, adding the advantage of users having
> > that docs always present without needing to re-emerge the package or
> > manually read ebuilds
> 
> How about adding an additional short message at the end of an emerge, for 
> example: 
> 
> The following packages have installed a README.gentoo file in /usr/share/doc:
>   app-office/bla, app-text/fnord, ...
> 
> -- 
> 
> Andreas K. Huettel
> Gentoo Linux developer 
> dilfridge@gentoo.org
> http://www.akhuettel.de/
> 

Ideally, if it would be used by more packages, it could be documented
somewhere (like handbook), the problem is that, as there are a lot of
people that doesn't want to use it... :/