bug#73575: Mate fails to build on i686-linux

[Dariqq]

Had a look at the test failures:


- python-werkzeug:
tests/test_serving.py:  ConnectionRefusedError: [Errno 111] Connection 
refused


Not sure what is causing this. Some other linux distributions disable 
this test (this package has a lot of dependants though)




- skia
../../src/base/SkContainers.cpp:66: fatal error: "assert(capacity >= 0)"


The function that is causing the error looks like this

#+begin_src cpp
size_t SkContainerAllocator::roundUpCapacity(int64_t capacity) const {
SkASSERT(capacity >= 0);

// If round will not go above fMaxCapacity return rounded capacity.
if (capacity < fMaxCapacity - kCapacityMultiple) {
return SkAlignTo(capacity, kCapacityMultiple);
}

return SkToSizeT(fMaxCapacity);
}
#+end_src


In the same file there is another function which calls roundUpCapacity 
which looks like it can overflow because things get castet to int64_t 
after the multiplication which will fail to catch the overflow


#+begin_src cpp
size_t SkContainerAllocator::growthFactorCapacity(int capacity, double 
growthFactor) const {

SkASSERT(capacity >= 0);
SkASSERT(growthFactor >= 1.0);
// Multiply by the growthFactor. Remember this must be done in 
64-bit ints and not

// size_t because size_t changes.
const int64_t capacityGrowth = static_cast(capacity * 
growthFactor);


// Notice that for small values of capacity, rounding up will 
provide most of the growth.

return this->roundUpCapacity(capacityGrowth);
}
#+end_src




- node:
In tests/parallel/test-fs-utimes-y2K38.js
this is failing:

#+begin_src js
const path = `${tmpdir.path}/test-utimes-precision`;
fs.writeFileSync(path, '');

const Y2K38_mtime = 2 ** 31;
fs.utimesSync(path, Y2K38_mtime, Y2K38_mtime);
#+end_src

with
#+begin_example
not ok 1133 parallel/test-fs-utimes-y2K38
  ---
  duration_ms: 157.49700
  severity: fail
  exitcode: 1
  stack: |-
node:internal/fs/utils:351
throw err;
^

Error: EINVAL: invalid argument, utime 
'/tmp/guix-build-node-18.19.0.drv-0/node-v18.19.0/test/.tmp.1155/test-utimes-precision'

at Object.utimesSync (node:fs:2134:3)
at Object. 
(/tmp/guix-build-node-18.19.0.drv-0/node-v18.19.0/test/parallel/test-fs-utimes-y2K38.js:46:4)

at Module._compile (node:internal/modules/cjs/loader:1356:14)
at Module._extensions..js 
(node:internal/modules/cjs/loader:1414:10)

at Module.load (node:internal/modules/cjs/loader:1197:32)
at Module._load (node:internal/modules/cjs/loader:1013:12)
at Function.executeUserEntryPoint [as runMain] 
(node:internal/modules/run_main:128:12)

at node:internal/main/run_main_module:28:49 {
  errno: -22,
  syscall: 'utime',
  code: 'EINVAL',
  path: 
'/tmp/guix-build-node-18.19.0.drv-0/node-v18.19.0/test/.tmp.1155/test-utimes-precision'

}

Node.js v18.19.0
#+end_example


This seems to be another overflow/integer too big error as 2**31 -1 works.

bug#72990: Core packages updated broke Guix

[Ludovic Courtès]

Hi,

Preston Miller Firestone  skribis:

> I can also confirm: I was having this same problem on the same update
> and unsetting LD_LIBRARY_PATH also fixed it for me. I was then able to
> run `guix pull` and everything was good again.
>
> Thanks Ludo for the fix! I wonder how LD_LIBRARY_PATH got set in the
> first place? I'm running Guix system.

No idea.  Perhaps you could:

  grep LD_LIBRARY_PATH \
/run/current-system/profile/manifest \
~/.guix-home/profile/manifest

… for the offending system and user profile generations.

Ludo’.

bug#73579: guix repo is down

[Nicolas Graves]

Actually all repos on savannah seem down:
https://git.savannah.gnu.org/cgit/

-- 
Best regards,
Nicolas Graves

bug#73579: https://git.savannah.gnu.org/git/guix.git returns http error 404

[Nicolas Graves]

-- 
Best regards,
Nicolas Graves

bug#73579: guix repo is down

[Nicolas Graves]

FSF is actually managing, closing this bug. See
https://hostux.social/@fsfstatus


On 2024-10-01 16:41, Nicolas Graves wrote:

> Actually all repos on savannah seem down:
> https://git.savannah.gnu.org/cgit/

-- 
Best regards,
Nicolas Graves

bug#73587: llvm@0.15 build failure on i686-linux

[Dariqq]

Sry, had the wrong link


https://ci.guix.gnu.org/build/4980333/details

bug#73587: llvm@0.15 build failure on i686-linux

[Dariqq]

Hi,

After core-updates the llvm@0.15 pacakge is ooming during 
'make-dynamic-linker-cache phase on i686-linux.


Was looking through the llvm.scm and this phase already gets skipped on 
llvm@16, llvm@17 and llvm@18



From https://ci.guix.gnu.org/build/5769504/details

starting phase `make-dynamic-linker-cache'
GC Warning: Repeated allocation of very large block (appr. size 32772 KiB):
May lead to memory leak and poor performance
GC Warning: Repeated allocation of very large block (appr. size 65540 KiB):
May lead to memory leak and poor performance
GC Warning: Repeated allocation of very large block (appr. size 131076 KiB):
May lead to memory leak and poor performance
GC Warning: Repeated allocation of very large block (appr. size 262148 KiB):
May lead to memory leak and poor performance
GC Warning: Repeated allocation of very large block (appr. size 32772 KiB):
May lead to memory leak and poor performance
GC Warning: Repeated allocation of very large block (appr. size 65540 KiB):
May lead to memory leak and poor performance
GC Warning: Repeated allocation of very large block (appr. size 262148 KiB):
May lead to memory leak and poor performance
GC Warning: Failed to expand heap by 278532 KiB
GC Warning: Failed to expand heap by 262148 KiB
GC Warning: Out of Memory! Heap size: 3449 MiB. Returning NULL!
Warning: Unwind-only out of memory exception; skipping pre-unwind handler.
Warning: Unwind-only out of memory exception; skipping pre-unwind handler.
Warning: Unwind-only out of memory exception; skipping pre-unwind handler.
build process 18 exited with status 256

bug#73462: emacs-guix: shell commands broken

[Suhail Singh]

Christopher Howard  writes:

> Recipe:
> 1. M-x guix
> 2. c (for "guix shell commands)

In case relevant, on a foreign distribution with on Emacs 29.4 and
emacs-guix installed via MELPA (using the same commit emacs-guix uses
for upstream) I am unable to reproduce the issue.

However, the below allows me to observe the issue:

#+begin_src sh
  guix shell emacs emacs-guix guix -- emacs -q
#+end_src

-- 
Suhail

bug#73564: broken link on the bottom of the page https://packages.guix.gnu.org/

[Sergey Trofimov]

Jim Dupont  writes:

> Hello gnus, 
> https://guix.gnu.org/manual/en/manual/devel/en/html_node/Invoking-guix-shell.html
>  is a broken link on the
> bottom of the page 
> https://packages.guix.gnu.org/packages/tree-sitter-typescript/

Thanks for reporting, I've opened a PR to fix it: 
https://codeberg.org/luis-felipe/guix-packages-website/pulls/16

bug#73304: Python in relocatable guix pack leads to wrong sys.path

[Konrad Hinsen]

Ludovic Courtès  writes:

> Rutherther  skribis:
>
>> When I add both python and a python package (seems like any) to a
>> relocatable guix pack, the resulting python in the merged profile seems
>> to be broken. Specifically its `sys.path` contains missing paths.

> Commit d5e0180805f52ef38a03ff9d6c11dd6174e3526b fixed a similar issue I
> think, discussed at .
>
> Not sure whether it’s a new problem here.  Konrad, Maxim, Josselin,
> WDYT? :-)

This problem clearly looks like it's caused by our sitecustomize.py.
One indicator is "When I add both python and a python package": if there
is no additional package, only python by itself, our sitecustomize
doesn't do anything.

However, I don't see how the recent patch (see
https://issues.guix.gnu.org/68241) could be responsible for this new
problem. It should have happened before as well.

Here is what sitecustomize.py does:

 1. Collect the "site-packages" subdirectories of everything on
$GUIX_PYTHONPATH.
 2. Normalize them via sys.normpath()
 3. Add them to sys.path
 4. Re-arrange the elements in sys.path such that the add-on
packages come before Python's standard library.

The recent patch fixes a bug in the last step, which wasn't executed at
all (and generated an error message). So the difference between the
current and the previous behavior is only the order of entries in
sys.path.

The current problem is that even the standard library's paths are wrong.
I suspect that this is due to sys.normpath not implementing the correct
POSIX semantics for dot-dot.

Cheers,
  Konrad.