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

[Niels Thykier]

On 2014-01-05 12:22, Robert Millan wrote:
> 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?
> 

Hi,

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

Thanks for looking into this.  I have asked on #d-gnome about the patch
you submitted; hopefully it can be applied soon, so we can get a better
view.

> 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
>   working.
> 
> - According to upstream website, ConsoleKit is deprecated and not actively
>   maintained.
> 
> 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.
> 

Do you have an idea of the consequences of making it linux-only?  If it
is just using (e.g.) xdm instead of and kFreeBSD losing a couple of
packages, it will probably not be much of an issue.  But then, I assume
that GNOME and GDM are not tightly coupled.

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

Good.  :)

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

Okay, perhaps you could follow up on the bug with that information and
ask if it is still an issue?

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

I guess you are referring to comment #25 here?  Quote:


"""

This test is guarded by:

[...]

The kqueue support might have the same limit.

I do not know whether is better to use kqueue via gamin
or kqueue directly in glib2.0.

Petr

"""


Seems like no one picked it up from there.  To be honest, I am not sure
where the ball is on that bug right now - as an outsider it is not clear
to me if Petr is asking for the GNOME maintainers or the BSD porters to
follow/second him.  Admittedly, I have very limited knowledge of the
code in question, so it may be more obvious to you.
  Perhaps you could follow up on the bug and prod the GNOME maintainers
for a follow up, if you believe the ball is in their court right now.


~Niels