About ignoring problems instead of fixing them
From farbror (CD build server): --- tools/boot/squeeze/boot-x86 (revision 1964) +++ tools/boot/squeeze/boot-x86 (working copy) @@ -230,7 +230,8 @@ boot$N/isolinux/win32-loader.ini boot$N/ fi - if [ -e boot$N/isolinux/f3.txt.withgtk ]; then + + if [ 0 = 1 ] -e boot$N/isolinux/f3.txt.withgtk ]; then extra_image gtk/initrd.gz mv boot$N/isolinux/f3.txt.withgtk boot$N/isolinux/f3.txt mv boot$N/isolinux/f4.txt.withgtk boot$N/isolinux/f4.txt Wow, so now the build does not fail. Is it really better to ignore errors and create broken images [1] than to actually solve the error? That really sucks. It would have been so much nicer if, when you don't know the cause of a problem or how to solve it, to write a mail and discuss it on the relevant lists so that others could have been given an opportunity to help or comment. I've already committed a proper fix in D-I for this a bit earlier [2] and therefore reverted this nonsense. After testing if my fix is correct I'll also upload D-I again as otherwise 'alpha1' images would also be broken. In despair at how problems appear to be solved nowadays, FJP [1] Apparently nobody has even bothered to test a daily built image recently because if they had it would have been obvious that it includes syslinux options for the graphical installer that don't work. And I've even *said* that this should be tested when we discussed disabling the graphical installer on d-boot. [2] And then did a local test build which failed and then wondered why daily builds were not failing. -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: About ignoring problems instead of fixing them
On Thursday 24 December 2009, you wrote: I saw that the graphical images weren't available any more so I disabled them. Problem is that you did not disable them. You only silently ignored a failure, with the result that you were creating broken images. If I had not accidentally caught that now, we would have had a release with broken images. I would not have minded if you'd ignored the failure and at the same time informed people of the problem so that it could be looked into and solved properly. From the last discussion I saw fly past, it looks like the lack of graphical images is a known feature. Yes. They have been disabled on purpose. But the system is supposed to be flexible enough to *see* whether or not D-I is building graphical images [1] and then excluding those options from the isolinux menu. But because we've never had that situation before, this was not actually implemented 100% on the D-I side. debian-cd uses the file f3.txt.withgtk to test do we have graphical or not, so D-I should not be including that file if graphical is disabled. I'm getting dozens of complaints every time the weekly builds fail these days, so with no further information to go on and no warning from the d-i folks I took this choice. There was no warning because it was supposed to work. That means that we need a main or bug report to inform us of breakage. Without that there's no trigger to fix the problem. So now we need an extra upload of D-I to fix the problem instead of having had the problem fixed shortly after Otavio committed the change to disable the graphical images. It's getting painful using the daily-built d-i images for the weekly testing CDs, as the number of broken builds is very high. True. Weekly builds are supposed to be built from released D-I images instead of daily images. Unfortunately the D-I release manager has been unable to get a release out so far. I would really *really* like to see d-i properly integrated into the archive and uploaded periodically so it can migrate to testing, as we've discussed in the past many times. The current situation is a train wreck. This broken record argument from you will not help *at all* (as I've tried to explain several times in the past). Do you really think that when people are unable to get a release going in almost a year that periodic uploads magically are going to be correct? If daily builds fail then builds integrated in the archive will fail just as hard. One solution could be to change the upload script for D-I daily images to not upload anything except the log files if a daily build fails. The real problem is that nobody is monitoring builds, doing any testing or fixing any issues on any frequent basis. Not like Joey and I used to do in the past. I currently do not consider myself as the person who monitors things, so I only react to concrete reported problems. Even so if I do still seem to end up catching and fixing most issues. BTW, I thought that d-cd simply kept the old images if a build failed for an arch, or is that only implemented for daily builds? Cheers, FJP [1] There is a difference between a graphical images failing and being disabled. The case of graphical images failing while normal images do build is not handled, but that is fairly exceptional. -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: About ignoring problems instead of fixing them
On Thu, Dec 24, 2009 at 09:33:03PM +0100, Frans Pop wrote: From farbror (CD build server): --- tools/boot/squeeze/boot-x86 (revision 1964) +++ tools/boot/squeeze/boot-x86 (working copy) @@ -230,7 +230,8 @@ boot$N/isolinux/win32-loader.ini boot$N/ fi - if [ -e boot$N/isolinux/f3.txt.withgtk ]; then + + if [ 0 = 1 ] -e boot$N/isolinux/f3.txt.withgtk ]; then extra_image gtk/initrd.gz mv boot$N/isolinux/f3.txt.withgtk boot$N/isolinux/f3.txt mv boot$N/isolinux/f4.txt.withgtk boot$N/isolinux/f4.txt Wow, so now the build does not fail. Is it really better to ignore errors and create broken images [1] than to actually solve the error? That really sucks. I saw that the graphical images weren't available any more so I disabled them. From the last discussion I saw fly past, it looks like the lack of graphical images is a known feature. I'm getting dozens of complaints every time the weekly builds fail these days, so with no further information to go on and no warning from the d-i folks I took this choice. It's getting painful using the daily-built d-i images for the weekly testing CDs, as the number of broken builds is very high. I would really *really* like to see d-i properly integrated into the archive and uploaded periodically so it can migrate to testing, as we've discussed in the past many times. The current situation is a train wreck. -- Steve McIntyre, Cambridge, UK.st...@einval.com Since phone messaging became popular, the young generation has lost the ability to read or write anything that is longer than one hundred and sixty characters. -- Ignatios Souvatzis -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: About ignoring problems instead of fixing them
On Thursday 24 December 2009, Frans Pop wrote: I would really *really* like to see d-i properly integrated into the archive and uploaded periodically so it can migrate to testing, as we've discussed in the past many times. The current situation is a train wreck. And you simply cannot use periodic uploads for daily CD images. Why? Because the udebs used in D-I images must match the udebs loaded from CD later in the installation. If you'd use periodic D-I uploads as a basis for daily CD builds (or network based installs), you will still end up with images that don't work because the two will slowly diverge due to uploads to sid. So: daily CD builds *must* use daily built D-I images. Some occasional and mostly temporary breakage is unavoidable. In a lot of cases (sid just being sid) a problem will resolve itself within a day or two. If a problem persists it simply needs to be traced and solved. -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: About ignoring problems instead of fixing them
On Thursday 24 December 2009, Frans Pop wrote: I've already committed a proper fix in D-I for this a bit earlier [2] and therefore reverted this nonsense. After testing if my fix is correct I'll also upload D-I again as otherwise 'alpha1' images would also be broken. The last CD build failed because it was still using old D-I images, but I've just done a local CD build using Joey's current images and that looks perfect: no build errors and a correct syslinux menu without graphical installer options. So the next daily CD builds should also be OK again. Cheers, FJP -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
