Trouble with DPorts (based on freebsd-ports)

Tue Feb 14 14:17:04 PST 2017

Hi everyone, this is just a heads up,

as some of you are aware there were some recent developments regarding
the DragonFly ports collection and FreeBSD-ports in general. Huge
graphics stack update (including but not limited to dri, gbm, libdrm,
libEGL, libGL, clang39, xorg-server and its drivers) was just pushed
without giving us a any heads up to prepare for it or perform an early
testing. This came as a surprise since last time we were notified
about upcoming developments that allowed us could construct, patch and
test the new stack. This is how radeonSI card support was added to
xorg for the radeon owners to enjoy running their Desktop machines
with accelerated graphics. We pushed ours and later FreeBSD pushed
theirs since we have a different level of GPU support in kernel DRM
drivers yet we share the same ports tree.

However, this time it was not the case and we are trying to understand
what has happened.

We are aware that there is huge ongoing effort to finally import the
drm 4.9 gpu drivers from linux using linux-kpi emulator layer allowing
to cp/paste linux drivers almost without modifications including the
OFED. We understand this is quite an achievement that FreeBSD users
will finally will be able to run their Desktop machines without a need
to buy expensive nvidia cards and use binary blobs.

I'm a fan of this work cause I have been struggling to get amdgpu
working on few cards that I have stacked (drm/ttm + amdgpu is
complicated), but given that few years old Radeon R7 360 spins quite
nicely, does not overheat and allows to hook monitor to my Xeon box I
am golden. I know I know, radeonkms has few quirks and I was not
paying enough time for it, there are a lot of other fun stuff to
experiment and I have to choose :)

So to catch up with graphics stack update and not to have version
locked packages for such low level ports I for now will put other
ongoing projects and will concentrate on cooking up a quick and dirty
ports tree for testing the new stack. With a bit of luck we might not
need any additions to our current i915 and radeonkms kernel GPU
drivers and new stack will turn out to be quite compatible. This is
just a heads up that during upcoming weeks ports tree might be a bit
unstable as we patch and test cause testing takes time.
First quick  go through the changes both in packages and patches gives
the impression that it should not be very complicated. Mainly thanks
to the freebsd-xorg developers, who looks like added almost all cases
needed to support this complicated Xorg stack on DragonFly too. Maybe
Wayland will be easier to maintain. That is yet to be seen.

Luckily this update has not hit us unprepared and by pure luck we had
to delay the DragonFly BSD v4.8 final release tag due to few last
minute bugs noticed in VM subsystem. So at least we have not branched
out new release before the recent unexpected freebsd-ports changes.
To make things worse one of major contributors was just suspended
literally the day before ports changes were introduced. We still not
sure about the details, just hope this was not a permanent ban from
FreeBSD-ports and he will still be able to contribute for both open
source projects.
https://svnweb.freebsd.org/ports?view=revision&revision=433827

I was not aware how much John contributes outside DragonFly BSD, just did a
quick at recent Marino contributions at FreeBSD-ports:
https://svnweb.freebsd.org/ports?view=revision&revision=432948
https://svnweb.freebsd.org/ports?view=revision&revision=433191
https://svnweb.freebsd.org/ports?view=revision&revision=433339
https://svnweb.freebsd.org/ports?view=revision&revision=433630
https://svnweb.freebsd.org/ports?view=revision&revision=433681
https://svnweb.freebsd.org/ports?view=revision&revision=433771
https://svnweb.freebsd.org/ports?view=revision&revision=433775
https://svnweb.freebsd.org/ports?view=revision&revision=433804
https://svnweb.freebsd.org/ports?view=revision&revision=433810

I could not find any indication of him going turbo by committing
changes without port maintainer approval (he reported to port
maintainers as per rules, patched only the ones that that have no
maintainer assigned) or harming ports in any way. So far it is unclear
why so suddenly his ports commit rights were taken without giving any
specific reason why.

Only one older (two weeks ago) commit might had an issue:
https://svnweb.freebsd.org/ports?view=revision&revision=432860
But again that should have not been enough for anyone to get sacked.

John was the main developer bringing Ada language support for both
DragonFly and FreeBSD as far as porting Ada to work on FreeBSD aarch64
architecture.
Guy has even written awesome ports building tool almost in pure Ada:
https://github.com/jrmarino/synth

Yet just yesterday all his ports and Ada infrastructure support were
resetted to a global ports pool without assigning any person to take
over all his hard work to maintain the ports.
https://svnweb.freebsd.org/ports?view=revision&revision=433856
https://svnweb.freebsd.org/ports?view=revision&revision=433961
And, even worse, preventing him or any other user to even have a
contact to submit the patches or updates. Maybe something like
freebsd-ada@ would work and would help other users as well.

Luckily looks like somebody stepped in and took over
https://svnweb.freebsd.org/ports?view=revision&revision=434055
however this has one of those restricted access to phabricator links:
https://reviews.freebsd.org/D9572
I, as open source proponent and contributor to many projects including
but not limited to open source drivers testing (both Linux and BSD),
fortran development for HPC and number crunching packages, compiler
toolchains, hope this is not a sign of reducing openness and
transparency in FreeBSD project or even implementation and use of
secret courts.
I am aware of strict rules they have:
https://www.freebsd.org/internal/code-of-conduct.html and
https://www.freebsd.org/doc/en/articles/committers-guide/rules.html
7th rule "Do not fight in public with other committers; it looks bad." +
the "As noted, breaking some of these rules can be grounds for suspension or,
upon repeated offense, permanent removal of commit privileges."
It is unclear weather "some of these rules" includes the 7th.
I very doubt John would have broken any other rule, specially the 10th one.

I had and hope will continue to have a pleasure to work with John
while fixing ports, yes he sometimes can be painfully correct for
technological reasons and he is right in most of the cases, but in none
of the cases he exhibited the
"Do not make it personal. Do not take it personally.", nor in any time
I had suspicion that he would try the backroom deal me. We all come
from different backgrounds, with different temperaments, different
expectations from other people, but lets not forget that anyone might
just be having a bad day, family, work related problems. After all we
are just a humans who happen to dedicate their free time to hack on
stuff and have a joy of getting stuff to work.

Granted I'm not familiar with what exactly happened there and weather
John went turbo and started to intentionally break the ports, limit
their functionality by removing support for different things. If that
was the case FreeBSD board have every right to temporarily suspend the
commit rights while leaving a way to contribute to the project while
emotions cool down.
However, from what I have gather so far, recently there was no reason for it.
If it was some heated technical discussion over IRC, guys please..
What happens on IRC, stays on IRC. Mentioned rule works both ways
"Do not make it personal. Do not take it personally."
The question were there any provocations by other people.

Hopefully John would not become the 3rd person in the list mentioned in a
recent presentation at linux.conf.au
https://www.youtube.com/watch?v=Ib7tFvw34DM

Such things can be misinterpreted for attempts to install censorship
and justify its use, nor does it benefit the open source community in
any way. It just promotes the ideas how badly the open source written
code is, discourage the new people joining and hacking on the various
projects give it be ports, base system or even documentation. Most of
us are not paid to do it, we do it in our free time cause it is fun.

Ah! Lets not forget the most important one activity - Testing!
There are no way to have too little testers who are wiling to test
changes by integrating them into their running systems. Some features
might even end up with bricked hardware for some unlucky every day guy
who just installed the BSD on a brand new laptop, just because of by
one error in GPU voltage table due to various reasons like ported
driver and the home user was simply not aware that he might look for
system instability signs and power down the system in time avoiding
the permanent damage.
This me speaking as one of Skylake brick owner while testing changes
for stability on Fedora. Power button blue led went pup-pup and
silence =)

Hmm I got sidetracked, you get the idea, I think I have spent at least
5h just researching the recent changes in FreeBSD-ports and an hour
just writing this, what can I say am a slow writer, English is a hard
language.

I sincerely ask DragonFly BSD community not to engage in fights over
this with certain FreeBSD community members. Fighting between the
projects only makes benefit for third parties and just distances the
developers by not sharing good ideas. In the end sharing is caring.
It is still not clear what happened so lets not jump to conclusions.

To end up this email with a bit brighter mood.
I think I managed to get clang import into base to almost done state.
Currently to get a clang built system I think i got it to just:
cd /usr/src/nrelease
make release WORLD_CCVER=clangb WORLD_ALTCOMPILER=all
dd if=/usr/obj/release/dfly.img of=/dev/da8 bs=1M && sync
boot the usb on testing setup

And it worked, even the loader. I have even verified the:
# CCVER=clangb cc -v
# strings /boot/kernel/kernel |grep clang
# strings /lib/libc.so.8 |grep clang
they do have:
DragonFly clang version 3.9.1 (tags/RELEASE_391/final) (based on LLVM 3.9.1)

So far I am very happy how clang import went through and soon
DragonFly will have 3 base compilers, yes three, gcc 4.7, gcc 5.4.1
and now clang 3.9.1 too. This will allow to further increase the
spectrum we can experiment with and do the further research.
Fun fact I just learned that clang's -O defaults to -O2 and not -O1 as
it is on gcc :)

But for now I'll will focus on DPorts issues. Just hope I will be able
to squeeze clang addition before we do the release.

Best regards,
Rimvydas

This email contains personal opinions and shall not be interpreted as
an official opinion of DragonFly project or any persons associated
with it.