Re: gdal

[Matthieu Volat]

On Sun, 2 May 2021 13:55:45 -0400
LuMiWa via freebsd-ports  wrote:

> Hi!
> 
> I have a problem to build graphics/gdal on FreeBSD-13.0-RELEASE:
> m::seekp' declared here: type mismatch at 1st parameter ('uint64_t'
> (aka 'unsigned long') vs 'GInt64' (aka 'long long')) virtual void
>  seekp (uint64_t pos) = 0; ^
> exrdataset.cpp:495:1: error: unknown type name 'Int64'; did you mean
> 'GInt64'? Int64 GDALEXRIOStream::tellg ()
> ^
> GInt64
> /usr/ports/graphics/gdal/work/gdal-3.2.2/port/cpl_port.h:267:26: note:
> 'GInt64' declared here typedef GIntBig  GInt64;
>  ^
> exrdataset.cpp:497:24: error: unknown type name 'Int64'; did you mean
> 'GInt64'? return static_cast(VSIFTellL(m_fp));
>^
>GInt64
> /usr/ports/graphics/gdal/work/gdal-3.2.2/port/cpl_port.h:267:26: note:
> 'GInt64' declared here typedef GIntBig  GInt64;
>  ^
> exrdataset.cpp:500:30: error: unknown type name 'Int64'; did you mean
> 'GInt64'? void GDALEXRIOStream::seekg (Int64 pos)
>  ^
>  GInt64
> /usr/ports/graphics/gdal/work/gdal-3.2.2/port/cpl_port.h:267:26: note:
> 'GInt64' declared here typedef GIntBig  GInt64;
>  ^
> exrdataset.cpp:566:36: error: allocating an object of abstract class
> type 'GDALEXRIOStream' poDS->m_pIStream.reset(new GDALEXRIOStream(fp,
> osFilename)); ^
> exrdataset.cpp:992:25: error: variable type 'GDALEXRIOStream' is an
> abstract class GDALEXRIOStream ostream(fp, pszFilename);
> ^
> exrdataset.cpp:1984:32: error: allocating an object of abstract class
> type 'GDALEXRIOStream' poDS->m_pOStream.reset(new GDALEXRIOStream(fp,
> pszFilename)); ^
> 3 warnings and 14 errors generated.
> gmake[4]: *** [../../GDALmake.opt:646: ../o/exrdataset.o] Error 1
> gmake[4]: Leaving directory
> '/usr/ports/graphics/gdal/work/gdal-3.2.2/frmts/exr' gmake[3]: ***
> [GNUmakefile:15: exr-install-obj] Error 2 gmake[3]: Leaving directory
> '/usr/ports/graphics/gdal/work/gdal-3.2.2/frmts' gmake[2]: ***
> [GNUmakefile:114: frmts-target] Error 2 gmake[2]: Leaving directory
> '/usr/ports/graphics/gdal/work/gdal-3.2.2' *** Error code 1
> 
> Stop.
> make[1]: stopped in /usr/ports/graphics/gdal
> *** Error code 1
> 
> Thank you.
> 

Hi, this happens indeed when you build gdal *without* the EXR option when 
openexr is present at build time. I guess the off option is not passed 
correctly to the configure script?

Cheers,

-- Matthieu Volat


pgpGCWQ4vBdwa.pgp
Description: OpenPGP digital signature

Re: Working on FLAVOR support in portmaster

[Matthieu Volat]

On Sun, 10 Dec 2017 22:33:25 +0100
Stefan Esser <s...@freebsd.org> wrote:

> Am 10.12.17 um 18:47 schrieb Matthieu Volat:
> > They do... but only if you commit and push something (even if it's only
> > a personnal clone). If you just keep the changes on your computer, there's
> > nothing.  
> The GitHub master version has changes, that are not yet in any release.

As someone involved in some projects, I do understand the differences between 
working trees and releases, this was specifically about helping developpement 
by being more communicative about it.

There's nothing in the commit tree 
(<https://github.com/freebsd/portmaster/commits/master>) nor the networkd 
(<https://github.com/freebsd/portmaster/network>) as of now regarding this 
issue. I don't know for others, but this has led me to invest some time not 
knowing this was duplicate work.

> 
> This is irrelevant as long as FLAVOR support is missing in portmaster,
> since there is no version that fully supports flavors, right now.

Please understand I am not asking for a working release, I'm asking for a more 
transparent developpement process that would allow other people to more easily 
follow, familiarize themselves with and help in portmaster development...

> 
> > As much as I am defiant of github on certain aspects, I've found in quite
> > some occasion the discussion/comment system around pull requests quite 
> > nice.  
> 
> I'm working in FLAVOR support and I have a version that correctly builds
> the Python ports, that have been converted.
> 
> But I'm currently trying to understand, where the information that the
> ports is to be re-installed, gets lost. Debugging shell scripts is a lot
> of work, since you cannot single step through them. Portmaster does call
> itself recursively, which further complicates understanding and tracing
> the execution. (Besides, portmaster is a main program of 4300+ lines with
> functions sprinkled throughout the code. I have a local version, which
> breaks this large main program in named subroutines, which makes it much
> easier to understand the logic flow, but hides the actual changes when
> creating diffs. I have backported the FLAVOR changes to a portmaster
> version without those subroutines, to get the minimal functional patch,
> but now I'm fighting with the install vs. upgrade distinction being lost.)

You can however set the execution trace argument to produce a full log. I was 
under the impression that when encountering package@flavor, splitting was 
needed in a few places to match the port directory and then simply add 
-DFLAVOR=value to the MAKEFLAGS.

> 
> I can send you the current version in private mail (I do not want to spam
> the mail-list with a 120k+ shell script).

This is exactly why I thought a WIP branch or something of the like would be 
useful, unless you want to proceed alone without any feedback. But then again, 
I posted my own (naive) approach at the issue and it did not seems to provoke 
any feedback, so maybe I was a bit too much hopeful.





pgpxJRx4uqwwf.pgp
Description: OpenPGP digital signature

Re: Working on FLAVOR support in portmaster

[Matthieu Volat]

On Sat, 09 Dec 2017 02:23:10 -0800
"Chris H" <bsd-li...@bsdforge.com> wrote:

> On Sat, 9 Dec 2017 10:25:17 +0100 "Matthieu Volat" <ma...@alkumuna.eu> said
> 
> > On Fri, 8 Dec 2017 14:18:28 +0100
> > Baptiste Daroussin <b...@freebsd.org> wrote:
> >   
> > > On Fri, Dec 08, 2017 at 02:13:09PM +0100, Alexander Leidinger wrote:  
> > > > Quoting Baptiste Daroussin <b...@freebsd.org> (from Thu, 7 Dec 2017  
> > > 14:54:27  
> > > > +0100):
> > > > 
> > > > > On Thu, Dec 07, 2017 at 02:49:45PM +0100, Alexander Leidinger wrote:  
> > > > >   
> > > > 
> > > > > > Alternatively, how would a FreeBSD committer like Stefan or
> > > > > > Torsten or me or whoever gain write access to
> > > > > > https://github.com/freebsd/portmaster/ so get some progress in
> > > > > > the official portmaster location and create a new release
> > > > > > (sorry my ignorance for github and how it works, I'm used to
> > > > > > CVS/SVN workflows)?
> > > > > 
> > > > > They just need to ask git admins to get access, I have already asked
> > > > > Stefan (not
> > > > > reply yet)
> > > > > 
> > > > > They can also ask me directly if they want given I am part of the git 
> > > > >  
> > > admins
> > > > 
> > > > And I see that I'm already part of the FreeBSD organisation on github, 
> > > > so  
> > > I  
> > > > should have access. So... currently portmaster is wild-wild-west  
> > > territory?  
> > > > No real owner, anyone willing to fix/improve is free to do so, and it's 
> > > > up
> > > > to each individual to wear his fireproof-suite (after flavours is 
> > > > settled  
> > > I  
> > > > would be interested to have a look at the local packages installation 
> > > > pull
> > > > request)?
> > > > 
> > > 
> > > The official maintainer is tz@ for now, he just handed the maintainership 
> > > to
> > > se@
> > > 
> > > As for push access for now, only git-admin (which I am part of) and 
> > > bdrewery
> > > (who use to maintain portmaster) have access. I'll be glad to give push 
> > > acces
> > > to
> > > more people.
> > > 
> > > For now I have pushed patches from Stefan in the repo (not the flavor
> > > support
> > > but the preliminary to it)
> > > 
> > > Best regards,
> > > Bapt  
> > 
> > 
> > Would it be possible to have some page to track/show the changes/progress to
> > the code? For some times, we had a lot of "i'm working on it but behind
> > closed doors".
> > 
> > For that kind of tools, it would be nice to see the process of upgrading
> > portmaster (or any other tool for that matter) and get a bit more familiar
> > with the code.
> > 
> > Even a wip branch would be great to involve more people, and that way, 
> > people
> > would be a bit less in the dark, but that is just my 2 cents...  
> 
> Doesn't the GitHub activity graphs, diffs, and commit logs already provide
> this information? Or have I just misunderstood the question?
> 

They do... but only if you commit and push something (even if it's only a 
personnal clone). If you just keep the changes on your computer, there's 
nothing.

As much as I am defiant of github on certain aspects, I've found in quite some 
occasion the discussion/comment system around pull requests quite nice.

Regards,

--
Matthieu Volat <ma...@alkumuna.eu>


pgperwcbvK5Dg.pgp
Description: OpenPGP digital signature

Re: Working on FLAVOR support in portmaster

[Matthieu Volat]

On Fri, 8 Dec 2017 14:18:28 +0100
Baptiste Daroussin <b...@freebsd.org> wrote:

> On Fri, Dec 08, 2017 at 02:13:09PM +0100, Alexander Leidinger wrote:
> > Quoting Baptiste Daroussin <b...@freebsd.org> (from Thu, 7 Dec 2017 14:54:27
> > +0100):
> >   
> > > On Thu, Dec 07, 2017 at 02:49:45PM +0100, Alexander Leidinger wrote:  
> >   
> > > > Alternatively, how would a FreeBSD committer like Stefan or
> > > > Torsten or me or whoever gain write access to
> > > > https://github.com/freebsd/portmaster/ so get some progress in
> > > > the official portmaster location and create a new release
> > > > (sorry my ignorance for github and how it works, I'm used to
> > > > CVS/SVN workflows)?  
> > > 
> > > They just need to ask git admins to get access, I have already asked
> > > Stefan (not
> > > reply yet)
> > > 
> > > They can also ask me directly if they want given I am part of the git 
> > > admins  
> > 
> > And I see that I'm already part of the FreeBSD organisation on github, so I
> > should have access. So... currently portmaster is wild-wild-west territory?
> > No real owner, anyone willing to fix/improve is free to do so, and it's up
> > to each individual to wear his fireproof-suite (after flavours is settled I
> > would be interested to have a look at the local packages installation pull
> > request)?
> >   
> 
> The official maintainer is tz@ for now, he just handed the maintainership to 
> se@
> 
> As for push access for now, only git-admin (which I am part of) and bdrewery
> (who use to maintain portmaster) have access. I'll be glad to give push acces 
> to
> more people.
> 
> For now I have pushed patches from Stefan in the repo (not the flavor support
> but the preliminary to it)
> 
> Best regards,
> Bapt


Would it be possible to have some page to track/show the changes/progress to 
the code? For some times, we had a lot of "i'm working on it but behind closed 
doors".

For that kind of tools, it would be nice to see the process of upgrading 
portmaster (or any other tool for that matter) and get a bit more familiar with 
the code.

Even a wip branch would be great to involve more people, and that way, people 
would be a bit less in the dark, but that is just my 2 cents...

Have a nice day,

--
Matthieu Volat <ma...@alkumuna.eu>


pgprKFsRC8yIM.pgp
Description: OpenPGP digital signature

Re: Working on FLAVOR support in portmaster

[Matthieu Volat]

On Tue, 5 Dec 2017 08:35:55 +0100
Stefan Esser  wrote:

> Am 05.12.17 um 00:43 schrieb Tatsuki Makino:
> > By the way, where is the clever way to update to flavor?
> > I am using portmaster.  
> 
> I'm working on FLAVOR support in portmaster. My version did already build
> all updated ports, the FLAVOR parameter is passed to build sub-processes,
> but there is still some confusion between multiple flavored versions of the
> same port (installing the py27 version wants to deinstall the py36 version
> and vice versa), which I still have to fix.
> 
> I'm not sure that I have time to complete the fix today, but it is not too
> hard. Ports need to complement the port origin with the FLAVOR, where
> appropriate (e.g. when a flavored destination is found in MOVED). Already
> installed packages are annotated with "flavor" and that must be passed to
> the build command, when that port is updated. Most other logic in portmaster
> remains unaffected.
> 
> 
> My work version has all non PKG_NG support stripped, but that is mainly to
> not waste effort fixing irrelevant sub-routines.
> 
> Is it acceptable, to have portmaster stop supporting the old package system?
> AFAIK, there is no way that a modern ports tree with flavor support works
> with a non-PKG_NG infrastructure?
> 
> Regards, STefan

Ho, and here I was, almost ready to request some comments after playing a bit:

  
https://github.com/freebsd/portmaster/compare/master...mazhe:wip-flavors?expand=1

Regarding old pkg support, wasn't it removed from the repo master branch?


pgpEgNBrsxMHc.pgp
Description: OpenPGP digital signature

Re: [HEADUP] FLAVORS landing.

[Matthieu Volat]

On Tue, 26 Sep 2017 10:37:03 -0400
George Mitchell  wrote:

> On 09/26/17 10:05, Mathieu Arnold wrote:
> > [...]
> > This has been a long awaiting feature, most of the work has been done by
> > bapt, bdrewery and antoine, I am just the one actually doing the
> > announce and commit and all.
> > [...]  
> What is the last SVN revision without the changes?  I just updated a
> few minutes ago and portmaster is already unable to build lang/perl5.24
> to fix a security vulnerability. -- George
> 

Indeed, this is *not cool*(tm), especially when an update was *needed* to fix 
some firefox dependancies.


pgpR87VpIj2FH.pgp
Description: OpenPGP digital signature

Re: The future of portmaster [and of ports-mgmt/synth]

[Matthieu Volat]

On Thu, 1 Jun 2017 15:45:43 +0200
Torsten Zuehlsdorff  wrote:

> [...]
> Just as a short note: there is a complete rewrite of portmaster ongoing. 
> Since its a beast and everything else is very hard there is no public 
> evidence in case of failure. ;) Until now.
> 
> I'm currently try to convince all persons already got frustrated by 
> portmaster-programming to come together and work on it. I'm also working 
> at an decent automatic QA for it (and PHP and GitLab).
>

Hi and thanks, is there a name and a public repository for this initiative?


pgpDnNHjpXSXE.pgp
Description: OpenPGP digital signature

Re: MP3 licensing over - can we remove LAME restrictions?

[Matthieu Volat]

On Tue, 16 May 2017 14:44:52 +
Ben Woods <woods...@gmail.com> wrote:

> On Tue, 9 May 2017 at 1:07 pm, Koichiro IWAO <m...@vmeta.jp> wrote:
> 
> > Hi,
> >
> > FYI, MP3 is coming back to Fedora. I think FreeBSD may able to do that.
> > https://fedoramagazine.org/full-mp3-support-coming-soon-to-fedora/
> >  
> 
> If this analysis is correct, it sounds like the final patents will expire
> by the end of this year?
> 
> http://www.tunequest.org/a-big-list-of-mp3-patents/20070226/
> 
> Regards,
> Ben

Hi, the Fraunhofer institute released a statement about their licensing of the 
patents:

https://www.iis.fraunhofer.de/en/ff/amm/prod/audiocodec/audiocodecs/mp3.html

That should be it? Now we can wait for aac, h264, h265 ;)

Regards,

-- 
Matthieu Volat <ma...@alkumuna.eu>


pgp1mp1tTvX1v.pgp
Description: OpenPGP digital signature

Re: The future of portmaster

[Matthieu Volat]

On Fri, 17 Feb 2017 10:37:16 +0300
abi <a...@abinet.ru> wrote:

> 17.02.2017 00:22, Chris H пишет:
> > On Thu, 16 Feb 2017 15:48:57 -0500 Baho Utot <baho-u...@columbus.rr.com> 
> > wrote
> >
> >> On 02/16/17 15:40, George Mitchell wrote:
> >>> On 02/16/17 15:33, Baho Utot wrote:
> >>>>
> >>>> On 02/16/17 14:01, Lowell Gilbert wrote:
> >>>>> Baho Utot <baho-u...@columbus.rr.com> writes:
> >>>>>
> >>>>>> On 02/16/17 06:08, Luca Pizzamiglio wrote:
> >>>>>>> I'm looking for constructive critics, feedbacks, anything that can
> >>>>>>> help me to make portmaster an actively maintained and used tool.
> >>>>>> If you can have it build in a clean chroot or jail then you'll get my
> >>>>>> attention
> >>>>> What kind of special support?
> >>>>>
> >>>>> I use it with a chroot that mounts /usr/ports (and src) read-only, and
> >>>>> aside from the initial base system install, it took about fifteen
> >>>>> minutes to set up.
> >>>>>
> >>>> Using chroot or jails to build each individual package
> >>>> [...]
> >>> While I understand the interest in chroot/jails as an optional
> >>> feature, I hope it doesn't become required.  The current non-use
> >>> of chroot/jails is, for me, a feature -- not a bug.-- George
> >>>
> >>>
> >> Having built and packaged linux from scratch using the rpm package
> >> manager, I came to find that if one is building packages to be used on
> >> multiple machines, one needs to build each package in a chroot
> >> environment or the package could inherit things from the parent not
> >> found in the target machine.  Here by making the package unusable.
> > Hello. You shouldn't have any difficulty accomplishing your goal
> > by simply setting up a jail, and using portmaster within that jail(8).
> > portmaster really doesn't care where it's run. So long as it has
> > everything it needs to accomplish it's job(s). :-)
> >
>  From my point of view, jails are overkill. Chroot should be enough and 
> it would be nice if portmaster starts building in clean environment.

Just dropping privileges to a dedicated user for building would be a big step, 
but that's more a port feature (openbsd's ports do that, if I'm not wrong).



-- 
Matthieu Volat <ma...@alkumuna.eu>



pgp61YY2k5YcB.pgp
Description: OpenPGP digital signature

Re: Status of synth following expulsion of John Marino?

[Matthieu Volat]

On Wed, 15 Feb 2017 09:26:18 +
"Thomas Mueller" <mueller6...@twc.com> wrote:

> Expulsion of John Marino was a shocker to me, caught me by surprise.
> 
> Now my question is what is the status of synth?
> 
> Should I switch from portmaster to synth?
> 
> If synth is deprecated or dropped, after I switch from portmaster to synth, 
> then I have to switch back, and this would be a monster mess of extra work.
> 
> Not to be inflammatory here, just want to know where I/we stand and don't 
> want to go too far off course updating my ports.
> 
> 
> Tom
> 


To my knowledge (ie reading freebsd-ports@), portmaster is not deprecated and 
you are not forced to switch unless you want to use different functionnality 
only provided by other tools...


-- Matthieu Volat <ma...@alkumuna.eu>


pgp9qSjbW6Zig.pgp
Description: OpenPGP digital signature

Re: Firefox and sndio

[Matthieu Volat]

On Sun, 29 Jan 2017 12:53:10 +0300
abi <a...@abinet.ru> wrote:

> On 29.01.2017 05:10, Jan Beich wrote:
> > Mike Clarke <jmc-freeb...@milibyte.co.uk> writes:
> >
> >> On Sat, 28 Jan 2017 14:58:51 +
> >> Grzegorz Junka <li...@gjunka.com> wrote:
> >>
> >>> On 28/01/2017 11:37, Tobias Kortkamp wrote:
> >>>> On Sat, Jan 28, 2017, at 11:23, Grzegorz Junka wrote:
> >>>>> Audio in Firefox seems to be working fine when ALSA is enabled. But when
> >>>>> ALSA is disabled and only SNDIO is enabled there is no sound. In either
> >>>>> case I had PULSEAUDIO disabled. What's the expected configuration for
> >>>>> this to work?
> >>>> Is sndiod running?  If not:
> >>>>
> >>>>   sysrc sndiod_enable=YES
> >>>>   service sndiod start
> >>>>
> >>>
> >>> Thanks Tobias. That helped. Out of interest. Is there any reason why I
> >>> should prefer either SNDIO, PUlSEAUDIO or ALSA?
> >>
> >> This currently creates a problem for those of us using Firefox from
> >> packages because the default build has SNDIO turned off.
> >>
> >> $ pkg info firefox
> > [...]
> >>  ALSA   : on
> > [...]
> >>  PULSEAUDIO : on
> > [...]
> >>  SNDIO  : off
> >
> > Only backends that support lazy bindings are enabled by default i.e.,
> > try PULSEAUDIO, if N/A fallback to ALSA, if N/A fallback to native OSS.
> > SNDIO has lower priority than ALSA in libcubeb but higher in WebRTC and
> > cannot fallback to native OSS as well. SNDIO currently doesn't work
> > inside jail and neither sndiod nor Firefox support Capsicum sandboxing,
> > so falling back to ALSA (or OSS) is important.
> 
> Why OSS is not added to port options? OSS is that, probably, all of us have.

I was about the bring the subject, obviously there is no OSS support in firefox 
yet (!!!), but there is an ongoing work on mozilla's bugzilla:

  https://bugzilla.mozilla.org/show_bug.cgi?id=1021761

Did somebody tried to streamline/backport it? With firefox-esr, the latest 
version do not apply, and I've issue autoreconf-ing after applying previous 
versions...

-- Matthieu Volat



pgpFP2iHrd8XE.pgp
Description: OpenPGP digital signature

Re: CFT upgrade to xorg 1.18.4 and newer intel/ati DDX

[Matthieu Volat]

On Tue, 24 Jan 2017 11:12:56 -0800
Pete Wright <p...@nomadlogic.org> wrote:

> On 01/24/2017 00:55, Matthieu Volat wrote:
> > On Tue, 24 Jan 2017 00:55:16 +0100
> > Baptiste Daroussin <b...@freebsd.org> wrote:
> >
> >> Hi all,
> >>
> >> This is a call for testing for newer Xorg along with newer drivers: intel 
> >> and
> >> ati.
> >>
> >> The patch against the head ports: 
> >> https://people.freebsd.org/~bapt/newxorg.diff
> >>
> >> Note that you would need to rebuild all the xf86-* packages to work with 
> >> that
> >> newer xorg (hence the bump of the revision)
> >>
> >> Do not expect newer gpu supported as this is not the kernel part.
> >>
> >> If you experience any issue with intel or radeon driver please try to use 
> >> the
> >> new modesetting driver provided by xorg directly (note that fedora and 
> >> debian
> >> recommands to use that new driver instead of the ati/intel one)
> >>
> >> To use that driver:
> >>
> >> cat /usr/local/etc/xorg.conf.d/modesetting.conf
> >> Section "Device"
> >>  Identifier "Card0"
> >>  Driver "modesetting"
> >> EndSection
> >>
> >> You need to first load the kms driver eiter via loader.conf or manually via
> >> kldload
> >>
> >> Best regards,
> >> Bapt of behalf of the X11 team
> > Looks good with x11/nvidia driver!
> 
> Hi Matthieu - did you run into any issues building components from 
> x11-drivers?  specifically i'm running into this error when attempting 
> to build x11-drivers/xf86-input-mouse x11-drivers/xf86-video-vesa (among 
> others):
> 
> from vesa build log:
> 
> checking if DPMSExtension is defined... yes
> checking for XORG... no
> configure: error: Package requirements (xorg-server >= 1.6 xproto 
> fontsproto  randrproto renderproto xextproto) were not met:
> 
> Package dri3proto was not found in the pkg-config search path.
> Perhaps you should add the directory containing `dri3proto.pc'
> to the PKG_CONFIG_PATH environment variable
> Package 'dri3proto', required by 'xorg-server', not found
> 
> 
> Consider adjusting the PKG_CONFIG_PATH environment variable if you
> installed software in a non-standard prefix.
> 
> 
> It's odd because xorg-server built fine as did dri3proto - so I'm not 
> sure why its not being picked up by poudriere when i attempt to build 
> these packages.
> 
> Cheers!
> -pete
> 

Hmm, I did not have the issue when I rebuilt ports, but you're right: it seems 
that dri3proto should be added to ${PORTSDIR}/Mk/bsd.xorg.mk line 61 USE_XORG 
flags...

I think I missed the problem since xorg-server must have brought the dependancy 
that was not removed from my system until I ran "pkg autoremove".

-- Matthieu Volat


pgpvzoParoOMW.pgp
Description: OpenPGP digital signature

Re: CFT upgrade to xorg 1.18.4 and newer intel/ati DDX

[Matthieu Volat]

On Tue, 24 Jan 2017 00:55:16 +0100
Baptiste Daroussin <b...@freebsd.org> wrote:

> Hi all,
> 
> This is a call for testing for newer Xorg along with newer drivers: intel and
> ati.
> 
> The patch against the head ports: 
> https://people.freebsd.org/~bapt/newxorg.diff
> 
> Note that you would need to rebuild all the xf86-* packages to work with that
> newer xorg (hence the bump of the revision)
> 
> Do not expect newer gpu supported as this is not the kernel part.
> 
> If you experience any issue with intel or radeon driver please try to use the
> new modesetting driver provided by xorg directly (note that fedora and debian
> recommands to use that new driver instead of the ati/intel one)
> 
> To use that driver:
> 
> cat /usr/local/etc/xorg.conf.d/modesetting.conf
> Section "Device"
> Identifier "Card0"
> Driver "modesetting"
> EndSection
> 
> You need to first load the kms driver eiter via loader.conf or manually via
> kldload
> 
> Best regards,
> Bapt of behalf of the X11 team

Looks good with x11/nvidia driver!

In related matters, I noticed that parts of the stack (libclc) require/use llvm 
3.9 while the main body (mesa related ports) still use llvm 3.7. I cherry 
picked very few changes from mesa 12.0 and 13.0 and was able to build 
graphics/libEGL and graphics/dri with llvm 3.9 too:

https://gist.githubusercontent.com/mazhe/e094ac71ae25d40d46fd49510311204e/raw/aca8404c14693a3779d618c3c920a97a7fb620fb/ports_mesa_llvm39.diff

As a nvidia driver user, I guess most of mesa is shortcutted in my config, but 
maybe that would be of interest to other people? 

-- Matthieu Volat


pgp5FEqJW1j_t.pgp
Description: OpenPGP digital signature

Re: HEADSUP: FLAVORS (initial version) and subpackages proposals

[Matthieu Volat]

On Mon, 19 Dec 2016 01:31:43 +0100
Baptiste Daroussin <b...@freebsd.org> wrote:

> Hi all,
> 
> I have been working for a while on 2 long standing feature request for the 
> ports
> tree: flavors and subpackages.
> 
> For flavors I would like to propose a simple approach first which is more 
> like a
> rework of the slave ports for now:
> 
> Examples available here:
> https://reviews.freebsd.org/D8840 (with the implementation)
> and
> https://reviews.freebsd.org/D8843
> 
> Design: introduce a 3rd level in the hierarchy and make it work a bit like 
> slave
> ports
> 
> pros:
> - all slave ports are self hosted under the same directory: easier for
>   maintenance
> - should work with all existing tools
> 
> cons:
> - hackish: it is not really much more than a slave port
> - it adds plenty of new Makefiles :(
> 
> I think anyway this is an improvement
> 
> Next step after that is in would be to extend it to allow some dependency on 
> "I
> depend on whatever flavor if port X"
> 
> Subpackages:
> Design:
> Add a new macro MULTI_PACKAGES
> flag plist with an @pkg{suffixofthesubpackage} file
> the framework will split the plist into small plist and create all the 
> packages
> All variables like COMMENT can be overridden with a 
> COMMENT_${suffixofthesubpackage}
> 
> pros:
> - simple and working almost now
> - allow to simplify lots of ports
> - options friendly (_PACKAGE automatically appends a new entry to
>   MULTI_PACKAGES)
> 
> cons:
> - will break the paradigm that certain tools depend on (portmaster/portupgrade
>   in particular are a huge problem since they are not actively maintained)
> 
> Example of the usage:
> https://people.freebsd.org/~bapt/multipackage.diff
> 
> Note that I took the mpg123 as an example because it was a simple one to test
> not because it may need subpackages
> 
> As a result you build 3 packages:
> mpg123 (the runtime tools)
> mpg123-lib: the runtime libraries
> mpg123-sndio: the sndio plugin
> 
> LIB_DEPENDS on ports depending on libmpg123.so does not have to be changed, 
> the
> framework already automatically register only the mpg123-lib as a dependency 
> and
> not others.
> 
> Not the example is missing one thing: a dependency between mpeg123-lib and
> mpg123
> 
> The second is not ready yet and would take time to land
> 
> Any comment?
> 
> Best regards,
> Bapt

Does this approach would manage a file that differ between flavors? Let's say 
there a libfoo.so file that behave differently wheter an option A is selected 
or not, but is still present in both cases. 

On another note, I kinda liked the macports approach to use the "+" separator 
regarding naming flavors/options, it allows to better distinguish what in the 
package name and what are the selected options, and handled itself quite well 
with multiple instances, like "vim+nls+python+x11"... Did you consider 
something like that?


-- 
Matthieu Volat <ma...@alkumuna.eu>



pgpKyNhOOomNS.pgp
Description: OpenPGP digital signature

Re: The ports collection has some serious issues

[Matthieu Volat]

On Thu, 15 Dec 2016 19:31:22 +0100
list-freebsd-po...@jyborn.se wrote:

> On Thu, Dec 15, 2016 at 01:18:05PM -0500, George Mitchell wrote:
> > On 12/15/16 09:40, Warren Block wrote:
> > > On Thu, 8 Dec 2016, Matt Smith wrote:
> > > 
> > >> On Dec 08 05:16, Daniil Berendeev wrote:
> > >>>
> > >>> Although portmaster is not releated to the FreeBSD project and is an
> > >>> outside tool, there aren't any alternatives from the project itself. So
> > >>> use it or die. Not a nice situation.
> > >>
> > >> People have been trying to get portmaster deprecated and removed from
> > >> the handbook but have met with resistance.
> > > 
> > > Well, yes.  Because it works, has no dependencies, and there is no
> > > equivalent replacement.  [...]
> > 
> > Warren, you have hit the nail on the head.  -- George
> 
> +1
> 
> I never have problems with portmaster.
> (But portupgrade could at times be an utter mess,
> I never looked back after switching to portmaster
> many years ago.)
> 
> And I'm not at all interested in running poudriere
> or synth, thank you.
> 

It seems that if people happy with portmaster keep silent, others will assume 
it's okay to try to dismiss it; so here am I, happy with portmaster.

I could switch to something else that is feature wise similar; but if it would 
not written in some quasi-obselete/niche/hipster programing language or involve 
admin/config tasks like creating repos.

Until a challenger appears, I'm just going to use and recommend portmaster.

Happy bsding everybody

-- Matthieu


pgplStNvzBqaD.pgp
Description: OpenPGP digital signature

Re: Is there possible run a MacOS X binary

[Matthieu Volat]

On Mon, 5 Dec 2016 14:31:06 -0500
"Kevin P. Neal"  wrote:

> On Mon, Dec 05, 2016 at 02:49:07PM -0300, Nilton Jose Rizzo wrote:
> > 
> > 
> >  Sorry for cross posting (-current and -ports)
> > 
> > 
> > Is there any emulator like linuxator to run Mac OS X binaries, or 
> > is ther any licensing problem?
> 
> It may be possible to make an emulator for Darwin (the OS that Mac OS sits
> on top of), but an emulator for Mac OS would probably require a legal copy
> of Mac OS.
> 
> So, no, there is no Mac OS emulator for FreeBSD. And I'd be surprised if
> it ever happened.
> 

You can have a look at darling  which aim to 
provide the macos(x) equivalent to wine (so, no kernel bits?), but given how 
I'm currently struggling with wine on FreeBSD, I would not bet this will work 
without some porting.

(Note that lots of parts of macos are closed source (frameworks, and aqua), so 
unlike linux, you can't just grab their libraries like that, and there's the 
problem of the display)

-- Matthieu


pgpIkKJUDSChk.pgp
Description: OpenPGP digital signature

Re: upgrade to devel/dbus breaks xfce4

[Matthieu Volat]

On Wed, 30 Nov 2016 15:32:49 -0500
Aryeh Friedman  wrote:

> On Wed, Nov 30, 2016 at 3:28 PM, Kevin Oberman  wrote:
> 
> > On Wed, Nov 30, 2016 at 11:42 AM, Aryeh Friedman  > > wrote:
> >
> >> On Wed, Nov 30, 2016 at 9:11 AM, Raphael Kubo da Costa <
> >> rak...@freebsd.org>
> >> wrote:
> >>
> >> > Aryeh Friedman  writes:
> >> >
> >> > > After upgrading deval/dbus to dbus-1.10.12 xfce4 fails to start as a
> >> > > non-root user due to being unable to open/write to /etc/machine-id. I
> >> > > made a tempurary fix by touching /etc/machine-id and chmod'ing it to
> >> > > 777.
> >> >
> >> > If the /etc/machine-id message you're getting looks like
> >> >
> >> > D-Bus library appears to be incorrectly set up; failed to read
> >> > machine uuid: Failed to open "/etc/machine-id": No such file or
> >> > directory
> >> >
> >> > it may be misleading as /etc/machine-id is a fallback if other files
> >> > were not found before (see bug 213540, for example).
> >> >
> >> > Is dbus running when you try to launch XFCE?
> >> >
> >>
> >> That is the message I got... it was immediately after boot and dbus was
> >> not
> >> running (it asked for a onestart when I attempted to manually start it).
> >> My .xinitrc is as follows:
> >>
> >> xfce4-session
> >>
> >>
> >>
> >> --
> >> Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
> >>
> >
> > To ask a dumb question, do you have 'dbus_enable="YES"' in /etc/rc.conf?
> > It looks like the dbus daemon is not running and, when it tries to run from
> > xfce, it lacks the privs needed. Perhaps the protections were adjusted in
> > the new version of dbus.
> >
> 
> I am using what ever the defaults are but I suspect since I had to use
> onestart it was not enabled (before the update this was not needed).
> 

I had a very hard time starting xfce those days with a minimal xinitrc
(could not get the shutdown permissions to apply and such). I ended
copying /usr/local/etc/xdg/xfce4/xinitrc which seems to take care of everything.


pgpQp7uLIwV7g.pgp
Description: OpenPGP digital signature

Re: upgrade to devel/dbus breaks xfce4

[Matthieu Volat]

On Tue, 29 Nov 2016 18:00:40 -0500
Aryeh Friedman  wrote:

> After upgrading deval/dbus to dbus-1.10.12 xfce4 fails to start as a
> non-root user due to being unable to open/write to /etc/machine-id.   I
> made a tempurary fix by touching /etc/machine-id and chmod'ing it to 777.
> 

"Funny", this (/etc/machine-id) is systemd-os stuff, the port is configured to 
use /var/db/dbus/machine-id which should be generated by the rc script.

I'm not having issues with slim/xfce4...

-- Matthieu


pgpmqV44YMFiz.pgp
Description: OpenPGP digital signature

Re: Request to commit distcc port fix

[Matthieu Volat]

On Thu, 24 Nov 2016 10:21:56 +0100
Kurt Jaeger  wrote:

> Hallo,
> 
> > My growing set of pending PR begin to grow, would a commiter (with interest 
> > in the distcc port?) be available to have a last look at this PR and commit 
> > the patch?
> > 
> >   https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213875
> 
> I've looked at the patch. It has ctrl-m at the end and it needs
> some mangeling to apply the files/ rename. So it's not cookie-cutter
> easy 8-}
> 
> I'll try to look into it in the next days. Sorry, the backlog of
> open ports PRs is growing, so your PR is also part of that...
> 

Sorry, I'm not sure what inserted those ^M. I suspect newer svn diff related 
stuff, if that helps, I renegerated the patch with some flags.

Thanks a lot for taking time to review this!

-- Matthieu


pgpRloojIkRrn.pgp
Description: OpenPGP digital signature

Request to commit distcc port fix

[Matthieu Volat]

Hi,

My growing set of pending PR begin to grow, would a commiter (with interest in 
the distcc port?) be available to have a last look at this PR and commit the 
patch?

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

Summary:
  * Change master site from googlecode to github (new upstream source)
  * Some updates to bring back the port in accordance with 2016 best practices

Thanks,

-- Matthieu Volat <ma...@alkumuna.eu>


pgp89kqHsR95u.pgp
Description: OpenPGP digital signature

Re: clang support for compiler:openmp

[Matthieu Volat]

On Mon, 7 Nov 2016 18:59:26 -0300
"Nilton Jose Rizzo" <ri...@i805.com.br> wrote:

> Em Mon, 7 Nov 2016 22:12:59 +0100, Matthieu Volat escreveu
> > On Mon, 7 Nov 2016 16:59:36 +
> > Brooks Davis <bro...@freebsd.org> wrote:
> > [...]

> 
>   I have one question about a llvm and clang ports.  it's possible
> port the llvm 3.9 and clang 4.0.0 with cuda support?
> 
> 

I don't think we'll see that anytime soon: even if there are now some compilers 
that produce cuda PTX bytecode, you neeed userland and kernel code to actually 
compile it to native GPU code/push it/do data transfert, and only the nvidia 
official driver do that for now.

There's some of that in the linux compatibility part of the nvidia driver, and 
some people managed to use it in the past, but right now, I'm not so sure.


-- Mazhe


pgpvVxoF50Yx7.pgp
Description: OpenPGP digital signature

Re: clang support for compiler:openmp

[Matthieu Volat]

On Mon, 7 Nov 2016 16:59:36 +
Brooks Davis  wrote:

> On Sun, Nov 06, 2016 at 08:36:22AM +0100, Marcus von Appen wrote:
> > Hi,
> > 
> > is there a specific reason, why we do not (yet) have openmp support for
> > clang via compiler:openmp? With devel/openmp in the ports tree, I'd
> > expect compiler:openmp to set
> > 
> > LIB_DEPENDS+=   libomp.so:devel/openmp
> > 
> > for compiler=clang. CFLAGS and LIBS/LDFLAGS might be tweaked on a
> > per-port level.
> 
> I talked with Baptiste about this in Belgrade.  I think the best way
> forward would be to remove the OPENMP option from the llvm ports and
> alter the clang-patch-fopenmp.diff patch to use the .so from
> devel/openmp.
> 
> I have a major deadline at the end of the week so it definitely won't
> happen this week.
> 

Would not that make that every clang use the llvm 3.8 libomp snapshot? It might 
be useful to use later versions in some cases, but anyway, that would be great!

It would also be awesome if base clang would be able to find omp.h and libomp 
more "out of the box" once the package is installed...

-- Mazhe


pgpl3cmFmrGvS.pgp
Description: OpenPGP digital signature

Re: FreeBSD Port: fusefs-wdfs-1.4.2_6

[Matthieu Volat]

On Fri, 4 Nov 2016 11:19:11 +0100
Ruud Boon <r...@b-funky.nl> wrote:

> Hi,
> 
> I’m wondering if this port is still maintained. 
> Under FreeBSD 10.3 it looks like it’s failing (trying to mount a webdav 
> result is disappearing mount directory)
> 

Hi, I also ran into various issues with wdfs, the last release is from 2007, so 
the project is all but dead as the "rest of the world" seems to rely on davfs2 
now.

I tried in the past to port davfs2, but it relies on using some gnu & linux 
APIs, mostly related to actually mount volumes that were a bit tricky to 
convert (best shot at it would be to convince upstream to use the libfuse 
functions)...

-- Matthieu Volat


pgpjw6UF0SuPL.pgp
Description: OpenPGP digital signature

Looking for commiter to review/commit matplotlib port patch

[Matthieu Volat]

Hi, if a port commiter (one with interest in matplotlib and its Qt5 backend?) 
could have a look at this issue?

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

Maintainer already ok'ed it!

Thanks,

-- Matthieu Volat <ma...@alkumuna.eu>


pgpUfHKbqenpS.pgp
Description: OpenPGP digital signature

Re: harder and harder to avoid pkg

[Matthieu Volat]

On Fri, 14 Oct 2016 13:05:35 +0200
David Demelier <demelier.da...@gmail.com> wrote:

> 2016-10-14 11:22 GMT+02:00 Baptiste Daroussin <b...@freebsd.org>:
> > It is imho doable in both sides.
> >
> > We could imagine tagging the plist/manifest so pkg can allow a user to 
> > install
> > only the things tagged as runtime for exemple which would do the job. for 
> > what
> > Julian is asking for beside adding lots of complexity pkg(8) and adding a
> > nightmare in the solver.
> >
> > That would "please" the people that want "hey keep the giant flat package 
> > as it
> > is better for dev given I don't have to install the -devel version 
> > something"
> > and the people wanting fine grain selection if they need to.
> >
> > But on the ports side that would be a nightmare having to tag all the plist 
> > (and
> > this cannot be automated because there are to many corner cases.
> 
> IIRC, rpm builders have script that automate this by finding files in
> standard directories. Probably by checking in the stage a include/
> directory and "tag" it as the development part.

Unless things changed very recently, not quite : you have to pile subpackage 
declaration and files sections according to the subpackages you create. The 
only things it has to ease the burden is you can use wildcard patterns to 
select files.

> It will be the most smart way of doing this but still require some
> addition to pkg. Probably like:
> 
> - pkg install mylib
> - pkg install -t dev mylib
> - pkg install -t runtime mylib
> - pkg install -t dev,runtime,doc mylib
> 
> Just thinking ;)

More options, then more options to `pkg info` to get what was installed when 
something cannot build, then more pkg search options and manpage because more 
"-t" flags will be added and we don't know what's needed?

-- 
Matthieu Volat <ma...@alkumuna.eu>



pgpZY_aqAJ_bU.pgp
Description: OpenPGP digital signature

Re: harder and harder to avoid pkg

[Matthieu Volat]

On Tue, 11 Oct 2016 11:59:47 -0700
Julian Elischer <jul...@freebsd.org> wrote:

> As the number of dependencies between packages get ever higher, it 
> becomes more and more difficult to compile packages and the dependence 
> on binary precompiled packages is increased. However binary packages 
> are unsuitable for some situations.  We really need to follow the lead 
> of some of the Linux groups and have -runtime and -devel versions of 
> packages,  OR  we what woudlbe smarter, woudl be to have several "sub 
> manifests" to allow unpacking in different environments.
> [...]
> 

And GNU/Linuxes can be a PITA when you have to track -dev(el) packages (which 
sometimes really requires -bin, -app or whatever), or worst, describe to people 
how they are supposed to build your software with weird subpackage names.

I really like that ports provides the software project as intended by upstream 
(modulo options).

-- 
Matthieu Volat <ma...@alkumuna.eu>


pgpL0u4FDI6tS.pgp
Description: OpenPGP digital signature

Re: dependency explosions

[Matthieu Volat]

On Mon, 3 Oct 2016 14:29:27 +
Grzegorz Junka <li...@gjunka.com> wrote:

> On 03/10/2016 14:11, Mike Clarke wrote:
> > On Mon, 3 Oct 2016 13:11:43 +
> > Grzegorz Junka <li...@gjunka.com> wrote:
> >
> >> Shouldn't all packages default to noX dependencies? If I am not mistaken
> >> FreeBSD is predominantly a server-side system, with X running only
> >> occasionally
> > I'd disagree with that. I don't know whether or not the majority of
> > FreeBSD installations are servers or personal computers but the chances
> > are that the majority of server installations will have relatively few
> > packages installed whereas most PC's are likely to make use of far
> > more packages and are also likely to be using X. Building from ports
> > to get the required options would be a much bigger task for these
> > installations than it would be for the servers.
> >
> 
> I have been wondering if it would be possible to have two distinct set 
> of packages compiled automatically, one tailored for X and one for the 
> console. It seems that requirements of both environment are quite 
> opposite. The server-side requires small amount of packages without X 
> because it wants to run the system headless, as long as possible and 
> without interruptions and restarts. Whereas the X/PC environment always 
> wants to have everything latest and newest. In the Linux world they 
> would just create a new distribution, even in the BSD world there is 
> PC-BSD/TrueOS. But we have ports and can re-use the same base for two 
> distinctive set of packages. I don't believe we can create pre-compiled 
> packages for FreeBSD in such a way, that both camps are happy (which 
> this thread is one of many signs of).
> 
> Grzegorz

That must be somehow possible and even extensible to be something like macports 
variants, except with binary package support (macports localy build packages 
when user defined option differs from default); but this would take signifiant 
space and processing power...

On the other hand, setting OPTIONS_UNSET to include X11 is quite trivial. I 
would expect a server administrator to be more proficient in that kind of 
settings...

PS. I agree with the multiplication of dependencies, but I see them as the 
result of nowaday FOSS ecosystem practices rather than port management issues.

-- 
Matthieu Volat <ma...@alkumuna.eu>


pgpE7Ij5qzGwY.pgp
Description: OpenPGP digital signature

Re: Patch to cmake detect OpenMP

[Matthieu Volat]

On Tue, 20 Sep 2016 00:55:44 -0300
Otacílio <otacilio.n...@bsd.com.br> wrote:

> I'm trying to port flann (http://www.cs.ubc.ca/research/flann/) to 
> FreeBSD, but I need that cmake detects OpenMP. Unhappy, cmake do not 
> detects OpenMP even when devel/openmp is installed,  so I did this patch 
> to cmake port. What you guys think about? Can I open a bug report with 
> patch?
> 
> []'s
> 

Hi, are you planning to submit this patch for cmake in ports or the upstream 
project?

This is not a really good idea to hardcode /usr/local like that, for there can 
be may more providers for libomp (lang/clangXY ports, if you need a specific to 
workaround bugs for example... or even maybe base in the future?). Also, it 
would break cmake with GCC.

Without changing any upstream code in either cmake or flann, for FreeBSD 11+, 
you can just set :

  USES+=  compiler:openmp 
  CFLAGS+= -I${LOCALBASE}/include
  LDFLAGS+= -L${LOCALBASE}/lib -lomp -lm

I did not test how this behave on older release yet... And if you need to build 
cmake-based projects outside ports, here's the flags I use:

 -DCMAKE_REQUIRED_INCLUDES="/usr/local/include" \
 -DCMAKE_REQUIRED_LIBRARIES="-L/usr/local/lib -lomp -lm" \
 -DCMAKE_EXE_LINKER_FLAGS="-L/usr/local/lib -lomp -lm" \
 -DCMAKE_MODULE_LINKER_FLAGS="-L/usr/local/lib -lomp -lm" \
 -DCMAKE_SHARED_LINKER_FLAGS="-L/usr/local/lib -lomp -lm"

-- Matthieu Volat <ma...@alkumuna.eu>


pgpPnOxTm0Xcz.pgp
Description: OpenPGP digital signature

Re: New dependencies of ImageMagick-nox11 - are they necessary?

[Matthieu Volat]

On Sun, 14 Aug 2016 23:00:59 +0200
Miroslav Lachman <000.f...@quip.cz> wrote:

> I upgraded ImageMagick-nox11: 6.9.4.3,1 -> 6.9.5.5_1,1 and found these 
> new dependencies:
> 
> 
> New packages to be INSTALLED:
>  gettext-runtime: 0.19.8.1
>  glib: 2.46.2_2
>  python27: 2.7.12
>  pcre: 8.39
> 
> I did this in one small jail where I don't want any unnecessary 
> packages. This was minor update of ImageMagick so I am surprised with 
> these not so small new dependencies.
> 
> Are they really necessary even for nox11 variant of ImageMagick?

After playing a bit with options, it seems that:

1. gettext-runtime
I did not see a configure option to disable NLS support in ImageMagick

2. glib, pcre
They are not always needed indeed, in my limited options configuration test[1], 
LQR needs it at least (I suppose others, like PDF or SVG, would too).

3. python
I suppose a dependency brought it?

> 
> Miroslav Lachman

[1] Full option list and glib/pcre dependency:

16BIT_PIXEL: none
BZIP2: none
DJVU: ?
DOCS: ?
FFTW: ?
FONTCONFIG: none
FPX: ?
FREETYPE: none
GRAPHVIZ: ?
GSLIB: ?
HDRI: ?
JBIG: none
JPEG: none
JPEG2000: none
LCMS2: none
LQR: glib, pcre
LZMA: none
MODULES: none
OPENEXR: none
OPENMP: ?
PANGO: ?
PDF: ?
PERL: ?
PNG: none
SVG: ?
TESTS: ?
THREADS: none
TIFF: none
WEBP: ?
WMF: ?
X11: none


pgpQ98DGwaz86.pgp
Description: OpenPGP digital signature

rmilter issue/maintainer timeout

[Matthieu Volat]

Hi,
6 months ago, I submitted an issue regarding a very annoying bug in rmilter 
packaging. This one bite me again and left me without mail for 3 days, can 
anybody have a look and maybe commit it if maitainer timeout?

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

Thanks

-- Matthieu Volat <ma...@alkumuna.eu>


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Framework question....

[Matthieu Volat]

On Tue, 12 Jul 2016 20:45:55 -0500
Larry Rosenman <l...@lerctr.org> wrote:

> Ports Folks,
> I have a port (mail/dovecot2-pigeonhole) that I apparently need to 
> pick up
> the mail/dovecot2 gssapi option, but do NOT want to make the user set it 
> via the normal
> options dialog.  I.E. if dovecot2 has gssapi_heimdal set, I want to know 
> that.
> 
> Does the framework give me a way to get the OTHER ports option?

Last time I had to face such a problem (~1 year ago?), it did not... You may 
end up doing something using a subshell command such as :

DOVECOT2_GSSAPI=${:!grep GSSAPI ${PORT_DBDIR}/mail_dovecot2/options|grep 
_SET|cut -d= -f2!}

Until somebody proposes something better...

> 
> 
> 
> -- 
> Larry Rosenman http://www.lerctr.org/~ler
> Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
> US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
> ___
> 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"


-- 
Matthieu Volat <ma...@alkumuna.eu>



pgpdpR0KfwMg6.pgp
Description: OpenPGP digital signature

Re: [CFT] net-im/ejabberd to 16.01

[Matthieu Volat]

On Mon, 07 Mar 2016 12:27:11 +0530
ash...@freebsd.org (Ashish SHUKLA) wrote:

> On Sat, 5 Mar 2016 18:09:35 +0100, Matthieu Volat <ma...@alkumuna.eu> said:
> 
> [...]
> 
> Hi,
> 
> | Ok, back on business!
> 
> | My issue with the non-applied patchs is that those were not creates in the 
> files subdir in ejabberd, but in a ejabberd/files subdir.
> 
> That is likely due to the missing/incorrect, use of 'patch -pN'. I remember
> testing successful diff application before posting on the list, except for a
> 404-ing URL in one of my diffs.

Yeah, it was a simple patch -p0 call... But anyway, that won't matter for final 
distribution...

> 
> | Regarding the pam module installation, it seems to be installed in :
> | /usr/local/lib/erlang/lib/ejabberd-16.01/lib/p1_pam-1.0.0/priv/bin/epam
> 
> | But ejabberd at start will fail with :
> | 2016-03-05 17:52:49.297 [error] <0.394.0> Can't open file
> | 
> "/usr/local/lib/erlang/lib/ejabberd-16.01/lib/erlang/lib/ejabberd-16.01/priv/bin/epam":
>  enoent
> 
> | So I guess it's not installed in the right place?
> 
> I guess, although I don't see in the sources, where exactly it refer to this
> path, or even install the module. I'll check and get back to you.

I forgot to tell that I did not see it either, but I tried to put it manually 
and pam support was working.

> 
> | Then, regarding the bash issue, I made some progress, but I still need
> | to test it a bit more to be sure it do not introduce new bugs (it's
> | not much, but I have to see if the kinda simple shell escaping
> | function equivalent I put is enough).
> 
> These bash script changes could you contribute to upstream instead. I don't
> really wish to keep maintaining them downstream.

I agree.

> 
> ejabberd team has released 16.02 in the meantime, I'll work on updating to it
> instead. It works fine in my testing so far except for the PAM issue you've
> mentioned.
> 
> I'll post updated patch here for testing.
> 
> Thanks!
> -- 
> Ashish SHUKLA  | GPG: F682 CDCC 39DC 0FEA E116  20B6 C746 CFA9 E74F A4B0
> 
> “If I were to compare a human's heart with the ocean, the ocean would be
> stagnant.”   (Recruit, Arakawa Under the Bridge)
> 
> Sent from my Emacs


-- 
Matthieu Volat <ma...@alkumuna.eu>
tel: 06 84 54 39 43
www: <http://500px.com/Mazhe>


pgpBZzzTB6IWN.pgp
Description: OpenPGP digital signature

Re: [CFT] net-im/ejabberd to 16.01

[Matthieu Volat]

On Mon, 29 Feb 2016 19:34:09 +0530
ash...@freebsd.org (Ashish SHUKLA) wrote:

> On Mon, 29 Feb 2016 14:37:22 +0100, Matthieu Volat <ma...@alkumuna.eu> said:
> 
> 
> [...]
> 
> 
> | Hmm, I'll be a bit overwhelmed until thursday, I'll check that...
> 
> Thanks, and I appreciate it.
> 
> [...]
> 
> | Thanks, there was another blocking issue for me yesterday, which is the 
> ejabberdctl is now in bash.
> 
> | If possible, I'd like to make a patch to (optionally) revert to pure sh, as 
> I find it a bit sad to go full bash only to read a few parameters...
> 
> | I'll keep you informed
> 
> Thanks in advance, if you could provide the patch. For now, I have updated the
> diff to include dependency on bash, which I apparently missed before :/
> 
> New diff:
> 
> https://people.freebsd.org/~ashish/diffs/ejabberd-16.01-01.diff
> sha256 sum: ec71fdd19c752b22271ce6e3f899b966b0017f05fa13532d1decf18478e41b6e
> 

Ok, back on business!

My issue with the non-applied patchs is that those were not creates in the 
files subdir in ejabberd, but in a ejabberd/files subdir.


Regarding the pam module installation, it seems to be installed in :
/usr/local/lib/erlang/lib/ejabberd-16.01/lib/p1_pam-1.0.0/priv/bin/epam

But ejabberd at start will fail with :
2016-03-05 17:52:49.297 [error] <0.394.0> Can't open file
"/usr/local/lib/erlang/lib/ejabberd-16.01/lib/erlang/lib/ejabberd-16.01/priv/bin/epam":
 enoent

So I guess it's not installed in the right place?


Then, regarding the bash issue, I made some progress, but I still need to test 
it a bit more to be sure it do not introduce new bugs (it's not much, but I 
have to see if the kinda simple shell escaping function equivalent I put is 
enough).


-- 
Matthieu Volat <ma...@alkumuna.eu>


pgpCwzOQ0hyZ_.pgp
Description: OpenPGP digital signature

Re: [CFT] net-im/ejabberd to 16.01

[Matthieu Volat]

> Le 29 févr. 2016 à 02:01, Ashish SHUKLA <ash...@freebsd.org> a écrit :
> 
> On Sun, 28 Feb 2016 19:33:53 +0100, Matthieu Volat <ma...@alkumuna.eu> said:
> | On Sun, 28 Feb 2016 21:02:59 +0530
> | ash...@freebsd.org (Ashish SHUKLA) wrote:
> 
> [..]
> 
> | Thanks for your work,
> 
> Thank you for taking time to test the diff.
> 
> | On my 10.2/amd64 host, the build failed due to using  types 
> without including it in :
> 
> |   /usr/ports/net-im/ejabberd/work/deps/p1_stringprep/c_src/stringprep.cpp
> 
> Following changeset from the diff file should fix this:
> 
> --8<---cut here---start->8---
> diff -urN 
> /usr/ports/net-im/ejabberd/files/patch-.._deps_p1__stringprep_c__src_stringprep.cpp
>  ejabberd/files/patch-.._deps_p1__stringprep_c__src_stringprep.cpp
> --- 
> /usr/ports/net-im/ejabberd/files/patch-.._deps_p1__stringprep_c__src_stringprep.cpp
>1970-01-01 05:30:00.0 +0530
> +++ ejabberd/files/patch-.._deps_p1__stringprep_c__src_stringprep.cpp 
> 2016-02-28 20:11:00.521409079 +0530
> @@ -0,0 +1,10 @@
> +--- ../deps/p1_stringprep/c_src/stringprep.cpp.orig
>  ../deps/p1_stringprep/c_src/stringprep.cpp
> +@@ -19,6 +19,7 @@
> +  */
> +
> + #include 
> ++#include 
> + #include 
> +
> + #include "uni_data.c"
> --8<---cut here---end--->8---
> 
> Are you sure, the diff was not properly applied. I tried the diff from the
> URL, and applied on net-im/ejabberd and seems to have applied fine, and it
> builds fine too, on 10.2-RELEASE/amd64

Hmm, I'll be a bit overwhelmed until thursday, I'll check that...

> 
> | And it seems the pam module is not installed, again?
> 
> | chmod: /usr/local/lib/erlang/lib/ejabberd-16.01/priv/bin/epam: No such file 
> or directory
> | chown: /usr/local/lib/erlang/lib/ejabberd-16.01/priv/bin/epam: No such
> | file or directory
> 
> This is an oversight on my part. Sorry about this. I have updated the diff to
> refer to the correct path.
> 
> https://people.freebsd.org/~ashish/diffs/ejabberd-16.01-01.diff
> sha256 sum: 7dd1f02da1ccf035f58d857a710787bdc6080d2e2651ca1dd9d1a335a3cc57c8
> 
> If you could functionally test PAM support as well, that'll be great.

Thanks, there was another blocking issue for me yesterday, which is the 
ejabberdctl is now in bash.

If possible, I'd like to make a patch to (optionally) revert to pure sh, as I 
find it a bit sad to go full bash only to read a few parameters...

I'll keep you informed

> 
> Thanks!
> --
> Ashish SHUKLA  | GPG: F682 CDCC 39DC 0FEA E116  20B6 C746 CFA9 E74F A4B0
> Sent from my Emacs



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [CFT] net-im/ejabberd to 16.01

[Matthieu Volat]

On Sun, 28 Feb 2016 21:02:59 +0530
ash...@freebsd.org (Ashish SHUKLA) wrote:

> Howdy,
> 
> I've prepared a long-time pending update for net-im/ejabberd port. Could you
> please test it, and see if it works for you, or something needs change, or
> need a explicit mention ?
> 
> One thing of note is that in this release, paths are changed a bit, courtesy:
> upstream. So, it may break if you rely on paths or something.
> 
> I plan to commit this update on Friday, March 04, 2016.
> 
> If you could give it a shot, and report any issues, that'll be great.
> 
> Following is the link to update:
> 
> http://people.freebsd.org/~ashish/diffs/ejabberd-16.01.diff
> sha256: 1e95776e60a3e2c9cef055d9b08ee59a99f4a18690ab752b17b73bc545d74f22
> 
> Thanks in advance.
> 
> Have a great week{,end} ahead!
> 
> -- 
> Ashish SHUKLA  | GPG: F682 CDCC 39DC 0FEA E116  20B6 C746 CFA9 E74F A4B0
> Sent from my Emacs

Thanks for your work,

On my 10.2/amd64 host, the build failed due to using  types without 
including it in :

  /usr/ports/net-im/ejabberd/work/deps/p1_stringprep/c_src/stringprep.cpp

And it seems the pam module is not installed, again?

chmod: /usr/local/lib/erlang/lib/ejabberd-16.01/priv/bin/epam: No such file or 
directory
chown: /usr/local/lib/erlang/lib/ejabberd-16.01/priv/bin/epam: No such
file or directory

-- 
Matthieu Volat <ma...@alkumuna.eu>


pgpTUpxdX5fVJ.pgp
Description: OpenPGP digital signature

Looking for port commiter: Bug 202205 - install examples in directory using python version

[Matthieu Volat]

Hello all,

I wonder if somebody would be kind enough to commit the patch going with this 
PR:
  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202205

It was already approved by maintainer for some time and help using 
math/py-matplotlib with python3.

Thanks,

-- Matthieu Volat ma...@alkumuna.eu


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [HEADSUP] portmaster/portupgrade support for new features

[Matthieu Volat]

On Mon, 24 Aug 2015 15:58:02 +0200
Baptiste Daroussin b...@freebsd.org wrote:

 On Mon, Jun 29, 2015 at 11:22:27AM +0200, Baptiste Daroussin wrote:
  hi all,
  
  A couple of new features are coming to the ports tree. The first of which 
  has
  landed in the ports tree and should not be used before a while, still 
  before we
  start using it, it would be a very good idea to bring support for it to
  portmaster/portupgrade. (I have already done the change in poudriere and it 
  will
  be in te next version.)
  
  So since recently we can remove the ${PORTSDIR} from all the dependency 
  lines.
  (Please do not use that syntax before all the tools are able to handle it!)
  
  Aka BLA_DEPENDS= pattern:${PORTSDIR}/category/port can now become
  pattern:category/ports
  
  I haven't checked portmaster/portupgrade code so I have no idea if they will
  support that out of box or if they will need some changes.
  
  I would really appreciate to see people testing that and provide patches if
  necessary so that the day we adopt this syntax those tools are already 
  ready to
  use it ootb.
  
  FYI: https://github.com/freebsd/portmaster and
  https://github.com/freebsd/portupgrade
  
  Later more changes will be necessary to support upcoming VARIANTS (formerly
  known as FLAVOURS) and sub packages.
  
  This first step would allow you to step into the code of those tools before 
  the
  having to deal with more intrusive changes :)
  
  Best regards,
  Bapt
 
 Here is a reminder on help needed. We do really need to get this feature in 
 the
 ports tree to be able to step further in flexible dependencies (hear
 provides/requires) and VARIANTS/FLAVORS and subpackages.
 
 If one cares about those tools, please make them work without ${PORTSDIR}
 information.
 
 Best regards,
 Bapt

Hello,

Are those features already present somehow in ports?

The first thing I see is a failure because calling commands
such as make build-depends-list in port directories in which I
removed ${PORTSDIR} from LIB_DEPENDS failing.

Regards,


--
Matthieu Volat ma...@alkumuna.eu


pgp4UvJ8LXrmj.pgp
Description: OpenPGP digital signature

Re: port /usr/ports/graphics/epdfview/

[Matthieu Volat]

On Sun, 3 May 2015 10:45:07 + (UTC)
Algimantas B via freebsd-ports freebsd-ports@freebsd.org wrote:

 Hello, port /usr/ports/graphics/epdfview/  is not broken anymore, it is 
 written, that it is BROKEN (unfetchable), but I commented and it installed 
 just fine. File is present at Index of /ftp/mirror/slitaz/sources/packages/e 

Beware, epdfview has been abandonned by upstream[1][2].

Switching to evince was the recommended path, but I found mate fork atril way 
more usable, especially when trimed down (i submitted a PR, which did not 
gather much interest[3])

[1] https://lists.fedoraproject.org/pipermail/devel/2013-February/178580.html
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=710550
[3] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197197

-- 
Matthieu Volat ma...@alkumuna.eu


pgpMZnuKspqe2.pgp
Description: OpenPGP digital signature

Re: FreeBSD Port: mDNSResponder-561.1.1_1

[Matthieu Volat]

On Sun, 26 Apr 2015 20:33:22 +0800
Sunpoet Po-Chuan Hsieh sunp...@freebsd.org wrote:

 [...]
 FYI, mDNSResponder 567 is in ports tree now (r384780).
 [...]

As a related matter, I submitted Bug 199711 [1] to also bump the NSS library 
(dns/mDNSResponder_nss).

[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199711

-- 
Matthieu Volat ma...@alkumuna.eu


pgpVt2ssz2onx.pgp
Description: OpenPGP digital signature

Looking for a commiter

[Matthieu Volat]

Hi,

I asked for a enchancement to print/gutenprint-base to which the maintainer 
agreed, but now need a good soul with commit bit:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196321

I'd also like that if somebody with an interest in image processing ports would 
be nice enough to have a look at a graphic/lensfun update I posted more than 
two month without any reply:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196182

I'm not feeling this is the right way to bump issues, is there any way I don't 
know of in the bugzilla to draw attention?

Thanks in advance

-- 
Matthieu Volat ma...@alkumuna.eu



pgpmIEZYHZefe.pgp
Description: OpenPGP digital signature

Re: Looking for a commiter

[Matthieu Volat]

On Tue, 24 Feb 2015 15:10:49 -0600
cpet c...@sdf.org wrote:

 On 2015-02-24 15:07, Matthieu Volat wrote:
  Hi,
  
  I asked for a enchancement to print/gutenprint-base to which the
  maintainer agreed, but now need a good soul with commit bit:
  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196321
  
  I'd also like that if somebody with an interest in image processing
  ports would be nice enough to have a look at a graphic/lensfun update
  I posted more than two month without any reply:
  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196182
  
  I'm not feeling this is the right way to bump issues, is there any way
  I don't know of in the bugzilla to draw attention?
  
  Thanks in advance
 
 Committers are busy working on making the ports the way they are so the 
 updates will happen when a committer has time to do so and I am sure 
 they are aware of this. However you may join #bsdports on efnet and talk 
 to any op.
 

Of course, I am very aware of this, I hope the request did not sound like a 
complain or such. I was just affraid that those PR would just never go 
anywhere, since I don't see how they would reach devs...

-- 
Matthieu Volat ma...@alkumuna.eu


pgptxWS7uUjve.pgp
Description: OpenPGP digital signature

Re: Update of security/gnupg fails because of conflict with security/dirmngr

[Matthieu Volat]

On Sat, 29 Nov 2014 13:56:31 +0100
A.J. 'Fonz' van Werven free...@skysmurf.nl wrote:

 Yuri wrote:
 
  ===   Registering installation for gnupg-2.1.0_1 as automatic
  pkg-static: gnupg-2.1.0_1 conflicts with dirmngr-1.1.0_12 (installs 
  files into the same place).  Problematic file: /usr/local/bin/dirmngr
 
 Yes, that sort of thing seems to be happening a lot lately. I found out
 that it often helps if you temporarily uninstall the offending port, then
 install the other one and finally reinstall the uninstalled one. Or in
 your case:
 1. delete dirmngr (remember if it takes anything else with it!)
 2. install gnupg;
 3. reinstall dirmngr again (as well as anything that got deleted with it).
 
 Hope that helps.
 
 However, considering that this sort of thing occurs commonly these days, I
 suspect there must be something wrong in the ports infrastructure. What I
 also find somewhat mindboggling is how ports are built, staged and
 packaged entirely, only THEN to discover there's a conflict. Couldn't that
 have been detected way earlier?
 
 AvW
 
 -- 
 Imbibo, ergo sum.

The issue was reported[1], mentionned[2], without action being taken yet... Is 
gnupg such an obscure and unused port?

[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195489
[2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195206

-- 
Matthieu Volat ma...@alkumuna.eu


pgp2JGZEgOsXg.pgp
Description: OpenPGP digital signature

xsltproc segfaults

[Matthieu Volat]

Hi all,

I've been having a few xsltproc segfaults in some ports (devel/dbus, 
devel/dconf) that begin to be a bother... I'm not sure about what could be 
wrong, I am running 10.1 and trimmed down my CFLAGS with no avail..

For example, in devel/dconf:
Makefile:941: recipe for target 'dconf-service.1' failed
gmake: *** [dconf-service.1] Segmentation fault (core dumped)

# gdb xsltproc xsltproc.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB.  Type show warranty for details.
This GDB was configured as amd64-marcel-freebsd...(no debugging symbols 
found)...
Core was generated by `xsltproc'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/local/lib/libxslt.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /usr/local/lib/libxslt.so.2
Reading symbols from /usr/local/lib/libexslt.so.8...(no debugging symbols 
found)...done.
Loaded symbols for /usr/local/lib/libexslt.so.8
Reading symbols from /usr/local/lib/libgcrypt.so.20...(no debugging symbols 
found)...done.
Loaded symbols for /usr/local/lib/libgcrypt.so.20
Reading symbols from /usr/local/lib/libgpg-error.so.0...done.
Loaded symbols for /usr/local/lib/libgpg-error.so.0
Reading symbols from /usr/local/lib/libxml2.so.2...done.
Loaded symbols for /usr/local/lib/libxml2.so.2
Reading symbols from /lib/libz.so.6...done.
Loaded symbols for /lib/libz.so.6
Reading symbols from /lib/libm.so.5...done.
Loaded symbols for /lib/libm.so.5
Reading symbols from /lib/libc.so.7...done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /usr/local/lib/libintl.so.9...done.
Loaded symbols for /usr/local/lib/libintl.so.9
Reading symbols from /usr/lib/liblzma.so.5...done.
Loaded symbols for /usr/lib/liblzma.so.5
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0  0x000800a6d16c in exsltDateXpathCtxtRegister ()
   from /usr/local/lib/libexslt.so.8
(gdb) bt
#0  0x000800a6d16c in exsltDateXpathCtxtRegister ()
   from /usr/local/lib/libexslt.so.8
#1  0x0100 in ?? ()
#2  0x08003e00 in ?? ()
#3  0x01002c80f604 in ?? ()
#4  0x in ?? ()

Worse, I've been building my port tree with -g, and strangely, I don't get any 
debuging information... Activationg memory debug option in libxslt port do not 
give more than that, too.

Does anybody had experience with such problems and found the source?

Thanks

-- 
Matthieu Volat ma...@alkumuna.eu



pgp8iYKtC7Qiz.pgp
Description: OpenPGP digital signature

Re: security/gnupg: No ecdh/ecdsa capability

[Matthieu Volat]

On Thu, 9 Oct 2014 08:30:46 -0700 (PDT)
Beeblebrox zap...@berentweb.com wrote:

 Hello. 
 Is there a particular reason that security/gnupg on FreeBSD does not include
 the ecdh/ecdsa algorithm?

Elliptic curves algorithms will be supported in GnuPG from version 2.1, which 
have been beta only for quite a while, so everything is normal.

 
 $ gpg2 --version
 gpg (GnuPG) 2.0.26
 libgcrypt 1.6.1
 ..
 Supported algorithms:
 Pubkey: RSA, ELG, DSA
 Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
 CAMELLIA128, CAMELLIA192, CAMELLIA256
 Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
 Compression: Uncompressed, ZIP, ZLIB, BZIP2
 
 Whereas, it should be:  Pubkey: RSA, ELG, DSA, ECDH, ECDSA
 
 I doubt this is an export restriction issue, when
 a. Linux distros have this enabled on gnupg and
 b. openssl has support for it
 This is available in gnupg since 9/2010 (GnuPG 2.1.0  / libgcrypt 1.5.0)
 
 * Is the reason that code has somehow not been merged
 (https://code.google.com/p/gnupg-ecc/source/browse/#svn/branches/gpg2ecc)?
 * I have not tried security/pgp - I could switch if that has ecdsa enabled?
 
 Regards.
 
 
 
 -
 FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS
 --
 View this message in context: 
 http://freebsd.1045724.n5.nabble.com/security-gnupg-No-ecdh-ecdsa-capability-tp5955619.html
 Sent from the freebsd-ports mailing list archive at Nabble.com.
 ___
 freebsd-ports@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-ports
 To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


-- 
Matthieu Volat ma...@alkumuna.eu
tel: 06 84 54 39 43
www: http://500px.com/Mazhe


signature.asc
Description: PGP signature

Re: Splitting devel/subversion into SEVERAL ports -- how fine-grained do we want to see it?

[Matthieu Volat]

On Sun, 8 Jun 2014 00:16:18 +0400
Lev Serebryakov l...@freebsd.org wrote:

 Hello, Ports.
 
  I've learned proper way to split subversion into several ports. Question
 is: how fine-grained should I do this? I want to split it at least  into:
 
 (1) devel/subversion-libs-- base libs, used by all other ports. Options
 about SERF, BDB and SASL goes here.
 (2) devel/subversion-client  -- all base tools, like svn, svnversion and
 so on, but not svnserve.
 (3) devel/subversion-server  -- svnserve binary.
 (4) devel/subversion-tools   -- additional tools (option now).
 (5) devel/subversion-apache  -- all mod_dav_svn-related stuff.
 (6) devel/subversion-gnome   -- GNOME KEyRing integration (option now).
 (7) devel/subversion-kde -- KDE KWallet integration (option now).
 (8) devel/subversion -- meta-port with options (and real stuff, like
 patches and all infrastructure).
 
 But it is possible to extract more options to separate ports: BDB repository
 format, remote access with svn: scheme and SERF support (http: scheme
 remote access) could be separate ports (and packages), not options! But
 maybe, it is too much already?
 
 -- 
 // Black Lion AKA Lev Serebryakov l...@freebsd.org

Holy...

Is this Debian now? How about 14 packages to have granularity over what 
sub-library needed, and 23 others for each svn* command? And don't forget 
headers.

An aspect of ports I liked was it followed/respected the upstream packaging 
mindset, instead of going for artificial repackaging like linux distros. This 
minigame of cutting other people works in tiny atomics bits so I have to figure 
what is missing at runtime is tiresome.

If this is a binary/options issue, I'd rather see an effort in providing a 
system able to allow using globally packages with local build when desired 
options differs, and the reverse (build everything except a list of stuff where 
binary is prefered).

Be more like macports, less like apt.

My 2 cents.

-- 
Matthieu Volat ma...@alkumuna.eu


signature.asc
Description: PGP signature

Re: ejabberd update to 14.05 no longer runs

[Matthieu Volat]

On Wed, 04 Jun 2014 16:08:18 +0200
Neal Nelson nea...@nicandneal.net wrote:

 Hi.
 
 I've just updated ejabberd to the latest 14.05 version, but alas it no
 long runs. Normally I would do some debugging, but this is erlang, so
 all bets are off as I have no idea what to look at, hence the vague
 problem description.
 
 I'd be very grateful is anyone has any idea why a perfectly functional
 ejabber installation no longer works after the upgrade and how I might
 go about fixing it.
 
 Thanks.
 ___

Did you converted your configuration to yaml, or provided a fresh new one, 
before restarting the service? Ejabberd no longer use the erlang-based conf 
files...

-- 
Matthieu Volat ma...@alkumuna.eu


signature.asc
Description: PGP signature

Re: FreeBSD Port: ejabberd-2.1.13 - Release updates available; 14.05, 13.12 13.10

[Matthieu Volat]

On Thu, 22 May 2014 14:05:09 +0530
ash...@freebsd.org (Ashish SHUKLA) wrote:

 [...]
 Sorry for the delay in getting back to you.
 
 Could you please try this diff[1] which fixes this '@rootdir@' thing ?
 
 After installing the port, you need to manually copy the 'epam' binary to its
 place as you were doing before.
 
 Let me know how it goes for you

Thanks, it is working. Like you said, I had to copy epam manualy, set it to 
root:ejabberd 750 with setuid bit. Very well done!

 
 References:
 [1]  http://people.freebsd.org/~ashish/diffs/ejabberd-14.05-0.diff
  sha256: 9d8ced60960ee3177a234b620c4518092afb834e9880ecfa9ddc04b6b2c873fc
 
 Thanks!
 -- 
 Ashish SHUKLA  | GPG: F682 CDCC 39DC 0FEA E116  20B6 C746 CFA9 E74F A4B0
 Sent from my Emacs


-- 
Matthieu Volat ma...@alkumuna.eu
tel: 06 84 54 39 43
www: http://500px.com/Mazhe


signature.asc
Description: PGP signature

Re: FreeBSD Port: ejabberd-2.1.13 - Release updates available; 14.05, 13.12 13.10

[Matthieu Volat]

On Mon, 19 May 2014 13:40:00 +0530
ash...@freebsd.org (Ashish SHUKLA) wrote:

 Hi,
 
 Thanks to the PR ports/189812[1] filed by Joseph Benden, I'm able to update
 the net-im/ejabberd to 14.05. Following is the link to the diff, if you like
 to try it:
 
 url:http://people.freebsd.org/~ashish/diffs/ejabberd-14.05.diff
 sha256: ce4ed8c47734348bc4499af3d11ae2dbc53fc50f4b2041dc557dae793706b188
 
 There is one issue though. As, I don't use PAM option, I could not check PAM
 support. This port does not install 'epam' binary anymore (although it's
 compiled). So, if you (or someone) are using PAM support already, and can test
 if it works without that binary that'll be great.
 
 If you encounter any other issues, please feel free to report those to me. I
 plan to commit this by the end of this week.
 
 References:
 [1]  http://www.freebsd.org/cgi/query-pr.cgi?pr=189812
 
 Thanks!
 -- 
 Ashish SHUKLA  | GPG: F682 CDCC 39DC 0FEA E116  20B6 C746 CFA9 E74F A4B0
 Sent from my Emacs

Thanks for your work,

I use the pam module, and the server would not start without epam:
2014-05-19 21:03:50.464 [error] 0.408.0 Can't open file
@rootdir@/lib/erlang/lib/ejabberd-14.05/priv/bin/epam: enoent

Copying the epam binary from WRKDIR, setted to root:ejabberd rwsr-x--- to 
/usr/local/lib/erlang/lib/ejabberd-14.05/priv/bin/epam is not enough, it 
seems...

-- 
Matthieu Volat ma...@alkumuna.eu



signature.asc
Description: PGP signature

Re: ACTION REQUIRED - Unstaged Ports being DEPRECATED on June 31st.

[Matthieu Volat]

On Sat, 10 May 2014 10:33:52 -0500
Bryan Drewery bdrew...@freebsd.org wrote:

 You are receiving this mail as it affects FreeBSD ports that you maintain.
 [...]
 
 If you already have PR needing to be committed please let us know and we
 will try to get on them ASAP.

I've added ports/189682 to add staging support to print/cups-pdf (which have no 
maintainer ATM):
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/189682

-- Matthieu Volat ma...@alkumuna.eu


signature.asc
Description: PGP signature

Re: ACTION REQUIRED - Unstaged Ports being DEPRECATED on June 31st.

[Matthieu Volat]

On Sat, 10 May 2014 10:47:42 -0500
Bryan Drewery bdrew...@freebsd.org wrote:

 On 5/10/2014 10:33 AM, Bryan Drewery wrote:
  You are receiving this mail as it affects FreeBSD ports that you maintain.
  
 
 You can see the full list here:
 
 http://people.freebsd.org/~bapt/notstaged.txt
 
 
 -- 
 Regards,
 Bryan Drewery
 

Regarding graphic/darktable, there have been for months an update proposal that 
included stage support: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/186979 
(while I don't agree on enforcing the entirely optionnal ninja as cmake bakend).

-- 
Matthieu Volat ma...@alkumuna.eu


signature.asc
Description: PGP signature

Re: replacing gcc with clang

[Matthieu Volat]

On Mon, 21 Apr 2014 11:58:58 +0200
Mathieu Arnold m...@freebsd.org wrote:

 +--On 20 avril 2014 20:10:39 -0400 Robert Huff roberth...@rcn.com wrote:
 | Is there a authoritative list of those ports know to not build with
 | clang 3.2/3.4?
 
 No, but you can grep for USE_GCC in the ports tree to find that out.
 
 -- 
 Mathieu Arnold

That is a start, but you would raise many false positives with ports building 
and working fine with clang, but that have an GCC option to use things like 
openmp, profiled builds, etc.

-- 
Matthieu Volat ma...@alkumuna.eu


signature.asc
Description: PGP signature

Can someone have a look at PR 185060 (audio/sonata) ?

[Matthieu Volat]

Hi everybody,

I know everybody is overloaded, but if somebody could have a look at 
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/185060

It would be nice, audio/sonata is pretty useless on freebsd now, and have been 
for more than a month… And it's getting irritating in these periods of rebuild 
to ever have to manually patch things… :(

-- Matthieu Volat


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Can someone have a look at PR 185060 (audio/sonata) ?

[Matthieu Volat]

Le 4 févr. 2014 à 14:11, Mathieu Arnold m...@freebsd.org a écrit :

 +--On 4 février 2014 09:47:58 +0100 Matthieu Volat ma...@alkumuna.eu
 wrote:
 | Hi everybody,
 | 
 | I know everybody is overloaded, but if somebody could have a look at 
 | http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/185060
 | 
 | It would be nice, audio/sonata is pretty useless on freebsd now, and have
 | been for more than a month… And it's getting irritating in these
 | periods of rebuild to ever have to manually patch things… :(
 
 Fix committed, thanks :-)
 
 -- 
 Mathieu Arnold
 

Thank you very much!


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Building specific ports with gcc in 10.0

[Matthieu Volat]

Le 3 déc. 2013 à 00:00, Matthias Andree matthias.and...@gmx.de a écrit :

 Signé partie PGP
 Am 13.11.2013 19:50, schrieb Matthieu Volat:
  Hi everybody,
 
  With the 10.0 release becoming more and more tangible, I tried to switch 
  one laptop to 10.0-BETA3 and see how it would go.
 
  I fumbled into a problem that I have a hard time to resolve: I would like 
  to build graphics/darktable with gcc (lang/gcc46 to be precise, through the 
  USE_GCC system) to benefit from openmp support.
 
  Here's the problem : graphics/darktable, mostly C, uses graphics/exiv2 
  which is written in C++, but built with clang++/libc++. So when I try to 
  build graphics/darktable, I get errors of unresolved symbols from exiv2 
  library:
 
  libdarktable.so: undefined reference to 
  `Exiv2::XmpProperties::registerNs(std::basic_stringchar, 
  std::char_traitschar, std::allocatorchar  const, 
  std::basic_stringchar, std::char_traitschar, std::allocatorchar  
  const)'
  libdarktable.so: undefined reference to 
  `Exiv2::XmpParser::encode(std::basic_stringchar, std::char_traitschar, 
  std::allocatorchar , Exiv2::XmpData const, unsigned short, unsigned 
  int)'
  libdarktable.so: undefined reference to
  `Exiv2::ExifData::operator[](std::basic_stringchar,
  std::char_traitschar, std::allocatorchar  const)'
  [...]
 
  I suppose this comes from symbol naming conventions between clang++/libc++ 
  and g++/libstdc++ (wasn't C++ ABI supposed to be standard? I guess not). If 
  I build exiv2 with g++, I can build darktable, but I feel this way of doing 
  things will be a PITA in the future.
 
  Does anybody knowledgeable with gcc know how to manage those issues?
 
 
 An older post, but since it's unanswered, here goes:
 
 I'd personally avoid mixing C++ libraries with software that complex,
 not only to spare myself the bloat, but also to avoid subtle crashes.
 
 I have run into the same issue with graphics/rawtherapee, and have
 solved it by ignoring OpenMP for now on systems that default to clang,
 and use clang to build rawtherapee on those. Not sure how well it works,
 haven't received feedback anywhere yet.
 
 Solving this for good would require changes to the ports infrastructure
 where a C++-based port can state I need libstdc++ ABI versions of
 library FOO and BAR, or, more generally, where:
 
 1. multiple libraries with different C++ ABI versions can be installed
(possibly only installing the differing ABI if there is already an
installation, as a later refinement)
 
If it required two full installations (with distinct prefix) for the
nonce, I could live with that.
 
 2. ports can choose to depend on a particular ABI version, per their
compiler preference, so that rawtherapee or darktable, if they set
USE_GCC or equivalent, will automatically depend on the libstdc++
ABI versions of libraries, and if necessary, install them.
 
 We may also need to build/install subpackages, or multiple packages from
 the same port.  I guess with STAGEDIR this has become somewhat closer to
 realizable.

Thanks, giving up on OpenMP in this case (and praying that no other c++ port 
will trigger this problem) was also my conclusion… That or begin with 
installing gcc from ports and then using it as port compiler, but I've grown to 
like clang :)

One other possible solution would be to manage having gcc to not use its c++ 
header/libstdc++, but the base headers and libc++. I see that one debian 
developer seems to achieved that 
(http://sylvestre.ledru.info/blog/2012/08/15/libc_new_c_standard_library_in_debian).

 
 
 Side remarks:
 
 a. We dug up three clang bugs in 10-STABLE so far. One only causes
 excessive compile times, two cause the compiler to run out of memory.
 dim@ helped dig up references, reduce the test cases to reasonable size;
 these issues have all been reported upstream unless the upstream
 bugtracker already knew them.
 
 b. Apparently Intel donated OpenMP to clang back in the clang-3.1 days.
 I hope that these be integrated into clang, but haven't seen much
 conclusive material.

There were some news a while ago that it was updated to clang 3.3 and the llvm 
project seems to like the idea as they put it in their project list : 
http://openmp.llvm.org/ . The problem is that it requires the intel openmp 
runtime that only build with gcc/icc for now, I tried to add clang support but 
it's not so trivial...


signature.asc
Description: Message signed with OpenPGP using GPGMail

Building specific ports with gcc in 10.0

[Matthieu Volat]

Hi everybody,

With the 10.0 release becoming more and more tangible, I tried to switch one 
laptop to 10.0-BETA3 and see how it would go.

I fumbled into a problem that I have a hard time to resolve: I would like to 
build graphics/darktable with gcc (lang/gcc46 to be precise, through the 
USE_GCC system) to benefit from openmp support. 

Here's the problem : graphics/darktable, mostly C, uses graphics/exiv2 which is 
written in C++, but built with clang++/libc++. So when I try to build 
graphics/darktable, I get errors of unresolved symbols from exiv2 library:

libdarktable.so: undefined reference to 
`Exiv2::XmpProperties::registerNs(std::basic_stringchar, 
std::char_traitschar, std::allocatorchar  const, std::basic_stringchar, 
std::char_traitschar, std::allocatorchar  const)'
libdarktable.so: undefined reference to 
`Exiv2::XmpParser::encode(std::basic_stringchar, std::char_traitschar, 
std::allocatorchar , Exiv2::XmpData const, unsigned short, unsigned int)'
libdarktable.so: undefined reference to
`Exiv2::ExifData::operator[](std::basic_stringchar,
std::char_traitschar, std::allocatorchar  const)'
[...]

I suppose this comes from symbol naming conventions between clang++/libc++ and 
g++/libstdc++ (wasn't C++ ABI supposed to be standard? I guess not). If I build 
exiv2 with g++, I can build darktable, but I feel this way of doing things will 
be a PITA in the future.

Does anybody knowledgeable with gcc know how to manage those issues?

-- 
Matthieu Volat ma...@alkumuna.eu


signature.asc
Description: PGP signature

VLC bringing in pulseaudio

[Matthieu Volat]

I've noticed that the last multimedia/vlc commit just added pulseaudio as a 
non-optional functionality to workaround an OSS bug in the latest release.

Was not it possible to rollback to VLC 2.0.x while things are being sorted out? 
Bringing in pulseaudio, which is what it is, as a solution without warning is 
a bit forceful to my liking...

-- 
Matthieu Volat ma...@alkumuna.eu


signature.asc
Description: PGP signature

net/mDNSResponder related bug reports

[Matthieu Volat]

There is a few PRs on net/mDNSResponder to fix a trivial bug that makes it 
segfault on ipv6 networks :
 * http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/182199
 * http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/182718
 * http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/182815

There have been no activity for 3 weeks, can somebody have a look at those?

I also submitted a port for an nss module that would use mDNSResponder to 
resolve hostnames on the local domain, should I withdraw the proposal since 
there has been zero feedback on this since april?
 * http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/178052

-- 
Matthieu Volat ma...@alkumuna.eu


signature.asc
Description: PGP signature

Re: [CFT] Update of xorg libraries and MESA

[Matthieu Volat]

On Tue, 17 Sep 2013 22:43:03 +0200
Matthieu Volat ma...@alkumuna.eu wrote:

 On Tue, 17 Sep 2013 20:43:11 +0300
 Vitaly Magerya vmage...@gmail.com wrote:
 
  On 09/17/2013 10:29, Matthieu Volat wrote:
   Just as a side note : I tested the devd backend and mouse  keyboard were 
   detected.
   But what would be the best way to set the keyboard layout now?
  
  You should add something like this to your xorg.conf:
  
  Section InputClass
  Identifier All The Keyboards
  MatchDevicePath /dev/*kbd*
  Option XkbLayout us,ru
  -- any other kbd(4) options here --
  EndSection
  
  (Warning: not tested).
  
  This should work with any backend, be it HAL or DEVD; see INPUTCLASS
  section of xorg.conf man page for details on how it works.
 
 Thanks, I was not aware of this section type which seems to be definitively 
 the way to go.
 
 It is indeed working with hal based configuration (after removing the bits 
 from hal config), but not so much with the devd backend.
 
 First of all, with a quite bare configuration file (no ServerFlags options), 
 I do have the following messages in log file:
 [  8342.054] (==) Not automatically adding devices
 [  8342.054] (==) Not automatically enabling devices
 
 Strangely, keyboard and mouse are added, with default settings,
 ignoring InputClass settings. If I force AutoAddDevices and
 AutoEnableDevices, these messages are switched to confirm devices will be 
 searched and enabled... Except that I don't have keyboard/mouse in this case.
 
 If it can help, here's my xorg.conf :
 https://gist.github.com/mazhe/6600263
 

Ok, I've had a few hours to poke around: it seems that calling the
config_devd_init/fini functions is not done in config/config.c, is it
by design?

If I put it, I begin to have some function if ServerFlags
AutoAddDevices and AutoEnableDevices:
[  2961.464] (II) config/devd: Adding input device Keyboard
(/dev/atkbd0)
[  2961.464] (II) No input driver specified, ignoring this device.
[  2961.464] (II) This device may have been added with another device
file.
[  2961.464] (II) config/devd: Adding input device Mouse (/dev/psm0)
[  2961.464] (II) No input driver specified, ignoring this device.
[  2961.464] (II) This device may have been added with another device
file.

This is were InputClass section should came in handy, I suppose, but I'm not 
sure this is the keyboard xserver should be using (reports unavailable when I 
try to set a driver) and I remember fighting against HAL to use /dev/sysmouse 
(moused is enabled) in favor of /dev/psm0 for the mouse device.

Also, despite even adding init/fini function to config/config.c, xserver still 
don't acknowledge I am using a hotpplugin backend :
[  4066.978] (WW) Hotplugging requested but the server was compiled
without a config backend. No input devices were configured, the server
will start without any input devices.

I'll try to poke around later, but I may not have time for this for a few days.

-- 
Matthieu Volat ma...@alkumuna.eu


signature.asc
Description: PGP signature

Re: [CFT] Update of xorg libraries and MESA

[Matthieu Volat]

Le 16 sept. 2013 à 13:53, Vitaly Magerya vmage...@gmail.com a écrit :

 Baptiste Daroussin wrote:
 1) 'usb_id' is always NULL, so 'MatchUSBID' directive in xorg.conf won't
 work;
 
 2) 'vendor' and 'product' will be determined from 'dev.x.x.%desc' sysctl
 by splitting on the first space, so for example my USB tablet, which has
 %desc equal to WALTOP International Corp. Slim Tablet will have vendor
 WALTOP and product International Corp. Slim Tablet -- so those are
 the strings I should use in 'MatchVendor' and 'MatchProduct';
 
 3) if 'devd' is restarted while Xorg is running, further hardware
 changes will not be reported to Xorg.
 
 Can you confirm I'm reading this right? If so, are there any plans to
 improving these points?
 
 Yes you are totally right about all this points this should be fixed.
 
 I have no time to work on this right now. Anyone volunteering?
 
 I am, once my flu is gone.
 
 I'm actually using a devd backend I wrote a few months ago
 (which avoids the mentioned issues), but it's rather different
 from yours (more intrusive that is): directives are added to
 devd config to call a script when devices appropriate for Xorg
 are added or removed. That script will maintain a file with the
 list of those devices; it will also print add/remove messages
 into a special pipe, if it exists. Xorg will read the file with
 the list on startup, and will create and listen to the pipe to
 see added/removed devices. This way devd restarts are safely
 handled, and the script called from devd can invoke 'usbconfig'
 to correctly determine vendor name, product name and usb id.
 
 The open problems here are:
 1) what should happen if multiple X instances are running?
 2) how to clean the file with the list of devices on boot?
 
 If you're OK with this approach in general, I can clean up my
 code, update it and submit a patch.
 ___
 freebsd-ports@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-ports
 To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Just as a side note : I tested the devd backend and mouse  keyboard were 
detected. But what would be the best way to set the keyboard layout now?

Thanks for the work, it is awesome to see we'll survive HAL deprecation :)

-- Mazhe


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [CFT] Update of xorg libraries and MESA

[Matthieu Volat]

On Tue, 17 Sep 2013 20:43:11 +0300
Vitaly Magerya vmage...@gmail.com wrote:

 On 09/17/2013 10:29, Matthieu Volat wrote:
  Just as a side note : I tested the devd backend and mouse  keyboard were 
  detected.
  But what would be the best way to set the keyboard layout now?
 
 You should add something like this to your xorg.conf:
 
 Section InputClass
 Identifier All The Keyboards
 MatchDevicePath /dev/*kbd*
 Option XkbLayout us,ru
 -- any other kbd(4) options here --
 EndSection
 
 (Warning: not tested).
 
 This should work with any backend, be it HAL or DEVD; see INPUTCLASS
 section of xorg.conf man page for details on how it works.

Thanks, I was not aware of this section type which seems to be definitively the 
way to go.

It is indeed working with hal based configuration (after removing the bits from 
hal config), but not so much with the devd backend.

First of all, with a quite bare configuration file (no ServerFlags options), I 
do have the following messages in log file:
[  8342.054] (==) Not automatically adding devices
[  8342.054] (==) Not automatically enabling devices

Strangely, keyboard and mouse are added, with default settings,
ignoring InputClass settings. If I force AutoAddDevices and
AutoEnableDevices, these messages are switched to confirm devices will be 
searched and enabled... Except that I don't have keyboard/mouse in this case.

If it can help, here's my xorg.conf :
https://gist.github.com/mazhe/6600263

-- 
Matthieu Volat ma...@alkumuna.eu


signature.asc
Description: PGP signature

enlightenment-0.17.4 hanging from xdm

[Matthieu Volat]

Hi e17 users,

I can't get e17 to start a session from xdm, and it's quite unreliable from 
startx too... There's no big error message in .xsession, it just seems to hang 
after :
RUN INIT: /usr/local/lib/enlightenment/utils/enlightenment_init
'/usr/local/share/enlightenment/data/themes/default.edj' '0'
'Enlightenment' '0.17.4'

There's no problem if I rollback to 0.17.3... I'm in 9.2-RC3 amd64 with clang 
set as port compiler... (tried to rebuild just enlightenment with gcc with no 
avail). Does anybody has found this problem and maybe a solution?

-- 
Matthieu Volat ma...@alkumuna.eu


signature.asc
Description: PGP signature

Re: enlightenment-0.17.4 hanging from xdm

[Matthieu Volat]

On Thu, 05 Sep 2013 17:49:51 +0200
Grzegorz Blach ma...@roorback.net wrote:

 On 09/05/13 17:42, Matthieu Volat wrote:
  Hi e17 users,
  
  I can't get e17 to start a session from xdm, and it's quite unreliable from 
  startx too... There's no big error message in .xsession, it just seems to 
  hang after :
  RUN INIT: /usr/local/lib/enlightenment/utils/enlightenment_init
  '/usr/local/share/enlightenment/data/themes/default.edj' '0'
  'Enlightenment' '0.17.4'
  
  There's no problem if I rollback to 0.17.3... I'm in 9.2-RC3 amd64 with 
  clang set as port compiler... (tried to rebuild just enlightenment with gcc 
  with no avail). Does anybody has found this problem and maybe a solution?
  
 
 Hi Matthieu,
 
 You need to rebuild graphics/evas-core using gcc, this should resolve
 your problem.
 

Thanks for the advice, it did not work neither... That's strange since evas 
were not even updated... I will try to rebuild every e17 port with base gcc to 
see... maybe try with the vesa driver, too...

-- 
Matthieu Volat ma...@alkumuna.eu


signature.asc
Description: PGP signature

Re: enlightenment-0.17.4 hanging from xdm

[Matthieu Volat]

On Thu, 05 Sep 2013 18:46:10 +0200
Grzegorz Blach ma...@roorback.net wrote:

 On 09/05/13 18:39, Matthieu Volat wrote:
  On Thu, 05 Sep 2013 17:49:51 +0200
  Grzegorz Blach ma...@roorback.net wrote:
  
  On 09/05/13 17:42, Matthieu Volat wrote:
  Hi e17 users,
 
  I can't get e17 to start a session from xdm, and it's quite unreliable 
  from startx too... There's no big error message in .xsession, it just 
  seems to hang after :
  RUN INIT: /usr/local/lib/enlightenment/utils/enlightenment_init
  '/usr/local/share/enlightenment/data/themes/default.edj' '0'
  'Enlightenment' '0.17.4'
 
  There's no problem if I rollback to 0.17.3... I'm in 9.2-RC3 amd64 with 
  clang set as port compiler... (tried to rebuild just enlightenment with 
  gcc with no avail). Does anybody has found this problem and maybe a 
  solution?
 
 
  Hi Matthieu,
 
  You need to rebuild graphics/evas-core using gcc, this should resolve
  your problem.
 
  
  Thanks for the advice, it did not work neither... That's strange since evas 
  were not even updated... I will try to rebuild every e17 port with base gcc 
  to see... maybe try with the vesa driver, too...
  
 
 Similar issue was reported on https://phab.enlightenment.org/T308 Please
 rebuild e17 with this patch:
 http://git.enlightenment.org/core/enlightenment.git/commit/?h=enlightenment-0.17id=b17a9b9cc9438b6dfac4402ac4107f08e23a4373
 and write me if it solves your problem

Yes, applying the patch *and* building evas-core with base gcc did the trick!

Thanks a lot for taking time to look into that!

-- 
Matthieu Volat ma...@alkumuna.eu


signature.asc
Description: PGP signature

Re: FreeBSD Port: net-p2p/transmission

[Matthieu Volat]

On Tue, 03 Sep 2013 13:48:20 -0400
Mike Jakubik mike.jaku...@intertainservices.com wrote:

 
 On 08/31/13 09:05, Matthieu Volat wrote:
  On Sat, 31 Aug 2013 09:21:56 +0100
  cr...@bayofrum.net wrote:
 
  I'm sorry that I was unable to runtime test transmission-qt.
 
  I'll try to get an instance up when I can-- is anyone else able to launch 
  transmission-qt4?  I don't think I missed any patches from opened when I 
  imported them :-(
 
  Chris
  No problem here with transmission-qt 2.82 (system is running 
  FreeBSD-9.2-RC3, qt and transmission ports are built with clang).
 
  Maybe a gdb trace would provide more info?
 
 
 Hello,
 
 Below is a simple backtrace, I'm no expert at debugging so any 
 suggestions are welcome. It should be noted that the cli version works 
 fine, i have tried recompiling all the qt4 stuff and transmission but 
 same sig 11 happens.
 
 [...]
 

Weird, it seems to happen somewhere between the qt and the libevent libraries. 
At this point, I'd consider to :
1. try to run transmission-qt after renaming ~/.config/transmission and 
~/.cache/transmission
2. report the issue upstream

-- 
Matthieu Volat ma...@alkumuna.eu


signature.asc
Description: PGP signature

Re: FreeBSD Port: net-p2p/transmission

[Matthieu Volat]

On Sat, 31 Aug 2013 09:21:56 +0100
cr...@bayofrum.net wrote:

 I'm sorry that I was unable to runtime test transmission-qt.
 
 I'll try to get an instance up when I can-- is anyone else able to launch 
 transmission-qt4?  I don't think I missed any patches from opened when I 
 imported them :-( 
 
 Chris

No problem here with transmission-qt 2.82 (system is running FreeBSD-9.2-RC3, 
qt and transmission ports are built with clang).

Maybe a gdb trace would provide more info?

-- 
Matthieu Volat ma...@alkumuna.eu


signature.asc
Description: PGP signature

Re: CFT: dovecot2-pigeonhole (sieve) users

[Matthieu Volat]

On Wed, 03 Jul 2013 14:15:02 -0500
Mark Felder f...@feld.me wrote:

 Hi all,
 
 I'm hoping someone reading this list is a Dovecot2 user that can spend a  
 few minutes testing a patch to the pigeonhole port.
 
 Basically, there's a conflict between mail/dovecot2 and  
 mail/dovecot2-pigeonhole that breaks the ability to use pkgng with those  
 ports. What I need from you is to test this patch and let me know if you  
 experience any problems with utilizing pigeonhole (sieve). It should be an  
 instantaneous result: either it works and lets you make changes, or it  
 doesn't. My brief testing proved that it binds to the correct port and  
 responds, but I don't have a proper test environment to go further.
 
 The main difference is that the dovecot2-pigeonhole port could now be  
 installed in a PREFIX if needed and its docs and headers are in their own  
 directories: %%PREFIX%%/share/doc/dovecot-pigeonhole/ and  
 %%PREFIX%%/lib/dovecot-2.2-pigeonhole/sieve/
 
 The attached is an svn diff. Your feedback would be much appreciated.
 
 
 Thanks

Sorry for the delay, I had forgot my test about it :

So far, sounds good to me, it build and installed without any messages, I'll 
let this version run on my server and report here if there is any problems.

Thanks for your work!

-- Matthieu Volat


signature.asc
Description: PGP signature

Re: 9.1-RELEASE is out - is there any hope for an actual graphics/gimp-app?

[Matthieu Volat]

On Tue, 26 Feb 2013 05:14:09 -0600
ajtiM lum...@gmail.com wrote:

 [...]
 
 Search in mailing list about GIMP 2.8 and you should find a response from 
 maintainer. As I remember we will wait on the 2.8 still...
 BTW; I use  live linux cd and it work very good. There are also OpenBSD Live 
 CDs and OpenBSD has 2.8. I don't know how is with plugins on OpenBSD.

Good news, everybody: many gnome-related ports where bumped to versions high 
enough to build babl, gegl and gimp in their latest versions.

I suppose gimp 2.8 in port is near, but the impatient can more safely use the 
updated makefiles I updated a while ago :
https://github.com/mazhe/gimp28_ports

Disclaimer : you still have to revert to gimp 2.6 before tasks like portmaster 
-r if they impact babl/gegl/gimp, as older gimp do not build with older 
babl/gegl

-- 
Matthieu Volat ma...@alkumuna.eu
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

dovecot2-pigeonhole pkgng conflicts

[Matthieu Volat]

Hi all,

I've migrated a server to pkgng and had some problem with 
mail/dovecot2-pigeonhole that install files in (at least) same docdir as 
mail/dovecot2.

I saw this is a problem that can occur with pkgng, but did not find any 
recommandation to workaround this kind of conflict, is there a prefered way? 
Should I open a PR for the maintainer?

Regards,

-- 
Matthieu Volat ma...@alkumuna.eu
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: dovecot2-pigeonhole pkgng conflicts

[Matthieu Volat]

On Wed, 23 Jan 2013 01:39:29 +0100
Baptiste Daroussin b...@freebsd.org wrote:

 On Tue, Jan 22, 2013 at 09:47:06PM +0100, Matthieu Volat wrote:
  Hi all,
  
  I've migrated a server to pkgng and had some problem with 
  mail/dovecot2-pigeonhole that install files in (at least) same docdir as 
  mail/dovecot2.
  
  I saw this is a problem that can occur with pkgng, but did not find any 
  recommandation to workaround this kind of conflict, is there a prefered 
  way? Should I open a PR for the maintainer?
  
 
 Yes a PR should be sent to the maintainer, a port should not overwrite files
 files from other ports, this should be fixed.
 
 As a workaround you can define
 dovecot-pigeonhole_UNSET=DOCS
 in you make.conf
 
 regards,
 Bapt

Thanks, I've submitted a PR.

-- 
Matthieu Volat ma...@alkumuna.eu
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: FreeBSD Port: graphics/hugin

[Matthieu Volat]

On Thu, 17 Jan 2013 16:34:59 -0600
ajtiM lum...@gmail.com wrote:

 My system: 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243826: Tue Dec  4 06:55:39 
 UTC 
 2012 r...@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386
 
 clang -v: FreeBSD clang version 3.1 (branches/release_31 156863) 20120523
 Target: i386-unknown-freebsd9.0
 Thread model: posix


I was never able to build hugin with clang, building with gcc is somewhat of a 
workaround.

-- 
Matthieu Volat ma...@alkumuna.eu
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

E17 won't start

[Matthieu Volat]

Hello everybody,

I've been unable to start an enlightenment session after the recent upgrade to 
the release.

I just have a black screen with the mouse (that can move) and nothing else. 
There is nothing that can help in ~/.xession-errors...

I've erased ~/.e and ~/.cache without any better result, does anybody have this 
problem, and luckily a workaround?

-- 
Matthieu Volat ma...@alkumuna.eu
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: E17 won't start

[Matthieu Volat]

On Sun, 23 Dec 2012 20:26:17 +0100
Matthias Apitz g...@unixarea.de wrote:

 El día Sunday, December 23, 2012 a las 08:18:22PM +0100, Matthieu Volat 
 escribió:
 
  Hello everybody,
  
  I've been unable to start an enlightenment session after the recent upgrade 
  to the release.
  
  I just have a black screen with the mouse (that can move) and nothing else. 
  There is nothing that can help in ~/.xession-errors...
  
  I've erased ~/.e and ~/.cache without any better result, does anybody have 
  this problem, and luckily a workaround?
 
 Hi Matthieu,
 
 I've stumbled about your posting and have no answer; but I'm curious: 
 enlightenment is used as the desktop in my Linux based cellphone (the
 Openmoko Freerunner), for what else enlightenment is used and especially
 in FreeBSD?
 
 Thanks for an answer in advance
 
   matthias
 -- 
 Sent from my FreeBSD netbook
 
 Matthias Apitz   |  - No system with backdoors like Apple/Android
 E-mail: g...@unixarea.de |  - No HTML/RTF in E-mail
 WWW: http://www.unixarea.de/ |  - No proprietary attachments
 phone: +49-170-4527211   |  - Respect for open standards
 ___
 freebsd-ports@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-ports
 To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
 

Hi Matthias,

Exactly the same, I and others are using it as our X11 shell/window manager 
option for freebsd desktop :) 

-- 
Matthieu Volat ma...@alkumuna.eu
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: E17 won't start

[Matthieu Volat]

On Mon, 24 Dec 2012 03:46:11 +0100
Dominic Fandrey kamik...@bsdforen.de wrote:

 On 24/12/2012 03:28, Dominic Fandrey wrote:
  On 24/12/2012 03:19, Dominic Fandrey wrote:
 
  On 23/12/2012 20:18, Matthieu Volat wrote:
  I've been unable to start an enlightenment session after the recent 
  upgrade to the release.
 
  I have the same issue.
 
  I just have a black screen with the mouse (that can move) and nothing 
  else. There is nothing that can help in ~/.xession-errors...
 
  Well it's noteworthy that after the first ESTART: SLEEP message I've
  got a line that says PAUSE !. As far as I can figure this is unusual.
 
  If there's anything /unusual/ in my install, it's that all ports that
  can be built witch clang, were built with clang.
  
  I just ran it in gdb. But gdb reports a series of signals:
  SIGTRAP
  SIGTRAP
  SIGTTIN
  SIGTRAP
  Now, finally the startup procedures are executed until:
  ESTART: 0.34318 [0.1] - Manage all windows
  ESTART: 0.36315 [0.01997] - MAIN LOOP AT LAST
  ESTART: 0.64266 [0.27951] - SLEEP
  
  at which point gdb catches a SIGSEV!
  
  If I continue from here I end up with the single PAUSE ! line and
  nothing at all happens from here on.
  
 
 I managed to fix it by building all evas-* packages with base gcc!
 
 -- 
 A: Because it fouls the order in which people normally read text.
 Q: Why is top-posting such a bad thing?
 A: Top-posting.
 Q: What is the most annoying thing on usenet and in e-mail? 
 ___
 freebsd-ports@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-ports
 To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Hooo, I definitively did not think of that, I confirm I was also building 
(almost) everything with clang (3.1).

Very well found!

At this point, we should report the problem upstream...

-- 
Matthieu Volat ma...@alkumuna.eu
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: opera 12.12

[Matthieu Volat]

On Fri, 21 Dec 2012 09:55:26 -0600
Mark Felder f...@feld.me wrote:

 On Wed, 19 Dec 2012 22:04:49 +0100
 Matthieu Volat ma...@alkumuna.eu wrote:
 
  2. (maybe) use symlinks to trick opera to use the new one and hope that 
  there is enough compatibility between both version of icu
 
 Isnt this what /etc/libmap.conf is for? You should NEVER use symlinks.
 
 http://www.freebsd.org/cgi/man.cgi?query=libmap.conf
 [...]

Oh, I did not know of this mechanism, this looks very interesting ^^

Much more cleaner and trackable that symlinks.

Meanwhile, I upgraded today to new icu and new opera and have no problem with 
both libraries...

-- 
Matthieu Volat ma...@alkumuna.eu
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: opera 12.12

[Matthieu Volat]

On Wed, 19 Dec 2012 14:24:30 -0600
ajtiM lum...@gmail.com wrote:

 After ICU update there so many problems. One of this is todays update for 
 Opera 12.12:
 
 opera
 Unable to load library icui18n Cannot load library icui18n: (Shared object 
 libicui18n.so.48 not found, required by opera) 
 
 Thanks.
 [...]

It seems to me that both /usr/local/lib/opera/liboperagtk2.so and 
/usr/local/lib/opera/liboperakde4.so look for those specific version of the icu 
libraries.

There is not much to do freebsd-side except for...
1. have the 4.8 icu version installed alongside the new one
2. (maybe) use symlinks to trick opera to use the new one and hope that there 
is enough compatibility between both version of icu
3. (maybe) disable kde and gtk backends
4. ask nicely opera for an update

-- 
Matthieu Volat ma...@alkumuna.eu
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: [RFC/HEADSUP] portmaster default -w (preserve shared libraries)

[Matthieu Volat]

On Tue, 11 Dec 2012 09:55:24 -0600
Bryan Drewery bdrew...@freebsd.org wrote:

 (As maintainer) I'm proposing to make -w the default for portmaster.
 This will preserve old shared libraries when upgrading. This helps 2 things:
 
 [...]

I have a few question about what happens if you always use this flag: 
* Do you keep every version of the shlibs you ever built on your system?
* Are there any method to clean the unused ones?
* What do we do about libraries versions that have security issues and that we 
need to get out asap?

Regards,

-- 
Matthieu Volat ma...@alkumuna.eu
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Opera vulnerability, marked forbidden instead of update?

[Matthieu Volat]

Hello,

I've noticed that www/opera was marked FORBIDDEN because of a security hole:
http://www.freebsd.org/cgi/getmsg.cgi?fetch=614275+0+current/svn-ports-head

The opera software compagny advisory indeed mark this bug as high severity, and 
mention that there is an update to fix it.

I am not familiar with the security process in ports, but would not it be 
better to update the version? Marking it FORBIDDEN do not do much for the 
userbase that does already have it installed.

I've bumped the versions in the Makefile
OPERA_VER?= 12.11
OPERA_BUILD?=   1661
and made a `make makesum reinstall`, there was no apparent problem.

Regards,

-- 
Matthieu Volat ma...@alkumuna.eu
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: Opera vulnerability, marked forbidden instead of update?

[Matthieu Volat]

On Fri, 23 Nov 2012 09:00:59 +
Matthew Seaman matt...@freebsd.org wrote:

 On 23/11/2012 08:26, Matthieu Volat wrote:
  I've noticed that www/opera was marked FORBIDDEN because of a security hole:
  http://www.freebsd.org/cgi/getmsg.cgi?fetch=614275+0+current/svn-ports-head
  
  The opera software compagny advisory indeed mark this bug as high severity, 
  and mention that there is an update to fix it.
  
  I am not familiar with the security process in ports, but would not it be 
  better to update the version? Marking it FORBIDDEN do not do much for the 
  userbase that does already have it installed.
  
  I've bumped the versions in the Makefile
  OPERA_VER?= 12.11
  OPERA_BUILD?=   1661
  and made a `make makesum reinstall`, there was no apparent problem.
 
 Marking a port 'FORBIDDEN' is a quick response measure that can be done
 without having to worry about time consuming testing the of port and so
 forth.  It's an interim measure taken to ensure that users do not
 unwittingly install software with known vulnerabilities.
 
 Yes, updating the port to a non-vulnerable version is the ideal
 response, but that may not be possible to do straight away.  You've
 sketched out the first couple of steps a port maintainer would take, but
 that 'there was no apparent problem' statement would need to be backed
 up by some more rigorous testing before a maintainer would feel
 confident in committing the update.
 
   Cheers,
 
   Matthew
 ___
 freebsd-ports@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-ports
 To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org 

Hello and thanks for the explanation,

Cheers,

-- 
Matthieu Volat ma...@alkumuna.eu
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: Help. Porting FreeOCL fails (atomic_ops.h missing, CLANG++ libc++ issues ...)

[Matthieu Volat]

On Wed, 05 Sep 2012 16:45:49 +0200
O. Hartmann ohart...@mail.zedat.fu-berlin.de wrote:

 Hello.
 
 FreeBSD has fallen back far behind the standards of modern scientific
 computing and I dsperately look for solutions having OpenCL support on
 FreeBSD anyway.
 
 I stumbled into this project recently:
 
 FreeOCL at
 http://code.google.com/p/freeocl/
 
 or the sources located at
 
 http://code.google.com/p/freeocl/downloads/detail?name=FreeOCL-0.3.6-src.tar.gzcan=2q=
 
 For your convenience, please find my naive attempt of a port attached to
 this email.
 
 Well, I tried LLVM/CLANG, but Cmake of the sources fairly fails many
 checks especuially for OpenMP. Using clang++ requisites the usage of the
 new libc++ (CXXFLAGS+= -stdlib=libc++). But this fails with this error:
 
 
 [...]
 [ 17%] Building CXX object src/CMakeFiles/FreeOCL.dir/codebuilder.cpp.o
 In file included from
 /usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/codebuilder.cpp:26:
 /usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/parser/parser.h:118:15:
 error: no viable conversion from 'std::__1::basic_istreamchar' to
 'const bool'
 const bool ok = in.get(c);
^~
 /usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/codebuilder.cpp:444:13:
 warning: 70 enumeration values not handled in switch: 'VOID', 'BOOL',
 'HALF'... [-Wswitch]
 switch(native-get_type_id())
^
 1 warning and 1 error generated.
 *** [src/CMakeFiles/FreeOCL.dir/codebuilder.cpp.o] Error code 1
 [..]
 
 
 I tried also setting USE_GCC= 4.7+ using gcc-4.7 I installed, but that
 fails with
 
 [...]
 -- Build files have been written to:
 /usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source
 ===  Building for freeocl-0.3.6
 Scanning dependencies of target FreeOCL
 [  1%] Building CXX object src/CMakeFiles/FreeOCL.dir/freeocl.cpp.o
 In file included from
 /usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/freeocl.cpp:18:0:
 /usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/freeocl.h:71:2:
 error: 'u_int64_t' does not name a type
 *** [src/CMakeFiles/FreeOCL.dir/freeocl.cpp.o] Error code 1
 [...]
 
 I think patches are required.
 
 More disturbing is the use of gcc-4.6 via
 
 USE_GCC= 4.6+
 
 The error is then a compalin about a missing include file
 
 atomic_ops.h
 
 which is located in the abandoned KSE facility of the kernel, so the
 includes seem not to be installed anymore - but since I'm not involved
 in the development, I can only guess and ask the people here.
 
 Maybe some experienced freeBSD developers with the same need for OpenCl
 is willing to pick up this and help a bit.
 
 Well, as far as I see, the FreeOCL project of Roland Borchard is a
 OpenCL library for CPU usage. As far as I can understand, if we on
 FreeBSd could have a library libOpenCL as this is usually installed by
 the nVidia BLOB drivers on Linux for the use of OpenCL/GPGPU support
 with their GPUs, this would fill a still painfull open gap in FreeBSD as
 a scientific development platform.
 
 There is still no suitable compiler for OpenCL out here for freeBSD, but
 I have still the hope that LLVM can provide such a thing in the near future.
 
 I cross post this posting also to performance in the hope finding some
 people attracted and lurd into this subject.
 
 Regards,
 
 O. Hartmann

Hello,

I've taken a quick look in that implementation : it seems to depends on 
devel/libatomic_ops even if the devs did not write any CMake checks for that 
(grrr).

After installing it, I was able to build the port with gcc-46 without problems, 
if I find some time, I will try to test it later.

Btw, did you had a look to poCL too 
(http://sourceforge.net/apps/mediawiki/pocl/index.php?title=Main_Page)? I know 
the Debian people were considering it for a base implementation, but I'm a bit 
clueless about all those foss versions coming. A comparison could be helpful ^^

-- 
Matthieu Volat ma...@alkumuna.eu
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

New experimental gimp 2.8.2 port

[Matthieu Volat]

Hi all,

I've been continuing to maintain my gimp 2.8 experimental ports, more 
rigorously checking pkg-plist files and updating to 2.8.2 (well, just 
incrementing the version number in the Makefile).

For those who are interested, until gimp 2.8 is properly imported in the port 
tree, I've put everything on a github repo:
https://github.com/mazhe/gimp28_ports

Along a script to update the dependancies and gimp itself. Still missing are 
the help ports, and a script to revert to the standard versions, I'll check 
that ASAP.

Have a nice day,

-- 
Matthieu Volat ma...@alkumuna.eu
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: CFT: vlc 2.0.3 - want to know where it works and where only partly

[Matthieu Volat]

On Thu, 2 Aug 2012 21:07:48 +0200
Juergen Lock n...@jelal.kn-bremen.de wrote:

  Indeed, my provider rtsp-streamed tv channels did not work either, with no 
  helpful messages from vlc (dead input). I'll try poking around later with 
  a (arch)linux installation on my laptop.
  
 Hm I tested rtsp with a second vlc instance setup to stream a local
 file via rtsp, that worked with the latest version I posted:
 
   http://wiki.videolan.org/Streaming
 
  Maybe your tv channels are in fact not rtsp but multicast udp aka
 `iptv'?

I see rtsp:// urls but having trouble with those channels behind my custom 
router (with NAT) was not something new. I've tested rtp streaming between a 
vlc and a mplayer instances without problem.

 
  I also noticed another error while starting from command line :
  [0x802055198] main libvlc: Running vlc with the default interface. Use 
  'cvlc' to use vlc without interface.
  [0x8021909d8] qt4 interface error: Unable to load extensions module
  [0x803c493d8] xcb_xv vout display error: shared memory allocation error: 
  Cannot allocate memory
  
  I don't get either of these two messages on 9.1 beta/amd64 with
 nvidia gfx
 
  Display still works, but that's not really a good error message still. I do 
  have the reasonable shmem settings in my /boot/loader.conf :
  kern.ipc.shmmni=1024
  kern.ipc.shmseg=1024
 
  Mine are even lower, hmm.

This one keeps getting stranger too. I don't see the message when closing every 
other Qt application, or when I play non HD videos. This might also not be a 
porting issue.

Seems I should take a detour to the vlc mailing lists for those issues :)

Keep up the good job!

-- 
Matthieu Volat ma...@alkumuna.eu
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: CFT: vlc 2.0.3 - want to know where it works and where only partly

[Matthieu Volat]

On Thu, 2 Aug 2012 01:48:58 +0200
Juergen Lock n...@jelal.kn-bremen.de wrote:

  Looks like I didn't actually enable the LIVEMEDIA knob when I `tested'
  it...  I tried to fix it (configure finds it now), tho I couldn't find
  an rtsp url that actually worked; I tested a few from here:
  
  http://wiki.multimedia.cx/index.php?title=RTSP
  
  And I also cleaned up some no longer supported knobs.  New patch here:
  
  http://people.freebsd.org/~nox/tmp/vlc-2.0.3-003.patch
 
 Fixed rtsp now:
 
   http://people.freebsd.org/~nox/tmp/vlc-2.0.3-004.patch
 
  Enjoy, :)
   Juergen

Still with the same configuration.

Indeed, my provider rtsp-streamed tv channels did not work either, with no 
helpful messages from vlc (dead input). I'll try poking around later with a 
(arch)linux installation on my laptop.

I also noticed another error while starting from command line :
[0x802055198] main libvlc: Running vlc with the default interface. Use 'cvlc' 
to use vlc without interface.
[0x8021909d8] qt4 interface error: Unable to load extensions module
[0x803c493d8] xcb_xv vout display error: shared memory allocation error: Cannot 
allocate memory

Display still works, but that's not really a good error message still. I do 
have the reasonable shmem settings in my /boot/loader.conf :
kern.ipc.shmmni=1024
kern.ipc.shmseg=1024

-- 
Matthieu Volat ma...@alkumuna.eu
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: CFT: vlc 2.0.3 - want to know where it works and where only partly

[Matthieu Volat]

On Tue, 31 Jul 2012 20:29:28 +0200 (CEST)
Juergen Lock n...@jelal.kn-bremen.de wrote:

 [...]
  New patches here, please also test with phonon-vlc if you use it:
 
   http://people.freebsd.org/~nox/tmp/vlc-2.0.3-002.patch
 
   http://people.freebsd.org/~nox/tmp/livemedia-20120404-001.patch
 [...]

Hmm, for some reason, vlc port do not find the live liveMedia installation :
# make
...
checking for live555 version 1324598400 or later... no
configure: WARNING: liveMedia is missing or its installed version is too old:
Version 2011.12.23 or later is required to proceed.
You can get an updated one from http://www.live555.com/liveMedia .
configure: error: Update live555 or pass --disable-live555 to disable RTSP 
input support.
...


When looking at the config log :
...
configure:27786: clang++ -E 
-I/usr/ports/multimedia/vlc/work/fake/usr/local/include 
-I/usr/ports/multimedia/vlc/work/vlc-2.0.3/include  -I/usr/local/include 
-I/usr/local/ffmpeg-I/usr/local/include/speex -I/usr/local/include 
-I/usr/include/liveMedia -I/usr/include/groupsock 
-I/usr/include/BasicUsageEnvironment -I/usr/include/UsageEnvironment 
conftest.cpp
conftest.cpp:121:10: fatal error: 'liveMedia_version.hh' file not found
#include liveMedia_version.hh
 ^
1 error generated.
configure:27786: $? = 1
...


I've noticed that the patched version of net/liveMedia installed itself in 
/usr/local/live, is it normal? Am I missing something?

-- 
Matthieu Volat ma...@alkumuna.eu
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: CFT: vlc 2.0.3 - want to know where it works and where only partly

[Matthieu Volat]

On Wed, 01 Aug 2012 20:34:44 +0200
Oliver Heesakkers free...@heesakkers.info wrote:

 [...]
 At the start of configure it is reported that --with-live555-tree is an 
 unrecognized option.
 Changing line 381 of the patched Makefile for vlc to:
 
 CPPFLAGS+=-I${LOCALBASE}/live/liveMedia/include
 
 and removing the backslash from the line before of course, looks like a good 
 solution to me.
 

Right!

So a bit more of reports :
FreeBSD 9.0-RELEASE-p3
amd64
CC=clang CXX=clang++ CPP=clang-cpp (base system version)

All ports up to date from a portsnap run, built with WITH_NEW_XORG and using 
the x11/nvidia-driver x11 driver (GeForce 8800GT).

build: 
need the fix above to build with livemedia support

run: 
fails to load qt interface :
% vlc
VLC media player 2.0.3 Twoflower (revision 2.0.2-93-g77aa89e)
[0x802055198] main libvlc: Running vlc with the default interface. Use 'cvlc' 
to use vlc without interface.
[0x8021909d8] main interface error: corrupt module: 
/usr/local/lib/vlc/plugins/gui/libqt4_plugin.so
Remote control interface initialized. Type `help' for help.

The strange thing is it worked with the vlc-2.0.3-001.patch version. cvlc is 
running fine. Building with base gcc/g++ is also fine.

-- 
Matthieu Volat ma...@alkumuna.eu
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

OpenMPI 1.6 port

[Matthieu Volat]

Hello everybody

As I had to deal with OpenMPI 1.6 packaging for my work, I thought that I could 
use the acquired knowledge to update the net/openmpi port after working hours.

I've attached a tar containing the updated port directory, I hope it can help a 
bit the maintainers or interested people. I did not find any problem with a few 
basic programs.

As this version changed a bunch of soname, it will impact any port depending on 
openmpi (freshports lists science/dlpoly-classic and science/meep).

Regards,

-- 
Matthieu Volat ma...@alkumuna.eu


openmpi.tar.gz
Description: Binary data
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: Building gimp-2.8

[Matthieu Volat]

On Sun, 17 Jun 2012 20:23:30 +0400
Ruslan Mahmatkhanov cvs-...@yandex.ru wrote:

 Matthieu Volat wrote on 07.05.2012 15:56:
  Hello everybody,
 
  As gimp 2.8 was released a few days ago, I naturaly tried to get it working 
  on my 9.0-RELEASE desktop :)
 
  I forked a few ports directories to bump gimp and the dependancies to the 
  needed versions. Everything seems to work quite nicely.
 
  I'm sure those modifications cannot be pushed right now in the ports tree, 
  there are quite a few version bump that would impact other ports, but I'd 
  like to share them anyway.
 
  I've attached a tarball of my files, here are the list of modified ports:
  glib20 - 2.30.2
  gio-fam-backend - 2.30.2
  atk - 2.2.0
  gtk - 2.24.10
  gdk-pixbuf2 - 2.24.1
  pango - 1.29.4
  babl - 0.1.10
  gegl - 0.2.0
  gimp - 2.8.0
 
  I hope it can help people wanting to upgrade to the lastest version of gimp.
 
 Lol, dunno how I read this thread so this message was still missed :).
 
 I checked my system with pkg_libchk and there was no ports that needed 
 rebuild for new libraries. I also rebooted, checked all my gtk2 
 applications - all of them runs fine. So I think it more need to 
 concentrate on testing gimp-depended ports, like a plugins/extensions etc.
 
 -- 
 Regards,
 Ruslan
 
 Tinderboxing kills... the drives.
 
 

I've been using a few plugins (focusblur, lqr, resynthetizer mainly) without 
any problems. The Gimp devs are realy conservative about plugin APIs, and it 
seems that even ABI wasn't broken as I did not have to rebuild any plugin.

But I haven't done the new gimp-data-extras and gimp-help (doc was released a 
few days after the app).

-- 
Matthieu Volat ma...@alkumuna.eu
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: Imagemagick: FAIL, now in Magick++/demo/analyze.sh

[Matthieu Volat]

On Sat, Jun 9, 2012 at 8:02 PM, Doug Barton dougb at freebsd.org wrote:
 The new version fails in a new location, even with the default options.


It seems to me that this failure cames from the fact that the tests try to 
dynamicaly load modules from the path where the previous version is installed 
instead of build dirs.

Basicaly, the test do the following (I've cut through various shell wrappers to 
be able to use gdb):

cd /usr/ports/graphics/ImageMagick/work/ImageMagick-6.7.7-7
env LD_LIBRARY_PATH=magick/.libs:wand/.libs:Magick++/lib/.libs 
MAGICK_CODER_MODULE_PATH=coders/.libs MAGICK_FILTER_MODULE_PATH=filters/.libs 
./Magick++/demo/.libs/analyze ./Magick++/demo/model.miff

The problem is, you can check by running the test through gdb, that amongst the 
dlopen-ed libraries, 
/usr/local/lib/ImageMagick-6.7.7/modules-Q16/filters/analyze.so is used as if 
the MAGICK_FILTER_MODULE_PATH environment variable was not working.

A quick and dirty test is to save 
/usr/local/lib/ImageMagick-6.7.7/modules-Q16/filters/analyze.so and 
/usr/local/lib/ImageMagick-6.7.7/modules-Q16/filters/analyze.la, and to replace 
them with the versions just built. In my case, the test passed.

I am not too sure about how to fix that however... If I have some time, I will 
check that the MAGICK_FILTER_MODULE_PATH value is really checked before the 
normal installation path.

About my setup : I'm running freebsd 9.0, amd64 and building with clang, openmp 
support is disabled.

-- 
Matthieu Volat ma...@alkumuna.eu
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: Building gimp-2.8

[Matthieu Volat]

On Mon, 7 May 2012 15:38:03 -0500
ajtiM lum...@gmail.com wrote:

 [...]
 
 I like to give a try but I am not familliar with ports (I never dd). Maybe we 
 will be lucky and GIMP 2.8 show in ports soon.
 
 Mitja
 
 http://jpgmag.com/people/lumiwa
 [...]

It's not really hard, you just have to run make deinstall reinstall clean as 
root in each package directory in the order I gave in the first mail.

The only concern is that I'm not sure how related packages of a few 
dependencies will react (glib bindings?) and did not test the impact in heavily 
integrated desktops (especialy gnome, I'm just running a few standalone gtk 
apps).

But I hope that it will help the port team :)

-- 
Matthieu Volat ma...@alkumuna.eu
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Building gimp-2.8

[Matthieu Volat]

Hello everybody,

As gimp 2.8 was released a few days ago, I naturaly tried to get it working on 
my 9.0-RELEASE desktop :)

I forked a few ports directories to bump gimp and the dependancies to the 
needed versions. Everything seems to work quite nicely.

I'm sure those modifications cannot be pushed right now in the ports tree, 
there are quite a few version bump that would impact other ports, but I'd like 
to share them anyway.

I've attached a tarball of my files, here are the list of modified ports:
glib20 - 2.30.2
gio-fam-backend - 2.30.2
atk - 2.2.0
gtk - 2.24.10
gdk-pixbuf2 - 2.24.1
pango - 1.29.4
babl - 0.1.10
gegl - 0.2.0
gimp - 2.8.0

I hope it can help people wanting to upgrade to the lastest version of gimp.

-- 
Matthieu Volat ma...@alkumuna.eu


ports-gimp-2.8.tar.xz
Description: Binary data
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org