arm-none-eabi toolchain and compiling C++ stuff
Hello Attila, lately I've been trying to make arm-none-eabi toolchain with gcc 12.3, since the older ones cannot be used with QMK. I also stumbled accross this issue. The issue is actually caused by wrong order of paths in "CROSS_CPLUS_INCLUDE_PATH". The C include path has to come after the C++ path. So as a workaround, remove the /include from beginning of this, and append it instead as last. Apart from that you will probably have an issue with linking against the libstdc++, since it's inside of "lib" folder instead or "arm-none-eabi/lib" that is in CROSS_LIBRARY_PATH. As a workaround, just add "$GUIX_ENVIRONMENT/lib" to "CROSS_LIBRARY_PATH". I will try to submit the 12.3 patch soon. In the mean time I have it inside of my own channel https://github.com/Rutherther/guix-exprs/blob/main/ruther/packages/embedded.scm Redards, Rutherther
Re: LibreWolf 130.0-1 notes
Hi Ian, sex 06 set 2024 às 08:29:40 (1725622180), i...@retrospec.tv enviou: > 130.0-1 is out, but there’s an issue around DNS-over-HTTP preferences > changing[1] in this version. Since this has a negative impact on users > requiring them to reset their preferences to correct, I’m skipping this one > and will package the next release. > > I separately have an issue open with them around the Firefox 130 AI Chatbot > integration. This uses non-free "AI" services which have been trained on > stolen GPL code, and hopefully will get stripped out of LW. It’s an > experimental opt-in feature at the moment, but shouldn’t be present at all. > > Once there’s a fix for #1975, I’ll work on packaging it, disabling the AI > nonsense in the Guix package definition, if necessary. > > Thanks, > > — Ian > > [1]: https://codeberg.org/librewolf/issues/issues/1975 In my opinion we should keep these discussions open and transparent for the whole guix community, unless there are some serious concerns in sharing it with the internet at large or if they are truly personal exchanges of no interest to other guix. Since I believe your above message _is_ of interest to guix (guixen could have a different understanding on this heated debate and could have a distinct judgement on the desirability of skipping this release), there is no personal or private information on your message and since we were instructed to keep team discussions on guix-devel[1], I'm taking the liberty to CC the list here. As for the content of your message, I think it's your take here, but IMO the DoH bug is annoying but not a show stopper, unless of course they are about to release a fixed version (which seems to be the case). As for the 'non-free AI services', well aren't services beyond free/non-free or always non-free since they run on machines beyond users' control? I did not read on it though and would certainly be in favor of removing it if it means that librewolf would be auto-connecting to some services upon start or if it has code that is collecting /analyzing users' input, suggesting services or etc. Finally, though I see why some people are concerned with corporations training models on GPL'd code without attribution and without warning their users of the need to respect GPL when further sharing, I'd suggest you to avoid loaded terms such as 'stolen'[2]. License or copyright infringement should not be equated with theft, copyright should not be equated with private property. IMO it goes against the very core idea of free software to equate those things. 1. https://lists.gnu.org/archive/html/guix-devel/2024-08/msg00174.html 2. https://www.gnu.org/philosophy/words-to-avoid.html#Theft
Re: Rebasing commits and re-signing before mergeing (Was: ‘core-updates’ is gone; long live ‘core-packages-team’!)
On Fri, Sep 06, 2024 at 01:29:11PM -0700, Vagrant Cascadian wrote:
> > In Guix, the "signed-off-by" tag gives credit to the reviewer of the
> > patch, but doesn't indicate anything about authority to push to
> > guix.git.
>
> That sounds more like a Reviewed-by tag.
>
> from doc/contributing.texi:
>
> When pushing a commit on behalf of somebody else, please add a
> @code{Signed-off-by} line at the end of the commit log message---e.g.,
> with @command{git am --signoff}. This improves tracking of who did
> what.
We used the signed-off-by tag for years before we started signing
commits, so in Guix it has also indicated the person who performed the
primary review of the patch / commit.
> My understanding of what properly signed commits tell me, at least in
> the context of Guix, is that the person who has signed a given commit
> has made reasonable efforts to ensure the code works, is freely
> licensed, and is not malicious, etc.
I see. That's a misconception. The commit signature can only be used as
a code-signing authorization tool, to control access to the
authoritative copy of the codebase and, transitively, to control access
to users' computers.
The project leadership does aim to only authorize people they believe
will make the efforts you describe above.
But in Guix, the requirement to make those efforts is only enforced
socially.
There are no mechanisms to ensure that the build is not broken on the
master branch, etc.
Re: core-update scope
On Wed, Sep 04, 2024 at 10:01:28AM +0100, Christopher Baines wrote: > It doesn't seem like a core package to me, but also every branch doesn't > need a team. It's fine to have a ffmpeg or ffmpeg-update branch and just > bump that one package. > > There's a balance to be struck in grouping packages together to both > minimise builds but also make changes easier to test. I agree, we don't have to have a team for this. I'm not sure anyone else cares about the "media" packages as a whole. But if there is interest, that's good too. If I find the time, I would personally batch the codec updates with FFmpeg and GStreamer updates since they are largely equivalent in the package graph.
Re: Rebasing commits and re-signing before mergeing (Was: ‘core-updates’ is gone; long live ‘core-packages-team’!)
On 2024-09-07, Leo Famulari wrote:
> On Fri, Sep 06, 2024 at 01:29:11PM -0700, Vagrant Cascadian wrote:
>> > In Guix, the "signed-off-by" tag gives credit to the reviewer of the
>> > patch, but doesn't indicate anything about authority to push to
>> > guix.git.
>>
>> That sounds more like a Reviewed-by tag.
>>
>> from doc/contributing.texi:
>>
>> When pushing a commit on behalf of somebody else, please add a
>> @code{Signed-off-by} line at the end of the commit log message---e.g.,
>> with @command{git am --signoff}. This improves tracking of who did
>> what.
>
> We used the signed-off-by tag for years before we started signing
> commits, so in Guix it has also indicated the person who performed the
> primary review of the patch / commit.
Well, guix documentation mentions both Signed-off-by and Reviewed-by,
even if historically there was different practice in use...
Given that "pushing a commit on behalf of someone else" also necessarily
requires for all practical purposes "signing" the commit with a valid
key, I read that as the two going together. Although there might be a
Signed-off-by by someone other than the signer.
Not a huge deal, really, in any case.
>> My understanding of what properly signed commits tell me, at least in
>> the context of Guix, is that the person who has signed a given commit
>> has made reasonable efforts to ensure the code works, is freely
>> licensed, and is not malicious, etc.
>
> I see. That's a misconception. The commit signature can only be used as
> a code-signing authorization tool, to control access to the
> authoritative copy of the codebase and, transitively, to control access
> to users' computers.
>
> The project leadership does aim to only authorize people they believe
> will make the efforts you describe above.
>
> But in Guix, the requirement to make those efforts is only enforced
> socially.
>
> There are no mechanisms to ensure that the build is not broken on the
> master branch, etc.
I do not see the distinction between social and tehnical mechanisms here
as... meaningful?
The code-signing authorization tool (e.g. technical) is useful way to
track that social agreements of the project are being respected
(e.g. social) or not, and a mechanism to maintain those agreements. That
it also tracks the authoritative codebase seems a desireable
side-effect... which has both social and technical elements.
I have no illusions that someone could push a broken commit or otherwise
imperfect commit; I have even done so myself at least once or twice! The
question is more what to do when that happens, or repeatedly happens,
which has various technical measures to enforce the social norms.
live well,
vagrant
signature.asc
Description: PGP signature
Re: LibreWolf 130.0-1 notes
Hi André, André Batista writes: Hi Ian, sex 06 set 2024 às 08:29:40 (1725622180), i...@retrospec.tv enviou: 130.0-1 is out, but there’s an issue around DNS-over-HTTP preferences changing[1] in this version. Since this has a negative impact on users requiring them to reset their preferences to correct, I’m skipping this one and will package the next release. I separately have an issue open with them around the Firefox 130 AI Chatbot integration. This uses non-free "AI" services which have been trained on stolen GPL code, and hopefully will get stripped out of LW. It’s an experimental opt-in feature at the moment, but shouldn’t be present at all. Once there’s a fix for #1975, I’ll work on packaging it, disabling the AI nonsense in the Guix package definition, if necessary. Thanks, — Ian [1]: https://codeberg.org/librewolf/issues/issues/1975 In my opinion we should keep these discussions open and transparent for the whole guix community, unless there are some serious concerns in sharing it with the internet at large or if they are truly personal exchanges of no interest to other guix. Since I believe your above message _is_ of interest to guix (guixen could have a different understanding on this heated debate and could have a distinct judgement on the desirability of skipping this release), there is no personal or private information on your message and since we were instructed to keep team discussions on guix-devel[1], I'm taking the liberty to CC the list here. As for the content of your message, I think it's your take here, but IMO the DoH bug is annoying but not a show stopper, unless of course they are about to release a fixed version (which seems to be the case). 130.0-3 is out with this fix, and I’ve begun work to get it packaged, and to excise the GenAI sidebar. There are discussions happening around what to do with the sidebar[1]. My hope is that it’s removed upstream. Thanks, — Ian [1]: https://codeberg.org/librewolf/issues/issues/1919
