[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Release sprint results - team changes, auto-rm and arch status

On 05/01/2014 10:30, Niels Thykier wrote:
> On 2013-12-16 23:32, Robert Millan wrote:
>> On 15/12/2013 13:34, Niels Thykier wrote:
>>> It would probably be good if you (i.e. the BSD porters) could start a
>>> dialogue with the GNOME maintainers and figure out exactly where GNOME
>>> is on kFreeBSD (vs. where it is supposed to be).  Once that is sorted
>>> out, please send the release team a summary of the status so we have
>>> accurate information here.
>> Will do. But this can't be done right away. The reports you mention are
>> too vague ("xxx doesn't work", etc) to act upon. We will first need to
>> evaluate the current state of things to have an accurate idea on where
>> we stand regarding GNOME.
> Hi Robert / BSD porters,
> Any news on your front on the status of GNOME on kFreeBSD?

So far #733122. Barring that, the GNOME desktop seems to work fine (including
empathy, nautilus, etc). Once the patch in #733122 is applied, it will be easier
to gather reports from day-to-day users and provide a more complete assessment.

GDM is a different story (see #733546). The problem goes much deeper though. It's
now begun to use SystemD by default, and then falling back to ConsoleKit when
that's not available. There are two serious problems with this:

- The GDM->ConsoleKit codepath is seldom tested. We don't know if it's actually

- According to upstream website, ConsoleKit is deprecated and not actively

We can help as porters but we can't maintain abandoned codepaths on our own. I
think GDM upstream doesn't want to deal with this problem, so perhaps it is better
if we accept that GDM is not a portable program anymore, and make it Linux-only.

And then there's #734070 which AFAICT only results in a few harmless errors (still,
it'd be nice to have it merged, just in case).

> The other day, I was told on IRC that some of the glib tests had been
> disabled / ignored on kFreeBSD (see #649196 and #712848).  I have not
> reviewed them in detail, though the former have no follow up at all (but
> I don't see a CC either, so I guess that is not surprising).

#649196 is probably not an issue anymore. We've replaced our thread implementation

As for #712848, the latest comment sent by Petr suggested that the test might be
incorrect when applied to kqueue.

Robert Millan

Reply to: