Re: test /etc/init.d/MyPackage start before shipping, please
On Sat, Mar 24, 2012 at 10:32:00AM +0800, jida...@jidanni.org wrote: It doesn't matter who is to blame. A simple /etc/init.d/... start test could catch such grave bugs before they hit the user. Who is to blame could be figured out internally. Of course it matters. If you don't understand the explanations being offered to you then kindly stop offering half-baked suggestions to real developers and let them get on with their volunteering in peace. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120329105201.GD32743@debian
Re: test /etc/init.d/MyPackage start before shipping, please
jida...@jidanni.org writes: It doesn't matter who is to blame. A simple /etc/init.d/... start test could catch such grave bugs before they hit the user. Who is to blame could be figured out internally. And ftp-master should run that after every dinstall run for every single package in the archive to see if any of the uploads broke an existing package? Please do switch on your brain. As James said it wasn't broken when it was shipped. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wr6a3ykm.fsf@frosties.localnet
test /etc/init.d/MyPackage start before shipping, please
I have an idea, all /etc/init.d/ script packages should test to see they actually can be started and stopped before their debs get shipped. Hmmm, and all bin/ programs should given a test run too... to at least see they can print --version without segfaulting etc. Hmmm, all even more important than piuparts. I mean it would avoid show stoppers of the first degree. AT == Arno Töll deb...@toell.net writes: AT On 24.03.2012 01:59, jida...@jidanni.org wrote: May I humbly request that your build scripts in the future take the automobile for a test drive (/etc/init.d/apache2 start at least) at the factory, before it reaches the dealership. AT And your point is? Our package worked just fine until someone else AT decided to break unrelated packages by uploading broken reverse AT dependencies exactly 8 days after uploading and building our package - AT or to put it with your words after it left the factory. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87mx76wz4w.fsf...@jidanni.org
Re: test /etc/init.d/MyPackage start before shipping, please
On Sat, Mar 24, 2012 at 09:45:03AM +0800, jida...@jidanni.org wrote: I have an idea, all /etc/init.d/ script packages should test to see they actually can be started and stopped before their debs get shipped. As Arno already stated[0], this isn't a problem with Apache. One of the libraries it depends on was incorrectly uploaded with a changed ABI. When Apache then tried to use the library, it obviously failed. No amount of testing Apache would have caught that a library upload 10 days later would be broken. [0]: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=20;bug=665330 -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy james...@debian.org signature.asc Description: Digital signature
Re: test /etc/init.d/MyPackage start before shipping, please
On Friday, March 23, 2012 21:45:03, jida...@jidanni.org wrote: I have an idea, all /etc/init.d/ script packages should test to see they actually can be started and stopped before their debs get shipped. Hmmm, and all bin/ programs should given a test run too... to at least see they can print --version without segfaulting etc. Hmmm, all even more important than piuparts. I mean it would avoid show stoppers of the first degree. Servers build the packages in a chrooted jail after they're uploaded, but the chrooted jail usually doesn't have the necessary environment to actually run the programs/packages in question. Changing that to do this quick test would involve installing all the necessary dependencies. As a concrete example, testing the program 'kate' would involve installing a lot of KDE4 within the chroot. I suspect this would greatly slow the build process. And in general, Debian Developers/Maintainers are expected to test the programs and packages they build, so this quick test is already being done client-side rather than server-side before the upload. AT == Arno Töll deb...@toell.net writes: AT On 24.03.2012 01:59, jida...@jidanni.org wrote: May I humbly request that your build scripts in the future take the automobile for a test drive (/etc/init.d/apache2 start at least) at the factory, before it reaches the dealership. AT And your point is? Our package worked just fine until someone else AT decided to break unrelated packages by uploading broken reverse AT dependencies exactly 8 days after uploading and building our package - AT or to put it with your words after it left the factory. The proposed test would not have caught this problem, because the library is built separately from apache2, and apache2 had not been updated AFAIK. The bottom line is that even though it sounds like a reasonable idea in theory, it's probably not practical to do in practice. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201203232212.10147.chris.kna...@coredump.us
Re: test /etc/init.d/MyPackage start before shipping, please
It doesn't matter who is to blame. A simple /etc/init.d/... start test could catch such grave bugs before they hit the user. Who is to blame could be figured out internally. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87iphuwwyn@jidanni.org
