Hi Nicolas/Ludo,
On Fri, Oct 29 2021, Nicolas Goaziou wrote:
Among those, which importers provide source that differs from
what you’d get from upstream’s checkout or release tarballs?
My guess:
elpa (gives hosted tarballs that can differ from upstream
repo)
Indeed.
For MELPA specif
Hi Guixers!
I'd like to invite you to a guix packaging meetup tomorrow (Sat) Oct 30 2021 at
14:00 ET (18:00 PM UTC).
Meetup Link (no password):
https://meet.jit.si/guix-meetup
We'll be packaging on a capsul Guix System VPS. I'll share a tmate url at the
meetup.
Hope to see you there!
jgart
Hello!
Thanks everyone for your feedback!
Lars-Dominik Braun skribis:
> Would it be possible to just run the importer again for existing packages
> and compare the result (minus synopsis/description) with what’s
> available in Guix? That should give you much more accurate numbers than
> our gue
Hello,
Ludovic Courtès writes:
> My understanding is that most of them require manual intervention—i.e.,
> one has to tweak what ‘guix import’ produces, even if we ignore
> synopsis/description/license, to set the right inputs, etc. If we were
> to estimate the fraction of imported packages for
On Fri, Oct 29, 2021 at 06:22:28AM +0200, Liliana Marie Prikler wrote:
> Am Donnerstag, den 28.10.2021, 15:55 + schrieb Mekeor Melire:
> > 1. We generally do not create modules according to the groups of
> > developers, but rather package declarations are grouped into
> > modules ac
Hi,
Thanks for bringing this up, Mekeor.
Leo Famulari skribis:
> On Thu, Oct 28, 2021 at 03:55:26PM +, Mekeor Melire wrote:
>> I would like to propose to split the (gnu packages suckless) module,
>> located in the /gnu/packages/suckless.scm source file.
>
> I agree. There are already a hand
Hi!
Jelle Licht skribis:
> What can we do to make sure we won't simply forget to apply this and
> other such changes?
I’d suggest making this change right away in ‘core-updates’.
After all, the reason we introduced ‘-frozen’ is so we could keep having
fun on ‘core-updates’ while things are be
Hello!
Thiago Jung Bauermann skribis:
> I agree that guix-devel is a good place to announce new RFCs, probably
> using an eye-catching subject prefix so that we can more easily see and
> filter them.
>
> For RFCs where users are also stakeholders, we should also announce in
> places where use
zimoun skribis:
> For instance, try with the package ’sway’ (search bar [1]:
> https://github.com/swaywm/sway). SWH says the status for archiving
> succeeded. Even, it is archived for instance there [2].
>
> Then if you give a look at the visit webpage, it says that the
> repository had been vi
Hi,
Philip McGrath skribis:
> Since 2005, SRFIs have used the MIT/Expat license, and all but two
> older SRFIs were relicensed: however, the SRFI editors were not able
> to contact the author of SRFI 5, Andy Gaynor, so it remains under the
> original SRFI license.[1] That license, modeled on th
zimoun skribis:
> Some should be fixed soon. Other are already fixed but the fix has not
> yet landed to production. However, some are still open; for instance
>
> 26/10/2021, 09:29:59 git https://github.com/scikit-learn/scikit-learn
> accepted failed
>
>
> and the log says:
>
> swh.loader.git.
Hello!
zimoun skribis:
> Using the the URLs reported by this query, I notice:
>
> 1, https://git.code.sf.net is rejected by SWH. For instance, «The
> origin url is not valid or does not reference a code repository» or
> «Error: The "save code now" request has been rejected because the
> pro
Hello!
Timothy Sample skribis:
> Ludovic Courtès writes:
[...]
>> This is truly awesome! (Did you manage to grab all that info with the
>> default rate limit?!)
>
> Yes, but I have another trick. The “known” endpoint [1]. If you
> already know the SWHIDs you want to check, you can check 1,
Hi,
zimoun skribis:
> On Thu, 21 Oct 2021 at 22:47, Ludovic Courtès wrote:
>
>> ‘guix lint -c archival’ uses ‘lookup-origin-revision’, which is a good
>> approximation, but it’s not 100% reliable because tags can be modified
>> and that procedure only tells you that a same-named tag was found,
Hi,
Phil Beadling skribis:
> I was able to write a short manifest that avoided the overwriting of the
> original "foobarpy" package in my case, and instead cleanly replace it with
> a newer version specified using "with-source".
>
> By setting, for example, GUIX_FOOBAR_VERSION=1.23 and
> GUIX_TE
Ludovic Courtès 写道：
Would someone like to contact them on behalf of the project, Cc:
guix-sysadmin? :-)
I'll do it. They know^Wvaguely remember me from our guix-p9.
Kind regards,
T G-R
signature.asc
Description: PGP signature
Hello Maxim,
[ Not sure which mailing list to copy on this email, so I’m adding
guix-devel. I hope you don’t mind. ]
Em quarta-feira, 20 de outubro de 2021, às 15:56:37 -03, guix-
comm...@gnu.org escreveu:
> apteryx pushed a commit to branch core-updates-frozen-batched-changes
> in repository
Hi Greg,
Greg Hogan skribis:
> The cmake-build-system does defer to gnu-build-system, which calls `make
> test -jN`; however, CMake generated Makefile specifies 'test' as a single
> target (the Ninja generator suffers from the same issue) so `ctest` is run
> without parallelism.
>
> To run CMake
Hi!
Vagrant Cascadian skribis:
> I wonder if OSUOSL (or maybe other organizations) would be willing to
> provide a nice big server with access restricted to guix committers or
> something?
>
> https://osuosl.org/services/hosting/
>
> I know they provide some very capable machines for reproduci
Arun Isaac skribis:
> I just realized we might already have something close to this second,
> less powerful offload protocol that needs only one-way trust. According
> to the NEWS file, since Guix 0.13.0, the GUIX_DAEMON_SOCKET environment
> variable lets us specify remote daemons. See "(guix) Th
Hi,
Tobias Geerinckx-Rice skribis:
> Arun Isaac 写道：
[...]
>> Currently, guix offload requires mutual trust between the master
>> and the build machines. If we could make the trust only one-way,
>> security might be less of an issue.
>
> It might! It's easy to imagine a second, less powerful o
21 matches
Mail list logo
