Bug#950121: opensmtpd: Major vulnerabilities in opensmtpd resulting in RCE and DOS
Package: opensmtpd Version: 6.6.1p1-5~bpo10+1 Severity: critical Tags: security upstream Justification: root security hole Dear Maintainer, Opensmtpd 6.6.1 has 2 critical vulnerabilities, including one that results in a remote root arbitray code execution see https://www.mail-archive.com/misc@opensmtpd.org/msg04850.html -- System Information: Debian Release: 10.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (90, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-6-amd64 (SMP w/2 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 /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages opensmtpd depends on: ii adduser3.118 ii debconf [debconf-2.0] 1.5.71 ii ed 1.15-1 ii init-system-helpers1.56+nmu1 ii libasr01.0.2-2 ii libc6 2.28-10 ii libdb5.3 5.3.28+dfsg1-0.5 ii libevent-2.1-6 2.1.8-stable-4 ii libpam0g 1.3.1-5 ii libssl1.1 1.1.1d-0+deb10u2 ii lsb-base 10.2019051400 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages opensmtpd recommends: ii opensmtpd-extras 6.6.0-1~bpo10+1 Versions of packages opensmtpd suggests: ii ca-certificates 20190110 -- Configuration Files: /etc/smtpd.conf changed [not included] -- debconf information excluded
Bug#543037: epiphany: FTBFS: configure: error: cannot find install-sh or install.sh in "." "./.." "./../.." patch
Patch to adjust symlinks for automake --- epiphany-0.7.0/debian/rules +++ epiphany-0.7.0/debian/rules @@ -23,6 +23,7 @@ endif configure-stamp: configure + for i in depcomp install-sh missing ; do ln -sf /usr/share/automake-1.11/$$i $$i ; done dh_testdir CFLAGS="$(CFLAGS)" ./configure --host=$(DEB_HOST_GNU_TYPE) \ --build=$(DEB_BUILD_GNU_TYPE) \ -- Matt Wheeler m...@funkyhat.org signature.asc Description: OpenPGP digital signature
Bug#594623: xserver-xorg-video-intel: after upgrade to 2.12.0+legacy1-1 X freeze on gdm start
Julien Cristau wrote: > On Sat, Aug 28, 2010 at 00:36:31 +0200, Cesare Leonardi wrote: > >> I've also tried (don't know if it make sense) with >> 2.6.34-1~expermental.2, always with i915.modeset=0: same freeze. >> > OK, it's starting to sound like this 'legacy' experiment is a failure so > far. On my 965GM it's a huge improvement over the driver in testing which lasts seconds and is unusable. I've been running with it for some time now and only two crashes so far, no accelerated video is the thing I miss most. I'm running on 2.6.34-1 (2.6.35-rc5 was unstable) Regards, M -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#597739: Salome: cannot load module salomeloader
Package: salome Version: 5.1.3-10 Severity: grave Justification: renders package unusable When trying to start the program with the command salomeloader The following error is returned: :~$ salomeloader Traceback (most recent call last): File "/usr/bin/salomeloader", line 20, in import salomeloader ImportError: No module named salomeloader Renders package unusable. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.35.4-ispm (SMP w/2 CPU cores; PREEMPT) Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages salome depends on: ii libboost-signals1.42.0 1.42.0-4 managed signals and slots library ii libboost-system1.42.0 1.42.0-4 Operating system (e.g. diagnostics ii libboost-thread1.42.0 1.42.0-4 portable C++ multi-threading ii libc6 2.11.2-6 Embedded GNU C Library: Shared lib ii libcos4-1 4.1.3-1+b1 omniORB CORBA services stubs ii libcppunit-1.12-1 1.12.1-1 Unit Testing Library for C++ ii libexpat1 2.0.1-7 XML parsing C library - runtime li ii libgcc1 1:4.5.0-4GCC support library ii libgfortran34.5.0-4 Runtime library for GNU Fortran ap ii libgl1-mesa-glx [libgl1 7.7.1-4 A free implementation of the OpenG ii libglu1-mesa [libglu1] 7.7.1-4 The OpenGL utility library (GLU) ii libgvc5 2.26.3-5 rich set of graph drawing tools - ii libhdf5-openmpi-1.8.4 1.8.4-patch1-2 Hierarchical Data Format 5 (HDF5) ii libmed1 2.3.6-3 Library to exchange meshed data (F ii libmedimportcxx02.3.6-3 Library to import old version file ii libomniorb4-1 4.1.3-1+b1 omniORB core libraries ii libomnithread3c24.1.3-1+b1 C++ threading library ii libopencascade-foundati 6.3.0.dfsg.1-6 OpenCASCADE CAE platform shared li ii libopencascade-modeling 6.3.0.dfsg.1-6 OpenCASCADE CAE platform shared li ii libopencascade-ocaf-6.3 6.3.0.dfsg.1-6 OpenCASCADE CAE platform shared li ii libopencascade-ocaf-lit 6.3.0.dfsg.1-6 OpenCASCADE CAE platform shared li ii libopencascade-visualiz 6.3.0.dfsg.1-6 OpenCASCADE CAE platform shared li ii libopencascade-visualiz 6.3.0.dfsg.1-6 OpenCASCADE CAE platform library d ii libopenmpi1.3 1.4.2-4 high performance message passing l ii libpython2.62.6.6-5 Shared Python runtime library (ver ii libqscintilla2-52.4.3-1 The Qt4 port of the Scintilla sour ii libqt4-opengl 4:4.6.3-2Qt 4 OpenGL module ii libqt4-xml 4:4.6.3-2Qt 4 XML module ii libqtcore4 4:4.6.3-2Qt 4 core module ii libqtgui4 4:4.6.3-2Qt 4 GUI module ii libqwt5-qt4 5.2.0-1 Qt4 widgets library for technical ii libscotch-5.1 5.1.8a.dfsg-2programs and libraries for graph, ii libssl0.9.8 0.9.8o-2 SSL shared libraries ii libstdc++6 4.5.0-4 The GNU Standard C++ Library v3 ii libvtk5.4 5.4.2-7+b2 Visualization Toolkit - A high lev ii libx11-62:1.3.3-3X11 client-side library ii libxml2 2.7.7.dfsg-4 GNOME XML library ii libxt6 1:1.0.7-1X11 toolkit intrinsics library ii omniorb4-nameserver 4.1.3-1 Transitional package for the omniO ii python 2.6.6-1 interactive high-level object-orie ii python-central 0.6.16+nmu1 register and build utility for Pyt ii python-omniorb 3.3-1Python bindings for omniORB ii python-vtk 5.4.2-7+b2 Python bindings for VTK ii salome-common 5.1.3-10 Numerical simulation pre- and post ii zlib1g 1:1.2.3.5.dfsg-1 compression library - runtime salome recommends no packages. Versions of packages salome suggests: ii salome-doc5.1.3-10 Numerical simulation pre- and post ii salome-examples 5.1.3-10 Numerical simulation pre- and post
Bug#633499: Confirm
I confirm this bug with the exact same error. It is also _grave_ as I can't print AT ALL on my kde installation. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#727213: Ubuntu Packages test
Hi all, I tested the Ubuntu packages (1.0.28~saucy) and the same crash happens. backintime-common (1.0.28~saucy) backintime-notify (1.0.28~saucy) backintime-kde4 (1.0.28~saucy) Hope this helps. Cheers
Bug#727213: New error message, same behavior
Hi all, I just updated sid and it pulled new KDE libraries. Now I got the following error: Traceback (most recent call last): File "/usr/share/backintime/kde4/app.py", line 1136, in main_window = MainWindow( cfg, app_instance, kapp, kaboutdata ) File "/usr/share/backintime/kde4/app.py", line 237, in __init__ self.list_files_view_model.removeColumns( 3, 2 ) TypeError: KDirModel.removeColumns() is a private method >From the backintime-kde packages from sid rep.
Bug#793796: Wicd-KDE plugin does not show on systray or desktop (KDE5)
ubject: wicd-kde: Wicd-KDE plugin does not show on systray or desktop (KDE5) Package: wicd-kde Version: 0.3.1-1 Justification: renders package unusable Severity: grave Dear Maintainer, * What led up to the situation? Install the package and try to add it to the systray or desktop. * What exactly did you do (or not do) that was effective (or ineffective)? Added to the systray or desktop. * What was the outcome of this action? None. * What outcome did you expect instead? Show the wicd plugin/plasmid and be able to control wicd from it. Wicd-client works. -- System Information: Debian Release: stretch/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.0.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages wicd-kde depends on: ii libc6 2.19-19 ii libgcc1 1:5.1.1-14 ii libkdecore5 4:4.14.2-5 ii libkdeui5 4:4.14.2-5 ii libplasma3 4:4.14.2-5 ii libqt4-dbus 4:4.8.7+dfsg-1 ii libqt4-network 4:4.8.7+dfsg-1 ii libqt4-svg 4:4.8.7+dfsg-1 ii libqtcore4 4:4.8.7+dfsg-1 ii libqtgui4 4:4.8.7+dfsg-1 ii libsolid4 4:4.14.2-5 ii libstdc++6 5.1.1-14 ii wicd-daemon 1.7.2.4-4.1 wicd-kde recommends no packages. wicd-kde suggests no packages. -- no debconf information
Bug#880704: bumblebee-nvidia: Upgrading mesa and nvidia drivers with bumblebee-nvidia installed breaks the desktop
On Sun, 2017-11-05 at 17:35 +, Luca Boccassi wrote: > On Fri, 2017-11-03 at 19:41 -0500, JWM wrote: > > Package: bumblebee-nvidia > > Version: 3.2.1-16 > > Severity: grave > > Justification: renders package unusable > > > > Dear Maintainer, > > > > My system is a Thinkpad T440p, with both an Intel and an NVIDIA > > Optimus cards. > > On Wednesday, upgrading both the Mesa libraries and the NVIDIA > > driver > > broke the > > desktop ---i.e., after reboot, the GDM target never showed up due > > to > > a Clutter > > error. > > > > Synaptic's history shows the following as > > installed/upgraded/removed > > on that > > day: > > > > - > > --- > > Commit Log for Wed Nov 1 08:23:33 2017 > > > > > > Removed the following packages: > > libegl1-glvnd-nvidia > > libegl1-mesa-dev > > libgl1-mesa-glx:i386 > > libgtk-3-dev > > primus > > primus-libs-ia32:i386 > > primus-libs:i386 > > > > Upgraded the following packages: > > debconf (1.5.63) to 1.5.64 > > debconf-i18n (1.5.63) to 1.5.64 > > eog-plugin-map (3.25.92-1) to 3.26.1-1 > > epiphany-browser (3.24.3-1) to 3.26.1-1 > > epiphany-browser-data (3.24.3-1) to 3.26.1-1 > > giada (0.14.1~dfsg1-1) to 0.14.3~dfsg1-1 > > gir1.2-javascriptcoregtk-4.0 (2.16.6-1) to 2.18.1-1 > > gir1.2-webkit2-4.0 (2.16.6-1) to 2.18.1-1 > > gnome-maps (3.25.91-1) to 3.26.1-1 > > gnome-session (3.24.1-2) to 3.26.1-1 > > gnome-session-bin (3.24.1-2) to 3.26.1-1 > > gnome-session-common (3.24.1-2) to 3.26.1-1 > > gnome-software (3.22.5-1) to 3.26.1-2 > > gnome-software-common (3.22.5-1) to 3.26.1-2 > > gnome-software-plugin-flatpak (3.22.5-1) to 3.26.1-2 > > gstreamer1.0-plugins-bad (1.12.2-1+b1) to 1.12.3-2 > > libegl-nvidia0 (375.82-5) to 375.82-7 > > libegl1-mesa (13.0.6-1+b2) to 17.2.3-1 > > libgbm1 (13.0.6-1+b2) to 17.2.3-1 > > libgl1-glvnd-nvidia-glx (375.82-5) to 375.82-7 > > libgl1-mesa-dri (13.0.6-1+b2) to 17.2.3-1 > > libgl1-mesa-dri:i386 (13.0.6-1+b2) to 17.2.3-1 > > libgl1-mesa-glx (13.0.6-1+b2) to 17.2.3-1 > > libgl1-nvidia-glvnd-glx (375.82-5) to 375.82-7 > > libglapi-mesa (13.0.6-1+b2) to 17.2.3-1 > > libglapi-mesa:i386 (13.0.6-1+b2) to 17.2.3-1 > > libgles-nvidia1 (375.82-5) to 375.82-7 > > libgles-nvidia2 (375.82-5) to 375.82-7 > > libgles1-glvnd-nvidia (375.82-5) to 375.82-7 > > libgles1-nvidia (375.82-5) to 375.82-7 > > libgles2-glvnd-nvidia (375.82-5) to 375.82-7 > > libgles2-mesa (13.0.6-1+b2) to 17.2.3-1 > > libgles2-nvidia (375.82-5) to 375.82-7 > > libglx-nvidia0 (375.82-5) to 375.82-7 > > libglx0-glvnd-nvidia (375.82-5) to 375.82-7 > > libgstreamer-plugins-bad1.0-0 (1.12.2-1+b1) to 1.12.3-2 > > libharfbuzz-dev (1.5.1-1) to 1.6.2-1 > > libharfbuzz-gobject0 (1.5.1-1) to 1.6.2-1 > > libharfbuzz-icu0 (1.5.1-1) to 1.6.2-1 > > libharfbuzz0b (1.5.1-1) to 1.6.2-1 > > libjavascriptcoregtk-4.0-18 (2.16.6-1) to 2.18.1-1 > > libnetcdf-c++4 (4.2-7) to 4.2-7+b1 > > libnvidia-cfg1 (375.82-5) to 375.82-7 > > libnvidia-eglcore (375.82-5) to 375.82-7 > > libnvidia-glcore (375.82-5) to 375.82-7 > > libnvidia-ml1 (375.82-5) to 375.82-7 > > libosmesa6 (13.0.6-1+b2) to 17.2.3-1 > > libwayland-egl1-mesa (13.0.6-1+b2) to 17.2.3-1 > > libwebkit2gtk-4.0-37 (2.16.6-1) to 2.18.1-1 > > libwebkit2gtk-4.0-37-gtk2 (2.16.6-1) to 2.18.1-1 > > libxatracker2 (13.0.6-1+b2) to 17.2.3-1 > > mesa-vdpau-drivers (13.0.6-1+b2) to 17.2.3-1 > > netcdf-bin (1:4.4.1.1-2) to 1:4.5.0-1 > > nvidia-alternative (375.82-5) to 375.82-7 > > nvidia-driver (375.82-5) to 375.82-7 > > nvidia-driver-bin (375.82-5) to 375.82-7 > > nvidia-driver-libs (375.82-5) to 375.82-7 > > nvidia-egl-icd (375.82-5) to 375.82-7 > > nvidia-kernel-support (375.82-5) to 375.82-7 > > nvidia-smi (375.82-5) to 375.82-7 > > nvidia-vdpau-driver (375.82-5) to 375.82-7 > > nvidia-vulkan-icd (375.82-5) to 375.82-7 > > primus-libs (0~20150328-4) to 0~20150328-5 > > xserver-xorg-video-nvidia (375.82-5) to 375.82-7 > > xwayland (2:1.19.3-2) to 2:1.19.5-1 > > > > Installed the following packages: > > gir1.2-harfbuzz-0.0 (1.6.2-1) > > libegl1 (0.2.999+git20170802-5) > > libfwupd2 (1.0.0-4) > > libglvnd-core-dev (0.2.999+git20170802-5) > > libglvnd0:i386 (0.2.999+git20170802-5) > > libglx-mesa0 (17.2.3-1) > > libglx-mesa0:i386 (17.2.3-1) > > libllvm5.0 (1:5.0~+rc2-1) > > libllvm5.0:i386 (1:5.0~+rc2-1) > > libnetcdf13 (1:4.5.0-1) > > librtmidi4 (3.0.0~ds1-2) > > libxcb-xfixes0:i386 (1.12-1) > > python3-debconf (1.5.64) > > - > > --- > > > > > > > > In order to solved the issue, I uninstalled all the NVIDIA-related > > packages, > > reinstalled GDM and blacklisted nouveau. > > > > After that, I tried installing bumblebee-nvidia again, which > > effectively broke > > the system once again. > > > > So it seems the bumblebee-nvidia package is not compatible with the > > newest mesa > > and NVIDIA drivers. > > With nvidia-driver 375.82-8 it should all be installable again, > please > re-try when you have time. Sorry for the
Bug#904031: gnome-shell is not opening
Package: gnome-shell Version: 3.22.3-3 Severity: grave Justification: renders package unusable Dear Maintainer, * What led up to the situation? Just use debian desktop * What was the outcome of this action? syslog says gnome-shell[800]: JS LOG: pushModal: invocation of begin_modal failed -- System Information: Debian Release: 9.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-7-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gnome-shell depends on: ii dconf-gsettings-backend [gsettings-backend] 0.26.0-2+b1 ii evolution-data-server3.22.7-1 ii gir1.2-accountsservice-1.0 0.6.43-1 ii gir1.2-atspi-2.0 2.22.0-6+deb9u1 ii gir1.2-caribou-1.0 0.4.21-1+b1 ii gir1.2-freedesktop 1.50.0-1+b1 ii gir1.2-gcr-3 3.20.0-5.1 ii gir1.2-gdesktopenums-3.0 3.22.0-1 ii gir1.2-gdm-1.0 3.22.3-3+deb9u1 ii gir1.2-glib-2.0 1.50.0-1+b1 ii gir1.2-gnomebluetooth-1.03.20.1-1 ii gir1.2-gnomedesktop-3.0 3.22.2-1 ii gir1.2-gtk-3.0 3.22.11-1 ii gir1.2-gweather-3.0 3.20.4-1 ii gir1.2-ibus-1.0 1.5.14-3 ii gir1.2-mutter-3.03.22.3-2 ii gir1.2-networkmanager-1.01.6.2-3 ii gir1.2-nmgtk-1.0 1.4.4-1 ii gir1.2-pango-1.0 1.40.5-1 ii gir1.2-polkit-1.00.105-18 ii gir1.2-soup-2.4 2.56.0-2+deb9u2 ii gir1.2-telepathyglib-0.120.24.1-1.1 ii gir1.2-telepathylogger-0.2 0.8.2-2 ii gir1.2-upowerglib-1.00.99.4-4+b1 ii gjs 1.46.0-1+b2 ii gnome-backgrounds3.22.1-1 ii gnome-settings-daemon3.22.2-2+deb9u2 ii gnome-shell-common 3.22.3-3 ii gsettings-desktop-schemas3.22.0-1 ii libatk-bridge2.0-0 2.22.0-2 ii libatk1.0-0 2.22.0-1 ii libc62.24-11+deb9u3 ii libcairo21.14.8-1 ii libcanberra-gtk3-0 0.30-3 ii libcanberra0 0.30-3 ii libcroco30.6.11-3 ii libdbus-glib-1-2 0.108-2 ii libecal-1.2-19 3.22.7-1 ii libedataserver-1.2-223.22.7-1 ii libgcr-base-3-1 3.20.0-5.1 ii libgdk-pixbuf2.0-0 2.36.5-2+deb9u2 ii libgirepository-1.0-11.50.0-1+b1 ii libgjs0e [libgjs0-libmozjs-24-0] 1.46.0-1+b2 ii libglib2.0-0 2.50.3-2 ii libglib2.0-bin 2.50.3-2 ii libgstreamer1.0-01.10.4-1 ii libgtk-3-0 3.22.11-1 ii libical2 2.0.0-0.5+b1 ii libicu57 57.1-6+deb9u2 ii libjson-glib-1.0-0 1.2.6-1 ii libmozjs-24-024.2.0-5.1+b2 ii libmutter0i 3.22.3-2 ii libnm-glib4 1.6.2-3 ii libnm-util2 1.6.2-3 ii libpango-1.0-0 1.40.5-1 ii libpangocairo-1.0-0 1.40.5-1 ii libpolkit-agent-1-0 0.105-18 ii libpolkit-gobject-1-00.105-18 ii libpulse-mainloop-glib0 10.0-1+deb9u1 ii libpulse010.0-1+deb9u1 ii libsecret-1-00.18.5-3.1 ii libstartup-notification0 0.12-4+b2 ii libsystemd0 232-25+deb9u4 ii libtelepathy-glib0 0.24.1-1.1 ii libwayland-client0 1.12.0-1 ii libx11-6 2:1.6.4-3 ii libxfixes3 1:5.0.3-1 ii mutter 3.22.3-2 ii python3 3.5.3-1 Versions of packages gnome-shell recommends: ii gdm33.22.3-3+deb9u1 ii gkbd-capplet3.22.0.1-1+b1 ii gnome-contacts 3.22.
Bug#896295: Tensorflow is missing
Hi, On Mon, Jan 07, 2019 at 12:24:29AM +0100, Petter Reinholdtsen wrote: > Is TensorFlow different from libtensorflow, already in unstable: experimental > libtensorflow-cc1.10 - Computation using data flow graphs for scalable > machine learning (C++) > libtensorflow-dev - Computation using data flow graphs for scalable machine > learning (dev) > libtensorflow-framework1.10 - Computation using data flow graphs for scalable > machine learning > libtensorflow1.10 - Computation using data flow graphs for scalable machine > learning (C) > > If not, perhaps keras should be adjusted to use it, and its No. Please don't build any package that depends on TF 1.X because it is literally an incomplete WIP. You can do that untill TF 2.X landed onto experimental with a (yet anotehr) totally re-written build system. > package description updated? The tensorflow source package > entered unstable 2018-11-22. experimental > As for the problem with running keras in unstable, perhaps it is a > good idea to extend the autopkgtest script to detect such problems early? Without autopkgtest I'm already aware of bunch of issues existing in the present tensorflow package, which renders it inappropriate to enter even unstable.
Bug#919183: julia: baseline violation on armhf
control: severity -1 important This is not baseline violation. julia -C "armv7-a;armv7-a,neon;armv7-a,neon,vfp4" compiles 3 branches of code, and the optimal branch will be selected during runtime. The SIGILL raised during build on the buildd stems from LLVM's incorrect CPU detection. Here is a proof with QEMU emulated ARM Cortex-a7: (sid_armhf-dchroot)lumin@abel:~$ julia Invalid ARM instruction at 0xad4253d0: 0xf2800050 signal (4): Illegal instruction in expression starting at no file:0 __init__ at ./sysinfo.jl:92 jl_apply_generic at /usr/bin/../lib/arm-linux-gnueabihf/libjulia.so.1 (unknown line) unknown function (ip: 0xb6d7e006) unknown function (ip: 0xb6d6e43a) julia_init__threading at /usr/bin/../lib/arm-linux-gnueabihf/libjulia.so.1 (unknown line) unknown function (ip: 0x44df2c) __libc_start_main at /lib/arm-linux-gnueabihf/libc.so.6 (unknown line) unknown function (ip: 0x44dfc4) Allocations: 3006 (Pool: 3002; Big: 4); GC: 0 Illegal instruction (sid_armhf-dchroot)lumin@abel:~$ qemu-arm -cpu cortex-a7 julia Error while loading julia: Permission denied (sid_armhf-dchroot)lumin@abel:~$ qemu-arm -cpu cortex-a7 /usr/bin/julia _ _ _ _(_)_ | Documentation: https://docs.julialang.org (_) | (_) (_)| _ _ _| |_ __ _ | Type "?" for help, "]?" for Pkg help. | | | | | | |/ _` | | | | |_| | | | (_| | | Version 1.0.3 _/ |\__'_|_|_|\__'_| | Debian ⛬ julia/1.0.3+dfsg-1 |__/ | julia>
Bug#1034624: zfs-dkms: Please revert corruption-causing optimization in 2.1.10 release
Control: fixed -1 2.1.11-1 2.1.11-1 has migrated to testing.
Bug#1035458: libtorch-dev: broken symlinks: /usr/lib/x86_64-linux-gnu/libcaffe2_*.so -> libcaffe2_*.so.1.13
Control: severity -1 important Control: fixed -1 1.13.1+dfsg-5 I believe these symlinks were deprecated already. These symlinks are removed in 1.13.1+dfsg-5 (experimental). I'm not able to prepare a 1.13.1+dfsg-4.1 release to only remove these symlinks within a short time... too busy lately. So just downgrading the severity as it is not expected to harm any functionality.
Bug#1038152: supertuxkart: Supertuxkart does not start - missing NotoColorEmoji.ttf
I tried purging the mono font packages, then supertuxkart and then reinstalling supertuxkart from scratch. This way the installation was working fine. I do not know what happened (why the first installation of supertuxkart did not work), but I solved the problem. So you can close this bug I guess. Thanks
Bug#1027851: pytorch FTBFS with Python 3.11 as default version
Feel free to break the pytorch reverse dependencies without a transition slot -- we do not need the slot in the current status. The rdeps are already not in testing due to RC bugs and needs some new patchworks. Manual upload is needed for its rebuild. On Fri, 2023-01-27 at 20:19 +0800, Aron Xu wrote: > On Fri, Jan 27, 2023 at 3:48 PM Andreas Tille wrote: > > > > Hi Aron, > > > > Am Fri, Jan 27, 2023 at 02:09:05AM +0800 schrieb Aron Xu: > > > > > > The packaging work of 1.13.1[1] has started on salsa. We still have a > > > failure related to fmtlib before making the package build successfully > > > [5/1781]. Both Mo and I have limited bandwidth here and help is always > > > appreciated. > > > > I've just checked the changelog and noticed: > > > >Bump SOVERSION to 1.13 > > > > but we are in transition freeze. So this needs to be coordinated with > > release team. I guess if we argue that 1.13 will support Python3.11 > > this could be some argument after the decision that this should be the > > supported Python3 version for the next release. > > > > Agreed. And it seems the only rdepends of libtorch1.12 is > python3-torchvision which is owned by us, too, so the update would be > fairly easy to handle. > > Regards, > Aron >
Bug#1027851: pytorch FTBFS with Python 3.11 as default version
For reference, a 8 core + 16GB RAM configuration should be able to finish the pytorch compilation timely. The build takes roughly an hour. My observation is based on power9 -- on amd64 it should be something similar. On Sun, 2023-01-29 at 11:09 +0800, Aron Xu wrote: > On Fri, Jan 27, 2023 at 9:42 PM Andreas Tille wrote: > > > > Am Fri, Jan 27, 2023 at 08:21:46PM +0800 schrieb Aron Xu: > > > On Fri, Jan 27, 2023 at 7:12 PM Andreas Tille wrote: > > > > make: *** [debian/rules:83: binary] Terminated > > > > ninja: build stopped: interrupted by user. > > > > > > > > could be a sign for this. Was I to naive to assume Salsa CI could > > > > manage a pytorch build and should we possibly switch this off again? > > > > > > > > > > Not sure but by wild guess it could be caused by running for too long? > > > > I do not think so. Since I was aware that it will take long I have > > adjusted the timeout from 1h (default) to 4h. The log stops a bit after > > 3h. To my experience if timeout is the reason the log ends with this > > information. > > > > Then I guess it could be out-of-memory, the build process is hungry > for RAM and a single cc1plus process can take at least up to 2GB > memory during my quick observation. > > Regards, > Aron >
Bug#1027851: pytorch FTBFS with Python 3.11 as default version
On Sun, 2023-01-29 at 09:03 +0100, Andreas Tille wrote: > > > I have no idea about fmtlib but I noticed: > > [2022-09-04] fmtlib 9.1.0+ds1-2 MIGRATED to testing (Debian testing > watch) > [2022-09-04] Accepted fmtlib 9.1.0+ds1-2 (source) into unstable > (Shengjing Zhu) > [2022-08-27] Accepted fmtlib 9.1.0+ds1-1 (source) into experimental > (Shengjing Zhu) > [2022-08-24] fmtlib 9.0.0+ds1-4 MIGRATED to testing (Debian testing > watch) > > Is this failure dating back to August last year and possibly > connected to > the version bump from 9.00 to 9.1.0? I had some similar thoughts during diagnosis. That said, I have already patched the line that FTBFS, and reverted it back to the std::ostringstream implementation, which is merely introducing some overhead. And Aron has uploaded pytorch to NEW.
Bug#1027851: pytorch FTBFS with Python 3.11 as default version
On Mon, 2023-01-30 at 06:46 +0100, Andreas Tille wrote: > Am Sun, Jan 29, 2023 at 10:22:24AM -0500 schrieb M. Zhou: > > > Since we do not have this module[2] (yet) we should probably exclude all > tests that need this module, right? If you think its a nice thing to > have I would volunteer to package this in DPT. Yes, we can skip these python tests for now. And the fix is already uploaded. We should be ready to wait for the testing migration.
Bug#1041230: onetbb 2021.9.0-1 FTBFS on multiple release architectures
Source: onetbb Version: 2021.9.0-1 Severity: serious I'm aware of this issue. I'm slightly faster than buildd for toolchain upgrades. The issue will automatically disappear once our amd64 buildd migrates to gcc-13. The gcc-12 will lead to the FTBFS you see now. Local sbuild with gcc-13 has no issue.
Bug#1027215: How much do we lose if we remove theano (+keras, deepnano, invesalius)?
Currently, I'd say PyTorch and TensorFlow are the two most popular libraries. And I even worry google is trying to write something new like Jax to replace TensorFlow in some aspects. On Sat, 2023-01-14 at 11:12 +, Rebecca N. Palmer wrote: > theano has been mostly abandoned upstream since 2018. (The Aesara fork > is not abandoned, but includes interface changes including the import > name, so would break reverse dependencies not specifically altered for it.) > > Its reverse dependencies are keras, deepnano and invesalius. > > It is currently broken, probably by numpy 1.24 (#1027215), and the > immediately obvious fixes weren't enough > (https://salsa.debian.org/science-team/theano/-/pipelines). > > Is this worth spending more effort on fixing, or should we just remove it? >
Bug#1027613: update
Control: severity -1 important I think this FTBFS mostly stems from the toolchain. 1. before the bug is filed, it builds successfully on amd64 2. On the day I recieved this bug report, I reproduced it 3. after some toolchain updates, I cannot reproduce it anymore
Bug#1024795: python-llvmlite
Sure, I think we can ship a snapshot version as long as it works fine with llvm-14. Could you please verify the snapshot hash again? https://github.com/numba/llvmlite/commit/c65b3e662b7b08920172b710419d7a06b660be59 The commit seems missing. If it was close to the master branch, I can directly pull the master branch and upload the corresponding snapshot. On Wed, 2022-12-21 at 20:05 -0800, Diane Trout wrote: > Hi, > > I was trying to update numba, and need the updated version of llvmlite > built against llvm-14 > > The version that's currently in unstable is still built against llvml- > 11 > > https://packages.debian.org/sid/python3-llvmlite > > I've checked out out the llvmlite repository and rebuilt it locally > using commit c65b3e662b7b08920172b710419d7a06b660be59 against llvm-14 > > and llvmlite's test cases pass. (And most of numba's passed too. And I > think the remaining test failures aren't related to llvmlite) > > Is there a chance we could get an updated version released soon? > > Thanks > Diane Trout
Bug#1024795: python-llvmlite
Control: tags -1 +moreinfo
I'm confused. How did you manage to build the package from source
using c65b3e662b7b08920172b710419d7a06b660be59 on salsa?
I did not upload it because I can never successfully build it
from source.
-
passmanagers.cpp: In function ‘void LLVMPY_SetTimePasses(bool)’:
passmanagers.cpp:36:37: error: ‘TimePassesIsEnabled’ was not declared in this
scope
36 | LLVMPY_SetTimePasses(bool enable) { TimePassesIsEnabled = enable; }
| ^~~
passmanagers.cpp: In function ‘void
LLVMPY_AddDeadCodeEliminationPass(LLVMPassManagerRef)’:
passmanagers.cpp:158:50: error: cannot convert ‘llvm::FunctionPass*’ to
‘llvm::Pass*’
158 | unwrap(PM)->add(createDeadCodeEliminationPass());
| ~^~
| |
| llvm::FunctionPass*
In file included from passmanagers.cpp:10:
/usr/lib/llvm-14/include/llvm/IR/LegacyPassManager.h:48:26: note:
initializing argument 1 of ‘virtual void
llvm::legacy::PassManagerBase::add(llvm::Pass*)’
48 | virtual void add(Pass *P) = 0;
|~~^
passmanagers.cpp: In function ‘void LLVMPY_AddSROAPass(LLVMPassManagerRef)’:
passmanagers.cpp:181:75: error: cannot convert ‘llvm::FunctionPass*’ to
‘llvm::Pass*’
181 | LLVMPY_AddSROAPass(LLVMPassManagerRef PM) {
unwrap(PM)->add(createSROAPass()); }
|
~~^~
|
|
|
llvm::FunctionPass*
/usr/lib/llvm-14/include/llvm/IR/LegacyPassManager.h:48:26: note:
initializing argument 1 of ‘virtual void
llvm::legacy::PassManagerBase::add(llvm::Pass*)’
48 | virtual void add(Pass *P) = 0;
|~~^
make[1]: *** [Makefile.linux:22: passmanagers.o] Error 1
make[1]: *** Waiting for unfinished jobs
make[1]: Leaving directory '/<>/ffi'
14.0.6
SVML not detected
Traceback (most recent call last):
File "/<>/ffi/build.py", line 227, in
main()
File "/<>/ffi/build.py", line 217, in main
main_posix('linux', '.so')
File "/<>/ffi/build.py", line 209, in main_posix
subprocess.check_call(['make', '-f', makefile] + makeopts)
File "/usr/lib/python3.10/subprocess.py", line 369, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['make', '-f', 'Makefile.linux',
'-j8']' returned non-zero exit status 2.
error: command '/usr/bin/python3' failed with exit code 1
E: pybuild pybuild:386: build: plugin distutils failed with: exit code=1:
/usr/bin/python3 setup.py build
dh_auto_build: error: pybuild --build -i python{version} -p "3.11 3.10"
returned exit code 13
make: *** [debian/rules:11: build] Error 25
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
On Thu, 2022-12-22 at 18:20 -0500, M. Zhou wrote:
> Sure, I think we can ship a snapshot version as long as it works
> fine with llvm-14. Could you please verify the snapshot hash
> again?
>
> https://github.com/numba/llvmlite/commit/c65b3e662b7b08920172b710419d7a06b660be59
>
> The commit seems missing. If it was close to the master branch,
> I can directly pull the master branch and upload the corresponding
> snapshot.
>
> On Wed, 2022-12-21 at 20:05 -0800, Diane Trout wrote:
> > Hi,
> >
> > I was trying to update numba, and need the updated version of llvmlite
> > built against llvm-14
> >
> > The version that's currently in unstable is still built against llvml-
> > 11
> >
> > https://packages.debian.org/sid/python3-llvmlite
> >
> > I've checked out out the llvmlite repository and rebuilt it locally
> > using commit c65b3e662b7b08920172b710419d7a06b660be59 against llvm-14
> >
> > and llvmlite's test cases pass. (And most of numba's passed too. And I
> > think the remaining test failures aren't related to llvmlite)
> >
> > Is there a chance we could get an updated version released soon?
> >
> > Thanks
> > Diane Trout
>
Bug#980464: zfs-dracut: dracut+ZFS-on-root systems rendered unbootable
Control: severity -1 important Lowering the severity to unblock the migration, as migration is currently the first priority for us due to the huge diff between 0.8.6 and 2.0.1, given the stable freeze schedule. I will fix it and upload 2.0.1-3 immediately after migration. It is easy to apply for freeze exceptions for such important bugfix that does not involve a big diff. In contrast, exception for the 0.8.6 -> 2.0.1 change is impossible to get approved.
Bug#973417: Also happens on Amazon EC2 & Lightsail
Hi, I can confirm this bug happening on Amazon Lightsail and EC2 instances running Debian. After kernel upgrade the machines won't boot anymore and end in kernel panic. Here is a log from failed boot on EC2: [0.16] [] ? rest_init+0x80/0x80 [0.16] [] ? kernel_init+0xa/0x100 [0.16] [] ? ret_from_fork+0x57/0x70 [0.16] Code: 8d ba 03 02 00 00 48 8d 14 d2 44 8d 59 11 49 8d 2c d2 c1 e7 0c 48 63 ff 8b 55 14 81 e2 ff 0f 00 00 48 81 ea 00 10 80 00 48 29 fa <44> 89 1a 89 72 10 8b 55 14 83 c1 10 81 e2 ff 0f 00 00 48 81 ea [0.16] RIP [] mp_irqdomain_activate+0x62/0xa0 [0.16] RSP [0.16] CR2: ff5fb000 [0.16] ---[ end trace 3b908cb762782fed ]--- [0.160039] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0009 [0.160039] [0.00] Cannot get hvm parameter CONSOLE_EVTCHN (18): -22! [0.156662] BUG: unable to handle kernel paging request at ff5fb000 [0.16] IP: [] mp_irqdomain_activate+0x62/0xa0 [0.16] PGD 8420d067 [0.16] PUD 8420f067 [0.16] PMD 84210067 [0.16] PTE 0 [0.16] [0.16] Oops: 0002 [#1] SMP [0.16] Modules linked in: [0.16] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.0-14-amd64 #1 Debian 4.9.240-1 [0.16] Hardware name: Xen HVM domU, BIOS 4.2.amazon 08/24/2006 [0.16] task: 8c64ca06d040 task.stack: a7ccc0644000 [0.16] RIP: 0010:[] [] mp_irqdomain_activate+0x62/0xa0 [0.16] RSP: :a7ccc0647cf0 EFLAGS: 00010086 [0.16] RAX: 0082 RBX: 8c64ca2e9d00 RCX: [0.16] RDX: ff5fb000 RSI: 0001 RDI: 00204000 [0.16] RBP: b28ad988 R08: b26be7f0 R09: [0.16] R10: b28ad940 R11: 0011 R12: 0001 [0.16] R13: 8c64cad85058 R14: 8c64cad850d4 R15: 8c64ca2ef380 [0.16] FS: () GS:8c64cb20() knlGS: [0.16] CS: 0010 DS: ES: CR0: 80050033 [0.16] CR2: ff5fb000 CR3: 84208000 CR4: 00160670 [0.16] DR0: DR1: DR2: [0.16] DR3: DR6: fffe0ff0 DR7: 0400 [0.16] Stack: [0.16] 8c64cad85058 8c64cad85058 b1ade5ea 8c64cad85000 [0.16] b1adaf03 8c64cad85000 8c64cad85000 8c64cad850a0 [0.16] 0009 b1ad968c 0246 8c64cad85058 [0.16] Call Trace: [0.16] [] ? irq_domain_activate_irq+0x1a/0x30 [0.16] [] ? irq_startup+0x33/0x80 [0.16] [] ? __setup_irq+0x58c/0x640 [0.16] [] ? xen_register_pirq.constprop.9+0xd4/0x110 [0.16] [] ? request_threaded_irq+0x10a/0x1b0 [0.16] [] ? acpi_ev_sci_dispatch+0x5a/0x5a [0.16] [] ? acpi_os_install_interrupt_handler+0xa5/0x100 [0.16] [] ? acpi_sleep_proc_init+0x22/0x22 [0.16] [] ? set_debug_rodata+0xc/0xc [0.16] [] ? acpi_ev_install_xrupt_handlers+0x16/0x64 [0.16] [] ? acpi_init+0xb6/0x33e [0.16] [] ? __class_create+0x4f/0x80 [0.16] [] ? video_setup+0x79/0x79 [0.16] [] ? set_debug_rodata+0xc/0xc [0.16] [] ? do_one_initcall+0x4e/0x180 [0.16] [] ? set_debug_rodata+0xc/0xc [0.16] [] ? kernel_init_freeable+0x16b/0x1ec [0.16] [] ? rest_init+0x80/0x80 [0.16] [] ? kernel_init+0xa/0x100 [0.16] [] ? ret_from_fork+0x57/0x70 [0.16] Code: 8d ba 03 02 00 00 48 8d 14 d2 44 8d 59 11 49 8d 2c d2 c1 e7 0c 48 63 ff 8b 55 14 81 e2 ff 0f 00 00 48 81 ea 00 10 80 00 48 29 fa <44> 89 1a 89 72 10 8b 55 14 83 c1 10 81 e2 ff 0f 00 00 48 81 ea [0.16] RIP [] mp_irqdomain_activate+0x62/0xa0 [0.16] RSP [0.16] CR2: ff5fb000 [0.16] ---[ end trace 18c93002ce0feedc ]--- [0.160041] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0009 [0.160041]
Bug#844333: node-iconv-lite: Source doesn't include required directories
Package: node-iconv-lite Version: 0.4.13-1 Severity: grave Justification: renders package unusable Dear Maintainer, Directories `encodings` and `generation` are not included in debian package archive. npm2deb skips it as those directories are not mentioned in package.json. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages node-iconv-lite depends on: ii nodejs 4.6.1~dfsg-1 node-iconv-lite recommends no packages. node-iconv-lite suggests no packages. -- no debconf information
Bug#987689: tbb already in new queue of debian
To anyone who is concerned with the package status in debian, since there is a significant change in packaging, we have to go through new queue again. https://ftp-master.debian.org/new/onetbb_2021.4.0-1~exp1.html This depends on our ftp team. The latest package git repository is here: https://salsa.debian.org/science-team/tbb
Bug#1000336: Upgrading tbb
Hi Diane, Thank you. I have added that patch in the git repository. On Tue, 2022-02-08 at 13:49 -0800, Diane Trout wrote: > Hi, > > After Andreas pointed it out I looked through some of the build > failures for onetbb and talked to upstream about the i386 failure. > https://github.com/oneapi-src/oneTBB/issues/370#issuecomment-1030387116 > > They have a patch. > https://github.com/oneapi-src/oneTBB/commit/542a27fa1cfafaf76772e793549d9f4d288d03a9 > > I've tested it against a checkout of the 2021.5.0-1 version of onetbb > on i386 and it does build with it applied. Once there was a test > failure, and once all tests ran successfully > > I see that you've made some more progress for the memory alignment > bugs > so I didn't commit "Detect 32 bit x86 systems while adding -mwaitpkg > option" i386 patch but could if you want. > > Diane > >
Bug#1005713: tensorflow FTBFS; bazel still tries to download during build.
Source: tensorflow Version: 2.3.1-1 Severity: serious Justification: FTBFS; Bazel tries to download during build. Building tensorflow locally with sbuild results in errors like the follows ERROR: /<>/tensorflow/compiler/mlir/tensorflow/BUILD:1249:11: //tensorflow/compiler/mlir/tensorflow:compile_mlir_util_no_tf_dialect_p asses depends on @llvm-project//mli r:Parser in repository @llvm-project which failed to fetch. no such package '@llvm-project//mlir': java.io.IOException: Error downloading [https://storage.googleapis.com/mirror.tens orflow.org/github.com/llvm/llvm- project/archive/7e825abd5704ce28b166f9463d4bd304348fd2a9.tar.gz, https://github.com/llvm/llvm-project/archive/7e825abd5704ce28b166f9463d4bd304348fd2a 9.tar.gz] to /tmp/.cache/bazel/_bazel_lumin/30c7b4fa2330f0b3b6e67535723f3f22/externa l/llvm-project/7e825abd5704ce28b166f9463d4bd304348fd2a9.tar.gz: connect timed out ERROR: /<>/tensorflow/compiler/mlir/tensorflow/BUILD:1249:11: //tensorflow/compiler/mlir/tensorflow:compile_mlir_util_no_tf_dialect_p asses depends on @llvm-project//mli r:Pass in repository @llvm-project which failed to fetch. no such package '@llvm-project//mlir': java.io.IOException: Error downloading [https://storage.googleapis.com/mirror.tensor flow.org/github.com/llvm/llvm- project/archive/7e825abd5704ce28b166f9463d4bd304348fd2a9.tar.gz, https://github.com/llvm/llvm-project/archive/7e825abd5704ce28b166f9463d4bd304348fd2a9 . tar.gz] to /tmp/.cache/bazel/_bazel_lumin/30c7b4fa2330f0b3b6e67535723f3f22/externa l/llvm-project/7e825abd5704ce28b166f9463d4bd304348fd2a9.tar.gz: connect timed out ERROR: /<>/tensorflow/compiler/mlir/tensorflow/BUILD:1249:11: //tensorflow/compiler/mlir/tensorflow:compile_mlir_util_no_tf_dialect_p asses depends on @llvm-project//mli r:Shape in repository @llvm-project which failed to fetch. no such package '@llvm-project//mlir': java.io.IOException: Error downloading [https://storage.googleapis.com/mirror.tenso rflow.org/github.com/llvm/llvm- project/archive/7e825abd5704ce28b166f9463d4bd304348fd2a9.tar.gz, https://github.com/llvm/llvm-project/archive/7e825abd5704ce28b166f9463d4bd304348fd2a9 .tar.gz] to /tmp/.cache/bazel/_bazel_lumin/30c7b4fa2330f0b3b6e67535723f3f22/externa l/llvm-project/7e825abd5704ce28b166f9463d4bd304348fd2a9.tar.gz: connect timed out ERROR: /<>/tensorflow/compiler/mlir/tensorflow/BUILD:1249:11: //tensorflow/compiler/mlir/tensorflow:compile_mlir_util_no_tf_dialect_p asses depends on @llvm-project//mli r:StandardOps in repository @llvm-project which failed to fetch. no such package '@llvm-project//mlir': java.io.IOException: Error downloading [https://storage.googleapis.com/mirror .tensorflow.org/github.com/llvm/llvm- project/archive/7e825abd5704ce28b166f9463d4bd304348fd2a9.tar.gz, https://github.com/llvm/llvm-project/archive/7e825abd5704ce28b166f9463d4bd30434 8fd2a9.tar.gz] to /tmp/.cache/bazel/_bazel_lumin/30c7b4fa2330f0b3b6e67535723f3f22/externa l/llvm-project/7e825abd5704ce28b166f9463d4bd304348fd2a9.tar.gz: connect timed out ERROR: /<>/tensorflow/compiler/mlir/tensorflow/BUILD:1249:11: //tensorflow/compiler/mlir/tensorflow:compile_mlir_util_no_tf_dialect_p asses depends on @llvm-project//mli r:TransformUtils in repository @llvm-project which failed to fetch. no such package '@llvm-project//mlir': java.io.IOException: Error downloading [https://storage.googleapis.com/mir ror.tensorflow.org/github.com/llvm/llvm- project/archive/7e825abd5704ce28b166f9463d4bd304348fd2a9.tar.gz, https://github.com/llvm/llvm-project/archive/7e825abd5704ce28b166f9463d4bd30 4348fd2a9.tar.gz] to /tmp/.cache/bazel/_bazel_lumin/30c7b4fa2330f0b3b6e67535723f3f22/externa l/llvm-project/7e825abd5704ce28b166f9463d4bd304348fd2a9.tar.gz: connect timed out ERROR: /<>/tensorflow/compiler/mlir/tensorflow/BUILD:1249:11: //tensorflow/compiler/mlir/tensorflow:compile_mlir_util_no_tf_dialect_p asses depends on @llvm-project//mli r:Transforms in repository @llvm-project which failed to fetch. no such package '@llvm-project//mlir': java.io.IOException: Error downloading [https://storage.googleapis.com/mirror. tensorflow.org/github.com/llvm/llvm- project/archive/7e825abd5704ce28b166f9463d4bd304348fd2a9.tar.gz, https://github.com/llvm/llvm-project/archive/7e825abd5704ce28b166f9463d4bd304348 fd2a9.tar.gz] to /tmp/.cache/bazel/_bazel_lumin/30c7b4fa2330f0b3b6e67535723f3f22/externa l/llvm-project/7e825abd5704ce28b166f9463d4bd304348fd2a9.tar.gz: connect timed out WARNING: errors encountered while analyzing target '//tensorflow:tensorflow_cc': it will not be built INFO: Analyzed target //tensorflow:tensorflow_cc (186 packages loaded, 10010 targets configured).
Bug#1000336: Upgrading tbb
Hello guys. Finally it's all green on our release architectures https://buildd.debian.org/status/package.php?p=onetbb&suite=experimental I shall request the slot for transition once finished the rebuild of its reverse dependencies and filed FTBFS bugs if any. On Tue, 2022-02-08 at 17:59 -0500, M. Zhou wrote: > Hi Diane, > > Thank you. I have added that patch in the git repository. > > On Tue, 2022-02-08 at 13:49 -0800, Diane Trout wrote: > > Hi, > > > > After Andreas pointed it out I looked through some of the build > > failures for onetbb and talked to upstream about the i386 failure. > > https://github.com/oneapi-src/oneTBB/issues/370#issuecomment-1030387116 > > > > They have a patch. > > https://github.com/oneapi-src/oneTBB/commit/542a27fa1cfafaf76772e793549d9f4d288d03a9 > > > > I've tested it against a checkout of the 2021.5.0-1 version of onetbb > > on i386 and it does build with it applied. Once there was a test > > failure, and once all tests ran successfully > > > > I see that you've made some more progress for the memory alignment > > bugs > > so I didn't commit "Detect 32 bit x86 systems while adding -mwaitpkg > > option" i386 patch but could if you want. > > > > Diane > > > > >
Bug#1000336: Upgrading tbb
Hi, Recently I'm not able to test the build of libtbb-dev's reverse dependencies as my build machine was out of access. That blocks my submission of the transition bug and hence I'm stalled at this point. According to some archlinux developers, this transition breaks a lot of reverse dependencies since some of the core APIs have been changed. Please expect a relatively negative rebuild result. Help is welcome. On Mon, 2022-03-14 at 01:30 +0530, Nilesh Patra wrote: > Hi Mo, > > On 2/23/22 11:01 AM, M. Zhou wrote: > > Hello guys. Finally it's all green on our release architectures > > https://buildd.debian.org/status/package.php?p=onetbb&suite=experimental > > > > I shall request the slot for transition once finished the rebuild > > of its reverse dependencies and filed FTBFS bugs if any. > > Did you get a chance to do this yet? > As we _really_ need numba at this point. > > Regards, > Nilesh > >
Bug#1000336: Upgrading tbb
Hi all, The good news is that I managed to upgrade onetbb. It is in the NEW queue now: https://ftp-master.debian.org/new/onetbb_2021.4.0-1~exp1.html All changes have been pushed onto salsa (master branch). SOVERSION was bumped from 2 to 12 so NEW is inevitable. There are also some non-trivial API changes. So I guess the transition won't be easy. On Wed, 2021-12-29 at 23:27 -0800, Diane Trout wrote: On Thu, 2021-12-23 at 11:03 -0500, M. Zhou wrote: > Hi all, > > I'm back. > > I've just finished my final exams so I could do something during > the holiday. That TBB repository is still work-in-progress and > FTBFS from the master branch is something expected. I will finalize > it soon. Andreas said in previous posts that we prefer a faster > NEW queue process. I understand that but we cannot bypass NEW > process > this time as upstream has bumped the SONAME. So I'm changing the > source name as well following the upstream since NEW is inevitable. > > As for llvmlite, the latest upstream RC release v0.38.0rc1 seems > to support python 3.10 . Should I upload the RC release? > > BTW, what else should I do? I've been out of sync from the mailing > list for a long while. Have you managed to make much progress? I fiddled with the packaging and got it to build and trying to run the autopkgtests with 2021.4.0-1 What'd help me is to have a package I could build locally and test numba against. If you got it working could you commit what you have to a salsa branch and let me know where it is? Thanks, Diane
Bug#1000336: Upgrading tbb
Hi all, I'm back. I've just finished my final exams so I could do something during the holiday. That TBB repository is still work-in-progress and FTBFS from the master branch is something expected. I will finalize it soon. Andreas said in previous posts that we prefer a faster NEW queue process. I understand that but we cannot bypass NEW process this time as upstream has bumped the SONAME. So I'm changing the source name as well following the upstream since NEW is inevitable. As for llvmlite, the latest upstream RC release v0.38.0rc1 seems to support python 3.10 . Should I upload the RC release? BTW, what else should I do? I've been out of sync from the mailing list for a long while. On Thu, 2021-12-23 at 10:58 +0100, Drew Parsons wrote: > On 2021-12-23 10:24, Drew Parsons wrote: > > On 2021-12-23 06:57, Andreas Tille wrote: > > > Hi, > > > > > > Am Wed, Dec 22, 2021 at 05:09:35PM -0800 schrieb Diane Trout: > > > > On Wed, 2021-12-22 at 22:24 +0530, Nilesh Patra wrote: > > > > > > > > > > Actually because of the current state of numba, several > > > > > reverse > > > > > depends are FTBFS so it's > > > > > bit urgent to push. Apologies for getting on your nerves, > > > > > though. > > > > > > > > I tried. but numba needs tbb version >= 2021. I tried to update > > > > tbb > > > > but > > > > ran into problems trying to build it. > > > > > > Diane is testing a python3.10-compatibility branch for us in numba. > > > > At the same time numba upstream has released 0.55.0rc1 which > > contains > > their python3.10 fix. Should we just jump straight to it (and not > > wait for the final 0.55 release)? I don't know how it goes with > > tbb > > though. > > Actually I guess 0.55.0rc1 won't help so easily. It needs llvmlite > 0.38.0rc1, and we've only just got 0.37 packaged. numba is a kind of > ouroboros, can never get to the end of it. > > Drew >
Bug#935290: moar digging
Hi Dominique, Will do it later. BTW, the *.moarvm not found error is related to this: https://github.com/rakudo/rakudo/issues/3093 We can temporarily symlink several directories to wordaround this. On Fri, 13 Sep 2019 at 12:24, Dominique Dumont wrote: > > On Thursday, 12 September 2019 08:33:00 CEST Niels Thykier wrote: > > Does rakudo build with "Rules-Requires-Root: no"[1]? If it does, then > > you can work around the bug / issue in fakeroot for sid, testing and > > stable for now by using it. > > Yes ! I can now build rakudo on my laptop. Thanks for the help :-) > > Mo Zhou, can you follow-up and, if possible, release rakudo on unstable ? > > All the best > > > > -- Best,
Bug#935290: rakudo: FTBFS on amd64
Hi dod,
On Mon, 26 Aug 2019 at 16:45, Dominique Dumont wrote:
>
> On mercredi 21 août 2019 13:08:42 CEST Ivo De Decker wrote:
> > A binnmu of rakudo in unstable fails on amd64:
> >
> > https://buildd.debian.org/status/package.php?p=rakudo
>
> Rakudo fails to build with latest version of libuv1 but it builds fine with
> libuv1 1.24.1-1 (from stable).
>
> I guess that latest version of libuv1 is not 100% backward compatible.
>
> Since rakudo 2019-07 (uploaded in experimental by Mho Zou) builds fine, I
> guess
> we should update rakudo, nqp and moar in unstable to fix this FTBS.
moarvm and nqp (= 2019.07.1) builds fine in experimental. rakudo (2019.07.1)
still stays in the git repo and has not been uploaded yet. I'm somehow
stuck on a strange installation failure (likely permission issue):
'/home/lumin/Debian/perl6/rakudo/perl6-m'
'/home/lumin/Debian/perl6/rakudo/tools/build/upgrade-repository.p6'
'/home/lumin/Debian/perl6/rakudo/debian/rakudo/usr/lib/perl6/core'
'/home/lumin/Debian/perl6/rakudo/perl6-m'
'/home/lumin/Debian/perl6/rakudo/tools/build/upgrade-repository.p6'
'/home/lumin/Debian/perl6/rakudo/debian/rakudo/usr/lib/perl6/vendor'
'/home/lumin/Debian/perl6/rakudo/perl6-m'
'/home/lumin/Debian/perl6/rakudo/tools/build/upgrade-repository.p6'
'/home/lumin/Debian/perl6/rakudo/debian/rakudo/usr/lib/perl6/site'
'/home/lumin/Debian/perl6/rakudo/perl6-m'
'/home/lumin/Debian/perl6/rakudo/tools/build/install-core-dist.p6'
'/home/lumin/Debian/perl6/rakudo/debian/rakudo/usr/lib/perl6/core'
No writeable path found,
/home/lumin/Debian/perl6/rakudo/debian/rakudo/usr/lib/perl6/core not
writeable
in block at
/home/lumin/Debian/perl6/rakudo/tools/build/install-core-dist.p6 line
33
make[2]: *** [Makefile:763: m-install] Error 1
make[2]: Leaving directory '/home/lumin/Debian/perl6/rakudo'
dh_auto_install: make -j1 install
DESTDIR=/home/lumin/Debian/perl6/rakudo/debian/rakudo
AM_UPDATE_INFO_DIR=no returned exit code 2
make[1]: *** [debian/rules:43: override_dh_auto_install] Error 255
make[1]: Leaving directory '/home/lumin/Debian/perl6/rakudo'
make: *** [debian/rules:23: binary] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary subprocess
returned exit status 2
debuild: fatal error at line 1182:
dpkg-buildpackage -us -uc -ui -j5 failed
> Mho Zou, could you upload your work in unstable ?
At the begining I planned to inform the team about uploading
{moarvm,nqp,rakudo} (=2019.07.1)
from experimental to unstable when they are in good shape. We can
proceed when the
build failure (git master) was resolved.
> All the best
>
> Dod
>
>
--
Best,
Bug#935290: rakudo: FTBFS on amd64
On Tue, 27 Aug 2019 at 15:21, Dominique Dumont wrote: > > On Tuesday, 27 August 2019 10:04:23 CEST Dominique Dumont wrote: > > Right.. This is the same error than the one showing in the FTBS issue. > > > > I guess we need to talk to upstream. They may not have seen this issue yet > > if they use an older version of libuv. > > On the other hand, I'm able to build rakudo 2019-07 on my system with latest > libuv1. Have you built it with the root user? The build would pass. Try to switch to a normal user and it would FTBFS. If I build this package with root, the resulting package doesn't work correctly: root@ossbox-lumin ~/D/rakudo# perl6 Unhandled exception: While looking for '/usr/share/perl6/runtime/perl6.moarvm': no such file or directory I'm recently too busy to dig into these issues. > I mean that I've built and installed new moarvm, then built and installed new > nqp. Then rakudo builds fine. Yes, that is the correct order, as implied by the verioned B-Ds. > Mho Zou, can you check on your side if your can build rakudo on your system ? ^ This is a Chinese name and the correct spelling is "Mo Zhou". -- Best,
Bug#1014491: python3-torch: import fails: undefined symbol
Hi, Thanks for the bug report. I'm aware of the break, and other users have reported this issue some time before: https://lists.debian.org/debian-ai/2022/06/msg00060.html The break is due to onnx 1.12 upgrade. The pytorch version in the new queue works fine with onnx 1.12, as mentioned in the above mailing list post. If you would like to continue using pytorch 1.8 for a while, you may need to pin onnx to the previous version, or rollback using our snapshot archive. When dealing with the pytorch 1.12 upgrade, I lost (to be honest I would like to stick to 1.8 but we have to go through python 3.10 transition) access to build machines due to complicated reasons, and the access will not be recovered. So in order to continue the pytorch upgrade, I have to upload reverse dependencies to unstable early, so that I can build pytorch and upload to the NEW queue. Theoretically this bug can only be resolved when pytorch 1.12 passes the new queue. On Wed, 2022-07-06 at 14:01 -0700, Dima Kogan wrote: > Package: python3-torch > Version: 1.8.1-5+b1 > Severity: grave > X-Debbugs-Cc: none, Dima Kogan > > Hi. Thanks for maintaining pytorch. I can't imagine the pain it took to > get this packaged. Currently it doesn't work, unfortunately: > > $ python3 -mtorch > > Traceback (most recent call last): > File "/usr/lib/python3.10/runpy.py", line 187, in _run_module_as_main > mod_name, mod_spec, code = _get_module_details(mod_name, _Error) > File "/usr/lib/python3.10/runpy.py", line 146, in _get_module_details > return _get_module_details(pkg_main_name, error) > File "/usr/lib/python3.10/runpy.py", line 110, in _get_module_details > __import__(pkg_name) > File "/usr/lib/python3/dist-packages/torch/__init__.py", line 196, in > > from torch._C import * > ImportError: /usr/lib/x86_64-linux-gnu/libtorch_cpu.so.1.8: undefined > symbol: > _ZN4onnx12optimization8OptimizeERKNS_10ModelProtoERKSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaISA_EE > > This symbol is missing. I looked around, and I can't figure out which > package was supposed to provide it. Without it the linking fails, and > the package is unusable. Am I missing some dependency? > > > -- System Information: > Debian Release: bookworm/sid > APT prefers unstable > APT policy: (800, 'unstable'), (700, 'testing'), (500, 'unstable-debug'), > (500, 'stable') > Architecture: amd64 (x86_64) > Foreign Architectures: i386, armhf > > Kernel: Linux 5.16.0-5-amd64 (SMP w/4 CPU threads; PREEMPT) > Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE > Locale: LANG=en_US.utf-8, LC_CTYPE=en_US.utf-8 (charmap=UTF-8) (ignored: > LC_ALL set to en_US.utf-8), LANGUAGE=en_US.utf-8 > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages python3-torch depends on: > ii libc6 2.33-7 > ii libdnnl22.6-1 > ii libgcc-s1 12.1.0-4 > ii libgloo00.0~git20220518.5b14351-1 > ii libgoogle-glog0v6 0.6.0-1 > ii libonnx11.12.0-1 > ii libprotobuf23 3.12.4-1+b2 > ii libstdc++6 12.1.0-4 > ii libtorch-test 1.8.1-5+b1 > ii libtorch1.8 1.8.1-5+b1 > ii python3 3.10.4-1+b1 > ii python3-future 0.18.2-5 > ii python3-numpy [python3-numpy-abi9] 1:1.21.5-1 > ii python3-pkg-resources 59.6.0-1 > ii python3-requests2.25.1+dfsg-2 > ii python3-six 1.15.0-2 > ii python3-typing-extensions 3.10.0.2-1 > ii python3-yaml5.4.1-1+b1 > ii python3.10 3.10.5-1 > > Versions of packages python3-torch recommends: > ii build-essential 12.9 > pn libtorch-dev > ii ninja-build 1.10.1-1 > pn pybind11-dev > > Versions of packages python3-torch suggests: > ii python3-hypothesis 5.43.3-1 > ii python3-pytest 6.2.5-1 > > -- no debconf information >
Bug#1011033: onnx: flaky autopkgtest on armhf: Arrays are not almost equal to 7 decimals
Control: severity -1 important I've uploaded 1.12 to unstable. Let's see whether the situation has been changed a little bit for armhf. Floating point precision is sometimes flaky indeed, but I think this would not be that fatal. So changing the severity down to important. If the flaky test no longer appears, I'll close it.
Bug#1000922: reopen
Control: reopen -1 Control: found -1 0.38.1-3 Simply upgrading llvm deps from 11 to 13 leads to regression for numba. I'm reverting this change back until the upstream source code can really support a newer version.
Bug#1011653: blender ftbfs: no matching functional for call to openvdb*
Source: blender Version: 2.83.5+dfsg-5 Severity: serious I found it ftbfs during onetbb reverse dependency test, although the reason irrelevant to onetbb. Version 3.X is still not built for amd64.
Bug#1011657: gazebo ftbfs: missing symbol from libtiff*
Source: gazebo Version: 11.10.2+dfsg-1 Severity: serious I was testing rdeps for onetbb transition but found this issue.
Bug#1011928: trilinos FTBFS: isinf was not defined in this scope
Source: trilinos Version: 13.2.0-1 Severity: serious This is a side-product of a rebuild test against libtbb-dev/experimental ==> CMakeFiles/CMakeError.log <== Performing C++ SOURCE FILE Test FINITE_VALUE_HAVE_GLOBAL_ISNAN failed with the following output: Change Dir: /<>/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp Run Build Command(s):/usr/bin/gmake -f Makefile cmTC_c127c/fast && gmake[2]: Entering directory '/<>/obj- x86_64-linux-gnu/CMakeFiles/CMakeTmp' /usr/bin/gmake -f CMakeFiles/cmTC_c127c.dir/build.make CMakeFiles/cmTC_c127c.dir/build gmake[3]: Entering directory '/<>/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp' Building CXX object CMakeFiles/cmTC_c127c.dir/src.cxx.o /usr/bin/mpicxx -DFINITE_VALUE_HAVE_GLOBAL_ISNAN -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong - Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE= 2 -O3 -DNDEBUG -std=c++14 -o CMakeFiles/cmTC_c127c.dir/src.cxx.o -c /<>/obj-x86_64-linux- gnu/CMakeFiles/CMakeTmp/src.cxx /<>/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/src.cxx: In function ‘int main()’: /<>/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/src.cxx:6:3: error: ‘isnan’ was not declared in this scope; did you mean ‘std::isnan’? 6 | isnan(x); | ^ | std::isnan In file included from /<>/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/src.cxx:2: /usr/include/c++/11/cmath:632:5: note: ‘std::isnan’ declared here 632 | isnan(_Tp __x) | ^ gmake[3]: *** [CMakeFiles/cmTC_c127c.dir/build.make:78: CMakeFiles/cmTC_c127c.dir/src.cxx.o] Error 1 gmake[3]: Leaving directory '/<>/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp' gmake[2]: *** [Makefile:127: cmTC_c127c/fast] Error 2 gmake[2]: Leaving directory '/<>/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp'
Bug#991113: libpam-chroot: pam_chroot.so installed in wrong place - Not able to login after upgrade
Package: libpam-chroot Version: 0.9-5 Followup-For: Bug #991113 X-Debbugs-Cc: maddes+deb...@maddes.net Dear Maintainer, the library pam_chroot.so is installed in the wrong location, therefore it cannot be loaded. This prevents anyone (incl. root) to log into systems that require that module. Changed the pam module to optional via a live linux and found an error message in auth.log: ``` Jun 8 19:30:16 test-debian11 sshd[459]: PAM unable to dlopen(pam_chroot.so): /lib/security/pam_chroot.so: cannot open shared object file: No such file or directory Jun 8 19:30:16 test-debian11 sshd[459]: PAM adding faulty module: pam_chroot.so ``` Current wrong location: `/usr/lib/x86_64-linux-gnu/pam_chroot.so` Correct location: /lib/security/pam_chroot.so -> /usr/lib/x86_64-linux-gnu/security/ Workaround: Boot from a live linux system and move/copy/link file to correct location. `ln -v -s -r -t /usr/lib/x86_64-linux-gnu/security/ /usr/lib/x86_64-linux-gnu/pam_chroot.so` -- System Information: Debian Release: 11.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-14-amd64 (SMP w/1 CPU thread) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libpam-chroot depends on: ii libc6 2.31-13+deb11u3 ii libpam0g 1.4.0-9+deb11u1 libpam-chroot recommends no packages. libpam-chroot suggests no packages. -- no debconf information
Bug#991113: libpam-chroot: pam_chroot.so installed in wrong place - Not able to login after upgrade
I had a look at the package source and only the paths in the file debian/rules [1] have to be changed. Extend all `lib/$(DEB_HOST_MULTIARCH)` to `lib/$(DEB_HOST_MULTIARCH)/security` (added suffix `/security`). [1] https://sources.debian.org/src/libpam-chroot/0.9-5/debian/rules/ Here the changed lines I tested successfully: ``` mkdir -p $(CURDIR)/debian/libpam-chroot/lib/$(DEB_HOST_MULTIARCH)/security # Add here commands to install the package into debian/libpam-chroot $(MAKE) install DESTDIR=$(CURDIR)/debian/libpam-chroot LIBDIR=$(CURDIR)/debian/libpam-chroot/lib/$(DEB_HOST_MULTIARCH)/security INSTALL="install --strip-program=true" ``` Enable source repositories, install build tools and dependencies, then build and install: ``` nano /etc/apt/sources.list apt-get update apt-get install devscripts build-essential cd /var/tmp apt-get build-dep libpam-chroot apt-get source libpam-chroot cd libpam-chroot-0.9*/ sed -i -e 's#lib/\$(DEB_HOST_MULTIARCH)\( \|$\)#lib/\$(DEB_HOST_MULTIARCH\)/security\1#' debian/rules debuild -us -uc # cd /var/tmp dpkg -i libpam-chroot_0.9*.deb ```
Bug#1016283: onetbb: FTBFS: _segment_table.h:63:63: error: member ‘tbb::detail::d1::segment_table, 128>, tbb::detail::d1::cache_aligned_allo
The bug should have been fixed in the -13 upload of src:onetbb The FTBFS occurred because of GCC-11 -> GCC-12 bump. According to upstream suggestion, we can simply turn off some warnings. Please let me know if this bug persists. On Wed, 2022-08-24 at 13:21 -0700, Diane Trout wrote: > On Fri, 2022-08-12 at 13:57 +0200, Lucas Nussbaum wrote: > > On 08/08/22 at 22:45 +0200, Richard B. Kreckel wrote: > > > I am unable to reproduce the above compile-time error. > > > > Hi, > > > > I can still reproduce it. > > > > Lucas > > > > I saw this bug floating around and thought I'd try building tbb as > well. > > The version in git on salsa built for me without issues. Though I was > wondering if maybe the build process behaves differently depending on > the cpu architecture? > > I've run into a few programs that behave differently at compile time > depending on the build cpu. > > > So here's the end of the sbuild run and the start of cat /proc/cpuinfo > on the machine I used. > > > +-- > + > > Summary > > > +-- > + > > Build Architecture: amd64 > Build Type: full > Build-Space: 2839101 > Build-Time: 1683 > Distribution: unstable > Host Architecture: amd64 > Install-Time: 82 > Job: /woldlab/loxcyc/home/diane/src/debian/onetbb_2021.5.0-13.dsc > Lintian: info > Machine Architecture: amd64 > Package: onetbb > Package-Time: 1775 > Source-Version: 2021.5.0-13 > Space: 2839101 > Status: successful > Version: 2021.5.0-13 > --- > - > Finished at 2022-08-24T18:51:48Z > Build needed 00:29:35, 2839101k disk space > diane@trog:~/src/debian/tbb$ cat /proc/cpuinfo > processor : 0 > vendor_id : GenuineIntel > cpu family: 6 > model : 15 > model name: Intel(R) Xeon(R) CPU E5320 @ 1.86GHz > stepping : 7 > microcode : 0x66 > cpu MHz : 1748.216 > cache size: 4096 KB > physical id : 0 > siblings : 4 > core id : 0 > cpu cores : 4 > apicid: 0 > initial apicid: 0 > fpu : yes > fpu_exception : yes > cpuid level : 10 > wp: yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge > mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe syscall > nx lm constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf > pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca lahf_lm > pti tpr_shadow dtherm > vmx flags : tsc_offset vtpr > bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass > l1tf mds swapgs itlb_multihit > bogomips : 3723.91 > clflush size : 64 > cache_alignment : 64 > address sizes : 36 bits physical, 48 bits virtual > power management: >
Bug#1009200: pytorch: (autopkgtest) needs update for python3.10: 'float' object cannot be interpreted as an integer
On Sat, 2022-08-27 at 08:55 +0200, Emanuele Rocca wrote: > On 08/04 09:36, Paul Gevers wrote: > > We are in the transition of making python3.10 the default Python > > versions > > [0]. With a recent upload of python3-defaults the autopkgtest of > > pytorch > > fails in testing when that autopkgtest is run with the binary > > packages of > > python3-defaults from unstable. It passes when run with only > > packages from > > testing. FYI, everything is already fixed in git a couple of months ago, and we are just waiting for the package to go through NEW queue.
Bug#1019098: src:tbb: do not migrate. this source is deprecated in favor of src:onetbb
Source: tbb Version: 2020.3-2.1 Severity: serious src:tbb: do not migrate. this source is deprecated in favor of src:onetbb. The RM bug of src:tbb is filed at https://bugs.debian.org/1014990
Bug#1015805: scikit-learn tries to access network during documentation build
Source: scikit-learn Version: 1.1.1-1 Severity: serious Justification: Policy section 4.9 violation There are loads of similar traceback message saying the documentation build has failed to retrieve some URL, like this: ``` generating gallery for auto_examples/decomposition... [ 30%] plot_faces_decomposition.py WARNING: /<>/examples/decomposition/plot_faces_decomposition.py failed to execute correctly: Traceback (most recent ca ll last): File "/<>/examples/decomposition/plot_faces_decomposition.py", line 36, in faces, _ = fetch_olivetti_faces(return_X_y=True, shuffle=True, random_state=rng) File "/<>/.pybuild/cpython3_3.10/build/sklearn/datasets/_olivetti_faces.py", line 117, in fetch_olivetti_faces mat_path = _fetch_remote(FACES, dirname=data_home) File "/<>/.pybuild/cpython3_3.10/build/sklearn/datasets/_base.py", line 1511, in _fetch_remote urlretrieve(remote.url, file_path) File "/usr/lib/python3.10/urllib/request.py", line 241, in urlretrieve with contextlib.closing(urlopen(url, data)) as fp: File "/usr/lib/python3.10/urllib/request.py", line 216, in urlopen return opener.open(url, data, timeout) File "/usr/lib/python3.10/urllib/request.py", line 519, in open response = self._open(req, data) File "/usr/lib/python3.10/urllib/request.py", line 536, in _open result = self._call_chain(self.handle_open, protocol, protocol + File "/usr/lib/python3.10/urllib/request.py", line 496, in _call_chain result = func(*args) File "/usr/lib/python3.10/urllib/request.py", line 1391, in https_open return self.do_open(http.client.HTTPSConnection, req, File "/usr/lib/python3.10/urllib/request.py", line 1351, in do_open raise URLError(err) urllib.error.URLError: ``` This is clearly policy violation and should be patched. This issue is found during the QEMU build on ppc64el machine for the armel architecture, and it extremly slows down the building process likely due to URL access timeout. As a result, the URL access timeout took the whole night and the doc build is not yet finished by a half. Well, I guess I will have to wait for two or three days to see the discussed armel segfault in qemu with this problem unfixed.
Bug#1003165: scikit-learn testing migration
I have a long-term power 9 VM (not QEMU) as testbed. I'm trying to investigate the issues for release architectures, but this package is too slow to build with QEMU (multiple hours). (abel.debian.org is also extremely slow for scikit-learn) I've not yet given up, but the build speed means I cannot address this issue in timely manner. On Thu, 2022-07-28 at 10:15 +0200, Andreas Tille wrote: > Hi Graham, > > Am Thu, Jul 28, 2022 at 09:15:06AM +0200 schrieb Graham Inggs: > > Hi > > > > On Wed, 27 Jul 2022 at 17:57, M. Zhou wrote: > > > The previous segfault on armel becomes Bus Error on armel and armhf. > > > I can build it on Power9, but it seems that the test fails on power8 (our > > > buildd). > > > > In #1003165, one of the arm porters wrote they are happy to look at > > the bus errors, but the baseline issue should be fixed first. > > ... this was five months ago and silence since then. We've lost lots of > packages in testing and I see no progress here. It seems upstream is not > actually keen on working on this as well. Meanwhile they stepped forward > with new releases and I simply refreshed the issues for the new version > (which are the same and not solved). > > Currently we have bus errors on arm 32 bit architectures and a baseline > violation on power. If there is no solution at the horizon I'd vote for > excluding these three architectures instead of sit and wait (which is all > I can personally do in this topic). > > > > I have skimmed over the build logs and one of the main issues is the use > > > of > > > -march flags to enforce a certain baseline [1]: > > > > > > powerpc64le-linux-gnu-gcc: error: unrecognized command-line option > > > ‘-march=native’; did you mean ‘-mcpu=native’? > > > > This may be the cause of the test failures on power8. > > Could someone give this a try? I know I could use a porter box to do > so but my time is to limited to do it in a sensible time frame. > > Kind regards > > Andreas. >
Bug#991113: libpam-chroot: pam_chroot.so installed in wrong place - Not able to login after upgrade
The pam-chroot source code from Ed Schmollinger is currently at: https://github.com/gpjt/pam-chroot Maybe he is willing to create an GitHub Organization and add you as a developer. Or he even is willing switch to Salsa. Kind regards Matthias "Maddes" Bücher
Bug#1011386: openblas FTBFS due to *combssq deprecated from lapack
Source: openblas Version: 0.3.20+ds-1 Severity: serious Justification: FTBFS According to lapack 3.10.1 release note and upstream pull request 570, xCOMBSSQ has been deprecated. Openblas upstream source has not yet adapted to this change. And thus FTBFS due to missing the following two symbols (fortran ABI): scombssq_ dcombssq_ I think this should be straightforward to fix as long as we remove the two symbols from openblas symbol check.
Bug#1013005: onednn: ftbfs with GCC-12
Control: fixed -1 2.6.1-1
Bug#1025171: zfs-dkms FTBFS against 6.0.0-5-amd64
Package: zfs-dkms Version: 2.1.6-3 Severity: serious It was built againt 6.0.0-3-amd64 on my sid machine, but suddenly stopped working with the recent 6.0.0-5-amd64 kernel.
Bug#1025171: [Pkg-zfsonlinux-devel] Bug#1025171: zfs-dkms FTBFS against 6.0.0-5-amd64
Control: reassign -1 dkms 3.0.8-2 Control: retitle -1 regression: dkms/3.0.8-2 renders zfs-dkms FTBFS Control: severity -1 serious Hi, Thank you for the information! I can confirm that this is the same issue that you have encountered. By commenting out the --environment-overrides, the current zfs-dkms package can be built against 6.0.0-5-amd64 successfully. According to the build log when I filed the bug report, the problem is indeed that the compiler cannot find the header files. I believed it was some -I ... flags missing due to some reason. So it is a regression bug in dkms/3.0.8-2, as -I flags needed for zfs-dkms are accidentally removed. On Wed, 2022-11-30 at 22:56 +, Heikki Kallasjoki wrote: > There isn't enough detail to be sure, but this might be the same issue I > hit on sid yesterday, so adding it here. It might also count as a dkms > bug for all I know. > > In my case, zfs-dkms fails to build against either of my currently > installed kernels (5.19.0-1-amd64, 6.0.0-5-amd64), but only after > updating the package dkms to version 3.0.8-2 (from 3.0.8-1). > > This appears to be the result of the changes to the export-CC.patch: > https://sources.debian.org/patches/dkms/3.0.8-2/export-CC.patch/ > > The 3.0.8-2 version adds the following commands to the prepare_build() > function: > > export CC=$CC > export MAKEFLAGS="--environment-overrides" > > I've verified that zfs-dkms builds fine for me if I temporarily comment > out the second line from /usr/sbin/dkms. > > A build log for a failed attempt (with the flag present) is at: > https://0x0.st/o0fu.txt > > The log also includes a dump of the environment variables at the start > of the build, from a command I added to the dkms script. > > Digging a little deeper, it appears that when `--environment-overrides` > is set, a number of required command-line options (in particular, an -I > option to add /var/lib/dkms/zfs/2.1.6/build/include in the include > search path) fail to be set. I didn't manage to trace why exactly that > is, but you can see both a failing and a working example (for one object > file) at: > https://0x0.st/o0EC.txt > > FWIW, it seems like the build environment dkms uses inherits whatever > was present in the environment when apt was called. If this is the case, > then it feels to me including the `--environment-overrides` flag has > potential to make things brittle. The effect of the flag is to: "Give > variables taken from the environment precedence over variables from > makefiles." Any arbitrary environment variables the user may have set > for their own purposes might be unexpectedly overriding important > variables from the Makefile(s). > > ___ > Pkg-zfsonlinux-devel mailing list > pkg-zfsonlinux-de...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-zfsonlinux-devel
Bug#1025214: was: regression: dkms/3.0.8-2 renders zfs-dkms FTBFS
Control: merge 1025214 1025171 The "MAKEFLAGS="--environment-overrides" also caused zfs-dkms FTBFS. The two bugs above are the same issue, hence the merge.
Bug#1024326: [Pkg-zfsonlinux-devel] Bug#1024326: bullseye to bookworm upgrade failure: Could not locate dkms.conf file
Control: severity -1 important Control: tags -1 +moreinfo I'm still not sure about why the upgrade failed, and I could not reproduce the problem in a clean chroot using the following script: https://salsa.debian.org/zfsonlinux-team/zfs/-/blob/master/debian/tests/sbuild-shell-bullseye-to-bookworm.sh So I'm downgrading the bug's severity to unblock migration. On Thu, 2022-11-17 at 10:31 -0500, Antoine Beaupre wrote: > Package: zfs-dkms > Version: 2.1.6-3 > Severity: serious > > I have tried to upgrade to bookworm today and kernel builds fail on > zfs-dkms. It fails with: > > dkms: running auto installation service for kernel 6.0.0-4- > amd64:Error! Could not locate dkms.conf file. > File: /var/lib/dkms/zfs/2.0.3/source/dkms.conf does not exist. > > It's odd because zfs 2.0.3 is gone now... The package has been > upgraded at this point... Yet the /var/lib/dkms/zfs/2.0.3 directory > was still around. Removing it fixes the problem: > > rm -rf /var/lib/dkms/zfs/2.0.3 > > Note that I am doing batch upgrades with a special procedure, with > this command: > > env DEBIAN_FRONTEND=noninteractive APT_LISTCHANGES_FRONTEND=none > APT_LISTBUGS_FRONTEND=none UCF_FORCE_CONFFOLD=y \ > apt full-upgrade -y -o Dpkg::Options::='--force-confdef' -o > Dpkg::Options::='--force-confold' && > > ... which might have cause the old directory to not be removed. > > See this for my upgrade procedure: > > https://anarc.at/services/upgrades/bookworm/ > > More of the error log: > > Setting up linux-image-6.0.0-4-amd64 (6.0.8-1) ... > /etc/kernel/postinst.d/dkms: > dkms: running auto installation service for kernel 6.0.0-4- > amd64:Error! Could not locate dkms.conf file. > File: /var/lib/dkms/zfs/2.0.3/source/dkms.conf does not exist. > failed! > run-parts: /etc/kernel/postinst.d/dkms exited with return code 4 > dpkg: error processing package linux-image-6.0.0-4-amd64 (-- > configure): > installed linux-image-6.0.0-4-amd64 package post-installation script > subprocess returned error exit status 1 > dpkg: dependency problems prevent configuration of linux-image-amd64: > linux-image-amd64 depends on linux-image-6.0.0-4-amd64 (= 6.0.8-1); > however: > Package linux-image-6.0.0-4-amd64 is not configured yet. > > dpkg: error processing package linux-image-amd64 (--configure): > dependency problems - leaving unconfigured > Setting up linux-headers-6.0.0-4-amd64 (6.0.8-1) ... > /etc/kernel/header_postinst.d/dkms: > dkms: running auto installation service for kernel 6.0.0-4- > amd64:Error! Could not locate dkms.conf file. > File: /var/lib/dkms/zfs/2.0.3/source/dkms.conf does not exist. > failed! > run-parts: /etc/kernel/header_postinst.d/dkms exited with return code > 4 > Failed to process /etc/kernel/header_postinst.d at > /var/lib/dpkg/info/linux-headers-6.0.0-4-amd64.postinst line 11. > dpkg: error processing package linux-headers-6.0.0-4-amd64 (-- > configure): > installed linux-headers-6.0.0-4-amd64 package post-installation > script subprocess returned error exit status 1 > dpkg: dependency problems prevent configuration of linux-headers- > amd64: > linux-headers-amd64 depends on linux-headers-6.0.0-4-amd64 (= 6.0.8- > 1); however: > Package linux-headers-6.0.0-4-amd64 is not configured yet. > > dpkg: error processing package linux-headers-amd64 (--configure): > dependency problems - leaving unconfigured > Errors were encountered while processing: > linux-image-6.0.0-4-amd64 > linux-image-amd64 > linux-headers-6.0.0-4-amd64 > linux-headers-amd64
Bug#889028: minissdpd (1.5.20161216-2) assumes IPV6
Package: minissdpd Version: 1.5.20161216-2 Followup-For: Bug #889028 Dear Maintainer, During dist-upgrade minissdpd failed to install. It seems to try opening an IPV6 socket. -- Error message from apt: Setting up minissdpd (1.5.20161216-2) ... Job for minissdpd.service failed because the control process exited with error code. See "systemctl status minissdpd.service" and "journalctl -xe" for details. invoke-rc.d: initscript minissdpd, action "restart" failed. ● minissdpd.service - keep memory of all UPnP devices that announced themselves Loaded: loaded (/lib/systemd/system/minissdpd.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Sat 2018-02-10 16:29:47 CET; 14ms ago Docs: man:minissdpd(1) Process: 3450 ExecStart=/usr/sbin/minissdpd -i $MiniSSDPd_INTERFACE_ADDRESS $MiniSSDPd_OTHER_OPTIONS (code=exited, status=1/FAILURE) Main PID: 966 (code=exited, status=0/SUCCESS) Feb 10 16:29:47 Bantiger systemd[1]: Starting keep memory of all UPnP devices that announced themselves... Feb 10 16:29:47 Bantiger minissdpd[3450]: socket(udp): Address family not supported by protocol Feb 10 16:29:47 Bantiger minissdpd[3450]: Cannot open socket for receiving SSDP messages (IPv6), exiting Feb 10 16:29:47 Bantiger systemd[1]: minissdpd.service: Control process exited, code=exited status=1 Feb 10 16:29:47 Bantiger minissdpd[3450]: unlink(/var/run/minissdpd.pid): No such file or directory Feb 10 16:29:47 Bantiger systemd[1]: minissdpd.service: Failed with result 'exit-code'. Feb 10 16:29:47 Bantiger systemd[1]: Failed to start keep memory of all UPnP devices that announced themselves. dpkg: error processing package minissdpd (--configure): installed minissdpd package post-installation script subprocess returned error exit status 1 Processing triggers for libc-bin (2.26-4) ... Errors were encountered while processing: minissdpd E: Sub-process /usr/bin/dpkg returned an error code (1) -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8), LANGUAGE=en_US (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages minissdpd depends on: ii libc6 2.26-4 ii libnfnetlink0 1.0.1-3+b1 ii lsb-base 9.20170808 minissdpd recommends no packages. minissdpd suggests no packages. -- no debconf information
Bug#888513: huge graphical bug
Package: debian-installer Version: stable Severity: grave hi maintainer, big graphical bug with the installer netinstall of Debian Stretch 9.3, but also Testing and Sid. Ditto with the installer mini iso-Stretch 9.3 I created my bootable usb drive with "dd", unetbootin, etcher, but the big graphical bug still present :( I have a laptop pc Toshiba Satellite P870-338 with the Optimus technology (graphics chipset intel i7 3630qm and nvidia GT 630m) with a bios 100% uefi this is the screen that I get with the installer, it is impossible to install in these conditions. http://pix.toile-libre.org/upload/original/1516915180.jpg I think I might be an isolated case, but I still haven't found solution to resolve this bug very annoying. the bug has been present since two years... is there a workaround ?? a parameter to pass to the kernel ?? this bug est present on the mini iso, and the iso netinstall (testing, stable and sid). :'( please consider my bug report.
Bug#837786: Possible solution
On Tue, 27 Sep 2016 13:21:58 -0400 Jerome Charaoui wrote: > Le 2016-09-27 à 13:09, Svetlin Zarev a écrit : > > I've fixed the issue on my side by removing CLUTTER_PAINT=disable- > > clipped-redraws:disable-culling from my /etc/environment > > > > I;ve added this property years ago as a solution to tearing in gnome, > > but now it seems to break it. > > This fixed my problem as well, thank you for sharing! > > -- Jerome > I also had the CLUTTER_PAINT line in /etc/environment, as a workaround for the issue described in https://bugzilla.redhat.com/show_bug.cgi?id= 720605 . Just removed it, upgraded mutter and gnome-shell and everything seems to work properly now. I also have "CLUTTER_VBLANK=True", but that one doesn't seem to be causing any issues so far. --John.
Bug#1058532: golang-google-api: FTBFS: tests failed
This is blocking migration https://tracker.debian.org/pkg/golang-golang-x-oauth2 > Migration status for golang-golang-x-oauth2 (0.4.0-1 to 0.15.0-1): BLOCKED: > Rejected/violates migration policy/introduces a regression > Issues preventing migration: > ∙ ∙ autopkgtest for golang-golang-x-oauth2/0.15.0-1: amd64: Pass, arm64: > Pass, armel: Pass, armhf: Pass, i386: Pass, ppc64el: Pass, s390x: Pass > ∙ ∙ autopkgtest for golang-google-api/0.61.0-1: amd64: Regression or new test > ♻ (reference ♻), arm64: Regression or new test ♻ (reference ♻), armel: Failed > (not a regression), armhf: Failed (not a > regression), i386: Failed (not a > regression), ppc64el: Regression or new test ♻ (reference ♻), s390x: > Regression or new test ♻ (reference ♻)
Bug#1058532: golang-google-api: FTBFS: tests failed
The ultimate fix is to update the upstream version (#1059087) but this is blocked on work in four other packages including two new packages. An interim fix would be to backport the upstream fix (patch attached). 0001-ignore-universeDomain.patch Description: Binary data
Bug#1058532: golang-google-api: FTBFS: tests failed
> --- FAIL: TestTokenSource (0.00s)
> panic: cannot handle unexported field at {*google.Credentials}.universeDomain:
> "golang.org/x/oauth2/google".Credentials
This is fixed upstream
https://github.com/googleapis/google-api-go-client/commit/b3a71bda027d9ff92df3bf76b5ee9ffa55520dd9
so hopefully updating the package would fix the problem
Bug#1058657: patch
Control: tags -1 +patch https://salsa.debian.org/apt-team/python-apt/-/merge_requests/90
Bug#1050175: Missing symbol when importing torch
Sorry for the inconvenience. This is a temporary break due to the undergoing pytorch 2.0.1 upgrade work. On Mon, 2023-08-21 at 14:52 +0200, Mattias Ellert wrote: > Package: python3-torch > Version: 1.13.1+dfsg-4 > Severity: serious > > Importing torch results in failure due to missing symbols: > > $ python3 > Python 3.11.4 (main, Jun 7 2023, 10:13:09) [GCC 12.2.0] on linux > Type "help", "copyright", "credits" or "license" for more > information. > > > > import torch > Traceback (most recent call last): > File "", line 1, in > File "/usr/lib/python3/dist-packages/torch/__init__.py", line 218, > in > > from torch._C import * # noqa: F403 > ^^ > ImportError: /lib/x86_64-linux-gnu/libtorch_cpu.so.1.13: undefined > symbol: _ZN4onnx7checker11check_modelERKNS_10ModelProtoE > > > > > > pytorch requires rebuild due to updated libonnx1: > > $ c++filt _ZN4onnx7checker11check_modelERKNS_10ModelProtoE > onnx::checker::check_model(onnx::ModelProto const&) > > $ dpkg-query --show python3-torch libonnx1 > libonnx1:amd641.13.1-1 > python3-torch 1.13.1+dfsg-4 > > Mattias >
Bug#1042252: warning: cannot select font 'C'
If it helps, I opened a pandoc issue about the groff "warning: cannot select font 'C'" https://github.com/jgm/pandoc/issues/9020
Bug#1051271: GRUB2 2.12~rc1-7 prevent machine to boot
Same here. But I have some different conclusions after fixing my machine. Before my machine becoming unable to boot, the last apt log involves Start-Date: 2023-09-05 00:09:00 Commandline: apt upgrade Requested-By: lumin (1000) Upgrade: libimath-3-1-29:amd64 (3.1.9-2, 3.1.9-3), python3-brlapi:amd64 (6.6-2, 6.6-4), libtrilinos-aztecoo-13.2:amd64 (13.2.0-4, 13.2.0-5), libgtk-4-common:amd64 (4.12.1+ds-2, 4.12.1+ds-3), xbrlapi:amd64 (6.6-2, 6.6-4), libldb2:amd64 (2:2.7.2+samba4.18.6+dfsg-1, 2:2.8.0+samba4.19.0+dfsg-1), libwayland-cursor0:amd64 (1.22.0-2, 1.22.0-2.1), libbrlapi0.8:amd64 (6.6-2, 6.6-4), libtrilinos-ml- 13.2:amd64 (13.2.0-4, 13.2.0-5), libwayland-server0:amd64 (1.22.0-2, 1.22.0-2.1), libtrilinos-epetraext-13.2:amd64 (13.2.0-4, 13.2.0-5), dvisvgm:amd64 (3.1-1, 3.1.1+ds-1), libtrilinos-ifpack-13.2:amd64 (13.2.0-4, 13.2.0-5), libsuperlu6:amd64 (6.0.0+dfsg1-3, 6.0.1+dfsg1-1), libtrilinos-trilinosss-13.2:amd64 (13.2.0-4, 13.2.0-5), libtrilinos- kokkos-13.2:amd64 (13.2.0-4, 13.2.0-5), libwbclient0:amd64 (2:4.18.6+dfsg-1, 2:4.19.0+dfsg-1), libtrilinos-amesos-13.2:amd64 (13.2.0-4, 13.2.0-5), libsmbclient:amd64 (2:4.18.6+dfsg-1, 2:4.19.0+dfsg-1), gir1.2-gtk-4.0:amd64 (4.12.1+ds-2, 4.12.1+ds-3), grub-efi-amd64:amd64 (2.06-13, 2.12~rc1-7), gir1.2-accountsservice- 1.0:amd64 (23.13.9-3, 23.13.9-4), libnet-http-perl:amd64 (6.22-1, 6.23- 1), libtrilinos-epetra-13.2:amd64 (13.2.0-4, 13.2.0-5), libtrilinos- teuchos-13.2:amd64 (13.2.0-4, 13.2.0-5), libscotch-7.0:amd64 (7.0.3-2, 7.0.4-1), libtrilinos-zoltan-13.2:amd64 (13.2.0-4, 13.2.0-5), libunbound8:amd64 (1.17.1-2, 1.18.0-1), libtrilinos-galeri-13.2:amd64 (13.2.0-4, 13.2.0-5), grub-efi-amd64-bin:amd64 (2.06-13, 2.12~rc1-7), grub2-common:amd64 (2.06-13, 2.12~rc1-7), libwayland-egl1:amd64 (1.22.0-2, 1.22.0-2.1), libtrilinos-triutils-13.2:amd64 (13.2.0-4, 13.2.0-5), fonts-noto-cjk:amd64 (1:20230817+repack1-1, 1:20230817+repack1-3), grub-common:amd64 (2.06-13, 2.12~rc1-7), libgtk- 4-1:amd64 (4.12.1+ds-2, 4.12.1+ds-3), accountsservice:amd64 (23.13.9-3, 23.13.9-4), samba-libs:amd64 (2:4.18.6+dfsg-1, 2:4.19.0+dfsg-1), libptscotch-7.0:amd64 (7.0.3-2, 7.0.4-1), libgtk-4-bin:amd64 (4.12.1+ds-2, 4.12.1+ds-3), libgtk-4-media-gstreamer:amd64 (4.12.1+ds- 2, 4.12.1+ds-3), libwayland-client0:amd64 (1.22.0-2, 1.22.0-2.1), libaccountsservice0:amd64 (23.13.9-3, 23.13.9-4) End-Date: 2023-09-05 00:09:25 The machine does not boot since here. Then I wanted to reinstall grub without noticing that the package to install is no longer grub2 in the EFI era. Ignore this change. Start-Date: 2023-09-05 10:34:44 Commandline: apt install grub2 Install: grub2:amd64 (2.12~rc1-7), grub-pc-bin:amd64 (2.12~rc1-7, automatic), grub-pc:amd64 (2.12~rc1-7, automatic) Remove: grub-efi-amd64:amd64 (2.12~rc1-7) End-Date: 2023-09-05 10:34:47 I have tried some other ways to fix the boot, including rolling back grub to the testing version. But after that I noticed that the most important package grub-efi-amd64-signed:amd64 (1+2.06+13, 1+2.12~rc1+7) was not upgraded along with the other grub packages. Start-Date: 2023-09-05 10:48:36 Commandline: apt upgrade Requested-By: lumin (1000) Upgrade: evince:amd64 (45~alpha-2, 45~rc-1), libnghttp2-14:amd64 (1.55.1-1, 1.56.0-1), eog:amd64 (45~alpha-1, 45~rc-1), libevdocument3- 4:amd64 (45~alpha-2, 45~rc-1), libeatmydata1:amd64 (130-2+b1, 131-1), libevview3-3:amd64 (45~alpha-2, 45~rc-1), evince-common:amd64 (45~alpha-2, 45~rc-1), grub-efi-amd64-signed:amd64 (1+2.06+13, 1+2.12~rc1+7), gir1.2-evince-3.0:amd64 (45~alpha-2, 45~rc-1), eatmydata:amd64 (130-2, 131-1), libucx0:amd64 (1.15.0~rc3-1, 1.15.0~rc4-1) End-Date: 2023-09-05 10:48:43 After this, I removed all the extra config files I wrote in order to fix the boost. Then I did yet another clean grub install update-initramfs -k all -u update-grub2 Then reboot is successful with 1+2.12~rc1+7 . So my conclusion is that there might be something wrong in the Depends: sections of some of the grub2 packages, which did not specify versioned dependency to express incompatibility. I believe the maintainers have fully tested the grub loader before pushing it to unstable. But unfortunately, the asynchronized mirror update, resulted into partial upgrade of grub2 at the user end, which eventually affected a large amount of users. If it was a issue in the Depends field, it is still a critical bug which may damage user system, even if the trigger is partial upgrade due to mirror sync.
Bug#1051271: GRUB2 2.12~rc1-7 prevent machine to boot
On Tue, 5 Sep 2023 18:11:55 +0200 "Miguel A. Vallejo" wrote: > M. Zhou wrote: > > > But after that I noticed that the most important > > package grub-efi-amd64-signed:amd64 (1+2.06+13, > > 1+2.12~rc1+7) was not upgraded along with the other > > grub packages. > > You are right. I revised apt log and grub-efi-amd64-signed was NOT > updated, in fact, the version I have installed now is 1+2.06+13, but > all other grub packages have 2.06-3~deb11u5. > > Now, if I run apt update, and apt list --upgradable it shows: > > grub-common/unstable 2.12~rc1-7 amd64 [upgradable from: 2.06- 3~deb11u5] > grub-efi-amd64-bin/unstable 2.12~rc1-7 amd64 [upgradable from: 2.06- 3~deb11u5] > grub-efi-amd64-signed/unstable 1+2.12~rc1+7 amd64 [upgradable from: 1+2.06+13] > grub-efi-amd64/unstable 2.12~rc1-7 amd64 [upgradable from: 2.06- 3~deb11u5] > grub2-common/unstable 2.12~rc1-7 amd64 [upgradable from: 2.06- 3~deb11u5] > > > All of them with version 2.12~rc1-7 > > Is it safe to upgrade now? I'll wait a bit until I hear from the > package maintainers. I am able to boot with 2.12~rc1-7 now. And my currrent status is grub-common/unstable,now 2.12~rc1-7 amd64 [installed] grub-efi-amd64-bin/unstable,now 2.12~rc1-7 amd64 [installed,automatic] grub-efi-amd64-signed/unstable,now 1+2.12~rc1+7 amd64 [installed,automatic] grub-efi-amd64/unstable,now 2.12~rc1-7 amd64 [installed,automatic] grub2-common/unstable,now 2.12~rc1-7 amd64 [installed,automatic] I reinstalled grub using 2.12~rc1-7. But I still cannot guarantee it is safe to upgrade. I believe the issue is the missing versioned dependency, which allowed partial upgrade. If you check the testing, you will find that grub-efi-amd64-signed/1+2.06+13 Depends: grub-common (>= 2.06-13) Then, if we upgrade grub-common to 2.12~rc1-7, without upgrading grub-efi-amd64-signed itself, then the boot is broken. TLDR: the boot is broken with the following partial upgrade: grub-common/2.12~rc1-7 grub-efi-amd64-signed/2.06+13 A possible fix might be specifying Depends: grub-common (>= 2.12~rc1-7)), grub-common (<= 2.13~) to prevent incompatible grub-common and grub-efi-amd64-signed from co-existing. Although it does not help this time.
Bug#1043124: [Pkg-zfsonlinux-devel] Bug#1043124: consider skipping trying to build on affected kernels?
On Sun, 2023-09-17 at 14:12 +0200, Ari wrote: > Have you, maintainers of zfs, considered configuring the packages so > that it skips trying to build of affected kernels? > This would at least reduce the time of installing any packages > drastically - currently my system tries to build it for two kernels > every time I install any package, because the kernel packages fail > the configuration stage. > Maybe with this approach it would be even feasible that the kernels' > installation state would not be failed for which compilation failed? > After all, the kernel installed correctly, but it's rather the zfs > package that is broken. While it indeed increases the speed of dpkg configuration steps, skipping the build or silently leave the kernel installation without failure is seriously wrong for many use cases, I believe.
Bug#1041230: onetbb 2021.9.0-1 FTBFS on multiple release architectures
The issue still exists with armel: https://buildd.debian.org/status/package.php?p=onetbb On Wed, 2023-08-02 at 22:46 +0200, Petter Reinholdtsen wrote: > [M. Zhou] > > I'm aware of this issue. I'm slightly faster than buildd for > > toolchain > > upgrades. The issue will automatically disappear once our amd64 > > buildd > > migrates to gcc-13. The gcc-12 will lead to the FTBFS you see now. > > Is this still an issue?
Bug#1041230: onetbb 2021.9.0-1 FTBFS on multiple release architectures
Control: fixed -1 2021.9.0-2 I agree. On Thu, 2023-08-03 at 00:32 +0200, Petter Reinholdtsen wrote: > [M. Zhou] > > The issue still exists with armel: > > https://buildd.debian.org/status/package.php?p=onetbb > > If so, this is a duplicate of > https://bugs.debian.org/1042009 >, which is about the armel > issue, > and should be closed. >
Bug#368546: More info is needed
On Sun, Jun 18, 2006 at 02:52:59PM -0500, Luis Rodrigo Gallardo Cruz wrote: > As far as I can tell, this bug has not affected anyone else, nor has > it been reproducible. Do you have any information that could help track it > down? > > If you don't provide more info, in one month, I will downgrade this bug to > normal, and close it two months from then. > i just noticed thread about sawfish. i'm sorry about the trouble so i suggest to downgrade immediatly because nobody else had the problem. also i would like to ask you for hints how to get more information about this. i am a developer myself and am quit shure that sawfish has a memory lea under some circumstances i use here. problem is, that this 'memory leak' seams to be somewhere else but in the main memory because i didn't see any significant grow of process memory. could the problem be in video-memory usage? how can i debug that? do you have any suggestions here? best regards, michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#340562: Unable to install gnucash from unstable on amd64.
Package: gnucash Severity: grave Justification: renders package unusable Trying to install gnucash, from the latest unstable on http://debian.csail.mit.edu/debian-amd64/debian/. apt-get fails with two dependencies, slib and guile-1.6. Installing one of them causes the other one to be uninstalled. A transcript from installation attempt follows: nakatomi:~# apt-get update Get:1 http://debian.csail.mit.edu unstable Release.gpg [189B] Hit http://debian.csail.mit.edu unstable Release Ign http://debian.csail.mit.edu unstable Release Hit http://debian.csail.mit.edu unstable/main Packages Hit http://debian.csail.mit.edu unstable/contrib Packages Hit http://debian.csail.mit.edu unstable/non-free Packages Fetched 189B in 1s (151B/s) Reading package lists... Done W: GPG error: http://debian.csail.mit.edu unstable Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY E415B2B4B5F5BBED W: You may want to run apt-get update to correct these problems --- nakatomi:~# apt-get install gnucash Reading package lists... Done Building dependency tree... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. Since you only requested a single operation it is extremely likely that the package is simply not installable and a bug report against that package should be filed. The following information may help to resolve the situation: The following packages have unmet dependencies: gnucash: Depends: slib (>= 3a1-2) but it is not going to be installed Depends: guile-1.6-slib but it is not going to be installed E: Broken packages --- nakatomi:~# apt-cache show slib Package: slib Priority: optional Section: devel Installed-Size: 3808 Maintainer: Thomas Bushnell, BSG <[EMAIL PROTECTED]> Architecture: all Version: 3a2-2 Conflicts: libguile9 (<= 1:1.4-26), guile-1.6-libs (<= 1.6.7-1.1) Filename: pool/main/s/slib/slib_3a2-2_all.deb Size: 840504 MD5sum: ca4730d83681e0ab7f48ada96ba27e2a Description: Portable Scheme library SLIB is a portable scheme library meant to provide compatibility and utility functions for all standard scheme implementations. SLIB includes initialization files for Chez, ELK 2.1, GAMBIT, MacScheme, MITScheme, scheme->C, Scheme48, T3.1, and VSCM. SCM also supports SLIB. Tag: devel::library, langdevel::scheme, made-of::lang:scheme, role::content:data --- nakatomi:~# apt-get install guile-1.6 Reading package lists... Done Building dependency tree... Done The following extra packages will be installed: guile-1.6-libs Suggested packages: guile-1.6-doc The following packages will be REMOVED: slib The following NEW packages will be installed: guile-1.6 guile-1.6-libs 0 upgraded, 2 newly installed, 1 to remove and 223 not upgraded. Need to get 31.7kB/639kB of archives. After unpacking 1286kB disk space will be freed. Please let me know if more information is required. -d -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-amd64-generic Locale: LANG=en_CA, LC_CTYPE=en_CA (charmap=ISO-8859-1)
Bug#343583: kernel-source-2.4.27: kernel-source and kernel-image version out of sync for Sparc
Package: kernel-source-2.4.27 Version: 2.4.27-10sarge1 Severity: serious Justification: no longer builds from source -- System Information: Debian Release: 3.1 Architecture: sparc (sparc64) Kernel: Linux 2.4.27-2-sparc64 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Hello, When attempting to make some small modifications to the Sparc kernel, in general, one runs into problems making it, because the version of the available source code does not match the available image version. Installed image and source via dselect: kernel-image-2.4.27-2-sparc64_2.4.27-9sarge1_sparc.deb kernel-source-2.4.27_2.4.27-10sarge1_all.deb I could not find matching pairs of them using in ftp.debian.org either. Challanged though, I've first made a kernel image using the config-2.4.27 file which was placed in /boot (during install of Sarge, it's now put there, which is ok!). I compiled like explained in http://www.debian.org/releases/stable/sparc/ch08s04.html.en. After dpkg -i, It showed my kernel and the original kernel differed. I found out the config files of the source (in /usr/src/kernel-source-2.4.27/arch/sparc64) and image (in /boot) differed. Apart from that, I think the source code itself is different too, at least the version numbers differ... I did not succeed running this kernel by the way, because system halted after rebooting (Kernel panic: VFS: Unable to mount root fs on 03:01), but that's a problem to be posted somewhere else. Solution for the image/source version difference would be to synchronize the two. It's an easy fix, and I think a lot of users would benefit from. Thanks! Maarten -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#358840: gnumail.app: GNUmail crashes X server
Package: gnumail.app Version: 1.1.2-5 Severity: grave Justification: renders package unusable Hello, I'm an Etch user and wanted to give GNUmail a try. According to the user's guide and the screenshots it is a nice full featured MUA. I aptituded it, opened a terminal window (under xfce) and typed "GNUMail". It crashed my X session : all the apps were crashed and I was back to xdm login screen. I've never seen such a crash before. It said : XIO: fatal IO error 104 on X server ":0.0" after 227 requests (224 known processed) with 91 events remaining. OK, I known, I should run GNUstep or so, right ? But I run Balsa under xfce without Gnome, so why not GNUMail under xfce without GNUstep ? BTW I'm a supporter of the Maildir mailbox format and that is why I use Balsa and want to try GNUMail : v1.2 should support it. PM, aka "Joe User" :-) -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686 Locale: [EMAIL PROTECTED], LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Versions of packages gnumail.app depends on: ii addresses.framework 0.4.6-4Database API backend framework for ii addressmanager.app0.4.6-4Personal Address Manager for GNUst ii addressview.framework 0.4.6-4Display/edit framework for GNUstep ii gnustep-back 0.9.5-1.1 The GNUstep GUI Backend ii libc6 2.3.6-3GNU C Library: Shared libraries an ii libgnustep-base1.10 1.10.3-2 GNUstep Base library ii libgnustep-gui0.9 0.9.5-2GNUstep Gui Library ii libobjc1 1:4.0.3-1 Runtime library for GNU Objective- ii pantomime11.1.2-3Objective-C library for mail handl gnumail.app recommends no packages. -- no debconf information ___ Nouveau : téléphonez moins cher avec Yahoo! Messenger. Appelez le monde entier à partir de 0,012 /minute ! Téléchargez sur http://fr.messenger.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#358840: gnumail.app: Good news : the bug has vanished.
Package: gnumail.app Version: 1.1.2-5 Followup-For: Bug #358840 Hello Yavor and Hubert, before submitting the bug, I easily reproduced it 4 times in a row. But today it is unreproducible and I feel stupid ;) I'm sorry for this useless bug report which can be closed. As I try to update my Etch system frequently, may be a library has changed since last week. Nevermind, now GNUMail launches (under xfce, cool). Thank you for being responsive to a user report. Happy Debianing to v1.2 ! PM -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686 Locale: [EMAIL PROTECTED], LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Versions of packages gnumail.app depends on: ii addresses.framework 0.4.6-4Database API backend framework for ii addressmanager.app0.4.6-4Personal Address Manager for GNUst ii addressview.framework 0.4.6-4Display/edit framework for GNUstep ii gnustep-back 0.9.5-1.1 The GNUstep GUI Backend ii libc6 2.3.6-3GNU C Library: Shared libraries an ii libgnustep-base1.10 1.10.3-2 GNUstep Base library ii libgnustep-gui0.9 0.9.5-2GNUstep Gui Library ii libobjc1 1:4.0.3-1 Runtime library for GNU Objective- ii pantomime11.1.2-3Objective-C library for mail handl gnumail.app recommends no packages. -- no debconf information ___ Nouveau : téléphonez moins cher avec Yahoo! Messenger. Appelez le monde entier à partir de 0,012 /minute ! Téléchargez sur http://fr.messenger.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#361254: python-pysqlite2: does not work with current libsqlite3-0
Package: python-pysqlite2
Version: 2.0.5-1
Severity: grave
Justification: renders package unusable
i encounter the error
pysqlite2.dbapi2.Warning: You can only execute one statement at a time.
with version 3.3.5-0.1 of libsqlite3-0.
libsqlite3-0 3.2.8-1 works fine. an example program is
from pysqlite2 import dbapi2 as sqlite
conn = sqlite.connect('.gajim/logs.db', timeout = 20.0,isolation_level =
'IMMEDIATE')
cur = conn.cursor()
cur.execute('SELECT jid FROM jids')
(i found the problem while using gajim and tracked it down until here)
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-1-686
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)
Versions of packages python-pysqlite2 depends on:
pi python2.3.5-5An interactive high-level object-o
ii python2.3-pysqlite2 2.0.5-1python interface to SQLite 3
python-pysqlite2 recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#361236: see libsqlite3-0 bug
if you downgrade libsqlite3-0 gajim will work again. you can get it from http://snapshot.debian.net/archive/2006/01/05/debian/pool/main/s/sqlite3/libsqlite3-0_3.2.8-1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#361507: python2.4-pysqlite1.1: hangs on execute()
Package: python2.4-pysqlite1.1
Version: 1.1.6-2
Severity: grave
Justification: renders package unusable
this may be related to Bug#361254, 361066 and 361097. if using the
following program:
import sqlite
con = sqlite.connect('data.db')
res = con.cursor().execute('SELECT * FROM data')
the program hangs in execute() with high system load. this does happen
with libsqlite3-0_3.3.5-0.1 but not with libsqlite3-0_3.2.8-1.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-1-686
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)
Versions of packages python2.4-pysqlite1.1 depends on:
ii libc6 2.3.6-5GNU C Library: Shared libraries an
ii libsqlite3-0 3.2.8-1SQLite 3 shared library
ii python2.4 2.4.3-1An interactive high-level object-o
Versions of packages python2.4-pysqlite1.1 recommends:
pn python-egenix-mxdatetime (no description available)
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#361507: python2.4-pysqlite1.1: hangs on execute()
hi joel, On Sat, Apr 08, 2006 at 10:25:32PM +0200, Joel Rosdahl wrote: ... > I just uploaded python-pysqlite1.1_1.1.7-1. Please let me know whether > the new version fixes the problem. thnx for the fix! yes, it solves the problem. best regards, michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#355541: gossip: I think this bug should be closed
Package: gossip Version: 0.9-1 Followup-For: Bug #355541 Hello, I agree with Emmanuel, passwords should not be world readable. Emmanuel reported this bug against 0.10.1 and it has been forwarded upstream. Upstream said it is fixed in 0.10.2 which seems to be already in unstable. So I think this bug should be closed so 0.10.2 can enter Etch/testing. PM -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686 Locale: [EMAIL PROTECTED], LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Versions of packages gossip depends on: ii gconf2 2.14.0-1GNOME configuration database syste ii libc62.3.6-7 GNU C Library: Shared libraries ii libgconf2-4 2.14.0-1GNOME configuration database syste ii libglade2-0 1:2.5.1-2 library to load .glade files at ru ii libglib2.0-0 2.10.2-1The GLib library of C routines ii libgnome2-0 2.14.0-2The GNOME 2 library - runtime file ii libgnomeui-0 2.14.0-1The GNOME 2 libraries (User Interf ii libgnomevfs2-0 2.14.0-2GNOME virtual file-system (runtime ii libgtk2.0-0 2.8.16-1The GTK+ graphical user interface ii libloudmouth1-0 1.0.1-4 Lightweight C Jabber library ii libpango1.0-01.12.0-2Layout and rendering of internatio ii libpopt0 1.7-5 lib for parsing cmdline parameters ii libx11-6 6.9.0.dfsg.1-6 X Window System protocol client li ii libxml2 2.6.23.dfsg.2-3 GNOME XML library ii libxslt1.1 1.1.15-5XSLT processing library - runtime ii libxss1 6.9.0.dfsg.1-6 X Screen Saver client-side library ii xlibs6.9.0.dfsg.1-6 X Window System client libraries m gossip recommends no packages. -- no debconf information ___ Faites de Yahoo! votre page d'accueil sur le web pour retrouver directement vos services préférés : vérifiez vos nouveaux mails, lancez vos recherches et suivez l'actualité en temps réel. Rendezvous sur http://fr.yahoo.com/set -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#352863: vnc4server: terminates with error: 'select: Invalid argument (22)'
Package: vnc4server
Version: 4.1.1+X4.3.0-1
Severity: grave
Justification: renders package unusable
when trying to start x0vncserver or x0vnc4server i get:
Tue Feb 14 15:08:09 2006
main:XTest extension present - version 2.2
main:Listening on port 5900
main:select: Invalid argument (22)
~ImageCleanup called
using strace the select call shown looks like:
select(1024, [3 4], NULL, NULL, {3086070392, 3217232984}) = -1 EINVAL
(Invalid argument)
the timeval for select contains really strange values...
in this bugreport i saw version vnc-common is 3.x. i updated all to 4
with the same result for x0vnc4server.
-- System Information:
Debian Release: testing/unstable
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15-1-686
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)
Versions of packages vnc4server depends on:
ii libc6 2.3.6-1GNU C Library: Shared libraries an
ii libgcc1 1:4.0.2-9 GCC support library
ii libstdc++64.0.2-9The GNU Standard C++ Library v3
ii libx11-6 6.9.0.dfsg.1-4 X Window System protocol client li
ii libxext6 6.9.0.dfsg.1-4 X Window System miscellaneous exte
ii libxtst6 6.9.0.dfsg.1-4 X Window System event recording an
ii vnc-common3.3.7-8Virtual network computing server s
ii xbase-clients 6.9.0.dfsg.1-4 miscellaneous X clients
ii xserver-common6.9.0.dfsg.1-4 files and utilities common to all
ii zlib1g1:1.2.3-9 compression library - runtime
Versions of packages vnc4server recommends:
ii xfonts-base 6.9.0.dfsg.1-4 standard fonts for X
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#306822: nvu: time to re-enter Etch ?
Package: nvu Version: 1.0-1 Followup-For: Bug #306822 Hello, shouldn't 306822 be reclosed ? According to p.qa.d.org/n/nvu.html there is no more mips/mipsel problem. That would be cool to have this wysiwyg tool in Etch. Isn't it time to reclose that RC bug so that Nvu can enter Etch ? Thanks to all debdevs. PM, Etch user -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686 Locale: [EMAIL PROTECTED], LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Versions of packages nvu depends on: ii libatk1.0-0 1.10.3-1 The ATK accessibility toolkit ii libbonobo2-0 2.10.1-1 Bonobo CORBA interfaces library ii libc6 2.3.6-3GNU C Library: Shared libraries an ii libfontconfig12.3.2-1.1 generic font configuration library ii libfreetype6 2.1.10-1 FreeType 2 font engine, shared lib ii libgcc1 1:4.0.3-1 GCC support library ii libgconf2-4 2.12.1-12 GNOME configuration database syste ii libglib2.0-0 2.8.6-1The GLib library of C routines ii libgnome2-0 2.12.0.1-5 The GNOME 2 library - runtime file ii libgnomevfs2-02.12.2-5 GNOME virtual file-system (runtime ii libgtk2.0-0 2.8.13-1 The GTK+ graphical user interface ii libidl0 0.8.5-1library for parsing CORBA IDL file ii liborbit2 1:2.12.4-1 libraries for ORBit2 - a CORBA ORB ii libpango1.0-0 1.10.4-1 Layout and rendering of internatio ii libpopt0 1.7-5 lib for parsing cmdline parameters ii libstdc++64.0.3-1The GNU Standard C++ Library v3 ii libx11-6 6.9.0.dfsg.1-4 X Window System protocol client li ii libxext6 6.9.0.dfsg.1-4 X Window System miscellaneous exte ii libxft2 2.1.8.2-3 FreeType-based font drawing librar ii libxp66.9.0.dfsg.1-4 X Window System printing extension ii libxrender1 1:0.9.0.2-1X Rendering Extension client libra ii libxt66.9.0.dfsg.1-4 X Toolkit Intrinsics ii xlibs 6.9.0.dfsg.1-4 X Window System client libraries m ii zlib1g1:1.2.3-9 compression library - runtime Versions of packages nvu recommends: pn myspell-dictionary (no description available) -- no debconf information ___ Nouveau : téléphonez moins cher avec Yahoo! Messenger. Appelez le monde entier à partir de 0,012 /minute ! Téléchargez sur http://fr.messenger.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328225: grubconf destroys menu.lst
Package: grubconf Version: 0.5.1-4 Severity: critical Justification: breaks the whole system i checked grubconf today. after playing around i pressed 'Revert' and after that i choose 'close'. the dialog did not close. so i pressed the close-button of the windowmanager. the dialog stayed (i waited several seconds after each buttonpress) after that i stopped the program by pressing ^C on the console where i started it. after that i ended up with two empty files: menu.lst and menu.lst~ with size 0. i did not recognize that, rebooted and had to type in the commands by hand :( -- System Information: Debian Release: testing/unstable Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages grubconf depends on: ii grub 0.95+cvs20040624-17 GRand Unified Bootloader ii libart-2.0-2 2.3.17-1Library of functions for 2D graphi ii libatk1.0-0 1.10.1-2The ATK accessibility toolkit ii libaudiofile00.2.6-6 Open-source version of SGI's audio ii libbonobo2-0 2.10.0-1Bonobo CORBA interfaces library ii libbonoboui2-0 2.10.0-1The Bonobo UI library ii libc62.3.5-6 GNU C Library: Shared libraries an ii libesd-alsa0 [libesd 0.2.36-1Enlightened Sound Daemon (ALSA) - ii libgconf2-4 2.10.1-2GNOME configuration database syste ii libgcrypt11 1.2.1-4 LGPL Crypto library - runtime libr ii libglib2.0-0 2.8.0-1 The GLib library of C routines ii libgnome-keyring00.4.3-2 GNOME keyring services library ii libgnome2-0 2.10.1-1The GNOME 2 library - runtime file ii libgnomecanvas2-02.10.2-2A powerful object-oriented display ii libgnomeui-0 2.10.1-1The GNOME 2 libraries (User Interf ii libgnomevfs2-0 2.10.1-5The GNOME virtual file-system libr ii libgnutls11 1.0.16-13.1 GNU TLS library - runtime library ii libgpg-error01.1-4 library for common error values an ii libgtk2.0-0 2.6.10-1The GTK+ graphical user interface ii libice6 6.8.2.dfsg.1-7 Inter-Client Exchange library ii libjpeg626b-10 The Independent JPEG Group's JPEG ii liborbit21:2.12.2-3 libraries for ORBit2 - a CORBA ORB ii libpango1.0-01.8.2-1 Layout and rendering of internatio ii libpopt0 1.7-5 lib for parsing cmdline parameters ii libsm6 6.8.2.dfsg.1-7 X Window System Session Management ii libtasn1-2 0.2.13-1Manage ASN.1 structures (runtime) ii libx11-6 6.8.2.dfsg.1-7 X Window System protocol client li ii libxml2 2.6.21-1GNOME XML library ii xlibs6.8.2.dfsg.1-7 X Window System client libraries m ii zlib1g 1:1.2.3-4 compression library - runtime grubconf recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#319509: python2.4-psycopg: simple solution
Package: python2.4-psycopg Version: 1.1.19-1 Followup-For: Bug #319509 i solved the problem today for me: the file debian/python2.4-psycopg.dirs is missing, it must contain the line usr/lib/python2.4/site-packages -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages python2.4-psycopg depends on: ii libc6 2.3.5-7GNU C Library: Shared libraries an ii libpq48.0.4-1PostgreSQL C client library ii python2.4 2.4.2-1An interactive high-level object-o ii python2.4-egenix-mxdatetime 2.0.6-2date and time handling routines fo python2.4-psycopg recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#303687: Dumps core on start
Package: gnucash
Version: 1.8.10-11
Severity: grave
gnucash dumps core on startup after the latest update.
open("/home/adamm/.gconfd/lock/ior", O_RDONLY) = -1 ENOENT (No such file
or directory)
open("/usr/share/locale/en_CA.UTF-8/LC_MESSAGES/gconf1.mo", O_RDONLY) =
-1 ENOENT (No such file or directory)
open("/usr/share/locale/en_CA.utf8/LC_MESSAGES/gconf1.mo", O_RDONLY) =
-1 ENOENT (No such file or directory)
open("/usr/share/locale/en_CA/LC_MESSAGES/gconf1.mo", O_RDONLY) = -1
ENOENT (No such file or directory)
open("/usr/share/locale/en.UTF-8/LC_MESSAGES/gconf1.mo", O_RDONLY) = -1
ENOENT (No such file or directory)
open("/usr/share/locale/en.utf8/LC_MESSAGES/gconf1.mo", O_RDONLY) = -1
ENOENT (No such file or directory)
open("/usr/share/locale/en/LC_MESSAGES/gconf1.mo", O_RDONLY) = -1 ENOENT
(No such file or directory)
close(10) = 0
close(11) = 0
write(2, "\n", 1
) = 1
write(2, "gtkhtml", 7gtkhtml) = 7
write(2, "-", 1-)= 1
write(2, "ERROR **: ", 10ERROR **: ) = 10
write(2, "gconf error: Failed to contact c"..., 276gconf error: Failed
to contact configuration server (a likely cause of this is that you have
an existing configuration server (gconfd) running, but it isn't
reachable from here - if you're logged in from two machines at once, you
may need to enable TCP networking for ORBit)
) = 276
write(2, "\naborting...\n", 13
aborting...
) = 13
rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
tgkill(14241, 14241, SIGABRT) = 0
--- SIGABRT (Aborted) @ 0 (0) ---
+++ killed by SIGABRT (core dumped) +++
-- System Information:
Debian Release: 3.1
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.10-1-k7
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Versions of packages gnucash depends on:
ii bonobo 1.0.22-2.2 The GNOME Bonobo System.
ii gdk-imlib1 1.9.14-16.2 imaging library for use with gtk (
ii gnucash-common 1.8.10-11 A personal finance tracking progra
ii guile-1.6-libs 1.6.7-1 Main Guile libraries
ii guile-1.6-slib 1.6.7-1 Guile SLIB support
ii libart2 1.4.2-19The GNOME canvas widget - runtime
ii libaudiofile00.2.6-6 Open-source version of SGI's audio
ii libbonobo2 1.0.22-2.2 The GNOME Bonobo library.
ii libc62.3.2.ds1-20GNU C Library: Shared libraries an
ii libdate-manip-perl 5.42a-3 a perl library for manipulating da
ii libdb3 3.2.9-22Berkeley v3 Database Libraries [ru
ii libesd0 0.2.35-2Enlightened Sound Daemon - Shared
ii libfinance-quote-per 1.08-1 Perl module for retrieving stock q
ii libfreetype6 2.1.7-2.3 FreeType 2 font engine, shared lib
ii libgal23 0.24-1.4G App Libs (run time library)
ii libgconf11 1.0.9-6 GNOME configuration database syste
ii libgdk-pixbuf-gnome2 0.22.0-7The GNOME1 Canvas pixbuf library
ii libgdk-pixbuf2 0.22.0-7The GdkPixBuf image library, gtk+
ii libghttp11.0.9-15original GNOME HTTP client library
ii libglade-gnome0 1:0.17-3Library to load .glade files at ru
ii libglade01:0.17-3Library to load .glade files at ru
ii libglib1.2 1.2.10-9The GLib library of C routines
ii libgnome32 1.4.2-19The GNOME libraries
ii libgnomeprint15 0.37-5 The GNOME Print architecture - run
ii libgnomesupport0 1.4.2-19The GNOME libraries (Support libra
ii libgnomeui32 1.4.2-19The GNOME libraries (User Interfac
ii libgtk1.21.2.10-17 The GIMP Toolkit set of widgets fo
ii libgtkhtml1.1-3 1.1.10-4HTML rendering/editing library - r
ii libguile-ltdl-1 1.6.7-1 Guile's patched version of libtool
ii libguppi16 0.40.3-11 GNOME graph and plot component
ii libgwrapguile1 1.3.4-12g-wrap: Tool for exporting C libra
ii libice6 4.3.0.dfsg.1-12.0.1 Inter-Client Exchange library
ii libltdl3 1.5.6-6 A system independent dlopen wrappe
ii liboaf0 0.6.10-3The GNOME Object Activation Framew
ii libofx1 1:0.7.0-7 library to support Open Financial
ii liborbit00.5.17-9Libraries for ORBit - a CORBA ORB
ii libpopt0 1.7-5 lib for parsing cmdline parameters
ii libqthreads-12 1.6.7-1 QuickThreads library for Guile
ii libsm6 4.3.0.dfsg.1-12.0.1 X Window System Session Management
ii libstdc++5 1:3.3.5
Bug#303764: Not Ready for Sarge
Package: rails Version: 0.11.1-2 Severity: serious Rails is under development and will have (could have) a lot of changes before the 1.x milestone. It should not be added to Sarge at this time. Rails is an arch all package and should have all its dependencies satisfied in Sarge for some time. If Sarge releases without rails, you can use rails from Sid or if there are dependency problems, I will provide rails package either on backports.org or http://people.debian.org/~adamm/rails/ - Adam PS. If Sarge doesn't release in the next month or so, I will be adding rails and its necessary dependencies backported from sarge to woody on http://people.debian.org/~adamm/rails/ -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.10-1-k7 Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Versions of packages rails depends on: ii libmysql-ruby1.8 2.4.5-6.1 MySQL module for Ruby 1.8 ii libpgsql-ruby1.8 0.7.1-3PostgreSQL extension library for r ii libredcloth-ruby1.8 3.0.3-2Textile module for Ruby 1.8 ii libtest-unit-ruby 1.8.2-1unit-testing framework for the Rub ii rake 0.5.0-1a ruby build program ii rdoc 1.8.2-1Generate documentation from ruby s ii ruby 1.8.2-1An interpreter of object-oriented ii ruby1.8 1.8.2-3Interpreter of object-oriented scr -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#303687: Should be fixed
On Apr 8, 2005 3:56 AM, Josselin Mouette <[EMAIL PROTECTED]> wrote: > Could you please tell us whether gnucash still crashes for you with the > latest (1.0.9-7) gconf packages? No, gnucash -11 with gconf 1.0.9-7 does not work. I get the same error as before, gtkhtml-ERROR **: gconf error: Failed to contact configuration server (a likely cause of this is that you have an existing configuration server (gconfd) running, but it isn't reachable from here - if you're logged in from two machines at once, you may need to enable TCP networking for ORBit) aborting... Aborted (core dumped) Again, gnucash -10 works perfectly, irrespective of which gconf I use. - Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#303687: Dumps core on start
On Apr 8, 2005 12:43 AM, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > > severity 303687 normal > reassign 303687 gconf2 > thanks > > "Adam M." <[EMAIL PROTECTED]> writes: > > > Package: gnucash > > Version: 1.8.10-11 > > Severity: grave > > > > gnucash dumps core on startup after the latest update. > > This is actually a bug in gconf. There is a simple workaround > described in /usr/share/doc/gnucash/README.Debian. I know you can reassign bugs all you want, but the problem remains that gnucash DOES NOT work in Sid. I downgraded gnucash to the one in Sarge and it works perfectly, with latest gconf. The only difference on my system is the new gtkhtml+gnucash. I think it is a grave mistake to allow gnucash, or gtkhtml into Sarge at this time. gconf2 et al. are latest from sid works, gnucash: Installed: 1.8.10-10 Candidate: 1.8.10-11 gconf2: Installed: 2.8.1-5 Candidate: 2.8.1-5 The setup with latest gnucash fails to start. - Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#303687: Should be fixed
Ahh but now I can't test it until Monday morning... I will verify the fix for i386 on Monday if no one beats me to it. - Adam On Fri, 8 Apr 2005 12:15:16 -0700, Steve Langasek <[EMAIL PROTECTED]> wrote: > On Fri, Apr 08, 2005 at 12:27:13PM -0500, Adam M wrote: > > On Apr 8, 2005 3:56 AM, Josselin Mouette <[EMAIL PROTECTED]> wrote: > > > Could you please tell us whether gnucash still crashes for you with the > > > latest (1.0.9-7) gconf packages? > > > No, gnucash -11 with gconf 1.0.9-7 does not work. I get the same error > > as before, > > The fix was in the libgconf11 binary package, not the gconf binary package. > Do you have the latest version of libgconf11 installed as well? > > -- > Steve Langasek > postmodern programmer > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#303687: Should be fixed
On Apr 8, 2005 2:15 PM, Steve Langasek <[EMAIL PROTECTED]> wrote: > The fix was in the libgconf11 binary package, not the gconf binary package. > Do you have the latest version of libgconf11 installed as well? I can verify now that with new libgconf11 installed, gnucash 1.8.10-11 does not crash on start. - Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#307663: PostgreSQL Character Conversion and tsearch2 Module Vulnerabilities
Package: postgresql Severity: grave Tags: security sarge From: http://secunia.com/advisories/15217/ Workarounds (aka, fixes :) http://www.postgresql.org/about/news.315 DESCRIPTION: Two vulnerabilities have been reported in PostgreSQL, which can be exploited by malicious users to cause a DoS (Denial of Service) or potentially gain escalated privileges. 1) Missing validation of arguments supplied to the functions supporting client-to-server character set conversion can be exploited by unprivileged users when calling the functions from SQL commands. The vulnerability affects versions 7.3.* through 8.0.*. 2) The contrib/tsearch2 module misdeclares the return type of several functions, which breaks the type safety of "internal". The impact has reportedly not been investigated, but can at least crash the backend. The vulnerability affects versions 7.4 and later with the contrib/tsearch2 module installed. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.11-1-k7 Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Versions of packages postgresql depends on: ii adduser 3.63Add and remove users and groups ii debconf [debconf 1.4.48 Debian configuration management sy ii debianutils 2.13.2 Miscellaneous utilities specific t ii dpkg 1.10.27 Package maintenance system for Deb ii libc62.3.2.ds1-21GNU C Library: Shared libraries an ii libcomerr2 1.37-2 common error description library ii libkrb53 1.3.6-3 MIT Kerberos runtime libraries ii libpam0g 0.76-22 Pluggable Authentication Modules l ii libperl5.8 5.8.4-8 Shared Perl library ii libpq3 7.4.7-5 PostgreSQL C client library ii libreadline4 4.3-15 GNU readline and history libraries ii libssl0.9.7 0.9.7e-3SSL shared libraries ii mailx1:8.1.2-0.20040524cvs-4 A simple mail user agent ii postgresql-clien 7.4.7-5 front-end programs for PostgreSQL ii procps 1:3.2.5-1 /proc file system utilities ii python2.32.3.5-2 An interactive high-level object-o ii ucf 1.18Update Configuration File: preserv ii zlib1g 1:1.2.2-4 compression library - runtime -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#307663: PostgreSQL Character Conversion and tsearch2 Module Vulnerabilities
> Thanks for the report. I already uploaded a new package into Sid which > fixes this and spoke with the release and security team. The new > version will enter Sarge in two days (usual urgency=high upload), > release team approved Sarge inclusion. Thanks. I see you also read the PostgreSQL annoucement about two days ago. :) - Adam
Bug#308272: Cannot distribute in Debian
Package: unrar-nonfree Severity: serious It appears that the copyright does not permission distribution in Debian without a written permission, yet I find no such permission in debian/copyright. More specifically, 3. The unRAR utility may be freely distributed, provided the distribution package is not modified. No person or company may charge a fee for the distribution of unRAR without written permission from the copyright holder. But by definition, it is modified since it is shipped as a DEB, not a tar.gz file. I think clarification from copyright holder is needed here. - Adam -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.11-1-k7 Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Versions of packages unrar-nonfree depends on: ii libc6 2.3.2.ds1-21 GNU C Library: Shared libraries an ii libgcc11:3.4.3-13GCC support library ii libstdc++5 1:3.3.6-3.0.1 The GNU Standard C++ Library v3 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#308855: Privilege escalation in ELF core dump (fs/binfmt_elf.c)
Package: kernel-source-2.6.8
Version: 2.6.8-15
Severity: critical
Tags: security patch
>From Secunia advisory http://secunia.com/advisories/15341/
DESCRIPTION:
Paul Starzetz has reported a vulnerability in the Linux kernel, which
can be exploited by malicious, local users to gain escalated
privileges.
The vulnerability is caused due to a signedness error in the Linux
ELF binary format loader's core dump function (elf_core_dump()) and
can be exploited to cause a buffer overflow via a specially crafted
ELF binary.
Successful exploitation makes it possible to gain root privileges and
execute arbitrary code with kernel privileges.
The vulnerability has been reported in versions 2.2 through
2.2.27-rc2, versions 2.4 through 2.4.31-pre1, and versions 2.6
through 2.6.12-rc4.
ORIGINAL ADVISORY:
Kernel.org:
http://kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.11.9
iSEC Security Research:
http://www.isec.pl/vulnerabilities/isec-0023-coredump.txt
-- System Information:
Debian Release: 3.1
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11-1-k7
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Versions of packages kernel-source-2.6.8 depends on:
ii binutils 2.15-5 The GNU assembler, linker and bina
ii bzip2 1.0.2-6high-quality block-sorting file co
ii coreutils [fileutils] 5.2.1-2The GNU core utilities
-- no debconf information
--- a/fs/binfmt_elf.c 2005-05-11 15:43:56 -07:00
+++ b/fs/binfmt_elf.c 2005-05-11 15:43:56 -07:00
@@ -257,7 +257,7 @@
}
/* Populate argv and envp */
- p = current->mm->arg_start;
+ p = current->mm->arg_end = current->mm->arg_start;
while (argc-- > 0) {
size_t len;
__put_user((elf_addr_t)p, argv++);
@@ -1279,7 +1279,7 @@
static int fill_psinfo(struct elf_prpsinfo *psinfo, struct task_struct *p,
struct mm_struct *mm)
{
- int i, len;
+ unsigned int i, len;
/* first copy the parameters from user space */
memset(psinfo, 0, sizeof(struct elf_prpsinfo));
Bug#308855: reassign
reassign 308855 kernel thanks I probably shoud reassign this to the kernel pseudo-package since it applies to ALL of the kernels.. According to iSec, there is a quick workaround for the problem, "A hotfix for this vulnerability is to disallow processes to drop core. This can be accomplished by setting the hard core size limit for users to 0 (e.g. ulimit -H -c 0, man limits.conf)." - Adam
Bug#303991: Huh?
Why are you uploading dbmail2? Why not just upload dbmail 2.x as dbmail? I mean, you are uploading dbmail2 and having dbmail removed? This doesn't make any sense.. sorry. - Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#481264: simutrans: crash during playing
s=0x1c078b0) at simcity.cc:1702 #6 0x004efb41 in stadt_t::step (this=0x259a, delta_t=) at simcity.cc:1301 #7 0x0054041b in karte_t::step (this=0xd1a600) at simworld.cc:2280 #8 0x00540692 in karte_t::interactive (this=0xd1a600) at simworld.cc:4311 #9 0x00511977 in simu_main (argc=, argv=0x488) at simmain.cc:983 #10 0x00546215 in main (argc=1, argv=0x7fff7cb850e8) at simsys_s.c:602 (gdb) that's all. Thanks for look on it and good(gdb) bt #0 0x2b482eddf1d5 in raise () from /lib/libc.so.6 #1 0x2b482ede0680 in abort () from /lib/libc.so.6 #2 0x2b482edd875f in __assert_fail () from /lib/libc.so.6 #3 0x004e8930 in stadt_t::gib_zufallspunkt (this=0x1b6d6a0) at simcity.cc:1723 #4 0x004e8c9a in stadt_t::finde_passagier_ziel (this=0x1c078b0, will_return=0x7fff7cb83b9c) at simcity.cc:1764 #5 0x004eb5b1 in stadt_t::step_passagiere (this=0x1c078b0) at simcity.cc:1702 #6 0x004efb41 in stadt_t::step (this=0x259a, delta_t=) at simcity.cc:1301 #7 0x0054041b in karte_t::step (this=0xd1a600) at simworld.cc:2280 #8 0x00540692 in karte_t::interactive (this=0xd1a600) at simworld.cc:4311 #9 0x00511977 in simu_main (argc=, argv=0x488) at simmain.cc:983 #10 0x00546215 in main (argc=1, argv=0x7fff7cb850e8) at simsys_s.c:602 (gdb) bye. M. Kovarik -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24-1-amd64 (SMP w/1 CPU core) Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages simutrans depends on: ii libc6 2.7-10GNU C Library: Shared libraries ii libgcc11:4.3.0-3 GCC support library ii libsdl1.2debian1.2.13-2 Simple DirectMedia Layer ii libstdc++6 4.3.0-3 The GNU Standard C++ Library v3 ii simutrans-data 99.18~0.svn1664-2 transportation simulator (base dat ii simutrans-pak6499.18~0.svn26-1 transportation simulator (data fil ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime simutrans recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#476504: Can compile but fails install due to symbol disaggrement
I am able to compile the nvidia-kernel-source, 169.12-1, but I cannot *install* the resulting module. KSRC=/usr/src/linux-headers-2.6.25-2-amd64 On modprobe, I receive the error message "FATAL: Error inserting nvidia (path): Invalid module format." dmesg says "nvidia: disagrees about version of symbol struct_module" I am attempting to track this down, but I have limited kernel-fu. -- Moshe Yudkowsky Disaggregate 2952 W Fargo Chicago, IL 60645 USA +1 773 764 8727 [EMAIL PROTECTED] http://www.Disaggregate.com http://www.PebbleAndAvalanche.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#476504: [pkg-nvidia-devel] Bug#476504: Can compile but fails install due to symbol disaggrement
On May 23, 2008, at 10:41 , Lennart Sorensen wrote: On Fri, May 23, 2008 at 10:22:04AM -0500, M Yudkowsky wrote: I am able to compile the nvidia-kernel-source, 169.12-1, but I cannot *install* the resulting module. KSRC=/usr/src/linux-headers-2.6.25-2-amd64 On modprobe, I receive the error message "FATAL: Error inserting nvidia (path): Invalid module format." dmesg says "nvidia: disagrees about version of symbol struct_module" I am attempting to track this down, but I have limited kernel-fu. 169.12-1 doesn't normally compile against 2.6.25, so perhaps it didn't actually compile in your case and just got confused instead. We have a patch to make it work which will be in the next release of the driver (hopefully this weekend). Len, Thanks for writing. As far as I can tell from looking at the output from debian/rules, there are no glaring errors. I get a .deb that I can install, and the install results in a suitably-named module in the nvidia directory of 2.6.25-2. When modprobe finds this kernel module I run into problems. I will check over the weekend, try the new version, and let you know. Or if you like you can send me a URL to the new debian in advance and I can try it pre-release, but I have a very narrow window as I am going offline in 5 hours and will remain offline until Sat night. Regards, Moshe -- Moshe Yudkowsky Disaggregate 2952 W Fargo Chicago, IL 60645 USA +1 773 764 8727 [EMAIL PROTECTED] http://www.Disaggregate.com http://www.PebbleAndAvalanche.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
