From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id WDObJOCCA2AARQAA0tVLHw (envelope-from ) for ; Sun, 17 Jan 2021 00:20:48 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id oPxRIOCCA2DRYAAAB5/wlQ (envelope-from ) for ; Sun, 17 Jan 2021 00:20:48 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 2160494042E for ; Sun, 17 Jan 2021 00:20:47 +0000 (UTC) Received: from localhost ([::1]:40504 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l0voE-0000Co-SL for larch@yhetil.org; Sat, 16 Jan 2021 19:20:46 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:43878) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l0vnW-0000CW-SF for guix-patches@gnu.org; Sat, 16 Jan 2021 19:20:02 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:32791) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1l0vnW-0000Ls-Kh for guix-patches@gnu.org; Sat, 16 Jan 2021 19:20:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1l0vnW-0004Z6-Fr for guix-patches@gnu.org; Sat, 16 Jan 2021 19:20:02 -0500 X-Loop: help-debbugs@gnu.org Subject: [bug#45721] Telegram Desktop (v9) Resent-From: Raghav Gururajan Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Sun, 17 Jan 2021 00:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45721 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: To: Leo Prikler , 45721@debbugs.gnu.org Received: via spool by 45721-submit@debbugs.gnu.org id=B45721.161084275317485 (code B ref 45721); Sun, 17 Jan 2021 00:20:02 +0000 Received: (at 45721) by debbugs.gnu.org; 17 Jan 2021 00:19:13 +0000 Received: from localhost ([127.0.0.1]:44337 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l0vmi-0004Xx-NQ for submit@debbugs.gnu.org; Sat, 16 Jan 2021 19:19:13 -0500 Received: from relay3-d.mail.gandi.net ([217.70.183.195]:60389) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l0vmg-0004Xh-6w for 45721@debbugs.gnu.org; Sat, 16 Jan 2021 19:19:11 -0500 X-Originating-IP: 76.68.120.100 Received: from [192.168.5.10] (bras-vprn-toroon474rw-lp130-08-76-68-120-100.dsl.bell.ca [76.68.120.100]) (Authenticated sender: rg@raghavgururajan.name) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id CBBAD60002; Sun, 17 Jan 2021 00:19:02 +0000 (UTC) References: <260455952500fcfd067f395a55a7ac78a4f1bd0a.camel@student.tugraz.at> From: Raghav Gururajan Message-ID: Date: Sat, 16 Jan 2021 19:19:01 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Icedove/78.6.0 MIME-Version: 1.0 In-Reply-To: <260455952500fcfd067f395a55a7ac78a4f1bd0a.camel@student.tugraz.at> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: "Guix-patches" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -2.36 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-patches-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-patches-bounces@gnu.org X-Migadu-Queue-Id: 2160494042E X-Spam-Score: -2.36 X-Migadu-Scanner: scn0.migadu.com X-TUID: BJGnJwNjqLda Hi Leo! > congratulations on getting a working Telegram Desktop. I haven't yet > built this version on my own, but I want to comment on the patches a > little. Thanks! Couldn't have done without your help. :-) > LGTM, but there seem to be whitespace issues. Any idea? Those are from the patch file taken from upstream. The pack-def is clean. > Personal nitpick, but those should likely be prefixed with license: > To keep backwards-compatibility, you can (define gpl2+ license:gpl2+) > inside the module. Hmm. I think we have to make changes to all pack-def in this module. As the licenses doesn't use prefix. Can be a separate task. > LGTM. Cool! > Is there a less broad way of doing this? E.g. replacing c++-17 by c++- > 11? Updated in v10. > FWIW there seems to also exist an older version over at > https://gitlab.com/nimf-i18n/nimf > Would it be worth packaging that? Hmm, not sure. I can package it later though. > In my opinion the synopsis should be "Lightweight input method > framework" and the description should mention, that this specific fork > has a special focus on Korean. Updated in v10. > LGTM, albeit admittedly weird. Haha, yeah. > It's not "the", just "a". Usually such projects describe Material > Design in some way, but apparently it has come to a point where just > throwing around the word "Material" is enough. Updated in v10. > I find the following more useful: > [range-v3 is] an extension of the Standard Template Library that > makes its iterators and algorithms more powerful by making them > composable. Unlike other range-like solutions which, seek to do away > with iterators, in range-v3 ranges are an abstration layer on top of > iterators. Updated in v10. > It appears, that this library carries a few more (free) licenses with > it. Perhaps this needs to be revised? Updated in v10. > LGTM. Cool! > LGTM. Cool! > Use a proper version. Packages, that build directly from git without > any tagged versions usually have a preamble of > (let ((commit ) > (revision (package ...)) Updated in v10. > Is there a way of making this checkout non-recursive? I know you've > made that change in accordance to an upstream recommendation, but one > ought to look at it a little closer. Not sure, but we need the sub-modules any way for build. > It seems that some of those inputs are also found as third_party/ > libraries. Can you remove their respective sources from the package? Updated in v10. > I really don't like that synopsis and description. Granted, upstream > offers little to work with, but there ought to be a better way of > phrasing this. Updated in v10. > By the way, it would appear we already have some WebRTC stuff packaged, > but no direct "webrtc" package (which I guess is normal, given that it > is a protocol and not an individual piece of software). How tightly is > Telegram coupled to this specific implementation? Would there be a way > of replacing it with something else (kinda like our udev/eudev > situation)? Nah, telegram made a hard fork. There are some telegram-specific classes and objects. > Would there be a way of moving this into another module, e.g. (gnu > packages messaging)? I first tried there, but the was circular dependency. So moved it to separate module. We can also move telegram-related stuff like tg_owt etc, to this module in the future. Thank you so much for reviewing. :-) Regards, RG.