Re: Again, flavors or options?

[Shane Ambler]

On 21/12/2017 16:35, Freddie Cash wrote:
> On Dec 20, 2017 6:16 PM, "Yuri"  wrote:
> 
> I have the port for the digital currency. It has 3 parts that install
> non-intersecting file sets: daemon, cli, qt-ui. The commonality: same
> repository, same build options, same license, mostly same port options.
> 
> I am attracted to the idea to use flavors to let users choose which part do
> they want: FLAVORS=default daemon qt cli

As I said in my first answer, flavours changes the dependencies not the
options of the port, eg a flavour using py27 another using py36

I don't think there is a way to have different options enabled for
different flavours, each flavour will use the same options.

Until we have the ability to break a single port into multiple packages
that can be installed separately, you either have options for each item
or a different port for each. So you could make the daemon and cli
enabled as default, which will be available in the standard repos, then
the qt-gui as an option the user needs to enable and build themselves.

To simplify maintaining multiple related ports, you can use the same
Makefile for each by setting up the others as slave ports, see 5.10 of
the porters handbook. By setting a variable in the slave, you can use
logic tests to control what varies for each port in the one Makefile.

> "default" will install all of them, others will install individual parts.
> Option list will be slightly different for each flavor.
> 
> One alternative: only have port options. Then some options can't be
> conditional on which parts are built.

You have several options to logically control what options are enabled.
You can find several possibilities in 5.13 of the porters handbook.

from 5.13.3.7 -
OPT1_IMPLIES= OPT2
# this means when you enable OPT1, OPT2 will automatically be turned on

from 5.13.3.8 -
OPT1_PREVENTS= OPT2
# this prevents enabling OPT1 and OPT2 at the same time

You can use the standard logic available in any Makefile -

.if ${PORT_OPTIONS:MOPT1} && ${PORT_OPTIONS:MOPT2}
# make adjustments for both options being on
.endif

You also get custom build targets based on options (5.13.3.12) -
post-patch-OPT1-on:
${REINPLACE_CMD} -e 's|opt2=True|opt2=False|' ${WRKSRC}/configure


-- 
FreeBSD - the place to B...Software Developing

Shane Ambler

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail got updated!

[Matthias Andree]

Am 21.12.2017 um 06:07 schrieb Adam Weinberger:
>> On 20 Dec, 2017, at 17:19, Matthias Andree 
>> wrote:
>>
>> Am 20.12.2017 um 06:40 schrieb Eugene Grosbein:
>>> On 20.12.2017 01:03, Matthias Andree wrote:
>>>
 Dear Ted, Eugene,
>>> [skip]
>>>
>>> What happened with old good "Tools, not policy" thing?
>>
>> It's simpler than that, no policy involved.
>>
>> The tool had a hollow head, and broke after several years of banging it,
>> and the former tool maker told the public it's out of warranty (never
>> was in due to it being free) and not being fixed any more, and should be
>> scrapped.
>
> I'm a little unsettled by this discussion, because it is moving into
> territory with which we have very little precedent. And the precedent
> that it would establish is not wholly within our mandate.
>
> FreeBSD ports provides the best available versions of software to run
> on FreeBSD---we have traditionally been very conservative in
> deprecating software. The mere fact that there are better alternatives
> is not sufficient reason to take it away from people. When it ceases
> to work, or is intolerably dangerous, then it is incumbent upon us to
> act. You know far, far more about the intricacies of email than I do,
> Matthias, so please correct me if I am incorrect here, but I'm not
> aware of procmail being unsuitably dangerous for admins who make a
> conscious decision to use it.
>

 is all it
needs to mount the various mentioned cases, such as dangerous, bitrotten
and whatever other arguments have been asked for.

Given two CVEs and another crasher fixed in 3.22_5, that is reason
enough to reconsider. We either need to take responsibility and have the
port audited and someone paid to maintain it properly, or remove it, or
at least we need to move it into the poison cabinet and lock it up (i.
e. set DEPRECATED due to missing upstream maintenance and FORBIDDEN +
NOPACKAGE due to it being dangerous),

This is not to belittle ache@ (until 2011) or sunpoet@s and the
contributors' efforts, but really about the upstream software that we
are shipping.

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail got updated!

[Dave Horsfall]

On Wed, 20 Dec 2017, Adam Weinberger wrote:

I'm a little unsettled by this discussion, because it is moving into 
territory with which we have very little precedent. And the precedent 
that it would establish is not wholly within our mandate.


Am I the only one who remembers the kerfuffle over "jive" being de-ported 
(to coin a phrase)?  No technical reason whatsoever, but apparently it 
upset someone's delicate sensibilities, so there's sort of a precedent.


--
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Again, flavors or options?

[Freddie Cash]

On Dec 20, 2017 6:16 PM, "Yuri"  wrote:

I have the port for the digital currency. It has 3 parts that install
non-intersecting file sets: daemon, cli, qt-ui. The commonality: same
repository, same build options, same license, mostly same port options.

I am attracted to the idea to use flavors to let users choose which part do
they want: FLAVORS=default daemon qt cli

"default" will install all of them, others will install individual parts.
Option list will be slightly different for each flavor.

One alternative: only have port options. Then some options can't be
conditional on which parts are built.

Another alternative: 3 slave ports. I don't like this idea at all.

Do you think flavors are a good fit for this task?


Sounds like a textbook example of sub-packages.

Until then, slave ports would be the next-best thing as that provides
separate packages that can be installed.

Cheers,
Freddie
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail got updated!

[Adam Weinberger]

On 20 Dec, 2017, at 17:19, Matthias Andree  wrote:

Am 20.12.2017 um 06:40 schrieb Eugene Grosbein:

On 20.12.2017 01:03, Matthias Andree wrote:


Dear Ted, Eugene,

[skip]

What happened with old good "Tools, not policy" thing?


It's simpler than that, no policy involved.

The tool had a hollow head, and broke after several years of banging it,
and the former tool maker told the public it's out of warranty (never
was in due to it being free) and not being fixed any more, and should be
scrapped.


I'm a little unsettled by this discussion, because it is moving into  
territory with which we have very little precedent. And the precedent that  
it would establish is not wholly within our mandate.


FreeBSD ports provides the best available versions of software to run on  
FreeBSD---we have traditionally been very conservative in deprecating  
software. The mere fact that there are better alternatives is not  
sufficient reason to take it away from people. When it ceases to work, or  
is intolerably dangerous, then it is incumbent upon us to act. You know  
far, far more about the intricacies of email than I do, Matthias, so please  
correct me if I am incorrect here, but I'm not aware of procmail being  
unsuitably dangerous for admins who make a conscious decision to use it.


I'm not a fan of the message it would send: taking the port away from our  
users tells them that we don't trust their ability to decide what to do  
with their systems. I would far prefer that we educate our users about the  
alternatives, and provide a suitable warning for procmail, not censor it  
entirely.


We can plaster the port with warnings and recommendations for people to  
switch, or set DEPRECATED without an EXPIRATION_DATE, but taking it away  
from people establishes a precedent that I wouldn't feel great about.  
Procmail was the standard for an incredibly long time, and there are  
undoubtedly many shops that rely upon it.


# Adam


--
Adam Weinberger
ad...@adamw.org
http://www.adamw.org

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail got updated!

[Ted Hatfield]

On Wed, 20 Dec 2017, Kevin Oberman wrote:

On Wed, Dec 20, 2017 at 4:19 PM, Matthias Andree 
wrote:


Am 20.12.2017 um 06:40 schrieb Eugene Grosbein:

On 20.12.2017 01:03, Matthias Andree wrote:


Dear Ted, Eugene,

[skip]

What happened with old good "Tools, not policy" thing?




It's simpler than that, no policy involved.

The tool had a hollow head, and broke after several years of banging it,
and the former tool maker told the public it's out of warranty (never
was in due to it being free) and not being fixed any more, and should be
scrapped.



It still works (painfully) and is used by many.  They would be wise to
stop, but it is not the job of the project to force them to do so,

I do think that a pkg-message with "Here there be dragons! Proceed at your
own risk. dropmail is a MUCH safer (and easier) path." would be
appropriate. I don't think it is the job of the project to force people to
replace it if they think they know what they are doing. Of course, bitrot
or similar may take it before long.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683



I still use sendmail/procmail for all of my systems.  If it's up to a vote 
I would vote to keep procmail as a valid port.  That being said I am not a 
port maintainer and I wouldn't presume to tell them what to maintain as I 
am not the one doing the actual work.


However based upon my experience I am betting that there are a lot of 
systems still out there that are still using procmail.


I think if you choose to drop support for procmail you should do as 
Kevin suggests and give a warning and a firm date when support will stop.


This will give people a chance to update their systems appropriately.


Ted Hatfield


___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Vote: making wayland=on default

[Michael Gmelin]

> On 21. Dec 2017, at 02:14, Chris H  wrote:
> 
> On Thu, 21 Dec 2017 00:29:40 +0100 "Michael Gmelin"  said
> 
>> > On 20. Dec 2017, at 18:50, Chris H  wrote:
>> > > On Wed, 20 Dec 2017 17:13:43 +  said
>> > > On Wed, 20 Dec 2017 16:23:59 + "Johannes Lundberg" 
>> > > 
>> > said
>> > >> On Wed, Dec 20, 2017 at 4:08 PM, Chris H  
>> > >> wrote:
>> >> > On Wed, 20 Dec 2017 09:20:20 + "Johannes Lundberg"
>> >> 
>> >> > said
>> >> >
>> >> >> Hi
>> >> >>
>> >> >> I want to suggest that we enable wayland by default. In current state
>> >> >> having some parts of wayland in ports is basically useless the
>> >> >> end-users themselves re-build gtk30 and mesa-libs with wayland
>> >> >> enabled.
>> >> >>
>> >> >> libwayland-egl.so from mesa-libs and the extra libraries and headers
>> >> >> from gtk30 adds like a few KB, a drop in the ocean compared to xorg
>> >> >> packages. (might be something more that I missed)
>> >> >>
>> >> >> Personally I see no reason not to make it default on, even with
>> >> >> flavors coming up. For any Desktop user (as well as embedded devices
>> >> >> like IVI-systems and whatnot), Wayland is the future. There's no
>> >> >> escaping that.
>> >> >>
>> >> >> Wayland has been quite usable on FreeBSD for over a year now but
>> >> >> access to it is limited due to the extra efforts required to use it.
>> >> >>
>> >> >> If we are to compare with the other guys, several Linux distros are
>> >> >> already switching to wayland-based compositors as default window
>> >> >> server.
>> >> >>
>> >> >> What do you think?
>> >> >
>> >> > IMHO it's (still) too early. Too much other X(org) related work
>> >> > still being completed. In fact, I just built a new dev box to
>> >> > track 12 (CURRENT), and this was the first time I was not required
>> >> > to pre generate a config file for Xorg. I was only required to
>> >> > inform /usr/local/etc/X11/xorg.conf.d/nvidia-driver.conf that
>> >> > the driver was "nvidia", not "nv". Everything work(s|ed) famously.
>> >> > A real treat. I'm also a bit concerned about the progress (or lack
>> >> > there of) on network transparency.
>> >> > I (personally) could conceive it as a KERNEL OPTION, but would not
>> >> > want to see it in the Default kernel.
>> >> >
>> >> > Well, those are *my* thoughts. Because you asked. :-)
>> >> >
>> >> > --Chris
>> >> >
>> >> Thanks for your feedback!
>> >> Just to clarify, we're not talking about changing any defaults that
>> >> would impact or change users' choice of desktop. We only want to
>> >> enable Wayland compositors as an alternative to X (leaving X as is).
>> >> This does not break or modify anything existing. It does not force you
>> >> to do anything differently. It simply adds a couple of libraries that
>> >> you won't use unless you run Wayland stuff (if you install qt5/gtk30
>> >> and mesa-libs).
>> >> The reference to Linux making it default might have been unclear.
>> >> Since FreeBSD doesn't have a default desktop, it's hard to change. It
>> >> is and will continue to be up to the end user what they choose to use,
>> >> we only add more options :)
>> > Thanks for the informative reply, Johannes.
>> > So no kernel (libs/extensions)?
>> > Hmm, gtk3. Why is it not possible to make the Wayland stuff a sub
>> > package/option? I think this is the preferred track/policy anyway.
>> > I do this for all the ports I currently maintain. IOW any DE related
>> > stuff I install, that uses GNOME related material, will pull in gtk3,
>> > which, as I understand you say, will ultimately pull in Weston,mesa,...
>> > is that correct? While I understand, you indicate it's only a few Kb.
>> > I think it's cruft/(unnecessary)overhead. Which, in and of itself
>> > seems insignificant. But in the "big picture", and over many (100's)
>> > of builds/installations, is *not* insignificant. This also dismisses
>> > the security related work, maintaining extra un(used|needed) material.
>> > I suppose some will think that I'm just being nit-picky. But IMHO
>> > I'm not. This sort of thing, if overlooked, *does* affect the bottom
>> > line.
>> > > Thanks again, Johannes!
>> > > P.S. I have nothing against Wayland. I'm just not ready to run it
>> > on anything "production" related, just yet. :-)
>> > > --Chris
>> > The key is to have it in a state that easy to maintain and allows people to
>> install it using pkg install without conflicting with X, so you can switch
>> back and forth easily. I'm also not ready to switch to wayland yet (favorite
>> window manager not available, so many custom configurations I came up with
>> over the years etc.), but giving users an easy way to test it (or use it, as
>> it's becoming more and more mainstream now) is a good thing. Having a 
>> modern, working, out of the box desktop (read: no custom kernel
>> builds, no need to use ports, a 

Again, flavors or options?

[Yuri]

I have the port for the digital currency. It has 3 parts that install 
non-intersecting file sets: daemon, cli, qt-ui. The commonality: same 
repository, same build options, same license, mostly same port options.


I am attracted to the idea to use flavors to let users choose which part 
do they want: FLAVORS=default daemon qt cli


"default" will install all of them, others will install individual 
parts. Option list will be slightly different for each flavor.



One alternative: only have port options. Then some options can't be 
conditional on which parts are built.


Another alternative: 3 slave ports. I don't like this idea at all.


Do you think flavors are a good fit for this task?


Yuri

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Vote: making wayland=on default

[Sid]

Wayland should not be mixed in with other code like gtk3, gtk2, gnome related 
programs. This will immediately create bloat.

Wayland does remove a lot of unneeded obsolete code that is in Xorg, that is 
put in there by principle, and not much else. If gtk creeps into Wayland, those 
benefits will be lost.

The current eagerness about wanting Wayland is centered around gtk. This will 
quickly harm the project.

Wayland should work on top of xlibs that are not obsolete.

Wayland shouldn't be made the default until small window managers like antiwm, 
blackbox, bspwm, ctwm, cwm, i3, jwm, qtile, vtwm and others like this work on 
it. It should also work on fluxbox and enlightenment first. Wayland on FreeBSD 
shouldn't be centered around GNU, gtk or Gnome.

I would say make a Wayland-gtk package offshoot, but this will also quickly 
ruin things. Wayland should stay clean, and allow modular components on top of 
it, that don't spread out bloat dependencies out. Wayland should keep the same 
habit as Xorg, with the exception of keeping obsolete hardware code.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Vote: making wayland=on default

[Chris H]

On Thu, 21 Dec 2017 00:29:40 +0100 "Michael Gmelin"  said


> On 20. Dec 2017, at 18:50, Chris H  wrote:
> 
> On Wed, 20 Dec 2017 17:13:43 +  said
> 
> On Wed, 20 Dec 2017 16:23:59 + "Johannes Lundberg" 

> said
> 
>> On Wed, Dec 20, 2017 at 4:08 PM, Chris H  wrote:

>> > On Wed, 20 Dec 2017 09:20:20 + "Johannes Lundberg"
>> 
>> > said
>> >
>> >> Hi
>> >>
>> >> I want to suggest that we enable wayland by default. In current state
>> >> having some parts of wayland in ports is basically useless the
>> >> end-users themselves re-build gtk30 and mesa-libs with wayland
>> >> enabled.
>> >>
>> >> libwayland-egl.so from mesa-libs and the extra libraries and headers
>> >> from gtk30 adds like a few KB, a drop in the ocean compared to xorg
>> >> packages. (might be something more that I missed)
>> >>
>> >> Personally I see no reason not to make it default on, even with
>> >> flavors coming up. For any Desktop user (as well as embedded devices
>> >> like IVI-systems and whatnot), Wayland is the future. There's no
>> >> escaping that.
>> >>
>> >> Wayland has been quite usable on FreeBSD for over a year now but
>> >> access to it is limited due to the extra efforts required to use it.
>> >>
>> >> If we are to compare with the other guys, several Linux distros are
>> >> already switching to wayland-based compositors as default window
>> >> server.
>> >>
>> >> What do you think?
>> >
>> > IMHO it's (still) too early. Too much other X(org) related work
>> > still being completed. In fact, I just built a new dev box to
>> > track 12 (CURRENT), and this was the first time I was not required
>> > to pre generate a config file for Xorg. I was only required to
>> > inform /usr/local/etc/X11/xorg.conf.d/nvidia-driver.conf that
>> > the driver was "nvidia", not "nv". Everything work(s|ed) famously.
>> > A real treat. I'm also a bit concerned about the progress (or lack
>> > there of) on network transparency.
>> > I (personally) could conceive it as a KERNEL OPTION, but would not
>> > want to see it in the Default kernel.
>> >
>> > Well, those are *my* thoughts. Because you asked. :-)
>> >
>> > --Chris
>> >
>> Thanks for your feedback!
>> Just to clarify, we're not talking about changing any defaults that
>> would impact or change users' choice of desktop. We only want to
>> enable Wayland compositors as an alternative to X (leaving X as is).
>> This does not break or modify anything existing. It does not force you
>> to do anything differently. It simply adds a couple of libraries that
>> you won't use unless you run Wayland stuff (if you install qt5/gtk30
>> and mesa-libs).
>> The reference to Linux making it default might have been unclear.
>> Since FreeBSD doesn't have a default desktop, it's hard to change. It
>> is and will continue to be up to the end user what they choose to use,
>> we only add more options :)
> Thanks for the informative reply, Johannes.
> So no kernel (libs/extensions)?
> Hmm, gtk3. Why is it not possible to make the Wayland stuff a sub
> package/option? I think this is the preferred track/policy anyway.
> I do this for all the ports I currently maintain. IOW any DE related
> stuff I install, that uses GNOME related material, will pull in gtk3,
> which, as I understand you say, will ultimately pull in Weston,mesa,...
> is that correct? While I understand, you indicate it's only a few Kb.
> I think it's cruft/(unnecessary)overhead. Which, in and of itself
> seems insignificant. But in the "big picture", and over many (100's)
> of builds/installations, is *not* insignificant. This also dismisses
> the security related work, maintaining extra un(used|needed) material.
> I suppose some will think that I'm just being nit-picky. But IMHO
> I'm not. This sort of thing, if overlooked, *does* affect the bottom
> line.
> 
> Thanks again, Johannes!
> 
> P.S. I have nothing against Wayland. I'm just not ready to run it

> on anything "production" related, just yet. :-)
> 
> --Chris
> 


The key is to have it in a state that easy to maintain and allows people to
install it using pkg install without conflicting with X, so you can switch
back and forth easily. I'm also not ready to switch to wayland yet (favorite
window manager not available, so many custom configurations I came up with
over the years etc.), but giving users an easy way to test it (or use it, as
it's becoming more and more mainstream now) is a good thing. 


Having a modern, working, out of the box desktop (read: no custom kernel
builds, no need to use ports, a laptop is the point of first contact for many
potential users) is incredibly important for proliferation and compared to
the total size of binaries required to run X, I think the usefulness of
providing wayland easily outweighs the extra overhead.

I wouldn't argue, nor did I argue those points. Who would? But muddying up
the individual 

Re: Canberra

[Sid]

> Blubee blubeeme
> I'll work on it but let me get the port in the tree first, then I can refine 
> it.
> Just as i've done with my previous ports.

> Sid
> a simple program that plays simple sounds like "Ding!"
> The problem with libcanberra is around pulseaudio and gstreamer. It is also 
> with how gtk, a Visual Graphical toolkit, is mixed in with an Audio 
> application.

I was inspecting libcanberra and libcanberra-gtk3.

audio/libcanberra-gtk3 takes care of canberra plugins for pulseaudio and 
gstreamer. It also takes care of two gtk3 library files, one of which is a 
module. Ports that really need gtk3 are tangled mostly upstream, and require 
--enable-gtk3. Others ports require libcanberra-gtk3 for either gtk3, 
pulseaudio or gstreamer. Some ports have audio/libcanberra-gtk3 as a 
dependency, but don't need it.

audio/libcanberra itself is not so bad. audio/libcanberra also works without 
gtk20 in the test Makefile, which shouldn't be needed at all. So, plain 
libcanberra without libcanberra-gtk3 is not complicated, because it doesn't 
involve gtk3, pulseaudio, and gstreamer; it has gtk2 as a dependency, which it 
doesn't need.


Sooner or later, a drop in replacement for libcanberra needs to be made for all 
BSD's. It should use ogg files from audio/freedesktop-sound-theme. Perhaps it 
can include simple pipe to play ogg and other audio files as well. After 
investigating, libcanberra is suitable for the short term, and anything that 
fails without libcanberra-gtk3 is an issue with the upstream ports themselves.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail got updated!

[Kevin Oberman]

On Wed, Dec 20, 2017 at 4:19 PM, Matthias Andree 
wrote:

> Am 20.12.2017 um 06:40 schrieb Eugene Grosbein:
> > On 20.12.2017 01:03, Matthias Andree wrote:
> >
> >> Dear Ted, Eugene,
> > [skip]
> >
> > What happened with old good "Tools, not policy" thing?
> >
> >
>
> It's simpler than that, no policy involved.
>
> The tool had a hollow head, and broke after several years of banging it,
> and the former tool maker told the public it's out of warranty (never
> was in due to it being free) and not being fixed any more, and should be
> scrapped.
>

It still works (painfully) and is used by many.  They would be wise to
stop, but it is not the job of the project to force them to do so,

I do think that a pkg-message with "Here there be dragons! Proceed at your
own risk. dropmail is a MUCH safer (and easier) path." would be
appropriate. I don't think it is the job of the project to force people to
replace it if they think they know what they are doing. Of course, bitrot
or similar may take it before long.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Vote: making wayland=on default

[Kevin Oberman]

On Wed, Dec 20, 2017 at 3:29 PM, Michael Gmelin  wrote:

>
>
> > On 20. Dec 2017, at 18:50, Chris H  wrote:
> >
> > On Wed, 20 Dec 2017 17:13:43 + 
> said
> >
> > On Wed, 20 Dec 2017 16:23:59 + "Johannes Lundberg" <
> johal...@gmail.com>
> > said
> >
> >> On Wed, Dec 20, 2017 at 4:08 PM, Chris H 
> wrote:
> >> > On Wed, 20 Dec 2017 09:20:20 + "Johannes Lundberg"
> >> 
> >> > said
> >> >
> >> >> Hi
> >> >>
> >> >> I want to suggest that we enable wayland by default. In current state
> >> >> having some parts of wayland in ports is basically useless the
> >> >> end-users themselves re-build gtk30 and mesa-libs with wayland
> >> >> enabled.
> >> >>
> >> >> libwayland-egl.so from mesa-libs and the extra libraries and headers
> >> >> from gtk30 adds like a few KB, a drop in the ocean compared to xorg
> >> >> packages. (might be something more that I missed)
> >> >>
> >> >> Personally I see no reason not to make it default on, even with
> >> >> flavors coming up. For any Desktop user (as well as embedded devices
> >> >> like IVI-systems and whatnot), Wayland is the future. There's no
> >> >> escaping that.
> >> >>
> >> >> Wayland has been quite usable on FreeBSD for over a year now but
> >> >> access to it is limited due to the extra efforts required to use it.
> >> >>
> >> >> If we are to compare with the other guys, several Linux distros are
> >> >> already switching to wayland-based compositors as default window
> >> >> server.
> >> >>
> >> >> What do you think?
> >> >
> >> > IMHO it's (still) too early. Too much other X(org) related work
> >> > still being completed. In fact, I just built a new dev box to
> >> > track 12 (CURRENT), and this was the first time I was not required
> >> > to pre generate a config file for Xorg. I was only required to
> >> > inform /usr/local/etc/X11/xorg.conf.d/nvidia-driver.conf that
> >> > the driver was "nvidia", not "nv". Everything work(s|ed) famously.
> >> > A real treat. I'm also a bit concerned about the progress (or lack
> >> > there of) on network transparency.
> >> > I (personally) could conceive it as a KERNEL OPTION, but would not
> >> > want to see it in the Default kernel.
> >> >
> >> > Well, those are *my* thoughts. Because you asked. :-)
> >> >
> >> > --Chris
> >> >
> >> Thanks for your feedback!
> >> Just to clarify, we're not talking about changing any defaults that
> >> would impact or change users' choice of desktop. We only want to
> >> enable Wayland compositors as an alternative to X (leaving X as is).
> >> This does not break or modify anything existing. It does not force you
> >> to do anything differently. It simply adds a couple of libraries that
> >> you won't use unless you run Wayland stuff (if you install qt5/gtk30
> >> and mesa-libs).
> >> The reference to Linux making it default might have been unclear.
> >> Since FreeBSD doesn't have a default desktop, it's hard to change. It
> >> is and will continue to be up to the end user what they choose to use,
> >> we only add more options :)
> > Thanks for the informative reply, Johannes.
> > So no kernel (libs/extensions)?
> > Hmm, gtk3. Why is it not possible to make the Wayland stuff a sub
> > package/option? I think this is the preferred track/policy anyway.
> > I do this for all the ports I currently maintain. IOW any DE related
> > stuff I install, that uses GNOME related material, will pull in gtk3,
> > which, as I understand you say, will ultimately pull in Weston,mesa,...
> > is that correct? While I understand, you indicate it's only a few Kb.
> > I think it's cruft/(unnecessary)overhead. Which, in and of itself
> > seems insignificant. But in the "big picture", and over many (100's)
> > of builds/installations, is *not* insignificant. This also dismisses
> > the security related work, maintaining extra un(used|needed) material.
> > I suppose some will think that I'm just being nit-picky. But IMHO
> > I'm not. This sort of thing, if overlooked, *does* affect the bottom
> > line.
> >
> > Thanks again, Johannes!
> >
> > P.S. I have nothing against Wayland. I'm just not ready to run it
> > on anything "production" related, just yet. :-)
> >
> > --Chris
> >
>
> The key is to have it in a state that easy to maintain and allows people
> to install it using pkg install without conflicting with X, so you can
> switch back and forth easily. I'm also not ready to switch to wayland yet
> (favorite window manager not available, so many custom configurations I
> came up with over the years etc.), but giving users an easy way to test it
> (or use it, as it's becoming more and more mainstream now) is a good thing.
>
> Having a modern, working, out of the box desktop (read: no custom kernel
> builds, no need to use ports, a laptop is the point of first contact for
> many potential users) is incredibly important for proliferation and
> compared to the total size of binaries 

Re: Procmail got updated!

[Matthias Andree]

Am 20.12.2017 um 06:40 schrieb Eugene Grosbein:
> On 20.12.2017 01:03, Matthias Andree wrote:
>
>> Dear Ted, Eugene,
> [skip]
>
> What happened with old good "Tools, not policy" thing?
>
>

It's simpler than that, no policy involved.

The tool had a hollow head, and broke after several years of banging it,
and the former tool maker told the public it's out of warranty (never
was in due to it being free) and not being fixed any more, and should be
scrapped.


___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Vote: making wayland=on default

[Michael Gmelin]

> On 20. Dec 2017, at 18:50, Chris H  wrote:
> 
> On Wed, 20 Dec 2017 17:13:43 +  said
> 
> On Wed, 20 Dec 2017 16:23:59 + "Johannes Lundberg" 
> said
> 
>> On Wed, Dec 20, 2017 at 4:08 PM, Chris H  wrote:
>> > On Wed, 20 Dec 2017 09:20:20 + "Johannes Lundberg"
>> 
>> > said
>> >
>> >> Hi
>> >>
>> >> I want to suggest that we enable wayland by default. In current state
>> >> having some parts of wayland in ports is basically useless the
>> >> end-users themselves re-build gtk30 and mesa-libs with wayland
>> >> enabled.
>> >>
>> >> libwayland-egl.so from mesa-libs and the extra libraries and headers
>> >> from gtk30 adds like a few KB, a drop in the ocean compared to xorg
>> >> packages. (might be something more that I missed)
>> >>
>> >> Personally I see no reason not to make it default on, even with
>> >> flavors coming up. For any Desktop user (as well as embedded devices
>> >> like IVI-systems and whatnot), Wayland is the future. There's no
>> >> escaping that.
>> >>
>> >> Wayland has been quite usable on FreeBSD for over a year now but
>> >> access to it is limited due to the extra efforts required to use it.
>> >>
>> >> If we are to compare with the other guys, several Linux distros are
>> >> already switching to wayland-based compositors as default window
>> >> server.
>> >>
>> >> What do you think?
>> >
>> > IMHO it's (still) too early. Too much other X(org) related work
>> > still being completed. In fact, I just built a new dev box to
>> > track 12 (CURRENT), and this was the first time I was not required
>> > to pre generate a config file for Xorg. I was only required to
>> > inform /usr/local/etc/X11/xorg.conf.d/nvidia-driver.conf that
>> > the driver was "nvidia", not "nv". Everything work(s|ed) famously.
>> > A real treat. I'm also a bit concerned about the progress (or lack
>> > there of) on network transparency.
>> > I (personally) could conceive it as a KERNEL OPTION, but would not
>> > want to see it in the Default kernel.
>> >
>> > Well, those are *my* thoughts. Because you asked. :-)
>> >
>> > --Chris
>> >
>> Thanks for your feedback!
>> Just to clarify, we're not talking about changing any defaults that
>> would impact or change users' choice of desktop. We only want to
>> enable Wayland compositors as an alternative to X (leaving X as is).
>> This does not break or modify anything existing. It does not force you
>> to do anything differently. It simply adds a couple of libraries that
>> you won't use unless you run Wayland stuff (if you install qt5/gtk30
>> and mesa-libs).
>> The reference to Linux making it default might have been unclear.
>> Since FreeBSD doesn't have a default desktop, it's hard to change. It
>> is and will continue to be up to the end user what they choose to use,
>> we only add more options :)
> Thanks for the informative reply, Johannes.
> So no kernel (libs/extensions)?
> Hmm, gtk3. Why is it not possible to make the Wayland stuff a sub
> package/option? I think this is the preferred track/policy anyway.
> I do this for all the ports I currently maintain. IOW any DE related
> stuff I install, that uses GNOME related material, will pull in gtk3,
> which, as I understand you say, will ultimately pull in Weston,mesa,...
> is that correct? While I understand, you indicate it's only a few Kb.
> I think it's cruft/(unnecessary)overhead. Which, in and of itself
> seems insignificant. But in the "big picture", and over many (100's)
> of builds/installations, is *not* insignificant. This also dismisses
> the security related work, maintaining extra un(used|needed) material.
> I suppose some will think that I'm just being nit-picky. But IMHO
> I'm not. This sort of thing, if overlooked, *does* affect the bottom
> line.
> 
> Thanks again, Johannes!
> 
> P.S. I have nothing against Wayland. I'm just not ready to run it
> on anything "production" related, just yet. :-)
> 
> --Chris
> 

The key is to have it in a state that easy to maintain and allows people to 
install it using pkg install without conflicting with X, so you can switch back 
and forth easily. I'm also not ready to switch to wayland yet (favorite window 
manager not available, so many custom configurations I came up with over the 
years etc.), but giving users an easy way to test it (or use it, as it's 
becoming more and more mainstream now) is a good thing. 

Having a modern, working, out of the box desktop (read: no custom kernel 
builds, no need to use ports, a laptop is the point of first contact for many 
potential users) is incredibly important for proliferation and compared to the 
total size of binaries required to run X, I think the usefulness of providing 
wayland easily outweighs the extra overhead.

Yours,
Michael


>> >>
>> >>
>> >> /Johannes
>> >
>> >
>>> 
> 
> 
> ___
> freebsd-ports@freebsd.org mailing list
> 

Re: some fix needed still

[Walter Schwarzenfeld]

a "little thing"

pkg info portmaster
portmaster-3.17.11_11
Name   : portmaster
Version    : 3.17.11_11

--

portmaster --version

===>>> Version 3.17.10

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Vote: making wayland=on default

[roberthuff]

Yuri writes:

>  It appears that this is the case of fixing of something (xorg)
>  that wasn't/isn't broken in the first place. And if it is
>  considered broken, then how, in which way?

You ask "Is it broken?".
I ask "Is there a better way?"
Think about gcc: it was developed in the mid '80s, and at the
time was pretty dang impressive.  But over time ... "provisional"
hacks to handle less-common hardware or specific software anomalies
became permanently entrenched (or so I am told) even as hardware
changed, and both compiler technology and coding practices improved.
I think of X the same way.


To the list:
I salute X for doing its job, but I have no brand loyalty.  If
something comes along that is some combination of a) more robust, b)
faster, and c) as easy to install/manage I'll switch in a heartbeat.
(Smaller footprint would be nice too.)  Is that Wayland?  Fact not
(yet) in evidence. 
Is Wayland-on-FreeBSD in active development?  If so: where -
other than ports@ - do I go to check the /status quo/?


Respectfully,


Robert Huff
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Vote: making wayland=on default

[Pete Wright]

On 12/20/2017 11:49, n...@arrishq.net wrote:

Hi,

On Wed, 20 Dec 2017, Johannes Lundberg wrote:


Hi

Personally I see no reason not to make it default on, even with
flavors coming up. For any Desktop user (as well as embedded devices
like IVI-systems and whatnot), Wayland is the future. There's no
escaping that.


and why does everyone think a Unix should be run on a desktop only ?


I suspect you might be a little confused - no one is saying that Unix is 
going to be "desktop only" - this is in regards to where graphical 
interfaces is moving for Unix like operating systems in general.
And the "future", well, lot of companies are going to say "Cloud 
first" ;) is the future so the next thing-of-the-day will replace the 
today-thing-of-the-day to add what's required then and we're busy 
replacing things with the newest shiny technology because someone has 
to re-invent the wheel another time.


Personally I don't see much problems rebuilding some ports if I really 
want Wayland, but as long as some apps run on some RasPi's and 
embedded devices without a display using plain X11 is the way and 
Wayland adds just overhead.


how does adding support, by default, for Wayland in some graphical 
binaries add overhead to your system at run time?


no one is saying that this will supplant Xorg, but rather this will make 
it easier for more people in the FreeBSD community to actively test and 
dogfood Wayland.  the alternative is for FreeBSD to continue to be an 
afterthought by freedesktop and Wayland community which doesn't seem 
like a good long-term strategy IMHO.


-pete

--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Vote: making wayland=on default

[Niclas Zeising]

On 12/20/17 10:20, Johannes Lundberg wrote:

Hi

I want to suggest that we enable wayland by default. In current state
having some parts of wayland in ports is basically useless the
end-users themselves re-build gtk30 and mesa-libs with wayland
enabled.

libwayland-egl.so from mesa-libs and the extra libraries and headers
from gtk30 adds like a few KB, a drop in the ocean compared to xorg
packages. (might be something more that I missed)

Personally I see no reason not to make it default on, even with
flavors coming up. For any Desktop user (as well as embedded devices
like IVI-systems and whatnot), Wayland is the future. There's no
escaping that.

Wayland has been quite usable on FreeBSD for over a year now but
access to it is limited due to the extra efforts required to use it.

If we are to compare with the other guys, several Linux distros are
already switching to wayland-based compositors as default window
server.

What do you think?




With my x11@ hat on.

I have no problem with this, as long as the old xorg stuff keeps on 
working, as you've stated they will do.  I do not have time to fix this 
this week, but if you can help me prepare a patch we can perhaps get it 
in after that (beginning of next week, in the days between Christmas and 
new years).  Do you know which ports are affected by this, and have a 
WAYLAND option?  We should also check, probably just in case, if portmgr 
thinks an exp run is needed (I don't think so).


Regards!
--
Niclas
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: some fix needed still

[Stefan Esser]

Am 20.12.17 um 13:08 schrieb Sergio de Almeida Lenzi:
> Version portmaster-3.17.11_9
> when you are in the port directory, the portmaster build wrong path
> /usr/ports/ports instead of /usr/ports
> =
> 
> 
> 
> [root@VMS /usr/ports/x11-themes/kf5-oxygen-icons5]# portmaster 
> 
>   ===>>> No /usr/ports/ports/Mk exists, and no information
>   ===>>> about ports/Mk can be found in /usr/ports/MOVED
> 
> ===>>> No valid installed port, or port directory given
> ===>>> Try portmaster --help

Thank you for the report. Fixed in portmaster-3.17.11_11.

Regards, STefan
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Vote: making wayland=on default

[net]

Hi,

On Wed, 20 Dec 2017, Johannes Lundberg wrote:


Hi

Personally I see no reason not to make it default on, even with
flavors coming up. For any Desktop user (as well as embedded devices
like IVI-systems and whatnot), Wayland is the future. There's no
escaping that.


and why does everyone think a Unix should be run on a desktop only ?
And the "future", well, lot of companies are going to say "Cloud first" 
;) is the future so the next thing-of-the-day will replace the 
today-thing-of-the-day to add what's required then and we're busy 
replacing things with the newest shiny technology because someone has to 
re-invent the wheel another time.


Personally I don't see much problems rebuilding some ports if I really 
want Wayland, but as long as some apps run on some RasPi's and embedded 
devices without a display using plain X11 is the way and Wayland adds just 
overhead.


Sure, that's my usage way and maybe 99% of all others have different 
opions.


---
Sent from my iP..., nah, sent from my coffee machine
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Vote: making wayland=on default

[Ultima]

I support adding wayland support on by default as well. It
still is WIP in several areas one I have not seen mentioned
yet includes nvidia graphics cards. Needing to rebuild
several ports just to test does seem a bit too much though.

Best regards,
Richard Gallamore

On Wed, Dec 20, 2017 at 11:14 AM, Johannes Lundberg 
wrote:

> Hi Yuri
>
> To be clear, we're not transitioning to anything, we're simply adding
> more options. Compare it to adding a new window manager for X, it
> doesn't mean you have to stop using the existing ones...
>
>
> On Wed, Dec 20, 2017 at 5:39 PM, Yuri  wrote:
> > On 12/20/17 01:20, Johannes Lundberg wrote:
> >>
> >> For any Desktop user (as well as embedded devices
> >> like IVI-systems and whatnot), Wayland is the future. There's no
> >> escaping that.
> >
> >
> > Over the history of its development, Wayland could never clearly answer
> the
> > question "What are the benefits of Wayland for the end user?".
> > Additionally, they always advocated the removal of features like
> networked
> > connections, window manager features.
> >
> > It appears that this is the case of fixing of something (xorg) that
> > wasn't/isn't broken in the first place. And if it is considered broken,
> then
> > how, in which way?
> >
> > But you are right, it is a reality that Wayand devs had enough
> horsepower to
> > eventually, after many years, make it and now impose it on everybody, and
> > force it to be a future reality.
> >
> > There are a lot of things that need to be verified that they work:
> x11vnc,
> > the ability to connect to a display remotely, every window manager should
> > work with it, ex. xfce4, dwm.
> >
> > People should be asking the question "What's the benefit of the
> transition
> > to X?". The answer should include the functional benefits to users, not
> just
> > "We need to switch to something called X." What new features or
> improvements
> > will users actually see?
> >
> >
> > Just my 2c.
> > Yuri
> >
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Setting system user home directory

[Stefan Esser]

Am 20.12.17 um 15:12 schrieb Adam Vande More:
> On Sat, Dec 16, 2017 at 2:10 PM, Dmytro Bilokha  wrote:
> 
>> Guys, thanks for your help. I've managed to adjust user's homedir
>> using pkg-install script. Now I'll try to move everything writable
>> from /usr/local to /var (as Miroslav suggested), test and submit the new
>> port version.
> 
> I think you should do what makes sense for your application.  The /var/db
> stuff is not a hard fast rule and it doesn't work well for many
> situations.  Also it's mostly system related DB's that live there.  It's
> not only some java related ports that live mostly under /usr but also
> things like postgres(at least used to).
> 
> IMO, as long as you're not flagrantly violating hier(7), do what is best
> for your port.

For a port that needs quite a large database (password hashes from accounts
that have been leaked), I implemented an option to initialize the application
by downloading the data files after the user had a chance to select a place
for the data (by editing the config file). The default is in /var/db, but the
user may prefer a home directory or some sub-directory of /usr/local/ ...

Regards, STefan

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Setting system user home directory

[Dmytro Bilokha]

On Wed, Dec 20, 2017 at 08:12:52AM -0600, Adam Vande More wrote:

On Sat, Dec 16, 2017 at 2:10 PM, Dmytro Bilokha  wrote:


Guys, thanks for your help. I've managed to adjust user's homedir
using pkg-install script. Now I'll try to move everything writable
from /usr/local to /var (as Miroslav suggested), test and submit the new
port version.



I think you should do what makes sense for your application.  The /var/db
stuff is not a hard fast rule and it doesn't work well for many
situations.  Also it's mostly system related DB's that live there.  It's
not only some java related ports that live mostly under /usr but also
things like postgres(at least used to).

IMO, as long as you're not flagrantly violating hier(7), do what is best
for your port.

--
Adam


Thanks for your response. For me both approaches are fine, application will
work. As far as I understand, which layout is better depends on how the 
system is managed. For now having writable data in /var seems reasonable,

so I'll try it.

--
Dmytro Bilokha
dmy...@posteo.net
+38-050-607-41-43
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Vote: making wayland=on default

[Johannes Lundberg]

Hi Yuri

To be clear, we're not transitioning to anything, we're simply adding
more options. Compare it to adding a new window manager for X, it
doesn't mean you have to stop using the existing ones...


On Wed, Dec 20, 2017 at 5:39 PM, Yuri  wrote:
> On 12/20/17 01:20, Johannes Lundberg wrote:
>>
>> For any Desktop user (as well as embedded devices
>> like IVI-systems and whatnot), Wayland is the future. There's no
>> escaping that.
>
>
> Over the history of its development, Wayland could never clearly answer the
> question "What are the benefits of Wayland for the end user?".
> Additionally, they always advocated the removal of features like networked
> connections, window manager features.
>
> It appears that this is the case of fixing of something (xorg) that
> wasn't/isn't broken in the first place. And if it is considered broken, then
> how, in which way?
>
> But you are right, it is a reality that Wayand devs had enough horsepower to
> eventually, after many years, make it and now impose it on everybody, and
> force it to be a future reality.
>
> There are a lot of things that need to be verified that they work: x11vnc,
> the ability to connect to a display remotely, every window manager should
> work with it, ex. xfce4, dwm.
>
> People should be asking the question "What's the benefit of the transition
> to X?". The answer should include the functional benefits to users, not just
> "We need to switch to something called X." What new features or improvements
> will users actually see?
>
>
> Just my 2c.
> Yuri
>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Vote: making wayland=on default

[Chris H]

On Wed, 20 Dec 2017 17:13:43 +  said

On Wed, 20 Dec 2017 16:23:59 + "Johannes Lundberg" 
said


On Wed, Dec 20, 2017 at 4:08 PM, Chris H  wrote:
> On Wed, 20 Dec 2017 09:20:20 + "Johannes Lundberg"

> said
>
>> Hi
>>
>> I want to suggest that we enable wayland by default. In current state
>> having some parts of wayland in ports is basically useless the
>> end-users themselves re-build gtk30 and mesa-libs with wayland
>> enabled.
>>
>> libwayland-egl.so from mesa-libs and the extra libraries and headers
>> from gtk30 adds like a few KB, a drop in the ocean compared to xorg
>> packages. (might be something more that I missed)
>>
>> Personally I see no reason not to make it default on, even with
>> flavors coming up. For any Desktop user (as well as embedded devices
>> like IVI-systems and whatnot), Wayland is the future. There's no
>> escaping that.
>>
>> Wayland has been quite usable on FreeBSD for over a year now but
>> access to it is limited due to the extra efforts required to use it.
>>
>> If we are to compare with the other guys, several Linux distros are
>> already switching to wayland-based compositors as default window
>> server.
>>
>> What do you think?
>
> IMHO it's (still) too early. Too much other X(org) related work
> still being completed. In fact, I just built a new dev box to
> track 12 (CURRENT), and this was the first time I was not required
> to pre generate a config file for Xorg. I was only required to
> inform /usr/local/etc/X11/xorg.conf.d/nvidia-driver.conf that
> the driver was "nvidia", not "nv". Everything work(s|ed) famously.
> A real treat. I'm also a bit concerned about the progress (or lack
> there of) on network transparency.
> I (personally) could conceive it as a KERNEL OPTION, but would not
> want to see it in the Default kernel.
>
> Well, those are *my* thoughts. Because you asked. :-)
>
> --Chris
>

Thanks for your feedback!

Just to clarify, we're not talking about changing any defaults that
would impact or change users' choice of desktop. We only want to
enable Wayland compositors as an alternative to X (leaving X as is).

This does not break or modify anything existing. It does not force you
to do anything differently. It simply adds a couple of libraries that
you won't use unless you run Wayland stuff (if you install qt5/gtk30
and mesa-libs).

The reference to Linux making it default might have been unclear.
Since FreeBSD doesn't have a default desktop, it's hard to change. It
is and will continue to be up to the end user what they choose to use,
we only add more options :)

Thanks for the informative reply, Johannes.
So no kernel (libs/extensions)?
Hmm, gtk3. Why is it not possible to make the Wayland stuff a sub
package/option? I think this is the preferred track/policy anyway.
I do this for all the ports I currently maintain. IOW any DE related
stuff I install, that uses GNOME related material, will pull in gtk3,
which, as I understand you say, will ultimately pull in Weston,mesa,...
is that correct? While I understand, you indicate it's only a few Kb.
I think it's cruft/(unnecessary)overhead. Which, in and of itself
seems insignificant. But in the "big picture", and over many (100's)
of builds/installations, is *not* insignificant. This also dismisses
the security related work, maintaining extra un(used|needed) material.
I suppose some will think that I'm just being nit-picky. But IMHO
I'm not. This sort of thing, if overlooked, *does* affect the bottom
line.

Thanks again, Johannes!

P.S. I have nothing against Wayland. I'm just not ready to run it
on anything "production" related, just yet. :-)

--Chris



>>
>>
>> /Johannes
>
>





___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Vote: making wayland=on default

[Yuri]

On 12/20/17 01:20, Johannes Lundberg wrote:

For any Desktop user (as well as embedded devices
like IVI-systems and whatnot), Wayland is the future. There's no
escaping that.


Over the history of its development, Wayland could never clearly answer 
the question "What are the benefits of Wayland for the end user?".
Additionally, they always advocated the removal of features like 
networked connections, window manager features.


It appears that this is the case of fixing of something (xorg) that 
wasn't/isn't broken in the first place. And if it is considered broken, 
then how, in which way?


But you are right, it is a reality that Wayand devs had enough 
horsepower to eventually, after many years, make it and now impose it on 
everybody, and force it to be a future reality.


There are a lot of things that need to be verified that they work: 
x11vnc, the ability to connect to a display remotely, every window 
manager should work with it, ex. xfce4, dwm.


People should be asking the question "What's the benefit of the 
transition to X?". The answer should include the functional benefits to 
users, not just "We need to switch to something called X." What new 
features or improvements will users actually see?



Just my 2c.
Yuri

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

re: Vote: making wayland=on default

[Sid]

I would rather see smaller window managers work with Wayland first.
If gtk2 and gtk3 want to enable it fine. But gtk2 and gtk3 shouldn't be mixed 
in with Wayland by default, which is what will happen if it is enabled before 
it gets a foothold with other window managers.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Vote: making wayland=on default

[blubee blubeeme]

On Thu, Dec 21, 2017 at 12:23 AM, Johannes Lundberg 
wrote:

> On Wed, Dec 20, 2017 at 4:08 PM, Chris H  wrote:
> > On Wed, 20 Dec 2017 09:20:20 + "Johannes Lundberg" <
> johal...@gmail.com>
> > said
> >
> >> Hi
> >>
> >> I want to suggest that we enable wayland by default. In current state
> >> having some parts of wayland in ports is basically useless the
> >> end-users themselves re-build gtk30 and mesa-libs with wayland
> >> enabled.
> >>
> >> libwayland-egl.so from mesa-libs and the extra libraries and headers
> >> from gtk30 adds like a few KB, a drop in the ocean compared to xorg
> >> packages. (might be something more that I missed)
> >>
> >> Personally I see no reason not to make it default on, even with
> >> flavors coming up. For any Desktop user (as well as embedded devices
> >> like IVI-systems and whatnot), Wayland is the future. There's no
> >> escaping that.
> >>
> >> Wayland has been quite usable on FreeBSD for over a year now but
> >> access to it is limited due to the extra efforts required to use it.
> >>
> >> If we are to compare with the other guys, several Linux distros are
> >> already switching to wayland-based compositors as default window
> >> server.
> >>
> >> What do you think?
> >
> > IMHO it's (still) too early. Too much other X(org) related work
> > still being completed. In fact, I just built a new dev box to
> > track 12 (CURRENT), and this was the first time I was not required
> > to pre generate a config file for Xorg. I was only required to
> > inform /usr/local/etc/X11/xorg.conf.d/nvidia-driver.conf that
> > the driver was "nvidia", not "nv". Everything work(s|ed) famously.
> > A real treat. I'm also a bit concerned about the progress (or lack
> > there of) on network transparency.
> > I (personally) could conceive it as a KERNEL OPTION, but would not
> > want to see it in the Default kernel.
> >
> > Well, those are *my* thoughts. Because you asked. :-)
> >
> > --Chris
> >
>
> Thanks for your feedback!
>
> Just to clarify, we're not talking about changing any defaults that
> would impact or change users' choice of desktop. We only want to
> enable Wayland compositors as an alternative to X (leaving X as is).
>
> This does not break or modify anything existing. It does not force you
> to do anything differently. It simply adds a couple of libraries that
> you won't use unless you run Wayland stuff (if you install qt5/gtk30
> and mesa-libs).
>
> The reference to Linux making it default might have been unclear.
> Since FreeBSD doesn't have a default desktop, it's hard to change. It
> is and will continue to be up to the end user what they choose to use,
> we only add more options :)
>
> >>
> >>
> >> /Johannes
> >
> >
> >
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
>

I'd +1 to this
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Vote: making wayland=on default

[Johannes Lundberg]

On Wed, Dec 20, 2017 at 4:08 PM, Chris H  wrote:
> On Wed, 20 Dec 2017 09:20:20 + "Johannes Lundberg" 
> said
>
>> Hi
>>
>> I want to suggest that we enable wayland by default. In current state
>> having some parts of wayland in ports is basically useless the
>> end-users themselves re-build gtk30 and mesa-libs with wayland
>> enabled.
>>
>> libwayland-egl.so from mesa-libs and the extra libraries and headers
>> from gtk30 adds like a few KB, a drop in the ocean compared to xorg
>> packages. (might be something more that I missed)
>>
>> Personally I see no reason not to make it default on, even with
>> flavors coming up. For any Desktop user (as well as embedded devices
>> like IVI-systems and whatnot), Wayland is the future. There's no
>> escaping that.
>>
>> Wayland has been quite usable on FreeBSD for over a year now but
>> access to it is limited due to the extra efforts required to use it.
>>
>> If we are to compare with the other guys, several Linux distros are
>> already switching to wayland-based compositors as default window
>> server.
>>
>> What do you think?
>
> IMHO it's (still) too early. Too much other X(org) related work
> still being completed. In fact, I just built a new dev box to
> track 12 (CURRENT), and this was the first time I was not required
> to pre generate a config file for Xorg. I was only required to
> inform /usr/local/etc/X11/xorg.conf.d/nvidia-driver.conf that
> the driver was "nvidia", not "nv". Everything work(s|ed) famously.
> A real treat. I'm also a bit concerned about the progress (or lack
> there of) on network transparency.
> I (personally) could conceive it as a KERNEL OPTION, but would not
> want to see it in the Default kernel.
>
> Well, those are *my* thoughts. Because you asked. :-)
>
> --Chris
>

Thanks for your feedback!

Just to clarify, we're not talking about changing any defaults that
would impact or change users' choice of desktop. We only want to
enable Wayland compositors as an alternative to X (leaving X as is).

This does not break or modify anything existing. It does not force you
to do anything differently. It simply adds a couple of libraries that
you won't use unless you run Wayland stuff (if you install qt5/gtk30
and mesa-libs).

The reference to Linux making it default might have been unclear.
Since FreeBSD doesn't have a default desktop, it's hard to change. It
is and will continue to be up to the end user what they choose to use,
we only add more options :)

>>
>>
>> /Johannes
>
>
>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Vote: making wayland=on default

[Chris H]

On Wed, 20 Dec 2017 09:20:20 + "Johannes Lundberg"  said


Hi

I want to suggest that we enable wayland by default. In current state
having some parts of wayland in ports is basically useless the
end-users themselves re-build gtk30 and mesa-libs with wayland
enabled.

libwayland-egl.so from mesa-libs and the extra libraries and headers
from gtk30 adds like a few KB, a drop in the ocean compared to xorg
packages. (might be something more that I missed)

Personally I see no reason not to make it default on, even with
flavors coming up. For any Desktop user (as well as embedded devices
like IVI-systems and whatnot), Wayland is the future. There's no
escaping that.

Wayland has been quite usable on FreeBSD for over a year now but
access to it is limited due to the extra efforts required to use it.

If we are to compare with the other guys, several Linux distros are
already switching to wayland-based compositors as default window
server.

What do you think?

IMHO it's (still) too early. Too much other X(org) related work
still being completed. In fact, I just built a new dev box to
track 12 (CURRENT), and this was the first time I was not required
to pre generate a config file for Xorg. I was only required to
inform /usr/local/etc/X11/xorg.conf.d/nvidia-driver.conf that
the driver was "nvidia", not "nv". Everything work(s|ed) famously.
A real treat. I'm also a bit concerned about the progress (or lack
there of) on network transparency.
I (personally) could conceive it as a KERNEL OPTION, but would not
want to see it in the Default kernel.

Well, those are *my* thoughts. Because you asked. :-)

--Chris




/Johannes



___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Setting system user home directory

[Miroslav Lachman]

Adam Vande More wrote on 2017/12/20 15:12:

On Sat, Dec 16, 2017 at 2:10 PM, Dmytro Bilokha  wrote:


Guys, thanks for your help. I've managed to adjust user's homedir
using pkg-install script. Now I'll try to move everything writable
from /usr/local to /var (as Miroslav suggested), test and submit the new
port version.



I think you should do what makes sense for your application.  The /var/db
stuff is not a hard fast rule and it doesn't work well for many
situations.  Also it's mostly system related DB's that live there.  It's
not only some java related ports that live mostly under /usr but also
things like postgres(at least used to).


Databases (Postgres) are mess. MySQL, CouchDB, Elasticsearch and others 
are using /var/db prefix, PostgreSQL and some others are using 
/usr/local. It is very inconsistent...


Miroslav Lachman
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Setting system user home directory

[Adam Vande More]

On Sat, Dec 16, 2017 at 2:10 PM, Dmytro Bilokha  wrote:

> Guys, thanks for your help. I've managed to adjust user's homedir
> using pkg-install script. Now I'll try to move everything writable
> from /usr/local to /var (as Miroslav suggested), test and submit the new
> port version.


I think you should do what makes sense for your application.  The /var/db
stuff is not a hard fast rule and it doesn't work well for many
situations.  Also it's mostly system related DB's that live there.  It's
not only some java related ports that live mostly under /usr but also
things like postgres(at least used to).

IMO, as long as you're not flagrantly violating hier(7), do what is best
for your port.

-- 
Adam
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Vote: making wayland=on default

[Johannes Lundberg]

On Wed, Dec 20, 2017 at 1:13 PM, antranigv  wrote:
> Hi!
>
> Trying to understand the changes that would be made by making wayland=on
> by default.
>
> I see a lot of people moving to Wayland from X, but if we do wayland=on,
> what will this mean to Xorg people? from the first thing I got is larger
> binaries for gtk and Qt. anything else that will happen? please fill me
> in, I'd love to vote wayland=on by default if people think it's the
> future, but without hurting people who still use and like Xorg.
>

Hi!

Yes, libraries that are common for X and Wayland like mesa-libs, qt5
and gtk30 will get a bit bigger in order to enable Wayland.
This is completely transparent to X users and does not affect
X-related stuff in anyway.

Using Wayland compositors like x11-wm/sway or x11-wm/weston is still
completely optional and can they can co-exist with any X server and
X11 window manager.
Simply run "startx" if you wanna run X or "weston-launch" if you wanna
run weston. Any X client should run fine in Weston (requires the pkg
"xwayland"), however the opposite is not true.


> Thanks in advance,
>
> antranigv
> https://antranigv.am/|PGP Key ID : 0xDAB81456
> /* do one thing and do it well */
>
> On 12/20/2017 01:20 PM, Johannes Lundberg wrote:
>> Hi
>>
>> I want to suggest that we enable wayland by default. In current state
>> having some parts of wayland in ports is basically useless the
>> end-users themselves re-build gtk30 and mesa-libs with wayland
>> enabled.
>>
>> libwayland-egl.so from mesa-libs and the extra libraries and headers
>> from gtk30 adds like a few KB, a drop in the ocean compared to xorg
>> packages. (might be something more that I missed)
>>
>> Personally I see no reason not to make it default on, even with
>> flavors coming up. For any Desktop user (as well as embedded devices
>> like IVI-systems and whatnot), Wayland is the future. There's no
>> escaping that.
>>
>> Wayland has been quite usable on FreeBSD for over a year now but
>> access to it is limited due to the extra efforts required to use it.
>>
>> If we are to compare with the other guys, several Linux distros are
>> already switching to wayland-based compositors as default window
>> server.
>>
>> What do you think?
>>
>>
>> /Johannes
>> ___
>> freebsd-ports@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
>> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
>>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Vote: making wayland=on default

[Tommi Pernila]

Looking forward to testing Wayland more on FreeBSD.

So yes please!


-Tommi

On Wed, Dec 20, 2017 at 2:56 PM, Michael Gmelin  wrote:

>
>
> > On 20. Dec 2017, at 13:32, Baptiste Daroussin  wrote:
> >
> >> On Wed, Dec 20, 2017 at 09:20:20AM +, Johannes Lundberg wrote:
> >> Hi
> >>
> >> I want to suggest that we enable wayland by default. In current state
> >> having some parts of wayland in ports is basically useless the
> >> end-users themselves re-build gtk30 and mesa-libs with wayland
> >> enabled.
> >>
> >> libwayland-egl.so from mesa-libs and the extra libraries and headers
> >> from gtk30 adds like a few KB, a drop in the ocean compared to xorg
> >> packages. (might be something more that I missed)
> >>
> >> Personally I see no reason not to make it default on, even with
> >> flavors coming up. For any Desktop user (as well as embedded devices
> >> like IVI-systems and whatnot), Wayland is the future. There's no
> >> escaping that.
> >>
> >> Wayland has been quite usable on FreeBSD for over a year now but
> >> access to it is limited due to the extra efforts required to use it.
> >>
> >> If we are to compare with the other guys, several Linux distros are
> >> already switching to wayland-based compositors as default window
> >> server.
> >>
> >> What do you think?
> >>
> >
> > I agree on that, we should activate wayland everywhere by defualt, as it
> does
> > not prevent at all from having a fully fonctionnal regular X working as
> well.
> >
> > All wayland option should be on, and this as nothing to do with flavors
> :)
> >
> > Please do it :)
> >
> > Best regards,
> > Bapt
>
> I add my "vote" from the X11 list: Yes please, I had exactly that problem
> yesterday.
>
> Best,
> Michael
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Vote: making wayland=on default

[Michael Gmelin]

> On 20. Dec 2017, at 13:32, Baptiste Daroussin  wrote:
> 
>> On Wed, Dec 20, 2017 at 09:20:20AM +, Johannes Lundberg wrote:
>> Hi
>> 
>> I want to suggest that we enable wayland by default. In current state
>> having some parts of wayland in ports is basically useless the
>> end-users themselves re-build gtk30 and mesa-libs with wayland
>> enabled.
>> 
>> libwayland-egl.so from mesa-libs and the extra libraries and headers
>> from gtk30 adds like a few KB, a drop in the ocean compared to xorg
>> packages. (might be something more that I missed)
>> 
>> Personally I see no reason not to make it default on, even with
>> flavors coming up. For any Desktop user (as well as embedded devices
>> like IVI-systems and whatnot), Wayland is the future. There's no
>> escaping that.
>> 
>> Wayland has been quite usable on FreeBSD for over a year now but
>> access to it is limited due to the extra efforts required to use it.
>> 
>> If we are to compare with the other guys, several Linux distros are
>> already switching to wayland-based compositors as default window
>> server.
>> 
>> What do you think?
>> 
> 
> I agree on that, we should activate wayland everywhere by defualt, as it does
> not prevent at all from having a fully fonctionnal regular X working as well.
> 
> All wayland option should be on, and this as nothing to do with flavors :)
> 
> Please do it :)
> 
> Best regards,
> Bapt

I add my "vote" from the X11 list: Yes please, I had exactly that problem 
yesterday.

Best,
Michael
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Vote: making wayland=on default

[Baptiste Daroussin]

On Wed, Dec 20, 2017 at 09:20:20AM +, Johannes Lundberg wrote:
> Hi
> 
> I want to suggest that we enable wayland by default. In current state
> having some parts of wayland in ports is basically useless the
> end-users themselves re-build gtk30 and mesa-libs with wayland
> enabled.
> 
> libwayland-egl.so from mesa-libs and the extra libraries and headers
> from gtk30 adds like a few KB, a drop in the ocean compared to xorg
> packages. (might be something more that I missed)
> 
> Personally I see no reason not to make it default on, even with
> flavors coming up. For any Desktop user (as well as embedded devices
> like IVI-systems and whatnot), Wayland is the future. There's no
> escaping that.
> 
> Wayland has been quite usable on FreeBSD for over a year now but
> access to it is limited due to the extra efforts required to use it.
> 
> If we are to compare with the other guys, several Linux distros are
> already switching to wayland-based compositors as default window
> server.
> 
> What do you think?
> 

I agree on that, we should activate wayland everywhere by defualt, as it does
not prevent at all from having a fully fonctionnal regular X working as well.

All wayland option should be on, and this as nothing to do with flavors :)

Please do it :)

Best regards,
Bapt


signature.asc
Description: PGP signature

some fix needed still

[Sergio de Almeida Lenzi]

Version portmaster-3.17.11_9
when you are in the port directory, the portmaster build wrong path
/usr/ports/ports instead of /usr/ports
=



[root@VMS /usr/ports/x11-themes/kf5-oxygen-icons5]# portmaster 

===>>> No /usr/ports/ports/Mk exists, and no information
===>>> about ports/Mk can be found in /usr/ports/MOVED

===>>> No valid installed port, or port directory given
===>>> Try portmaster --help

[root@VMS /usr/ports/x11-themes/kf5-oxygen-icons5]# 

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Vote: making wayland=on default

[Johannes Lundberg]

>
> The normal scenario would be for FreeBSD to wait until other distros have
> throughly vetted the application/protocol/device/other and then consider
> adding it to the basic FreeBSD structure. Unfortunately, by that time the
> target has moved on and FreeBSD is as all too often late to the party.
>

Just to be clear. We're not talking about replacing X as the default
choice (if there's such a thing on FreeBSD). We simply want to make
Wayland more accessible to people who want to try it out or make it
their default desktop.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Vote: making wayland=on default

[Carmel NY]

On Wed, 20 Dec 2017 09:20:20 +, Johannes Lundberg stated:

>Hi
>
>I want to suggest that we enable wayland by default. In current state
>having some parts of wayland in ports is basically useless the
>end-users themselves re-build gtk30 and mesa-libs with wayland
>enabled.
>
>libwayland-egl.so from mesa-libs and the extra libraries and headers
>from gtk30 adds like a few KB, a drop in the ocean compared to xorg
>packages. (might be something more that I missed)
>
>Personally I see no reason not to make it default on, even with
>flavors coming up. For any Desktop user (as well as embedded devices
>like IVI-systems and whatnot), Wayland is the future. There's no
>escaping that.
>
>Wayland has been quite usable on FreeBSD for over a year now but
>access to it is limited due to the extra efforts required to use it.
>
>If we are to compare with the other guys, several Linux distros are
>already switching to wayland-based compositors as default window
>server.
>
>What do you think?

The normal scenario would be for FreeBSD to wait until other distros have
throughly vetted the application/protocol/device/other and then consider
adding it to the basic FreeBSD structure. Unfortunately, by that time the
target has moved on and FreeBSD is as all too often late to the party.

I am considering firing up an older PC I have laying around,install the
latest version of FreeBSD and then trying out a few application that are
presently not available or like "wayland" need some massaging. It all depends
if I can actually get some free time. Wayland does look promising though, I
hate "X".

-- 
Carmel
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224205

[Rodrigo Osorio]

On 12/20/17 11:49, Stefan Lambrev wrote:

Hi,

Can a port commiter look into this -
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224205 ?
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


I take it.

Cheers
- rodrigo
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224205

[Stefan Lambrev]

Hi,

Can a port commiter look into this -
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224205 ?
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Canberra

[blubee blubeeme]

On Wed, Dec 20, 2017 at 5:27 PM, Sid  wrote:

> The problem with libcanberra is around pulseaudio and gstreamer. It is
> also with how gtk, a Visual Graphical toolkit, is mixed in with an Audio
> application.
>
> I didn't say you didn't know about it, I was just putting it out there.
> They've done a good job of cleaning up and fixing ALSA to work on top of
> OSS: the most obvious problems with that are fixed. Pulseaudio hasn't been
> cleaned up, which it is better for applications to avoid it all together,
> and I don't know if Pulseaudio is worth fixing.
>
> It is really a travesty that a simple program that plays simple sounds
> like "Ding!" has to be this complicated, when OSS, and sndio work, and even
> when something as complicated as ALSA was simplified enough to work
> efficiently on top of OSS.
>
> "When devs take the easiest path..." This is the Linuxism route, to pile
> on. I don't even consider that the easiest path, a lazy path instead,
> considering its usual outcome, of requiring hours to compile something
> which should compile in 5 minutes. FreeBSD and other BSD's have largely
> simplified many of these issues, recently.
>
> > blubee blubeeme; Wed Dec 20 07:26:43 UTC 2017
> > I know this.
> > These are just some of the reasons why I wanted to make sure that the
> OSS in FreeBSD is actually up to snuff
> because working on fixing issues like these the easiest route is; just use
> ALSA or some such crap which is
> unacceptable to me if it can use OSS.
>
> > When devs take the easiest path then instead of fixing the root issues,
> problems are compounded;
> just like the example you gave of layering pulse on top of gstreamer,
> those "solutions" are brittle and will
> inevitably break.
>
> > I'd like to have a solid foundation and build from there, not be
> constantly trying to re-implement the wheel.
>
> > This is just one OPTIONAL dependency for a piece of software that I want
> to port and this software isn't
> even audio related, it's an ibus plugin.
>
> Sid; Wed Dec 20 07:04:08 UTC 2017
>
> >> According to http://0pointer.de/lennart/projects/libcanberra/#status[
> http://0pointer.de/lennart/projects/libcanberra/#status] updated
> September 2012
>
> >> "libcanberra is mostly feature complete. For now however it includes
> backends only for ALSA, PulseAudio, OSS and GStreamer."
>
> >> "The OSS driver is incomplete: only sound files that are in a format
> natively understood by the sound card are supported. If the sample type,
> channel map or sampling rate of the sound file are not supported by the
> sound card no automatic conversion will take place and the file will not be
> played. Also note that the OSS backend is most likely incompatible with
> OSS4, due to subtle incompatibilities between OSS4 and the OSS 3.x."
>
> >> "It is recommended to always take the "shortest" path from libcanberra
> to the audio device. I.e. don't use the GStreamer plugin if libcanberra
> supports the final output target natively. Besides being more
> resource-friendly and less error-prone, some advanced functionality might
> get lost with each layer you add to your stack. For example: while you
> could use libcanberra's Gstreamer backend to output to a PulseAudio server
> this will not be able to make use of sample cacheing or will be able to
> attach additional meta data to the sounds played, which might be necessary
> for effects like positional event sounds."
>
> I'll work on it but let me get the port in the tree first, then I can
refine it.

Just as i've done with my previous ports.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Canberra

[Sid]

The problem with libcanberra is around pulseaudio and gstreamer. It is also 
with how gtk, a Visual Graphical toolkit, is mixed in with an Audio application.

I didn't say you didn't know about it, I was just putting it out there. They've 
done a good job of cleaning up and fixing ALSA to work on top of OSS: the most 
obvious problems with that are fixed. Pulseaudio hasn't been cleaned up, which 
it is better for applications to avoid it all together, and I don't know if 
Pulseaudio is worth fixing.

It is really a travesty that a simple program that plays simple sounds like 
"Ding!" has to be this complicated, when OSS, and sndio work, and even when 
something as complicated as ALSA was simplified enough to work efficiently on 
top of OSS.

"When devs take the easiest path..." This is the Linuxism route, to pile on. I 
don't even consider that the easiest path, a lazy path instead, considering its 
usual outcome, of requiring hours to compile something which should compile in 
5 minutes. FreeBSD and other BSD's have largely simplified many of these 
issues, recently.

> blubee blubeeme; Wed Dec 20 07:26:43 UTC 2017
> I know this.
> These are just some of the reasons why I wanted to make sure that the OSS in 
> FreeBSD is actually up to snuff
because working on fixing issues like these the easiest route is; just use ALSA 
or some such crap which is
unacceptable to me if it can use OSS.
 
> When devs take the easiest path then instead of fixing the root issues, 
> problems are compounded;
just like the example you gave of layering pulse on top of gstreamer, those 
"solutions" are brittle and will
inevitably break.

> I'd like to have a solid foundation and build from there, not be constantly 
> trying to re-implement the wheel.
 
> This is just one OPTIONAL dependency for a piece of software that I want to 
> port and this software isn't
even audio related, it's an ibus plugin.

Sid; Wed Dec 20 07:04:08 UTC 2017

>> According to 
>> http://0pointer.de/lennart/projects/libcanberra/#status[http://0pointer.de/lennart/projects/libcanberra/#status]
>>  updated September 2012

>> "libcanberra is mostly feature complete. For now however it includes 
>> backends only for ALSA, PulseAudio, OSS and GStreamer."

>> "The OSS driver is incomplete: only sound files that are in a format 
>> natively understood by the sound card are supported. If the sample type, 
>> channel map or sampling rate of the sound file are not supported by the 
>> sound card no automatic conversion will take place and the file will not be 
>> played. Also note that the OSS backend is most likely incompatible with 
>> OSS4, due to subtle incompatibilities between OSS4 and the OSS 3.x."

>> "It is recommended to always take the "shortest" path from libcanberra to 
>> the audio device. I.e. don't use the GStreamer plugin if libcanberra 
>> supports the final output target natively. Besides being more 
>> resource-friendly and less error-prone, some advanced functionality might 
>> get lost with each layer you add to your stack. For example: while you could 
>> use libcanberra's Gstreamer backend to output to a PulseAudio server this 
>> will not be able to make use of sample cacheing or will be able to attach 
>> additional meta data to the sounds played, which might be necessary for 
>> effects like positional event sounds."

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Vote: making wayland=on default

[Johannes Lundberg]

Hi

I want to suggest that we enable wayland by default. In current state
having some parts of wayland in ports is basically useless the
end-users themselves re-build gtk30 and mesa-libs with wayland
enabled.

libwayland-egl.so from mesa-libs and the extra libraries and headers
from gtk30 adds like a few KB, a drop in the ocean compared to xorg
packages. (might be something more that I missed)

Personally I see no reason not to make it default on, even with
flavors coming up. For any Desktop user (as well as embedded devices
like IVI-systems and whatnot), Wayland is the future. There's no
escaping that.

Wayland has been quite usable on FreeBSD for over a year now but
access to it is limited due to the extra efforts required to use it.

If we are to compare with the other guys, several Linux distros are
already switching to wayland-based compositors as default window
server.

What do you think?


/Johannes
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"