From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id FRDALLiGA2CdcgAA0tVLHw (envelope-from ) for ; Sun, 17 Jan 2021 00:37:12 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id cJ8dKLiGA2DlcAAA1q6Kng (envelope-from ) for ; Sun, 17 Jan 2021 00:37:12 +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 5EFE79403D6 for ; Sun, 17 Jan 2021 00:37:12 +0000 (UTC) Received: from localhost ([::1]:45128 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l0w47-0003GB-BN for larch@yhetil.org; Sat, 16 Jan 2021 19:37:11 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:45488) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l0w3z-0003G2-AF for guix-patches@gnu.org; Sat, 16 Jan 2021 19:37:03 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:32813) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1l0w3y-0006HW-Dw for guix-patches@gnu.org; Sat, 16 Jan 2021 19:37:03 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1l0w3y-0004zI-Ar for guix-patches@gnu.org; Sat, 16 Jan 2021 19:37:02 -0500 X-Loop: help-debbugs@gnu.org Subject: [bug#45721] Telegram Desktop (v9) Resent-From: Leo Prikler Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Sun, 17 Jan 2021 00:37: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: Raghav Gururajan , 45721@debbugs.gnu.org Received: via spool by 45721-submit@debbugs.gnu.org id=B45721.161084380419148 (code B ref 45721); Sun, 17 Jan 2021 00:37:02 +0000 Received: (at 45721) by debbugs.gnu.org; 17 Jan 2021 00:36:44 +0000 Received: from localhost ([127.0.0.1]:44359 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l0w3f-0004yl-VC for submit@debbugs.gnu.org; Sat, 16 Jan 2021 19:36:44 -0500 Received: from mailrelay.tugraz.at ([129.27.2.202]:18914) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l0w3d-0004yc-BQ for 45721@debbugs.gnu.org; Sat, 16 Jan 2021 19:36:42 -0500 Received: from nijino.local (217-149-173-242.nat.highway.telekom.at [217.149.173.242]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4DJGFK6mqCz3xsX; Sun, 17 Jan 2021 01:36:37 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1610843798; bh=TvABs/Zg7KI/PKiFouKPkBILlNjroQc/6YuUVWb26Ho=; h=Subject:From:To:Date:In-Reply-To:References; b=hxKf5Xwsi0V/VA+2QLluqc8FSCQdmanMMK9wZoIA6gx2xlVg2p3A9iz8LscApvhF7 RJlxpwrfFY7cbwmukvjXpWPCPa1R32kLb8eZNA4uPsUdp63YwHO0uW2K3Y+VVmgXH/ j6xa2+jZRbMgEPYelZZ6XIZZQeTJgw0vWrdKlrU8= Message-ID: From: Leo Prikler Date: Sun, 17 Jan 2021 01:36:37 +0100 In-Reply-To: References: <260455952500fcfd067f395a55a7ac78a4f1bd0a.camel@student.tugraz.at> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.2 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-TUG-Backscatter-control: bt4lQm5Tva3SBgCuw0EnZw X-Spam-Scanner: SpamAssassin 3.003001 X-Spam-Score-relay: -1.9 X-Scanned-By: MIMEDefang 2.74 on 129.27.10.116 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: -1.26 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=tugraz.at header.s=mailrelay header.b=hxKf5Xws; dmarc=fail reason="SPF not aligned (relaxed)" header.from=student.tugraz.at (policy=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: 5EFE79403D6 X-Spam-Score: -1.26 X-Migadu-Scanner: scn1.migadu.com X-TUID: VkrCaqtXkOGf Hi Raghav, Am Samstag, den 16.01.2021, 19:19 -0500 schrieb Raghav Gururajan: > 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. Nvm then. > > 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. Again, you can (define gpl2+ license:gpl2+) at the start of the module, so that existing definitions can be kept the same, but your packages adhere to the license: style. > > LGTM. > > Cool! > > > Is there a less broad way of doing this? E.g. replacing c++-17 by > > c++- > > 11? > > Updated in v10. Yes, okay. > > 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. Already discussed that one in IRC. > > 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. Okay. > > 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. Thanks. > > It appears, that this library carries a few more (free) licenses > > with > > it. Perhaps this needs to be revised? > > Updated in v10. Seems okay, I also saw you double-checking in IRC. > > 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. Use full commit hashes please. > > 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. Perhaps, but it seems kinda weird, that this package gets special treatment in how we accept anything else it might pull in. > > 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 don't particularly agree with the way this has been solved in v10. Do we really need to keep around custom forks and old versions? Can we not instead patch tg_owt? > > 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. Yep, that sounds better. > > 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. Fair enough. > > 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. That would make sense in my opinion. Regards, Leo