Re: Init system for non-Linux ports
On 29/01/2014 09:26, Petr Salinger wrote: >> 1. stay with sysvinit >> 2. switch to OpenRC unconditionally >> 3. switch to Upstart unconditionally >> 4. switch to Upstart only if Linux uses it by default, otherwise OpenRC >> 5. further discussion >> >> Please rank the above putting your preferred option first, as per >> Debian's usual Condorcet voting system. This is totally non-binding, >> I'm most interested in hearing people's ideas, questions, or the reasons >> for their choices. > > I would add also > 6. switch to Upstart only if Linux uses it by default, otherwise stay with > sysvinit > > My preference is > > 6-5-1,2,4-3 We have less options now ;-) I'm a bit afraid that even if sysvinit itself stays mostly fine, the scripts written for it could turn into a bunch of bitrot. And AFAICS we may be able to use Upstart some time in the future but this doesn't seem possible right now. What is the current status of OpenRC? Is it usable? -- Robert Millan -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52fb50d4.1010...@debian.org
Re: [Fwd: Re: Init system for non-Linux ports]
On 12/02/14 12:04, Svante Signell wrote: > I fear that it is currently broken since one of the latest patches. Do > you have a (scrappable) pre-installed image I can download, ala: > http://people.debian.org/~sthibault/hurd-i386/ Yes, Aurelien Jarno has kindly made these: > http://blog.aurel32.net/153 > http://people.debian.org/~aurel32/qemu/ Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52fb63f3.1030...@pyro.eu.org
Re: Init system for non-Linux ports
On 12/02/14 10:45, Robert Millan wrote: > I'm a bit afraid that even if sysvinit itself stays mostly fine, the scripts > written for > it could turn into a bunch of bitrot. There are a few reasons to keep sysvinit scripts maintained for jessie: 1. for smoother upgrades from wheezy 2. in order to backport jessie packages to wheezy 3. for non-Linux (or non-systemd) ports So ports are not the only reason. And yet all of the above points still apply to ports; we'd have to support sysvinit even if we went with something else. I don't think it matters much what we choose, but seems we'd want to make use of legacy sysvinit compatibility - write very few scripts in specific formats (e.g. OpenRC runscripts / Upstart jobs). We probably have right up until freeze to make a preference, and perhaps by then there will be more than one fully-working init system. GNU/Hurd porters already said they aim to maintain sysvinit scripts: https://lists.debian.org/debian-hurd/2014/01/msg00051.html And there are plenty of GNU/Linux users who will want to run systems without systemd. (individuals, derivatives, quite possibly Google). Thinking ahead, package maintainers won't have such need to support sysvinit for jessie+1 so that's when we'll really have problems. Having something like OpenRC or Upstart might allow to add/override broken init scripts with native/declarative ones. Perhaps by then we'll have new ways to convert init scripts or generate them from metalanguage; or built-in support for reading each others' formats. > And AFAICS we may be able to use Upstart some time in the future but this > doesn't seem > possible right now. We could initially ask the maintainer to apply Dmitri's patches and try to keep it building on kfreebsd. And just keep it around for people to play around with and possibly get it fully working. IIRC it runs, but will need early boot scripts re-writing, equivalent to /etc/rcS.d/ > What is the current status of OpenRC? Is it usable? Pretty good as I recall; it was very easy to test using jails. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52fb647f.3090...@pyro.eu.org
[Fwd: Re: Init system for non-Linux ports]
Forwarded Message From: Svante Signell To: debian-h...@lists.debian.org Subject: Re: Init system for non-Linux ports Date: Wed, 12 Feb 2014 13:02:45 +0100 On Wed, 2014-02-12 at 10:45 +, Robert Millan wrote: > On 29/01/2014 09:26, Petr Salinger wrote: > What is the current status of OpenRC? Is it usable? I fear that it is currently broken since one of the latest patches. Do you have a (scrappable) pre-installed image I can download, ala: http://people.debian.org/~sthibault/hurd-i386/ -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1392206649.10315.16.ca...@s1499.it.kth.se
Re: Init system for non-Linux ports
On 12/02/2014 12:09, Steven Chamberlain wrote: > There are a few reasons to keep sysvinit scripts maintained for jessie: > 1. for smoother upgrades from wheezy > 2. in order to backport jessie packages to wheezy > 3. for non-Linux (or non-systemd) ports > > So ports are not the only reason. And yet all of the above points still > apply to ports; we'd have to support sysvinit even if we went with > something else. If we have to support it anyway, is it really worth spending effort on Upstart/OpenRC for Jessie? IMHO it'd be safer to wait and see where things go. For example, are Upstart developers serious about portability or was this just an experiment? Is OpenRC going to be adopted by FreeBSD and/or other BSDs? -- Robert Millan -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52fb67d2.4000...@debian.org
Re: Init system for non-Linux ports
On 12/02/14 12:23, Robert Millan wrote: > If we have to support it anyway, is it really worth spending effort on > Upstart/OpenRC for Jessie? Right, sysvinit is a viable and easy option for jessie; having any other init systems working is a bonus. At least we know now that we need to concentrate on maintaining sysvinit scripts. Although, come jessie+1, I wonder how upgrades will be handled, if sysvinit scripts go away. Maybe it is preferable to have some new init system *already* in place, as default in jessie. But it's difficult to predict so far ahead. > IMHO it'd be safer to wait and see where things go. I agree, a lot could change now that GNU/Linux has chosen systemd, and we have plenty of time. In particular I wonder what Ubuntu will do, and if Upstart has a future at all. The still-ongoing GNOME/logind issue may have some impact on that. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52fb6bb7.5020...@pyro.eu.org
Re: Init system for non-Linux ports
On 12/02/2014 12:40, Steven Chamberlain wrote: > Although, come jessie+1, I wonder how upgrades will be handled, if > sysvinit scripts go away. Maybe Pre-Depends. Or maybe have written instructions to install the new init by hand, like we often do for kernels. Or maybe backward compat? I hear some of the new init implementations support SysV. I think having one or more replacements in good shape would be nice, but I doubt we'll be in trouble because of this. -- Robert Millan -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52fb74a1.8070...@debian.org
Re: Init system for non-Linux ports
On 12/02/14 13:18, Robert Millan wrote: > Or maybe backward compat? I hear some of the new init implementations > support SysV. SysV init scripts? I thought this was obvious, or maybe I misunderstand what you mean. *All* of the init systems that were discussed by the TC, even systemd (for now), can use existing SysV init scripts. This is important to know, because some (perhaps most) packages may not bother creating systemd unit files at all for jessie, and continue to fully maintain the SysV init scripts they already have. And adopting any new init system for jessie is made considerably easier by using the same init scripts as sysvinit. SysV init scripts can be overridden by creating a new runscript/job of the same name. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52fb7974.60...@pyro.eu.org
Bug#738486: freebsd-nfs-common: NFSv4 non-functional due to missing nfsuserd and nfscbd
Control: tag -1 help Hi Roger, Unfortunately we're very short on manpower to add new features. Do you think you'd be able to help with this one? On 09/02/2014 22:11, Roger Leigh wrote: > Package: freebsd-nfs-common > Version: 9.2+ds1-1+b1 > Severity: important > > Dear Maintainer, > > It does not appear possible to mount an NFSv4 filesystem > with the current kfreebsd nfs packages. nfsuserd is > missing (needed both client and server side), and > nfscbd is missing (needed client side for some > configurations; not sure about the server). > > I can get NFSv4 mounts working fine booting the system > into a native FreeBSD 10.0-RELEASE install. So it is > configured correctly server-side. It's just the > kFreeBSD packages missing bits which are standard in > the base FreeBSD install. If they could be added, > that would probably fix the problem. > > Note that there may be additional other NFS daemons > which I've missed. > > > Thanks, > Roger > > > -- System Information: > Debian Release: jessie/sid > APT prefers unstable > APT policy: (500, 'unstable') > Architecture: kfreebsd-amd64 (x86_64) > > Kernel: kFreeBSD 10.0-1-amd64 > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > > Versions of packages freebsd-nfs-common depends on: > ii libbsd00.6.0-1 > ii libc0.12.17-97 > ii libfreebsd-glue-0 0.2.17 > ii libtirpc1 0.2.2-5 > ii rpcbind0.2.1-2 > > freebsd-nfs-common recommends no packages. > > freebsd-nfs-common suggests no packages. > > -- no debconf information > > -- Robert Millan -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52fb7e11.2010...@debian.org
Processed: Re: Bug#738486: freebsd-nfs-common: NFSv4 non-functional due to missing nfsuserd and nfscbd
Processing control commands: > tag -1 help Bug #738486 [freebsd-nfs-common] freebsd-nfs-common: NFSv4 non-functional due to missing nfsuserd and nfscbd Added tag(s) help. -- 738486: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738486 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.b738486.13922135251327.transcr...@bugs.debian.org
Bug#738188: VESA Newcons is awfully slow
On 09/02/2014 12:56, Markus Koschany wrote: > Switching between virtual terminals and X works flawlessly after I > loaded the intel drivers manually. What about switching from one VT to another? (no X involved) -- Robert Millan -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52fb7e57.1090...@debian.org
Re: Init system for non-Linux ports
On 12 February 2014 12:23, Robert Millan wrote: > On 12/02/2014 12:09, Steven Chamberlain wrote: >> There are a few reasons to keep sysvinit scripts maintained for jessie: >> 1. for smoother upgrades from wheezy >> 2. in order to backport jessie packages to wheezy >> 3. for non-Linux (or non-systemd) ports >> >> So ports are not the only reason. And yet all of the above points still >> apply to ports; we'd have to support sysvinit even if we went with >> something else. > > If we have to support it anyway, is it really worth spending effort on > Upstart/OpenRC for Jessie? > > IMHO it'd be safer to wait and see where things go. For example, are Upstart > developers serious about portability or was this just an experiment? Is > OpenRC going to be adopted by FreeBSD and/or other BSDs? > Yes, a few upstart upstream developers are interested in porting to kFreebsd, and later to Freebsd. If packages follow the current policy, there shouldn't be much additional work once upstart is supported on those platforms. Integration-wise, there will be needed to inspect and/or tweak a few jobs where things don't match up (e.g. udev <-> devd events). We didn't start on Hurd yet. In the best interest of Debian/kFreeBSD, it is probably best to stick with sysv-init as default for jessie, and have alternatives fully available by feature freeze such that a switch can be made for jessie+1. This is simply because no init alternatives exist on !Debian/Linux in squeeze already, and e.g. on Debian/Linux upstart/systemd already exist as working alternatives on squeeze systems. Out of all the open-source operating systems, i'm yet to see one that introduce new init and switch to it by default in a single upgrade. -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhlughvwru+8cvawtrgzjj5_p_qboke_rreqtnp1m6onu...@mail.gmail.com
Processed: Re: Bug#738188: VESA Newcons is awfully slow
Processing control commands: > retitle -1 VGA Newcons is awfully slow Bug #738188 [kfreebsd-image-11.0-0-amd64] VESA Newcons is awfully slow Changed Bug title to 'VGA Newcons is awfully slow' from 'VESA Newcons is awfully slow' -- 738188: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738188 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.b738188.13922139415087.transcr...@bugs.debian.org
Bug#738188: VESA Newcons is awfully slow
Control: retitle -1 VGA Newcons is awfully slow Hi Ed, On 09/02/2014 19:47, Ed Maste wrote: > On what hardware (or VM) do you experience this? On my Thinkpad X220 > the console is acceptably performant in both VGA-mode (at boot) and > i915 (after starting X), with a FreeBSD-CURRENT kernel from the end of > January. In VirtualBox it is noticeably pokey for me, but certainly > not on the order of one second for a scroll. On VirtualBox, I get the "lag effect" on both scrolling and VT switching. On real hardware (with VGA mode), VT switching is very slow, but scrolling is fine. There's a small glitch during VT switch: immediately after pressing the keys, screen is redrawn, but where you'd normally see the login prompt, blurry characers are drawn. After a fraction of a second, these are replaced with proper glyphs. Smells like a font related problem. Would you like to see a video capture? -- Robert Millan -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52fb7faf.7030...@debian.org
Bug#738188: VESA Newcons is awfully slow
On 12 February 2014 09:05, Robert Millan wrote: > There's a small glitch during VT switch: immediately after pressing the > keys, screen is redrawn, but where you'd normally see the login prompt, > blurry characers are drawn. After a fraction of a second, these are replaced > with proper glyphs. Smells like a font related problem. Would you like to > see a video capture? That sounds quite odd. Sure, if you can easily obtain a video capture please do. -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capyfy2bp6ysb_jxnmmt2tzp7oj-78u8_h6s4eyzy12se6ri...@mail.gmail.com
Re: Bits from the Release Team: Architecture health check
On 2014-01-30 16:23, Robert Millan wrote: > On 30/01/2014 00:03, Niels Thykier wrote: >> @Robert: Re your "Could you elaborate?". I haven't forgotten it, but I >> out of time - so I will get back to you on that. > > It's ok. > > I wanted more detail both on the problem and on the solution. You just > provided > the second, which I believe is the most important. > Okay - as promised, the problem side. As I see it, there are two concrete problems with the (number of) supported packages. First, the number of packages actually built on kFreeBSD is just shy of 90%, whereas most other release architectures are at 96%[1]. Here kFreeBSD has increased in the past quarter from ~89.5% to "almost, but not quite 90%". Secondly, there are cases like GDM, where a single unsupported package have rather "long reaching" consequences. In the concrete example, GNOME (via gnome-core) strictly depends on gdm3, meaning that if gdm3 goes, (more or less) all of gnome goes with it[2]. That in turn means that task-gnome-desktop cannot be installed on kFreeBSD (I presume this will at least affect d-i). Here we need you to assess what can you reasonably support. Once we know that we can look at the consequences and how to deal with them. By the way, when you present your set of supported packages, please consider highlighting where you would like the "default" package set to be different from current release architectures. E.g. with the TC's decision on init systems, Linux will be using systemd as default init system[3]. I presume kFreeBSD will go with a different init system. ~Niels [1] https://buildd.debian.org/stats/graph-week-big.png The notable exception here being s390x, which is at ~93%. [2] I vaguely remember something XDM being a possible alternative to GDM, but never mind that for now. [3] Here I bluntly assume there will not be a GR overturning that decision. -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52fbd439.1070...@thykier.net
Re: Heads up: xorg-server 1.15 soon in sid
On Tue, Feb 4, 2014 at 10:04:47 +, Robert Millan wrote: > On 28/01/2014 22:39, Julien Cristau wrote: > > I haven't been able > > to test nv, msm, omap, omapfb or sunffb. > > nv builds fine. Thanks for the heads-up. > It doesn't seem to be whitelisted in wanna-build, so I'm unable to binNMU it. Would you mind building and uploading binNMUs yourself? Thanks, Julien signature.asc Description: Digital signature
