devel/libevent shopstopper

[Dewayne Geraghty]

On 21 February 2017 at 07:48, The Doctor <doctor at doctor.nl2k.ab.ca> wrote:

> On Mon, Feb 20, 2017 at 12:35:41PM -0800, Kevin Oberman wrote:
> > On Mon, Feb 20, 2017 at 11:57 AM, The Doctor <doctor at doctor.nl2k.ab.ca>
> > wrote:
> >
> > > On Mon, Feb 20, 2017 at 05:55:46PM +0000, Jan Beich wrote:
> > > > The Doctor <doctor at doctor.nl2k.ab.ca> writes:
> > > >
> > > > > We have a big one!!
> > > > >
> > > > > Libevent compiles but does not install
> > > > >
> > > > > ===>  Installing for libevent-2.1.8
> > > > > ===>  Checking if libevent already installed
> > > > > ===>   Registering installation for libevent-2.1.8 as automatic
> > > > > Installing libevent-2.1.8...
> > > > > pkg-static: libevent-2.1.8 conflicts with libevent2-2.1.8 (installs
> > > > > files into the same place).  Problematic file:
> > > > > /usr/local/bin/event_rpcgen.py
> > > > > *** Error code 70
> > > > >
> > > > > Stop.
> > > > > make[1]: stopped in /usr/ports/devel/libevent
> > > > > *** Error code 1
> > > > >
> > > > > Stop.
> > > > > make: stopped in /usr/ports/devel/libevent
> > > > >
> > > > > ===>>> Installation of libevent-2.1.8 (devel/libevent) failed
> > > > > ===>>> Aborting update
> > > > >
> > > > > ===>>> Update for devel/libevent failed
> > > > > ===>>> Aborting update
> > > >
> > > > How did you invoke the build? portmaster and portupgrade are
> supposed to
> > > > look into /usr/ports/MOVED before proceeding. If they don't then
> you're
> > > > probably treading the unsupported territory[1] or encountered a bug.
> > >
> > > My sequence is
> > >
> > > pkg update -f
> > > portsnap fetch update
> > > portmaster -a
> > >
> > > Am I doing something wrong?
> > >
> >
> > If you are building from ports, I'm not clear on why you do 'pkg update
> > -f', but it should not hurt.
> >
> > Before running "portmaster -a", you should run "portmster -o
> devel/libevent
> > devel/libevent2".
> >
> > Just looking quickly at portmaster, it appears to deal with deleted ports
> > and ports moved to a different location in the tree, but it does not look
> > to me like it handles renamed ports properly. If someone who is better at
> > shell scripting than I am wants to look at the code after line 1100,
> maybe
> > this could either be fixed or added.
>
> Is this a portmaster issue?
>
> > --
> > Kevin Oberman, Part time kid herder and retired Network Engineer
> > E-mail: rkoberman at gmail.com
> > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
>
> --
> Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@
> nl2k.ab.ca
> Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist
> rising!
> http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
> God is dead! Yahweh lives! Jesus his only begotten Son is the Risen
> Saviour!!
> _______________________________________________
> freebsd-ports at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscribe at freebsd.org"
>



Unlikely to be a portmaster issue.  If you look inside /usr/ports/UPDATING
you're find some useful references to the way that portmaster handles name
changes and John's "portmaster -o" advice is correct; its easy to miss that
point in the man page ;)

Perhaps its just a timing issue but both libevent2 and libcheck name
changed broke our overnight builds.  Unfortunately we didn't realise that
we had a dependency until databases/memcached barfed.  So we need to check
/usr/ports/UPDATING and MOVED against a previous build to minimise that
liklihood and catch dependencies.

Upside is that we've just completed testing of synth, and decided to move
the development servers to it.  A recent post (from Bapt@) reaffirmed that
the changes to /usr/ports is likely to break portmaster and other tools due
to flavour's same origin.  So rather than continue to rely upon a
previously advocated tool, which is well suited to our very narrow purpose,
its time to move.

For those interested in synth but skittish:
1. install synth; read the manual
2. synth configure
which places the synth.ini file in /usr/local/etc/synth
and for testing purposes try
3. synth just-build $category/$portname;
Example: synth just-build devel/check devel/libevent ftp/curl
4. Examine your logs in /var/log/synth
Particularly 00_last_results.log and 02_failure_list.log
5. Examine your new packages in /var/synth/live_packages/All

Gotchas: if you have complex make.conf file that pulls in other files, you
will need to concatenate them into the one make.conf.

If you have home grown build systems like we do, that have used portmaster
since around 2005, its a big deal to change.  We're looking forward to this
incremental change.  And if you use jails extensively, synth runs happily
in a jail too - but this was against John Marinos advice, however we have
strict functional separation here.