[gentoo-dev] Re: How help in arch testing work
Hi,
Alexis Ballier aball...@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/
signature.asc
Description: PGP signature
[gentoo-dev] Re: How help in arch testing work
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] Re: How help in arch testing work
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 signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: How help in arch testing work
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-) 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
[gentoo-dev] Re: How help in arch testing work
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
