Re: Security patching and the branching workflow: a new security-updates branch

[Ludovic Courtès]

Léo,

Léo Le Bouter  skribis:

> I feel harassed by your comments because you obsessed on this zstd
> issue and try to make it the cause of some other problems you saw
> without any evidence.

It’s unacceptable to call someone “obsessed” just because you disagree
and calling Simon’s comments “harassment” is equally inappropriate.

We’re all passionate about the project, and each one of us looks at it
from a different angle.

You’re new to the project.  I think we’re all glad you joined; that has
already boosted security work and the POWER9 port.  But we also have
expectations: that you follow written rules (the code of conduct, the
“Commit Access” section of the manual), and the unwritten rule that, as
a newcomer, you would humbly listen to suggestions made by more
experienced contributors.

The unresolved issues Simon points out are not just technical problems;
they’re a hindrance to our cooperation and to our well-being as a group.
It’s completely okay to make mistakes, but it’s not okay to break the
community rules and to dismiss the opinion of others as unimportant.

Please adjust accordingly.

Thanks,
Ludo’.

Petition to remove hidden flag from cmake-minimal package

[Tom Hiller]

Could cmake-minimal be made publicly available as a version of cmake 
without the documentation dependencies?  I believe the only thing 
preventing this is the hidden flag inherited from cmake-bootstrap.

Re: Document our WIP

[Leo Famulari]

On Wed, Mar 31, 2021 at 07:52:30PM +0200, Léo Le Bouter wrote:
> On Tue, 2021-03-30 at 12:37 +0200, Ludovic Courtès wrote:
> > To me, a good way to make sure work remains “in progress” is to post
> > regular updates to this list, and then to write blog posts for the
> > web
> > site whenever an important milestone is reached.
> > 
> > I think a web page is likely to quickly become outdated… unless said
> > work transitions from “in progress” to “stalled”.  :-)
> 
> I feel like using the mailing list fails at solving one concern that is
> discoverability of WIP problems for people to show up and help tackle
> them, even if they were abandonned by the people who started them. Not
> everyone can handle the load of incoming mail in the ML. On the GNOME
> 40 upgrade for example I linked the mailing list thread on the wiki
> page also. The wiki page is also more likely to get outdated if it
> doesnt have great visibility on the GNU Guix official website, that,
> for sure.

Yeah, I agree that it's hard to learn about "what's cooking" when you
first arrive at the mailing lists.

It's true that wikis tend to get out of date, but I think that it won't
be too bad for this use case. At least, it won't be worse than the
mailing lists, for newcomers who want to know about longer-term efforts
like the GNOME upgrade.


signature.asc
Description: PGP signature

Re: Document our WIP

[Léo Le Bouter]

On Tue, 2021-03-30 at 12:37 +0200, Ludovic Courtès wrote:
> To me, a good way to make sure work remains “in progress” is to post
> regular updates to this list, and then to write blog posts for the
> web
> site whenever an important milestone is reached.
> 
> I think a web page is likely to quickly become outdated… unless said
> work transitions from “in progress” to “stalled”.  :-)

I feel like using the mailing list fails at solving one concern that is
discoverability of WIP problems for people to show up and help tackle
them, even if they were abandonned by the people who started them. Not
everyone can handle the load of incoming mail in the ML. On the GNOME
40 upgrade for example I linked the mailing list thread on the wiki
page also. The wiki page is also more likely to get outdated if it
doesnt have great visibility on the GNU Guix official website, that,
for sure.

Léo


signature.asc
Description: This is a digitally signed message part

Re: Question about compile packages

[Vincent Legoll]

Hello Mark,

On Wed, Mar 31, 2021 at 2:30 AM Mark H Weaver  wrote:
> If more people are interested in using Guix in this way, the experience
> could probably be made much nicer.

I think this would interest quite a few people, a guixtoo cookbook chapter ?

I've wondered about such subject myself since my early tries with guix,
and just today, I got to know it is doable, and there are people just doing
it, and some hints about what & how to try it myself...

So thank you, and Raingloom.

-- 
Vincent Legoll

Re: [aarch64] sbcl build failure

[Pierre Neidhardt]

You can try two things:

- Does version 2.1.2 work?
- Can you try bootstrapping SBCL with ECL instead of CLISP?

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

Re: [aarch64] sbcl build failure

[Leo Famulari]

On Wed, Mar 31, 2021 at 01:26:20AM -0400, Leo Famulari wrote:
> > I'm looking at the following cl-zstd build failure:
> > https://ci.guix.gnu.org/build/133326/details
> > which is caused by sbcl build failure that I
> > reproduced locally.

Unfortunately, the build failed on the Overdrive 1000, basically as
shown in the build log of job 133326:

--
//testing for consistency of first and second GENESIS passes
//header files match between first and second GENESIS -- good

real38m6.607s
user35m38.723s
sys 2m26.799s
//entering make-target-2.sh
//doing warm init - compilation phase
This is SBCL 2.1.3, an implementation of ANSI Common Lisp.
More information about SBCL is available at .

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.
Initial page table:
Gen  Boxed   CodeRaw  LgBox LgCode  LgRaw  Pin   Alloc Waste
Trig  WP GCs Mem-age
 6 398251  0  0  0  0042470112 62752 
200 649   0  0.
   Total bytes allocated=  42470112
   Dynamic-space-size bytes =3221225472
COLD-INIT... (Length(TLFs)= 9815)
Argh! corrupted error depth, halting
fatal error encountered in SBCL pid 579 tid 579:
%PRIMITIVE HALT called; the party is over.

Error opening /dev/tty: No such device or address
Welcome to LDB, a low-level debugger for the Lisp runtime environment.
ldb> 
real0m0.186s
user0m0.145s
sys 0m0.041s
command "sh" "make.sh" "clisp" 
"--prefix=/gnu/store/p4pwjnbh197g5s5h7axklk2f1wwhx9gh-sbcl-2.1.3" 
"--dynamic-space-size=3072" "--with-sb-core-compression" 
"--with-sb-xref-for-internals" failed with status 1
builder for `/gnu/store/zij71vlv5a93qs2bmz29qwy1byz076iy-sbcl-2.1.3.drv' failed 
with exit code 1
-

Re: GNOME 40

[宋文武]

> If anyone is curious of the work or wants to participate, we are
> working there: 
> https://git.guix-patches.cbaines.net/guix-patches/log/?h=wip-gnome-40
>
Hello, looks great!  I'd like to do some work for GNOME4 too, mostly at
weekends though.

> If anyone wants to participate, please reach to cbaines about access.
>
Um, not sure yet, I'll ask later if I need it...


Léo Le Bouter  writes:

> On Sun, 2021-03-28 at 16:48 -0400, Mark H Weaver wrote:
>> How is it more flexible than a "wip-*" branch on Savannah?
>> 
>>  Thanks,
>>Mark
>
> Because as the GNU Guix project we have no control on the forge to
> catter it to our own needs, because there is bureaucracy involved with
> approving new committers so they can work on wip branches (shouldnt be
> necessary).

Does't our savannah repository need committers' gpg signatures for
'wip-*' branch too?

If it is, then I guess there could be some problems.  To push to
savannah, I have to git rebase the cbaines wip-gnome-40 branch to add my
signature to all the commits?  I haven't did this, any help?

If it is not, then I think there should be little difference for me to
use savannah or cbaines's repository.  I can merge cbaines/wip-gnome-40
into savannah/wip-gnome-40 many times, and when it's ready, send patches
to the list for pick, or do some works to get rid of the merge commits
if needed..

Eager to see GNOME4 on Guix!

Re: I have merged wip-ppc64le-for-master to master

[Chris Marusich]

Ludovic Courtès  writes:

> Chris Marusich  skribis:
>
>> FYI, I have merged wip-ppc64le-for-master to master and closed bug
>> 47182.  I have also deleted the wip-ppc64le-for-master branch.
>
> Yay, congrats!  \o/
>
> I now have access to the OSUOSL POWER9 machine.  I’ve set up offloading
> and it seems to work well.
>
> Thanks to all the hackers involved + OSUOSL!

That's fantastic news!  Please let us know if you have any trouble
running the "make release" target.  I think the recipe is good to go,
since SUPPORTED_SYSTEMS now contains powerpc64le-linux.

Is there something else I can help with for the release?  Leo and I are
working on a blog post; we should probably share it soon for review.

By the way, I have just now updated the documentation in commit
e52ec6c64a17a99ae4bb6ff02309067499915b06 and the news.scm file in
0374617920e3d278e68c71826fec1f590921e31b.

I'm really excited about this release!  I'm looking forward to
continuing to work on POWER9 support with everyone going forward.

-- 
Chris


signature.asc
Description: PGP signature