Michal, On Wed, Nov 19, 2014 at 09:34:22AM +0100, Michal Suchanek wrote: > On 19 November 2014 08:02, Didier 'OdyX' Raboud <o...@debian.org> wrote: > > Le mercredi, 19 novembre 2014, 00.00:48 Michal Suchanek a écrit : > >> On 18 November 2014 18:57, Jordi Mallach <jo...@debian.org> wrote: > >> > El dl 17 de 11 de 2014 a les 15:41 +0100, en/na Michal Suchanek va > >> > escriure: > >> >> -- System Information: > >> >> Distributor ID: Ubuntu > >> >> Description: Ubuntu GNU/Linux testing (jessie)
> >> It's a cosmetic issue ;-). > >> I had Ubuntu base system on this particular PC some years ago and I > >> noticed this issue and spent a few minutes trying to figure out where > >> that value is stored. I did not figure it out and since the upgrade to > >> Debian base system is not supposed to handle this situation it is > >> technically not a bug in Debian. It's only a cosmetic issue so I left > >> it at that. > > Systems cross-craded from Ubuntu to Debian are absolutely not supported, > > and I wouldn't be surprised if some of the issues you're seeing are in > > some way related to this. > Sure, it's always user error when something fails. Systems upgraded > from Ubuntu are not supported, systems upgraded from Debian are not > supported, nor are systems freshly bootstrapped and booted inside > qemu. Because all these fail. Maybe the only clean enough approach is > to get rid of Debian and all its derivatives. Then you will be sure to > get rid of all Debian bugs. > However, I had this biased personal opinion that the goal of the > Debian project should to remove Debian bugs on systems that do run > Debian. Please corect me if this is too disconnected from reality. You aren't getting constructive responses here because you did not submit an actionable bug report. If you are experiencing a bug in upstart or in systemd (or both), the way to get that resolved is by filing a bug report against upstart or systemd (or both). If you think a particular bug is sufficiently grave and intractable to warrant Debian revisiting its choice of init system, there are ways to trigger such a review. But filing a 'general' bug report declaring that 'non-sysvinit init systems are made of fail' is not the way to accomplish anything. As regards the two issues you've described: the first is not a bug. It's a necessary change in how we view the boot in a truly event-driven system. There is no sane default policy for how to interpret entries in /etc/fstab on upgrade except to regard them as all mandatory - *but* it's important that the admin be given the opportunity to intervene to override this policy. The second is certainly a bug. I'm sure if you had filed it as a bug report against either of upstart or systemd, the response from the maintainers would have acknowledged that it is a bug. But you haven't done this; nor have you provided concrete details about the circumstances of your failure. So while you have encountered a bug, I'm sure it's a better use of the systemd maintainers' time to wait for a real bug report from someone who is actually interested in working with them to get this bug fixed. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
