[gentoo-dev] How help in arch testing work

[gentoo-dev] How help in arch testing work

[Agostino Sarubbo]

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

This mail is come from my long time experience about testing.

So, everytime, I must suggest the same things and I can say that at some point 
it gets boring.

I appreciate the work of all, but I must say that some people pay little 
attention to stablereq bugs, so this mail wants to be a short reminder of what 
could decrease our work.

1) There is a discussion[1] about it, but for the moment, a stablereq should 
be "keywording and stabilization" and enhancement importance.
If you need to accelerate the stabilization please set high and not from 
enhancement to critical and so on.
Don't forget STABLEREQ keyword or the bug will not appears in our list.

2) _Before_ filing a request, please run repoman full, to be sure that there 
is nothing to fix, then take a look at the ebuild and make sure your ebuild 
have a minimum of QA; all external binary called in the ebuild(sed, mv, cp, 
ln, rm, and so on) should have 'die'; if you don't use EAPI4, make sure that 
all portage helper[2] have also '|| die'.

3) Check your rdepend, where is possible with scanelf[3] and if you declare 
it, please, as you said, exclude gcc/glibc and all package from @system

4) Nobody knows how work all packages in tree, so there are obvious packages 
like a browsers, IM, audio player,that is easy decide if is ok or not, but 
there are also packages that an Arch tester has never seen, so is a lack of 
time everytime google about it or ask to maintainer, so, please specify what 
test you want for this package; e.g.
-only compile test
-compile test and make sure src_test goes well
-make sure /usr/bin/${foo} works properly in ${that} manner
-see 5) about library

So, you can write one time 'how to' and copy/paste for the future stablereq; I 
guess I'm not asking a long and difficult task.

5) If is a library, obviously, we can try to rebuild stable RDEPENDS in tree 
and an easy way to check the list of rdepend is asking our bot: 
!rdep ${package}
Unfortunately it prints a complete list of RDEPEND(stable+testing), and is a 
lack of time checking manually what is the list of stable packages.
So you can lighten our work in 2 ways:
a) Please rebuild the following list of rdepends.( if no need to rebuild all 
because maintainer already do it)
b) Please rebuild all rdepends.
So, unfortunately, I don't know a rapid way to have only a stable list of 
packages, so if really there isn't it, is very very appreciated print the list 
of packages that needs rebuild
Sorry in advance if there is and I'm ignoring it, please tell me.



I want to point out that this is not a polemic, but is a way to suggest what 
you can do for arch teams to increase the quality of teamwork and do not waste 
precious time.


[1]: https://bugs.gentoo.org/show_bug.cgi?id=381627
[2]: qlist -e portage | grep ebuild-helpers
[3]: amd64box ~ # cat /usr/local/bin/scan
#!/bin/bash                                                                                                                                                                         
qlist -e "$@" | xargs scanelf -L -n -q -F '%n #F' | tr , ' ' | xargs qfile -Cv 
| sort -u | awk '{print $1}' | uniq 

-- 
Agostino Sarubbo		ago -at- gentoo.org
Gentoo/AMD64 Arch Security Liaison
GPG: 0x7CD2DC5D

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

Re: [gentoo-dev] How help in arch testing work

[Tobias Klausmann]

Hi! 

On Wed, 18 Jan 2012, Agostino Sarubbo wrote:
> 4) Nobody knows how work all packages in tree, so there are
> obvious packages like a browsers, IM, audio player,that is easy
> decide if is ok or not, but there are also packages that an
> Arch tester has never seen, so is a lack of time everytime
> google about it or ask to maintainer, so, please specify what
> test you want for this package; e.g.
>
> -only compile test
> -compile test and make sure src_test goes well
> -make sure /usr/bin/${foo} works properly in ${that} manner
> -see 5) about library
> 
> So, you can write one time 'how to' and copy/paste for the
> future stablereq; I guess I'm not asking a long and difficult
> task.

I'd like to point out that the Emacs people have a very nifty
list of "how to test our stuff":

  http://overlays.gentoo.org/proj/emacs/wiki/test%20plans

If you want to be an awesome maintainer, have something like this
for the archtesters, especially for the more obscure packages as
Agostino pointed out.

Regards,
Tobias

Re: [gentoo-dev] How help in arch testing work

[Alexis Ballier]

Hi,

On Wed, 18 Jan 2012 15:23 +0100
Agostino Sarubbo <ago@gentoo.org> wrote:

> 2) _Before_ filing a request, please run repoman full, to be sure
> that there is nothing to fix, then take a look at the ebuild and make
> sure your ebuild have a minimum of QA; all external binary called in
> the ebuild(sed, mv, cp, ln, rm, and so on) should have 'die'; if you
> don't use EAPI4, make sure that all portage helper[2] have also '||
> die'.
> 
> 3) Check your rdepend, where is possible with scanelf[3] and if you
> declare it, please, as you said, exclude gcc/glibc and all package
> from @system


imho this has nothing to do with stabilization, every single package
should have these 2 points addressed.
however, fact is that a second pair of eyes reviewing the ebuild (which
is what arch testers usually do) usually spots more than the author.
there are obvious problems (reports from repoman) that indeed
should be fixed before asking for stabilization, but others are more
difficult to spot (automagics, missing die's/typos), and, as a
maintainer, the reviewing done by arch testers is usually a good help.


> 4) Nobody knows how work all packages in tree, so there are obvious
> packages like a browsers, IM, audio player,that is easy decide if is
> ok or not, but there are also packages that an Arch tester has never
> seen, so is a lack of time everytime google about it or ask to
> maintainer, so, please specify what test you want for this package;
> e.g. -only compile test
> -compile test and make sure src_test goes well
> -make sure /usr/bin/${foo} works properly in ${that} manner
> -see 5) about library
> 
> So, you can write one time 'how to' and copy/paste for the future
> stablereq; I guess I'm not asking a long and difficult task.

what i dislike in this approach is that arch testers will follow a
test plan which the maintainer has obviously tested before and knows
it works.
sending people into the jungle of 'try to do something with $pkg' may
make them encounter problems the maintainer hadnt thought about.

Regards,

Alexis.

Re: [gentoo-dev] How help in arch testing work

[Rich Freeman]

On Wed, Jan 18, 2012 at 9:55 AM, Alexis Ballier <aballier@gentoo.org> wrote:
> On Wed, 18 Jan 2012 15:23 +0100
> Agostino Sarubbo <ago@gentoo.org> wrote:
>> 3) Check your rdepend, where is possible with scanelf[3] and if you
>> declare it, please, as you said, exclude gcc/glibc and all package
>> from @system
>
> imho this has nothing to do with stabilization, every single package
> should have these 2 points addressed.

True, although unless I'm missing something I don't see the harm in
listing packages as (R)DEPENDS that are in @system.  If anything this
would help to reduce churn down the road as we try to minimize the
system set.  If including packages from @system does break things like
stage3s I'll rescind my remarks, but my impression is that all the
circular deps necessitated some level of hard-coding in the scripts
already...

>> So, you can write one time 'how to' and copy/paste for the future
>> stablereq; I guess I'm not asking a long and difficult task.
>
> what i dislike in this approach is that arch testers will follow a
> test plan which the maintainer has obviously tested before and knows
> it works.
> sending people into the jungle of 'try to do something with $pkg' may
> make them encounter problems the maintainer hadnt thought about.

Yes and no.  First, maintainers often run ~arch packages with ~arch
dependencies.  They are also likely to test on one of x86/amd64, but
not both, or perhaps only in a 32-bit chroot where stuff like init
scripts isn't really running/etc.  Arch teams should be testing on
stable systems running consistently on the same arch (no chroots,
minimal package.keywords, etc).  Arch teams due to dumb luck are also
likely to be running different USE flags.  So, I don't consider
repeating tests as a real waste (trust me, at work I'm all over this
sort of thing as we waste a lot of time running tests we know will
pass due to NIH syndrome).

Also, a maintainer might be able to suggest things that are more
likely to break, or which are more likely to cause their users pain.
If some aspect of a package is more fragile, then pointing that out to
a tester is a good thing.

No harm in having the arch team bumbling about a little, but unless a
package is perceived as being fairly important I suspect most won't do
a great deal of this.

All that said, this is Gentoo - if you want a distro with 3 releases
per year with coordinated beta cycles where everything is tested
together, look elsewhere.  Without doing this sort of thing we're
going to have to accept that bugs are more likely to crop up (but will
likely be fixed faster when they do) - release somewhat early, release
very often is a pretty good summary about what we're about.

Rich

Re: [gentoo-dev] How help in arch testing work

[Mike Frysinger]

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

On Wednesday 18 January 2012 10:44:44 Rich Freeman wrote:
> On Wed, Jan 18, 2012 at 9:55 AM, Alexis Ballier wrote:
> > On Wed, 18 Jan 2012 15:23 +0100 Agostino Sarubbo wrote:
> >> 3) Check your rdepend, where is possible with scanelf[3] and if you
> >> declare it, please, as you said, exclude gcc/glibc and all package
> >> from @system
> > 
> > imho this has nothing to do with stabilization, every single package
> > should have these 2 points addressed.
> 
> True, although unless I'm missing something I don't see the harm in
> listing packages as (R)DEPENDS that are in @system.  If anything this
> would help to reduce churn down the road as we try to minimize the
> system set.  If including packages from @system does break things like
> stage3s I'll rescind my remarks, but my impression is that all the
> circular deps necessitated some level of hard-coding in the scripts
> already...

it isn't just circular deps.  it's also about breaking alternatives and 
useless bloat.  adding "coreutils" to their depend because they execute `mv`, 
or "sed" because they execute `sed`, etc... is absolutely pointless.  same 
goes for virtual/libc or virtual/os-headers.
-mike

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

Re: [gentoo-dev] How help in arch testing work

[Rich Freeman]

On Wed, Jan 18, 2012 at 11:45 AM, Mike Frysinger <vapier@gentoo.org> wrote:
> it isn't just circular deps.  it's also about breaking alternatives and
> useless bloat.  adding "coreutils" to their depend because they execute `mv`,
> or "sed" because they execute `sed`, etc... is absolutely pointless.  same
> goes for virtual/libc or virtual/os-headers.

Perhaps pointless, but likely harmless as well.  I wasn't suggesting
that we should systematically add @system deps - only that we
shouldn't systematically remove them either unless they cause harm.

When I think about the use cases for reduced @system, I think that
listing them in RDEPEND probably has more utility than having them in
DEPEND.  It usually matters more on minimal systems that the packages
in the run state are smaller, and the build state often doesn't matter
as much (consider something installed into a chroot using
crossdev/etc).  Coreutils is obviously an extreme example, although
even that could be replaced by something like busybox.  Then again,
unless somebody makes a virtual for it I don't think that trying to
put that in an RDEPEND gets us anywhere.

Bottom line is that if somebody has a reason for sticking an @system
package in (R)DEPEND I don't see the need to treat it as a bug, unless
it actually causes harm beyond 30 more bytes in block tail space for
something in /usr/portage.

Just my two cents...

Rich

Re: [gentoo-dev] How help in arch testing work

[Mike Frysinger]

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

On Wednesday 18 January 2012 13:42:12 Rich Freeman wrote:
> On Wed, Jan 18, 2012 at 11:45 AM, Mike Frysinger wrote:
> > it isn't just circular deps.  it's also about breaking alternatives and
> > useless bloat.  adding "coreutils" to their depend because they execute
> > `mv`, or "sed" because they execute `sed`, etc... is absolutely
> > pointless.  same goes for virtual/libc or virtual/os-headers.
> 
> Perhaps pointless, but likely harmless as well.  I wasn't suggesting
> that we should systematically add @system deps - only that we
> shouldn't systematically remove them either unless they cause harm.

it is a problem.  not all profiles use "coreutils" ... they provide replacement 
packages.  busybox is just one example.  the bsd/prefix guys go in even weirder 
directions.

it also encourages people to add this crap to other packages, and gets us into 
an even more confusing state.  people look at existing ebuilds as examples, 
and having things like "grep" or "sed" or "coreutils" sets an awful example.

when i see these things in ebuilds, i make sure to scrub them when updating.

> When I think about the use cases for reduced @system, I think that
> listing them in RDEPEND probably has more utility than having them in
> DEPEND.  It usually matters more on minimal systems that the packages
> in the run state are smaller, and the build state often doesn't matter
> as much (consider something installed into a chroot using
> crossdev/etc).  Coreutils is obviously an extreme example, although
> even that could be replaced by something like busybox.  Then again,
> unless somebody makes a virtual for it I don't think that trying to
> put that in an RDEPEND gets us anywhere.

DEPEND usage is useless cruft to the point of absurdity.

RDEPEND is much less common as then you're really only talking about the 
random shell scripts.  i'd argue still though that it still doesn't make sense 
considering a system can hardly boot without "coreutils".  and if you are in a 
situation where you have such a reduced install that it can, the existing 
@system semantics work for you.
-mike

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

Re: [gentoo-dev] How help in arch testing work

[Rich Freeman]

On Wed, Jan 18, 2012 at 3:01 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> it is a problem.  not all profiles use "coreutils" ... they provide replacement
> packages.  busybox is just one example.  the bsd/prefix guys go in even weirder
> directions.

Yup - hence my point about coreutils not being a good one to include
unless you virtualized it, which probably is more than we'd really
want to do for a system package.

>
> DEPEND usage is useless cruft to the point of absurdity.
>
> RDEPEND is much less common as then you're really only talking about the
> random shell scripts.  i'd argue still though that it still doesn't make sense
> considering a system can hardly boot without "coreutils".  and if you are in a
> situation where you have such a reduced install that it can, the existing
> @system semantics work for you.

Again, you're using coreutils as an example, and that doesn't seem
like something that would be much of a value-add to place in RDEPEND.
However, if you had a package that required openssh, that would seem
to be a much better candidate for an RDEPEND, since it is trivial to
boot a system without openssh installed despite it being in system.

Openssh is obviously a bit of a contrived example in the opposite
direction, but it is in @system.

Basically what I'm advocating is that somebody shouldn't have to
defend their actions if they include something from @system in
*DEPEND.  Future maintainers are welcome to undo the work of previous
maintainers as always.  @system packages in *DEPEND should not be
considered a bug (as long as they're right).

Rich

[gentoo-dev] Re: How help in arch testing work

[Duncan]

Rich Freeman posted on Wed, 18 Jan 2012 15:45:04 -0500 as excerpted:

> Again, you're using coreutils as an example, and that doesn't seem like
> something that would be much of a value-add to place in RDEPEND.
> However, if you had a package that required openssh, that would seem to
> be a much better candidate for an RDEPEND, since it is trivial to boot a
> system without openssh installed despite it being in system.

For years I had openssh in package.provided, since I literally did not 
have a use for it at all.  Then portage changed something and that didn't 
work, so I had it added as a negative dependency in packages (where 
busybox and module-init-tools are now, since I don't need either, all 
modules built-in so no module-loading needed and I have a full backup 
system install image copied over and test-booted for verification as my 
rescue image so no rescue shell needed, and I never could get busybox to 
build back when I used to try, until I gave up as no need for it anyway).

But when I got the netbook setup with the build chroot on the main 
system, I installed ssh to handle secure rsyncing and remote admin from 
my main system.  So THEN I needed it and simply deleted the negative 
dependencies.

But I STILL argue that ssh doesn't belong in @system.  It's as optional 
and special-purpose as X is, and xorg isn't in system.  If people want 
it, they can merge it, just like any other package.  Really, the same 
applies to busybox, and arguably, even to module-init-tools (and the more 
recent replacement, kmod...), since that's not needed if people choose to 
build all their drivers into the kernel.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: How help in arch testing work

[Mike Frysinger]

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

On Wednesday 18 January 2012 21:23:47 Duncan wrote:
> If people want
> it, they can merge it, just like any other package.  Really, the same
> applies to busybox, and arguably, even to module-init-tools (and the more
> recent replacement, kmod...), since that's not needed if people choose to
> build all their drivers into the kernel.

not really.  the # of people who build their kernel without module support is 
such a minority that they can suck it up and accept the additional dep, or 
simply use one of the many existing knobs in /etc/portage/ to disable it.

busybox is there because we believe Gentoo should have a rescue shell 
installed for when the system/user eats things and needs recovery without 
resorting to a livecd.  if you never make a mistake, then you're free to 
ignore it like anything else.
-mike

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

[gentoo-dev] Re: How help in arch testing work

[Duncan]

Mike Frysinger posted on Thu, 19 Jan 2012 11:46:21 -0500 as excerpted:

> On Wednesday 18 January 2012 21:23:47 Duncan wrote:
>> If people want it, they can merge it, just like any other package. 
>> Really, the same applies to busybox, and arguably, even to
>> module-init-tools (and the more recent replacement, kmod...), since
>> that's not needed if people choose to build all their drivers into the
>> kernel.
> 
> not really.  the # of people who build their kernel without module
> support is such a minority that they can suck it up and accept the
> additional dep, or simply use one of the many existing knobs in
> /etc/portage/ to disable it.

That's why I said "arguably, even..." for the kernel modules suggestion.  
I wasn't seriously making that argument, only stating that it could be 
made.

> busybox is there because we believe Gentoo should have a rescue shell
> installed for when the system/user eats things and needs recovery
> without resorting to a livecd.  if you never make a mistake, then you're
> free to ignore it like anything else.

Having other recovery arrangements (like the mentioned system backup 
partition, reachable with a simple alternate root= on the command line) 
!= never make a mistake!  In fact, it's precisely because I'm all too 
aware of the possibility of my own fat-fingering (or neural short-
circuiting) as well as recognition of the fact that I DO run ~arch and 
even masked packages (like the live-git openrc-9999) that I set it up 
that way, the rootbak solution being at once both FAR more resilient than 
a busybox after all still installed on the same working partition that 
we're assuming now has major faults of an unspecified type, thus 
triggering the emergency in the first place, AND far more flexible, since 
the rootbaky solution has all of the same tools in the same configuration 
as the user was using at the time the backup took place.  So if (as 
happened to a famous LWN editor at one point) an in-hindsight unwise 
system update shortly before a conference where an important presentation 
was to be made breaks the working installation, simply boot to rootbak 
instead, and do the presentation using a snapshot of the system taken 
when it was known to be working say a month or two earlier.

Busybox installed on a broken partition isn't going to help; neither will 
busybox alone allow you to do your presentation coming up in 15 minutes, 
if it's going to take 30 minutes of hacking to find and fix the problem.  
Simply rebooting to a tested working rootbak snapshot of the system made 
when it WAS working, using an alternate root= on the kernel command line, 
allows both, and a single root= change in grub is going to be far easier 
than working in an unfamiliar busybox environment, as well.

Of course, that implies changes to the handbook, etc, to encourage users 
to setup their rootbak partition (partitions, if /usr and /var are on 
separate partitions), and to periodically update AND TEST the rootbak 
system snapshot(s), when the system is known to be in a reasonably stable 
state.

But still, openssh is certainly the low hanging fruit, here, busybox less 
so and not at all as long as it remains the recommended and default 
emergency solution, and module-init-tools/kmod is only included as an 
example of an excludeable should we REALLY want to get strict with 
@system.

Meanwhile, the great thing about Gentoo is that it provides mechanisms 
such as /etc/portage/profile/packages for users who wish to, to make such 
changes on their own.  On that I'm quite sure pretty much everyone here 
can agree, or we'd not be here discussing it in the first place! =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] How help in arch testing work

[Mike Frysinger]

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

On Wednesday 18 January 2012 15:45:04 Rich Freeman wrote:
> On Wed, Jan 18, 2012 at 3:01 PM, Mike Frysinger wrote:
> > it is a problem.  not all profiles use "coreutils" ... they provide
> > replacement packages.  busybox is just one example.  the bsd/prefix guys
> > go in even weirder directions.
> 
> Yup - hence my point about coreutils not being a good one to include
> unless you virtualized it, which probably is more than we'd really
> want to do for a system package.

the virtual is irrelevant.  it's noise regardless.

> > DEPEND usage is useless cruft to the point of absurdity.
> > 
> > RDEPEND is much less common as then you're really only talking about the
> > random shell scripts.  i'd argue still though that it still doesn't make
> > sense considering a system can hardly boot without "coreutils".  and if
> > you are in a situation where you have such a reduced install that it
> > can, the existing @system semantics work for you.
> 
> Again, you're using coreutils as an example, and that doesn't seem
> like something that would be much of a value-add to place in RDEPEND.

a shell ?  sed ?  grep ?  find ?  awk ?  which ?

> However, if you had a package that required openssh, that would seem
> to be a much better candidate for an RDEPEND, since it is trivial to
> boot a system without openssh installed despite it being in system.

this is a bad example for many reasons:
 - there are already talks of getting rid of it (in favor of stage4/etc...)
 - this doesn't fall inline with our already long stated policy:
	http://devmanual.gentoo.org/general-concepts/dependencies/index.html
 - you're confusing the literal @system with implicit system deps

> Basically what I'm advocating is that somebody shouldn't have to
> defend their actions if they include something from @system in
> *DEPEND.  Future maintainers are welcome to undo the work of previous
> maintainers as always.  @system packages in *DEPEND should not be
> considered a bug (as long as they're right).

if it's part of the implicit system dep, they absolutely need to defend their 
actions.  you want to change the policy, then start a thread on it.
-mike

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

Re: [gentoo-dev] How help in arch testing work

[Mike Gilbert]

On Wed, Jan 18, 2012 at 10:05 PM, Mike Frysinger <vapier@gentoo.org> wrote:
>  - you're confusing the literal @system with implicit system deps

I don't quite follow here. By "implicit system deps", are you
referring to the "common sense" set of essential packages that you
have floating around in that brain of yours? :)

If so, it would save a lot of useless mailing list discussion if we
could just write that list down once and for good.

The devmanual specifically mentions the "entire system target", which
is logically interpreted as @system. If that's not the case, then lets
clarify that policy.

Re: [gentoo-dev] How help in arch testing work

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 18/01/12 10:41 PM, Mike Gilbert wrote:
> On Wed, Jan 18, 2012 at 10:05 PM, Mike Frysinger
> <vapier@gentoo.org> wrote:
>> - you're confusing the literal @system with implicit system deps
> 
> I don't quite follow here.
> 

literal @system = the exact packages listed in the 'system' package list

implicit deps = packages installed as part of the system due to
dependency resolution (including via use flags or whatnot and/or
default settings from the profile)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk8YSBMACgkQAJxUfCtlWe0LlAEAnSzthcxjk3BAFJSrYysjtiUl
mfQw1TMZ4wxcLgxJtQAA/jjquypoUwjCCJhwEYSNPM5dRHu3jNhapVfN2+8H32AF
=4LFJ
-----END PGP SIGNATURE-----

Re: [gentoo-dev] How help in arch testing work

[Mike Frysinger]

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

On Wednesday 18 January 2012 22:41:26 Mike Gilbert wrote:
> On Wed, Jan 18, 2012 at 10:05 PM, Mike Frysinger wrote:
> >  - you're confusing the literal @system with implicit system deps
> 
> I don't quite follow here. By "implicit system deps", are you
> referring to the "common sense" set of essential packages that you
> have floating around in that brain of yours? :)

this policy predates me, and i'm not the only one supporting it (i've had 
almost no hand in the construction of any part of the devmanual for examle).  
i might have a pretty good idea of what things entail now, but that's purely a 
matter of me staring at the guts of the core system for so long.

at this point, things can probably be enumerate a bit more clearly due to the 
slow culling of less important packages from @system.  i'd have to noodle.
-mike

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

Re: [gentoo-dev] How help in arch testing work

[Rich Freeman]

On Wed, Jan 18, 2012 at 10:05 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> if it's part of the implicit system dep, they absolutely need to defend their
> actions.  you want to change the policy, then start a thread on it.

What policy?  I don't see any written policy stating that you aren't
allowed to include system packages in *DEPEND.

There is a line in the devmanual stating that it is "not necessary,
nor advisable,..." to list some kinds of system dependencies, full of
caveats about the system set varying by profile and specific versions
and such.  It does not say that it is not permitted.

So, I don't really see any policy to change.  Anybody wanting to
create such a policy is of course welcome to start a thread on it...
:)

Rich

Re: [gentoo-dev] How help in arch testing work

[Mike Frysinger]

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

On Thursday 19 January 2012 09:04:08 Rich Freeman wrote:
> On Wed, Jan 18, 2012 at 10:05 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> > if it's part of the implicit system dep, they absolutely need to defend
> > their actions.  you want to change the policy, then start a thread on
> > it.
> 
> What policy?  I don't see any written policy stating that you aren't
> allowed to include system packages in *DEPEND.

we've always avoided depending on implicit system packages.  the devmanual was 
the first attempt and writing it down, but it doesn't change the history no 
matter how much you want otherwise.  the exact package list has been refined 
over time to shrink things down, but it hasn't change the policy.

> There is a line in the devmanual stating that it is "not necessary,
> nor advisable,..." to list some kinds of system dependencies, full of
> caveats about the system set varying by profile and specific versions
> and such.  It does not say that it is not permitted.

considering all the packages listed have known conflicts for other profiles, it 
is an error for you to attempt to include it.  and as already stated, doing it 
is "just in my packages" doesn't fly as crap spreads.
-mike

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

Re: [gentoo-dev] How help in arch testing work

[Agostino Sarubbo]

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

On Wednesday 18 January 2012 11:55:30 Alexis Ballier wrote:
> > 3) Check your rdepend, where is possible with scanelf[3] and if you
> > declare it, please, as you said, exclude gcc/glibc and all package
> > from @system
> 
> imho this has nothing to do with stabilization
There is a misunderstading about it. I did not mean what the other sayd.
So, if is not clear, the goal should be: check your RDEPEND before filing 
stabilization. Stop


> what i dislike in this approach is that arch testers will follow a
> test plan which the maintainer has obviously tested before and knows
> it works.
> sending people into the jungle of 'try to do something with $pkg' may
> make them encounter problems the maintainer hadnt thought about.

I think the same, but just for your info, there are, imho, few people that 
works in popular arches like x86/amd64 and is not possible because of missing 
of 'tester', imagine in arches like sparc/ia64 where only people like armin76 
works =)
-- 
Agostino Sarubbo		ago -at- gentoo.org
Gentoo/AMD64 Arch Security Liaison
GPG: 0x7CD2DC5D

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

[gentoo-dev] Re: How help in arch testing work

[Christian Faulhammer]

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

Hi,

Alexis Ballier <aballier@gentoo.org>:
> > 4) Nobody knows how work all packages in tree, so there are obvious
> > packages like a browsers, IM, audio player,that is easy decide if is
> > ok or not, but there are also packages that an Arch tester has never
> > seen, so is a lack of time everytime google about it or ask to
> > maintainer, so, please specify what test you want for this package;
> > e.g. -only compile test
> > -compile test and make sure src_test goes well
> > -make sure /usr/bin/${foo} works properly in ${that} manner
> > -see 5) about library
> > 
> > So, you can write one time 'how to' and copy/paste for the future
> > stablereq; I guess I'm not asking a long and difficult task.
> 
> what i dislike in this approach is that arch testers will follow a
> test plan which the maintainer has obviously tested before and knows
> it works.
> sending people into the jungle of 'try to do something with $pkg' may
> make them encounter problems the maintainer hadnt thought about.

 To stick with the Emacs example: We barely use all those packages we
maintain.  So sometimes we do not even execute this documented
test plan ourselves.  Of course it only contains a small subset of
everything, but some test plans contain a "fool around with the
program" and it is better than nothing.

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://gentoo.faulhammer.org/>

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

Re: [gentoo-dev] How help in arch testing work

[Mike Frysinger]

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

On Wednesday 18 January 2012 09:23:00 Agostino Sarubbo wrote:
> So, everytime, I must suggest the same things and I can say that at some
> point it gets boring.

so put it into a Gentoo guide and refer people to that

> 3) Check your rdepend, where is possible with scanelf[3] and if you declare
> it, please, as you said, exclude gcc/glibc and all package from @system

portage generates a NEEDED file in the vdb

> 4) Nobody knows how work all packages in tree, so there are obvious

sounds like a candidate for metadata.xml
-mike

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

Re: [gentoo-dev] How help in arch testing work

[Donnie Berkholz]

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

On 10:05 Wed 18 Jan     , Mike Frysinger wrote:
> On Wednesday 18 January 2012 09:23:00 Agostino Sarubbo wrote:
> > 3) Check your rdepend, where is possible with scanelf[3] and if you 
> > declare it, please, as you said, exclude gcc/glibc and all package 
> > from @system
> 
> portage generates a NEEDED file in the vdb

Awesome, never seen that before!

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer, Gentoo Linux <http://dberkholz.com>
Analyst, RedMonk <http://redmonk.com/dberkholz/>

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

Re: [gentoo-dev] How help in arch testing work

["Paweł Hajdan, Jr."]

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

On 1/18/12 4:48 PM, Donnie Berkholz wrote:
> On 10:05 Wed 18 Jan     , Mike Frysinger wrote:
>> On Wednesday 18 January 2012 09:23:00 Agostino Sarubbo wrote:
>>> 3) Check your rdepend, where is possible with scanelf[3] and if you 
>>> declare it, please, as you said, exclude gcc/glibc and all package 
>>> from @system
>>
>> portage generates a NEEDED file in the vdb
> 
> Awesome, never seen that before!

Same here. How about adding some warning to portage (maybe just in the
developer profile) when files in NEEDED are provided by packages not in
RDEPEND?


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

Re: [gentoo-dev] How help in arch testing work

[Mike Frysinger]

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

On Wednesday 18 January 2012 12:32:08 Paweł Hajdan, Jr. wrote:
> On 1/18/12 4:48 PM, Donnie Berkholz wrote:
> > On 10:05 Wed 18 Jan     , Mike Frysinger wrote:
> >> On Wednesday 18 January 2012 09:23:00 Agostino Sarubbo wrote:
> >>> 3) Check your rdepend, where is possible with scanelf[3] and if you
> >>> declare it, please, as you said, exclude gcc/glibc and all package
> >>> from @system
> >> 
> >> portage generates a NEEDED file in the vdb
> > 
> > Awesome, never seen that before!
> 
> Same here. How about adding some warning to portage (maybe just in the
> developer profile) when files in NEEDED are provided by packages not in
> RDEPEND?

atm, we'll get a lot of false positives due to over-linking.  the libtool + 
.la files "issue" is a general example.  another one off the top of my head: a 
package uses GTK+, so it runs `pkg-config --libs gtk+-2.0`, and links against a 
lot more stuff than GTK+, but it doesn't list those deps itself, so it'd fail.

we could extend the logic to assume anything not found in the pkg's RDEPEND, 
but was found in the full RDEPEND tree, is simply an implicit dep like that, 
but this quickly dilutes the usefulness i think :(.
-mike

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

Re: [gentoo-dev] How help in arch testing work

["Paweł Hajdan, Jr."]

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

On 1/18/12 7:10 PM, Mike Frysinger wrote:
> On Wednesday 18 January 2012 12:32:08 Paweł Hajdan, Jr. wrote:
>> Same here. How about adding some warning to portage (maybe just in the
>> developer profile) when files in NEEDED are provided by packages not in
>> RDEPEND?
> 
> atm, we'll get a lot of false positives due to over-linking.  the libtool + 
> .la files "issue" is a general example.  another one off the top of my head: a 
> package uses GTK+, so it runs `pkg-config --libs gtk+-2.0`, and links against a 
> lot more stuff than GTK+, but it doesn't list those deps itself, so it'd fail.
> 
> we could extend the logic to assume anything not found in the pkg's RDEPEND, 
> but was found in the full RDEPEND tree, is simply an implicit dep like that, 
> but this quickly dilutes the usefulness i think :(.

Oh, I meant the full RDEPEND tree in the above terminology.

It's not perfect indeed, but should catch most serious errors.

Also, we could make the "direct RDEPEND" problem a non-fatal warning.


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

Re: [gentoo-dev] How help in arch testing work

[Markos Chandras]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 01/18/2012 05:32 PM, "Paweł Hajdan, Jr." wrote:
> On 1/18/12 4:48 PM, Donnie Berkholz wrote:
>> On 10:05 Wed 18 Jan     , Mike Frysinger wrote:
>>> On Wednesday 18 January 2012 09:23:00 Agostino Sarubbo wrote:
>>>> 3) Check your rdepend, where is possible with scanelf[3] and
>>>> if you declare it, please, as you said, exclude gcc/glibc and
>>>> all package from @system
>>> 
>>> portage generates a NEEDED file in the vdb
>> 
>> Awesome, never seen that before!
> 
> Same here. How about adding some warning to portage (maybe just in
> the developer profile) when files in NEEDED are provided by
> packages not in RDEPEND?
> 
Interesting idea. I agree this has to be only in dev profile for now

- -- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iQIcBAEBCgAGBQJPFxcpAAoJEPqDWhW0r/LCplgP/2EpRfImbWztFPoRN0gw3edC
zhvSd0pQ8aVNSrT3A2f4abM0iigTtcrqLi2FoWAxxYOPrRFGftIKmLQVcRD82GFk
0CQtpDiQduEWozinSxITsp12lnvc/T0NDfnnLYRiys7+0t5FOdAsjceyR3+yObRL
3fFd5624n5PJoIISc82KFXs1WgKZhasf3XCxSaW7EAEKC4G9oxvTmGThCByUyyBf
v6jv+qk3UEYN+gI46TDMRF+2aDoSKKU1Tmb5N/XgHhixPHFxPf7nmgIDLb0SGGuQ
hlTLmQfsx9kVzGDdIdRl5ufuq2IjL0M0VUYP1qc5oiXh19SC2ddyIwMAQahLQEsL
NlaOOH+vchUlfENbXSPK6VwmbPH55h966JQezNcj53+VkfJ1PRnTPeUoE35sPn4D
aH++L7ioPog0jLKovRUYX+KRvjjQdLPuQe0t5V+f81yo1cjr13nL7o/ijfD6y/Me
9Vxr9kn/WwWQqlxzvb2UPtHYlFY+KbRnpGqh9bB4pP/y/dvEjcxjeNxxOGEHfIuP
tqVSBt0S6e326tsMXIQhPtYcd0j1KB+DCN0sV8QZpAlVbnq0ZsS2YbT9ls+RQdKr
9ttgwwZ6FLJungqul1QDIUh0qorBROTjC0J6bTrCoANyv0qYOMeinPLB+dozZF4d
/9M1VM3mnn5b/YVbnmYR
=Mp6K
-----END PGP SIGNATURE-----

Re: [gentoo-dev] How help in arch testing work

[Mike Frysinger]

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

On Wednesday 18 January 2012 14:02:01 Markos Chandras wrote:
> On 01/18/2012 05:32 PM, "Paweł Hajdan, Jr." wrote:
> > On 1/18/12 4:48 PM, Donnie Berkholz wrote:
> >> On 10:05 Wed 18 Jan     , Mike Frysinger wrote:
> >>> On Wednesday 18 January 2012 09:23:00 Agostino Sarubbo wrote:
> >>>> 3) Check your rdepend, where is possible with scanelf[3] and
> >>>> if you declare it, please, as you said, exclude gcc/glibc and
> >>>> all package from @system
> >>> 
> >>> portage generates a NEEDED file in the vdb
> >> 
> >> Awesome, never seen that before!
> > 
> > Same here. How about adding some warning to portage (maybe just in
> > the developer profile) when files in NEEDED are provided by
> > packages not in RDEPEND?
> 
> Interesting idea. I agree this has to be only in dev profile for now

would probably be easy to just whip up a tool that ran locally on all of the 
dev's installed packages ...
-mike

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

[gentoo-dev] Re: How help in arch testing work

[Michael]

On 19/01/2012 07:02, Mike Frysinger wrote:
> On Wednesday 18 January 2012 14:02:01 Markos Chandras wrote:
>> On 01/18/2012 05:32 PM, "Paweł Hajdan, Jr." wrote:
>>> On 1/18/12 4:48 PM, Donnie Berkholz wrote:
>>>> On 10:05 Wed 18 Jan     , Mike Frysinger wrote:
>>>>> On Wednesday 18 January 2012 09:23:00 Agostino Sarubbo wrote:
>>>>>> 3) Check your rdepend, where is possible with scanelf[3] and
>>>>>> if you declare it, please, as you said, exclude gcc/glibc and
>>>>>> all package from @system
>>>>>
>>>>> portage generates a NEEDED file in the vdb
>>>>
>>>> Awesome, never seen that before!
>>>
>>> Same here. How about adding some warning to portage (maybe just in
>>> the developer profile) when files in NEEDED are provided by
>>> packages not in RDEPEND?
>>
>> Interesting idea. I agree this has to be only in dev profile for now
>
> would probably be easy to just whip up a tool that ran locally on all of the
> dev's installed packages ...
> -mike

Although it does not make use of the newly-discovered NEEDED file, I 
wrote a tool a while back that checks scanelf output against RDEPEND: 
https://github.com/kensington/gentoo-tools/blob/master/missingdep.sh

Re: [gentoo-dev] How help in arch testing work

[Thomas Kahle]

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

On 15:23 Wed 18 Jan 2012, Agostino Sarubbo wrote:
[...] 

> 5) If is a library, obviously, we can try to rebuild stable RDEPENDS in tree 
> and an easy way to check the list of rdepend is asking our bot: 
> !rdep ${package}
> Unfortunately it prints a complete list of RDEPEND(stable+testing), and is a 
> lack of time checking manually what is the list of stable packages.

Can be done easily with some eix scripting.  app-portage/tatt has this
implemented too.

Cheers,
Thomas


-- 
Thomas Kahle
http://dev.gentoo.org/~tomka/

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

Re: [gentoo-dev] How help in arch testing work

["Paweł Hajdan, Jr."]

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

On 1/27/12 10:41 AM, Thomas Kahle wrote:
> On 15:23 Wed 18 Jan 2012, Agostino Sarubbo wrote:
> [...] 
> 
>> 5) If is a library, obviously, we can try to rebuild stable RDEPENDS in tree 
>> and an easy way to check the list of rdepend is asking our bot: 
>> !rdep ${package}
>> Unfortunately it prints a complete list of RDEPEND(stable+testing), and is a 
>> lack of time checking manually what is the list of stable packages.
> 
> Can be done easily with some eix scripting.  app-portage/tatt has this
> implemented too.

And my arch-tools also has a script for that (reverse-dependencies.py).


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