bug#68313: Build hdf5-parallel-openmpi.powerpc64le-linux on master is broken.
Hello, cuir...@gnu.org (Cuirass) writes: > The build hdf5-parallel-openmpi.powerpc64le-linux for specification > master > is broken. You can find the detailed information about this build href="https://ci.guix.gnu.org/build/3175009/details;>here. > > https://ci.guix.gnu.org/build/3175009/details Sample output: --8<---cut here---start->8--- Atomicity Test Failed Process 4: read_buf[2038] is 5, should be 0 Atomicity Test Failed Process 4: read_buf[2039] is 5, should be 0 Atomicity Test Failed Process 4: read_buf[2040] is 5, should be 0 Atomicity Test Failed Process 4: read_buf[2041] is 5, should be 0 Atomicity Test Failed Process 4: read_buf[2042] is 5, should be 0 Atomicity Test Failed Process 4: read_buf[2043] is 5, should be 0 Atomicity Test Failed Process 4: read_buf[2044] is 5, should be 0 Atomicity Test Failed Process 4: read_buf[2045] is 5, should be 0 Atomicity Test Failed Process 4: read_buf[2046] is 5, should be 0 Atomicity Test Failed Process 4: read_buf[2047] is 5, should be 0 Testing -- Store Dense Attributes (denseattr) Testing -- Store Dense Attributes (denseattr) Testing -- Store Dense Attributes (denseattr) Testing -- Store Dense Attributes (denseattr) Testing -- Store Dense Attributes (denseattr) Testing -- Store Dense Attributes (denseattr) Testing -- Collective Metadata read with some ranks having no selection (noselcollmdread) Testing -- Collective Metadata read with some ranks having no selection (noselcollmdread) Testing -- Collective Metadata read with some ranks having no selection (noselcollmdread) Testing -- Collective Metadata read with some ranks having no selection (noselcollmdread) Testing -- Collective Metadata read with some ranks having no selection (noselcollmdread) Testing -- Collective Metadata read with some ranks having no selection (noselcollmdread) Testing -- Collective MD read with multi chunk I/O (H5D__chunk_addrmap) (MC_coll_MD_read) Testing -- Collective MD read with multi chunk I/O (H5D__chunk_addrmap) (MC_coll_MD_read) Testing -- Collective MD read with multi chunk I/O (H5D__chunk_addrmap) (MC_coll_MD_read) Testing -- Collective MD read with multi chunk I/O (H5D__chunk_addrmap) (MC_coll_MD_read) Testing -- Collective MD read with multi chunk I/O (H5D__chunk_addrmap) (MC_coll_MD_read) Testing -- Collective MD read with multi chunk I/O (H5D__chunk_addrmap) (MC_coll_MD_read) Testing -- Collective MD read with link chunk I/O (H5D__sort_chunk) (LC_coll_MD_read) Testing -- Collective MD read with link chunk I/O (H5D__sort_chunk) (LC_coll_MD_read) Testing -- Collective MD read with link chunk I/O (H5D__sort_chunk) (LC_coll_MD_read) Testing -- Collective MD read with link chunk I/O (H5D__sort_chunk) (LC_coll_MD_read) Testing -- Collective MD read with link chunk I/O (H5D__sort_chunk) (LC_coll_MD_read) Testing -- Collective MD read with link chunk I/O (H5D__sort_chunk) (LC_coll_MD_read) All tests were successful. All tests were successful. All tests were successful. All tests were successful. All tests were successful. All tests were successful. === ***PHDF5 tests detected 1040 errors*** === --8<---cut here---end--->8--- -- Thanks, Maxim
bug#68243: alacritty segmentation fault
Am Donnerstag, dem 04.01.2024 um 15:32 + schrieb Steven Roose: > I've been using alacritty as my default terminal for about a year > without much issues. I'm currently on v0.12.3 of alacritty and use it > with i3 and Xorg. A month or two ago I noticed that upgrading GuixSD > broke alacritty. Since it's my main terminal and I didn't have any > other terminals installed, I was forced to rollback my system through > GRUB because I couldn't literally not even open a terminal to > investigate or roll-back by CLI. I was trying another system upgrade > now and noticed the issue is still not fixed. When running alacritty > from an already-open alacritty only shows me "segmentation fault". > The working and broken version is both 0.12.3, so I think it might > not be an alacritty issue but more a linking/build issue. I'm > basically stuck on a months-old Guix until this is fixed. > > If there is any way I can be of use by providing debug/log files of > some kind, please let me know. I suppose this might be related to the mesa update we had some while ago. I myself noticed that GNOME 4 apps stopped working due to some very, very weird behaviour of the driver that I still don't comprehend. Anyway, switching to the cairo renderer per environment variable worked for me. Perhaps there's something similar you can do for alacritty (or otherwise switch back to the older mesa with an inferior/use any other VTE for the time being). Cheers
bug#67651: [gnome-team] What should we do with the "gnome" package?
Am Dienstag, dem 05.12.2023 um 21:55 +0100 schrieb Vivien Kraus: > Dear guix, > > On the one hand, we have this list of packages: > https://ftp2.nluug.nl/windowing/gnome/teams/releng/44.6/versions For the record, we have a new 44 release: https://ftp2.nluug.nl/windowing/gnome/teams/releng/44.7/versions I've summarised our TODOs below: Each commented line (preceded by #) denotes a package that doesn't exist on the gnome-team branch yet. core:atkmm:2.28.3: #core:calls:44.2: core:font-abattis-cantarell:0.303.1: core:epiphany:44.7: #core:gnome-logs:43.0: #core:gnome-software:44.5: #core:gnome-tour:44.0: I think we should settle on what to do with the gnome package soon to not stall the branch even further. We can already start working towards GNOME 46 after the merge :) There is some gnome-adjacent software (particularly extensions, I don't want all of them to break like they did the last time and the time before) to have a look at as well before the merge, but it looks like a nice road ahead. We can do this!
bug#68243: alacritty segmentation fault
I meant more of what's the guix version from the generation which contains the non-working alacritty. On Fri, Jan 05, 2024 at 02:51:34PM +, ste...@roose.io wrote: > How can I check generations for packages? `guix package -l` doesn't seem to > show any useful information. > > I can't seem to find out what the syntax should be for the PATTERN arguments > in guix package, like `guix package --list-generations=PATTERN`. > > I try `guix package -l alacritty`, `guix package > --list-generations=alacritty` but always get `invalid syntax: alacritty`.. > > On 1/5/24 12:52 PM, Efraim Flashner wrote: > > On Thu, Jan 04, 2024 at 03:32:55PM +, Steven Roose wrote: > > > I've been using alacritty as my default terminal for about a year without > > > much issues. I'm currently on v0.12.3 of alacritty and use it with i3 and > > > Xorg. A month or two ago I noticed that upgrading GuixSD broke alacritty. > > > Since it's my main terminal and I didn't have any other terminals > > > installed, > > > I was forced to rollback my system through GRUB because I couldn't > > > literally > > > not even open a terminal to investigate or roll-back by CLI. I was trying > > > another system upgrade now and noticed the issue is still not fixed. When > > > running alacritty from an already-open alacritty only shows me > > > "segmentation > > > fault". The working and broken version is both 0.12.3, so I think it might > > > not be an alacritty issue but more a linking/build issue. I'm basically > > > stuck on a months-old Guix until this is fixed. > > > > > > If there is any way I can be of use by providing debug/log files of some > > > kind, please let me know. > > > > Looking at 'alacritty --help' it looks like you can try adding -v (up to > > 3) to get a more verbose output so hopefully we get more of an error > > message. > > > > Which generation are you on that is working for you? Which one do you > > know is segfaulting? I'd like to try to narrow it down. > > > > -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
