Re: No update for a day on ports?

2021-04-01 Thread Milan Obuch 
On Thu, 1 Apr 2021 09:47:04 +0200, Mathieu Arnold 
wrote:

> On Thu, Apr 01, 2021 at 09:16:15AM +0200, Milan Obuch wrote:
> > Also, what about svn mirror, as is done for src repository, for 11
> > and 12 branches at least? I did not tried it recently, but it used
> > to work. For some boxes, adding git to the mix would be big PITA.  
> 
> There will be no Git to Subversion conversion for ports, like for
> docs. The only reason there is for the base system on 11 and 12 is
> because Subversion was the source control software used when they
> were released.
> 

This is unpleasant move for me. This means git or equivalent (and
dependencies) must be installed on any box where tracking ports tree is
planned/needed... and no tool like svnlite could be expected in base
system for some time.

So I need some work on my local infrastructure to adjust to this move.
C'est la vie...

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

Re: No update for a day on ports?

2021-04-01 Thread Milan Obuch 
On Thu, 1 Apr 2021 09:35:11 +0200, Kurt Jaeger  wrote:

> Hi!
> 
> > > The repo moved/is moving to git, so svn is no longer updated.  
> 
> > I did not catch any notice about the move. I know it was planned,
> > but not announcing actual move is... not that nice.  
> 
> The announcement was this post, although it was maybe a bit terse
> on the exact date:
> 
> https://lists.freebsd.org/pipermail/freebsd-ports/2021-March/120566.html
> 

OK, but one more mail 'HEADSUP: Move to git just started, see $URL' sent
here yesterday would make everything much better visible.

Don't take this as critique, move to git is surely big move, and,
judging from src transition to git and its outcome, allows for better
tooling as well.

As an old fart, I am against changing tools just for the sake of
change, and being not involved in the process directly, I am just
waiting for the end. Only then I start to evaluate new state... I think
there are many like me here.

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

Re: No update for a day on ports?

2021-04-01 Thread Milan Obuch 
On Thu, 1 Apr 2021 09:09:16 +0200, Kurt Jaeger  wrote:

> Hi!
> 
> > did somebody encountered this issue? I am using svn daily to update
> > ports tree on some (maybe 15, exact number not important) boxes. No
> > new updates today. I noticed it first actually yesterday afternoon
> > or early evening, but I did not consider asking then.  
> 
> The repo moved/is moving to git, so svn is no longer updated.
> 

I did not catch any notice about the move. I know it was planned, but
not announcing actual move is... not that nice.

On the other side, it did no damage actually, it was just unusual or
unexpected behavior.

Also, what about svn mirror, as is done for src repository, for 11 and
12 branches at least? I did not tried it recently, but it used to work.
For some boxes, adding git to the mix would be big PITA.

Regards,
Milan
___
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"

No update for a day on ports?

2021-04-01 Thread Milan Obuch 
Hi,

did somebody encountered this issue? I am using svn daily to update
ports tree on some (maybe 15, exact number not important) boxes. No new
updates today. I noticed it first actually yesterday afternoon or early
evening, but I did not consider asking then.

Is there some breakage in ports infrastructure? I see request comming
in on ports-bugs mailing list, but no update past revision 569609.
Also, I did not read anything on switching to git for ports, but I
would expect svn mirror for older (11 and 12) systems anyway as it is
done for src tree now.

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

Re: Erroneous lines in /usr/ports/MOVED

2021-02-05 Thread Milan Obuch 
On Fri, 5 Feb 2021 12:04:36 +0100, Fernando Apesteguía
 wrote:

> On Fri, Feb 5, 2021 at 11:33 AM Milan Obuch 
> wrote:
> 
> > On Fri, 5 Feb 2021 09:59:46 +0100, Fernando Apesteguía
> >  wrote:
> >  
> > > On Thu, Feb 4, 2021 at 11:36 PM Milan Obuch
> > >  wrote:
> > >  
> > > > After updating ports tree now portmaster bails out on old
> > > > gstreamer ports, now moved to gstreamer1 ones. I found there
> > > > are some errors in MOVED file, which, at least for me, could be
> > > > fixed using patch in attachment.
> > > >  
> > >
> > > Done in https://svnweb.freebsd.org/changeset/ports/564092
> > >
> > > Thanks!
> > >
> > >  
> > > >
> > > > Maybe my fix is not the best, so I leave it for more experienced
> > > > ones... but this is what worked for me.
> > > >
> > > > Regards,
> > > > Milan
> > > >  
> > >  
> >
> > I did a bit more checks after I noticed there are similar errors on
> > other gstreamer ports moved onto gstreamer1 ones.
> >
> > Please review (and possibly commit) patch in attachment.
> >
> > I did not notice them earlier because at the moment I was interested
> > just in quick fix for what I have installed locally.
> >  
> 
> OK, I reviewed all gstreamer entries and they should be fixed now (
> https://svnweb.freebsd.org/changeset/ports/564108)
> 
> Thanks again!
> 

I think so, too. Thanks for fixing the issue.

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

Re: Erroneous lines in /usr/ports/MOVED

2021-02-05 Thread Milan Obuch 
On Fri, 5 Feb 2021 09:59:46 +0100, Fernando Apesteguía
 wrote:

> On Thu, Feb 4, 2021 at 11:36 PM Milan Obuch 
> wrote:
> 
> > After updating ports tree now portmaster bails out on old gstreamer
> > ports, now moved to gstreamer1 ones. I found there are some errors
> > in MOVED file, which, at least for me, could be fixed using patch in
> > attachment.
> >  
> 
> Done in https://svnweb.freebsd.org/changeset/ports/564092
> 
> Thanks!
> 
> 
> >
> > Maybe my fix is not the best, so I leave it for more experienced
> > ones... but this is what worked for me.
> >
> > Regards,
> > Milan
> >
>

I did a bit more checks after I noticed there are similar errors on
other gstreamer ports moved onto gstreamer1 ones.

Please review (and possibly commit) patch in attachment.

I did not notice them earlier because at the moment I was interested
just in quick fix for what I have installed locally.

Regards,
Milan
--- MOVED   2021-02-05 10:50:24.656315000 +0100
+++ MOVED.fix   2021-02-05 11:03:54.347849000 +0100
@@ -16098,20 +16098,20 @@
 
audio/gstreamer-plugins-twolame|audio/gstreamer1-plugins-twolame|2021-02-04|Replaced
 by gstreamer1
 
audio/gstreamer-plugins-vorbis|audio/gstreamer1-plugins-vorbis|2021-02-04|Replaced
 by gstreamer1
 
audio/gstreamer-plugins-wavpack|audio/gstreamer1-plugins-wavpack|2021-02-04|Replaced
 by gstreamer1
-graphics/gstreamer-plugins-aalib|net/gstreamer1-plugins-aalib|2021-02-04|Replaced
 by gstreamer1
-graphics/gstreamer-plugins-cairo|net/gstreamer1-plugins-cairo|2021-02-04|Replaced
 by gstreamer1
+graphics/gstreamer-plugins-aalib|graphics/gstreamer1-plugins-aalib|2021-02-04|Replaced
 by gstreamer1
+graphics/gstreamer-plugins-cairo|graphics/gstreamer1-plugins-cairo|2021-02-04|Replaced
 by gstreamer1
 graphics/gstreamer-plugins-gconf||2021-02-04|Replaced by gstreamer1
-graphics/gstreamer-plugins-gdkpixbuf|net/gstreamer1-plugins-gdkpixbuf|2021-02-04|Replaced
 by gstreamer1
+graphics/gstreamer-plugins-gdkpixbuf|graphics/gstreamer1-plugins-gdkpixbuf|2021-02-04|Replaced
 by gstreamer1
 graphics/gstreamer-plugins-gio||2021-02-04|Replaced by gstreamer1
-graphics/gstreamer-plugins-gl|net/gstreamer1-plugins-gl|2021-02-04|Replaced by 
gstreamer1
+graphics/gstreamer-plugins-gl|graphics/gstreamer1-plugins-gl|2021-02-04|Replaced
 by gstreamer1
 graphics/gstreamer-plugins-gnomevfs||2021-02-04|Replaced by gstreamer1
-graphics/gstreamer-plugins-jpeg|net/gstreamer1-plugins-jpeg|2021-02-04|Replaced
 by gstreamer1
-graphics/gstreamer-plugins-libcaca|net/gstreamer1-plugins-libcaca|2021-02-04|Replaced
 by gstreamer1
+graphics/gstreamer-plugins-jpeg|graphics/gstreamer1-plugins-jpeg|2021-02-04|Replaced
 by gstreamer1
+graphics/gstreamer-plugins-libcaca|graphics/gstreamer1-plugins-libcaca|2021-02-04|Replaced
 by gstreamer1
 
graphics/gstreamer-plugins-libpng|graphics/gstreamer1-plugins-png|2021-02-04|Replaced
 by gstreamer1
-graphics/gstreamer-plugins-libvisual|net/gstreamer1-plugins-libvisual|2021-02-04|Replaced
 by gstreamer1
-graphics/gstreamer-plugins-opencv|net/gstreamer1-plugins-opencv|2021-02-04|Replaced
 by gstreamer1
+graphics/gstreamer-plugins-libvisual|graphics/gstreamer1-plugins-libvisual|2021-02-04|Replaced
 by gstreamer1
+graphics/gstreamer-plugins-opencv|graphics/gstreamer1-plugins-opencv|2021-02-04|Replaced
 by gstreamer1
 graphics/gstreamer-plugins-sdl||2021-02-04|Replaced by gstreamer1
-graphics/gstreamer-plugins-soup|graphics/gstreamer-plugins-soup|2021-02-04|Replaced
 by gstreamer1
+graphics/gstreamer-plugins-soup|devel/gstreamer1-plugins-soup|2021-02-04|Replaced
 by gstreamer1
 multimedia/gstreamer-ffmpeg|multimedia/gstreamer1-libav|2021-02-04|Replaced by 
gstreamer1
 
multimedia/gstreamer-plugins-all|multimedia/gstreamer1-plugins-all|2021-02-04|Replaced
 by gstreamer1
 multimedia/gstreamer-plugins-annodex||2021-02-04|Replaced by gstreamer1
___
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"

Erroneous lines in /usr/ports/MOVED

2021-02-04 Thread Milan Obuch 
After updating ports tree now portmaster bails out on old gstreamer
ports, now moved to gstreamer1 ones. I found there are some errors in
MOVED file, which, at least for me, could be fixed using patch in
attachment.

Maybe my fix is not the best, so I leave it for more experienced
ones... but this is what worked for me.

Regards,
Milan
--- MOVED   2021-02-04 23:25:05.038678000 +0100
+++ MOVED.fix   2021-02-04 23:24:59.068265000 +0100
@@ -16107,15 +16107,15 @@
 graphics/gstreamer-plugins-gnomevfs||2021-02-04|Replaced by gstreamer1
 
graphics/gstreamer-plugins-jpeg|net/gstreamer1-plugins-jpeg|2021-02-04|Replaced 
by gstreamer1
 
graphics/gstreamer-plugins-libcaca|net/gstreamer1-plugins-libcaca|2021-02-04|Replaced
 by gstreamer1
-graphics/gstreamer-plugins-libpng|net/gstreamer1-plugins-png|2021-02-04|Replaced
 by gstreamer1
+graphics/gstreamer-plugins-libpng|graphics/gstreamer1-plugins-png|2021-02-04|Replaced
 by gstreamer1
 
graphics/gstreamer-plugins-libvisual|net/gstreamer1-plugins-libvisual|2021-02-04|Replaced
 by gstreamer1
 
graphics/gstreamer-plugins-opencv|net/gstreamer1-plugins-opencv|2021-02-04|Replaced
 by gstreamer1
 graphics/gstreamer-plugins-sdl||2021-02-04|Replaced by gstreamer1
 
graphics/gstreamer-plugins-soup|graphics/gstreamer-plugins-soup|2021-02-04|Replaced
 by gstreamer1
 multimedia/gstreamer-ffmpeg|multimedia/gstreamer1-libav|2021-02-04|Replaced by 
gstreamer1
-multimedia/gstreamer-plugins-all|multimedia-gstreamer1-plugins-all|2021-02-04|Replaced
 by gstreamer1
+multimedia/gstreamer-plugins-all|multimedia/gstreamer1-plugins-all|2021-02-04|Replaced
 by gstreamer1
 multimedia/gstreamer-plugins-annodex||2021-02-04|Replaced by gstreamer1
-multimedia/gstreamer-plugins-bad|multimedia-gstreamer1-plugins-bad|2021-02-04|Replaced
 by gstreamer1
+multimedia/gstreamer-plugins-bad|multimedia/gstreamer1-plugins-bad|2021-02-04|Replaced
 by gstreamer1
 multimedia/gstreamer-plugins-bz2||2021-02-04|Replaced by gstreamer1
 
multimedia/gstreamer-plugins-core|multimedia/gstreamer1-plugins-core|2021-02-04|Replaced
 by gstreamer1
 
multimedia/gstreamer-plugins-dts|multimedia/gstreamer1-plugins-dts|2021-02-04|Replaced
 by gstreamer1
@@ -16132,10 +16132,10 @@
 
multimedia/gstreamer-plugins-ugly|multimedia/gstreamer1-plugins-ugly|2021-02-04|Replaced
 by gstreamer1
 
multimedia/gstreamer-plugins-v4l2|multimedia/gstreamer1-plugins-v4l2|2021-02-04|Replaced
 by gstreamer1
 multimedia/gstreamer-plugins-vdpau||2021-02-04|Replaced by gstreamer1
-multimedia/gstreamer-plugins-vp8|8|2021-02-04|Replaced by gstreamer1
+multimedia/gstreamer-plugins-vp8||2021-02-04|Replaced by gstreamer1
 
multimedia/gstreamer-plugins-x264|multimedia/gstreamer1-plugins-x264|2021-02-04|Replaced
 by gstreamer1
 multimedia/gstreamer-plugins-xvid||2021-02-04|Replaced by gstreamer1
-multimedia/gstreamer-plugins|multimedia-gstreamer1-plugins|2021-02-04|Replaced 
by gstreamer1
+multimedia/gstreamer-plugins|multimedia/gstreamer1-plugins|2021-02-04|Replaced 
by gstreamer1
 multimedia/gstreamer|multimedia/gstreamer1|2021-02-04|Replaced by gstreamer1
 net/gstreamer-plugins-libmms|net/gstreamer1-plugins-libmms|2021-02-04|Replaced 
by gstreamer1
 
sysutils/gstreamer-plugins-cdio|sysutils/gstreamer1-plugins-cdio|2021-02-04|Replaced
 by gstreamer1
___
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"

Conflicts with mail/courier port

2020-05-11 Thread Milan Obuch 
Hi,

I am preparing new mail/courier port. There is an issue with conflicts,
current port version is 0.65.3 and new one will be 1.0.13 (or higher,
if upstream release comes sooner).

Currently I found following lines in Makefiles for relevant ports:

mail/courier-imap
CONFLICTS=  courier-[0-9]* imap-uw-[0-9]* panda-imap-[0-9]*

mail/maildrop
CONFLICTS=  courier-0.65* libunicode-[0-9]*

mail/meta1
CONFLICTS=  smx-*
CONFLICTS+= courier-0.* postfix-1.* postfix-2.* smail-3.* zmailer-2.* 
opensmtpd-* sendmail-*

mail/panda-imap
CONFLICTS_INSTALL=  imap-uw-20* courier-0.65.*

mail/postfix
CONFLICTS_INSTALL?= courier-0.* opensmtpd-[0-9]* sendmail-8.* 
sendmail+*-8.* \

mail/postfix-current
CONFLICTS_INSTALL?= courier-0.* opensmtpd-[0-9]* sendmail-8.* 
sendmail+*-8.* \

mail/sendmail
CONFLICTS?= courier-0.* postfix-1.* postfix-2.* smail-3.* zmailer-2.* 
opensmtpd-*
CONFLICTS+= sendmail-ldap-8.* sendmail-sasl2-8.* sendmail-tls-8.*
CONFLICTS+= sendmail-sasl2-8.* sendmail-tls-8.*
CONFLICTS+= sendmail-ldap-8.* sendmail-tls-8.*
CONFLICTS+= sendmail-ldap-8.* sendmail-sasl2-8.*
CONFLICTS2!=${MAKE_PKGNAMES} | ${GREP} -v 
"${PORTNAME}${PKGNAMESUFFIX:S|${PKGNAMESUFFIX2}||}-8."
CONFLICTS+= ${CONFLICTS2}

mail/sendmail-devel
CONFLICTS?= courier-0.* postfix-1.* postfix-2.* smail-3.* zmailer-2.* 
opensmtpd-*
CONFLICTS+= sendmail-ldap-8.* sendmail-sasl2-8.* sendmail-tls-8.*
CONFLICTS+= sendmail-sasl2-8.* sendmail-tls-8.*
CONFLICTS+= sendmail-ldap-8.* sendmail-tls-8.*
CONFLICTS+= sendmail-ldap-8.* sendmail-sasl2-8.*
CONFLICTS2!=${MAKE_PKGNAMES} | ${GREP} -v 
"${PORTNAME}${PKGNAMESUFFIX:S|${PKGNAMESUFFIX2}||}-8."
CONFLICTS+= ${CONFLICTS2}

I did not analyze the conflict itself, if you plan install mail/courier
port, i. e. full mail server suite, it is not wise to install another
mail server suite or some component. I just think it would be good to
upgrade conflict expression in mentioned ports. This could be done now
not taking into account new port is not yet submitted.

Maybe simplest action would be just use what's in mail/courier-imap
port, I think it is universal, but would like to hear second oppinion.

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

Re: www/luakit users?

2019-03-16 Thread Milan Obuch 
On Sat, 16 Mar 2019 10:09:32 +0100
Stefan Hagen  wrote:

> Milan Obuch wrote:
> > maintainer address from port at that time... po...@textmail.me  
> 
> This is mine and it shouldn't bounce. Hmm. I'll look into it.
>

Just tried it again, in my mail server log it gets:

554 5.7.1 : Recipient address rejected: Access denied

> > Well, my personal preference for such a project would be mailing
> > list with archive, as it is quite common here, maybe wiki, which
> > exists for luakit too, but it is marked outdated. Current issue
> > tracker would need at least some easy to use search engine...  
> 
> The current issue tracker is Github. Is this search not sufficient?
> 
> Just so we talk about the same...
> Web: https://luakit.github.io (or luakit.org)
> Source: https://github.com/luakit/luakit
> 
> The update to the latest Version (2.1) has not yet been committed:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233711
> 
> There was mailing list / google group in the past, but has been 
> discontinued in favor of IRC and the Github issue tracker.
>

Personal preferences/taste differs... I'll look into it again.

> >>> What I need find now is following: in a special arrangement, I
> >>> have luakit started directly from startx script, so I have some
> >>> kind of kiosk. Basically it works OK, I just need change mouse
> >>> cursor shape. Googling did not reveal anything for me, but maybe
> >>> someone knows better than I...  
> >>
> >> Will "xsetroot -cursor_name arrow" fix this for you?
> >>  
> > I'll try - I just need to find the right place to put it in (startx
> > itself, or start from luakit...)  
> 
> Put it into the .xinitrc before luakit.
>

Seems good, I'll test.

> > Is it possible to use newer sources? There is no newer source
> > tarball published, but it should be possible to use some carefully
> > chosen snapshot from GitHub... That being written, I have no much
> > experiences with choosing the right one, actually I am just
> > discovering luakit and found it really interesting.  
> 
> Using snapshots was not a good idea in the state the software was/is. 
> Due to active developments, lot of incompatible changes where made
> which broke the configuration. I don't want to push anything to
> FreeBSD which breaks configuration without having documentation ready
> about how to fix it.
> 
> However, building the latest version from source or doing a small
> change in the port to target a snapshot is not a big undertaking. 
> 
> > Also, I would like to change cursor shapes used in luakit. Could you
> > advice something? I am testing luakit in XFCE, but I have special
> > setup with luakit started directly from xinit with no window
> > manager as well, where this ability is requested.  
> 
> Luakit right now is not doing anything with the cursor. What you can
> do is to either set the cursor with Xorg tools before starting luakit
> or you can open a feature request on Github and describe the desired
> behavior. Luakit could probably set the arrow cursor and maybe a hand
> over links like firefox does.
>

I'll test the former first.

> I won't patch features into the port, so the request should go to 
> upstream luakit.
> 

Reasonable, understood.

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

Re: www/luakit users?

2019-03-15 Thread Milan Obuch 
On Fri, 15 Mar 2019 11:47:11 +0100
Stefan Hagen  wrote:

> Hi Milan,
> 
> Milan Obuch wrote:
> > some time ago I tried to write port maintainer just to get bounce
> > back... Now I see maintainer is reset.  
> 
> Which E-Mail Address did you use? I took over the laukit port about a
> year ago when development started to happen again and the migration to
> webkit2 has happened.
>

Hi,

maintainer address from port at that time... po...@textmail.me

> > I am curious if I can find some other users of this really
> > interesting browser, maybe try to build development version...
> > There is no much info I found, but it still seems to be actively
> > developed, at least there are some new entries in issue tracker.  
> 
> It is surely not a mainstream browser, but you can find a few users on
> OFTC in #luakit
>

No idea what's OFTC is... but luakit is surely really interesting,
scripting abilities are interesting. Also, it is lightweight, at least
compared with standard browsers like chrome, firefox and similar.

> I agree that the issue tracker is a bit messy right now. Many entries 
> are for the old webkit1 version of luakit. Some of them may not be
> valid anymore after the refactoring, some still might be. Some
> plugins could still be migrated.
>

Well, my personal preference for such a project would be mailing list
with archive, as it is quite common here, maybe wiki, which exists for
luakit too, but it is marked outdated. Current issue tracker would need
at least some easy to use search engine...

> > What I need find now is following: in a special arrangement, I have
> > luakit started directly from startx script, so I have some kind of
> > kiosk. Basically it works OK, I just need change mouse cursor shape.
> > Googling did not reveal anything for me, but maybe someone knows
> > better than I...  
> 
> So I assume after starting X you have the "X" shaped mouse cursor.

Yes - something like this. And some kind of arrow when hovering over
link.

> Will "xsetroot -cursor_name arrow" fix this for you?
> 

I'll try - I just need to find the right place to put it in (startx
itself, or start from luakit...)

Thanks for hint.

Regards,
Milan

N. B. Here is a copy of my older mail, which bounced, jff (just for fun)

Hi,

this address is listed as maintainer of luakit port for FreeBSD...

Is it possible to use newer sources? There is no newer source tarball
published, but it should be possible to use some carefully chosen
snapshot from GitHub... That being written, I have no much experiences
with choosing the right one, actually I am just discovering luakit and
found it really interesting.

Also, I would like to change cursor shapes used in luakit. Could you
advice something? I am testing luakit in XFCE, but I have special setup
with luakit started directly from xinit with no window manager as well,
where this ability is requested.

Regards,
Milan
___
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"

www/luakit users?

2019-03-14 Thread Milan Obuch 
Hi,

some time ago I tried to write port maintainer just to get bounce
back... Now I see maintainer is reset.

I am curious if I can find some other users of this really
interesting browser, maybe try to build development version... There is
no much info I found, but it still seems to be actively developed, at
least there are some new entries in issue tracker.

What I need find now is following: in a special arrangement, I have
luakit started directly from startx script, so I have some kind of
kiosk. Basically it works OK, I just need change mouse cursor shape.
Googling did not reveal anything for me, but maybe someone knows better
than I...

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

Re: py-setuptools fails to build with FLAVOR

2017-12-08 Thread Milan Obuch 
On Fri, 08 Dec 2017 14:41:29 -0600
Paul Schmehl  wrote:

> # cd ../py-setuptools
> [root@colo11 /usr/ports/devel/py-setuptools]# make distclean
> ===>  Cleaning for py27-setuptools-36.5.0
> ===>  Cleaning for py35-setuptools-36.5.0
> ===>  Cleaning for py36-setuptools-36.5.0
> ===>  Cleaning for py34-setuptools-36.5.0
> ===>  Deleting distfiles for py27-setuptools-36.5.0  
> [root@colo11 /usr/ports/devel/py-setuptools]# make FLAVOR=py27 install
> ===>  License PSFL accepted by the user
> ===>   py27-setuptools-36.5.0 depends on file: /usr/local/sbin/pkg -
> found => setuptools-36.5.0.zip doesn't seem to exist in   
> /usr/ports/distfiles/python.
> => Attempting to fetch   
> https://files.pythonhosted.org/packages/source/s/setuptools/setuptools-36.5.0.zip
> setuptools-36.5.0.zip 100% of  704 kB 4447
> kBps 00m00s
> ===> Fetching all distfiles required by py27-setuptools-36.5.0 for
> building ===>  Extracting for py27-setuptools-36.5.0
> => SHA256 Checksum OK for python/setuptools-36.5.0.zip.
> ===>  Patching for py27-setuptools-36.5.0
> ===>  Applying FreeBSD patches for py27-setuptools-36.5.0  
> Ignoring previously applied (or reversed) patch.
> 1 out of 1 hunks ignored--saving rejects to 
> setuptools/command/install_egg_info.py.rej
> => FreeBSD patch patch-setuptools__command__install_egg_info.py
> failed to apply cleanly.
> *** Error code 1
> 
> Stop.
> make: stopped in /usr/ports/devel/py-setuptools
> 
> Are we in a catch22?
> 
> Paul Schmehl, Retired
> 

I found following works for me:

portmaster -o devel/py-setuptools py27-setuptools-36.5.0

Afterwards I was able to update some dependent ports as if they were
not flavored (did not check).

So I think worth to try, but no guarantee other than it seemingly did
not break in my case.

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

Re: Working on FLAVOR support in portmaster

2017-12-05 Thread Milan Obuch 
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.
>

Thank you! Great news.

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

As I understand it, portmaster is kind of wrapper around ports
infrastructure. What makes it complicated is a good number corner cases
which are not easy to handle right.

In my experience, even unaltered still kind of works for me with recet
port tree. I did even upgrade some python ports with it, so chances are
it could be done.

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

This is not easy to tell... Is there still interest in old pkg_tools?
In my opinion, old pkg_tools should be in history (and I know I did use
them as long as it was kind of working before moving to current pkg).
How much of portmaster code deals with this legacy tools? Removing this
code could have positive effect of less code to deal with means less
space for bugs... Or portmaster-legacy port could be created, if there
is real interest.

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

Re: mail/roundcube - strange error

2017-03-22 Thread Milan Obuch 
On Tue, 21 Mar 2017 14:48:37 +0100
Milan Obuch <freebsd-po...@dino.sk> wrote:

> Hi,
> 
> I am trying to install mail/roundcube port on dedicated VM and issuing
> make in /usr/ports/mail/roundcube yields

[ snip ]

> /bin/mkdir-p /usr/ports/mail/roundcube/work/stage/usr/local/www/roundcube
> *** Error code 127

[ snip ]

For a record, I found the problem using 'make -d A' command. It gives
tons of debug output, most important is it displayed

*** Failed target:  do-install

and the exact command failing was missing cpio binary. Could our ports
framework be a bit more descriptive in such a case? Default output
suggests problem with mkdir binary, which is misleading and simply not
true... In my case it was caused by using WITHOUT_CPIO in
buildworld/installworld environment, so one could tell it is a pilot
error, but even if accept this being the case, error message is a bit
cryptic. Displaying failed command would be great help, I don't know,
how hard it is - in this case, it was

*** Failed command:
cd /usr/ports/mail/roundcube/work/roundcubemail-1.2.3 && /bin/sh -c
'(/usr/bin/find -Ed $0 $2 | /usr/bin/cpio -dumpl $1 >/dev/null 2>&1)
&& /usr/bin/find -Ed $0 $2 \( -type d -exec /bin/sh -c '\''cd
'\''$1'\'' && chmod 755 "$@"'\'' -- . {} + -o -type f -exec /bin/sh -c
'\''cd '\''$1'\'' && chmod 555 "$@"'\'' -- . {} + \)' --
bin /usr/ports/mail/roundcube/work/stage/usr/local/www/roundcube

(next line from 'make -d A' output, long, harder to parse, but really
meaningfull).

Regards,
Milan
___
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"

mail/roundcube - strange error

2017-03-21 Thread Milan Obuch 
Hi,

I am trying to install mail/roundcube port on dedicated VM and issuing
make in /usr/ports/mail/roundcube yields

===>  License GPLv3 accepted by the user
===>  Found saved configuration for roundcube-1.2.3,1
===>   roundcube-1.2.3,1 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by roundcube-1.2.3,1 for building
===>  Extracting for roundcube-1.2.3,1
=> SHA256 Checksum OK for roundcubemail-1.2.3-complete.tar.gz.
===>  Patching for roundcube-1.2.3,1
===>  Applying FreeBSD patches for roundcube-1.2.3,1
===>  Configuring for roundcube-1.2.3,1
===>  Staging for roundcube-1.2.3,1
===>   roundcube-1.2.3,1 depends on file: /usr/local/include/php/main/php.h - 
found
===>   roundcube-1.2.3,1 depends on file: 
/usr/local/lib/php/20131226/mbstring.so - found
===>   roundcube-1.2.3,1 depends on file: 
/usr/local/lib/php/20131226/session.so - found
===>   roundcube-1.2.3,1 depends on file: /usr/local/lib/php/20131226/iconv.so 
- found
===>   roundcube-1.2.3,1 depends on file: /usr/local/lib/php/20131226/dom.so - 
found
===>   roundcube-1.2.3,1 depends on file: /usr/local/lib/php/20131226/xml.so - 
found
===>   roundcube-1.2.3,1 depends on file: /usr/local/lib/php/20131226/json.so - 
found
===>   roundcube-1.2.3,1 depends on file: /usr/local/lib/php/20131226/intl.so - 
found
===>   roundcube-1.2.3,1 depends on file: /usr/local/lib/php/20131226/zip.so - 
found
===>   roundcube-1.2.3,1 depends on file: /usr/local/lib/php/20131226/filter.so 
- found
===>   roundcube-1.2.3,1 depends on file: 
/usr/local/lib/php/20131226/openssl.so - found
===>   roundcube-1.2.3,1 depends on file: 
/usr/local/lib/php/20131226/fileinfo.so - found
===>   roundcube-1.2.3,1 depends on file: /usr/local/lib/php/20131226/exif.so - 
found
===>   roundcube-1.2.3,1 depends on file: 
/usr/local/lib/php/20131226/pdo_mysql.so - found
===>   Generating temporary packing list
/bin/mkdir -p /usr/ports/mail/roundcube/work/stage/usr/local/www/roundcube
*** Error code 127

Stop.
make[1]: stopped in /usr/ports/mail/roundcube
*** Error code 1

Stop.
make: stopped in /usr/ports/mail/roundcube

It is not my first rouncube installation, but it is first time I see
this error. I can't find the meaning of error code 127, 'perror 127'
says just 'Unknown error: 127'. Directory requested to be
created, /usr/ports/mail/roundcube/work/stage/usr/local/www/roundcube
exists after process stop.

Any idea what could be wrong? It is on 11.0-STABLE built from svn
revision 313674.

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

Re: Port require a missing libraries: libgdk_pixbuf-2.0.so.0

2015-11-23 Thread Milan Obuch 
On Sun, 22 Nov 2015 00:34:42 +0100
Xavier  wrote:

> Hello,
> 
> I ran in a strange problem I cannot fix :
> 
> [root@valinor ~]# pkg check -d
> Checking all packages: 100%
> graphviz has require a missing libraries: libgdk_pixbuf-2.0.so.0
> gtk-engines2 has require a missing libraries: libgdk_pixbuf-2.0.so.0
> gtk-update-icon-cache has require a missing libraries: 
> libgdk_pixbuf-2.0.so.0
> gtk2 has require a missing libraries: libgdk_pixbuf-2.0.so.0
> [...]
> 
> However, GTK programs run fine, and the library is here :
> 
> [root@valinor ~]# pkg which /usr/local/lib/libgdk_pixbuf-2.0.so.0
> /usr/local/lib/libgdk_pixbuf-2.0.so.0 was installed by package 
> gdk-pixbuf2-2.32.1
> [root@valinor ~]# ls -alF /usr/local/lib/libgdk_pixbuf-2.0.so.0
> lrwxr-xr-x  1 root  wheel  29 Nov 22 00:10 
> /usr/local/lib/libgdk_pixbuf-2.0.so.0@ ->
> libgdk_pixbuf-2.0.so.0.3200.1
> 
> So I rebuild the whole stuff :
> 
> [root@valinor ~]# portupgrade -vf graphviz gtk-engines2 
> gtk-update-icon-cache gtk2 [...]
> 
> The build process finishes fine but the error "has require a missing 
> libraries: libgdk_pixbuf-2.0.so.0" is still here
> 
> How can this happen ?
> 
> Thanks
> 
> Xav
> 

Hi,

while I have no answer, just some more observation. In my case, I have
three instances with this kind of error, with various packages
installed, with the same library 'missing', but everything works. It
occured for the first time after upgrading pkg, maybe from version 1.4
to 1.5 or something similar, I have no exact number available. Current
version is 1.6.1 at the change occured 3 or 4 upgrades before.

Even reinstalling everything does not help, so I think there is a bug
in database write function, I just have no idea about its exact nature.

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

Re: What's going on with svn server?

2015-08-03 Thread Milan Obuch 
On Mon, 3 Aug 2015 09:07:06 +0200
Kurt Jaeger li...@opsec.eu wrote:

 Hi!
 
   svn: E210005: Unable to connect to a repository at URL
   'svn://svn.freebsd.org/ports/head' svn: E210005: No repository
   found in 'svn://svn.freebsd.org/ports/head'
  
  Same problem here.
  
  Access still works from repo.freebsd.org, but only via svn+ssh.
 
 Peter Wemm fixed it.
 

Confirmed. I just found it works again. Thanks.

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

What's going on with svn server?

2015-08-02 Thread Milan Obuch 
Hi,

there is something unexpected with svn.freebsd.org:

# svnlite update /usr/ports
Updating '/usr/ports':
svn: E210005: Unable to connect to a repository at URL 
'svn://svn.freebsd.org/ports/head'
svn: E210005: No repository found in 'svn://svn.freebsd.org/ports/head'

DNS seems to be working, svn.freebsd.org resolves to CNAME
svnmir.geo.freebsd.org. which resolves to A 213.138.116.72, so
something happened on server side, probably.

Or did I missed something? It worked for me just as expected
yesterday...

Regards,
Milan
___
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

pkg check -s -a output unusable/incomplete

2014-12-07 Thread Milan Obuch 
Hi,

today it occured to me due some power outage or something unexpected
like that caused filesystem breakage. fsck with journal was not able to
repair damage and the result was repeated restart. It is a virtual
machine on HyperV hypervisor, by the way, but that is irrelevant to the
problem I like to report and ask for solution if known or some hints.

Basically, there are 91 ports/packages installed, everything works
normally well. Then, issuing command 'pkg check -s -a' to find damages
I was able to identify package, p5-Locale-gettext-1.05_4, as one with
some damage to its files, but no more clue thereafter, that's what I
got:

# pkg check -s -a
Checking all packages:   2%
pkg: pkg_create_from_dir(lstat failed): No such file or directory
Checking all packages:  24%
pkg: pkg_create_from_dir(lstat failed): No such file or directory
Checking all packages: 100%
#

I knew I needed to rebuild/reinstall asterisk (some modules were not
able to load, which manifests itself clearly so is easily
identifiable), after that, the same command's output somewhat changed:

# pkg check -s -a
Checking all packages:  24%
pkg: pkg_create_from_dir(lstat failed): No such file or directory
Checking all packages: 100%
#

and no idea now which package needs reinstall.

Any idea on this one? There is no indication which file does not exist
(and should, it would not be checked for in the first place if that's
not the case) nor package name which should be reinstalled in order to
fix the issue.

Regards,
Milan
___
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: pkg check -s -a output unusable/incomplete

2014-12-07 Thread Milan Obuch 
On Sun, 07 Dec 2014 11:43:24 +0100
Xavier xav...@groumpf.org wrote:

 On 07/12/14 09:38, Milan Obuch wrote:
 
  # pkg check -s -a
  Checking all packages:  24%
  pkg: pkg_create_from_dir(lstat failed): No such file or directory
  Checking all packages: 100%
  #
  
  and no idea now which package needs reinstall.
 
 Agreed. One need to use verbose output to identifiy the problem.
 
 Xav
 

Thanks, 'pkg check -s -a -v' gives a clue here:

[23/91] Checking gettext-tools-0.19.3: checksums...pkg:
pkg_create_from_dir(lstat failed): No such file or directory

Rebuilding/reinstalling gettext-tools-0.19.3 makes a clean check now.
Anyway, in such an anomaly case, I would prefer message in non verbose
check to include package name, at least.

Regards,
Milan
___
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: courier-0.65.3_3

2014-10-06 Thread Milan Obuch 
On Mon, 06 Oct 2014 16:41:46 -0400
Christopher T. Stone ch...@stoneyforest.net wrote:

  On Sun, 14 Sep 2014 01:16:03 -0400
  Saigol.ca Admin admin at saigol.ca wrote:
  
  Hello,
  
  It seems that the Courier-MTA current version is 0.73.2.
  
  The latest FreeBSD port is based on version 0.65.3, which seems to
  be more than 3 years old.  Are there any plans to update the port
  to the latest version of the software?
  
  Thanks,
  
  Abid
  
  
  Yes, there are. Unfortunatelly, other tasks have currently more
  urgent attention here, and there are some issues to be solved - new
  dependencies are introduced and new port should be created first for
  library needed to build new courier... also old port was recently
  staged, which was necessary to keep it in tree at all. Also it looks
  like recently a bit more work needs to be put into patch to get new
  version committed into port tree, so it will take a bit of time
  before new version of mail/courier could be published in port tree.
  
  Before that, I will contact you as soon as I will have something to
  test. Your setup is most probably different from mine and thus 
  together
  we can cover more usage scenarios, which is good thing everytime.
  
  Regards,
  Milan
 
 Milan  Abid,
 
 I'm still working on checking functionality, but the liked diff
 builds (the new Unicode library was already in the ports tree). I
 only reviewed the old patches that were broken, anything that applied
 cleanly I left, those that were broken need a fair number of changes
 so I suspect the rest could use some review.
 
 Link to diff:
 http://stoneyforest.net/~chris/courier-0.73.2-20141006.diff.gz
 
 Apply to the mail/courier directory with:
 gunzip -c ../courier-0.73.2-20141006.diff.gz | patch
 
 ~Chris Stone


Big thanks for the patch. I am going to verify it here in my test
setup. If it works for you, it will do hopefully for me as well. Abid,
could you test it too? If nothing bad comes from my testing, I will
prepare upgrade for port then.

Regards,
Milan
___
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: courier-0.65.3_3

2014-09-14 Thread Milan Obuch 
On Sun, 14 Sep 2014 01:16:03 -0400
Saigol.ca Admin ad...@saigol.ca wrote:

 Hello,
 
 It seems that the Courier-MTA current version is 0.73.2.
 
 The latest FreeBSD port is based on version 0.65.3, which seems to be 
 more than 3 years old.  Are there any plans to update the port to the 
 latest version of the software?
 
 Thanks,
 
 Abid


Yes, there are. Unfortunatelly, other tasks have currently more urgent
attention here, and there are some issues to be solved - new
dependencies are introduced and new port should be created first for
library needed to build new courier... also old port was recently
staged, which was necessary to keep it in tree at all. Also it looks
like recently a bit more work needs to be put into patch to get new
version committed into port tree, so it will take a bit of time before
new version of mail/courier could be published in port tree.

Before that, I will contact you as soon as I will have something to
test. Your setup is most probably different from mine and thus together
we can cover more usage scenarios, which is good thing everytime.

Regards,
Milan
___
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: mail/courier build failures on newer FreeBSD versions

2014-05-26 Thread Milan Obuch 
On Mon, 26 May 2014 02:45:45 -0500
Scot Hetzel swhet...@gmail.com wrote:

  On Mon, May 26, 2014 at 12:04 AM, Milan Obuch
 freebsd-po...@dino.sk wrote:
  On Mon, 26 May 2014 03:29:55 +0200
  Matthias Andree matthias.and...@gmx.de wrote:

[ snip ]

  OK, I already began work on staging, this was just a small side step
  fixing another issue, in my eyes easily acceptable, but when it
  needs now be done in other order, fine.
 
  Milan, if you could share some of the troubles you're encountering,
  people may be able to help you.
 
 
  Well, I did 'make check-plist', here is part of its output:
 
  Error: Orphaned: %%ETCDIR%%/%%MAILOWN%%/%%MAILOWN%%d
  Error: Orphaned: %%ETCDIR%%/%%MAILOWN%%/esmtpd
  Error: Orphaned: %%ETCDIR%%/%%MAILOWN%%/esmtpd-msa
  Error: Orphaned: %%ETCDIR%%/%%MAILOWN%%/esmtpd-ssl
  Error: Orphaned: %%ETCDIR%%/%%MAILOWN%%/imapd
  Error: Orphaned: %%ETCDIR%%/%%MAILOWN%%/imapd-ssl
  Error: Orphaned: %%ETCDIR%%/%%MAILOWN%%/ldapaddressbook
  Error: Orphaned: %%ETCDIR%%/%%MAILOWN%%/%%CACHEOWN%%3d
  Error: Orphaned: %%ETCDIR%%/%%MAILOWN%%/%%CACHEOWN%%3d-ssl
  Error: Orphaned: %%ETCDIR%%/%%MAILOWN%%/sqwebmaild
  Error: Orphaned: %%ETCDIR%%/%%MAILOWN%%/webmlmrc
 
  It does not take much time to revert, for me, at least in this case,
  unnecessary substitution, some times a bit comic, to
 
  Error: Orphaned: etc/courier/courierd
  Error: Orphaned: etc/courier/esmtpd
  Error: Orphaned: etc/courier/esmtpd-msa
  Error: Orphaned: etc/courier/esmtpd-ssl
  Error: Orphaned: etc/courier/imapd
  Error: Orphaned: etc/courier/imapd-ssl
  Error: Orphaned: etc/courier/ldapaddressbook
  Error: Orphaned: etc/courier/pop3d
  Error: Orphaned: etc/courier/pop3d-ssl
  Error: Orphaned: etc/courier/sqwebmaild
  Error: Orphaned: etc/courier/webmlmrc
 
 I looked at the ports Makefile, but didn't see how these files are
 installed.  Are they being installed by the Courier's source
 Makefile's?  If they are, you just need to stop it from creating them,
 as they will be created when pkg installs the port.


They are comming from pkg-plist, see below...

  All these files are configuration files and all are handled this
  way:
 
  @unexec cmp -s %D/etc/courier/courierd %D/etc/courier/courierd.dist
   rm -f %D/etc/courier/courierd 2/dev/null || true
  etc/courier/courierd.dist
  @exec [ -f %D/etc/courier/courierd.dist ] 
  %%LOCALBASE%%/share/sysconftool/sysconftool
  %D/etc/courier/courierd.dist
 
  which does create them if they do not exist copying file.dist as
  template on install and if they are still the same on unistall, they
  are deleted. This way user configuration does not get lost across
  upgrades, and sysconftool merges new configuration items when they
  are introduced.
 
  This behavior is broken when I add these files into pkg-plist, they
  are simply deleted on uninstall and user-made changes in
  configuration is lost. How should this issue be solved? I think
  there should be a method to tell 'this file should be specially
  handled, ignore it, it is not an orphan' for make check-plist...
 
 
 The new way to specify sample configuration files is to use the
 @sample keyword in the pkg-plist:
 
 @sample etc/courier/courierd.sample
 @sample etc/courier/esmtpd.sample
 @sample etc/courier/esmtpd-msa.sample
 @sample etc/courier/esmtpd-ssl.sample
 @sample etc/courier/imapd.sample
 @sample etc/courier/imapd-ssl.sample
 @sample etc/courier/ldapaddressbook.sample
 @sample etc/courier/pop3d.sample
 @sample etc/courier/pop3d-ssl.sample
 @sample etc/courier/sqwebmaild.sample
 @sample etc/courier/webmlmrc.sample
 
 Note: you would have to change the port to install the files with a
 .sample suffix, instead of a .dist suffix.
 

Where can I find this docummented? I read in some mailing list post
about @sample, found this in Porter's handbook,
http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/plist-config.html
but I would like to see what it actually does... I will try, but
nevertheless, better description would be thanked for...

Milan
___
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: mail/courier build failures on newer FreeBSD versions

2014-05-26 Thread Milan Obuch 
On Mon, 26 May 2014 17:23:51 +0200
Dimitry Andric d...@freebsd.org wrote:

 On 25 May 2014, at 21:38, Milan Obuch freebsd-po...@dino.sk wrote:
  pkg-fallout-buil...@freebsd.org sends me every other day mails about
  failing mail/courier build for both 10.0 and 11.0 FreeBSD versions.
  There is some incompatibility with GCC 4.7, which is used to build
  mail/courier on systems with system compiler switched to clang. It
  works, however, with GCC 4.6, this is tested on both 10.0-STABLE and
  11.0-CURRENT systems, both i386 and amd64 architectures.
 
 Please try this diff, which makes mail/courier compile with clang.  I
 also verified that it builds with gcc 4.7 and 4.8.
 
 -Dimitry

Thanks, I will test it. If it works, no need to use external compiler =
less dependencies... for me, a good thing.

Milan
___
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: mail/courier build failures on newer FreeBSD versions

2014-05-26 Thread Milan Obuch 
On Mon, 26 May 2014 10:30:57 -0500
Scot Hetzel swhet...@gmail.com wrote:

 On Mon, May 26, 2014 at 3:05 AM, Milan Obuch freebsd-po...@dino.sk
 wrote:
  On Mon, 26 May 2014 02:45:45 -0500
  Scot Hetzel swhet...@gmail.com wrote:
 
   On Mon, May 26, 2014 at 12:04 AM, Milan Obuch
  freebsd-po...@dino.sk wrote:

[ snip ]

   Error: Orphaned: etc/courier/courierd
   Error: Orphaned: etc/courier/esmtpd
   Error: Orphaned: etc/courier/esmtpd-msa
   Error: Orphaned: etc/courier/esmtpd-ssl
   Error: Orphaned: etc/courier/imapd
   Error: Orphaned: etc/courier/imapd-ssl
   Error: Orphaned: etc/courier/ldapaddressbook
   Error: Orphaned: etc/courier/pop3d
   Error: Orphaned: etc/courier/pop3d-ssl
   Error: Orphaned: etc/courier/sqwebmaild
   Error: Orphaned: etc/courier/webmlmrc
  
  I looked at the ports Makefile, but didn't see how these files are
  installed.  Are they being installed by the Courier's source
  Makefile's?  If they are, you just need to stop it from creating
  them, as they will be created when pkg installs the port.
 
 
  They are comming from pkg-plist, see below...
 
 When these files are installed into the STAGEDIR, the @exec lines in
 the pkg-plist are not executed.  They are only executed when pkg
 installs the freshly created courier-0.65.3 package.
 
 I noticed that the post-install target has:
 
 316 @${GREP} '^@exec ' ${TMPPLIST} \
 317 | ${SED} -e 's:^@exec ::' -e 's:%D:${PREFIX}:g' \
 318  ${WRKDIR}/.PLIST.exec \
 319  ${SH} ${WRKDIR}/.PLIST.exec
 
 This looks like it might cause the issue, especially if you had
 changed it to:
 
 316 @${GREP} '^@exec ' ${TMPPLIST} \
 317 | ${SED} -e 's:^@exec ::' -e 's:%D:${STAGEDIR}${PREFIX}:g' \
 318  ${WRKDIR}/.PLIST.exec \
 319  ${SH} ${WRKDIR}/.PLIST.exec
 
 You should be able to remove this from the ports Makefile, as pkg will
 run the @exec lines when the package is installed.


This part of port was there long time ago, before I adopt it as
mantainer... which means it could solve some old issue and cause
others. I will definitelly try what you suggest.

[ snip ]

  The new way to specify sample configuration files is to use the
  @sample keyword in the pkg-plist:
 
  @sample etc/courier/courierd.sample
  @sample etc/courier/esmtpd.sample
  @sample etc/courier/esmtpd-msa.sample
  @sample etc/courier/esmtpd-ssl.sample
  @sample etc/courier/imapd.sample
  @sample etc/courier/imapd-ssl.sample
  @sample etc/courier/ldapaddressbook.sample
  @sample etc/courier/pop3d.sample
  @sample etc/courier/pop3d-ssl.sample
  @sample etc/courier/sqwebmaild.sample
  @sample etc/courier/webmlmrc.sample
 
  Note: you would have to change the port to install the files with a
  .sample suffix, instead of a .dist suffix.
 
 
  Where can I find this docummented? I read in some mailing list post
  about @sample, found this in Porter's handbook,
  http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/plist-config.html
  but I would like to see what it actually does... I will try, but
  nevertheless, better description would be thanked for...
 
 
 I had found the info on @sample here:
 
 http://www.freebsd.org/doc/en/books/porters-handbook/plist-keywords.html#plist-keywords-your-own
 
 It is implemented in ${PORTSDIR}/Keywords.
 

All .dist files are coming from distribution tarball, so it could be
error-prone a bit to find them all and rename them. For now, I leave it
as is... if it will continue to work :)

Milan
___
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: mail/courier build failures on newer FreeBSD versions

2014-05-26 Thread Milan Obuch 
On Mon, 26 May 2014 17:47:37 +0200
Kurt Jaeger li...@opsec.eu wrote:

 Hi!
 
   Do you also plan to upgrade to 0.73. ? With 0.65 we're badly
   behind the times, aren't we ?
   
   Yes, this upgrade is long due, but it has some issues too.
   
   What issues does 0.73.1 have ? Is there a list somewhere ?
   
   Frankly, courier looses more and more marketshare, as can be seen
   on
   
   http://openemailsurvey.org
 
   Which features are available on courier which are not provided
   by other MTAs ?
 
  Kurt, we're not asking porters to justify why a particular software
  is ported.
 
 I'm sorry if my mail was seen as too inquisitorial. I'm asking because
 I manage quite a few mailservers and it's becoming more and more
 like telco-equipment: lots of features which make them very
 difficult to compare. Like DANE, which currently seems to be
 a postfix-exclusive feature.


I did not take it that way. Sometimes I would like too why somebody
choose something, so I just answered... and if other questions are
asked, they will be answered, if I know the answers that is.

 Milan provided a very good reason for courier: courier is fully
 integrated. I was not aware of that.

  We also don't normally question the usefulness of a port on its
  own or based on surveys either.  So can we please stop this useless
  distraction and stop killing the porter's motivation, and instead
  see to get the necessary help furnished so the port gets back into
  good shape?
 
 Sorry for that, I do not try to kill the motivation. Because
 the time/change difference between the 0.65.3 and 0.73.1 is so large
 (3 years, and approx. 150K diff), I'm interested in learning
 why it's not easy to update.
 

In my eyes question like this is not that bad. It is true that courier
mail suite is not that popular, so there is not so big pressure to hunt
for upgrades, when it just works for me the way it is :) sort of
laziness, you know...

Regards,
Milan
___
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

mail/courier build failures on newer FreeBSD versions

2014-05-25 Thread Milan Obuch 
Hi,

pkg-fallout-buil...@freebsd.org sends me every other day mails about
failing mail/courier build for both 10.0 and 11.0 FreeBSD versions.
There is some incompatibility with GCC 4.7, which is used to build
mail/courier on systems with system compiler switched to clang. It
works, however, with GCC 4.6, this is tested on both 10.0-STABLE and
11.0-CURRENT systems, both i386 and amd64 architectures.

This port needs some more work, it does not support stage, which I am
currently working on, but this is not so easy for me, yet, and I must
solve some problems until it works well.

In the mean time, could someone review PR ports/190209 which addresses
this issue (http://www.freebsd.org/cgi/query-pr.cgi?pr=190209)? It is
really simple and should solve package builder failures for [REL -
10i386-default], [REL - 10amd64-default], [REL - 10i386-quarterly],
[REL - 10amd64-quarterly], [REL - head-i386-default] and [REL -
head-amd64-default].

Thanks in advance and regards,

Milan
___
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: mail/courier build failures on newer FreeBSD versions

2014-05-25 Thread Milan Obuch 
On Sun, 25 May 2014 22:10:08 +0200
Kurt Jaeger p...@opsec.eu wrote:

 Hi!
 
  In the mean time, could someone review PR ports/190209 which
  addresses this issue
  (http://www.freebsd.org/cgi/query-pr.cgi?pr=190209)? It is really
  simple and should solve package builder failures for [REL -
  10i386-default], [REL - 10amd64-default], [REL - 10i386-quarterly],
  [REL - 10amd64-quarterly], [REL - head-i386-default] and [REL -
  head-amd64-default].
 
 The commit system rejects ports which are still unstaged, so we
 we need a patch which also addresses staging.
 
 As far as I understand, you are the maintainer ?
 

Yes, I just use unique addresses for mailing lists...

Patch for stage is in works, but as mail/courier is a complex port, I
need to investigate various cases. Currently I work on pkg-plist, and
some questions will come, I am sure.

I just do not like to submit uncomplete work, and patch mentioned
solves the other issue, and being simple...

Regards,
Milan
___
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: mail/courier build failures on newer FreeBSD versions

2014-05-25 Thread Milan Obuch 
On Sun, 25 May 2014 22:43:14 +0200
Kurt Jaeger li...@opsec.eu wrote:

 Hi!
 
In the mean time, could someone review PR ports/190209 which
addresses this issue
(http://www.freebsd.org/cgi/query-pr.cgi?pr=190209)? It is
really simple and should solve package builder failures for
[REL - 10i386-default], [REL - 10amd64-default], [REL -
10i386-quarterly], [REL - 10amd64-quarterly], [REL -
head-i386-default] and [REL - head-amd64-default].
   
   The commit system rejects ports which are still unstaged, so we
   we need a patch which also addresses staging.
 
   As far as I understand, you are the maintainer ?
 
  Yes, I just use unique addresses for mailing lists...
  
  Patch for stage is in works, but as mail/courier is a complex port,
  I need to investigate various cases. Currently I work on pkg-plist,
  and some questions will come, I am sure.
 
 Do you also plan to upgrade to 0.73. ? With 0.65 we're badly behind
 the times, aren't we ?


Yes, this upgrade is long due, but it has some issues too. So I would
like to work on it in a step by step manner... it looks like staging is
actually prerequisite now :(

  I just do not like to submit uncomplete work, and patch mentioned
  solves the other issue, and being simple...
 
 Well, I have a patch for eclipse-devel, which is not accepted,
 because it's not staged either. So I'm in the same situation 8-}
 

It's a pity... anyway, I am working on it, however slowly...

Milan
___
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: mail/courier build failures on newer FreeBSD versions

2014-05-25 Thread Milan Obuch 
On Sun, 25 May 2014 23:19:55 +0200
Kurt Jaeger li...@opsec.eu wrote:

 Hi!
 
   Do you also plan to upgrade to 0.73. ? With 0.65 we're badly
   behind the times, aren't we ?
 
  Yes, this upgrade is long due, but it has some issues too.
 
 What issues does 0.73.1 have ? Is there a list somewhere ?


Well, maybe not issues, but there are new dependencies, so that needs
testing... and I like to keep number of dependencies minimal.

 Frankly, courier looses more and more marketshare, as can be seen on
 
 http://openemailsurvey.org


But it is still relevant - being the second one, even if with some loss
compared to previous year, I think. And I see nothing about smtp here,
only many unknowns... do not confuse courier and courier-imap, as is
often the case even on courier's mauiling lists...

 Which features are available on courier which are not provided
 by other MTAs ?
 

I can't actually make a comparison. But I like courier being the
complete solution, one package covering all protocols and features
(smtp, pop3, imap, http based webmail, maildrop filtering, mailing list
and some others) and its configuration structure is for me relatively
easy to understand. But that's personal preference, for sure.

Milan
___
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: mail/courier build failures on newer FreeBSD versions

2014-05-25 Thread Milan Obuch 
On Mon, 26 May 2014 03:29:55 +0200
Matthias Andree matthias.and...@gmx.de wrote:

[ snip ]

 I'd suggest to let Milan work on the port and tell him the
 constraints - for instance, that now staging needs to be addressed
 first and then the build-on-10 issue.


OK, I already began work on staging, this was just a small side step
fixing another issue, in my eyes easily acceptable, but when it needs
now be done in other order, fine.

 Milan, if you could share some of the troubles you're encountering,
 people may be able to help you.


Well, I did 'make check-plist', here is part of its output:

Error: Orphaned: %%ETCDIR%%/%%MAILOWN%%/%%MAILOWN%%d
Error: Orphaned: %%ETCDIR%%/%%MAILOWN%%/esmtpd
Error: Orphaned: %%ETCDIR%%/%%MAILOWN%%/esmtpd-msa
Error: Orphaned: %%ETCDIR%%/%%MAILOWN%%/esmtpd-ssl
Error: Orphaned: %%ETCDIR%%/%%MAILOWN%%/imapd
Error: Orphaned: %%ETCDIR%%/%%MAILOWN%%/imapd-ssl
Error: Orphaned: %%ETCDIR%%/%%MAILOWN%%/ldapaddressbook
Error: Orphaned: %%ETCDIR%%/%%MAILOWN%%/%%CACHEOWN%%3d
Error: Orphaned: %%ETCDIR%%/%%MAILOWN%%/%%CACHEOWN%%3d-ssl
Error: Orphaned: %%ETCDIR%%/%%MAILOWN%%/sqwebmaild
Error: Orphaned: %%ETCDIR%%/%%MAILOWN%%/webmlmrc

It does not take much time to revert, for me, at least in this case,
unnecessary substitution, some times a bit comic, to

Error: Orphaned: etc/courier/courierd
Error: Orphaned: etc/courier/esmtpd
Error: Orphaned: etc/courier/esmtpd-msa
Error: Orphaned: etc/courier/esmtpd-ssl
Error: Orphaned: etc/courier/imapd
Error: Orphaned: etc/courier/imapd-ssl
Error: Orphaned: etc/courier/ldapaddressbook
Error: Orphaned: etc/courier/pop3d
Error: Orphaned: etc/courier/pop3d-ssl
Error: Orphaned: etc/courier/sqwebmaild
Error: Orphaned: etc/courier/webmlmrc

All these files are configuration files and all are handled this way:

@unexec cmp -s %D/etc/courier/courierd %D/etc/courier/courierd.dist 
rm -f %D/etc/courier/courierd 2/dev/null || true
etc/courier/courierd.dist
@exec [ -f %D/etc/courier/courierd.dist ] 
%%LOCALBASE%%/share/sysconftool/sysconftool %D/etc/courier/courierd.dist

which does create them if they do not exist copying file.dist as
template on install and if they are still the same on unistall, they
are deleted. This way user configuration does not get lost across
upgrades, and sysconftool merges new configuration items when they are
introduced.

This behavior is broken when I add these files into pkg-plist, they are
simply deleted on uninstall and user-made changes in configuration is
lost. How should this issue be solved? I think there should be a method
to tell 'this file should be specially handled, ignore it, it is not an
orphan' for make check-plist...

 Regarding staging, check http://wiki.freebsd.org/ports/StageDir first,
 then see the porter's handbook - especially the section on the USES
 features -, and you may also find worth a read, and a current checkout
 of /usr/ports/CHANGES.


Well, I am already using first one mentioned, I verify there is an
example dealing with configuration files exactly the same way I use in
my port on wiki. I will look a bit more into porter's handbook, and
into /usr/ports/CHANGES too...

Hey, I just found a simple solution to my problem there! Using @comment
for such files works well... just as I need, just the way it worked
until now. Lesson taken.

Could this solution be put on http://wiki.freebsd.org/ports/StageDir
too? It would make all this really much easier, not only for me, I
think... please... :)

 If there are C++ troubles that involve std::_1 symbols during link
 time, the graphics/* ports that I maintain may give some hints to
 solve them.


No such problems - or maybe it is solved with using GCC 4.6 for newer
FreeBSD version, I don't know. Not that important at this time, anyway.

 Milan, feel free to ask questions, that's what the list is for.  Other
 people may have overcome similar challenges that you are facing and be
 able to share their findings.
 

Yes, I know, that's the reason I wrote my original post. I am going to
eliminate other 'make check-plist' findings, so I can take a step
further down the road...

Regards,
Milan
___
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: ftp/curl without GSSAPI

2014-03-29 Thread Milan Obuch 
On Sat, 29 Mar 2014 10:35:09 +0200
l...@lena.kiev.ua wrote:

 In `man curl`:
 
--krb level
   (FTP) Enable Kerberos authentication and use. The level
 must  be entered and should be one of 'clear', 'safe',
 'confidential', or 'private'. Should you use a level that  is  not
 one  of  these, 'private' will instead be used.
 
   This  option  requires  a library built with kerberos4
 or GSSAPI (GSS-Negotiate) support. This is not very common. Use -V,
 --ver- sion to see if your curl supports it.
 
 ~ $ curl -V
 curl 7.35.0 (i386-portbld-freebsd8.4) libcurl/7.35.0 OpenSSL/1.0.1f
 zlib/1.2.3 libssh2/1.4.3 Protocols: dict file ftp ftps gopher http
 https imap imaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp
 Features: AsynchDNS Largefile NTLM NTLM_WB SSL libz TLS-SRP ~ $
 
 `make config` offers choice of GSSAPI support via
 base system, security/heimdal and security/krb5.
 The base system option was always selected.
 I use 8.4-RELEASE i386, its base doesn't contain libgssapi.
 curl versions up to and including 7.35.0 worked without GSSAPI
 (which I needn't). Fresh curl (7.36.0) fails to build:
 
 ---  Upgrading 'curl-7.35.0' to 'curl-7.36.0' (ftp/curl)
 ...
 ===   curl-7.36.0 depends on file: /usr/local/lib/libcrypto.so.8 -
 found ===   curl-7.36.0 depends on file: /usr/local/bin/perl5.16.3 -
 found ===   curl-7.36.0 depends on shared library: libssh2.so - found
  - found
 ===  Configuring for curl-7.36.0
 ...
 checking run-time libs availability... failed
 configure: error: one or more libs available at link-time are not
 available run-time. Libs used at link-time: -lssh2 -lgssapi -lz ===
 Script configure failed unexpectedly. Please report the problem to
 sunp...@freebsd.org [maintainer] and attach the
 /usr/ports/ftp/curl/work/curl-7.36.0/config.log including the
 output of the failure of your make command. Also, it might be a good
 idea to provide an overview of all packages installed on your system
 (e.g. a /usr/sbin/pkg_info -Ea). *** Error code 1
 Stop in /usr/ports/ftp/curl.
 
 How to force curl 7.36.0 to build without GSSAPI?


Just unselect all GSS-related option. It is 'none or one of' option
group, not 'exactly one of' kind.

Milan
___
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: mail/courier build error in poudriere

2013-08-30 Thread Milan Obuch 
On Fri, 30 Aug 2013 15:27:43 +0400
Marat Bakeev haw...@hawara.com wrote:

 Hello.
 
 I'm trying to build mail/courier using poudriere on 9.1-RELEASE-p4
 amd64 in i386 jail.
 It fails with the following error:
 
 ===phase: build
  ===  Building for courier-0.65.3_1
  cd .  /usr/local/bin/automake-1.14 --foreign
 automake-1.14: warning: autoconf input should be named 'configure.ac',
 not 'configure.in'
 configure.in:17: error: required file './compile' not found
 configure.in:17:   'automake --add-missing' can install 'compile'
 gmake: *** [Makefile.in] Error 1
 *** [do-build] Error code 1
 
 Stop in /usr/ports/mail/courier.
 ***
 [/wrkdirs/usr/ports/mail/courier/work/.build_done.courier._usr_local]
 Error code 1
 
 
 How can I fix this?
 
 Thanks.
 
 P.S. I tried building courier on 9.1 i386 host directly from ports, it
 still fails with the same error.


Hi,

I know about this problem, however I did not yet discovered the root
cause of it - maybe some automake versionitis or somesuch... If anyone
knows anything which could help, I'd be really gratefull.

As a quick fix/hack, just change the line in Makefile containing

USE_AUTOTOOLS=  libtool aclocal

to

USE_AUTOTOOLS=  libtool

Then it should compile and run. If you find anything, please keep me
informed. I am already trying to get some time to work on update, which
is already due for some time, but there are still some problems
preventing me to work on it a bit more and prepare good new version's
port.

Regards,
Milan
___
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: mail/courier build error in poudriere

2013-08-30 Thread Milan Obuch 
On Fri, 30 Aug 2013 08:18:17 -0500
Bryan Drewery bdrew...@freebsd.org wrote:

 On 8/30/2013 6:27 AM, Marat Bakeev wrote:
  Hello.
  
  I'm trying to build mail/courier using poudriere on 9.1-RELEASE-p4
  amd64 in i386 jail.
  It fails with the following error:
  
 
 I have just committed a fix for this.
 

I tested it and it compiles here.

Thanks.

Milan
___
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: General usefulness of option descriptions

2012-10-07 Thread Milan Obuch 
On Sun, 7 Oct 2012 15:24:28 +0200
Michael Gmelin free...@grem.de wrote:

 Hi,

 This probably has been discussed before, but I think in many cases
 using the default descriptions of OptionsNG is more harm than good.

 I converted security/libpreludedb to OptionsNG yesterday and
 left in most of the descriptions and therefore overrode them. I did
 that for a good reason, since I believe that the description of the
 option should be more than just repeating the option name.
 Unfortunately the portmgr in charge disagreed and removed all
 description overrides, figuring that I must have forgotten to remove
 them. That's why I raise this topic on the list - I feel like we're
 using a lot of information if we converting ports like this.


Hi,

in my opinion, the best would be to indicate what will be gained using
an option. In some situation it is needed to try to install smallest
possible number of packages. In this situation it is important to know
what will be missed if an option is not selected and make informed
decision whether it will be enabled or not.

 In this specific example this means:

 Before:
  PERL=off: Include Perl bindings
  PYTHON=off: Include Python bindings
  MYSQL=on: Use MySQL backend
  PGSQL=off: Use PostgreSQL backend
  SQLITE=off: Use SQLite backend

 Afterwards:
  DOCS=on: Build and/or install documentation
  MYSQL=on: MySQL database
  PERL=off: Perl scripting language
  PGSQL=off: PostgreSQL database
  PYTHON=off: Python bindings
  SQLITE=off: SQLite database

 This might not seem dramatic at a first glance, but something
 bad just happened here. We moved from describing what the option
 actually means to the user in the context of the port (Include Perl
 binding, Use MySQL backend) to what it means to the ports tree
 (Perl scripting language, MySQL database). The purpose of using
 the option in context of the port is not visible anymore and at this
 point showing the user MYSQL PERL PGSQL PYTHON SQLITE as options
 without any descriptions would provide just as much information.


I think this is bad, really. For me it is important to know what I gain
if I switch some option on, whether it is something to be missed in
some occasion. But I already wrote that above :)

There is another change, but easy to handle - options a sorted
alphabetically by default. One could use NO_OPTION_SORT=yes to set it
the other way.

 One could argue that if a different description is necessary, a
 different option name should be chosen. But this doesn't really work,
 since the meaning to the ports tree in fact *is* that a dependency to
 Perl or MySQL should be introduced, so using the global option names
 makes sense. If one wants to install all ports with their Perl or
 MySQL features enabled, just flipping that one switch should do it,
 regardless of the exact meaning in the context of the port.

 Conclusion:

 1. Option names are for the ports tree structure, there should be as
little as possible and global option names are to be preferred. The
more generic the better, they express a software dependency between
ports on the level of give me support for xyz, but not the
 purpose of this dependency in context of the port.

 2. Option descriptions are for the user of the port and should be as
contextual as possible. In the end it makes a difference to the
user what feature/functionality is actually accomplished by
introducing/installing a dependency. There are always options where
this is just fine  and the meaning is clear (e.g. THREADS,
OPTIMIZE_CFLAGS), but blindly removing this information from a
port is harmful.


I support this one. Which information should be the decision to set or
unset some option based on if not on knowledge which features will be
gained/missed by doing so?

 3. Global option descriptions seem inconsistent as well (all kinds
exist like support/backend/bindings etc., probably depending on the
first port that used them) and to make matters worse, they're
actually changing, e.g. bsd.options.desc.mk from 2012/08/31 said:
MYSQL_DESC?= MySQL backend
While the one from 2012/10/07 says:
MYSQL_DESC?= MySQL database
So even if using the default was contextually correct at some
 point, it could just be changed without the maintainer noticing it.

 What are your thoughts on this?


See above :)

Regards,
Milan
___
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

ports/143974: [mail/courier] upgrade to 0.63.0

2010-03-08 Thread Milan Obuch 
Three weeks old, no activity...
Could someone act on this? It is simple update, nothing under definition of 
sweeping change...
Regards,
Milan
___
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

PR 137112 not taken yet

2009-08-08 Thread Milan Obuch 
Hi,

there is a PR submitted two weeks ago - ports/137112: [mail/courier] update to 
0.62 - with no sign of activity on it until yet. Could some committer look at 
it? I would like to see it in before 8.0 release...

Regards,
Milan
___
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: Unable to build /x11/kdelibs3 with updated jpeg-7 port

2009-07-24 Thread Milan Obuch 
On Thursday 23 July 2009 23:58:03 Mel Flynn wrote:
 On Tuesday 21 July 2009 02:59:29 Milan Obuch wrote:
  On Tuesday 21 July 2009 12:40:34 Jerry wrote:
   It appears that the /x11/kdelibs3 ports insists on using the older
   libjpeg.so.9 library. Since updating to jpeg-7, this library is
   no-longer available. Therefore, I cannot build this port.
  
   A complete copy of the build log is available here:
  
   http://filebin.ca/yrdvkw/kdelibs.log
 
  There is notice in UPDATING, section 20090719,
 
  I found temporary workaround
 
  ln -s /usr/local/lib/libjpeg.so.10 /usr/local/lib/libjpeg.so.9

 I don't know why people keep advising this, it only makes future upgrades
 harder.


Please read again: it is temporary workaround. At least for me. It makes my 
installed ports working *immediately* with small possibility something will 
not work at all due some ABI chabge or somesuch. Rebuilding some KDE ports 
took me couple of days (finding the way, compile etc).

The difference - works immediately vs. a week or so without working kde is 
immense.

 The solution is also very simple to determine:
 % ldd -a /usr/local/lib/libkdefx.so.6|egrep '(^/|jpeg.so)'

How did you determine this is exactly the lib to look into? Just wondering...

 /usr/local/lib/libkdefx.so.6:
 libjpeg.so.10 = /usr/local/lib/libjpeg.so.10 (0x28b31000)
 /usr/local/lib/libqt-mt.so.3:
 libjpeg.so.10 = /usr/local/lib/libjpeg.so.10 (0x28b31000)
 /usr/local/lib/libpng.so.5:
 /lib/libz.so.5:
 /usr/local/lib/libXext.so.6:
 /usr/local/lib/libX11.so.6:
 /usr/local/lib/libSM.so.6:
 /usr/local/lib/libICE.so.6:
 /usr/local/lib/libXrender.so.1:
 /usr/local/lib/libjpeg.so.10:
 /usr/lib/libstdc++.so.6:
 /lib/libm.so.5:
 /lib/libgcc_s.so.1:
 /usr/local/lib/libaudio.so.2:
 /usr/local/lib/libXt.so.6:
 /usr/local/lib/libmng.so.1:
 libjpeg.so.10 = /usr/local/lib/libjpeg.so.10 (0x28b31000)

 From this you can tell that you need to rebuild libqt-mt.so.3 and
 libmng.so.1. One more step:
 % egrep -l '(libqt-mt.so.3|libmng.so.1)' /var/db/pkg/*/+CONTENTS | xargs
 grep -h '@comment ORIGIN:'
 @comment ORIGIN:graphics/libmng
 @comment ORIGIN:x11-toolkits/qt33

 And those are the ports to rebuild for kdelibs3 to be able to build.

After my symlink trick, portmaster rebuilt everything necessary, so aj could 
remove the symlink afterwards. So I think it was kind of hackish solution, 
but made my fixing *much* easier and, more important, less stressfull. That's 
it. Maybe not nice, but really effective.

Regards,
Milan
___
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: Unable to build /x11/kdelibs3 with updated jpeg-7 port

2009-07-21 Thread Milan Obuch 
On Tuesday 21 July 2009 12:40:34 Jerry wrote:
 It appears that the /x11/kdelibs3 ports insists on using the older
 libjpeg.so.9 library. Since updating to jpeg-7, this library is
 no-longer available. Therefore, I cannot build this port.

 A complete copy of the build log is available here:

 http://filebin.ca/yrdvkw/kdelibs.log

There is notice in UPDATING, section 20090719,

I found temporary workaround

ln -s /usr/local/lib/libjpeg.so.10 /usr/local/lib/libjpeg.so.9

After that, all my ports seems to work again.
I am rebuilding kdelibs, kdebase and kdepim right now (most used apps in my 
case).

Regards,
Milan

___
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: call for testing: print/hplip update, pass 2

2009-07-11 Thread Milan Obuch 
On Saturday 11 July 2009 00:15:42 Juergen Lock wrote:

[ snip ]

  Build/install (well, I did portmaster hplip) went flawlessly, but when
  starting I got error
 
  Jul 10 08:35:43 wind python: [723]: error: dbus failed to load
  (python-dbus ver. 0.80+ required). Exiting...
 
  I added
 
  cupsd_enable=YES
  dbus_enable=YES
  hpssd_enable=YES

 hpssd is no longer used btw, it has been replaced by hp-systray that
 runs as your user.


Does it mean line

hpssd_enable=YES

should be taken out of /etc/rc.conf? If so, pkg-message of port should be 
changed to not request this addition.

  pkg_info | grep -i dbus
  dbus-1.2.4.6A message bus system for inter-application
  communication dbus-glib-0.80  GLib bindings for the D-BUS messaging
  system dbus-qt3-0.70_2 Qt3 bindings for the D-BUS messaging system
  py25-dbus-0.83.0_1  Python bindings for the D-BUS messaging system
  py25-qt4-dbus-4.4.4,1 Python bindings for the Qt4 toolkit, D-BUS module
 
  so the minimal or better required version is installed, so what? Or did I
  not understand the message correctly?

  Well, did you start dbus too? :)


ps -ax | grep dbus
  769  ??  Is 0:00.01 /usr/local/bin/dbus-daemon --system
23245  ??  Is 0:00.03 /usr/local/bin/dbus-daemon --fork --print-pid 
5 --print-address 7 --session
23455  ??  Is 0:00.03 /usr/local/bin/dbus-daemon --fork --print-pid 
5 --print-address 7 --session
23508  p4  S+ 0:00.00 grep dbus
23454  p6  I  0:00.00 dbus-launch --autolaunch 
3f34b36a9821314210c5d7c84a0a5962 --binary-syntax --close-stderr

  Or it could be that you also need qt4-dbus-4.4.3, at least I have that
 installed here too (devel/dbus-qt4, probably pulled in by another
 unrelated port here.)

I will try to install it too (and maybe possibly rebuild hplip again after 
that change) and report the results here. But give me some time to do it, 
please...

Regards,
Milan
___
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: call for testing: print/hplip update, pass 2

2009-07-10 Thread Milan Obuch 
On Thursday 09 July 2009 20:44:46 Dmitry Marakasov wrote:

[ snip ]

 First of all, here's latest version of the port:
 http://people.freebsd.org/~amdmi3/hplip.shar
 Please use it as a base for further changes (and also please check
 that I haven't missed any of your enchantments).


[ snip ]

Hi,

I have HP Photosmart D5460, which is not supported by hplip in ports now. This 
was my motivation to test new port.

Build/install (well, I did portmaster hplip) went flawlessly, but when 
starting I got error

Jul 10 08:35:43 wind python: [723]: error: dbus failed to load (python-dbus 
ver. 0.80+ required). Exiting...

I added 

cupsd_enable=YES
dbus_enable=YES
hpssd_enable=YES

into /etc/rc.conf, and

pkg_info | grep -i dbus
dbus-1.2.4.6A message bus system for inter-application communication
dbus-glib-0.80  GLib bindings for the D-BUS messaging system
dbus-qt3-0.70_2 Qt3 bindings for the D-BUS messaging system
py25-dbus-0.83.0_1  Python bindings for the D-BUS messaging system
py25-qt4-dbus-4.4.4,1 Python bindings for the Qt4 toolkit, D-BUS module

so the minimal or better required version is installed, so what? Or did I not 
understand the message correctly?

Regards,
Milan
___
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

2007-09-27 Thread Milan Obuch 
On Thursday 27 September 2007 11:21:02 Johan Hendriks wrote:
 I can not update Image Magick on all of my machines.
 This is on 6.2 and 6.1

 it errors out with the following error:


[snip]

 ** Command failed [exit code 1]: /usr/bin/script -qa
 /tmp/portupgrade.13874.0 env UPGRADE_TOOL=portupgrade
 UPGRADE_PORT=ImageMagick-6.3.3.5_1 UPGRADE_PORT_VER=6.3.3.5_1 make ** Fix
 the problem and try again.
 ** Listing the failed packages (*:skipped / !:failed)
 ! graphics/ImageMagick (ImageMagick-6.3.3.5_1)  (unknown build
 error) ---  Packages processed: 0 done, 0 ignored, 0 skipped and 1 failed

 regards
 Johan
 ___
 freebsd-ports@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-ports
 To unsubscribe, send any mail to [EMAIL PROTECTED]

Just a 'me too' - I did experience the same error.
Milan

-- 
No need to mail me directly. Just reply to mailing list, please.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: ImageMagick

2007-09-27 Thread Milan Obuch 
On Thursday 27 September 2007 11:31:38 Marcus von Appen wrote:
 On, Thu Sep 27, 2007, Johan Hendriks wrote:
  I can not update Image Magick on all of my machines.
  This is on 6.2 and 6.1
 
  it errors out with the following error:

 [Test broken]

 Deactivate the IMAGEMAGICK_TESTS knob. This circumvents the test issue
 and ImageMagick will be installed without any problems. The failed tests
 however indicate, that someone should look into it :-).

 Regards
 Marcus

Works for me. Good workaround pretending nothing else is broken ;)
Regards,
Milan

-- 
No need to mail me directly. Just reply to mailing list, please.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Gnash 0.8.1 submitted

2007-09-25 Thread Milan Obuch 
On Tuesday 18 September 2007 01:35:55 Dmitry Marakasov wrote:
 Hi!

 First of all, sorry for long delay with Gnash update. There were
 some problems with 0.8.0 (segfaults) and it took me some time to
 polish the new port of 0.8.1. Anyway, here's the PR:

 http://www.freebsd.org/cgi/query-pr.cgi?pr=116406

 And here is an overview of current Gnash functionality by me :)
 http://www.amdmi3.ru/gnash/
 (also should be useful as explanation of port options, i.e.
 renderers and media handlers, with some benchmarks and caveats
 explained).

 Also, if you use KDE and would like Gnash plugin for Konquerror,
 please contact me. I have no KDE installed, so I'll need some help,
 but it'll be easy and quick.

 Thank you for your patience, and enjoy free Flash player.
 It supports YouTube, yes :)

I was able to build gnash with konqueror plugin after applying following patch 
(warning, some linewrap is there):

--- Makefile2007-09-22 00:12:11.0 +0200
+++ Makefile.0  2007-09-23 10:11:23.0 +0200
@@ -55,9 +55,8 @@
FFMPEG  Media handler: ffmpeg (+SDL sound output) on 
\
GSTREAMER   Media handler: GStreamer off \
MAD Media handler: MAD (+SDL sound output) off  
\
-   DEBUGLOGLeave logfile in current directory on every 
run off
-
-#  KDE GUI: KDE (required for Konqueror plugin) off 
\
+   DEBUGLOGLeave logfile in current directory on every 
run off \
+   KDE GUI: KDE (required for Konqueror plugin) off 
\

 .include bsd.port.pre.mk

@@ -69,12 +68,12 @@
 CONFIGURE_ARGS+=   --disable-nsapi
 .endif

-#.if defined(WITH_KDE)  !defined(WITHOUT_PLUGIN)
-#PLIST_SUB+=   KONQPLUGIN=
-#.else
-#PLIST_SUB+=   KONQPLUGIN=@comment 
+.if defined(WITH_KDE)  !defined(WITHOUT_PLUGIN)
+PLIST_SUB+=KONQPLUGIN=
+.else
+PLIST_SUB+=KONQPLUGIN=@comment 
 CONFIGURE_ARGS+=   --disable-kparts
-#.endif
+.endif

 # Cygnal option processing
 .if defined(WITH_CYGNAL)
@@ -107,12 +106,12 @@
 PLIST_SUB+=GTK=@comment 
 .endif

-#.if defined(WITH_KDE)
-#GNASH_GUIS+=  kde
-#PLIST_SUB+=   KDE=
-#.else
+.if defined(WITH_KDE)
+GNASH_GUIS+=   kde
+PLIST_SUB+=KDE=
+.else
 PLIST_SUB+=KDE=@comment 
-#.endif
+.endif

 CONFIGURE_ARGS+=   --enable-gui=`${ECHO} ${GNASH_GUIS} | ${TR} ' ' ,`

Trouble is, with gnash build this way I was not able to run X with KDE any 
more - with CPU at 100 % and xorg server process consuming 98 % CPU accoding 
to top I had basically locked console, even though I was able to login via 
ssh and get good response for non CPU intensive command entered in shell.
If anybody have an idea, I can test it and report. Or maybe someone else could 
test it too...
Milan

-- 
No need to mail me directly. Just reply to mailing list, please.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Gnash 0.8.1 submitted

2007-09-25 Thread Milan Obuch 
On Tuesday 25 September 2007 22:28:58 Dmitry Marakasov wrote:
 * Milan Obuch ([EMAIL PROTECTED]) wrote:
  I was able to build gnash with konqueror plugin after applying following
  patch (warning, some linewrap is there):

 [patch skipped]

  Trouble is, with gnash build this way I was not able to run X with KDE
  any more - with CPU at 100 % and xorg server process consuming 98 % CPU
  accoding to top I had basically locked console, even though I was able to
  login via ssh and get good response for non CPU intensive command entered
  in shell. If anybody have an idea, I can test it and report. Or maybe
  someone else could test it too...

 Does X/KDE start to consume CPU right after it starts? Which exactly
 process does consume CPU? Does flipping options help (turn off media
 handlers, switch renderer to AGG)? Does standlalone player with KDE
 interface work (should be /usr/local/bin/kde-gnash)? Does GTK version cause
 any bugs?

See above - xorg server process (X itself) does consume almost all CPU. I need 
to try build a test instance - my working computer has too many konqueror 
windows and tabs open from the start so it is almost impossible to tell.
What do you mean by flipping options? Changing build options when building the 
port? I can try it in my test instance a bit later. I did not do yet too much 
checks, but I definitely will, as soom as I have simple test instance 
running.

Regards,
Milan

-- 
No need to mail me directly. Just reply to mailing list, please.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: keyboard lock light issues - xorg-7.3_1 or fluxbox

2007-09-25 Thread Milan Obuch 
On Wednesday 26 September 2007 07:08:24 Rob Clark wrote:
 Running:
 6.2-STABLE FreeBSD 6.2-STABLE #0: Thu Sep 20 12:21:22 EDT
 2007, xorg-7.3_1, fluxbox-1.0rc3_3 (window manager)

 Keyboard:
 IBM KB-8923

 Following both the xorg 7.3 update, and new install of the
 most recent fluxbox, I've lost the lock lights on the
 keyboard (i.e., Num Lock and Caps Lock) while running X and
 fluxbox.


It's the same here - I am using KDE suite, and it happened just after xorg 
6.9 - 7.3 upgrade. I just reported it yesterday on x11 list.

 Also had another issue with the f key not working.
 With mplayer full screened, the f key would not allow me to
 reduce the full screen back to original size -- had to
 ctrl-alt-backspace and exit X.


I did not notice any other keyboard related problem, but this says nothing. I 
just did not notice any.

 Keyboard appears and works fine in console mode, lights work
 without issue.


Same here - but this is expected, as kernel keyboard driver is set different 
ways in two cases - raw mode (key press and release reported with scan codes) 
for X, cooked mode (scan codes converted to characters) for console.

 Not sure if this is attributed to the xorg 7.3 update or my
 late migration over to fluxbox-1.0rc3_3 from fluxbox-0.1.14.


As my environment is different, I would say xorg update is the culprit. I 
would like to know what I can test - to me it looks like something in xorg's 
keyboard driver. If noone has a clue, this would be my starting point for 
investigation. It has low priority for me, now, it is annoying, but not life 
damaging bug ;)

Regards,
Milan

-- 
No need to mail me directly. Just reply to mailing list, please.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: mail/maildrop marked as broken

2007-03-21 Thread Milan Obuch 
On Wednesday 21 March 2007 21:13, KIMURA Yasuhiro wrote:
 From: Vizion [EMAIL PROTECTED]
 Subject: mail/maildrop marked as broken
 Date: Wed, 21 Mar 2007 11:33:59 -0700

  As title for information
  New today:
  portupgrade -a reports:
 
  FAM system mismatch: gamin is imstalled and desired FAM system is fam

 AFAIK Courier products work only with fam and not with gamin. But I
 not certain this is still the case now. Does anyone know if latest
 gamin is compatible with Courier products?

 ---
 KIMURA Yasuhiro


This is part of installed packages on one from my servers:

pkg_info
apache-2.2.4Version 2.2 of Apache web server with prefork MPM.
arc-5.21o_1 Create  extract files from DOS .ARC files
arj-3.10.22 Open-source ARJ
autoconf-2.53_3 Automatically configure source code on many Un*x platforms
autoconf-2.59_2 Automatically configure source code on many Un*x platforms
automake-1.5_2,1GNU Standards-compliant Makefile generator (1.5)
automake-1.9.6  GNU Standards-compliant Makefile generator (1.9)
clamav-0.90_3   Command line virus scanner written entirely in C
clamcour-0.3.8  ClamAV courier filter
courier-0.54.0  Courier SMTP IMAP POP3 HTTP mail server suite
courier-authlib-base-0.59.1 Courier authentication library base
courier-authlib-userdb-0.59.1 Userdb support for the Courier authentication 
library
courier-pythonfilter-0.18 Framework for courier filter development in python
curl-7.16.1 Non-interactive tool to get files from FTP, GOPHER, 
HTTP(S)
docbook-1.3 Meta-port for the different versions of the DocBook DTD
docbook-241_2   V2.4.1 of the DocBook DTD, designed for technical 
documenta
docbook-3.0_2   V3.0 of the DocBook DTD, designed for technical 
documentati
docbook-3.1_2   V3.1 of the DocBook DTD, designed for technical 
documentati
docbook-4.0_2   V4.0 of the DocBook DTD, designed for technical 
documentati
docbook-4.1_2   V4.1 of the DocBook DTD, designed for technical 
documentati
docbook-xml-4.2_1   XML version of the DocBook DTD
expat-2.0.0_1   XML 1.0 parser written in C
gamin-0.1.7_2   A file and directory monitoring system

And it works well. So yes, courier could be used with gamin. And if full 
courier suite works well, it could work partially, too.

Regards,
Milan

-- 
No need to mail me directly. Just reply to mailing list, please.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Can't do a portupgrade -rf on any of my mail/courier installation

2006-11-12 Thread Milan Obuch 
On Sunday 12 November 2006 22:05, [EMAIL PROTECTED] wrote:
 hi,

 Strange problem trying to run portupgrade -rf mail/courier on both
 current and 6.2-PRERELEASE with all ports up to date.  Only one of the
 machines has an older courier that I tried to update and get the error
 so I decided I would build a package from one of the up to date
 installations but much to my surprise I get the same error.  One of
 the installations I just built within the las 15 days so it would seem
 that it can be built but not rebuilt which makes no sense to me.  All
 of the courier installations are working fine.  This all came to light
 with a portupgrade -afr on one machine.  Same thing with a cd
 /usr/ports/mail/courier; make

 Any suggestions appreciated.

 thanks,

 ed


This seems to be an issue with either fam or gamin as currently present in 
ports tree. I do not understand everything in detail, one does not link (just 
as you showed), the second one builds but does not run (imapd dumps core, so 
no usable imap server). If someone with more fam/gamin knowledge could help 
here, it would be great. As a temporary workaround, you could comment out 
line in Makefile telling WITH_FAM= YES (or something similar is there) and be 
just fine, loosing ENHANCED IDLE support, however. You could even update this 
way to 0.53.3, by the way. I did not try to put this update into PR yet 
exactly due this fam/gamin issue.
Regards,
Milan

-- 
This address is used only for mailing list response.
Do not send any personal messages to it, use milan in
address instead.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]