From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 5E391158094 for ; Mon, 29 Aug 2022 14:53:13 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7B795E086D; Mon, 29 Aug 2022 14:53:12 +0000 (UTC) Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 004B3E086D for ; Mon, 29 Aug 2022 14:53:11 +0000 (UTC) Received: by mail-pl1-x632.google.com with SMTP id jm11so8206531plb.13 for ; Mon, 29 Aug 2022 07:53:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:content-disposition:mime-version :message-id:subject:to:from:date:from:to:cc; bh=74Qr8zKl2Be1O6a5smpeHo4u4g0W3nMDDW0I05ad2ug=; b=Crub5LXBjGsbdUjoJAS/NGkF9mCuBu3CBzs+cipQnlVsNrVYuPNjwqQGHHD1WgEoe5 j2PUnNONNDgMF7ECVfw3iLLqStYmYJ9Y7pgj4WTvYfqh+JOSnxXI4SLEjl+zSuBfmK5W L4qno4R8O6p2Va+O0DlW0Jb7PbYxjl4FoB0OW23uC7Ni/vu9Jv7hu1rQ1T6ojbeS5mhW ZwZ+jotRtP2nA6j6QrMFT9W1a2J17k0ASat/LYnvEDu6SMV0z1QnIlWJ/+gQFzgIjhEB YZy9/ixSfEjj27PZowvyt+dzHrJSqrzXcgZm0aF/bNCOJxR7qIQbqPd4NzxvwZifgf9m mMLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:content-disposition:mime-version :message-id:subject:to:from:date:x-gm-message-state:from:to:cc; bh=74Qr8zKl2Be1O6a5smpeHo4u4g0W3nMDDW0I05ad2ug=; b=otB2cMyOOJqtLhL4ZnkZgd4Ev11NqGlwYm+DJUbA1ea5/9nNhsWRTPnNWhaNa5VhRc ZOXR7ooIm3bmkBuvnPAlZW0GLSCtNl0uvUrYzgSK0Ok41m2N0EKmmNTaWIPizHEdeLL6 /RU88YzuaXr5GgQxTTjRE20juOfdd4S+1WyPKZT5GmKM3m2uYwyXuYL6zrbhaKSLfeMr FiLnEJpR6tvlzwSVkj6iQ/Reow6wcqlSSvwzKv+VlUL1jnOpgdspjUYiIJ9HkhEV+Vjo Mm4KqRJ++zZD6E88V+Lp9P+A+8Hj4Ds0CTnUnzTlacTvs1dfVyvg7MAWq9tTPQSbG4/a Ua8w== X-Gm-Message-State: ACgBeo37q2bbtHmljTm07gVyR7Jmc8RpS7GZ5D3stYDVM8HhdRP/HEQU vl44oqRaOa7pXP9ad0cy5d7+pjiE03B+4A== X-Google-Smtp-Source: AA6agR6vKROfghFokRcQFnpgvA36O1+USTpA1af0RC9NiZxej2JoGEHTjptTatxk22HCKgB5fo3AGw== X-Received: by 2002:a17:90a:a097:b0:1fb:5bc:7778 with SMTP id r23-20020a17090aa09700b001fb05bc7778mr18874050pjp.209.1661784791121; Mon, 29 Aug 2022 07:53:11 -0700 (PDT) Received: from localhost (49.212.183.201.v6.sakura.ne.jp. [2403:3a00:202:1120:49:212:183:201]) by smtp.gmail.com with ESMTPSA id o9-20020aa79789000000b00535da15a252sm7335466pfp.165.2022.08.29.07.53.09 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Aug 2022 07:53:10 -0700 (PDT) Date: Mon, 29 Aug 2022 22:53:07 +0800 From: wuyy To: gentoo-soc Subject: [gentoo-soc] Week 11 Report for Refining ROCm Packages in Gentoo Message-ID: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-soc@lists.gentoo.org Reply-to: gentoo-soc@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Archives-Salt: f9b49109-eeed-4717-a6c4-7dc13c03d654 X-Archives-Hash: 072fb11158a7dd115aafc5903604fc08 Hello all, My progress this week is mainly writing wiki and refining rocm.eclass. Although the current eclass can work with my new ebuilds [1], Michał Górny has pointed out various flaws on the Github PR [2]. He also pointed out the necessity about rocm.eclass, because it seems like a combination of two eclasses. In my opinion, rocm.eclass has its value, mainly for handling USE_EXPANDS and common phase functions. The ugly part is mainly in rocm_src_test: due to the inconsistency of test methods of packages in [3], I have to detect which method is using and do it accordingly. So my plan is to split the one-size-fits-all rocm_src_test into two functions, corresponding to two scenarios (cmake test or standalone binary), and let each ebuild decide which to use. This can avoid detailed detection code that make rocm_src_test bloated. Wiki writing: I think the main part of ROCm wiki[1] and HIP[2] is nearly finished. But due to the delay of rocm.eclass, the related information is not appended (ROCm#Developing guide). There is also a section a reserved: ROCm#Installation guide. I have little clue on how to write this part, because ROCm is a wide collection of packages. Maybe a meta package (there are users working on this) would be helpful. To be honest I'm a bit anxious, because there is only one week left, but there are still a lot to be determined and tested on rocm.eclass along with the sci-libs/roc* ebuilds. I hope I can resolve these core issues in the last week. [1] https://github.com/littlewu2508/gentoo/tree/rocm-5.1.3-scilibs [2] https://github.com/gentoo/gentoo/pull/26784 [3] https://github.com/ROCmSoftwarePlatform [4] https://wiki.gentoo.org/wiki/ROCm [5] https://wiki.gentoo.org/wiki/HIP -- Yiyang Wu