Re: Again, flavors or options?

2017-12-21 Thread Mathieu Arnold 
Le 21/12/2017 à 03:16, Yuri a écrit :
> Do you think flavors are a good fit for this task?

Flavors is for when a port needs to be built differently multiple times.
From what you are saying, this can be built once and splitted up later,
this is subpackages. For now, you should use options, with what most
people need as the default options. You could do slave ports, but I
don't see the point.


-- 
Mathieu Arnold




signature.asc
Description: OpenPGP digital signature

Re: Vote: making wayland=on default

2017-12-21 Thread Johannes Lundberg 
Thanks for the explanation, Kevin.

I should have included more background information about what Wayland
is and what turning it on by default means in more detail.
Again to clarify, enabling Wayland by default does not change
anything, it simply adds more options. Similar to adding a X11 window
manager, you have the option to use it but don't have to...


On Thu, Dec 21, 2017 at 12:27 AM, Kevin Oberman  wrote:
> 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 year

Re: Again, flavors or options?

2017-12-21 Thread Yuri 

On 12/21/17 00:17, Mathieu Arnold wrote:

Flavors is for when a port needs to be built differently multiple times.
 From what you are saying, this can be built once and splitted up later,
this is subpackages. For now, you should use options, with what most
people need as the default options. You could do slave ports, but I
don't see the point.



Is there an ETA for sub-packages?


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: Again, flavors or options?

2017-12-21 Thread Mathieu Arnold 
Le 21/12/2017 à 09:55, Yuri a écrit :
> On 12/21/17 00:17, Mathieu Arnold wrote:
>> Flavors is for when a port needs to be built differently multiple times.
>>  From what you are saying, this can be built once and splitted up later,
>> this is subpackages. For now, you should use options, with what most
>> people need as the default options. You could do slave ports, but I
>> don't see the point.
>
>
> Is there an ETA for sub-packages?

When it is done.

-- 
Mathieu Arnold

___
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!

2017-12-21 Thread Eugene Grosbein 
On 21.12.2017 07:35, Kevin Oberman wrote:

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

+1

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

___
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!

2017-12-21 Thread Eugene Grosbein 
On 21.12.2017 11:35, Ted Hatfield wrote:

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

There is nothing to stop. We have plenty software working but maintained by 
nobody
and it is not a big deal. Let it work until it really break. No dates needed.

___
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!

2017-12-21 Thread Eugene Grosbein 
On 21.12.2017 14:24, Matthias Andree wrote:

 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.

We do not "ship" procmail. It is not part of FreeBSD.
It is third-party software packaged for user's convenience without any 
guarantee.

So, you demand we stop shipping any unmaintained software with our Ports & 
Packages?
Absence of CVEs means nothing and almost any non-trivial software has bugs 
(axiom).

___
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

2017-12-21 Thread Guido Falsi 
On 12/20/2017 21:47, Niclas Zeising wrote:
> 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).
> 

I recently added a WAYLAND option to the multimedia/libva port I
maintain. I set it to off by default but that can be changes without
problems.

-- 
Guido Falsi 
___
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

2017-12-21 Thread Niclas Zeising 

On 12/20/17 23:21, roberth...@rcn.com wrote:


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/?



Wayland and xwayland is part of the x11@ umbrella.  The mailing list 
used is freebsd-...@freebsd.org

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"

FreeBSD ports you maintain which are out of date

2017-12-21 Thread portscout 
Dear port maintainer,

The portscout new distfile checker has detected that one or more of your
ports appears to be out of date. Please take the opportunity to check
each of the ports listed below, and if possible and appropriate,
submit/commit an update. If any ports have already been updated, you can
safely ignore the entry.

You will not be e-mailed again for any of the port/version combinations
below.

Full details can be found at the following URL:
http://portscout.freebsd.org/po...@freebsd.org.html


Port| Current version | New version
+-+
audio/rosegarden| 17.04   | 17.12
+-+


If any of the above results are invalid, please check the following page
for details on how to improve portscout's detection and selection of
distfiles on a per-port basis:

http://portscout.freebsd.org/info/portscout-portconfig.txt

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

2017-12-21 Thread Andrea Venturoli 

On 12/20/17 23:21, roberth...@rcn.com wrote:

First off, I'm not trying to bring up any flame... my questions are real 
and I'd really welcome good answers.





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?


I have the same questions Yuri has... I've always seen Wayland 
enthusiasts saying they can't stand X11 no more, but I've never seen 
them explain what's wrong with it.
N.B. I'm not implying nothing is wrong, I just wish they explained their 
point.





You ask "Is it broken?".
I ask "Is there a better way?"
...
I think of X the same way.


Fine, I agree with this.
So, in what ways is Wayland better?





That said, I have nothing against having Wayland support by default.
I'm still ssh-ing into remote boxes to run graphical applications and I 
don't want to see this go away... but I read this is not going to happen 
(yet?), so it's fine to me.




 bye
av.
___
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

2017-12-21 Thread blubee blubeeme 
On Thu, Dec 21, 2017 at 8:37 AM, Sid  wrote:

> > 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.
>
I'll look at the libcanberra OSS backend and see if I get get the changes
upstream then the libcanberra maintainer can update the port.
___
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: FLAVOR for Qt4 and Qt5 (was Re: Flavor or not for this port?)

2017-12-21 Thread Rainer Hurling 

Hi Loïc,

Am 19.12.2017 um 20:48 schrieb L.Bartoletti:

Hi,

Here's my WIP

https://gitlab.com/lbartoletti/freebsd_ports/tree/master/qwt6


Looks interesting to me.

Do we agree, that the package should be named qwt6-qt[45], and not 
qwt-qt[45]?


And shouldn't PORTNAME better be named qwt6 instead of qwt. If so, the 
port has to handle with DISTNAME in some way to fetch a file named qwt-.


At least, the actual naming brings some problems, for example if one 
tries to fetch the distfile


make distclean
make FLAVOR=qt4 fetch

make distclean
make FLAVOR=qt5 fetch


QWT is licensed under Qwt 1.0, which is a LGPL with three execptions[1]. 
There is no definition for this license in Mk/bsd.license.db.mk until 
now. I don't know, what is the right way to define this 'unknown' 
license in the port.



Again, many thanks for your work on this port.
Best wishes,
Rainer

[1] http://qwt.sourceforge.net/qwtlicense.html




Regards


On 18.12.2017 22:57, L.Bartoletti wrote:

Hi Rainer,

I have made a try with subpackages with success, but I think it's 
better with flavor (like on OpenBSD).


So, I have started to create flavors for this port.

For now, I success for qt4 but not yet for qt5.

Extract from my Makefile in progress:

FLAVORS=    qt5 qt4
FLAVOR?=

.if ${FLAVOR:Mqt5}
PKGNAMESUFFIX=    -qt5
USE_QT5=    widgets gui core designer gui opengl svg xml buildtools 
printsupport concurrent

PLIST=        ${PKGDIR}/pkg-plist.qt5
PLIST_SUB+=    QT_MKSPECDIR=lib/qt5/mkspecs
DOCSDIR=    ${PREFIX}/share/doc/qwt6-qt5
.else
PKGNAMESUFFIX=    -qt4
USE_QT4=     corelib gui opengl svg xml moc_build
PLIST=        ${PKGDIR}/pkg-plist.qt4
PLIST_SUB+=    QT_MKSPECDIR=lib/qt4/mkspecs
DOCSDIR=    ${PREFIX}/share/doc/qwt6-qt4
.endif

Ther error for qt5:

qwt-qt5-6.1.3 can't be installed: different Qt versions specified via
USE_QT[4 5].

Regards.

On 17.12.2017 10:12, Rainer Hurling wrote:

Am 02.11.2017 um 07:41 schrieb Rainer Hurling:

Am 02.11.2017 um 07:13 schrieb L.Bartoletti:

Hi,

I want to take x11-toolkits/qwt{5,6}-*

Both are built for Qt4. I especially need qwt6 for Qt5. Since we have
flavors. Is it better to add a Qt5 flavor for Qwt6 or simply add a
x11-toolkits/qwt6-qt5 (like security/qtkeychain-qt{4,5} ?)

Thanks.

Regards.

Loïc


Hi Loïc,

Thanks for your dedication. I am very interested in a qwt6-qt5 port,
since it is needed for the upcoming version 3.0 of graphics/qgis :)

Sorry for my inexperience. In case of adding the qwt6-qt5 as a flavor,
should we expect any change or restriction in the way, it would be used
as a dependency of e.g. QGIS?

Thanks for any answer.

Best wishes,
Rainer

Hi Loïc,

Again about x11-toolkits/qwt{5,6}-*

Now, that we have our first real world experiences with FLAVORS, it
seems to be functional to use flavors in this context. Something like

x11-toolkits/qwt6@qt4
x11-toolkits/qwt6@qt5

A bit tricky could be, that USE_QT* are different in both cases:

USE_QT4= corelib gui opengl svg xml moc_build
USE_QT5= core gui opengl svg xml printsupport qmake_build widgets

What do you think?

Best wishes,
Rainer

___
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: FLAVOR for Qt4 and Qt5 (was Re: Flavor or not for this port?)

2017-12-21 Thread Mathieu Arnold 
Le 19/12/2017 à 20:48, L.Bartoletti a écrit :
> Hi,
>
> Here's my WIP
>
> https://gitlab.com/lbartoletti/freebsd_ports/tree/master/qwt6

As long as you are defining a default FLAVOR value, do it right:

FLAVOR?= ${FLAVORS:[1]}

There are a few stuffs that could be simplified, this works for both
flavors:|

|

|PLIST= ${PKGDIR}/pkg-plist.${FLAVOR} PLIST_SUB+=
QT_MKSPECDIR=lib/${FLAVOR}/mkspecs DOCSDIR=
${PREFIX}/share/doc/qwt6-${FLAVOR} And this: ||@${REINPLACE_CMD} -e 
's/__QT_VERSION__/${FLAVOR:S/qt//}/g'
${WRKSRC}/qwtconfig.pri|
||



You are missing:

qt4_CONFLICTS_INSTALL= qwt6-qt5
qt5_CONFLICTS_INSTALL= qwt6-qt4



-- 

Mathieu Arnold




signature.asc
Description: OpenPGP digital signature

Re: OSS Audio

2017-12-21 Thread Sid 
blubee blubeeme; Mon Dec 11 17:03:10 UTC 2017
> I'm taking a look at soundcard.h in /usr/include/sys/soundcard.h in FreeBSD
> vs the soundcard.h in the offical OSS 4.01
> https://sourceforge.net/p/opensound/git/ci/master/tree/include/soundcard.h

> It seems like there's been a lot of changes between FreeBSD 3.8ish version
> and the 4.0 version.

> I was grepping around to see if any other files included this soundcard.h
> header and if updating to the latest would break any other programs.

Can you find OSS version 4.1 or 4.2 in https://svn.freebsd.org/base/ for head/ 
or stable/?

___
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

2017-12-21 Thread Dmytro Bilokha 

On Wed, Dec 20, 2017 at 08:32:37PM +0100, Stefan Esser wrote:

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



Thanks, Stefan, it is also a nice approach.

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

2017-12-21 Thread Grzegorz Junka 


On 21/12/2017 03:19, Michael Gmelin wrote:



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 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 ports (gtk3 for example) doesn't make anything lighter, or
better. Quite the contrary. IMHO Wayland should probably be added. Who
doesn't like more options? But, if it's coming to FreeBSD, and the ports
tree. It should isolate itself as it's own port(s), and include those
dependencies it requires. This is supposed to be policy. IOW if I decide
to include gtk3 as an option to one of

Re: Procmail got updated!

2017-12-21 Thread Matthias Andree 
Am 21.12.2017 um 10:16 schrieb Eugene Grosbein:

> So, you demand we stop shipping any unmaintained software with our Ports & 
> Packages?
> Absence of CVEs means nothing and almost any non-trivial software has bugs 
> (axiom).

Eugene, these are attempts to distract from the argument, or to mount to
fallacies. I do not intend to respond further to them or other of your
messages in this thread.

___
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

2017-12-21 Thread Sid 
> Blubee blubeeme
> I'll look at the libcanberra OSS backend and see if I get get the changes 
> upstream then the libcanberra maintainer can update the port.

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


I looked into it more. Canberra is meant only for sound (.oga, .wav), but 
graphical code is tied in heavily into it for XDG icons and graphics standards, 
so the problem is not just around gtk.

The source code of libcanberra has many graphical files and lines, and its only 
binary /usr/local/bin/canberra-gtk-play (--file) requires the window display 
(which shouldn't be needed for sound, and no graphical interface), so it can't 
run from a root console (onto a non-root desktop).

Icons and programs that need Canberra should just call it. Canberra has the 
ability to output a command, if for instance, the sound application fails. This 
should be output back to another program.

libcanberra needs to fork, to have only audio components (to not rely on any 
graphical toolkit), but it is required for it to keep the same GPL license. 
I'll keep looking at it, and take notes on that. Then see if I can compile it, 
leaving out graphical components (I'm C code illiterate). Later on, it can be 
replaced completely by an OSS API of original code.

While no FreeBSD ports currently use pulseaudio and gstreamer for libcanberra, 
that compatibility should stay in (as opposed to what I suggested previously).
___
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!

2017-12-21 Thread Eugene Grosbein 
22.12.2017 9:50, Matthias Andree пишет:
> Am 21.12.2017 um 10:16 schrieb Eugene Grosbein:
> 
>> So, you demand we stop shipping any unmaintained software with our Ports & 
>> Packages?
>> Absence of CVEs means nothing and almost any non-trivial software has bugs 
>> (axiom).
> 
> Eugene, these are attempts to distract from the argument, or to mount to
> fallacies. I do not intend to respond further to them or other of your
> messages in this thread.

That was real question, I like to know the answer.


___
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"