Ability to specify compiler package for Go build system.

[Hilton Chain]

Hi Guix,

I'm trying to package wakatime-cli[1], while Guix uses Go 1.17 as the default, 
the package requires
Go 1.19 at the current version (v1.60.4).

Though it's possible to package the last version supports Go 1.17 (v1.38.0), I 
wonder if we can
adjust the build system so that a Go package could be specified via an argument 
in the package
definition.

Thanks!

[1] 

Re: Some team related thoughts and questions...

[Vagrant Cascadian]

On 2023-01-09, Simon Tournier wrote:
> On ven., 06 janv. 2023 at 10:42, Vagrant Cascadian  wrote:
>> More I wanted to look through the patch text rather than the package
>> descriptions. It would ideally catch things like "reproducible" or
>> "deterministic" in comments in patches as well as git commit summary.
>
> Well, IIUC, your point would be to have teams based on “topic“ referred
> by search term in patches.  Why not, although it is far to be
> implemented, I guess. ;-)

Sure, it is wishing for a feature, on the hopes that someone more savvy
with parens sees the value and implements it. :)


> BTW, I would recommend to give a look at lei [1,2] from the Guix package
> public-inbox.  For instance, over the last 12 months, all patches
> containing the terms ’r-build-system’ and ’reproducible’,
>
> 1. Extract from a public-inbox instance:
>
> guix shell public-inbox \
>  -- lei q --threads --dedupe=mid \
>  -I https://yhetil.org/guix-patches/ -o /tmp/Mail/patches \
>  'dfn:gnu/packages AND b:r-build-system AND b:reproducible AND 
> rt:12.months.ago..'
>
> 2. Read it with a mail reader support Maildir:
>
> guix shell neomutt -- neomutt -f /tmp/Mail/patches
>
>
> where
>
>dfn: match filename from diff
>b:   match within message body, including text attachments
>rt:  match date-time range, git "approxidate" formats supported
> Open-ended ranges such as `d:last.week..' and `d:..2.days.ago'
> are supported

Thanks for the examples! I have tried to wrap my head around
public-inbox and related tooling, as it seems extremely
useful. Hopefully this gets me into actually using it. :)

Though using public-inbox is obviously working at it from the other end,
not getting CCed on things but having to rummage through the heap of
patches to find them. :)


live well,
  vagrant


signature.asc
Description: PGP signature

Re: skia for libreoffice

[Efraim Flashner]

On Sun, Jan 08, 2023 at 12:21:55PM +0100, Nicolas Graves via Development of GNU 
Guix and the GNU System distribution. wrote:
> 
> Hi!
> (please tell me if I should use another channel for such questions)
> 
> I recently have been working on enabling tests for skia and including
> skia in libreoffice (see bug 60571 for the first part).
> 
> Now that I delve into libreoffice's build of skia, I see that there's a
> series of patches that libreoffice use for the build of the
> library. Which makes me wonder if it's worth it packaging a
> "skia-for-libreoffice" package variant, or if we should just add the
> tarball in the external directory as it has been done with dtoa, and
> rely on libreoffice's build of skia. In the end, both versions will end
> up in the store in any case, because of the patches libreoffice needs.
> 
> What is Guix policy in this case?

It's a toss-up. skia-for-libreoffice wouldn't see any use outside of
libreoffice since it's specific patches and not a different version of
the library. In those cases (especially if the library is maintained
upstream by the same people, which I don't think is the case here) we're
far more lenient on leaving it bundled. On the other hand, separating it
out would decrease the build time for libreoffice, which would be a Good
Thing™.

IF (and I mean it) you can separate it out easily and it doesn't make
building libreoffice with it then go ahead and do so, especially if the
version and/or patches don't change regularly. Otherwise I'd consider
adding a note in libreoffice's snippet (assuming it has one) or
configure-flags about why we're not using an unbundled version.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature