Re: Mass-filing bugs based on piuparts?
Lars Wirzenius [EMAIL PROTECTED] writes: I'm running piuparts, my package installation, upgrading, and removal tester, against etch. It takes a while, and produces a fairly large number of error logs that need to be investigated manually. This sometimes reveals a bug in piuparts, and sometimes in the package, or a depency of the package. [...bug filing...] Is this acceptable to everyone? Suggestions on how to do this better? Yes, please do so. These are clearly bugs and need to be documented in the BTS to ensure that all of them are fixed (or at least not released with etch). Marc -- Fachbegriffe der Informatik - Einfach erklärt 190: Cisco Protokolhure. (unbekannt) pgpfbiChxJKCj.pgp Description: PGP signature
Re: Mass-filing bugs based on piuparts?
[Lars Wirzenius] The way I'm running it now, it installs and purges each package (plus dependencies), and then compares the state of the filesystem (the chroot) before and after and reports files that have been modified, removed, or created. Can you do upgrade testing as well. It would be great to know what packages fail to upgrade properly from woody to sarge, and from sarge to etch. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Mass-filing bugs based on piuparts?
In article [EMAIL PROTECTED] you wrote: Is this acceptable to everyone? Suggestions on how to do this better? This would be real great QA work, would you mind to also send a final or intermediate report with the most common errors you encountered. In my experience somebody who audits a particular aspect of a larger system is well suited to give trend analysis. Hopefully we find common errors which can be included in lintian or detected otherwise. I wonder if you already can report on common problems? Thans for your work Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Mass-filing bugs based on piuparts?
* Petter Reinholdtsen Can you do upgrade testing as well. It would be great to know what packages fail to upgrade properly from woody to sarge, and from sarge to etch. Indeed. And if you can, Lars, please include a test to see which packages which modify their own conffiles so the user is presented with a dpkg conffile changed dialogue during the upgrade. It would also be very interesting to see how many packages leave behind orphaned conffiles after purging a newer version which does not contain the files anymore. Regards -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Mass-filing bugs based on piuparts?
pe, 2005-07-22 kello 09:38 +0200, Petter Reinholdtsen kirjoitti: [Lars Wirzenius] The way I'm running it now, it installs and purges each package (plus dependencies), and then compares the state of the filesystem (the chroot) before and after and reports files that have been modified, removed, or created. Can you do upgrade testing as well. It would be great to know what packages fail to upgrade properly from woody to sarge, and from sarge to etch. Not in this run, I'm afraid. Just the simple test takes a while, and I'd prefer to wait for upgrade testing over the entire archive until there's more machines to run the tests one. piuparts can do the testing, however, and they will be run, later. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Mass-filing bugs based on piuparts?
Lars Wirzenius wrote: The way I'm running it now, it installs and purges each package (plus dependencies), and then compares the state of the filesystem (the chroot) before and after and reports files that have been modified, removed, or created. Quite simplistic, really, but good enough to find a number of problems already. Sounds interesting as I had the same idea. Is the source available? My plan was to write a tool which does such checks for a package installation on the most popular distries. But I too much to do with my 'wording' package, which aims to find wording problems in documentation and program messages. At the moment it can parse d-i templates, po and messages out of a PHP-suite; docbook.xml, HTML, POD and man coming soon. As with your tool I will have the same problem of mass-filing bugs. I hope to support this semi-automatically for my own convenience. Helmut Wollmersdorfer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Mass-filing bugs based on piuparts?
pe, 2005-07-22 kello 13:19 +0200, Helmut Wollmersdorfer kirjoitti: Lars Wirzenius wrote: The way I'm running it now, it installs and purges each package (plus dependencies), and then compares the state of the filesystem (the chroot) before and after and reports files that have been modified, removed, or created. Quite simplistic, really, but good enough to find a number of problems already. Sounds interesting as I had the same idea. Is the source available? See the piuparts package. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Mass-filing bugs based on piuparts?
On Thu, Jul 21, 2005 at 03:41:10PM +0300, Lars Wirzenius wrote: I'm running piuparts, my package installation, upgrading, and removal tester, against etch. It takes a while, and produces a fairly large number of error logs that need to be investigated manually. This sometimes reveals a bug in piuparts, and sometimes in the package, or a depency of the package. When there are problems in packages, I would like to file bugs. This is potentially a large number of bugs, up to hundreds. I want to file them one by one, not all at once, since it will take weeks or months to go through the entire archive. A few bugs a day, in other words, not hundreds all at once. I will verify the existence of every bug manually, and will attempt to use the best possible taste in deciding whether something is a bug in the package or not. For this first run, I will concentrate on the clear cases: if a package leaves /usr/bin/foo on the filesystem after purging, it is pretty clearly a bug. Is this acceptable to everyone? Suggestions on how to do this better? I say Go ahead!. I suggest you start with our base system; hopefully it's already correct, but you never know, and fixing such bugs as early in the release cycle as possible is important. Also, branch packages (for instance perl/php/python/apache/mysql) seems more important to test at an early stage than leaf packages (applications that use those packages). Regards: David -- /) David Weinehall [EMAIL PROTECTED] /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Mass-filing bugs based on piuparts?
Lars Wirzenius writes: Is this acceptable to everyone? It's fine with me. -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Mass-filing bugs based on piuparts?
On Thu, Jul 21, 2005 at 03:41:10PM +0300, Lars Wirzenius wrote: Is this acceptable to everyone? Suggestions on how to do this better? Any possibility of producing a nice web report on a per package basis? It could be useful to re-run periodically and your tester could probably have the same role of lintian/linda by this point of view. Filling BTS reports could be not so appropriate. Disclosure: I do not know piuparts at all :) -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Mass-filing bugs based on piuparts?
Francesco P. Lovergine writes: Any possibility of producing a nice web report on a per package basis? ... Filling BTS reports could be not so appropriate. I'd prefer bug reports. -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Mass-filing bugs based on piuparts?
On Thursday 21 July 2005 14.41, Lars Wirzenius wrote: [piuparts] Go ahead - if you, as you say, investigate the bugs manually, it doesn't matter how you discovered the bug. Just curious: what kind of bugs can piuparts help discover? cheers -- vbi -- The jig's up, Elman. Which jig? -- Jeff Elman pgpYpSaumNCys.pgp Description: PGP signature
Re: Mass-filing bugs based on piuparts?
to, 2005-07-21 kello 16:44 +0200, Francesco P. Lovergine kirjoitti: On Thu, Jul 21, 2005 at 03:41:10PM +0300, Lars Wirzenius wrote: Is this acceptable to everyone? Suggestions on how to do this better? Any possibility of producing a nice web report on a per package basis? It could be useful to re-run periodically and your tester could probably have the same role of lintian/linda by this point of view. Filling BTS reports could be not so appropriate. Disclosure: I do not know piuparts at all :) Something like this is planned by the QA team, and I'll do my best to help with that. Before that is created, I still want to run piuparts on the entire archive, if only to make sure we can deal with the all the weird things that packages do in postinst scripts and so (such as forcefully redirecting their stdin/stdout to /dev/tty and then asking question, despite DEBIAN_FRONTEND being set to noninteractive). As with lintian reports, when the tools find real bugs in the packages, bugs should be filed. However, since the tools are not infallible, bugs should not be filed automatically. (Ideally, of course, the maintainer will use the tools themselves and find and fix all such automatically found problems before uploading.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Mass-filing bugs based on piuparts?
to, 2005-07-21 kello 21:11 +0200, Adrian von Bidder kirjoitti: On Thursday 21 July 2005 14.41, Lars Wirzenius wrote: [piuparts] Go ahead - if you, as you say, investigate the bugs manually, it doesn't matter how you discovered the bug. Just curious: what kind of bugs can piuparts help discover? The way I'm running it now, it installs and purges each package (plus dependencies), and then compares the state of the filesystem (the chroot) before and after and reports files that have been modified, removed, or created. Quite simplistic, really, but good enough to find a number of problems already. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Mass-filing bugs based on piuparts?
On Thu, Jul 21, 2005 at 03:41:10PM +0300, Lars Wirzenius wrote: Is this acceptable to everyone? Suggestions on how to do this better? Hi Lars, by all means, proceed! Who say FLOSS lacks 'innovation'! Debian devs seem to comeup with good ideas all the time! Also, have you determined if any patterns have emerged in terms of error output. May be a summary mail of related bugs and associated packages so that folks can see what is happening and then a possible fix for each class. This could be a list of things of which to be aware during developement of upgrade scripts. Next stop, Mexico(not HEL)! Kev -- counter.li.org #238656 -- goto counter.li.org and be counted! `$' $' $ $ _ ,d$$$g$ ,d$$$b. $,d$$$b`$' g$b $,d$$b ,$P' `$ ,$P' `Y$ $$' `$ $ ' `$ $$' `$ $$ $ $$g$ $ $ $ ,$P $ $$ `$g. ,$$ `$$._ _. $ _,g$P $ `$b. ,$$ $$ `Y$$P'$. `YP $$$P' ,$. `Y$$P'$ $. ,$. signature.asc Description: Digital signature
