GNU bug report logs - #45954
Telegram-CLI

Previous Next

Full log

View this message in rfc822 format

From: Raghav Gururajan <rg <at> raghavgururajan.name>
To: Leo Prikler <leo.prikler <at> student.tugraz.at>, 45954 <at> debbugs.gnu.org
Cc: Jonathan Brielmaier <jonathan.brielmaier <at> web.de>
Subject: [bug#45954] Telegram-CLI (v7)
Date: Mon, 1 Feb 2021 21:33:43 -0500

[Message part 1 (text/plain, inline)]

Hi Leo!

> I didn't notice this before, but is there a reason to package this
> version over 1.3.1?

Yeah, there are quite a lot of improvements after the 1.3.1 release.

> Please stop trying to use this as a snippet to mean "the root of the
> source and build directory".  It is extremely obscure and people are
> already using "../source" just fine.  (Just do an rgrep if you aren't
> convinced.)

Fixed in v8.

>> Hmm. I tried but couldn't come up with a way to do it like that. :(
> You can still try harder for v8 ;)

I tried different ways but the arguments key-words between gnu and copy 
differ a lot. I am unable use key-words from both build systems at the 
same time. Like using #:configure-flags (from gnu) and #:install (from 
copy).

Also, I spent significant amount time to come up the phase I have. So if 
there are no critical issues, I would like to keep it as-is. :-)

>> The script may only be used on foreign-distro for now. For guix
>> system,
>> we need to define a service for it.
>>
>> Also, running telegram-cli doesn't require daemon, but vice-versa.
>> The
>> daemon is intended to be a complimentary feature to run telegram-cli
>> on
>> headless server.
> In that case, does the daemon script have any value of its own?  Given
> that the latest release of telegram-cli is about six years old, I doubt
> there is – foreign distros should already have it in their repos and
> Guix as a package manager makes no claim to manage system stuff like
> services on foreign distros.
> 
>> The file is a run-time script.
> That means literally nothing.  The wrap phase exists for a reason, some
> programs and script are even wrapped twice.
> 
>> Using (getenv "PATH") will instead use the value of PATH inside the
>> build environment.
> So you'll inadvertently have some native-inputs in it, is what you're
> trying to say?  Of course, there are better ways of wrapping PATH, but
> in this case wouldn't it be wise to limit it to just the expected
> paths?  Again, assuming that there is even merit in shipping this file,
> which is yet to be proven.

I don't know what I was thinking. XD. It is pretty useless to ship. I 
removed it in v8.

Regards,
RG.

[OpenPGP_0x5F5816647F8BE551.asc (application/pgp-keys, attachment)]

[OpenPGP_signature (application/pgp-signature, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.