Re: Bits from the Release Team: Architecture health check

2014-01-29 Thread 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

2014-01-29 Thread 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

2014-01-29 Thread 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

2014-01-29 Thread 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

2014-01-29 Thread 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

2014-01-29 Thread 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

2014-01-29 Thread 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

2014-01-29 Thread 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

Re: Bits from the Release Team: Architecture health check

2014-01-30 Thread Thijs Kinkhorst 
On Thu, January 30, 2014 00:03, Niels Thykier wrote:
> On 2014-01-29 23:24, Steven Chamberlain wrote:
>> 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?
> 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 believe that it's also important that the definition is uncomplicated
enough so our users can quickly understand what and what not to expect
from this port, perhaps with a little abstraction.


Thijs


-- 
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/a1eb8f128b0ff547b86a15fc53f23ebb.squir...@aphrodite.kinkhorst.nl

Re: Bits from the Release Team: Architecture health check

2014-01-30 Thread Robert Millan 
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.

-- 
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/52ea6e74.9040...@debian.org

Re: Bits from the Release Team: Architecture health check

2014-01-30 Thread Robert Millan 
On 30/01/2014 08:15, Raphael Hertzog wrote:
> So the console kit path seems like the only option so far (unless someone
> ports logind to use some other freebsd technology).

I'm not an expert on session or console management, but seeing how XDM has
managed to work without consolekit for the last 25 years, I have a hard time
believing either consolekit or logind are the only option if you want to
implement a display manager.

-- 
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/52ea6de9.60...@debian.org

Re: Bits from the Release Team: Architecture health check

2014-01-30 Thread Russ Allbery 
Robert Millan  writes:
> On 30/01/2014 08:15, Raphael Hertzog wrote:

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

> I'm not an expert on session or console management, but seeing how XDM
> has managed to work without consolekit for the last 25 years, I have a
> hard time believing either consolekit or logind are the only option if
> you want to implement a display manager.

They probably aren't.  However, they are, as I understand it, the only
options that GNOME has any support for whatsoever.  Adding support for
some third option might be possible, but I'm dubious that's realistic for
a jessie release timeframe.

-- 
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/8761p1ibuu@windlord.stanford.edu

Re: Bits from the Release Team: Architecture health check

2014-01-30 Thread brunomaximom 

Em 2014-01-30 16:05, Russ Allbery escreveu:

Robert Millan  writes:

On 30/01/2014 08:15, Raphael Hertzog wrote:



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



I'm not an expert on session or console management, but seeing how XDM
has managed to work without consolekit for the last 25 years, I have a
hard time believing either consolekit or logind are the only option if
you want to implement a display manager.


They probably aren't.  However, they are, as I understand it, the only
options that GNOME has any support for whatsoever.  Adding support for
some third option might be possible, but I'm dubious that's realistic 
for

a jessie release timeframe.

--
Russ Allbery (r...@debian.org)   



why not replace only gdm3 for kfreebsd?
the next problem is wayland...3.12 will have wayland by default and 
wayland wasn't ported to FreeBSD yet, so I think maintain Gnome in 
kFreeBSD port will become impossible...

it's best save efforts
what about this: https://wiki.gnome.org/Projects/Jhbuild/FreeBSD ?


--
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/d4ab1b6450e237e5c2192d2d6...@openmailbox.org

Re: Bits from the Release Team: Architecture health check

2014-02-12 Thread Niels Thykier 
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: Bits from the Release Team: Architecture health check

2014-02-13 Thread Robert Millan 
On 12/02/2014 20:06, Niels Thykier wrote:
> 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%".

The release architecture criteria [1] says the target is 98% but
hardware-specific packages are excluded. Does this apply to kernel
ports by simply replacing "hardware-specific" with "kernel-specific"?

[1] https://release.debian.org/jessie/arch_policy.html

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

Thanks. We'll discuss this among ourselves and present a proposal.

-- 
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/52fd511d.8010...@debian.org

Re: Bits from the Release Team: Architecture health check

2014-02-13 Thread Steven Chamberlain 
On 12/02/14 20:06, Niels Thykier wrote:
> 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%".

I'm a little puzzled you mention this as a problem because...

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

if we decide some packages can't be supported any more, I assume some
would become linux-any and thus the number of built packages would fall?
 So these seem like conflicting goals.

I fully agree with the latter point though, I see value in having a plan
for what to support, and probably free some packages of an obligation to
either build, be installable or functional kfreebsd if it no longer
makes sense.

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/52fd53f5.2090...@pyro.eu.org

Re: Bits from the Release Team: Architecture health check

2014-02-13 Thread brunomaximom 

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


gdm3 could be replaced by lightdm in the gnome-core package or not?


--
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/b72d0d082f92cfec116c5e9dafed4...@openmailbox.org

Re: Bits from the Release Team: Architecture health check

2014-02-14 Thread Andreas Barth 
* Robert Millan (r...@debian.org) [140214 00:11]:
> On 12/02/2014 20:06, Niels Thykier wrote:
> > 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%".
> 
> The release architecture criteria [1] says the target is 98% but
> hardware-specific packages are excluded. Does this apply to kernel
> ports by simply replacing "hardware-specific" with "kernel-specific"?
> 
> [1] https://release.debian.org/jessie/arch_policy.html


At the time where we wrote that criteria there wasn't a difference -
basically "packages which don't make a sense don't need to be ported"
was the main thought.


Andi


-- 
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/20140214204245.gh16...@mails.so.argh.org

Re: Bits from the Release Team: Architecture health check

2014-02-15 Thread Niels Thykier 
On 2014-02-14 00:23, Steven Chamberlain wrote:
> On 12/02/14 20:06, Niels Thykier wrote:
>> 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%".
> 
> I'm a little puzzled you mention this as a problem because...
> 
>> 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.
> 
> if we decide some packages can't be supported any more, I assume some
> would become linux-any and thus the number of built packages would fall?
>  So these seem like conflicting goals.
> 

Hi,

Indeed, they are conflicting goals.  But I do not see why that is so
surprising.  There are plenty of things in software development (and
especially in release management) that involves a trade-off on
conflicting goals.
  Ideally, I want all those graphs to show 99.999...%[1], but in the
short term I cannot have that.  Right now, we are trying to look at this
from a pragmatic angle.
  If we get a better kFreeBSD by focusing and dropping some packages
(possibly including a desktop or/and some specific server tasks), then
so be it - as long as there is ambition, motivation and a realistic plan
from your side, then I am willing to consider it.

> I fully agree with the latter point though, I see value in having a plan
> for what to support, and probably free some packages of an obligation to
> either build, be installable or functional kfreebsd if it no longer
> makes sense.
> 
> Regards,
> 

Those packages will probably end up being linux-any in the short term
(and some of them, possibly, in the long term as well).  In said short
term, they will need to be cleaned up (decrufted etc), so they no longer
hold up migration to testing for Jessie.
  For Jessie + 1, I would like for the gap to close between Linux and
kFreeBSD architectures.  But lets take that part later.

~Niels

[1] Which is obviously a different way of writing 100% :P
  http://en.wikipedia.org/wiki/0.999...

Okay, maybe not 100%, but then aim for 95%.


-- 
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/52ff4f2a.5030...@thykier.net

Re: Bits from the Release Team: Architecture health check

2014-02-16 Thread Niels Thykier 
On 2014-02-14 00:32, brunomaxi...@openmailbox.org wrote:
>>> 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).
> 
> gdm3 could be replaced by lightdm in the gnome-core package or not?
> 
> 

I believe Robert concluded that it was possible to use an alternative to
gdm3 (I forgot if it was lightdm or xdm).  Nevertheless, it would
require that the GNOME maintainers are willing to adopt and support that
change.
  If the GNOME maintainers are not willing to support lightdm/xdm as
alternatives, I suspect kFreeBSD might be better served with not
supporting GNOME in Jessie and revisit this problem in Jessie + 1.

~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/53007b84.5050...@thykier.net

Re: Bits from the Release Team: Architecture health check

2014-02-16 Thread Robert Millan 
On 16/02/2014 08:49, Niels Thykier wrote:
> I believe Robert concluded that it was possible to use an alternative to
> gdm3 (I forgot if it was lightdm or xdm).

Well, not exactly.

I think we're at a cross-roads. My understanding is that this used to be 
possible
until now, but the GNOME maintainers are already unhappy with this possibility
and in any case upstream will gradually move further in the opposite direction.

> Nevertheless, it would
> require that the GNOME maintainers are willing to adopt and support that
> change.

It used to be that any login manager was able to interact with any X session 
through
a very simple interface. These were the good old days, in which users could mix 
things
up and customize their environment to their will. But they're gone when it 
comes to
GDM and GNOME.

It seems to me that in GNOME land the UNIX mantra of "do one thing and do it 
well"
is being replaced by monolithic culture. I think this is a poor approach to 
system
design, but as I don't use GNOME myself and GNU/kFreeBSD users have plenty of
alternatives, I don't mean to argue with anyone about it (neither GNOME 
upstream,
nor the Debian GNOME maintainers).

-- 
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/5300b045.7030...@debian.org

Re: Bits from the Release Team: Architecture health check

2014-02-19 Thread Robert Millan 
On 29/01/2014 23:03, Niels Thykier wrote:
> 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.

Hi Niels,

After some discussion we've reached the following position statement, which
has the approval of Steven, Petr and myself:

~~~
It is with much regret that we observe that GDM has grown hard dependencies
on a Linux-specific component (systemd). Although GDM still offers the
possibility of running it using ConsoleKit, this codepath is no longer
supported by upstream, and ConsoleKit itself is considered deprecated
software and has been abandoned by its developers.

Furthermore, we observe that the GNOME UI has grown hard dependencies on GDM,
as well as other developments which make it impractical to run GNOME on
kernels other than Linux. Our understanding is that GNOME release managers don't
see this as a problem and are not actively trying to resolve this.

In this situation we do not think it's reasonably practical for us to continue
providing assistance to ensure portability of the GNOME desktop on GNU/kFreeBSD.

When it comes to individual applications, we'd like to support as many of
them as possible. As long as they are still intended to be portable by
their upstream developers, and that they don't have any hard dependency
on the GNOME desktop itself (i.e., they can be run as standalone apps), we
intend to continue providing porting assistance for them.
~~~

-- 
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/5304dcb3.5000...@debian.org

Re: Bits from the Release Team: Architecture health check

2014-02-19 Thread Cyril Brulebois 
Robert Millan  (2014-02-19):
> After some discussion we've reached the following position statement, which
> has the approval of Steven, Petr and myself:
> 
> ~~~
> It is with much regret that we observe that GDM has grown hard dependencies
> on a Linux-specific component (systemd). Although GDM still offers the
> possibility of running it using ConsoleKit, this codepath is no longer
> supported by upstream, and ConsoleKit itself is considered deprecated
> software and has been abandoned by its developers.
> 
> Furthermore, we observe that the GNOME UI has grown hard dependencies on GDM,
> as well as other developments which make it impractical to run GNOME on
> kernels other than Linux. Our understanding is that GNOME release managers 
> don't
> see this as a problem and are not actively trying to resolve this.
> 
> In this situation we do not think it's reasonably practical for us to continue
> providing assistance to ensure portability of the GNOME desktop on 
> GNU/kFreeBSD.
> 
> When it comes to individual applications, we'd like to support as many of
> them as possible. As long as they are still intended to be portable by
> their upstream developers, and that they don't have any hard dependency
> on the GNOME desktop itself (i.e., they can be run as standalone apps), we
> intend to continue providing porting assistance for them.
> ~~~

I thought this might be of some interest:
  http://blogs.gnome.org/mclasen/2014/02/19/on-portability/

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Bits from the Release Team: Architecture health check

2014-02-19 Thread brunomaximom 

Em 2014-02-19 13:45, Cyril Brulebois escreveu:

Robert Millan  (2014-02-19):
After some discussion we've reached the following position statement, 
which

has the approval of Steven, Petr and myself:

~~~
It is with much regret that we observe that GDM has grown hard 
dependencies

on a Linux-specific component (systemd). Although GDM still offers the
possibility of running it using ConsoleKit, this codepath is no longer
supported by upstream, and ConsoleKit itself is considered deprecated
software and has been abandoned by its developers.

Furthermore, we observe that the GNOME UI has grown hard dependencies 
on GDM,
as well as other developments which make it impractical to run GNOME 
on
kernels other than Linux. Our understanding is that GNOME release 
managers don't

see this as a problem and are not actively trying to resolve this.

In this situation we do not think it's reasonably practical for us to 
continue
providing assistance to ensure portability of the GNOME desktop on 
GNU/kFreeBSD.


When it comes to individual applications, we'd like to support as many 
of

them as possible. As long as they are still intended to be portable by
their upstream developers, and that they don't have any hard 
dependency
on the GNOME desktop itself (i.e., they can be run as standalone 
apps), we

intend to continue providing porting assistance for them.
~~~


I thought this might be of some interest:
  http://blogs.gnome.org/mclasen/2014/02/19/on-portability/

Mraw,
KiBi.


Interesting...he say: "We don’t make it a secret that modern Linux is 
the primary target that we are developing on and for.". KDE guys also 
make KDE first in LInux, but they have an official web site to support 
this purpose http://freebsd.kde.org/ and Gnome?
KDE also investing in new technologies and at same time they have a team 
to portability, so...



--
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/914917e9ce458a98991d41430b9de...@openmailbox.org

Re: Bits from the Release Team: Architecture health check

2014-02-19 Thread Robert Millan 
On 19/02/2014 16:45, Cyril Brulebois wrote:
> Robert Millan  (2014-02-19):
>> After some discussion we've reached the following position statement, which
>> has the approval of Steven, Petr and myself:
>>
>> ~~~
>> It is with much regret that we observe that GDM has grown hard dependencies
>> on a Linux-specific component (systemd). Although GDM still offers the
>> possibility of running it using ConsoleKit, this codepath is no longer
>> supported by upstream, and ConsoleKit itself is considered deprecated
>> software and has been abandoned by its developers.
>>
>> Furthermore, we observe that the GNOME UI has grown hard dependencies on GDM,
>> as well as other developments which make it impractical to run GNOME on
>> kernels other than Linux. Our understanding is that GNOME release managers 
>> don't
>> see this as a problem and are not actively trying to resolve this.
>>
>> In this situation we do not think it's reasonably practical for us to 
>> continue
>> providing assistance to ensure portability of the GNOME desktop on 
>> GNU/kFreeBSD.
>>
>> When it comes to individual applications, we'd like to support as many of
>> them as possible. As long as they are still intended to be portable by
>> their upstream developers, and that they don't have any hard dependency
>> on the GNOME desktop itself (i.e., they can be run as standalone apps), we
>> intend to continue providing porting assistance for them.
>> ~~~
> 
> I thought this might be of some interest:
>   http://blogs.gnome.org/mclasen/2014/02/19/on-portability/

Skillful talk and some screenshots may be useful to persuade people, but alas, 
it
has no effect whatsoever on the actual problem.

-- 
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/53050f95.8030...@debian.org

Re: Bits from the Release Team: Architecture health check

2014-03-12 Thread Niels Thykier 
On 2014-02-19 17:32, Robert Millan wrote:
> On 29/01/2014 23:03, Niels Thykier wrote:
>> 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.
> 
> Hi Niels,
> 
> After some discussion we've reached the following position statement, which
> has the approval of Steven, Petr and myself:
> 
> ~~~
> It is with much regret that we observe that GDM has grown hard dependencies
> on a Linux-specific component (systemd). Although GDM still offers the
> possibility of running it using ConsoleKit, this codepath is no longer
> supported by upstream, and ConsoleKit itself is considered deprecated
> software and has been abandoned by its developers.
> 
> Furthermore, we observe that the GNOME UI has grown hard dependencies on GDM,
> as well as other developments which make it impractical to run GNOME on
> kernels other than Linux. Our understanding is that GNOME release managers 
> don't
> see this as a problem and are not actively trying to resolve this.
> 
> In this situation we do not think it's reasonably practical for us to continue
> providing assistance to ensure portability of the GNOME desktop on 
> GNU/kFreeBSD.
> 
> When it comes to individual applications, we'd like to support as many of
> them as possible. As long as they are still intended to be portable by
> their upstream developers, and that they don't have any hard dependency
> on the GNOME desktop itself (i.e., they can be run as standalone apps), we
> intend to continue providing porting assistance for them.
> ~~~
> 

Hi,

Thanks for looking into this and I apologise for not following up any
sooner.

As I read/understand the above, you basically say (something along the
lines of):

"""
The Debian kFreeBSD porters will not support packages, where upstream
have no (visible) interest/intention of being portable (beyond
${OS}-any) nor their reverse dependencies.  Examples of these include
(but are not limited to) systemd and GNOME (via GDM).
"""

It is not that I want to change your wording or anything. I just wanted
to make sure I had captured the important parts of it.



In any event, we will be evaluating kFreeBSD (along with other
architectures) relatively soon.  Our current plans suggest early-mid
April, but I do not have a fixed date yet.

~Niels



-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5320afb2.9020...@thykier.net

Re: Bits from the Release Team: Architecture health check

2014-03-12 Thread Robert Millan 
On 12/03/2014 19:04, Niels Thykier wrote:
> As I read/understand the above, you basically say (something along the
> lines of):
> 
> """
> The Debian kFreeBSD porters will not support packages, where upstream
> have no (visible) interest/intention of being portable (beyond
> ${OS}-any) nor their reverse dependencies.  Examples of these include
> (but are not limited to) systemd and GNOME (via GDM).
> """
> 
> It is not that I want to change your wording or anything. I just wanted
> to make sure I had captured the important parts of it.

I don't think it's possible to put this in generic wording. There are specific
reasons why GNOME can't be considered a portable program. I think they're enough
well-known so that I shouldn't need to publicize them.

-- 
Robert Millan


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5320d8d4.2080...@debian.org