On Thu, Feb 15, 2024 at 11:29:55AM +0100, Konrad Hinsen wrote:
> Hi Saku,
>
> > Maybe someone else can give more general or Guix specific advice on
> > finding out the cause of such problems, but I believe that in this case
> > the fix would just be packaging GHC for aarch64-linux. It should[1] be
On Tue, Feb 06 2024, Suhail wrote:
> Steve George writes:
>
>> elsewhere in the thread someone mentions some tags we could use
>> consistently so maintainers can find patches that have been reviewed
>> easily.
>
> It seems on the [dev manual] we already have "reviewed-looks-good"
> documented. T
Am Fri, Feb 16, 2024 at 11:56:50AM +0100 schrieb Clément Lassieur:
> Would it makes sense to have a "does-not-apply" tag too?
Should this not appear in the QA page, assuming that once all the new
issues are closed, older ones will bubble to the top and be treated by QA?
(I am not sure if just look
On Fri, Feb 16 2024, Andreas Enge wrote:
> Am Fri, Feb 16, 2024 at 11:56:50AM +0100 schrieb Clément Lassieur:
>> Would it makes sense to have a "does-not-apply" tag too?
>
> Should this not appear in the QA page, assuming that once all the new
> issues are closed, older ones will bubble to the top
Clément Lassieur writes:
> On Fri, Feb 16 2024, Andreas Enge wrote:
>
>> Am Fri, Feb 16, 2024 at 11:56:50AM +0100 schrieb Clément Lassieur:
>>> Would it makes sense to have a "does-not-apply" tag too?
>>
>> Should this not appear in the QA page, assuming that once all the new
>> issues are close
Hi Simon,
Simon Tournier writes:
> Hi,
>
> On dim., 11 févr. 2024 at 11:38, Maxim Cournoyer
> wrote:
>
>> 'b4 shazam' is probably the most trouble-free way to apply patches;
>
> I agree*!
>
>> it
>> even selects the latest rev
Hi Clément,
Clément Lassieur writes:
[...]
>>> I also agree! :-) What appears to me “difficult” is that most of the
>>> tools as Email client are poorly supporting Message-ID.
>>>
>>> For instance, debbugs.el (Gnus). To my knowledge, there is not easy way
>>> to get the Message-ID when readin
Hi Sharlatan,
Sharlatan Hellseher writes:
> Hi Guix!
>
> I've pushed split IV
> https://issues.guix.gnu.org/69042
>
> Now there are all base golang-* modules which I'm about to populate on demand
> during patch review.
>
> - golang-build
> - golang-check
> - golang-compression
> - golang-crypto
one more quick change that I've realized will be necessary: add a
bootloader-targets field to boot-parameters. some bootloaders would
need target info to know where to install config files, and
reinstall-bootloader doesn't have access to the operating-system
record. rollbacks to generations pre-fie
hi everyone!
I've been working on submitting to mainline some bootloaders I
packaged a while ago on my channel (an efi-stub bootloader supporting
secure boot & full disk encryption and p-boot for pinephones) and came
across a good few hard points in how guix handles bootloaders. the
current system
Hi,
I wonder whether it's possible to maintain a channel using
gitlab-ci. Any thought or experiences to share?
My idea is to schedule jobs which are refreshing the packages,
building/testing them and to provide substitutes.
The channel is meant for Tryton (t
11 matches
Mail list logo
