Bug#587886: future of maintaining of the bootloader LILO
Dear members of CTTE, thank you very much for you decision. Now I can start with the maintaining of LILO. Have a nice day, Joachim (Germany) signature.asc Description: PGP signature
Bug#587886: future of maintaining of the bootloader LILO
Ian Jackson writes (Bug#587886: future of maintaining of the bootloader LILO): No, I don't think so. There's nothing more to be said. [for reference: A. lilo should be removed. In the meantime, William is to be sole maintainer of lilo. His promised request to the ftp team to remove lilo should be honoured, after which the ftp masters should not permit Matt and/or Joachim to reupload a new lilo package. B. lilo should be retained in unstable. Matt and Joachim are to be joint maintainers of lilo. ... I vote: I'm changing my vote as follows: 1: B 2: A 3: SQ Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587886: future of maintaining of the bootloader LILO
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Don Armstrong (d...@debian.org) [101129 12:06]: [for reference: A. lilo should be removed. In the meantime, William is to be sole maintainer of lilo. His promised request to the ftp team to remove lilo should be honoured, after which the ftp masters should not permit Matt and/or Joachim to reupload a new lilo package. B. lilo should be retained in unstable. Matt and Joachim are to be joint maintainers of lilo. ] I vote: B, A, further discussion (and obviously in case B is the decision, the maintainers are still allowed to request removal any time they consider it appropriate; also for reference, I don't see so bad issues with lilo that we need to enforce removal from the archive despite there are maintainers willing to take care of lilo (usual RC bug procedures of course still apply); and last not least please take care of the current release process with new uploads to unstable at this time of the cycle) Andi -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkz1MNAACgkQmdOZoew2oYVwVQCgqQdQjcC3PSIOiA+4glXkz7If qGUAoKA8j8ztb8x2hBAhOnT7WBb5WNNZ =LEI/ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587886: future of maintaining of the bootloader LILO
On Mon, 29 Nov 2010, Don Armstrong wrote: Is there any objection to starting the voting process on this issue with the options presented in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=587886#55 ? [for reference: A. lilo should be removed. In the meantime, William is to be sole maintainer of lilo. His promised request to the ftp team to remove lilo should be honoured, after which the ftp masters should not permit Matt and/or Joachim to reupload a new lilo package. B. lilo should be retained in unstable. Matt and Joachim are to be joint maintainers of lilo. I vote B A Status Quo Don Armstrong[1] 1: Whose brain seized up at SQ. -- My spelling ability, or rather the lack thereof, is one of the wonders of the modern world. http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587886: future of maintaining of the bootloader LILO
On Mon, 22 Nov 2010, Russ Allbery wrote: Ian Jackson ijack...@chiark.greenend.org.uk writes: Joachim Wiedorn writes: Finally it would be nice we could move the new Debian packages into Debian unstable ... I agree that Joachim and Matt Arnold should be made the joint lilo maintainers. Would other TC members please express an opinion ? If people are actively maintaining lilo, then yes, I think those people should be the package maintainers in preference to removing the package. In general, I think a good principle to follow is that if there are people who actively care about a package, we shouldn't remove that package unless there's some sort of overriding issue. Is there any objection to starting the voting process on this issue with the options presented in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=587886#55 ? [for reference: A. lilo should be removed. In the meantime, William is to be sole maintainer of lilo. His promised request to the ftp team to remove lilo should be honoured, after which the ftp masters should not permit Matt and/or Joachim to reupload a new lilo package. B. lilo should be retained in unstable. Matt and Joachim are to be joint maintainers of lilo. ] Don Armstrong -- Quite the contrary; they *love* collateral damage. If they can make you miserable enough, maybe you'll stop using email entirely. Once enough people do that, then there'll be no legitimate reason left for anyone to run an SMTP server, and the spam problem will be solved. -- Craig Dickson in 20020909231134.ga18...@linux700.localnet http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587886: future of maintaining of the bootloader LILO
Don Armstrong writes (Bug#587886: future of maintaining of the bootloader LILO): Is there any objection to starting the voting process on this issue with the options presented in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=587886#55 ? No, I don't think so. There's nothing more to be said. [for reference: A. lilo should be removed. In the meantime, William is to be sole maintainer of lilo. His promised request to the ftp team to remove lilo should be honoured, after which the ftp masters should not permit Matt and/or Joachim to reupload a new lilo package. B. lilo should be retained in unstable. Matt and Joachim are to be joint maintainers of lilo. I vote: 1: A 2: B 3: SQ Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587886: future of maintaining of the bootloader LILO
Don Armstrong d...@debian.org writes: Is there any objection to starting the voting process on this issue with the options presented in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=587886#55 ? Sounds fine to me. [for reference: A. lilo should be removed. In the meantime, William is to be sole maintainer of lilo. His promised request to the ftp team to remove lilo should be honoured, after which the ftp masters should not permit Matt and/or Joachim to reupload a new lilo package. B. lilo should be retained in unstable. Matt and Joachim are to be joint maintainers of lilo. ] I vote: B A further discussion -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ pgpBCK6EcMfn6.pgp Description: PGP signature
Bug#587886: future of maintaining of the bootloader LILO
Joachim Wiedorn writes (Bug#587886: future of maintaining of the bootloader LILO): Finally it would be nice we could move the new Debian packages into Debian unstable ... I agree that Joachim and Matt Arnold should be made the joint lilo maintainers. Would other TC members please express an opinion ? However we should not upload Joachim's new version to xen-unstable, because of the freeze. Joachim, amongst your fixes are there any that are very important RC bugfixes and which you are sure aren't going to break anything ? Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587886: future of maintaining of the bootloader LILO
Ian Jackson ijack...@chiark.greenend.org.uk writes: Joachim Wiedorn writes: Finally it would be nice we could move the new Debian packages into Debian unstable ... I agree that Joachim and Matt Arnold should be made the joint lilo maintainers. Would other TC members please express an opinion ? If people are actively maintaining lilo, then yes, I think those people should be the package maintainers in preference to removing the package. In general, I think a good principle to follow is that if there are people who actively care about a package, we shouldn't remove that package unless there's some sort of overriding issue. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587886: future of maintaining of the bootloader LILO
Ian Jackson ijack...@chiark.greenend.org.uk wrote on 2010-11-22 11:27: Joachim Wiedorn writes (Bug#587886: future of maintaining of the bootloader LILO): Finally it would be nice we could move the new Debian packages into Debian unstable ... I agree that Joachim and Matt Arnold should be made the joint lilo maintainers. Would other TC members please express an opinion ? However we should not upload Joachim's new version to xen-unstable, because of the freeze. That is o.k. because the new packages are made with the new release of lilo. Only one point would be interesting at this time: I would like to work on the bug reports (comments, tags). But I want to start with this work at first if I am defined as maintainer of the lilo package. I don't want to run in conflict with the (old) maintainer. Joachim, amongst your fixes are there any that are very important RC bugfixes and which you are sure aren't going to break anything ? Really there would be at least one bugfix which would be worth to go into 22.8 package: lilo compute the needed RAM undersized for newer kernels. The patch would be: http://git.debian.org/?p=lilo/lilo.git;a=commit;h=84ed3605738f8dcf8f960ea53c7cc4d44d6405c9 Then we could remove the warning in debian/lilo.postinst. Have a nice day, Joachim (Germany) signature.asc Description: PGP signature
Bug#587886: future of maintaining of the bootloader LILO
Hello, in the last four months I worked further on the development of LILO which can be seen on the project homepage and LILO homepage: https://alioth.debian.org/projects/lilo/ http://lilo.alioth.debian.org/ One result of my development on LILO is the release version 23.1 (from 2010-11-04), which can be downloaded here: https://alioth.debian.org/frs/?group_id=100507 and can also be seen in the git repository here: http://git.debian.org/?p=lilo/lilo.git;a=summary The newest outcome results from the collaboration with some Ubuntu developers: they wished not only to create Debian packages but also, with the same source package, Ubuntu packages. This work is now done. There are new packages for Debian and Ubuntu, made with the same source package of LILO 23.1. It can be seen in the following git repository: http://git.debian.org/?p=lilo/debian.git;a=summary and can be downloaded for Debian Squeeze (i386, amd64): http://lilo.alioth.debian.org/ftp/debian/ and also for Ubuntu Natty (i386, amd86): http://lilo.alioth.debian.org/ftp/ubuntu/ While working on these new packages I have analyzed all bugreports for LILO in Debian and Ubuntu. I have created many patches which can now be used to close 25 Debian bugreports and 5 Ubuntu bugreports. Finally it would be nice we could move the new Debian packages into Debian unstable ... Have a nice day, Joachim (Germany) signature.asc Description: PGP signature
Bug#587886: future of maintaining of the bootloader LILO
On Sat, 10 Jul 2010, Ian Jackson wrote: I think it's clear from William's response that joint maintainership involving both William on one hand, and one or both of Matt and Joachim on the other hand, is not tenable. I think this leaves the Technical Committee with two options: A. lilo should be removed. In the meantime, William is to be sole maintainer of lilo. His promised request to the ftp team to remove lilo should be honoured, after which the ftp masters should not permit Matt and/or Joachim to reupload a new lilo package. B. lilo should be retained in unstable. Matt and Joachim are to be joint maintainers of lilo. If lilo is retained in unstable that does not mean, of course, that it will be included in squeeze (or indeed any other relase). If anyone (William included) feels that the package has bugs which are so serious that they should not be included in Debian releases, then they may file bugs at a release-critical severity. If the bugs are determined to be release-critical (by the maintainer in the first instance of course, but subject to review by the Release Team and Technical Committee) then the package will not be released. Does anyone disagree with this assessment ? This sounds correct and reasonable to me. Is anyone not happy with bringing this issue to a vote in the near future? Is there some other question or more information which we need to resolve? Don Armstrong -- If I had a letter, sealed it in a locked vault and hid the vault somewhere in New York. Then told you to read the letter, thats not security, thats obscurity. If I made a letter, sealed it in a vault, gave you the blueprints of the vault, the combinations of 1000 other vaults, access to the best lock smiths in the world, then told you to read the letter, and you still can't, thats security. -- Bruce Schneier http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587886: future of maintaining of the bootloader LILO
On Sun, 08 Aug 2010 21:55:50 -0400 (EDT), Joachim Wiedorn wrote: in the last weeks nothing going on with the package Lilo. Now there is a new RC bug and Squeeze is already frozen. So I have decided to orphan this package and give other people the chance to overtake the maintaining of lilo to bring it in a good shape before Squeeze will be stable: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=592200 That is premature. Please don't do that. RC bugs can still be fixed after a freeze. If the RC bug still exists at the time of release, the package will be removed from Squeeze. But an RC bug at the time of freeze is not a fatal problem. But now I understand it was premature to orphan Lilo. I have thought the decision of TC is set by one member. But now it seems to me that the TC must decide together as team and this can take a longer time. So I will offer to revert my act of orphaning and wait until the TC have decided. Yes, please do. I would hate to see all your hard work go to waste. I am willing to help, but I don't think I'm quite ready to be a DM yet, especially for a package which requires knowledge of x86 assembly language. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587886: future of maintaining of the bootloader LILO
Hello, in the last weeks nothing going on with the package Lilo. Now there is a new RC bug and Squeeze is already frozen. So I have decided to orphan this package and give other people the chance to overtake the maintaining of lilo to bring it in a good shape before Squeeze will be stable: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=592200 I feel that the time run away for Lilo to come in a state to be usable before Squeeze is new stable. Then I have created an updated package of Lilo with patches for the RC bug and a few other bugs. But now I understand it was premature to orphan Lilo. I have thought the decision of TC is set by one member. But now it seems to me that the TC must decide together as team and this can take a longer time. So I will offer to revert my act of orphaning and wait until the TC have decided. Excuse me for this rash step. Have a nice day, Joachim (Germany) signature.asc Description: PGP signature
Bug#587886: future of maintaining of the bootloader LILO
For what it's worth: As promised in my previous post, I tried lilo 23.0 on my old Pentium II machine, which is an IBM ThinkPad 600. It works perfectly for me. I do not experience the triple-fault continuous reboot loop that William claims to experience on his Pentium II machine. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587886: future of maintaining of the bootloader LILO
Gentlemen, I just subscribed to this bug log as an interested party. Allow me to put in my two cents worth, if I may. (1) On behalf of Debian's lilo users, of which I am one, please do not remove lilo from the distribution. I used lilo for many years. When the default boot loader changed to grub version 1, I went with grub version 1. But when grub version 2 became the default with Squeeze, it wouldn't work for me. I switched back to lilo, and I have been using it ever since. And lots of other users use it too. It has a very loyal following. (2) William Pitcock is obviously a very smart man and a very capable maintainer; and I have nothing personal against him; but by making public statements such as lilo has no future, let the damn thing die already, nobody cares what you want, and other similar comments, he has, in my humble opinion, disqualified himself as a legitimate candidate for lilo's maintainer, regardless of how great his technical skills may be. A maintainer should nourish and cherish his package, not try to kill it off. Putting William in charge of lilo is like putting the fox in charge of the hen house. The fox does not have the hens' best interests at heart. I am currently using Joachim's lilo 23.0 on my Dell OptiPlex GX400, and it works flawlessly for me. That's not to say that it has no bugs: it probably does. But to say that it has no merit is going too far. I also have an old Pentium II machine, as William does. I'm going to try out lilo 23.0 there next. I also am volunteering to help out, whether in an official capacity or an unofficial capacity I really don't care. lilo's recent problems are mostly due to a change made to the official Debian stock kernel image package maintainer scripts for Lenny, which essentially broke the support for lilo, although no-one realized it at the time. (See Debian bug number 505609.) Everyone assumed that lilo's map installer was being run following a kernel upgrade, but it wasn't. Everyone assumed that lilo had some kind of fatal flaw. But it wasn't lilo's fault. I am the one who found the cause of that problem. It has been fixed now in the latest stable point release (5.0.5); but for Squeeze, the kernel people would not reinstate the kernel maintainer scripts' historic support for lilo. Hook scripts are now required to make lilo work properly under Squeeze, and /etc/kernel-img.conf must also be set up properly. Those trying to migrate to lilo from grub will have trouble if they don't set up the environment properly. See my unofficial custom kernel-building web page, http://www.wowway.com/~zlinuxman/Kernel.htm, under Step 10: Customizing the kernel installation environment, for more details. Joachim may be a little green, but he wants to see lilo succeed. And that is the most important qualification, in my opinion. Respectfully submitted. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587886: future of maintaining of the bootloader LILO
Hi, - Ian Jackson ijack...@chiark.greenend.org.uk wrote: Joachim Wiedorn writes (Bug#587886: future of maintaining of the bootloader LILO): because of the discussions of the last weeks mostly on debian-devel I have sent this bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=587886 to the Technical Committee of Debian to find a solution. I've caught up on all of this now. I'm not sure I quite understand the position of the current lilo maintainers. In http://lists.debian.org/debian-devel/2010/05/msg00769.html William writes: it has pretty much been determined that kernel sizes have crossed the line past where lilo can reliably determine the payload size. William, to what are you referring ? Can you provide a bug number ? Please read all of the bug reports on lilo. At least half of them are related to this issue. Fortunately, payload sizes have dropped below the watermark. William and Matt: Can you confirm that you still intend to remove lilo from squeeze ? Matt really is not part of this decision-making process at this time, as he has never provided any insight into any critical decisions with this package. Simply put: he is not qualified to maintain lilo and adding him to Uploaders was a terrible mistake. His motivation for maintaining lilo is that it's a 'high-calibur' package. I regret that mistake. Do we have another person who wants to maintain lilo in Debian ? It should not be maintained by someone who simply blindly applies patches to the 22.8 source. I believe that giving Joachim maintainership of lilo is actively harmful to the QA process of Debian, and will continue to believe so until his work on lilo actually has merit. If I believed otherwise, then lilo 23.0 would be uploaded right now obviously. On a side note: the bug reporter needs to find something better to do with their time. lilo has no future. Making a 23.0 release with nothing other than *broken* patches does not give it one. Let the damned thing die already. William -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587886: future of maintaining of the bootloader LILO
- Ian Jackson ijack...@chiark.greenend.org.uk wrote: Ian Jackson writes (Bug#587886: future of maintaining of the bootloader LILO): I've caught up on all of this now. I'm not sure I quite understand the position of the current lilo maintainers. In http://lists.debian.org/debian-devel/2010/05/msg00769.html William writes: it has pretty much been determined that kernel sizes have crossed the line past where lilo can reliably determine the payload size. William, to what are you referring ? Can you provide a bug number ? William and Matt: Can you confirm that you still intend to remove lilo from squeeze ? I've had private email exchanges with Matt (the other existing lilo maintainer) and Joachim. Matt and Joachim tell me that are keen to keep lilo in Debian and to maintain it. However due to disagreements with his co-maintainer Matt has been having difficulty getting sponsorship for uploads. William, are you be happy for Joachim to join the maintainer list for lilo ? What is your current view about the future of lilo ? In particular, is it appropriate for sponsors to sponsor uploads of new versions from Matt and Joachim ? It is not appropriate at this time, Matt is not qualified to maintain the package, and Joachim is just blindly applying patches and calling it a new version. I am not convinced that either actually know how lilo works. Specifically, LILO 23.0 is a dud on my old Pentium 2 machine while 22.8 is not. 23.0 triple-faults in the second stage boot process causing a reboot loop. Further, I am not even convinced that they are testing their releases on machines that run LILO. William -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587886: future of maintaining of the bootloader LILO
William, thanks for replying with your position and stating it very clearly. It's very helpful for us to know exactly what you think. William Pitcock writes (Re: Bug#587886: future of maintaining of the bootloader LILO): [Ian Jackson:] I've caught up on all of this now. I'm not sure I quite understand the position of the current lilo maintainers. In http://lists.debian.org/debian-devel/2010/05/msg00769.html William writes: it has pretty much been determined that kernel sizes have crossed the line past where lilo can reliably determine the payload size. William, to what are you referring ? Can you provide a bug number ? Please read all of the bug reports on lilo. At least half of them are related to this issue. Fortunately, payload sizes have dropped below the watermark. I've done as you asked and looked at the bug reports on lilo. I reviewed the title lines, and where necessary the bug log, of every bug report to decide whether the bug could possibly be due to an image size limitation as you suggest. Of the bugs only #357567 could possibly match the description you have given so far and that only at a huge stretch. If you still think that there is some really hard to fix image size limitation with lilo, could you please provide a more specific reference. William and Matt: Can you confirm that you still intend to remove lilo from squeeze ? Matt really is not part of this decision-making process at this time, as he has never provided any insight into any critical decisions with this package. The question is now before the Technical Committee, and our decision-making process will include consulting with Matt and Joachim and anyone else relevant. So Matt _is_ part of the decision-making process at this time. On a side note: the bug reporter needs to find something better to do with their time. lilo has no future. Making a 23.0 release with nothing other than *broken* patches does not give it one. Release with nothing other than broken patches is a very strong statement. Can you justify that ? For example, you could list the patches in Joachim's 23.0 release and explain why each of them is broken ? Joachim, do you have a convenient list of the patches you have folded into 23.0 ? What level of technical review were you able to give to them ? What is your opinion of the general quality of those patches ? Let the damned thing die already. I think it's clear from William's response that joint maintainership involving both William on one hand, and one or both of Matt and Joachim on the other hand, is not tenable. I think this leaves the Technical Committee with two options: A. lilo should be removed. In the meantime, William is to be sole maintainer of lilo. His promised request to the ftp team to remove lilo should be honoured, after which the ftp masters should not permit Matt and/or Joachim to reupload a new lilo package. B. lilo should be retained in unstable. Matt and Joachim are to be joint maintainers of lilo. If lilo is retained in unstable that does not mean, of course, that it will be included in squeeze (or indeed any other relase). If anyone (William included) feels that the package has bugs which are so serious that they should not be included in Debian releases, then they may file bugs at a release-critical severity. If the bugs are determined to be release-critical (by the maintainer in the first instance of course, but subject to review by the Release Team and Technical Committee) then the package will not be released. Does anyone disagree with this assessment ? Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587886: future of maintaining of the bootloader LILO
Hi, - Ian Jackson ijack...@chiark.greenend.org.uk wrote: William, thanks for replying with your position and stating it very clearly. It's very helpful for us to know exactly what you think. William Pitcock writes (Re: Bug#587886: future of maintaining of the bootloader LILO): [Ian Jackson:] I've caught up on all of this now. I'm not sure I quite understand the position of the current lilo maintainers. In http://lists.debian.org/debian-devel/2010/05/msg00769.html William writes: it has pretty much been determined that kernel sizes have crossed the line past where lilo can reliably determine the payload size. William, to what are you referring ? Can you provide a bug number ? Please read all of the bug reports on lilo. At least half of them are related to this issue. Fortunately, payload sizes have dropped below the watermark. I've done as you asked and looked at the bug reports on lilo. I reviewed the title lines, and where necessary the bug log, of every bug report to decide whether the bug could possibly be due to an image size limitation as you suggest. Of the bugs only #357567 could possibly match the description you have given so far and that only at a huge stretch. If you still think that there is some really hard to fix image size limitation with lilo, could you please provide a more specific reference. For the most part, it is worked around by using large-memory, but this is a bandaid, and is BIOS-dependent. William and Matt: Can you confirm that you still intend to remove lilo from squeeze ? Matt really is not part of this decision-making process at this time, as he has never provided any insight into any critical decisions with this package. The question is now before the Technical Committee, and our decision-making process will include consulting with Matt and Joachim and anyone else relevant. So Matt _is_ part of the decision-making process at this time. This is a complete abuse of the tech-ctte process initiated by Joachim who wishes to force his LILO 23.0 tree down my throat. On a side note: the bug reporter needs to find something better to do with their time. lilo has no future. Making a 23.0 release with nothing other than *broken* patches does not give it one. Release with nothing other than broken patches is a very strong statement. Can you justify that ? For example, you could list the patches in Joachim's 23.0 release and explain why each of them is broken ? The following commit shows blind importation of patches without cleanup to ensure proper maintainability: https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=lilo/lilo.git;a=commitdiff;h=f50e3fc18b100fe886270ffdf9c7e0e6d18e2cde There are many more commits like this. Contrary to popular opinion, I have been paying attention to Joachim's work. I should emphasize that in my mail, I told Joachim that he has to produce a lilo release with actual merit. 23.0 does not have actual merit. Joachim, do you have a convenient list of the patches you have folded into 23.0 ? What level of technical review were you able to give to them ? What is your opinion of the general quality of those patches ? Let the damned thing die already. I think it's clear from William's response that joint maintainership involving both William on one hand, and one or both of Matt and Joachim on the other hand, is not tenable. I have no qualms with Joachim being involved in maintenance provided that his work involves something more than applying random patches from distributions. Until such effort is demonstrated, any lilo uploads made by myself will not be based on the 23.x release series. 1:22.8-9 will be uploaded at some point in the next few weeks to fix some issues involving the new kernel bootloader policy. I think this leaves the Technical Committee with two options: A. lilo should be removed. In the meantime, William is to be sole maintainer of lilo. His promised request to the ftp team to remove lilo should be honoured, after which the ftp masters should not permit Matt and/or Joachim to reupload a new lilo package. lilo will have to be removed someday unless it is completely rewritten. Joachim's work has not shown that he is capable of taking on the task of rewriting lilo. A new upstream maintainer of lilo should be able to show that he has enough knowledge to get the job done. This has not been done either. Whether that time is during Squeeze's release cycle or not is irrelevant in the regard that it will eventually have to be removed. An orderly removal process with coordination from the release team is the proper way of ensuring that lilo is removed cleanly from the distribution. That said, I have not at this time committed to removing lilo from Debian. Although there has been discussion, there has not been any action on this at the time
Bug#587886: future of maintaining of the bootloader LILO
William Pitcock writes (Re: Bug#587886: future of maintaining of the bootloader LILO): Hi, If you still think that there is some really hard to fix image size limitation with lilo, could you please provide a more specific reference. For the most part, it is worked around by using large-memory, but this is a bandaid, and is BIOS-dependent. I see. Well, really, I don't see. Could you please tell me where I could read more about this problem ? The question is now before the Technical Committee, and our decision-making process will include consulting with Matt and Joachim and anyone else relevant. So Matt _is_ part of the decision-making process at this time. This is a complete abuse of the tech-ctte process initiated by Joachim who wishes to force his LILO 23.0 tree down my throat. The purpose of the Technical Committee is precisely to deal with these kind of disputes. To invoke the TC is not an abuse. Your emails on this subject in general seem to me to come across as very hostile, and you have been quite insulting towards Matt and Joachim. Now perhaps you are right and they don't have the skills and aptitude for this task, but if that's the argument you are relying on then (a) you should be able to put it forward more politely and (b) you'll have to provide some clear evidence for us. The following commit shows blind importation of patches without cleanup to ensure proper maintainability: https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=lilo/lilo.git;a=commitdiff;h=f50e3fc18b100fe886270ffdf9c7e0e6d18e2cde I'm afraid without more context I can't see whether this is a good or bad change. We're not generally bootloader experts here. There are many more commits like this. Contrary to popular opinion, I have been paying attention to Joachim's work. I should emphasize that in my mail, I told Joachim that he has to produce a lilo release with actual merit. 23.0 does not have actual merit. It's quite possible that there are things wrong with Joachim's work. But your explanations so far aren't very convincing at least to me. I have no qualms with Joachim being involved in maintenance provided that his work involves something more than applying random patches from distributions. Your emails to him and to Matt seem very hostile, though. lilo will have to be removed someday unless it is completely rewritten. Can you please explain why that's the case ? - does not work reliably across all BIOSen when in large-memory mode; - does not work reliably across all BIOSen when NOT in large-memory mode. Are these problems reflected in bug reports in the BTS ? Because if so I didn't seem to find them. lilo 23.0 as compared to 22.8: - removes a lot of cruft that is no longer applicable (this IS a good start towards improving maintainability); Earlier you said this: Making a 23.0 release with nothing other than *broken* patches does not give [lilo a future] Ie, you implied that that was what Joachim has done. However, now you agree that he has done some good things. Exaggerating the alleged misdeeds of the people you are having a disagreement with does not do you any favours. - adds patches from Fedora and OpenSuSE (without explaining rationale for adding the patches, most of the patches 'work around' bugs rather than correcting the actual design faults); Would you care to give an example ? I appreciate it might be too much work for us all to go through every such patch and have you explain in detail what the real problem is and why the applied patch is not correct. But I think you should be able to point to an example or two. - fixes bugs that are already fixed in Debian 22.8 sources. Surely that is exactly one of the things an upstream maintainer should be doing ? - changes elements of the buildsystem that do not need to be changed; That seems like a bikeshed issue to me. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587886: future of maintaining of the bootloader LILO
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/10/2010 07:40 PM, Ian Jackson wrote: Earlier you said this: Making a 23.0 release with nothing other than *broken* patches does not give [lilo a future] Ie, you implied that that was what Joachim has done. However, now you agree that he has done some good things. Exaggerating the alleged misdeeds of the people you are having a disagreement with does not do you any favours. - adds patches from Fedora and OpenSuSE (without explaining rationale for adding the patches, most of the patches 'work around' bugs rather than correcting the actual design faults); Would you care to give an example ? I appreciate it might be too much work for us all to go through every such patch and have you explain in detail what the real problem is and why the applied patch is not correct. But I think you should be able to point to an example or two. - fixes bugs that are already fixed in Debian 22.8 sources. Surely that is exactly one of the things an upstream maintainer should be doing ? - changes elements of the buildsystem that do not need to be changed; That seems like a bikeshed issue to me. Hello: Just in case i get another eye infection, and am unable to respond. Here is a concise summary of my views on the issue. If that happens and the TC needs more insight as to why I haven't been involved. Ian may forward them the aforementioned private e-mail William is right on that patch. That is a horrid way to comment an assembly language statement (no offense intended). But what does it show about Joachim'squalifications. I know I am probably not as well versed as i should bein lilo's internals but I know more than the average bear about x86 real mode assembly, as I spent better part of six months almost exclusively coding in it. although I have not done anything as complex as a bootloader before I stand a reasonable chance of doing this right. William is without question more qualified, though I think this exchange shows why I'm backing Joachim. It is not as William supposes my desire for brownie points, though in the interest of honesty being a DD has been a goal of mine ever since i first read the SC at 14, and therefore anything which advances that goal is a good thing to do. However in this instance that is not the motivating reason. My motivation is the fact that I know that for a fairly substantial number of users lilo works, and other loaders don't. Why interfere with that if we don't have too. I'd oppose the removal of loadlin for the same reasons, there are users who need it because other bootloaders don't work for their bios, with their keyboard, or whatever (although in the particular case of loadlin I'm given to understand that it is the only bootloader with screen reader support, but this is not the point). My point is for whatever reason about 2,500 people have chosen lilo as bootloader over extlinux, grub, etc. A bootloader is a critical part of the overall system, and just arbitrarily, yanking one because some Debian Contributer, no matter how smart/qualified he may be doesn't like it i s dangerous. In my way of thinking that is even more dangerous then having someone green at the wheel (if you'll pardon the expression). That is the reason why I oppose what William intends to do, and have always opposed it. If/When lilo falls out of use I will reconsider my stance on this but for now that is the bottom line. /Matt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkw5GXUACgkQfGeS0kace82X7wCeL928SoJvSMbVFpc783ah7jmJ oaUAn1pS00+prjzQzBmUpI6LY7VL7UAE =cRas -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587886: future of maintaining of the bootloader LILO
Do whatever you want. I'm not wasting anymore time on this. Any future emails sent to me regarding this will be ignored. LILO 22.8-9 will be uploaded when time permits. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587886: future of maintaining of the bootloader LILO
Ian Jackson writes (Bug#587886: future of maintaining of the bootloader LILO): I've caught up on all of this now. I'm not sure I quite understand the position of the current lilo maintainers. In http://lists.debian.org/debian-devel/2010/05/msg00769.html William writes: it has pretty much been determined that kernel sizes have crossed the line past where lilo can reliably determine the payload size. William, to what are you referring ? Can you provide a bug number ? William and Matt: Can you confirm that you still intend to remove lilo from squeeze ? I've had private email exchanges with Matt (the other existing lilo maintainer) and Joachim. Matt and Joachim tell me that are keen to keep lilo in Debian and to maintain it. However due to disagreements with his co-maintainer Matt has been having difficulty getting sponsorship for uploads. William, are you be happy for Joachim to join the maintainer list for lilo ? What is your current view about the future of lilo ? In particular, is it appropriate for sponsors to sponsor uploads of new versions from Matt and Joachim ? Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587886: future of maintaining of the bootloader LILO
Joachim Wiedorn ad_deb...@joonet.de wrote on 2010-07-05 17:46: If nobody want to do maintaining the lilo package I could do it and I would do it. My proposal: From my side I believe I could work together with Matt Arnold. I see the following cases: A) Matt Arnold as Maintainer, myself as Co-Maintainer B) Matt Arnold as Co-Maintainer, myself as Maintainer C) Matt Arnold as adviser (with less time), myself as Maintainer Have a nice day, Joachim (Germany) signature.asc Description: PGP signature
Bug#587886: future of maintaining of the bootloader LILO
On 07/06/2010 05:48 PM, Joachim Wiedorn wrote: Joachim Wiedorn ad_deb...@joonet.de wrote on 2010-07-05 17:46: If nobody want to do maintaining the lilo package I could do it and I would do it. My proposal: From my side I believe I could work together with Matt Arnold. I see the following cases: A) Matt Arnold as Maintainer, myself as Co-Maintainer B) Matt Arnold as Co-Maintainer, myself as Maintainer C) Matt Arnold as adviser (with less time), myself as Maintainer Have a nice day, Joachim (Germany) Personally i think B would be best Matt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587886: future of maintaining of the bootloader LILO
Joachim Wiedorn writes (Bug#587886: future of maintaining of the bootloader LILO): because of the discussions of the last weeks mostly on debian-devel I have sent this bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=587886 to the Technical Committee of Debian to find a solution. I've caught up on all of this now. I'm not sure I quite understand the position of the current lilo maintainers. In http://lists.debian.org/debian-devel/2010/05/msg00769.html William writes: it has pretty much been determined that kernel sizes have crossed the line past where lilo can reliably determine the payload size. William, to what are you referring ? Can you provide a bug number ? William and Matt: Can you confirm that you still intend to remove lilo from squeeze ? Do we have another person who wants to maintain lilo in Debian ? I think that if we do, and the current maintainers want to remove it, we should give the package to the maintainers who do not want to remove it. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587886: future of maintaining of the bootloader LILO
Ian Jackson ijack...@chiark.greenend.org.uk wrote on 2010-07-05 15:23: Do we have another person who wants to maintain lilo in Debian ? If nobody want to do maintaining the lilo package I could do it and I would do it. I think that if we do, and the current maintainers want to remove it, we should give the package to the maintainers who do not want to remove it. Have a nice day, Joachim (Germany) signature.asc Description: PGP signature
Bug#587886: future of maintaining of the bootloader LILO
Ian Jackson ijack...@chiark.greenend.org.uk wrote on 2010-07-05 15:23: I've caught up on all of this now. I'm not sure I quite understand the position of the current lilo maintainers. In http://lists.debian.org/debian-devel/2010/05/msg00769.html William writes: it has pretty much been determined that kernel sizes have crossed the line past where lilo can reliably determine the payload size. Because I had not understand this statement in the pointed email I made some tests and searched through the source code. Yesterday I have made my last test on an amd64 architecture with the recent kernel and a special made initrd (with over 1000 large kernel modules): kernel size = 2,4 MByte initrd size = 25,0 MByte and the lilo option 'large-memory'. Result of this test with lilo: This kernel+initrd is installable and bootable without problems! My results of these work: Lilo don't have any problems with the kernel + initrd size. If the 'large-memory' option is set this will be done without warnings and if this option is not set it will be done correctly but with warnings! Have a nice day, Joachim (Germany) signature.asc Description: PGP signature
Bug#587886: future of maintaining of the bootloader LILO
Package: tech-ctte Severity: normal Hello, Since six weeks I see a very problematic situation of LILO maintaining and I don't know how this problem could be solved. Since the initial mail from William Pitcock, the LILO maintainer (2010-05-22): http://lists.debian.org/debian-devel/2010/05/msg00769.html it started a discussion about the removing of LILO. Because of many statements of William it seems he don't want to do anymore for the lilo package in Debian. One central reason is: there is no upstream for years. On the other side there are many users (popcon = 2596) who still want to use lilo. And the second side is: grub2 is still very beta. Some mails to debian-devel say: grub2 is far away from stable and for using in productive systems! Because of this situation I have decided to overtake the development of LILO and offer an upstream for Debian (2010-06-06 and 2010-06-19): http://lists.debian.org/debian-devel/2010/06/msg00117.html http://lists.debian.org/debian-devel/2010/06/msg00399.html The reaction of William about my announcement was not in the way who I have thought. It seems he still wants to remove lilo from Debian. With the mail from William (2010-06-07) and the following thread: http://lists.debian.org/debian-devel/2010/06/msg00137.html it seems William doesn't believe to lilo anymore. In this thread he was asked to orphan the lilo package. But no answer came from the maintainer. In the following time I have asked William Pitcock (and the second maintainer Matt Arnold) to orphan the package because it is apparent they don't want to maintain the package anymore. I have asked twice: public on debian-devel and also private. But it seems they don't be interested in surrendering the maintaining of the package. On the other side how I can analyse about the QA site of lilo and the bug reports the recent maintainer seems to be nearly inactive since many months. In some other mails it seems the favorit for William (and also Matt Arnold) is now extlinux. O.K. this is a private preference, but I think on Debian it is normal to have more solutions for the same thing (here: bootloader). So I see no reason to remove the lilo package. In the last two weeks there were other discussions on debian-devel about bootloader to prepare for squeeze to make it working with new kernels and the new way of updateing kernel + initrd: Many informations about newer requirements to bootloader: http://lists.debian.org/debian-kernel/2010/06/msg01011.html New informations about updated package initramfs-tools: http://lists.debian.org/debian-kernel/2010/06/msg01063.html This evolution must be go into lilo, too. But this need a very active maintaining of this package, which I don't see. Now I see the danger, that lilo still slip into the next stable (squeeze) but can not be used productive in the next stable because of lack of the right scripts. Because lilo is a very good software and is still need by many users, I think the lilo package in Debian merit an active maintaining. It should not be blocked of maintaining. Please appeal to the recent maintainer to orphan the lilo package. Then other people who still use and want lilo can overtake the maintaining. Or is there another solution? Have a nice day, Joachim (Germany) signature.asc Description: PGP signature
Bug#587886: future of maintaining of the bootloader LILO
Hello, because of the discussions of the last weeks mostly on debian-devel I have sent this bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=587886 to the Technical Committee of Debian to find a solution. I invite you to write a summary of your position and send it to this bug report, too. Have a nice day, Joachim (Germany) signature.asc Description: PGP signature
