Note that this is a devel version but the new stable is expected within a
week or so. Committing now so that I have time to deal with the breakage
and can start the upcoming gnome3 update.
Please contact me _directly_ if you find any issue with it.
SEGFAULT when using g_closure() on at least amd64; unclear whether this
is a gcc/binutils/glib... bug yet but we want to be on the safe side for
the release.
Hopefully someone will be able to figure this out, I haven't...
Thanks to Stuart for teaching me PROPERTIES.
ok sthen@ naddy@
As a consequence, explicitely disable the FAM backend.
This bring a huge improvement compared to what we've been using before
(gio-fam+gamin): file / directory monitoring and notifications are next
to instantaneous without any cpu overhead like it was before.
This means we can also drop the bootstrap FLAVOR of gamin that was
needed because of the cyclic dependency (gamin->glib2->gamin).
also annotate gamin for bootstrap property, and mark haddock,no_deps as
a "real flavor", since it's only used for bootstrap anyways AND significantly
changes the build.
Committing now (along with upcoming atk, pango and gtk+3 updates) during
the hackathon where we have time to fix all the eventual fallout (bulk
running).
ok jasper@ robert@
* use MODPY_ADJ_FILES
* use REGRESS_FLAGS instead of 4 patches...
* use post-install to remove files we don't ship, 2 less patches
* install gtester-report(1) -- it's a python script but we do not
enforce a run dependency on python
PLIST and remove remove everything under the @sample'd directory instead
of the directory itself to prevent a warning from pkg_delete(1) trying
to remove a non existing directory and to help preventing left-over
files and directories.
implement the "intended" SCM_CREDS stack as if we had support for that
in the kernel (by-pass it almost completely).
send/recv a single null byte without creds, but on recv, just do a
getsockopt(SO_PEERCRED) and return that as if it coming from the cmsg.
This works as long as creds are not retreived from an fd which has
already been handed over to a different process via SCM_RIGHTS. It will
probably not be enough in the future but we'll see then.
all this work done by eric@ (thanks!) and tested by myself
Enable support for g_credential*
Fix a couple of warnings.
ok eric@ jasper@
Fixes the following:
* 644465 undefined reference to `_usleep'
* 644552 g_timeout_add_seconds(1, ...) may have a latency...
* 644607 correct internal definition of C_()
we set MODPY_BUILDDEP=No, whilst providing PYTHON via CONFIGURE_ENV. this
lead configure to believe there actually was a python present on the system.
which wasn't, so set MODPY_BUILDDEP=Yes and adjust REGRESS_DEPENDS accordingly
ok aja@ landry@
Major update to glib2-2.26.0.
This starts a flood commit of several big updates (gtk+2 and GNOME 2.32).
Please note that there will be some WANTLIB/DEPENDS breakage probably,
this went into several bulks but it's impossible to catch everything.
Any gtk+2/glib2 related build failures, please talk to me or jasper@
The ports tree is expected to be in a unconsistent state for a couple of
days to give us time to fix everything we didn't spot or any runtime
issue with the latest GNOME.
We do this now so that we have packages with all the latest major bumped
libraries at p2k10.
Thanks to landry@ and his zomg!cluster for the bulks and reports.
ok jasper@
GIO Reference Manual:
gio-querymodules creates a giomodule.cache listing the implemented
extension points for each module that has been found. It is used by GIO
at runtime to avoid opening all modules just to find out which extension
points they are implementing.
Glib now enforces threads requirement. As a result, this commit will
break p5-Glib2 (as our perl is not threaded).
Decision was taken after a chat with naddy@ and jasper@ as patching our
current glib2 like hell to cope with newer packages requirements is
clearly not a good solution.
naddy is ok with this move.
This is required by newer GTK. We cannot just update Glib because it now
requires threads which will break p5-Glib2 dependent apps as our perl is
not threaded... solution to this is rthreads or ... <insert solution
here and send it to aja@>. Yes this means we are stuck with this version
for now.