From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Subject: Re: Packaging Jami progress Date: Thu, 14 Nov 2019 23:16:05 +0100 Message-ID: <20191114231605.0ecec870@kompiuter> References: <20191104214754.793ec2ff@interia.pl> <20191105175001.389c6117@interia.pl> <87pni5qouc.fsf@ambrevar.xyz> <20191106172445.3bdd057d@interia.pl> <87r22lorwh.fsf@ambrevar.xyz> <877e4bo646.fsf@ambrevar.xyz> <20191107204757.23dd08de@interia.pl> <874kzfo21r.fsf@ambrevar.xyz> <20191108192542.5daa7a0a@interia.pl> <87zhh2kdt2.fsf@ambrevar.xyz> <20191111111423.66ec31d5@interia.pl> <87r22ek7x4.fsf@ambrevar.xyz> <874kzajvy9.fsf@ambrevar.xyz> <20191111163843.0629ef41@kompiuter> <87o8xe4d5m.fsf@ambrevar.xyz> <87eeya49hf.fsf@ambrevar.xyz> <20191114214010.7b61005f@kompiuter> <87lfsikttk.fsf@ambrevar.xyz> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:56940) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iVNPY-0001EL-TZ for guix-devel@gnu.org; Thu, 14 Nov 2019 17:16:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iVNPX-0004xD-O0 for guix-devel@gnu.org; Thu, 14 Nov 2019 17:16:20 -0500 Received: from smtpo.poczta.interia.pl ([217.74.65.233]:37864) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iVNPX-0004wS-0u for guix-devel@gnu.org; Thu, 14 Nov 2019 17:16:19 -0500 In-Reply-To: <87lfsikttk.fsf@ambrevar.xyz> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Pierre Neidhardt Cc: Guix-devel On Thu, 14 Nov 2019 22:54:15 +0100 Pierre Neidhardt wrote: > I don't think it's a Jami bug: as I mentioned the same bug affects the > old package so I believe it comes from us. Sorry, didn't read the entire message, I'm a bit tired, because of exams. > The thing is that those are 3 different build processes, so having 3 > packages makes it easier to package. I believe what we have is the > most natural way to go. Okay then. > What do you mean? Guix can be installed on foreign distribution and > Jami would work there the same way it works on Guix System. I mean Windows (ReactOS in the future?), OSX, iOS, Android - Jami is an universal platform. AFAIK there's the option to build with --target=mingw64 or something like this. Could Guix support other targets as well? Some people in the Jami community want to have reproducible builds for Jami, no matter on what distribution. Providing reproducible builds for other systems is going to improve overall security of the platform. > It's the job of the init system to decide what to start. The Guix > pack does not embed any init system information, I don't know if it > can or even if that would make sense. > Wouldn't it be a user service? I'm not sure if I understand this correctly, but autostart on GNU/Linux is handled by different init systems/process supervisors. How is the autostart handled on Guix System? When I searched for the way of adding a program to autostart on Debian-based distributions, I often found tutorials showing how to make an init script or systemd-something, anyway I thought that if libring is a daemon, then there needs to be something written for the Shepherd, but if it's handled as an user service, then it's fine. > I'm not sure there is much more we can do here: regarding the > packaging process, we already have a tutorial (cf. the cookbook) that > covers everything needed to package Jami. (As tough as Jami may be > to package...) I found some things hard/unintuitive, but maybe that's because I didn't entirely read the tutorial. Anyway if I find something worth improving, I'll tell. > Regarding the dependencies, it belongs to upstream > to tell which deps Jami uses; sadly this is not done very well in > their current documentation. We could open an issue I suppose. I'll ask about this. > Cheers! > Jan Wielkiewicz