Missing package: duckdb

[Fhavlonir]

Package name

duckdb

Package version

3.9: > 0.1.1, 3.11: all

PyPI URL

https://pypi.org/project/duckdb/

piwheels URL

https://www.piwheels.org/project/duckdb/

Python version

• Python 3.9
• Python 3.11
• Python 3.13

I am aware this is the issue tracker for a Python package index specifically for Raspberry Pi

• Yes

I have checked for duplicate issues

• Yes

I am the maintainer

• Yes

More information

The latest build is > 5 years old, and only for python 3.9 (unsurprising, since 3.11 was not released at that point.)

[bennuttall]

It looks like we skipped this package due to continuous memory issues. I'll try it again and see.

[Fhavlonir]

Don't stress out about it though, for my purposes, pysqlite3 works just as well. Just thought the shiny rust-based package seemed cool to try out. Appreciate the work you do, btw!

[MichaIng]

It is still blocked from being scheduled. Shall we give it another try?

[bennuttall]

I've un-skipped it, let's try again.

[bennuttall]

Well, they're mostly still failing. At a glance I can't see what the error is.

[MichaIng]

In two cases:

fatal error: error writing to /tmp/ccwp8n8A.s: No space left on device

[bennuttall]

I asked Claude to review the latest build log:

● Bash(ssh -o ConnectTimeout=10 ben@192.168.86.219 "grep -n 'Killed\|oom\|OOM\|fatal error\|cannot allocate\|memory exhausted\|signal 9\|Segmentation\|killed' /tmp/bui…)
  ⎿  16794:2026-03-20T14:46:53,014   /usr/include/c++/12/bits/vector.tcc: In member function ‘void std::vector<_Tp, _Alloc>::_M_realloc_insert(iterator, _Args&& ...) [with _Args = {duckdb::ParquetBloomFilterEntry}; _Tp = duckdb::ParquetBloomFilterEn     
     try; _Alloc = std::allocator<duckdb::ParquetBloomFilterEntry>]’:                                                                                                                                                                                         
     16795:2026-03-20T14:46:53,015   /usr/include/c++/12/bits/vector.tcc:439:7: note: parameter passing for argument of type ‘std::vector<duckdb::ParquetBloomFilterEntry, std::allocator<duckdb::ParquetBloomFilterEntry> >::iterator’ changed in GCC 7.
     … +12 lines (ctrl+o to expand)                                                                                                                                                                                                                           
                                                                                                                                                                                                                                                              
● There's the culprit — line 35138:                    
                                                                                                                                                                                                                                                              
  virtual memory exhausted: Cannot allocate memory                                                                                                                                                                                                            
   
  The compiler (GCC) ran out of virtual memory while compiling one of DuckDB's source files. This is an OOM failure — the Pi doesn't have enough RAM to compile DuckDB's heavily templated C++ code. The ninja: build stopped: subcommand failed at the end is
   a consequence of that.                                   
                                                                                                                                                                                                                                                              
  DuckDB is a notoriously large compile-time footprint. The piwheels Pi likely doesn't have enough RAM+swap to compile it. There's no straightforward fix on the build machine side short of adding more swap or using a machine with more memory. The build  
  itself isn't broken — it's just too large for the available memory.

[MichaIng]

Unmounting the /tmp tmpfs as builder preparation, or removing it from the base image, should really solve a lot of failing builds, albeit potentially slowing down those which succeed without swapping:

systemctl mask --now tmp.mount

[bennuttall]

It's only enabled by default on Trixie, and I recently disabled it.

[MichaIng]

and I recently disabled it.

Yes possible that this was a change in systemd between Bookworm and Trixie. How did you disable it? Only a mask can achieve that, since systemd forcefully starts this mount unit otherwise. Manual unmount on boot might also work, but systemd is doing a lot of magic (not meant in only positive way), so I wouldn't wonder if it gets remounted automatically in circumstances, unless the mask is set.

Otherwise, as mentioned elsewhere: CMAKE_BUILD_PARALLEL_LEVEL=2 or CMAKE_BUILD_PARALLEL_LEVEL=1. This is again C++ with CMake, like in many other cases, and each compiler process can take a lot of memory. Hence limiting it to use only 2 instead of 4 processes should solve it. But of course, same like skipping tmpfs, it can slow down other builds.

[bennuttall]

piwheels/piwheels@93faa24

[MichaIng]

Is a reboot done after this? As the mask without --now does not unmount it immediately.