Bug#970021: Seeking a small group to package Apache Arrow (was: Bug#970021: RFP: apache-arrow -- cross-language development platform for in-memory analytics)
On 3/25/24 7:17 PM, Julian Gilbey wrote: So this is a plea for anyone looking for something really helpful to do: it would be great to have a group of developers finally package this! There was some initial work done (see the RFP bug report for details: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970021), but that is fairly old now. As Apache Arrow supports numerous languages, it may well benefit from having a group of developers with different areas of expertise to build it. (Or perhaps it would make more sense to split the upstream source into a collection of different Debian source packages for the different supported languages. I don't know.) Unfortunately I don't have the capacity to devote any time to it myself. Thanks in advance for anyone who can step forward for this! As someone from the Debian-GIS community, I would also be very interested in this! The Apache Arrow C++ library is one of the dependencies to make GDAL/OGR able to read/write (geo)parquet files, a data format with a lot traction in the geo community [0]. Thereby making it possible for QGIS to handle those (on Debian). [0] https://cloudnativegeo.org/blog/2023/09/duckdb-the-indispensable-geospatial-tool-you-didnt-know-you-were-missing/ Regards, Richard Duivenvoorde
Bug#1055504: ITP: laz-perf -- LAZperf is an alternative LAZ (Compressed LAS pointclouds) decoding implementation.
Hi Gürkan, Just found out that LAZperf is not a dependency of PDAL because sources in taken into PDAL itself. But I'm still interested in trying to package LAZperf itself too, IF others think it is useful. If you say: "I prefer uploads to mentors.d.n" do you mean NOT in the science packaging team or do you mean something else? Reason I choose science packaging team is because the former package of PDAL proposed that. I'm very green in this, so please bare with me Regards, Richard Duivenvoorde On 11/7/23 15:33, Gürkan Myczko wrote: I would be great to help, cloudcompare seems to support it. Find me as tarzeau_ on irc I prefer uploads to mentors.d.n Maybe you find something useful at Index of /debian/laz-perf/ <https://sid.ethz.ch/debian/laz-perf/> sid.ethz.ch <https://sid.ethz.ch/debian/laz-perf/> <https://sid.ethz.ch/debian/laz-perf/> <https://sid.ethz.ch/debian/laz-perf/> On Nov 7, 2023, at 14:54, Richard Duivenvoorde wrote: Package: wnpp Severity: wishlist Owner: Richard Duivenvoorde X-Debbugs-Cc: debian-de...@lists.debian.org * Package name : laz-perf Version : 3.4.0 Upstream Contact: Howard Butler * URL : https://github.com/hobuinc/laz-perf * License : APLv2 Programming Lang: C, C++, C#, Python Description : LAZperf is an alternative LAZ (Compressed LAS pointclouds) decoding implementation. It supports compilation to WASM via Emscripten so that LAZ data can be decoded in a browser. LAZperf is a dependecy for the PDAL library (https://github.com/PDAL/PDAL/). PDAL can be used as a library for QGIS (https://qgis.org) to be able to read/analyze point clouds. I'm planning to maintain both LAZperf and PDAL with the science packaging team. If I'm correct I'm also looking for a sponsor. But I'm very new to Debian packaging, so every help is appreciated Regards, Richard Duivenvoorde
Bug#1055504: ITP: laz-perf -- LAZperf is an alternative LAZ (Compressed LAS pointclouds) decoding implementation.
Package: wnpp Severity: wishlist Owner: Richard Duivenvoorde X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: laz-perf Version : 3.4.0 Upstream Contact: Howard Butler * URL : https://github.com/hobuinc/laz-perf * License : APLv2 Programming Lang: C, C++, C#, Python Description : LAZperf is an alternative LAZ (Compressed LAS pointclouds) decoding implementation. It supports compilation to WASM via Emscripten so that LAZ data can be decoded in a browser. LAZperf is a dependecy for the PDAL library (https://github.com/PDAL/PDAL/). PDAL can be used as a library for QGIS (https://qgis.org) to be able to read/analyze point clouds. I'm planning to maintain both LAZperf and PDAL with the science packaging team. If I'm correct I'm also looking for a sponsor. But I'm very new to Debian packaging, so every help is appreciated Regards, Richard Duivenvoorde
Bug#982966: python3-pygame: Using pygame 1.9.6 crashes Wayland (hard) and X
On 3/7/21 11:54 AM, Bernhard Übelacker wrote:
>
> export DEBUGINFOD_URLS="https://debuginfod.debian.net;
> coredumpctl gdb 18825
Let me start, that I'm only half aware what I'm doing :-)
I hope this is usefull, happy to try again. As said: it is not one system, my
other Debian test system was/is behaving the same.
(I tried your linest as root first thinking it would reveal more info, but
failed then)
Then as normal user:
Starts with a lot of lines like:
warning: Can't open file /lib/x86_64-linux-gnu/libexpat.so.1.6.12 (deleted)
during file-backed mapping note processing
warning: Can't open file /lib/x86_64-linux-gnu/libdbus-1.so.3.19.13 (deleted)
during file-backed mapping note processing
warning: Can't open file /usr/lib/x86_64-linux-gnu/libffi.so.7.1.0 (deleted)
during file-backed mapping note processing
then:
warning: Can't open file /usr/lib/gnome-shell/libgnome-shell.so (deleted)
during file-backed mapping note processing
[New LWP 18825]
[New LWP 18839]
[New LWP 18840]
[New LWP 18837]
[New LWP 354152]
[New LWP 18862]
[New LWP 18859]
[New LWP 18858]
[New LWP 18856]
[New LWP 18855]
[New LWP 18861]
[New LWP 25857]
[New LWP 18860]
[New LWP 18857]
[New LWP 28724]
[New LWP 28718]
[New LWP 18846]
[New LWP 18848]
[New LWP 28719]
[New LWP 28720]
[New LWP 28722]
[New LWP 18847]
[New LWP 28717]
[New LWP 28721]
[New LWP 28723]
[New LWP 18845]
warning: .dynamic section for "/usr/lib/x86_64-linux-gnu/libmutter-7.so.0" is
not at the expected address (wrong library or version mismatch?)
Then downloading a lot of 'separate debug info' (paging by everytime hitting
enter)
ending with:
Downloading separate debug info for
/usr/lib/x86_64-linux-gnu/gtk-3.0/modules/libcanberra-gtk-module.so...
Downloading separate debug info for
/usr/lib/x86_64-linux-gnu/libcanberra-0.30/libcanberra-pulse.so...
Downloading separate debug info for
/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-xpm.so...
Core was generated by `/usr/bin/gnome-shell'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 g_type_check_instance
(type_instance=type_instance@entry=0x) at
../../../gobject/gtype.c:4133
Download failed: Invalid argument. Continuing without source file
./debian/build/deb/../../../gobject/gtype.c.
4133../../../gobject/gtype.c: No such file or directory.
[Current thread is 1 (Thread 0x7fe88668fdc0 (LWP 18825))]
(gdb)
then doing bt full:
(gdb) bt full
#0 g_type_check_instance
(type_instance=type_instance@entry=0x) at
../../../gobject/gtype.c:4133
#1 0x7fe88cf50883 in g_signal_handler_disconnect
(instance=0x, handler_id=0) at ../../../gobject/gsignal.c:2718
_g_boolean_var_ =
handler =
__func__ = "g_signal_handler_disconnect"
#2 0x7fe88cf42eef in weak_refs_notify (data=0x55a3a5500fe0) at
../../../gobject/gobject.c:2946
wstack = 0x55a3a5500fe0
i = 0
#3 0x7fe88ce2dfae in g_data_set_internal (datalist=0x55a3a5fcd1b0,
key_id=, new_data=, new_destroy_func=, dataset=0x0) at ../../../glib/gdataset.c:407
d = 0x55a3a24a6ba0
old_d =
old = {key = , data = , destroy =
0x7fe88cf42ec0 }
data =
data_last =
data_end =
#4 0x7fe88cf440a3 in g_object_unref (_object=) at
../../../gobject/gobject.c:3465
weak_locations = 0x0
old_ref =
__func__ = "g_object_unref"
object = 0x55a3a5fcd1a0 [StImageContent]
__func__ = "g_object_unref"
#5 g_object_unref (_object=0x55a3a5fcd1a0) at ../../../gobject/gobject.c:3395
object = 0x55a3a5fcd1a0 [StImageContent]
__func__ = "g_object_unref"
#6 0x7fe88d1c1df8 in shell_app_dispose (object=0x55a3a18908f0 [ShellApp])
at ../src/shell-app.c:1561
_pp = 0x55a3a1890918
_ptr =
app = 0x55a3a18908f0 [ShellApp]
__func__ = "shell_app_dispose"
#7 0x7fe88cf440a3 in g_object_unref (_object=) at
../../../gobject/gobject.c:3465
weak_locations = 0x0
old_ref =
__func__ = "g_object_unref"
object = 0x55a3a18908f0 [ShellApp]
__func__ = "g_object_unref"
#8 g_object_unref (_object=0x55a3a18908f0) at ../../../gobject/gobject.c:3395
object = 0x55a3a18908f0 [ShellApp]
__func__ = "g_object_unref"
#9 0x7fe88c546c7e in ObjectInstance::release_native_object()
(this=this@entry=0x55a3a3d87190) at ../gi/object.cpp:1299
#10 0x7fe88c546d5a in ObjectInstance::disassociate_js_gobject()
(this=0x55a3a3d87190) at ../gi/object.cpp:1496
had_toggle_down =
had_toggle_up =
toggle_queue =
@0x7fe88c5feb00: {lock = { = {_M_mutex =
pthread_mutex_t = {Type = Normal, Status = Not acquired, Robust = No, Shared =
No, Protocol = None}}, }, q = std::deque with 0 elements,
m_shutdown = {_M_base = {static _S_alignment = 1, _M_i = false}, static
is_always_lock_free = true}, m_idle_id = 0, m_toggle_handler = 0x0}
#11 0x7fe88c542588 in
Bug#982966: follow up info
See https://github.com/pygame/pygame/issues/2487 Pygame community/devs do not have resources to dive into older 1.9.6 issues, OR point to Wayland/Gnome. Not sure what would be best for Debian: maybe remove it, with arguments: - Python 3.9 and pygame 1.9.6 seems a strange combo - it is pretty easy to install pygame 2.0.1 via pip - you do not want to have packages in your distro which crash Wayland...
Bug#982966: python3-pygame: Using pygame 1.9.6 crashes Wayland (hard) and X
Package: python3-pygame Version: 1.9.6+dfsg-4+b1 Severity: important Dear Maintainer, * What led up to the situation? See https://github.com/pygame/pygame/issues/2487 for a full description. * What exactly did you do (or not do) that was effective (or ineffective)? Running the Flappy bird tutorial: Youtube: https://www.youtube.com/watch?v=UZg49z76cLw Code: https://github.com/clear-code-projects/FlappyBird_Python Just checkout the repo, and run 'python3 flappy.py' or 'python3 flappy_update.py' from the root dir. It makes my whole window manager crash after a while, looking at memory or cpu, nothing is wrong, but all of a sudden (while doing a little 'playing', even when just 15 minutes in tutorial (so having only 20% of code) : boom! In the pygame issue there is some info from my dmesg Also somebody proposed to NOT use pygame 1.9.6 (from Debian) but 2.0.1 (from pip) in combi with 3.9.1 and then I cannot reproduce the crash anymore. So if others can reproduce this in other pygame situations, OR can find out the underlaying issue (in libgobject-2.0 ?), not sure if it would be an option to upgrade to pygame 2.0.1? -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-3-amd64 (SMP w/8 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-pygame depends on: ii fonts-freefont-ttf 20120503-10 ii libc6 2.31-9 ii libfreetype62.10.4+dfsg-1 ii libjpeg62-turbo 1:2.0.5-2 ii libpng16-16 1.6.37-3 ii libportmidi01:217-6 ii libsdl-image1.2 1.2.12-12 ii libsdl-mixer1.2 1.2.12-16+b1 ii libsdl-ttf2.0-0 2.0.11-6 ii libsdl1.2debian 1.2.15+dfsg2-5 ii libx11-62:1.7.0-2 ii python3 3.9.1-1 ii python3-numpy [python3-numpy-abi9] 1:1.19.5-1 python3-pygame recommends no packages. Versions of packages python3-pygame suggests: pn python-pygame-doc pn timidity -- no debconf information
Bug#974602: Fedora patch info
FYI: Fedora patch info: https://src.fedoraproject.org/rpms/qt5-qtbase/c/6f0b990f87a72e843560c3aa414a0e337f0527b3?branch=master
Bug#974602: libqt5core5a: Upstream issue with QProcess breaks debugging with QtCreator in 5.15.1
Package: libqt5core5a Version: 5.15.1+dfsg-2 Severity: important Tags: upstream patch We (as QGIS developers) hit this today: https://lists.osgeo.org/pipermail/qgis-developer/2020-November/062625.html Since recent Qt update to 5.15.1 in Debian, QtCreator fails to debug Qt-Applications (like QGIS) because of an upstream issue related to gdb, lldb and the use of QProcess in applications: https://bugreports.qt.io/browse/QTBUG-86319 There seems to be an upstream fix: https://codereview.qt-project.org/c/qt/qtbase/+/313535 of which myself I cannot check if it is OK. I do not have enough knowledge about how to handle this: wait for 5.15.2? Or try to get this patch into debian (like Fedora did apparently, see osgeo thread). Hope this is enough information. If you need more information let me know. More experienced Qt/QGIS devs will probably respond on the osgeo/qgis dev list. Regards, Richard Duivenvoorde -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-1-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libqt5core5a depends on: ii libc6 2.31-4 ii libdouble-conversion3 3.1.5-6 ii libgcc-s1 10.2.0-16 ii libglib2.0-0 2.66.2-1 ii libicu67 67.1-4 ii libpcre2-16-0 10.34-7 ii libstdc++6 10.2.0-16 ii libzstd1 1.4.5+dfsg-4 ii shared-mime-info 2.0-1 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages libqt5core5a recommends: ii qttranslations5-l10n 5.15.1-2 Versions of packages libqt5core5a suggests: ii libthai0 0.1.28-3 -- no debconf information
Bug#911462: libgtk-3-0: Filefilter Combobox shows much too much whitespace with long lists or on bottom of screen
On Sat, 20 Oct 2018 09:26:15 -0400 Jeremy Bicha wrote: > By default, Debian GNOME in Buster uses Wayland. Could you try logging > out? As you log in, click the gear button and select the GNOME on Xorg > session. Can you still replicate the issue in that session? > > If not, it might be related to a problem I've seen in the GNOME Tweaks app: > https://gitlab.gnome.org/GNOME/gnome-tweaks/issues/177 Hi Jeremy, Thanks for looking into this. Switching to Gnome on Xorg shows the same behaviour. It really looks like the #177 gnome issue. I will add my screendump there. Regards, Richard Duivenvoorde
Bug#911462: libgtk-3-0: Filefilter Combobox shows much too much whitespace with long lists or on bottom of screen
Package: libgtk-3-0 Version: 3.24.1-2 Severity: normal Dear Maintainer, In QGIS we have in some filechooser applications long lists of filetypes. One of them (for a screenshot see https://issues.qgis.org/issues/20169)· shows a very long piece of whitespace above the filetypes in the combobox. First I thought it was a QGIS problem. But after some fiddling I was able to reproduce this with almost all comboboxes in Gnome applications, by moving the combobox (with for example "All Files" etc) all to the bottom of you screens. Then open the list and see that it looks like the canvas to be used to draw the items on is first created ON screen, then the items are painted on it, and then the last selection is selected. Sometimes showing little arrows/pointers to scroll up or down. But sometimes the whitespace above the first item sticks. And sometimes the canvas does not move down. In our (QGIS) case this give alwasy rise to a huge unused part of whitespace above the first item. I think this is an upstream issue, as I can reproduce it with all Gnome apps, but maybe not. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libgtk-3-0 depends on: ii adwaita-icon-theme 3.30.0-1 ii hicolor-icon-theme 0.17-2 ii libatk-bridge2.0-0 2.30.0-2 ii libatk1.0-0 2.30.0-1 ii libc62.27-6 ii libcairo-gobject21.15.12-1 ii libcairo21.15.12-1 ii libcolord2 1.3.3-2 ii libcups2 2.2.8-5 ii libepoxy01.5.3-0.1 ii libfontconfig1 2.13.1-1 ii libfreetype6 2.8.1-2 ii libgdk-pixbuf2.0-0 2.38.0+dfsg-6 ii libglib2.0-0 2.58.1-2 ii libgtk-3-common 3.24.1-2 ii libharfbuzz0b1.9.0-1 ii libjson-glib-1.0-0 1.4.4-1 ii libpango-1.0-0 1.42.4-3 ii libpangocairo-1.0-0 1.42.4-3 ii libpangoft2-1.0-01.42.4-3 ii librest-0.7-00.8.0-2 ii libsoup2.4-1 2.64.1-3 ii libwayland-client0 1.16.0-1 ii libwayland-cursor0 1.16.0-1 ii libwayland-egl1 1.16.0-1 ii libx11-6 2:1.6.7-1 ii libxcomposite1 1:0.4.4-2 ii libxcursor1 1:1.1.15-1 ii libxdamage1 1:1.1.4-3 ii libxext6 2:1.3.3-1+b2 ii libxfixes3 1:5.0.3-1 ii libxi6 2:1.7.9-1 ii libxinerama1 2:1.1.4-1 ii libxkbcommon00.8.2-1 ii libxml2 2.9.4+dfsg1-7+b1 ii libxrandr2 2:1.5.1-1 ii shared-mime-info 1.10-1 Versions of packages libgtk-3-0 recommends: ii libgtk-3-bin 3.24.1-2 Versions of packages libgtk-3-0 suggests: ii gvfs 1.38.0-2 ii librsvg2-common 2.40.20-3 Versions of packages libgtk-3-0 is related to: pn appmenu-gtk3-module ii fcitx-frontend-gtk31:4.2.9.6-5 pn gcin-gtk3-immodule pn gtk-vector-screenshot pn gtk3-engines-xfce ii gtk3-im-libthai0.2.1-8 pn hime-gtk3-immodule ii ibus-gtk3 1.5.19-1 pn imhangul-gtk3 ii libcanberra-gtk3-module0.30-6 pn libcaribou-gtk3-module pn libgtk3-nocsd0 pn maliit-inputcontext-gtk3 pn packagekit-gtk3-module ii scim-gtk-immodule [scim-gtk-immodule] 1.4.18-2.1 pn topmenu-gtk3 ii uim-gtk3 1:1.8.8-3 ii uim-gtk3-immodule 1:1.8.8-3 -- no debconf information
Bug#828031: qgis: QtWebKit not found by extensions
On Fri, 24 Jun 2016 08:01:17 +0200 =?utf-8?b?QmFsw6F6cyBCw6Fyw6FueQ==?= <bal...@tud.at> wrote: > Package: qgis > Version: 2.14.3+dfsg-2 > Severity: important > > Dear Maintainer, > > since a few days, QGIS isn't able to load modules that depend on QWebView > anymore. > > This affects e. g. the important OpenLayers module and happens on two Debian > Testing machines. Hi Balázs, The QGIS project is aware of the removing of this important Python module (QtWebKit) from Debian testing, and for QGIS itself there have been some changes to handle this. This means some functionality is missing, but core functionality should still be ok. The OpenLayers-plugins is an external plugin. I hope in your work you can use the QuickMapServices-plugin as an alternative. In the view of future, we hope to be able to use QtWebKit again in QGIS 3.0 which will be the next version after 2.16 and be based on Qt5 and use python3... Regards, Richard Duivenvoorde
