Re: Init system for non-Linux ports

[Petr Salinger]

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

Petr


--
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/alpine.lnx.2.00.1401291025160.15...@contest.felk.cvut.cz

Re: Init system for non-Linux ports

[Christoph Egger]

Hi!

Robert Millan  writes:
> [ 3 ] 1. stay with sysvinit
> [ 3 ] 2. switch to OpenRC unconditionally
> [ 3 ] 3. switch to Upstart unconditionally
> [ 1 ] 4. switch to Upstart only if Linux uses it by default, otherwise OpenRC
> [ 2 ] 5. further discussion

Petr Salinger  writes:
> 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

I agree we should follow Linux *iff* doing so is feasible. Apart from
that I haven't put enough time into details to really have a founded
opinion there

=> (6=4) 5 (1=2=3)

Robert Millan  writes:
> Btw is the tech-ctte going to force both ports to use the same option? This 
> might
> have a significant effect on options 3 and 4, depending on the viability of 
> Upstart
> on the Hurd (which I'm totally ignorant of).

I'm the tech-ctte will even consider deciding anything for !linux
without a really good reason. As long as we (the kfreebsd people) and
the hurd people each find something that works for us we should be
fine. The only thing from the tech-ctte / GR discussions that might
affect us is, if the project decides to drop support for some init
system.

  Christoph


-- 
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/87mwiff3ea@mitoraj.siccegge.de

Re: Bug#621379: havp: FTBFS on kfreebsd-*: checking for mandatory locking support... OS not supported

[Steven Chamberlain]

Version: 0.92a-2

Package havp already built on kfreebsd-*, nearly 3 years ago :/
therefore closing this bug now.

Thanks,
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/52e90c76.8060...@pyro.eu.org

Bug#650684: marked as done (freebsd-quota: FTBFS: Makefile:12: *** missing separator. Stop.)

[Debian Bug Tracking System]

Your message dated Wed, 29 Jan 2014 14:22:12 +
with message-id <52e90e94.9070...@pyro.eu.org>
and subject line Re: Bug#650684: freebsd-quota: FTBFS: Makefile:12: *** missing 
separator. Stop.
has caused the Debian Bug report #650684,
regarding freebsd-quota: FTBFS: Makefile:12: *** missing separator.  Stop.
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
650684: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=650684
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: src:freebsd-quota
Version: 8.2-1
Severity: Important
Tags: sid wheezy
User: debian-bsd@lists.debian.org
Usertags: kfreebsd

Hi!

Your package failed to build on the kfreebsd-* buildds:

dpkg-buildpackage: host architecture kfreebsd-i386
 fakeroot debian/rules clean
dh clean
   dh_testdir
   debian/rules override_dh_auto_clean
make[1]: Entering directory 
`/build/buildd-freebsd-quota_8.2-1-kfreebsd-i386-u04Br7/freebsd-quota-8.2'
COPTS="-Wall -g -pipe -fPIC -I. -D_GNU_SOURCE -D'__FBSDID(string)=' 
-D'__RCSID(string)='" CFLAGS="-Wall -g -pipe -fPIC -I. -D_GNU_SOURCE 
-D'__FBSDID(string)=' -D'__RCSID(string)='" NO_WERROR=1 NOGCCERROR=1 
NOSHARED=NO NO_SHARED=NO 
DESTDIR=/build/buildd-freebsd-quota_8.2-1-kfreebsd-i386-u04Br7/freebsd-quota-8.2/debian/tmp
 make -C libexec/rpc.rquotad clean
Makefile:12: *** missing separator.  Stop.
make[2]: Entering directory 
`/build/buildd-freebsd-quota_8.2-1-kfreebsd-i386-u04Br7/freebsd-quota-8.2/libexec/rpc.rquotad'
make[2]: Leaving directory 
`/build/buildd-freebsd-quota_8.2-1-kfreebsd-i386-u04Br7/freebsd-quota-8.2/libexec/rpc.rquotad'
make[1]: *** [override_dh_auto_clean] Error 2
make[1]: Leaving directory 
`/build/buildd-freebsd-quota_8.2-1-kfreebsd-i386-u04Br7/freebsd-quota-8.2'
make: *** [clean] Error 2

Full build log at
https://buildd.debian.org/status/fetch.php?pkg=freebsd-quota&arch=kfreebsd-i386&ver=8.2-1&stamp=1321191992

Regards

Christoph

-- 
9FED 5C6C E206 B70A 5857  70CA 9655 22B9 D49A E731
Debian Developer | Lisp Hacker | CaCert Assurer


--- End Message ---
--- Begin Message ---
Version: 8.2-2--- End Message ---

Re: Init system for non-Linux ports

[Jeff Epler]

I'm only a kFreeBSD user and don't have any official standing within the
Debian project, but all the same my preferences are

614253

where 6. is the proposed alternative to switch to Upstart if Linux uses
it, otherwise sysvinit.

Jeff


-- 
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/20140129160233.gb12...@unpythonic.net

Re: Bits from the Release Team: Architecture health check

[Robert Millan]

Hi Niels,

On 29/01/2014 19:41, Niels Thykier wrote:
>  * kfreebsd-amd64 and kfreebsd-i386
>- On one hand, we are unconvinced that kFreeBSD will be able
>  to be on par with other release architectures in terms of
>  supported packages for Jessie.
>- On the other hand, we believe kFreeBSD could be improved by
>  reducing the scope of the port for Jessie.

Could you elaborate? I.e. what is the problem and what solution you
have in mind.

>- Therefore, we would like to invite the kFreeBSD porters to a
>  dialogue to determine the scope of kFreeBSD for Jessie.

Sure. This is much needed IMHO. Please let us know what you think.

-- 
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/52e97c81.8020...@debian.org

Re: Bits from the Release Team: Architecture health check

[Steven Chamberlain]

On 29/01/14 22:11, Robert Millan wrote:
> On 29/01/2014 19:41, Niels Thykier wrote:
>>  * kfreebsd-amd64 and kfreebsd-i386
>>- On one hand, we are unconvinced that kFreeBSD will be able
>>  to be on par with other release architectures in terms of
>>  supported packages for Jessie.
>>- On the other hand, we believe kFreeBSD could be improved by
>>  reducing the scope of the port for Jessie.
> 
> Could you elaborate? I.e. what is the problem and what solution you
> have in mind.

What exactly does the 'scope of the port' mean?  Suites of packages,
tasksel tasks, desktop environments?  Particular use cases (server,
laptop, desktop)?  Or something else?

I'm grateful we've been given another 2 months to work on this.  The
init system debate might have come to a conclusion by then, and it could
have some bearing on this.  If some packages (potentially the whole
GNOME desktop environment) get a hard systemd dependency that would
somewhat reduce the scope of the port for us I think.

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/52e97fa1.1070...@pyro.eu.org

Re: Bits from the Release Team: Architecture health check

[Robert Millan]

On 29/01/2014 23:24, Steven Chamberlain wrote:
> If some packages (potentially the whole
> GNOME desktop environment) get a hard systemd dependency that would
> somewhat reduce the scope of the port for us I think.

>From what I can see in previous TC discussion, it seems that the plan
is for sysvinit support to remain mandatory (but deprecated) for one
more release cycle.

-- 
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/52e98365.6050...@debian.org

Re: Bits from the Release Team: Architecture health check

[Russ Allbery]

Robert Millan  writes:
> On 29/01/2014 23:24, Steven Chamberlain wrote:

>> If some packages (potentially the whole GNOME desktop environment) get
>> a hard systemd dependency that would somewhat reduce the scope of the
>> port for us I think.

> From what I can see in previous TC discussion, it seems that the plan
> is for sysvinit support to remain mandatory (but deprecated) for one
> more release cycle.

Per Josselin's latest discussion of this, there doesn't appear to be any
direct GNOME dependencies on systemd itself that would be blocking for
jessie.  The problem, rather, is with logind (and to a lesser extent the
other services, which I believe are more inherently portable), since the
ConsoleKit fallback is apparently in pretty bad shape.

Various folks, particularly Steve and Colin, feel like getting logind and
friends working with sysvinit won't be a huge problem.  If that's the
case, GNOME on kFreeBSD may not be any worse off than it is now (and
possibly quite a bit better, since it would remove the ConsoleKit path,
which is currently buggy), provided that such a systemd-independent logind
can run on kFreeBSD.  This piece of software/packaging does not actually
exist yet, though, and people's time/motivation to work on it may be
affected by the outcome of the larger decision.

-- 
Russ Allbery (r...@debian.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/87wqhi1jz3@windlord.stanford.edu

Re: Bits from the Release Team: Architecture health check

[Niels Thykier]

On 2014-01-29 23:24, Steven Chamberlain wrote:
> On 29/01/14 22:11, Robert Millan wrote:
>> On 29/01/2014 19:41, Niels Thykier wrote:
>>>  * kfreebsd-amd64 and kfreebsd-i386
>>>- On one hand, we are unconvinced that kFreeBSD will be able
>>>  to be on par with other release architectures in terms of
>>>  supported packages for Jessie.
>>>- On the other hand, we believe kFreeBSD could be improved by
>>>  reducing the scope of the port for Jessie.
>>
>> Could you elaborate? I.e. what is the problem and what solution you
>> have in mind.
> 
> What exactly does the 'scope of the port' mean?  Suites of packages,
> tasksel tasks, desktop environments?  Particular use cases (server,
> laptop, desktop)?  Or something else?
> 

Hi,

I believe this is a first for us (as well) - at the very least, I won't
claim to have all the answers.  Anyhow, as I see it, we want you to
choose a set of supported packages, then we will probably ask how / why
you made that choice and, quite possibly, poke a bit at making you
choosing a slightly larger set etc.

So, at this point, I think that you get to choose an initial draft for
the "scope of the port".  Of course, I don't expect you to list some
18k+ source packages, so defining it as something like "Desktop
environments except GNOME plus tasksel task X, Y and Z".
  Alternatively, you may want to define it as the set of packages you
won't support (e.g. "KDE, all webservers (except apache2 with PHP5), etc.")
  In fact, it is probably best for you if you combine the two
approaches.  But anyhow, you get to serve the ball on this one.  Just
remember, we will probably ask "why did you choose this set?" (or maybe
even "what would it take for you to also support Y?")

> I'm grateful we've been given another 2 months to work on this.

You are welcome.

>  The
> init system debate might have come to a conclusion by then, and it could
> have some bearing on this.  If some packages (potentially the whole
> GNOME desktop environment) get a hard systemd dependency that would
> somewhat reduce the scope of the port for us I think.
> 
> Regards,
> 


I believe Robert already concluded that GDM was likely a lost cause for
kFreeBSD atm.  I suppose that is what you are referring to?

@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.

~Niels



-- 
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/52e988c1.8010...@thykier.net

Re: Bits from the Release Team: Architecture health check

[Steven Chamberlain]

On 29/01/14 22:50, Russ Allbery wrote:
> Per Josselin's latest discussion of this, there doesn't appear to be any
> direct GNOME dependencies on systemd itself that would be blocking for
> jessie.

Sorry, I got completely the opposite impression from this tonight:

On 29/01/14 17:41, Josselin Mouette wrote:
> Le mercredi 29 janvier 2014 à 19:03 +0200, Adrian Bunk a écrit : 
>>> > > No, you are not. There are several features in systemd that GNOME uses.
>>> > > One of them is user sessions, for which there will indeed be a fallback
>>> > > in place. But it is not the only one.
>> > 
>> > Can you provide a list of features without a fallback in place?
> 
> At least logind, timedated, hostnamed, localed, the boot control
> interfaces. With a very widespread level of failure depending on the
> unavailable interface.
> 
>> > Assuming jessie will support multiple init systems, why would GNOME need 
>> > a dependency on systemd?
> 
> Because it needs logind.
> https://lists.debian.org/debian-ctte/2014/01/msg00360.html

So, even having an adequate logind substitute, GNOME is expected to be
considerably impaired without systemd?

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/52e98b51.9050...@pyro.eu.org

Re: Bits from the Release Team: Architecture health check

[Russ Allbery]

Steven Chamberlain  writes:

> Sorry, I got completely the opposite impression from this tonight:

> On 29/01/14 17:41, Josselin Mouette wrote:

>> Because it needs logind.
>> https://lists.debian.org/debian-ctte/2014/01/msg00360.html

> So, even having an adequate logind substitute, GNOME is expected to be
> considerably impaired without systemd?

Josselin can correct me if I've misunderstood him, but I believe his
opinion is that getting logind working without systemd for systemd
versions after 205 will be far harder than Steve thinks it is and will not
be viable for jessie.  This is, specifically, because the current Ubuntu
approach for separating logind from systemd breaks with versions of
systemd after 205 due to the implications of cgroup integration, and we
obviously don't want to ship jessie with systemd 204 when upstream is
already at a much newer version and will be even farther along by the time
jessie ships.

I don't think there is any disagrement over the scope of the dependency
(namely, on logind plus some of the other D-Bus services and daemons that
aren't as large of a porting issue).  Rather, the question is whether it
is actually viable to separate those services from systemd as init and
port logind to non-Linux, whether that work will be done in time for
jessie, and who is going to do it.

In other words, the portability issue is really about logind (plus some
other, more minor work), not about systemd, but the degree to which logind
forces systemd as init is disputed, and as yet no one has done the
concrete work to establish which technical opinion is correct with systemd
and logind >205.

-- 
Russ Allbery (r...@debian.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/87d2ja1ic9@windlord.stanford.edu

Re: Bits from the Release Team: Architecture health check

[Raphael Hertzog]

On Wed, 29 Jan 2014, Russ Allbery wrote:
> aren't as large of a porting issue).  Rather, the question is whether it
> is actually viable to separate those services from systemd as init and
> port logind to non-Linux, whether that work will be done in time for
> jessie, and who is going to do it.

Steve Langasek believes that logind can be separated from systemd (using
the code base in systemd v204) but even in that version, logind does rely
on cgroups heavily and so it is not portable to kfreebsd.

So the console kit path seems like the only option so far (unless someone
ports logind to use some other freebsd technology).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
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/20140130071532.gb29...@x230-buxy.home.ouaza.com