[gentoo-dev] making dodoc and dohtml die when they fail and stricter is on

[gentoo-dev] making dodoc and dohtml die when they fail and stricter is on

[Petteri Räty]

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

Moving this to gentoo-dev then.

-------- Original Message --------
Subject: Re: [gentoo-portage-dev] making dodoc and dohtml die when they
fail and stricter is on
Date: Sun, 25 Dec 2005 15:14:46 -0800
From: Brian Harring <ferringb@gentoo.org>
Reply-To: gentoo-portage-dev@lists.gentoo.org
To: gentoo-portage-dev@lists.gentoo.org
References: <43AF230C.5080904@gentoo.org>

On Mon, Dec 26, 2005 at 12:54:04AM +0200, Petteri Räty wrote:
> Currently there are quite a few ebuilds in the tree that execute dodoc
> or dohtml for files that do not exist. I think it would be nice to have
> ebuilds die if this is the case. To not break current ebuilds this would
> only happen with FEATURES="stricter". This is what I currently do in my
> bashrc. Obviously when integreted to portage one can use helper
> functions like hasq which are not available in bashrc.
> 
> 
> if [[ "${FEATURES/stricter}" != "${FEATURES}" ]]; then
> 
> _makefail() {
> 	bin="/usr/lib/portage/bin/${1}"
> 	shift 1
> 	"${bin}" "${@}" || die "${bin} ${@} failed"
> }
> 
> dodoc() {	_makefail ${FUNCNAME} "${@}"; }
> dohtml() {	_makefail ${FUNCNAME} "${@}"; }
Seems like more of a -dev discussion imo, since they're the ones
affected by it (for us it's just an api change).
~harring



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: [gentoo-dev] making dodoc and dohtml die when they fail and stricter is on

[Jason Stubbs]

On Monday 26 December 2005 08:14, Brian Harring wrote:
> On Mon, Dec 26, 2005 at 12:54:04AM +0200, Petteri Räty wrote:
> > Currently there are quite a few ebuilds in the tree that execute dodoc
> > or dohtml for files that do not exist. I think it would be nice to have
> > ebuilds die if this is the case. To not break current ebuilds this would
> > only happen with FEATURES="stricter". This is what I currently do in my
> > bashrc. Obviously when integreted to portage one can use helper
> > functions like hasq which are not available in bashrc.
> >
> >
> > if [[ "${FEATURES/stricter}" != "${FEATURES}" ]]; then
> >
> > _makefail() {
> > 	bin="/usr/lib/portage/bin/${1}"
> > 	shift 1
> > 	"${bin}" "${@}" || die "${bin} ${@} failed"
> > }
> >
> > dodoc() {	_makefail ${FUNCNAME} "${@}"; }
> > dohtml() {	_makefail ${FUNCNAME} "${@}"; }
>
> Seems like more of a -dev discussion imo, since they're the ones
> affected by it (for us it's just an api change).

As a side note, dodoc didn't return non-zero when specified files don't exist 
up until a month or two ago. dohtml was updated yesterday. Hence, up until 
now the above was not possible.

--
Jason Stubbs

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] making dodoc and dohtml die when they fail and stricter is on

[Jakub Moc]

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



>> Currently there are quite a few ebuilds in the tree that execute dodoc or
>> dohtml for files that do not exist. I think it would be nice to have
>> ebuilds die if this is the case. To not break current ebuilds this would
>> only happen with FEATURES="stricter".

Sigh... There are already bugs flowing in for TEXTRELs/executable stacks
checks implemented in recent portage versions. Some of these bugs are
completely INVALID or CANTFIX - emulation stuff, binary-only ebuilds, etc.
etc. What's the point of this breakage? Why are these QA checks fatal,
causing ebuilds to bail out? How can you disable such checks per-ebuild
(AFAIK - you can't) to not annoy users with QA notices and breakage one can
do nothing about anyway?

As Flameeyes pointed out, dodoc/dohtml is also used in eclasses. This can
break many ebuilds. Users will report duplicate bugs because they will not
realize that it's the eclass causing the failure, not the ebuild. Again,
what's the point? How will it work with FEATURES="nodoc"? Why should an
ebuild ever fail just because some doc file is missing or got renamed or
whatever?


-- 
Best regards,

 Jakub Moc
 mailto:jakub@gentoo.org
 GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

[-- Attachment #2: Type: application/pgp-signature, Size: 183 bytes --]

Re: [gentoo-dev] making dodoc and dohtml die when they fail and stricter is on

[Petteri Räty]

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

Jakub Moc wrote:
> 
>>>Currently there are quite a few ebuilds in the tree that execute dodoc or
>>>dohtml for files that do not exist. I think it would be nice to have
>>>ebuilds die if this is the case. To not break current ebuilds this would
>>>only happen with FEATURES="stricter".
> 
> 
> Sigh... There are already bugs flowing in for TEXTRELs/executable stacks
> checks implemented in recent portage versions. Some of these bugs are
> completely INVALID or CANTFIX - emulation stuff, binary-only ebuilds, etc.
> etc. What's the point of this breakage? Why are these QA checks fatal,
> causing ebuilds to bail out? How can you disable such checks per-ebuild
> (AFAIK - you can't) to not annoy users with QA notices and breakage one can
> do nothing about anyway?
> 
> As Flameeyes pointed out, dodoc/dohtml is also used in eclasses. This can
> break many ebuilds. Users will report duplicate bugs because they will not
> realize that it's the eclass causing the failure, not the ebuild. Again,
> what's the point? How will it work with FEATURES="nodoc"? Why should an
> ebuild ever fail just because some doc file is missing or got renamed or
> whatever?
> 
> 

echo "dodoc: ${x} does not exist" 1>&2

This should not be showed to users then because we know this to happen
and do not want to do anything about it. Also try to remember that not
every package is done following the GNU conventions (Java). It can
happen that the doc files are for example renamed and dieing will help
catch this. dodoc/dohtml dieing will not have any affect on
FEATURES="nodoc".

How about making it possible to tell dodoc/dohtml not to die as an
argument/variable/whatever? We could also have new diedodoc functions,
but it would be nice to keep this as simple as possible.

Regards,
Petteri

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: [gentoo-dev] making dodoc and dohtml die when they fail and stricter is on

[Danny van Dyk]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jakub Moc schrieb:
|
|>>Currently there are quite a few ebuilds in the tree that execute dodoc or
|>>dohtml for files that do not exist. I think it would be nice to have
|>>ebuilds die if this is the case. To not break current ebuilds this would
|>>only happen with FEATURES="stricter".
|
|
| Sigh... There are already bugs flowing in for TEXTRELs/executable stacks
| checks implemented in recent portage versions. Some of these bugs are
| completely INVALID or CANTFIX - emulation stuff, binary-only ebuilds, etc.
| etc. What's the point of this breakage? Why are these QA checks fatal,
| causing ebuilds to bail out? How can you disable such checks per-ebuild
| (AFAIK - you can't) to not annoy users with QA notices and breakage
one can
| do nothing about anyway?
You can disable them. Have a look at dyn_install in ebuild.sh.
There are 2 categories of such QA violations:

* One category (qa_sucks_for_sure) currently only consists of ebuilds
~  that have run-paths pointing to a subdir of ${BUILDDIR}. Such bugs can
~  always be fixed (as it never affects binary packages) and thus this
~  category of bug lets the build process always die.

* The other category (qa_kinda_sucks) only causes the death of the build
~  process when the user has FEATURES="stricter" and the ebuild doesn't
~  have RESTRICT="stricter".

The obvious solution for unfixable (binary) packages is to set
RESTRICT="stricter" for them. On the other hand, some binary UPSTREAMs
are very kind and competent to handle such bugs if you tell them. AMD
for example, who will fix an "exectuable stack" problem in ACML after
the holidays.

Danny
- --
Danny van Dyk <kugelfang@gentoo.org>
Gentoo/AMD64 Project, Gentoo Scientific Project
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDr+j8aVNL8NrtU6IRAq0kAJ92IHWPU/WRRzj5F807yU+89bm87gCfbbBF
lkpmuU3EgpaFHfaCaiShQxI=
=drQA
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] making dodoc and dohtml die when they fail and stricter is on

[Jason Stubbs]

On Monday 26 December 2005 20:01, Jakub Moc wrote:
> >> Currently there are quite a few ebuilds in the tree that execute dodoc
> >> or dohtml for files that do not exist. I think it would be nice to have
> >> ebuilds die if this is the case. To not break current ebuilds this would
> >> only happen with FEATURES="stricter".
>
> Sigh... There are already bugs flowing in for TEXTRELs/executable stacks
> checks implemented in recent portage versions. Some of these bugs are
> completely INVALID or CANTFIX - emulation stuff, binary-only ebuilds, etc.
> etc.

Sigh... None of these issues have made there way to dev-portage.

--
Jason Stubbs
-- 
gentoo-dev@gentoo.org mailing list

Re[2]: [gentoo-dev] making dodoc and dohtml die when they fail and stricter is on

[Jakub Moc]

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


26.12.2005, 14:28:12, Jason Stubbs wrote:

> On Monday 26 December 2005 20:01, Jakub Moc wrote:
>> >> Currently there are quite a few ebuilds in the tree that execute dodoc
>> >> or dohtml for files that do not exist. I think it would be nice to have
>> >> ebuilds die if this is the case. To not break current ebuilds this would
>> >> only happen with FEATURES="stricter".
>>
>> Sigh... There are already bugs flowing in for TEXTRELs/executable stacks
>> checks implemented in recent portage versions. Some of these bugs are
>> completely INVALID or CANTFIX - emulation stuff, binary-only ebuilds, etc.
>> etc.

> Sigh... None of these issues have made there way to dev-portage.

> --
> Jason Stubbs

Well, then assign Bug 116499 or Bug 116602 to yourself (qemu), there're
textrels in openoffice-bin, mozilla-firefox-bin (upstream, don't hold your
breath to get this fixed), acroread (cantfix really), this for sure will be
an issue for many games binaries, etc. While it's often upstream/cantfix, I
don't see much sense in making these QA checks fatal really.

-- 
Best regards,

 Jakub Moc
 mailto:jakub@gentoo.org
 GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

[-- Attachment #2: Type: application/pgp-signature, Size: 183 bytes --]

Re: [gentoo-dev] making dodoc and dohtml die when they fail and stricter is on

[Diego 'Flameeyes' Pettenò]

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

On Monday 26 December 2005 00:32, Petteri Räty wrote:
> > Currently there are quite a few ebuilds in the tree that execute dodoc
> > or dohtml for files that do not exist. I think it would be nice to have
> > ebuilds die if this is the case.
I wouldn't like this.
The reason is, they are also used in eclasses that might be generic; while for 
example kde eclass checks for the presence of files before dodoc-ing them, I 
would rather see it ignore the actually presence or less of the files, and 
just dodoc the one that exists, without failing if some does not exists.

One can be reasonably safe that it will find AUTHORS ChangeLog README NEWS and 
TODO files in generic packages, if they follow GNUs style for example, but 
sometimes they can be missing.

I'd rather not see the change.

-- 
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] making dodoc and dohtml die when they fail and stricter is on

[Chris White]

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

On Monday 26 December 2005 10:26, Diego 'Flameeyes' Pettenò wrote:
> I wouldn't like this.
> The reason is, they are also used in eclasses that might be generic; while
> for example kde eclass checks for the presence of files before dodoc-ing
> them, I would rather see it ignore the actually presence or less of the
> files, and just dodoc the one that exists, without failing if some does not
> exists.

I'm not sure if we're on the same page as far as the target audience of this 
change.  The target audience is developers/those with strict in their 
features.  The whole reason it's done is to be a bit more "strict" (hence the 
FEATURE phrasing) on general QA.  For users that don't need this level of 
strict checking, they simply disable the feature.  Generalized assumptions of 
code finding files simply isn't clean.  Checks should be done to verify files 
before attempting to install, that's just the way it should be out of general 
practice.

> One can be reasonably safe that it will find AUTHORS ChangeLog README NEWS
> and TODO files in generic packages, if they follow GNUs style for example,
> but sometimes they can be missing.

Yes, but while GNU style is indeed the more popular of build sytems, others 
still do exist, and will continue to exist.  I've always found dodoc should 
be checked anyways, and if we're assuming the documentation consists of the 
formentioned items, then we're also having the situation of missing other 
important documentation as well.  This all should be checked the first time a 
package is imported/version bumped for consistancy.

> I'd rather not see the change.

Chris White

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] making dodoc and dohtml die when they fail and stricter is on

[Diego 'Flameeyes' Pettenò]

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

On Monday 26 December 2005 03:28, Chris White wrote:
> I'm not sure if we're on the same page as far as the target audience of
> this change.  The target audience is developers/those with strict in their
> features.
Actually "stricter", and there are way too many people to put that in without 
knowing what that do... or is it a default nowadays, I'm not even sure.

> I've always found dodoc should 
> be checked anyways, and if we're assuming the documentation consists of the
> formentioned items, then we're also having the situation of missing other
> important documentation as well.  
Take KDE-related packages.. a good 90% of those have just the files I named or 
a subset of them as documentation, for those, the eclass already take care of 
them definitely.
When there's something _more_, it can be dodoc-ed by hand. But it would fail 
if someone didn't put a NEWS file or a ChangeLog ... that seems stupid to me.

Also, I think jakub is totally right with this.

-- 
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] making dodoc and dohtml die when they fail and stricter is on

[Petteri Räty]

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

Diego 'Flameeyes' Pettenò wrote:
> On Monday 26 December 2005 03:28, Chris White wrote:
> 
>>I'm not sure if we're on the same page as far as the target audience of
>>this change.  The target audience is developers/those with strict in their
>>features.
> 
> Actually "stricter", and there are way too many people to put that in without 
> knowing what that do... or is it a default nowadays, I'm not even sure.
> 

When I asked about stricter the first time, the response was that it is
meant as a developer tool only so it will not be on by default any time
soon.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: [gentoo-dev] making dodoc and dohtml die when they fail and stricter is on

[Simon Stelling]

Diego 'Flameeyes' Pettenò wrote:
>>I'm not sure if we're on the same page as far as the target audience of
>>this change.  The target audience is developers/those with strict in their
>>features.
> 
> Actually "stricter", and there are way too many people to put that in without 
> knowing what that do... or is it a default nowadays, I'm not even sure.

You're mixing up 'strict' with 'stricter'.

-- 
Simon Stelling
Gentoo/AMD64 Operational Co-Lead
blubb@gentoo.org
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] making dodoc and dohtml die when they fail and stricter is on

[Diego 'Flameeyes' Pettenò]

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

On Monday 26 December 2005 13:59, Simon Stelling wrote:
> > Actually "stricter", and there are way too many people to put that in
> > without knowing what that do... or is it a default nowadays, I'm not even
> > sure.
> You're mixing up 'strict' with 'stricter'.
Well if I'm mixing up, someone moved the QA checks from stricter to strict 
lately ;)
I don't run strict as I usually have modified ebuilds if I'm working on them; 
I don't run stricter as lot of packages that fails are not mine, I usually 
use it only when I'm testing my packages or my changes.

-- 
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] making dodoc and dohtml die when they fail and stricter is on

[Dan Meltzer]

On 12/26/05, Diego 'Flameeyes' Pettenò <flameeyes@gentoo.org> wrote:
> On Monday 26 December 2005 13:59, Simon Stelling wrote:
> > > Actually "stricter", and there are way too many people to put that in
> > > without knowing what that do... or is it a default nowadays, I'm not even
> > > sure.
> > You're mixing up 'strict' with 'stricter'.
> Well if I'm mixing up, someone moved the QA checks from stricter to strict
> lately ;)
> I don't run strict as I usually have modified ebuilds if I'm working on them;
> I don't run stricter as lot of packages that fails are not mine, I usually
> use it only when I'm testing my packages or my changes.

strict is in make.defaults...
This causes packages with executable stacks to die, and fairly
arbitrarily imo (with portage 2.1_pre2 that is) (see bug 116611).

IMUO, portage should never die when an issue of questionable merit
comes up and features are simply those set by default.


>
> --
> Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
> Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE
>
>
>

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] making dodoc and dohtml die when they fail and stricter is on

[Dan Meltzer]

and my bad.

I am not yet awake.

It died cause of runpaths on strict, it just showed both, and I wasn't
thinking when I sent earlier email...
On 12/26/05, Dan Meltzer <parallelgrapefruit@gmail.com> wrote:
> On 12/26/05, Diego 'Flameeyes' Pettenò <flameeyes@gentoo.org> wrote:
> > On Monday 26 December 2005 13:59, Simon Stelling wrote:
> > > > Actually "stricter", and there are way too many people to put that in
> > > > without knowing what that do... or is it a default nowadays, I'm not even
> > > > sure.
> > > You're mixing up 'strict' with 'stricter'.
> > Well if I'm mixing up, someone moved the QA checks from stricter to strict
> > lately ;)
> > I don't run strict as I usually have modified ebuilds if I'm working on them;
> > I don't run stricter as lot of packages that fails are not mine, I usually
> > use it only when I'm testing my packages or my changes.
>
> strict is in make.defaults...
> This causes packages with executable stacks to die, and fairly
> arbitrarily imo (with portage 2.1_pre2 that is) (see bug 116611).
>
> IMUO, portage should never die when an issue of questionable merit
> comes up and features are simply those set by default.
>
>
> >
> > --
> > Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
> > Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE
> >
> >
> >
>

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Putting qa warnings to a text file instead of showing them to the world

[Petteri Räty]

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

> On Mon, Dec 26, 2005 at 12:54:04AM +0200, Petteri Räty wrote:
> 
>>Currently there are quite a few ebuilds in the tree that execute dodoc
>>or dohtml for files that do not exist. I think it would be nice to have
>>ebuilds die if this is the case. To not break current ebuilds this would
>>only happen with FEATURES="stricter". This is what I currently do in my
>>bashrc. Obviously when integreted to portage one can use helper
>>functions like hasq which are not available in bashrc.
>>
>>

Well some people opposed this idea so what do everyone think about
making portage output stuff like this to a qa-warnings (or whatever)
file that developers can use? This would have the added benefit that
users would not normally see this stuff and report stuff so easily but
developers would still have easy access to it. Portage could even output
a header to this file saying not to file bug reports unless you know
what you are doing?

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: [gentoo-dev] Putting qa warnings to a text file instead of showing them to the world

[Mike Frysinger]

On Tuesday 27 December 2005 14:41, Petteri Räty wrote:
> > On Mon, Dec 26, 2005 at 12:54:04AM +0200, Petteri Räty wrote:
> >>Currently there are quite a few ebuilds in the tree that execute dodoc
> >>or dohtml for files that do not exist. I think it would be nice to have
> >>ebuilds die if this is the case. To not break current ebuilds this would
> >>only happen with FEATURES="stricter". This is what I currently do in my
> >>bashrc. Obviously when integreted to portage one can use helper
> >>functions like hasq which are not available in bashrc.
>
> Well some people opposed this idea so what do everyone think about
> making portage output stuff like this to a qa-warnings (or whatever)
> file that developers can use? This would have the added benefit that
> users would not normally see this stuff and report stuff so easily but
> developers would still have easy access to it. Portage could even output
> a header to this file saying not to file bug reports unless you know
> what you are doing?

if we start "hiding" the output like that then most people will ignore them
-mike

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Putting qa warnings to a text file instead of showing them to the world

[Lares Moreau]

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

On Tue, 2005-12-27 at 21:41 +0200, Petteri Räty wrote:
> > On Mon, Dec 26, 2005 at 12:54:04AM +0200, Petteri Räty wrote:
> > 
> >>Currently there are quite a few ebuilds in the tree that execute dodoc
> >>or dohtml for files that do not exist. I think it would be nice to have
> >>ebuilds die if this is the case. To not break current ebuilds this would
> >>only happen with FEATURES="stricter". This is what I currently do in my
> >>bashrc. Obviously when integreted to portage one can use helper
> >>functions like hasq which are not available in bashrc.
> >>
> >>
> 
> Well some people opposed this idea so what do everyone think about
> making portage output stuff like this to a qa-warnings (or whatever)
> file that developers can use? This would have the added benefit that
> users would not normally see this stuff and report stuff so easily but
> developers would still have easy access to it. Portage could even output
> a header to this file saying not to file bug reports unless you know
> what you are doing?

I see the point about not showing all the QA stuff to the 'regluar'
user.  Maybe only show this info on screen with --verbose set. As for
the QA-warnings file, how does this differ from parsing the files in
PORTLOG_DIR?

Later Days,
-Lares

-- 
Lares Moreau <lares.moreau@gmail.com>  | LRU: 400755 http://counter.li.org
lares/irc.freenode.net                 |
Gentoo x86 Arch Tester                 |               ::0 Alberta, Canada
Public Key: 0D46BB6E @ subkeys.pgp.net |          Encrypted Mail Preferred
Key fingerprint = 0CA3 E40D F897 7709 3628  C5D4 7D94 483E 0D46 BB6E

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

Re: [gentoo-dev] Putting qa warnings to a text file instead of showing them to the world

[Petteri Räty]

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



Lares Moreau wrote:
> On Tue, 2005-12-27 at 21:41 +0200, Petteri Räty wrote:
> 
>>>On Mon, Dec 26, 2005 at 12:54:04AM +0200, Petteri Räty wrote:
>>>
>>>
>>>>Currently there are quite a few ebuilds in the tree that execute dodoc
>>>>or dohtml for files that do not exist. I think it would be nice to have
>>>>ebuilds die if this is the case. To not break current ebuilds this would
>>>>only happen with FEATURES="stricter". This is what I currently do in my
>>>>bashrc. Obviously when integreted to portage one can use helper
>>>>functions like hasq which are not available in bashrc.
>>>>
>>>>
>>
>>Well some people opposed this idea so what do everyone think about
>>making portage output stuff like this to a qa-warnings (or whatever)
>>file that developers can use? This would have the added benefit that
>>users would not normally see this stuff and report stuff so easily but
>>developers would still have easy access to it. Portage could even output
>>a header to this file saying not to file bug reports unless you know
>>what you are doing?
> 
> 
> I see the point about not showing all the QA stuff to the 'regluar'
> user.  Maybe only show this info on screen with --verbose set. As for
> the QA-warnings file, how does this differ from parsing the files in
> PORTLOG_DIR?
> 

Stuff that goes to PORT_LOGDIR is also shown to the user.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: [gentoo-dev] Putting qa warnings to a text file instead of showing them to the world

[Lares Moreau]

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

On Tue, 2005-12-27 at 22:10 +0200, Petteri Räty wrote:
> > I see the point about not showing all the QA stuff to the 'regluar'
> > user.  Maybe only show this info on screen with --verbose set. As for
> > the QA-warnings file, how does this differ from parsing the files in
> > PORTLOG_DIR?
> > 
> 
> Stuff that goes to PORT_LOGDIR is also shown to the user.

Could it be split? Have the QA stuff shown on screen only when --verbose
is set, but have all the information written to PORT_LOGDIR no matter
the flag.

In my experience most users don't use PORT_LOGDIR in the first place.
People who want the information define PORT_LOGDIR and have the
information. Why add files containing duplicate information?

-Lares

-- 
Lares Moreau <lares.moreau@gmail.com>  | LRU: 400755 http://counter.li.org
lares/irc.freenode.net                 |
Gentoo x86 Arch Tester                 |               ::0 Alberta, Canada
Public Key: 0D46BB6E @ subkeys.pgp.net |          Encrypted Mail Preferred
Key fingerprint = 0CA3 E40D F897 7709 3628  C5D4 7D94 483E 0D46 BB6E

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

Re: [gentoo-dev] Putting qa warnings to a text file instead of showing them to the world

[Kalin KOZHUHAROV]

Lares Moreau wrote:
> On Tue, 2005-12-27 at 22:10 +0200, Petteri Räty wrote:
> 
>>>I see the point about not showing all the QA stuff to the 'regluar'
>>>user.  Maybe only show this info on screen with --verbose set. As for
>>>the QA-warnings file, how does this differ from parsing the files in
>>>PORTLOG_DIR?
>>>
>>
>>Stuff that goes to PORT_LOGDIR is also shown to the user.
> 
> 
> Could it be split? Have the QA stuff shown on screen only when --verbose
> is set, but have all the information written to PORT_LOGDIR no matter
> the flag.

That will be difficult to explain as a behaviour, not logical to me.


> In my experience most users don't use PORT_LOGDIR in the first place.
> People who want the information define PORT_LOGDIR and have the
> information. Why add files containing duplicate information?

ditto.

Imagine a world where every (Gentoo) user is a developer... dream... more!
You are right - impossible. However, by bitching about problems, there are some users that decide to
check WTF is this warning, in turn they urge devs to fix it (and that is the main point of QA,
right?), they report it with their bug reports and so on. In other words, the problem gets _NOTICED_
by everybody.

IMHO, leave it as it is now and don't bother. It is not that much of an output, compared to the
compile output anyway.

I'd prefer even having it red/bold/whatever for easy spotting. And for the future, what about
defining something like GENTOO_LEVEL="n00b|user|know_how|master|admin|dev|guru" in make.conf? And
act acording to this, but trying to move the user up a level or two most of the time.

Kalin.
/know_how ->master -->dev/

-- 
|[ ~~~~~~~~~~~~~~~~~~~~~~ ]|
+-> http://ThinRope.net/ <-+
|[ ______________________ ]|

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Putting qa warnings to a text file instead of showing them to the world

[Lares Moreau]

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

On Wed, 2005-12-28 at 10:34 +0900, Kalin KOZHUHAROV wrote:
>  what about
> defining something like GENTOO_LEVEL="n00b|user|know_how|master|admin|dev|guru" in make.conf? And
> act acording to this, but trying to move the user up a level or two most of the time.

This is what happens anyway, but it is called FEATURES :)

-Lares

-- 
Lares Moreau <lares.moreau@gmail.com>  | LRU: 400755 http://counter.li.org
lares/irc.freenode.net                 |
Gentoo x86 Arch Tester                 |               ::0 Alberta, Canada
Public Key: 0D46BB6E @ subkeys.pgp.net |          Encrypted Mail Preferred
Key fingerprint = 0CA3 E40D F897 7709 3628  C5D4 7D94 483E 0D46 BB6E

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

Re: [gentoo-dev] Putting qa warnings to a text file instead of showing them to the world

[Kalin KOZHUHAROV]

Lares Moreau wrote:
> On Wed, 2005-12-28 at 10:34 +0900, Kalin KOZHUHAROV wrote:
> 
>> what about defining something like GENTOO_LEVEL="n00b|user|know_how|master|admin|dev|guru" in
>> make.conf? And act acording to this, but trying to move the user up a level or two most of the
>> time.
> 
> 
> This is what happens anyway, but it is called FEATURES :)

>From `man make.conf`
       FEATURES = "sandbox ccache autoaddcvs"
              Defines actions portage takes by default.  These options should not be changed by
anyone but developers and/or maintainers.  'sandbox' is an  important  part  of FEATURES and should
not be disabled by default.  This is an incremental variable.

So I guess I am close to "developers and/or maintainers" as I change that on day 0 on any Gentoo box
I install :-)

s/'sandbox' is an  important  part  of FEATURES and should not be disabled by default/
'sandbox' is an  important  part  of FEATURES and should not be disabled by default (but disabled on
`emerge perl`)/g or die;

I still think, GENTOO_LEVEL is a better one though.

Kalin.

-- 
|[ ~~~~~~~~~~~~~~~~~~~~~~ ]|
+-> http://ThinRope.net/ <-+
|[ ______________________ ]|

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Putting qa warnings to a text file instead of showing them to the world

[Ryan Tandy]

<snip>

>However, by bitching about problems, there are some users that decide to
>check WTF is this warning, in turn they urge devs to fix it (and that is the main point of QA,
>right?), they report it with their bug reports and so on. In other words, the problem gets _NOTICED_
>by everybody.
>
>IMHO, leave it as it is now and don't bother. It is not that much of an output, compared to the
>compile output anyway.
>I'd prefer even having it red/bold/whatever for easy spotting. 
>
I agree - hiding QA stuff just makes it be there longer.  The more 
people notice it, the more likely it is to get fixed, which is the best 
way of making it not show up (IMHO anyway).

>And for the future, what about
>defining something like GENTOO_LEVEL="n00b|user|know_how|master|admin|dev|guru" in make.conf? And
>act acording to this, but trying to move the user up a level or two most of the time.
>
I don't think many people would enjoy having a system that made it its 
business to tell them what they should know about.  Different people 
have different learning rates and learn in different ways about 
different things.  People who want to learn to solve their own problems 
will; those who don't aren't likely to want their computer to try to 
force them to (although I'll admit that Gentoo doesn't exactly attract 
loads of the latter type).
-- 
gentoo-dev@gentoo.org mailing list