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 Ooe+GdsqA2B/JQAA0tVLHw (envelope-from ) for ; Sat, 16 Jan 2021 18:05:15 +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 0GFtFdsqA2D/WAAAB5/wlQ (envelope-from ) for ; Sat, 16 Jan 2021 18:05:15 +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 0890D9404CE for ; Sat, 16 Jan 2021 18:05:11 +0000 (UTC) Received: from localhost ([::1]:51882 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l0pwk-0003g6-Ri for larch@yhetil.org; Sat, 16 Jan 2021 13:05:10 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:45208) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l0pwc-0003fH-Ho for guix-patches@gnu.org; Sat, 16 Jan 2021 13:05:02 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:60654) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1l0pwc-0003wr-Ab for guix-patches@gnu.org; Sat, 16 Jan 2021 13:05:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1l0pwc-0001fa-5J for guix-patches@gnu.org; Sat, 16 Jan 2021 13:05:02 -0500 X-Loop: help-debbugs@gnu.org Subject: [bug#45721] Telegram Desktop (v9) References: In-Reply-To: Resent-From: Leo Prikler Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Sat, 16 Jan 2021 18:05: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: 45721@debbugs.gnu.org Received: via spool by 45721-submit@debbugs.gnu.org id=B45721.16108202836378 (code B ref 45721); Sat, 16 Jan 2021 18:05:02 +0000 Received: (at 45721) by debbugs.gnu.org; 16 Jan 2021 18:04:43 +0000 Received: from localhost ([127.0.0.1]:43967 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l0pwI-0001eo-Qe for submit@debbugs.gnu.org; Sat, 16 Jan 2021 13:04:43 -0500 Received: from mailrelay.tugraz.at ([129.27.2.202]:27303) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l0pwF-0001ec-Ih for 45721@debbugs.gnu.org; Sat, 16 Jan 2021 13:04: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 4DJ5Xz6dmQz3wWT; Sat, 16 Jan 2021 19:04:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1610820276; bh=6VRa94G/59Ira0bwflYM5H9DO798cWIK4q6Fr3wzatw=; h=Subject:From:To:Cc:Date; b=aBm/y5HkLyE6qDPfgUEbsN8cMh44ls8RcW5xWk68huH80Wg8Pn5kftMjdnbrgVsle gYUYPVos3B68+05KWgSRkkocWeDZYBypB71PaRZIjm28EzzV6OHI1EW8gLBaWxvFvq PyG2sJR7ijO++RPTlRdV0QAJ5fUIFfL2jsBtYrTg= Message-ID: <260455952500fcfd067f395a55a7ac78a4f1bd0a.camel@student.tugraz.at> From: Leo Prikler Date: Sat, 16 Jan 2021 19:04:35 +0100 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: , Cc: Raghav Gururajan Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: "Guix-patches" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -1.25 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=tugraz.at header.s=mailrelay header.b="aBm/y5Hk"; 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: 0890D9404CE X-Spam-Score: -1.25 X-Migadu-Scanner: scn0.migadu.com X-TUID: /Xrsv02NLmVw Hi Raghav, 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. Am Freitag, den 15.01.2021, 11:08 -0500 schrieb Raghav Gururajan: > * gnu/packages/cpp.scm (gsl): New variable. > * gnu/packages/patches/gsl-gtest.patch: New file. > * gnu/local.mk (dist_patch_DATA): Add it. LGTM, but there seem to be whitespace issues. Any idea? > (define-module (gnu packages fcitx) > - #:use-module ((guix licenses) #:select (gpl2+)) > + #:use-module (guix licenses) Personal nitpick, but those should likely be prefixed with license: To keep backwards-compatibility, you can (define gpl2+ license:gpl2+) inside the module. > * gnu/packages/language.scm (libchewing): New variable. LGTM. > + (add-after 'unpack 'patch-std > + (lambda _ > + (substitute* '("configure" "Makefile") > + (("17") > + "11")) > + #t)) Is there a less broad way of doing this? E.g. replacing c++-17 by c++- 11? > + (git-reference > + (url "https://github.com/hamonikr/nimf.git") > + (commit > + (string-append "nimf-" version)))) FWIW there seems to also exist an older version over at https://gitlab.com/nimf-i18n/nimf Would it be worth packaging that? > + (synopsis "Korean input method framework") > + (description "Nimf is a lightweight, fast and extensible input > method > +framework.") 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. > * gnu/packages/cmake.scm (cmake-shared): New variable. LGTM, albeit admittedly weird. > + (synopsis "Material Decoration for Qt") > + (description "MaterialDecoration is the client-side decoration > for Qt > +applications on Wayland.") 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. > + (description "Range-v3 is the range library for > C++14/17/20. This code was > +the basis of a formal proposal to add range support to the C++ > standard library.") 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. > + (license > + (list > + ;; Dual-Licensed > + license:expat > + license:ncsa)))) It appears, that this library carries a few more (free) licenses with it. Perhaps this needs to be revised? > * gnu/packages/cpp.scm (rlottie): New variable. LGTM. > * gnu/packages/qt.scm (qt5ct): New variable. LGTM. > +(define-public tg_owt > + (package > + (name "tg_owt") > + (version "0.0.0") Use a proper version. Packages, that build directly from git without any tagged versions usually have a preamble of (let ((commit ) (revision + (source > + (origin > + (method git-fetch) > + (uri > + (git-reference > + (url "https://github.com/desktop-app/tg_owt.git") > + (commit "fa86fcc") > + (recursive? #t))) 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. > + (inputs > + `(("abseil-cpp" ,abseil-cpp) > + ("alsa" ,alsa-lib) > + ("ffmpeg" ,ffmpeg) > + ("libjpeg" ,libjpeg-turbo) > + ("libsrtp" ,libsrtp) > + ("libvpx" ,libvpx) > + ;; ("libyuv" ,libyuv) > + ("openh264" ,openh264) > + ("openssl" ,openssl) > + ("opus" ,opus) > + ("protobuf" ,protobuf) > + ("pulseaudio" ,pulseaudio) > + ("rnnoise" ,rnnoise))) It seems that some of those inputs are also found as third_party/ libraries. Can you remove their respective sources from the package? > + (synopsis "WebRTC build for Telegram") > + (description "TG_OWT is the packaged build of WebRTC, for its > use in > +Telegram-Desktop application.") 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. 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)? > * gnu/packages/telegram.scm: New module. > * gnu/local.mk (GNU_SYSTEM_MODULES): Add it. > * gnu/packages/telegram.scm (tdesktop): New variable. Would there be a way of moving this into another module, e.g. (gnu packages messaging)? Regards, Leo