Re: Discover GNU Guix eco-system with awesome-guix!
On February 13, 2021, Hartmut Goebel wrote: > Am 09.02.21 um 17:16 schrieb Léo Le Bouter: > > Commonly awesome lists are used to share links to all things related > to > > some topic or some software > > I wonder why not just calling it "Link list" then? [This] would be > much > easier to understand for non-nerds. Awesome lists are "a thing." A number of people maintain "awesome awesome" lists, which list other pages with "awesome lists." The best known of these "awesome awesomes" is https://github.com/sindresorhus/awesome which has over 152,000 stars and 19,900 forks on GitHub and almost a thousand commits. For my fellow recursion enjoyers, there's also an "awesome awesome awesome" list which lists these lists of lists: https://github.com/t3chnoboy/awesome-awesome-awesome So, while saying "link list" is fine and understandable, there are many people who specifically create and seek out "awesome lists" and find it easier to share and discover such lists under the less generic name. Ryan
Re: Guix Day: Notes from the CI session
On Wed, Feb 10, 2021 at 06:11:08PM +0100, Mathieu Othacehe wrote: > Thanks to Ricardo support I was able to setup a Wireguard tunnel between > berlin and the overdrive1. It seems to work pretty well and > https://ci.guix.gnu.org/workers shows that it is building some packages. I noticed that the number of "slots" on overdrive1 was reduced to 1, at least according to ci.guix.gnu.org/workers I would have guessed that a single slot is appropriate for the machine, but I'm curious what you saw that led to the change?
Re: Changes to the branching workflow
Leo, On 2021-02-13 19:21, Leo Famulari wrote: Due to overwhelming demand both on and off list, the bikeshed has been repainted. ...and the second-floor window (it's... a big shed?) no longer reads 'Way Out ->'. One can trivialise anything. Genuine thanks for pushing for improvement, T G-R Sent from a Web browser. Excuse or enjoy my brevity.
Re: Changes to the branching workflow
On Sat, Feb 13, 2021 at 12:24:50PM +0100, Hartmut Goebel wrote: > Am 12.02.21 um 21:49 schrieb Andreas Enge: > > From what I understood of the discussion, I would also go with Tobias's and > > Efraim's suggestion: There is a core-updates branch that is constantly open > > and where people can push; this does not seem to leave a possibility of > > mistake, almost by definition. Then we can branch off core-updates-frozen, > > which is frozen :), except for cherry-picked bug fixing commits and merges > > from master. Once it is finished, it is merged into master and deleted. > > This is what I understood, too. > > > Technically speaking, this is the same as your suggestion, Leo, but it > > avoids the constant dance between core-updates, that disappears and > > reappears under the name core-updates-next, that disappears and reappears > > under the name core-updates, and so on. > It's even worse: When removing staging and core-updates at Savannah, this > does not effect local copies. Thus one might push these branches to > Savannah, which might lead to a lot of confusion and trouble. Alright. Due to overwhelming demand both on and off list, the bikeshed has been repainted.
Re: FOSDEM + Guix Day: hurrah!
On Fri, Feb 12, 2021 at 04:07:24AM +0100, raingloom wrote: > Wait what??? > I was under the impression that talks would be recorded. So they... > weren't??? At all??? Am I waiting for an upload in vain? The FOSDEM talks were recorded. The Guix day we made more informal. I am sorry, we did not record as with the normal in-person days. Pj.
Re: Discover GNU Guix eco-system with awesome-guix!
Am 09.02.21 um 17:16 schrieb Léo Le Bouter: Commonly awesome lists are used to share links to all things related to some topic or some software I wonder why not just calling it "Link list" then? Thsi would be much easier to understand for non-nerds. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: Changes to the branching workflow
Am 12.02.21 um 21:49 schrieb Andreas Enge: From what I understood of the discussion, I would also go with Tobias's and Efraim's suggestion: There is a core-updates branch that is constantly open and where people can push; this does not seem to leave a possibility of mistake, almost by definition. Then we can branch off core-updates-frozen, which is frozen :), except for cherry-picked bug fixing commits and merges from master. Once it is finished, it is merged into master and deleted. This is what I understood, too. Technically speaking, this is the same as your suggestion, Leo, but it avoids the constant dance between core-updates, that disappears and reappears under the name core-updates-next, that disappears and reappears under the name core-updates, and so on. It's even worse: When removing staging and core-updates at Savannah, this does not effect local copies. Thus one might push these branches to Savannah, which might lead to a lot of confusion and trouble. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: Changes to the branching workflow
Am 11.02.21 um 23:42 schrieb Leo Famulari: The default branch names remain "core-updates" and "staging". […] During those periods, new patches can be pushed to "core-updates-next" and "staging-next". What should be the use of these *-next branches. I can't see any except confusing committers. Why can't on push to staging and core-update during the active part of the cycle? -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: Guix Day: Notes frome the Bootstrap session
Ludovic Courtès writes: Hello, > > Jan Nieuwenhuizen skribis: > >> Attached the notes from the "Bootstrap what's next" session yesterday. > > Thanks for sharing! > >> - Making the guix build system code less dependent on Guile and more >> dependent on MES > > Not necessarily more dependent on Mes :-), but rather portable between > the two. Ah, sure -- my bad for simply forwarding the notes without really reading them, only adding the status update :-/ > On this topic, one action item we identified was to try and see what it > would take to run (guix build gnu-build-system) and the modules it > depends on on Mes. If we can run that on Mes during early bootstrap > (before Guile is built), then that’s a step towards removing the big > ‘%bootstrap-guile’ binary seed. > > These modules require some Guilish module support as well as a bunch of > (ice-9 *) and (srfi *) modules. Perhaps with some tricks such as > autoloads, we can reduce the number of modules actually needed. > > Another option is to write a simplified but compatible subset of (guix > build gnu-build-system) specifically for use during early bootstrap. > > At any rate, the first step is to try to feed that code to Mes and see > what happens. :-) > > If you’ve always wanted to join the bootstrapping movement, now’s your > opportunity! Yes, very nice! Note that we already have some experience with this: the Nyacc project is a Guile library that runs on Mes; only minor modifications were necesary. Greetings, Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Update on wip-arm-bootstrap
Hi,
Last month, we found that
--8<---cut here---start->8---
// prereq.c
#if defined __GNUC__ && defined __GNUC_MINOR__
# define __GNUC_PREREQ(maj, min) \
((__GNUC__ << 16) + __GNUC_MINOR__ >= ((maj) << 16) + (min))
#else
# define __GNUC_PREREQ(maj, min) 0
#endif
#if __GNUC_PREREQ (3,1) && !defined __GNUG__
#error gcc too new
#endif
--8<---cut here---end--->8---
compiled wrong with gcc-core-mesboot0:
--8<---cut here---start->8---
16:34:37 janneke@novena:~/src/guix [env]
$ /gnu/store/h0v5by5fgvcqi5gkhq0yi7ma6nhyp2ql-gcc-core-mesboot0-2.95.3/bin/gcc
-S prereq.c
prereq.c:8: warning: integer constant out of range
prereq.c:8: warning: integer constant out of range
prereq.c:8: warning: integer constant out of range
prereq.c:9: #error gcc too new
[1]16:35:27 janneke@novena:~/src/guix [env]
--8<---cut here---end--->8---
Well, Danny identified the problem in gcc-core-mesboot0:
--8<---cut here---start->8---
//noadd.c
#if (1 >= 10)
#endif
--8<---cut here---end--->8---
=>
--8<---cut here---start->8---
$ /gnu/store/h0v5by5fgvcqi5gkhq0yi7ma6nhyp2ql-gcc-core-mesboot0-2.95.3/bin/gcc
-E noadd.c
noadd.c:1: warning: integer constant out of range
# 1 "noadd.c"
--8<---cut here---end--->8---
which lead to
--8<---cut here---start->8---
"#if (5)" works
"#if (10)" is broken [13:10]
any idea where that code "lives"
?
gcc/cppexp.c [13:13]
Maybe "case CPP_NUMBER"
-> parse_number
--8<---cut here---end--->8---
That turned out to be caused by a problems in Mes lib c
--8<---cut here---start->8---
janneke: I fixed the __*div* functions in mes a little--commit
https://git.savannah.gnu.org/cgit/mes.git/commit/?id=33cf5ea5e820e21a8f46de7df08a8b49bb8f62ee
--8<---cut here---end--->8---
functions that used to be stubs on x86, need a working implementation on
ARM. Okay, that makes sense. Danny pushes an update for Mes to
wip-arm-bootstrap.
[13:05:53] And then ../sysdeps/unix/sysv/linux/arm/sigaction.c:139:
`__NR_sigaction' undeclared (first use in this function)
[13:07:32] dannym: that's great!
[13:08:31] dannym: seems familiar
[13:09:04] dannym: when trying to get glibc-mesboot0 built, i was
collecting a number of patches
[13:10:10] i didn't share or push these yet (or maybe reverted), as
they became more uninformed and hacky as i went along
Okay, Janneke sorts-out glibc patches for ARM and pushes an update to
wip-arm-bootstrap. And now, we can build glibc-mesboot0!
--8<---cut here---start->8---
[21:39:23] dannym: amazing:
/gnu/store/jgkf60r29blzhrg0w3dar3rz06xwkx5q-glibc-mesboot0-2.2.5
[21:39:37] \o/
[21:40:34] yeah \o/
--8<---cut here---end--->8---
As we were stuck on building the first glibc for quite some time now,
this was something to celebrate!
Sadly, the gcc-core-mesboot0 + glibc-mesboot0 combo produces executables
that "Illegal instruction" upon syscalls.
--8<---cut here---start->8---
Program received signal SIGILL, Illegal instruction.
0x000276bc in __writev (fd=2, vector=0xbeffd010, count=10) at
../sysdeps/unix/sysv/linux/writev.c:51
51bytes_written = INLINE_SYSCALL (writev, 3, fd, CHECK_N (vector,
count), count);
(gdb) disas /r
Dump of assembler code for function __writev:
0x00027698 <+0>: 0d c0 a0 e1 mov r12, sp
0x0002769c <+4>: f0 dd 2d e9 push{r4, r5, r6, r7, r8, r10, r11,
r12, lr, pc}
0x000276a0 <+8>: 04 b0 4c e2 sub r11, r12, #4
0x000276a4 <+12>:02 50 a0 e1 mov r5, r2
0x000276a8 <+16>:01 70 a0 e1 mov r7, r1
0x000276ac <+20>:00 60 a0 e1 mov r6, r0
0x000276b0 <+24>:6c a0 9f e5 ldr r10, [pc, #108] ; 0x27724
<__writev+140>
0x000276b4 <+28>:00 80 9a e5 ldr r8, [r10]
0x000276b8 <+32>:14 00 00 ef svc 0x0014
=> 0x000276bc <+36>:00 40 a0 e1 mov r4, r0
--8<---cut here---end--->8---
Let's try to bisect where the problem is; we now have tree first
candidates: gcc-core-mesboot0, glibc-mesboot0 and binutils-mesboot0.
Luckily, Debian "woody" carries an almost compatible set. Doing
someting like
--8<---cut here---start->8---
guix environment --ad-hoc binutils patchelf wget
wget http://archive.debian.org/debian/pool/main/g/glibc/libc6_2.2.5-11.8_arm.deb
ar x libc6_2.2.5-11.8_arm.deb
tar xf data.tar.gz
wget
http://archive.debian.org/debian/pool/main/g/glibc/libc6-dev_2.2.5-11.8_arm.deb
ar x libc6-dev_2.2.5-11.8_arm.deb
tar
