On Mon, Feb 15, 2016 at 09:47:54PM +, Pedro de Oliveira wrote:
> Hi again,
>
> Here is an updated version, with two patches from github, it now also
> passes portcheck.
> I believe that in the next version both patches will already be in upstream.
>
> https://github.com/hishamhm/htop/pull/398
There is definitely a bug here, but I don't think it is a prosody
problem.
I did some digging:
lua51 -e 'for _,v in ipairs(require"DBI".Drivers()) do print(v) end'
Should list the MySQL driver when installed, but only lists SQLite3 on
my CURRENT machine.
As you can see below loading the dbdmysq
On Mon, Feb 15, 2016 at 08:51:34PM +, Christian Weisgerber wrote:
> On 2016-02-15, Tobias Ulmer wrote:
>
> > +padding for 32bit strict alignment archs
> > +
> > +--- tools/build/src/engine/hash.c.orig Mon Feb 15 20:11:07 2016
> > tools/build/src/engine/hash.c Mon Feb 15 20:22:03 201
Hi again,
Here is an updated version, with two patches from github, it now also
passes portcheck.
I believe that in the next version both patches will already be in upstream.
https://github.com/hishamhm/htop/pull/398
https://github.com/hishamhm/htop/pull/376
On Sun, Feb 14, 2016 at 10:08 PM, Jua
On Mon, February 15, 2016 7:17 am, Jérémie Courrèges-Anglas wrote:
>
> We should fix the current situation one way of the other. duplicity
> users on OpenBSD should speak up. Does the default ssh backend,
> paramiko, prevent you from easily using duplicity on OpenBSD-current?
> Looks like para
On 2016-02-15, Tobias Ulmer wrote:
> +padding for 32bit strict alignment archs
> +
> +--- tools/build/src/engine/hash.c.orig Mon Feb 15 20:11:07 2016
> tools/build/src/engine/hash.cMon Feb 15 20:22:03 2016
> +@@ -33,6 +33,7 @@ typedef struct item ITEM;
> + struct item
> + {
> +
On Mon, Feb 15, 2016 at 10:54:26AM -0600, attila wrote:
>
> Landry Breuil writes:
>
> > On Mon, Feb 08, 2016 at 02:53:16PM -0600, attila wrote:
> >>
> >> Landry Breuil writes:
> >
> >
> >
> >> > Have you tried leaving the .xpi files compressed in their respective
> >> > dirs at runtime (even
Fix 'jam' so it doesn't crash immediately on sparc.
While debugging I found file_query wasn't declared, which is nice since
it returns a pointer. Surprised this works at all on 64 bit machines,
I'm guessing it's because of -O0.
More sparc fixes may be coming, or I may mark the thing as BROKEN, we
Stuart Henderson writes:
> On 2016/02/15 13:05, Jérémie Courrèges-Anglas wrote:
>> If someone knows what the hell the alien C syntax in
>> patches/patch-src_fns_c is about, cluebat welcome.
>
> it's C99:
>
> https://en.wikipedia.org/wiki/Restrict
I've heard about restrict, but I had indeed never
Landry Breuil writes:
> On Mon, Feb 08, 2016 at 02:53:16PM -0600, attila wrote:
>>
>> Landry Breuil writes:
>
>
>
>> > Have you tried leaving the .xpi files compressed in their respective
>> > dirs at runtime (eventually unzipping/patching/rezipping) as you comment
>> > in Makefile.inc line
And now with attachment :)
On Mon, Feb 15, 2016 at 10:44:57AM -0500, Jiri B wrote:
> A python wrapper against libtidy(p).
>
> Maybe to useful to reconsider after ports unlock.
>
> $ env LD_DEBUG=1 python2.7 -c "import tidylib" 2>&1 | grep tidy
> dlopen: loading: libtidyp.so
> flags /usr/local/l
On 2016-02-14, Matthieu Herrb wrote:
> I've taken the list of individual optimisation from gcc(1) for both -O1
> and -O2 and replaced -O2 by this in CFLAGS.
gcc-local(1) is also worth a look...
> +O2= ${O1} -fthread-jumps -fcrossjumping \
> + -foptimize-sibling-calls -fcse-follow-jumps -fcs
A python wrapper against libtidy(p).
Maybe to useful to reconsider after ports unlock.
$ env LD_DEBUG=1 python2.7 -c "import tidylib" 2>&1 | grep tidy
dlopen: loading: libtidyp.so
flags /usr/local/lib/libtidyp.so.0.0 = 0x0
head /usr/local/lib/libtidyp.so.0.0
obj /usr/local/lib/libtidyp.so.0.0 ha
On 2016/02/15 13:05, Jérémie Courrèges-Anglas wrote:
> If someone knows what the hell the alien C syntax in
> patches/patch-src_fns_c is about, cluebat welcome.
it's C99:
https://en.wikipedia.org/wiki/Restrict
"trondd" writes:
> Bump to get this in for 5.9 so users aren't confused by the changed
> default and the resulting incorrect manpage.
>
> If no one thinks it should go in for 5.9, I'll wait for unlock to poke again.
Thanks for caring about this, Tim.
We should fix the current situation one way
Hi,
emacs-25.1 will probably be out before the ports will be unlocked.
While we should focus on the current ports tree, I already experiment
breakage in my Gnus setup and I'd prefer to keep the number of new
issues low...
So here's a diff to update to last friday's pretest tarball. Test
reports
16 matches
Mail list logo
