Hello,
On 2024-12-05 07:13, Maxim Cournoyer wrote:
Hi Tomas,
...
I agree it's a bit tedious, both manually and also in diffs. My
personal preference is to leave just one space between the field name
and the value, that also holds for variable bounds in lets, etc., to
avoid the problem (at the
Hi,
On Thu, 05 Dec 2024 15:20:53 +0800,
Efraim Flashner wrote:
>
> I'm now thinking about the easy-package -> hard-package learning curve
> for new contributors, and I'm not sure how we'd address that.
I'm thinking about something like a wiki of packaging examples, where it starts
from a 'hello'
Suhail Singh writes:
> Efraim Flashner writes:
>
>> Also I don't think we should spam the bug tracker with package upgrades,
>> so we'd have to think about something for that.
>
> Could you clarify what you're objecting to? Is it bug issues being
> created that are then not (as is currently the
Hi Guix,
Am Donnerstag, dem 05.12.2024 um 09:06 +0200 schrieb Efraim Flashner:
> On Mon, Dec 02, 2024 at 08:24:29PM +0100, Ricardo Wurmus wrote:
> > Perhaps this would be a good time to revive the antioxidant-build-
> > system
> […]
> I still have a copy of the code on my machine but unfortunately
Suhail Singh writes:
> If we do decide to keep bots in a separate realm as it were, it would be
> desirable (and in my opinion, important) if that still allowed for at
> least as much transparency that the issue tracker provides for human
> activities.
Examples are the guix-cran and guix-bioc ch
> If we do decide to keep bots in a separate realm as it were, it would be
> desirable (and in my opinion, important) if that still allowed for at
> least as much transparency that the issue tracker provides for human
> activities.
what other data would you miss that is not available in the git l
Hilton Chain writes:
> On Thu, 05 Dec 2024 15:20:53 +0800,
> Efraim Flashner wrote:
>>
>> I'm now thinking about the easy-package -> hard-package learning curve
>> for new contributors, and I'm not sure how we'd address that.
>
> I'm thinking about something like a wiki of packaging examples, whe
Hello,
Efraim Flashner skribis:
> I still have a copy of the code on my machine but unfortunately it no
> longer builds due to the constant churn of rust packages.
>
> One thing I remember explicitly about it was that building end packages
> was faster than the current method, and that was befor
Am Mittwoch, dem 04.12.2024 um 09:03 +0100 schrieb Jelle Licht:
> Hi guix,
>
> I've just sent out the v2 series to bump Node.js and friends:
> https://issues.guix.gnu.org/74187
>
> In this proposed series of patches, the version of Node.js
> (node@10.24.1) we use to bootstrap node-llhttp-bootstra
Efraim Flashner writes:
> Also I don't think we should spam the bug tracker with package upgrades,
> so we'd have to think about something for that.
Could you clarify what you're objecting to? Is it bug issues being
created that are then not (as is currently the case) automatically
closed? Or
Attila Lendvai writes:
> sidenote: as a newcomer i found it rather off-putting that the bug
> tracker is full of random two-liner package updates, many long
> forgotten and even obsolete.
This is exactly my point and why I think the bug tracker must contain
only *actionable* work that humans are
On Fri, Nov 29, 2024 at 4:35 AM Liliana Marie Prikler
wrote:
>
> Hi Greg,
>
> Am Montag, dem 25.11.2024 um 13:27 -0500 schrieb Greg Hogan:
> > Guix,
> >
> > Should we have a C++ team? I think project contributions regarding C
> > and C++ compilers, libraries, tools, and programs would benefit from
Attila Lendvai writes:
> what other data would you miss that is not available in the git log?
No data that is currently being automatically generated. Then again,
none of the patches at present are. One can argue (and perhaps that's
what you are) that, even in the future, whatever automated-co
13 matches
Mail list logo
