Re: New port: net/telegram-purple

2017-06-23 Thread Brian Callahan


On 6/23/2017 7:24 AM, Dmitrij D. Czarkoff wrote:
> Brian Callahan  wrote:
>
>> Run tested it on amd64, works fine.
>> Why not do this though:
>>
>> USE_GMAKE = Yes
>> MAKE_FLAGS =CC="${CC}"
>> CONFIGURE_STYLE =   gnu
>> CONFIGURE_ENV = CFLAGS="${CFLAGS} -I${LOCALBASE}/include" \
>>LDFLAGS="${LDFLAGS} -L${LOCALBASE}/lib"
>>
>> Then it'll de-hardcode gcc, and you can remove those extra CFLAGS+= and
>> LDFLAGS= lines.
> Basically I define CFLAGS separately because they are also passed to
> MAKE_ENV, and then defining LDFLAGS there seems more aestetically
> pleasant to me.  This approach does not provide any actual benefits in
> this case though, so I don't really want to insist on it.
>
> Regarding MAKE_FLAGS addition:  I'd rather avoid unnecessarily polluting
> the environment, so patching Makefile.in seems more appropriate to me.
>

And I prefer to avoid writing patches, but I'm not gonna insist on it
either :)
That new version is ok by me too for import.

~Brian



Re: New port: net/telegram-purple

2017-06-23 Thread Dmitrij D. Czarkoff
Brian Callahan  wrote:

>Run tested it on amd64, works fine.
>Why not do this though:
>
>USE_GMAKE = Yes
>MAKE_FLAGS =CC="${CC}"
>CONFIGURE_STYLE =   gnu
>CONFIGURE_ENV = CFLAGS="${CFLAGS} -I${LOCALBASE}/include" \
>LDFLAGS="${LDFLAGS} -L${LOCALBASE}/lib"
>
>Then it'll de-hardcode gcc, and you can remove those extra CFLAGS+= and
>LDFLAGS= lines.

Basically I define CFLAGS separately because they are also passed to
MAKE_ENV, and then defining LDFLAGS there seems more aestetically
pleasant to me.  This approach does not provide any actual benefits in
this case though, so I don't really want to insist on it.

Regarding MAKE_FLAGS addition:  I'd rather avoid unnecessarily polluting
the environment, so patching Makefile.in seems more appropriate to me.



Re: New port: net/telegram-purple

2017-06-23 Thread Dmitrij D. Czarkoff
Stuart Henderson  wrote:

>On 2017/06/22 18:11, Dmitrij D. Czarkoff wrote:
>> "Dmitrij D. Czarkoff"  wrote:
>> 
>>>The attached port contains libpurple protocol plugin that adds support
>>>for the Telegram messenger to net/pidgin.
>>>
>>>OK to import?
>> 
>> ping
>
>Build-testing only (I'm not going to run pidgin to try it \
>out at runtime),
>there are parts where it hardcodes gcc. Otherwise looks ok.

Sorry, I did not notice that.  The updated port fixes that.  Basically I
patch Makefile to pass CC to nested configure invocation.


telegram-purple-1.3.1.tgz
Description: application/gzip


Re: New port: net/telegram-purple

2017-06-23 Thread Dmitrij D. Czarkoff
Jakub Skrzypnik  wrote:

>I would like to ask about something different - how tightly is that
>telegram support tied to GUI libraries? Some of these libpurple-based
>transports for IM protocols are tied up to use with Pidgin/Adium,
>completely ignoring the fact that libpurple can be used by many other
>applications.
>
>The problem itself is that I would like to use Bitlbee with libpurple
>for XMPP, GG, Facebook and Telegram if it gets merged, but I'm a bit
>afraid about pushing the whole GUI stack as a dependency tail of
>libpurple and/or these transports, while libpurple itself can actually
>work without X.

This port does not depend on any X11 stuff, and it is known to work with
finch (console version of pidgin).  For all I know there is an open
issue about a user being constantly signed out from telegram on
Bitlbee¹, though I am not sure whether it is an issue with particular
setup, or a defect in telegram-purple.

You can actually build a port and test it.

¹ https://github.com/majn/telegram-purple/issues/392



Re: New port: net/telegram-purple

2017-06-22 Thread Jakub Skrzypnik
I would like to ask about something different - how tightly is that
telegram support tied to GUI libraries? Some of these libpurple-based
transports for IM protocols are tied up to use with Pidgin/Adium,
completely ignoring the fact that libpurple can be used by many other
applications.

The problem itself is that I would like to use Bitlbee with libpurple
for XMPP, GG, Facebook and Telegram if it gets merged, but I'm a bit
afraid about pushing the whole GUI stack as a dependency tail of
libpurple and/or these transports, while libpurple itself can actually
work without X.

On Thu, 22 Jun 2017 18:11:24 +0200
"Dmitrij D. Czarkoff"  wrote:

> "Dmitrij D. Czarkoff"  wrote:
> 
> >The attached port contains libpurple protocol plugin that adds
> >support for the Telegram messenger to net/pidgin.
> >
> >OK to import?  
> 
> ping



Re: New port: net/telegram-purple

2017-06-22 Thread Brian Callahan


On 6/22/2017 12:11 PM, Dmitrij D. Czarkoff wrote:
> "Dmitrij D. Czarkoff"  wrote:
>
>> The attached port contains libpurple protocol plugin that adds support
>> for the Telegram messenger to net/pidgin.
>>
>> OK to import?
> ping

Run tested it on amd64, works fine.
Why not do this though:

USE_GMAKE = Yes
MAKE_FLAGS =CC="${CC}"
CONFIGURE_STYLE =   gnu
CONFIGURE_ENV = CFLAGS="${CFLAGS} -I${LOCALBASE}/include" \
LDFLAGS="${LDFLAGS} -L${LOCALBASE}/lib"

Then it'll de-hardcode gcc, and you can remove those extra CFLAGS+= and
LDFLAGS= lines.

ok bcallah@ with those tweaks.

Is it worth listing https://github.com/majn/telegram-purple as HOMEPAGE?
I don't know. Maybe not. Don't let that stop you from importing.

~Brian



Re: New port: net/telegram-purple

2017-06-22 Thread Stuart Henderson
On 2017/06/22 18:11, Dmitrij D. Czarkoff wrote:
> "Dmitrij D. Czarkoff"  wrote:
> 
> >The attached port contains libpurple protocol plugin that adds support
> >for the Telegram messenger to net/pidgin.
> >
> >OK to import?
> 
> ping

Build-testing only (I'm not going to run pidgin to try it out at runtime),
there are parts where it hardcodes gcc. Otherwise looks ok.

Not directly related to telegram-purple, but shown up by the tests:

loadtest:/usr/local/lib/libsilc.so.10.0: /usr/local/lib/libidn.so.17.2 : 
WARNING: symbol(stringprep_profiles) size mismatch, relink your program

- looks like a conflict between versions of the stringprep_profiles
struct between silc-toolkit and libidn..



Re: New port: net/telegram-purple

2017-06-22 Thread Dmitrij D. Czarkoff
"Dmitrij D. Czarkoff"  wrote:

>The attached port contains libpurple protocol plugin that adds support
>for the Telegram messenger to net/pidgin.
>
>OK to import?

ping


telegram-purple-1.3.1.tgz
Description: application/gzip


New port: net/telegram-purple

2017-06-15 Thread Dmitrij D. Czarkoff
Hi!

The attached port contains libpurple protocol plugin that adds support
for the Telegram messenger to net/pidgin.

OK to import?

--
Dmitrij D. Czarkoff


telegram-purple-1.3.1.tgz
Description: application/gzip