From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14217 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Brian Peregrine Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: Adapting binaries easily to musl, or database with binaries (musl) Date: Sun, 9 Jun 2019 14:10:31 +0000 Message-ID: References: <20190608105133.GX16415@port70.net> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="126147"; mail-complaints-to="usenet@blaine.gmane.org" To: musl@lists.openwall.com Original-X-From: musl-return-14233-gllmg-musl=m.gmane.org@lists.openwall.com Sun Jun 09 16:10:53 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1hZyX4-000Whq-Il for gllmg-musl@m.gmane.org; Sun, 09 Jun 2019 16:10:50 +0200 Original-Received: (qmail 1313 invoked by uid 550); 9 Jun 2019 14:10:45 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 1289 invoked from network); 9 Jun 2019 14:10:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=5bP9PrKMMQ6+HjaMECa593vIvEhvY2hugfiT1GfD/cc=; b=bMy8Y4dwFG2Or6YA0piR+nfBlKpQwI0gFErrBQhPhiy3BMOezbOrbU050J60+wFVnw 5htm44weyUrjpZ1D68gyj8/lyu1fAt0A9zs0wRX55cinzAIconag2KtFeiWixJxzxftw b+hc5+Y1kLkkvhU3ab6WYoj64LwO4Nn8Z8aqXq3byi274GIEglW207rm6Zkhir7Xvy60 W44twqxN1l8wMoGsBDurGYEpeqrCsw3dDt5dbrXeq4d2XRRCjb54xdNotWhv45/Y56Ly c+1Ej7eGvb7JoxWc8C9QuAHgxJh+T2CJG9Gewv/QNMJxV6e+apo18plG7E7K8lYW8KIT SFBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=5bP9PrKMMQ6+HjaMECa593vIvEhvY2hugfiT1GfD/cc=; b=jyX3fIgN2G74KS9ufW+Iv1zTkCD89Y3uQ9wUGaQgWRPuw47cRpM/+X6v+FXnkvo3a8 YHfAQHz0dvGvP14cfgKCdoPTnv1NssH4hpJbsHY7nQBZDMmt4TLgSy8XtrlP0KyhUuZT eb18gYa16ZbH/Kp9vXVlBBK1F2zi9f3+SJF+MUJUQURgx+2DkHCCUaoV1HT7rL1CHNsr Vr0WWbirewXbj9IQP3Sw4LfzGxeR8SPhYKhejwsxBuhUgc2NkZaUSpzXc6u6+crzxAjd N3pOLtrj5GpS7qQj7n+2baHxpVUte236o1VFd9C84T8jqCfR+Le86IL7qukQBJEzRNYr JjBA== X-Gm-Message-State: APjAAAWZ51JUTJqegoFr2NyRBhnXs1W9k0m6hQx3rWAQzpG7weVjOUSR UJuv4wDhzqYGv+q3cLBmYTJJmhZ6ufW1cVZXjEKg3yix X-Google-Smtp-Source: APXvYqxYwJM3psO7LqAmZrRKyxNjZjzqtcmohrO90wV8lNHj5bcU7owyeOtkVMrFcD1dBJrmU64J5mSeMeyZoWesk1s= X-Received: by 2002:a67:f918:: with SMTP id t24mr21524224vsq.234.1560089432590; Sun, 09 Jun 2019 07:10:32 -0700 (PDT) In-Reply-To: <20190608105133.GX16415@port70.net> Xref: news.gmane.org gmane.linux.lib.musl.general:14217 Archived-At: I've been trying to get firefox musl (from https://distfiles.adelielinux.org/adelie/1.0-beta3/user/pmmx/ ) started (haven't gotten much further then a XPCOMGlueLoad error so far). Regardless of this, I did notice that the firefox version is 52.9.0-r4 whereas we're currently at version 67, so not sure whether that's recent enough for github. I'm also thinking whether this is really the best approach or not. One alternative could be to just download the ebuild from portage, and then compile it for musl i686 to a usb stick (main reason for putting the files to a usb stick is that TAZ is a livecd so you can only store files for a limited duration -any files not stored on removable media are erased at reboot). After saving the files to the usb stick, the user would start the program from the usb stick (so not copying the files manually to the system; reason is that it's easier to not copy the files every time and the system itself is read-only, no copying to the system is permitted) I don't know however whether * ebuilds from portage can be compiled under musl at all * whether the files saved this way can actually be started from usb stick (I doubt the files thus obtained by this method qualify as a "binary") * whether compiling programs using portage is leaner (less cpu/ram intensive) then compiling the programs from (github) source (assuming there is a difference at all). This is important as since it's a live cd, it is already ram-intensive and we also focus on low-spec machines (starting from i686) Another possible way is to use anbox on gentoo and run the android versions of the programs (which can be found easily at the app store) directly (so not through installation with APK Tools). I don't know however whether this would run at all under gentoo musl and it's probably also overkill (as anbox, adb, ... need to be installed and the android programs might also not be stable even if they do run) On 6/8/19, Szabolcs Nagy wrote: > * Brian Peregrine [2019-06-08 09:33:32 +0000]: >> I looked at https://distfiles.adelielinux.org/adelie/1.0-beta3/user/pmmx/ >> but those are apk packages. I actually want something that avoids >> users needing to compile non-standard programs themselves and have >> these technical (compiling) skills to begin with. > > you can bundle the apks into a self extracting script. > >> >> I'm not familiar with apk packages; can these simply be unzipped (ie >> with xarchiver) and can the unzipped files then run directly in gentoo >> (same as with a binary) ? If so, then it would be suitable >> (installation with APK Tools wouldn't be suitable as we have ). I > > $ file foo.apk > foo.apk: gzip compressed data > $ gunzip /dev/stdin: POSIX tar archive > > it's a tar.gz with the files to install and some metadata. > > a packaging tool can manage dependencies, so you can > install/uninstall/update components easily, if you do > it with a third party script, it will be unclear what > deps come from the system and what deps from the script > and how to manage security updates for the latter. > and if the abi of a system component changes after an > update then the third party app may stop working. > > extracting is likely not enough, you want to put the > binaries under a separate directory and set up paths > for that so lib/exe/etc is found by the app. > >> don't care too much with these on whether it's for i586 and not i686 >> as long as it runs and people can download the file quickly and run >> without too much fuss (the extraction step doesn't add that much time >> compared to compiling it, ...), mainly as it's just a 2nd browser that >> would not be used often, except in special cases. >> >> For TAZ, VCT Labs compiles the standard gentoo packages and makes sure >> it runs under musl, in TAZ. So technically, there's not reason why we >> can't do this for firefox, and simply include that program (firefox) >> in our distro. Why haven't we done, you might ask. Reason is that we >> already have a browser (Palemoon) and this has been made to run under >> musl. However, for only certain websites (github for instance) it >> doesn't work, even when using (recent firefox or chrome user agent >> strings). I don't want to add another browser in our distro since that >> would be (most of the time) redundant and I want TAZ users to use >> Palemoon (as that focuses on security and simplicity more). >> >> We also have git-scm but that doesn't allow to do all functions github >> has (for instance, changing the profile photo, modifying git issues, >> ...) and I think that it's also annoying to need to use git-scm when >> you need to change just a few lines on your repo (which in the >> browser, would take far less time to do then with git-scm). >