From mboxrd@z Thu Jan 1 00:00:00 1970 From: Maxim Cournoyer Subject: Re: Debugging info unavailability Date: Wed, 03 May 2017 08:22:11 -0700 Message-ID: <87r3066k4c.fsf@gmail.com> References: <20170423020206.41aac1a2@scratchpost.org> <87d1brk1ul.fsf@gnu.org> <87shknnrfm.fsf@gmail.com> <87pofr0xjs.fsf@gnu.org> <87zieu7d8n.fsf@gmail.com> <87bmrah2s3.fsf@elephly.net> <87tw52uu51.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:53614) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d5w6d-00004v-Tt for guix-devel@gnu.org; Wed, 03 May 2017 11:22:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d5w6c-0000uj-OM for guix-devel@gnu.org; Wed, 03 May 2017 11:22:19 -0400 In-Reply-To: <87tw52uu51.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Wed, 03 May 2017 12:11:54 +0200") 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: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: guix-devel@gnu.org --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable ludo@gnu.org (Ludovic Court=C3=A8s) writes: > Ricardo Wurmus skribis: > >> Maxim Cournoyer writes: >> >>>>> Adding the "debug" to the default value of would every pack= age >>>>> to now have a debug output; isn't this why Danny suggested to only >>>>> change it at the build system level? That way nothing which doesn't h= ave >>>>> debugging symbols by default would break or have a useless debug outp= ut. >>>> >>>> Yes, it=E2=80=99s tempting to do it at the build-system level. Howeve= r, there >>>> would now be a discrepancy between the actual outputs of the package >>>> derivations and those of the package object: the package object would >>>> declare just one output, but the corresponding derivation would have t= wo >>>> outputs. >>>> >>> >>> Thanks for pointing that! It would be a Bad Thing indeed to introduce a >>> mismatch between the package definition and the corresponding store >>> item... >>> >>> Possibly another Bad Idea, but we could leave things as they are... And >>> run a script which would rewrite (really, at the package definition >>> level) the package outputs to include "debug" for every package built >>> using the gnu/glib-or-gtk build systems? The commit will not be >>> pretty, that would bring us where we want to be? Being Scheme, that'd be >>> somewhat easy. >> >> This sounds better. I just don=E2=80=99t know if Hydra would have enoug= h space >> for all of these additional outputs. >> >> Can we increase storage space on Hydra already or do we need to wait for >> bayfront to replace the server in Boston? > > I don=E2=80=99t think we can have more space easily on hydra.gnu.org. > > I=E2=80=99m also unsure how much would be needed. Currently =E2=80=98gui= x publish=E2=80=99 > prepares bakes archives on-demand. So if you ask for glibc:out, it > returns 404, prepares it, and the next request for glibc:out will > succeed. But if you ask for glibc:debug, it=E2=80=99s similarly missing > initially. > > With this model, =E2=80=98guix publish=E2=80=99 gives the impression that= not all the > outputs of a given derivation are available at the same time. > > We could change =E2=80=98guix publish=E2=80=99 to =E2=80=9Cbake=E2=80=9D = all the outputs of a derivation > as soon as one if requested=E2=80=94e.g., when you ask for glibc:out, it = bakes > not only glibc:out but also glibc:debug. But then we might have a disk > space issue. > > Thoughts? > > Ludo=E2=80=99. The ideal situation would be to not be space contrived and to build a cache everything or at least following some heuristic such as "every package that was requested at least once in the past month". For someone following master, I find that the current way substitutes are built is not aggressive enough, and I find often find myself building the world with =2D-fallback. What good is a substitute server if it doesn't hold the stuff I need *now*? :) On the other side, it really makes me want to look at GNUnet, which seems like the better long term solution. I'll investigate the script to add "debug" to our gnu/gtk packages. Maxim --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEJ9WGpPiQCFQyn/CfEmDkZILmNWIFAlkJ9aMACgkQEmDkZILm NWKiMg/8Dmbc3i/TymfbneByLlk6u3SsExAEcffRTyM2hj36KqZu/tAzg2CJLt1T KeXdH+8lZyRYtylsIchv9PjcaP9EB65/m4uLnIx1QdeKjkaDFxlfswABuaSRQj2j yh8Z3McRZWRyMQor5m5XLl2yvoTaw0bswhyNlOH8HcxfsGyfA4h5ApXl+14f5GPF L57ovMnMEBlc3TjlXORgHOwSBe0Kcxw3GoezvY3kqO7Qqf6+57PyYhAIeRMienwG Y+pIX0hOM9ktxSo1zgVYP3zCUKV3bkfB7IT7zxHv5xGHrIOkuDHxOKhgd/H46614 BfHSX8OGlWzWoc355PFlQfASPG9zO7zcoDkpUniPmwNZTJYR6c0fO63lrRFHKwrp q/aULRXjNbuTGamwXm28OcITyeMFzLTqQ8Be4fS6cA1MNUGnlqvt9fy70Ap+3w6J 6sNc+j27oLf3KL7Mw8MB1SIvm/dkIDKrRA5HiEtzH5UKI6mjclw3XO+6bvEbWFze JHHndA+7g8h/DytphwaL96xiZy49srV+kNiZ7589HuhrgGtFA2lWtvW4a/qQ+gWn cnztEHyaO2muGJin8IURznlgooKw6YuxMDGA7WU61UAWxdQLZ/AcJMwY57ECpiP+ PL2KwQl6HvTlWoREOcnNvjlTFbgM+oJBFjn/ScJh283Sh2EYhe8= =dksW -----END PGP SIGNATURE----- --=-=-=--