Bug#1068636: lincity-ng: conflict with older lincity-ng-data
Package: lincity-ng Version: 2.10.1-1 Severity: normal Dear Maintainer, `apt upgrade` failed with Unpacking lincity-ng (2.10.1-1) over (2.9.0-1) ... dpkg: error processing archive /tmp/apt-dpkg-install-msgcqU/39-lincity-ng_2.10.1-1_amd64.deb (--unpack): trying to overwrite '/usr/share/icons/hicolor/128x128/apps/lincity-ng.png', which is also in package lincity-ng-data 2.9.0-1 (a simple `apt -f install` fixes it) If the file was really supposed to change package (was it?), you need to declare suitable breaks/conflicts/replaces/etc control fields. -- System Information: Debian Release: trixie/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'stable-debug'), (500, 'testing'), (400, 'stable-security'), (400, 'stable'), (50, 'unstable-debug'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64, ppc64el, mips64el, s390x, armhf Kernel: Linux 6.6.15-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lincity-ng depends on: ii libc62.37-15 ii libgcc-s114-20240201-3 ii libgl1 1.7.0-1 ii libphysfs1 3.0.2-6 ii libsdl2-2.0-02.30.0+dfsg-1 ii libsdl2-gfx-1.0-01.0.4+dfsg-5 ii libsdl2-image-2.0-0 2.8.2+dfsg-1 ii libsdl2-mixer-2.0-0 2.8.0+dfsg-1 ii libsdl2-ttf-2.0-02.22.0+dfsg-1 ii libstdc++6 14-20240201-3 ii libxml2 2.9.14+dfsg-1.3+b2 ii lincity-ng-data 2.10.1-1 ii zlib1g 1:1.3.dfsg-3+b1 lincity-ng recommends no packages. lincity-ng suggests no packages. -- no debconf information
Bug#1064438: gnome-settings-daemon: gsd-xsettings crash with older gsettings-desktop-schemas
Package: gnome-settings-daemon Version: 46~beta-1 Severity: important Dear Maintainer, since the update of gnome-settings-daemon to version 46 in testing, gsd-xsettings crashes while reporting (gsd-xsettings:5037): GLib-GIO-ERROR **: 08:45:13.336: Settings schema 'org.gnome.desktop.a11y.interface' does not contain a key named 'show-status-shapes' The backtrace doesn't say much more (gdb) bt #0 g_log_structured_array (log_level=, fields=0x7fffdc20, n_fields=4) at ../../../glib/gmessages.c:556 #1 0x7732f9e2 in g_log_default_handler (log_domain=log_domain@entry=0x77568ecb "GLib-GIO", log_level=log_level@entry=6, message=message@entry=0x7fffe4004c80 "Settings schema 'org.gnome.desktop.a11y.interface' does not contain a key named 'show-status-shapes'", unused_data=unused_data@entry=0x0) at ../../../glib/gmessages.c:3284 #2 0x7732fc50 in g_logv (log_domain=0x77568ecb "GLib-GIO", log_level=G_LOG_LEVEL_ERROR, format=, args=args@entry=0x7fffdd70) at ../../../glib/gmessages.c:1392 #3 0x7732ff03 in g_log (log_domain=log_domain@entry=0x77568ecb "GLib-GIO", log_level=log_level@entry=G_LOG_LEVEL_ERROR, format=format@entry=0x77580ed8 "Settings schema '%s' does not contain a key named '%s'") at ../../../glib/gmessages.c:1461 #4 0x7750d5b1 in g_settings_schema_get_value (key=, schema=) at ../../../gio/gsettingsschema.c:1015 #5 g_settings_schema_get_value (schema=0x55611220, key=0x55561ac5 "show-status-shapes") at ../../../gio/gsettingsschema.c:1001 #6 0x7750dc37 in g_settings_schema_key_init (key=key@entry=0x7fffdee0, schema=0x55611220, name=name@entry=0x55561ac5 "show-status-shapes") at ../../../gio/gsettingsschema.c:1295 #7 0x77511d07 in g_settings_get_value (settings=0x556108d0 [GSettings], key=0x55561ac5 "show-status-shapes") at ../../../gio/gsettings.c:1224 #8 0xe379 in gsd_xsettings_manager_start (manager=0x555ebbe0 [GsdXSettingsManager], error=error@entry=0x7fffe090) at ../plugins/xsettings/gsd-xsettings-manager.c:1519 #9 0xb0f0 in main (argc=, argv=) at ../plugins/common/daemon-skeleton-gtk.h:277 The mention of "schema" led me to notice that gsettings-desktop-schemas has a newer version in unstable, and indeed upgrading that package (and the gir and dev packages that come with it) from 45.0-2 to 46~beta-3 seems to have fixed the issue. My suggestion would be to tighten the dependency, which currently only says (>= 42~). Maybe in the very short term you could also ask if the migration of gsettings-desktop-schemas to testing can be sped up? -- System Information: Debian Release: trixie/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'testing'), (500, 'stable'), (50, 'unstable-debug'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.6.15-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE 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 gnome-settings-daemon depends on: ii gnome-settings-daemon-common 46~beta-1 ii gsettings-desktop-schemas 46~beta-3 ii libasound21.2.10-3 ii libc6 2.37-15 ii libcairo2 1.18.0-1+b1 ii libcanberra-gtk3-00.30-11 ii libcanberra0 0.30-11 ii libcolord21.4.7-1 ii libcups2 2.4.7-1+b1 ii libfontconfig12.14.2-6+b1 ii libgck-1-03.41.1-4 ii libgcr-base-3-1 3.41.1-4 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-3+b1 ii libgeoclue-2-02.7.1-2 ii libgeocode-glib-2-0 3.26.3-6+b1 ii libglib2.0-0 2.78.4-1 ii libgnome-desktop-3-20 44.0-2+b1 ii libgtk-3-03.24.41-1 ii libgudev-1.0-0238-3 ii libgweather-4-0 4.4.0-1 ii libmm-glib0 1.22.0-3 ii libnm01.44.2-7 ii libnotify40.8.3-1 ii libp11-kit0 0.25.3-4 ii libpam-systemd [logind] 255.3-2 ii libpango-1.0-01.51.0+ds-4 ii libpangocairo-1.0-0 1.51.0+ds-4 ii libpolkit-gobject-1-0 124-1 ii libpulse-mainloop-glib0 16.1+dfsg1-3 ii libpulse0 16.1+dfsg1-3 ii libspa-0.2-bluetooth 1.0.3-1 ii libsystemd0 255.3-2 ii libupower-glib3 1.90.2-8 ii libwacom9 2.9.0-2 ii libwayland-client01.22.0-2.1+b1 ii libx11-6 2:1.8.7-1 ii libxext6 2:1.3.4-1+b1 ii libxfixes31:6.0.0-2 ii libxi6
Bug#1053230: python3-httpx: Dependency version for httpcore
Package: python3-httpx Version: 0.23.3-1 Severity: normal Dear Maintainer, when I run `pip check`, it prints among other things httpx 0.23.3 has requirement httpcore<0.17.0,>=0.15.0, but you have httpcore 0.17.3. and that's indeed the information in /usr/lib/python3/dist-packages/httpx-0.23.3.dist-info/METADATA This does not match the debian field "Depends:", which only requires "python3-httpcore (>= 0.15.0)". This is problematic because in testing / unstable, we only have python3-httpcore version 0.17.3-1 right now. If the 2 versions don't work correctly together, I think this should be reflected in debian dependencies. If they do work correctly together, it would be nice to update METADATA to avoid scaring users. -- System Information: Debian Release: trixie/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'testing'), (500, 'stable'), (50, 'unstable-debug'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-1-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE 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 python3-httpx depends on: ii python3 3.11.4-5+b1 ii python3-certifi 2023.7.22-1 ii python3-click 8.1.6-1 ii python3-httpcore 0.17.3-1 ii python3-pygments 2.15.1+dfsg-1 ii python3-rfc3986 1.5.0-3 ii python3-rich 13.3.1-2 ii python3-sniffio 1.2.0-1 python3-httpx recommends no packages. python3-httpx suggests no packages. -- no debconf information
Bug#1050512: gnome-shell: Crash when viewing video with mpv
On Sun, 10 Sep 2023, Simon McVittie wrote: Would you be able to reproduce this with MUTTER_SYNC=1 in the environment (setting it in ~/.config/environment.d/mutter-sync.conf should apparently work) to confirm that it's the same crash as mutter#2857 upstream? I was hoping to wait until the other bug was fixed, since producing the trace is a bit of work. You say this happens when playing a video with mpv: perhaps this could be because mpv disables power saving / screen blanking while it's playing the video? I have no idea. It also happens (but less quickly) when watching videos full screen with firefox. If you install the x11-xserver-utils package and run "xset -dpms", does that trigger the same crash? No, it doesn't seem to have any effect. There is a merge request upstream which *might* fix this. If you are able to rebuild the mutter source package with patches applied, please try applying the attached file "bug1050512-without-xsync.patch" and see whether you can reproduce the crash. If that works, please report back. If not, please revert that change, apply "bug1050512-with-xsync.patch", rebuild and try again. The first patch does not work (still crashing). The second one does seem to help, that's great! Playing a few videos did not trigger any crash :-) If the problem reappears (with a lower frequency), I'll write again. If you're not able to rebuild the mutter source package, I had to use DEB_BUILD_OPTIONS=nocheck since several tests were failing, including some with very long timeouts. there's a heatwave here at the moment, Same here... -- Marc Glisse
Bug#1051080: texlive-binaries: Failed tex-common fmtutil trigger
Package: texlive-binaries Version: 2023.20230311.66589-3 Severity: normal Dear Maintainer, today's `apt upgrade` which consisted of The following NEW packages will be installed: luametatex The following packages will be upgraded: context context-modules gir1.2-adw-1 gir1.2-gtk-4.0 gir1.2-packagekitglib-1.0 gnome-control-center gnome-control-center-data gstreamer1.0-packagekit jekyll lcdf-typetools libadwaita-1-0 libayatana-ido3-0.4-0 libfreetype-dev libfreetype6 libgtk-4-1 libgtk-4-bin libgtk-4-common libgtk-4-dev libgtk-4-media-gstreamer libkpathsea6 liblzma-dev liblzma5 libpackagekit-glib2-18 libpackagekit-glib2-dev libptexenc1 libsndfile1 libsynctex2 libtexlua53-5 libtexluajit2 menhir octave octave-common octave-doc packagekit packagekit-tools pigz python3-colorama python3-pyproject-api python3-requests-toolbelt python3-sphinx-rtd-theme qtcreator qtcreator-data qtcreator-doc sphinx-rtd-theme-common texlive-binaries xz-utils ended with Processing triggers for tex-common (6.18) ... Running mktexlsr. This may take some time... done. Running mtxrun --generate. This may take some time... done. Running updmap-sys. This may take some time... done. Running mktexlsr /var/lib/texmf ... done. Building format(s) --all. This may take some time... fmtutil failed. Output has been stored in /tmp/fmtutil.SshoHJZZ Please include this file if you report a bug. The full output is available at https://geometrica.saclay.inria.fr/team/Marc.Glisse/tmp/fmtutil.SshoHJZZ , but the relevant part seems to be about hitex: fmtutil [INFO]: --- remaking hitex with hitex fmtutil: running `hitex -ini -jobname=hitex -progname=hitex -etex -ltx hitex.ini' ... This is HiTeX, Version 3.141592653-2.6-2.0 (TeX Live 2023) (INITEX) entering extended mode (hitex.ini (etex.src (plain.tex Preloading the plain format: codes, registers, parameters, fonts, more fonts, macros, math definitions, output routines, hyphenation (hyphen.tex [skipping from \patterns to end-of-file...])) (etexdefs.lib Skipping module "grouptypes"; Loading module "interactionmodes"; Skipping module "nodetypes"; Skipping module "iftypes";) (language.def (hyphen.tex) (loadhyph-ka.tex T8M Georgian hyphenation patterns (conv-utf8-t8m.tex) (hyph-ka.tex)) (loadhyph-nn.tex EC Norwegian Nynorsk hyphenation patterns (conv-utf8-ec.tex) (hyph-nn.tex (hyph-no.tex))) (loadhyph-eo.tex IL3 Esperanto hyphenation patterns (conv-utf8-il3.tex) (hyph-eo.tex)) (loadhyph-hu.tex EC Hungarian hyphenation patterns (conv-utf8-ec.tex) (hyph-hu.tex)) (loadhyph-it.tex ASCII Italian hyphenation patterns (hyph-it.tex)) (loadhyph-de-1996.tex EC German hyphenation patterns (reformed orthography) (dehyphn.tex New German Hyphenation Patterns `dehyphn' Rev.31 <2001-05-07> (WaS))) (loadhyph-la-x-classic.tex EC Classical Latin hyphenation patterns, v.2.0 2019-07-03 (hyph-la-x-classic.ec.tex)) (loadhyph-es.tex EC Spanish hyphenation patterns (conv-utf8-ec.tex) (hyph-es.tex)) (loadhyph-tk.tex EC Turkmen hyphenation patterns (conv-utf8-ec.tex) (hyph-tk.tex)) (loadhyph-bg.tex T2A Bulgarian hyphenation patterns (conv-utf8-t2a.tex) (hyph-bg.tex Bulgarian hyphenation patterns (options: --safe-morphology --standalone-tex, ve rsion 21 October 2017))) (loadhyph-sk.tex EC Slovak hyphenation patterns (conv-utf8-ec.tex) (hyph-sk.tex)) (loadhyph-mk.tex MACEDONIAN Macedonian hyphenation patterns (hyph-mk.macedonian.tex)) (loadhyph-hi.tex No Hindi hyphenation patterns - only for Unicode engines) (loadhyph-be.tex T2A Belarusian hyphenation patterns (conv-utf8-t2a.tex) (hyph-be.tex)) (loadhyph-rm.tex ASCII Romansh hyphenation patterns (hyph-rm.tex )) (loadhyph-la-x-liturgic.tex EC Liturgical Latin hyphenation patterns (hyph-la-x-liturgic.ec.tex)) (loadhyph-cop.tex Coptic hyphenation patterns (copthyph.tex)) (loadhyph-nl.tex EC Dutch hyphenation patterns (conv-utf8-ec.tex) (hyph-nl.tex)) (loadhyph-en-gb.tex ASCII Hyphenation patterns for British English (hyph-en-gb.tex)) (loadhyph-mr.tex No Marathi hyphenation patterns - only for Unicode engines) (loadhyph-or.tex No Oriya hyphenation patterns - only for Unicode engines) (loadhyph-ru.tex T2A Russian hyphenation patterns (ruhyphen.tex (catkoi.tex) (koi2t2a.tex) (ruhyphal.tex) (cyryoal.tex) (hypht2.tex))) (loadhyph-gu.tex No Gujarati hyphenation patterns - only for Unicode engines) (loadhyph-hy.tex No Armenian hyphenation patterns - only for Unicode engines) (loadhyph-sr-latn.tex EC Serbian hyphenation patterns in Latin script (conv-utf8-ec.tex) (hyph-sh-latn.tex)) (loadhyph-cu.tex No Church Slavonic hyphenation patterns - only for Unicode engines) (loadhyph-ta.tex No Tamil hyphenation patterns - only for Unicode engines) (loadhyph-pi.tex No Pali hyphenation patterns - only for Unicode engines) (loadhyph-th.tex LTH Thai hyphenation patterns (conv-utf8-lth.tex) (hyph-th.tex )) (loadhyph-kmr.tex EC Kurmanji hyphenation patterns (conv-utf8-ec.tex) (hyph-kmr.tex)) (loadhyph-id.tex ASCII Indonesian hyphenation patterns (hyph-id.tex)) (loadhyph-pa.tex No Pa
Bug#1050729: gnome-terminal: shift-click in vim acts like page-down
https://gitlab.gnome.org/GNOME/vte/-/issues/2643 -- Marc Glisse
Bug#1050729: gnome-terminal: shift-click in vim acts like page-down
I am also getting this strange behavior with kgx (gnome-console), so it seems related to gnome but not necessarily gnome-terminal in particular. The problem is even worse with kgx, where shift + right-click both starts a search for the current word (inside vim) and prints the menu "[copy - ]paste - select all", whereas gnome-terminal only shows a terminal menu. In vim, I have the option mouse=a (the default). I can work around this by changing this option to disable use of the mouse, but that's a bit extreme. -- Marc Glisse
Bug#1050512: gnome-shell: Crash when viewing video with mpv
It looks like my stack trace is useless because I forgot to set MUTTER_SYNC=1 :-( It seems likely that this is the same bug as https://gitlab.gnome.org/GNOME/mutter/-/issues/2857 (sadly not fixed yet). -- Marc Glisse
Bug#1050729: gnome-terminal: shift-click in vim acts like page-down
Package: gnome-terminal Version: 3.49.92-2 Severity: normal Dear Maintainer, I noticed a strange behavior today, that was not present in July. When I run vim (gtk3 or basic) in a gnome terminal, if I keep SHIFT pressed and left-click with the mouse, the behavior I get is the same as pressing PageDown. I tried it with another account that has no .vimrc and got the same issue. To compare, I have run vim in xterm and konsole and did not have this weird behavior: shift+double-click selected a word as expected. I may be getting the PageDown behavior *in addition to* the normal behavior. If I go to the end of the file so PageDown has no effect, shift+double-click does select a word. PageDown seems to be the expected behavior when rotating the wheel of the mouse while pressing SHIFT, in case that matters. I noticed the issue with the version of gnome-terminal in testing and only upgraded it to experimental because reportbug asked me to check that the bug was still present there (it is). -- System Information: Debian Release: trixie/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'testing'), (500, 'stable'), (50, 'unstable-debug'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.4.0-3-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE 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 gnome-terminal depends on: ii dbus-user-session [default-dbus-session-bus] 1.14.8-2 ii dbus-x11 [dbus-session-bus] 1.14.8-2 ii dconf-gsettings-backend [gsettings-backend] 0.40.0-4 ii gnome-terminal-data 3.49.92-2 ii gsettings-desktop-schemas 44.0-2 ii libatk1.0-0 2.49.90-5 ii libc6 2.37-7 ii libgcc-s1 13.2.0-2 ii libglib2.0-0 2.77.2-1 ii libgtk-3-03.24.38-4 ii libhandy-1-0 1.8.2-2 ii libpango-1.0-01.51.0+ds-2 ii libstdc++613.2.0-2 ii libuuid1 2.39.2-1 ii libvte-2.91-0 0.73.93-1 ii libx11-6 2:1.8.6-1 Versions of packages gnome-terminal recommends: ii gvfs 1.51.90-1 ii nautilus-extension-gnome-terminal 3.49.92-2 ii yelp 42.2-1 gnome-terminal suggests no packages. -- no debconf information
Bug#1050512: gnome-shell: Crash when viewing video with mpv
Package: gnome-shell Version: 44.3-5 Severity: important Dear Maintainer, when I play a video with mpv, after a bit of time (usually less than a minute), I get a gray screen telling me that gnome shell has crashed and I need to log out. Funny thing: if I press the windows key, I see all the windows in small size, and the video is actually still playing. But as soon as I leave the overview, the grey screen comes back. This is quite reproducible, I've had it 4 times today already with different videos. This system is up-to-date "testing", and the problem is recent (most likely the mutter/gnome-shell updates from today). You can find a more complete backtrace at https://geometrica.saclay.inria.fr/team/Marc.Glisse/tmp/gnome-shell-0 , I am only pasting the basic one here Thread 1 "gnome-shell" received signal SIGTRAP, Trace/breakpoint trap. g_log_structured_array (log_level=, fields=0x7ffd87953a60, n_fields=4) at ../../../glib/gmessages.c:555 Download failed: Invalid argument. Continuing without source file ./debian/build/deb/../../../glib/gmessages.c. 555 ../../../glib/gmessages.c: No such file or directory. (gdb) bt #0 g_log_structured_array (log_level=, fields=0x7ffd87953a60, n_fields=4) at ../../../glib/gmessages.c:555 #1 0x7fe19fd36a8e in g_log_default_handler (log_domain=log_domain@entry=0x7fe19f99e48f "libmutter", log_level=log_level@entry=6, message=message@entry=0x561f847d66f0 "Received an X Window System error.\nThis probably reflects a bug in the program.\nThe error was 'BadMatch (invalid parameter attributes)'.\n (Details: serial 149487 error_code 8 request_code 147 (unknow"..., unused_data=unused_data@entry=0x0) at ../../../glib/gmessages.c:3284 #2 0x7fe19fd36d00 in g_logv (log_domain=0x7fe19f99e48f "libmutter", log_level=G_LOG_LEVEL_ERROR, format=, args=args@entry=0x7ffd87953bb0) at ../../../glib/gmessages.c:1391 #3 0x7fe19fd36faf in g_log (log_domain=log_domain@entry=0x7fe19f99e48f "libmutter", log_level=log_level@entry=G_LOG_LEVEL_ERROR, format=format@entry=0x7fe19f9bc010 "Received an X Window System error.\nThis probably reflects a bug in the program.\nThe error was '%s'.\n (Details: serial %ld error_code %d request_code %d (%s) minor_code %d)\n (Note to programmers: nor"...) at ../../../glib/gmessages.c:1460 #4 0x7fe19f916ffe in display_error_event (error=0x7ffd87953d30, x11_display=0x561f82ef19a0 [MetaX11Display]) at ../src/x11/meta-x11-errors.c:113 #5 meta_x_error (xdisplay=, error=0x7ffd87953d30) at ../src/x11/meta-x11-errors.c:136 #6 meta_x_error (xdisplay=, error=0x7ffd87953d30) at ../src/x11/meta-x11-errors.c:132 #7 0x7fe19f2dd99b in _XError (dpy=dpy@entry=0x561f82268200, rep=rep@entry=0x7fe18808a0f0) at ../../src/XlibInt.c:1503 #8 0x7fe19f2da607 in handle_error (dpy=0x561f82268200, err=0x7fe18808a0f0, in_XReply=) at ../../src/xcb_io.c:211 #9 0x7fe19f2da6a5 in handle_response (dpy=dpy@entry=0x561f82268200, response=0x7fe18808a0f0, in_XReply=in_XReply@entry=0) at ../../src/xcb_io.c:403 #10 0x7fe19f2db152 in _XEventsQueued (dpy=dpy@entry=0x561f82268200, mode=mode@entry=2) at ../../src/xcb_io.c:442 #11 0x7fe19f2cc817 in XPending (dpy=0x561f82268200) at ../../src/Pending.c:55 #12 0x7fe19fd2dec8 in g_main_context_check_unlocked (context=context@entry=0x561f821b58b0, max_priority=, max_priority@entry=2147483647, fds=fds@entry=0x561f90579290, n_fds=n_fds@entry=11) at ../../../glib/gmain.c:4171 #13 0x7fe19fd2e51b in g_main_context_iterate_unlocked (context=0x561f821b58b0, block=block@entry=1, dispatch=dispatch@entry=1, self=) at ../../../glib/gmain.c:4346 #14 0x7fe19fd2eebf in g_main_loop_run (loop=0x561f845069a0) at ../../../glib/gmain.c:4551 #15 0x7fe19f8d71a5 in meta_context_run_main_loop (context=context@entry=0x561f821b3c80 [MetaContextMain], error=error@entry=0x7ffd87954020) at ../src/core/meta-context.c:482 #16 0x561f81aeb99f in main (argc=, argv=) at ../src/main.c:683 In case it matters, on one of the videos, mpv shows (+) Video --vid=1 (*) (h264 1280x720 29.706fps) (+) Audio --aid=1 (*) (aac 2ch 44100Hz) AO: [pipewire] 44100Hz stereo 2ch floatp VO: [gpu] 1280x720 yuv420p I have a nvidia gpu with the proprietary driver packaged by Debian. I don't see anything relevant in Xorg.*.log* dmesg shows for each crash something like [25284.801604] rfkill: input handler enabled [25284.877204] gnome-shell[25306]: segfault at 28 ip 7f5bba4f5f14 sp 7ffd36235540 error 4 in libmutter-clutter-12.so.0.0.0[7f5bba489000+8d000] likely on CPU 8 (core 0, socket 0) [25284.877213] Code: 72 e1 03
Bug#1050295: libqglviewer: Qt6 version?
Source: libqglviewer Severity: wishlist Dear Maintainer, it seems that upstream supports Qt6, at least I see commits like "Fix build with Qt6 on Linux". When you upgrade to version 2.9.1 or newer (we are currently at 2.8.0), could you also create Qt6 packages, not just Qt5? -- System Information: Debian Release: trixie/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'testing'), (500, 'stable'), (50, 'unstable-debug'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.4.0-2-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE 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
Bug#1049989: gnome-calendar: Multiple assertion failures
Package: gnome-calendar Version: 44.1-2 Severity: important Dear Maintainer, my terminal currently shows the following, I think you can guess why I am not happy hippo ~ $ gnome-calendar (gnome-calendar:33118): GcalWeatherService-WARNING **: 00:10:36.416: Could not create GCLueSimple: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Geolocation disabled for UID 59682 (gnome-calendar:33118): Gtk-CRITICAL **: 00:11:12.266: gtk_header_bar_pack: assertion 'gtk_widget_get_parent (widget) == NULL' failed ** GcalEditCalendarPage:ERROR:../src/gui/calendar-management/gcal-edit-calendar-page.c:206:update_calendar: assertion failed: (self->calendar != NULL) Bail out! GcalEditCalendarPage:ERROR:../src/gui/calendar-management/gcal-edit-calendar-page.c:206:update_calendar: assertion failed: (self->calendar != NULL) zsh: IOT instruction (core dumped) gnome-calendar hippo ~ $ gnome-calendar (gnome-calendar:35447): GcalWeatherService-WARNING **: 00:22:44.384: Could not create GCLueSimple: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Geolocation disabled for UID 59682 ** GcalTimeline:ERROR:../src/core/gcal-timeline.c:579:on_calendar_monitor_completed_cb: assertion failed: (self->completed_calendars <= g_hash_table_size (self->calendars)) Bail out! GcalTimeline:ERROR:../src/core/gcal-timeline.c:579:on_calendar_monitor_completed_cb: assertion failed: (self->completed_calendars <= g_hash_table_size (self->calendars)) zsh: IOT instruction (core dumped) gnome-calendar I launched gnome-calendar, added an online calendar, removed some, looked around in manage calendars, and it crashed. Twice, with a different error. I am sorry, I do not remember what exact menu I was on at the time, and if I was clicking on something. After that, I restarted gnome-calendar in gdb, removed a few more calendars, and finally got GcalTimeline:ERROR:../src/core/gcal-timeline.c:579:on_calendar_monitor_completed_cb: assertion failed: (self->completed_calendars <= g_hash_table_size (self->calendars)) Bail out! GcalTimeline:ERROR:../src/core/gcal-timeline.c:579:on_calendar_monitor_completed_cb: assertion failed: (self->completed_calendars <= g_hash_table_size (self->calendars)) Thread 1 "gnome-calendar" received signal SIGABRT, Aborted. __pthread_kill_implementation (threadid=, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44 Download failed: Invalid argument. Continuing without source file ./nptl/./nptl/pthread_kill.c. 44 ./nptl/pthread_kill.c: No such file or directory. (gdb) bt #0 __pthread_kill_implementation (threadid=, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44 #1 0x76cbc15f in __pthread_kill_internal (signo=6, threadid=) at ./nptl/pthread_kill.c:78 #2 0x76c6e472 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x76c584b2 in __GI_abort () at ./stdlib/abort.c:79 #4 0x770f3ee8 in g_assertion_message (domain=domain@entry=0x555b76c9 "GcalTimeline", file=file@entry=0x555b76fd "../src/core/gcal-timeline.c", line=line@entry=579, func=func@entry=0x555c1b20 <__func__.8> "on_calendar_monitor_completed_cb", message=message@entry=0x56ded470 "assertion failed: (self->completed_calendars <= g_hash_table_size (self->calendars))") at ../../../glib/gtestutils.c:3497 #5 0x7715955a in g_assertion_message_expr (domain=domain@entry=0x555b76c9 "GcalTimeline", file=file@entry=0x555b76fd "../src/core/gcal-timeline.c", line=line@entry=579, func=func@entry=0x555c1b20 <__func__.8> "on_calendar_monitor_completed_cb", expr=expr@entry=0x555bde58 "self->completed_calendars <= g_hash_table_size (self->calendars)") at ../../../glib/gtestutils.c:3523 #6 0x55587853 in on_calendar_monitor_completed_cb (monitor=, pspec=, self=0x55875fd0 [GcalTimeline]) at ../src/core/gcal-timeline.c:579 #11 0x77d6e5ff in (instance=instance@entry=0x557db8f0, signal_id=, detail=) at ../../../gobject/gsignal.c:3675 #7 0x77d543f8 in g_closure_invoke (closure=0x56bb8680, return_value=0x0, n_param_values=2, param_values=0x7fffdbd0, invocation_hint=0x7fffdb20) at ../../../gobject/gclosure.c:832 #8 0x77d6701c in signal_emit_unlocked_R (node=node@entry=0x7fffdca0, detail=detail@entry=345, instance=instance@entry=0x557db8f0, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffdbd0) at ../../../gobject/gsignal.c:3980 #9 0x77d68951 in signal_emit_valist_unlocked (instance=instance@entry=0x557db8f0, signal_id=signal_id@entry=1, detail=detail@entry=345, var_args=var_args@entry=0x7fffde00) at ../../../gobject/gsignal.c:3612 #10 0x77d6e552 in g_signal_emit_valist (instance=0x557db8f0, signal_id=1, detail=345, var_args=0x7fffde00) at ../../../gobject/gsignal.c:3355 #12 0x77d581b4 in g_object_dispatch_properties_cha
Bug#1032283: python3-sphinx: sphinx-build ignores virtual env
Package: python3-sphinx Version: 5.3.0-3 Severity: normal Dear Maintainer, I used to install tensorflow with pip, and sphinx-build had no trouble building my documentation which includes `import tensorflow`. Since we are not supposed to use pip directly anymore, I created a virtual environment, with the option --system-site-packages since I only want to add a few things not packaged in Debian, and installed tensorflow in it. I now activate the environment, run sphinx-build, and... it fails to find tensorflow. The issue is that sphinx-build starts with #!/usr/bin/python3 , it does not use the python3 symlink that the activation added at the beginning of PATH, and thus does not look for packages in my active virtual environment. I have many possible workarounds: * execute python3 -m sphinx.cmd.build * execute python3 /usr/bin/sphinx-build * export a PYTHONPATH pointing to the virtual environment * install another copy of sphinx in the virtual environment etc but they essentially mean that the sphinx-build script shipped by Debian is useless to me, I just use the first workaround instead. The most natural change would be to use #!/usr/bin/env python3, but Debian policy says not to do that. Is there a way this policy could be relaxed when there is a good reason? Or is there another way to let sphinx-build do the right thing with virtual environments? Or should I resign myself? -- System Information: Debian Release: bookworm/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'testing'), (500, 'stable'), (50, 'unstable-debug'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-5-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE 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 python3-sphinx depends on: ii python3 3.11.2-1 ii python3-alabaster 0.7.12-1 ii python3-babel 2.10.3-1 ii python3-distutils 3.11.2-2 ii python3-docutils0.19+dfsg-6 ii python3-imagesize 1.4.1-1 ii python3-importlib-metadata 4.12.0-1 ii python3-jinja2 3.0.3-2 ii python3-packaging 23.0-1 ii python3-pygments2.14.0+dfsg-1 ii python3-requests2.28.1+dfsg-1 ii python3-snowballstemmer 2.2.0-2 ii sphinx-common 5.3.0-3 Versions of packages python3-sphinx recommends: ii make 4.3-4.1 ii python3-pil 9.4.0-1.1+b1 Versions of packages python3-sphinx suggests: ii dvipng 1.15-1.1+b1 ii fonts-freefont-otf 20120503-10 ii imagemagick-6.q16 8:6.9.11.60+dfsg-1.6 ii latexmk1:4.79-1 ii libjs-mathjax 2.7.9+dfsg-1 ii python3-lib2to33.11.2-2 ii python3-sphinx-rtd-theme 1.2.0+dfsg-1 pn sphinx-doc ii tex-gyre 20180621-6 ii texlive-fonts-recommended 2022.20230122-2 ii texlive-latex-extra2022.20230122-2 ii texlive-latex-recommended 2022.20230122-2 ii texlive-plain-generic 2022.20230122-2 -- no debconf information
Bug#1020697: nvidia-alternative fails update
On Wed, 5 Oct 2022, Riccardo Gagliarducci wrote: I think I have, on bookworm, a related or similar bug/problem to the one highlighted here. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020761 . A new version was uploaded today, you need to give it a few days for it to build, migrate to testing, propagate to mirrors, etc. -- Marc Glisse
Bug#1020761: nvidia-cuda-dev: Depends on driver from experimental or for tesla
On Thu, 29 Sep 2022, Meik Hellmund wrote: I stumbled about this problem yesterday (28 Sep) and 'solved' it by apt install nvidia-cuda-dev nvidia-cuda-toolkit apt dist-upgrade $ sudo apt install nvidia-cuda-dev nvidia-cuda-toolkit [...] The following packages have unmet dependencies: nvidia-alternative : Breaks: nvidia-tesla-alternative (> 0) but 510.85.02-1 is to be installed I have testing by default. With unstable, it installs the tesla drivers, and I haven't seen any documentation stating that this is the expected thing to do if one wants to use cuda. -- Marc Glisse
Bug#1020761: nvidia-cuda-dev: Depends on driver from experimental or for tesla
Package: nvidia-cuda-dev Version: 11.5.2-2 Severity: normal Dear Maintainer, since yesterday, on this debian testing system, apt upgrade prints the following: 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. The following information may help to resolve the situation: The following packages have unmet dependencies: nvidia-alternative : Breaks: nvidia-tesla-alternative (> 0) but 510.85.02-1 is to be installed This appears to be because I have nvidia-cuda-dev (11.4.3-5) installed. Apt wants to upgrade it to 11.5.2-2, but that version wants libcuda1 (>= 495), which is only available in experimental. It sees the alternative libnvidia-tesla-cuda1 (>= 495), which is available in testing, but that requires changing too many packages. I am confused, what is the expected path forward? Some possible hypotheses: - the tesla driver somehow replaces the normal driver now. I am not finding much evidence for this. - nvidia-cuda-toolkit was accidentally uploaded too early / nvidia-graphics-drivers was accidentally not uploaded early enough. -- System Information: Debian Release: bookworm/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'testing'), (500, 'stable'), (50, 'unstable-debug'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.19.0-1-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE 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
Bug#1009299: linux-image-5.16.0-6-amd64: 5.16 breaks buttons below touchpad on Dell Precision 7550
Hello, I installed linux-image-5.17.0-1-amd64:amd64/unstable 5.17.3-1 uptodate (and corresponding headers, etc) and right click works again, the issue is fixed, thank you! -- Marc Glisse
Bug#1009171: closed by Julian Gilbey (Re: Bug#1009171: python3-spyder: Dependency on older python3-spyder-kernels)
Ah, I failed to notice that spyder had been removed from testing already, sorry for the unnecessary report, and thanks a lot for working on the new version, which was far from a trivial update from what I can see. It seems to be working fine, from 30 seconds of use so far... -- Marc Glisse
Bug#1009299: linux-image-5.16.0-6-amd64: 5.16 breaks buttons below touchpad on Dell Precision 7550
Package: src:linux
Version: 5.16.18-1
Severity: normal
Dear Maintainer,
the Dell Precision 7550 is a laptop which has a touchpad, and below it 3
physical buttons. If I boot with linux-image-5.15.0-3-amd64, these
buttons work perfectly well. However, with linux-image-5.16.0-6-amd64,
the right button does not work. Running xev, it prints nothing when I
click that button. evemu-record does see something when I click on the
right button, here are some random parts of its log
# DMI:
dmi:bvnDellInc.:bvr1.12.0:bd12/12/2021:br1.12:svnDellInc.:pnPrecision7550:pvr:rvnDellInc.:rn01PXFR:rvrA00:cvnDellInc.:ct10:cvr:sku09C3:
# Input device name: "DELL09C3:00 0488:120A Touchpad"
# Input device ID: bus 0x18 vendor 0x488 product 0x120a version 0x100
# Event type 1 (EV_KEY)
# Event code 272 (BTN_LEFT)
# Event code 325 (BTN_TOOL_FINGER)
# Event code 328 (BTN_TOOL_QUINTTAP)
# Event code 330 (BTN_TOUCH)
# Event code 333 (BTN_TOOL_DOUBLETAP)
# Event code 334 (BTN_TOOL_TRIPLETAP)
# Event code 335 (BTN_TOOL_QUADTAP)
# Properties:
# Property type 0 (INPUT_PROP_POINTER)
# Property type 2 (INPUT_PROP_BUTTONPAD)
E: 0.01 0004 0005 # EV_MSC / MSC_TIMESTAMP0
E: 0.01 # SYN_REPORT (0) -- +0ms
E: 0.001257 0004 0005 4400 # EV_MSC / MSC_TIMESTAMP4400
E: 0.001257 # SYN_REPORT (0) -- +1ms
E: 0.002600 0004 0005 8900 # EV_MSC / MSC_TIMESTAMP8900
E: 0.002600 # SYN_REPORT (0) -- +1ms
E: 0.004029 0004 0005 13300 # EV_MSC / MSC_TIMESTAMP13300
[...]
The buttons were always a bit strange (see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980376).
syslog (or Xorg.0.log) has, among other things
Apr 11 08:44:23 hippo /usr/libexec/gdm-x-session[1418]: (II) event23 -
DELL09C3:00 0488:120A Touchpad: is tagged by udev as: Touchpad
Apr 11 08:44:23 hippo /usr/libexec/gdm-x-session[1418]: (EE) event23 -
DELL09C3:00 0488:120A Touchpad: kernel bug: missing right button, assuming it
is a clickpad.
Apr 11 08:44:23 hippo /usr/libexec/gdm-x-session[1418]: (II) event23 -
DELL09C3:00 0488:120A Touchpad: device is a touchpad
Please let me know any logs I should attach to help.
-- Package-specific info:
** Version:
Linux version 5.16.0-6-amd64 (debian-ker...@lists.debian.org) (gcc-11 (Debian
11.2.0-19) 11.2.0, GNU ld (GNU Binutils for Debian) 2.38) #1 SMP PREEMPT Debian
5.16.18-1 (2022-03-29)
** Command line:
BOOT_IMAGE=/vmlinuz-5.16.0-6-amd64 root=/dev/mapper/hippo--vg-root ro quiet
** Tainted: PO (4097)
* proprietary module was loaded
* externally-built ("out-of-tree") module was loaded
** Kernel log:
[ 294.309266] leds dell::kbd_backlight: Setting an LED's brightness failed (-5)
[ 294.317480] input: HDA Intel PCH Headphone Mic as
/devices/pci:00/:00:1f.3/sound/card0/input29
[ 294.318288] ACPI BIOS Error (bug): AE_AML_BUFFER_LIMIT, Field [WAR2] at bit
offset/length 64/32 exceeds size of target Buffer (64 bits)
(20210930/dsopcode-198)
[ 294.318327] ACPI Error: Aborting method \_SB.AMW0.WMBA due to previous error
(AE_AML_BUFFER_LIMIT) (20210930/psparse-529)
[ 294.319617] Bluetooth: hci0: Failed to read codec capabilities (-56)
[ 294.320650] Bluetooth: hci0: Failed to read codec capabilities (-56)
[ 294.321568] iwlwifi :00:14.3 wlo1: renamed from wlan0
[ 294.321603] Bluetooth: hci0: Failed to read codec capabilities (-56)
[ 294.322628] Bluetooth: hci0: Failed to read codec capabilities (-56)
[ 294.322716] ACPI BIOS Error (bug): AE_AML_BUFFER_LIMIT, Field [WAR2] at bit
offset/length 64/32 exceeds size of target Buffer (64 bits)
(20210930/dsopcode-198)
[ 294.322751] ACPI Error: Aborting method \_SB.AMW0.WMBA due to previous error
(AE_AML_BUFFER_LIMIT) (20210930/psparse-529)
[ 294.322805] usbcore: registered new interface driver snd-usb-audio
[ 294.323626] Bluetooth: hci0: Failed to read codec capabilities (-56)
[ 294.324692] Bluetooth: hci0: Failed to read codec capabilities (-56)
[ 294.381074] audit: type=1400 audit(1649659457.376:2): apparmor="STATUS"
operation="profile_load" profile="unconfined" name="firejail-default" pid=972
comm="apparmor_parser"
[ 294.381542] audit: type=1400 audit(1649659457.376:3): apparmor="STATUS"
operation="profile_load" profile="unconfined" name="libreoffice-xpdfimport"
pid=986 comm="apparmor_parser"
[ 294.381842] audit: type=1400 audit(1649659457.376:4): apparmor="STATUS"
operation="profile_load" profile="unconfined" name="libreoffice-oosplash"
pid=983 comm="apparmor_parser"
[ 294.381982] audit: type=1400 audit(1649659457.376:5): apparmor="STATUS"
operation="profile_load" profile="unconfined" name="lsb_release" pid=973
comm="apparmor_parser"
[ 294.382340] audit: type=1400 audit(1649659457.376:6): apparmor="STATUS"
operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=976
comm="apparmor_parser"
[ 294.382344] audit: type=1400 audit(1
Bug#1009171: python3-spyder: Dependency on older python3-spyder-kernels
Package: python3-spyder Version: 4.2.1+dfsg1-3 Severity: normal Dear Maintainer, python3-spyder-kernels was recently updated to 2.3.0-1. Since python3-spyder depends on a version << 1.11.0, it means it cannot be installed anymore, or people who already have it cannot update python3-spyder-kernels. In the future, would it be possible to synchronize those 2 packages better, so python3-spyder-kernels cannot migrate to testing until a compatible version of python3-spyder is available? Thank you for maintaining this package. -- System Information: Debian Release: bookworm/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'testing'), (500, 'stable'), (50, 'unstable-debug'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.16.0-6-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE 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 python3-spyder depends on: ii ipython3 7.31.1-1 ii libjs-jquery 3.6.0+dfsg+~3.5.13-1 ii libjs-mathjax 2.7.9+dfsg-1 ii pylint2.12.2-1 ii python3 3.9.8-1 ii python3-atomicwrites 1.4.0-2 ii python3-chardet 4.0.0-1 ii python3-cloudpickle 2.0.0-1 ii python3-diff-match-patch 20200713-2 ii python3-docutils 0.17.1+dfsg-2 ii python3-intervaltree 3.0.2-1.1 ii python3-ipython 7.31.1-1 ii python3-jedi 0.18.0-1 ii python3-jsonschema3.2.0-5 ii python3-keyring 23.5.0-1 ii python3-nbconvert 6.4.4-1 ii python3-numpydoc 1.2.1-1 ii python3-parso 0.8.1-1 ii python3-pexpect 4.8.0-2 ii python3-pickleshare 0.7.5-5 ii python3-pkg-resources 59.6.0-1.2 ii python3-psutil5.9.0-1 ii python3-pygments 2.11.2+dfsg-2 ii python3-pyls 0.36.2-3 ii python3-pyls-black0.4.6-3.1 ii python3-pyls-spyder 0.4.0-2 ii python3-qdarkstyle2.8.1+ds1-3 ii python3-qtawesome 1.1.1-1 ii python3-qtconsole 5.3.0-1 ii python3-qtpy 2.0.0-3 ii python3-setuptools59.6.0-1.2 ii python3-sphinx4.3.2-1 ii python3-spyder-kernels1.10.2-1 ii python3-textdistance 4.2.2-4 ii python3-three-merge 0.1.1-4 ii python3-watchdog 2.1.7-1 ii python3-xdg 0.27-2 ii python3-zmq 22.3.0-1+b1 ii spyder-common 4.2.1+dfsg1-3 Versions of packages python3-spyder recommends: ii python3-autopep8 1.6.0-1 ii python3-mccabe 0.6.1-3 ii python3-pycodestyle 2.8.0-2 ii python3-pydocstyle 6.1.1-1 ii python3-pyflakes 2.4.0-2 ii python3-rope 0.23.0-1 ii python3-yapf 0.32.0-1 Versions of packages python3-spyder suggests: ii cython3 0.29.28-3 ii python3-matplotlib 3.5.1-2+b1 ii python3-numpy 1:1.21.5-1 ii python3-pandas 1.3.5+dfsg-3 ii python3-pil 9.0.1-1 ii python3-scipy 1.7.3-2 ii python3-sympy 1.9-1 Versions of packages python3-pyqt5 depends on: ii libc6 2.33-7 ii libgcc-s1 12-20220319-1 ii libpython3.10 3.10.4-1 ii libqt5core5a [qtbase-abi-5-15-2] 5.15.2+dfsg-15 ii libqt5dbus5 5.15.2+dfsg-15 ii libqt5designer5 5.15.2-5+b1 ii libqt5gui55.15.2+dfsg-15 ii libqt5help5 5.15.2-5+b1 ii libqt5network55.15.2+dfsg-15 ii libqt5printsupport5 5.15.2+dfsg-15 ii libqt5test5 5.15.2+dfsg-15 ii libqt5widgets55.15.2+dfsg-15 ii libqt5xml55.15.2+dfsg-15 ii libstdc++612-20220319-1 ii python3 3.9.8-1 ii python3-pyqt5.sip 12.9.1-1 -- no debconf information
Bug#1005724: python3-clang-13: python package not advertised enough
Package: python3-clang-13
Version: 1:13.0.1-2
Severity: normal
Dear Maintainer,
I have python3-clang-13 version 1:13.0.1-2 installed and can import it
just fine. However, some tools fail to find the package
$ pip3 check
tensorflow 2.8.0 requires libclang, which is not installed.
$ python3 -c 'from importlib.metadata import version;
print(version("libclang"))'
[...]
importlib.metadata.PackageNotFoundError: libclang
If I run `pip3 install libclang`, those errors disappear. I think it may
be because you don't include libclang-13.0.0.dist-info in the package,
but I am not a pro of python packaging.
-- System Information:
Debian Release: bookworm/sid
APT prefers testing-debug
APT policy: (500, 'testing-debug'), (500, 'stable-security'), (500,
'stable-debug'), (500, 'testing'), (500, 'stable'), (50, 'unstable-debug'),
(50, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.15.0-3-amd64 (SMP w/16 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
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 python3-clang-13 depends on:
ii libclang-13-dev 1:13.0.1-2
ii python3 3.9.7-1
python3-clang-13 recommends no packages.
python3-clang-13 suggests no packages.
-- no debconf information
Bug#1004998: python3-filelock: version 0.0.0
Package: python3-filelock Version: 3.4.2-1 Severity: normal Dear Maintainer, while the version is 3.4.2 $ python3.10 -c "import filelock;print(filelock.__version__)" 3.4.2 the packaging makes it look like it is version 0.0.0. We have the path /usr/lib/python3/dist-packages/filelock-0.0.0.egg-info, the file PKG-INFO says "Version: 0.0.0", etc. One consequence is $ python3.10 -m pip check virtualenv 20.13.0+ds has requirement filelock<4,>=3.2, but you have filelock 0.0.0. and I think any tool based on pkg_resources will be similarly confused. (I have no local packages for python3.10, only the current debian testing system packages) -- System Information: Debian Release: bookworm/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'testing'), (500, 'stable'), (50, 'unstable-debug'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.15.0-3-amd64 (SMP w/16 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE 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 python3-filelock depends on: ii python3 3.9.7-1 python3-filelock recommends no packages. python3-filelock suggests no packages. -- no debconf information
Bug#980376: libinput10: Dell 7x50 touchpad right click
I should mention that this was fixed in testing a long time ago. I am not closing the bug myself in case it motivates a backport for stable, but I am not affected anymore and fine with the bug being closed. -- Marc Glisse
Bug#1003273: pipewire: headset mic not working
On Thu, 27 Jan 2022, Dylan Aïssi wrote: Pipewire 0.3.43 is now in testing, this version includes f8cdc05720bf1. Could you check if it works without having to modify the config file? I've reverted the manual change and rebooted, and the mic still seems to work. Looks fixed :-) -- Marc Glisse
Bug#1003725: python3-prettytable: Advertises version as 0.0.0
Package: python3-prettytable Version: 2.5.0-1 Severity: normal Dear Maintainer, when some tool (like pip3) checks the version of prettytable, it gets 0.0.0. And indeed manually $ ipython3 Python 3.9.9 (main, Jan 10 2022, 10:55:59) Type 'copyright', 'credits' or 'license' for more information IPython 7.31.0 -- An enhanced Interactive Python. Type '?' for help. In [1]: import prettytable In [2]: prettytable.__version__ Out[2]: '0.0.0' If I install the pip version with pip3 install -U prettytable, the same code properly reports '3.0.0'. -- System Information: Debian Release: bookworm/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'testing'), (500, 'stable'), (50, 'unstable-debug'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.15.0-2-amd64 (SMP w/16 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-prettytable depends on: ii python3 3.9.7-1 ii python3-importlib-metadata 4.6.4-1 ii python3-wcwidth 0.1.9+dfsg1-2 python3-prettytable recommends no packages. python3-prettytable suggests no packages. -- no debconf information
Bug#1003273: pipewire: headset mic not working
Package: pipewire Version: 0.3.42-1 Severity: important Dear Maintainer, I have a headset that I connect with a USB dongle. It used to work in December. Today, sound output still works, but not input. I can select the headset as input source in gnome settings, I see it in pavucontrol, etc, but they don't actually get any sound (unlike the internal mic of the laptop, for which I see a bar that moves when I talk). In the log, I first see Jan 7 12:17:57 hippo /usr/libexec/gdm-x-session[1449]: (II) event10 - EPOS EPOS BTD 800 Consumer Control: is tagged by udev as: Keyboard Hmm, no, that's a headset... But whatever, this also happens on a debian stable system where the headset still works. Then Jan 7 11:06:18 hippo pipewire[1542]: spa.alsa: 0x55da812704c8: card already opened at rate:48000 Jan 7 11:06:18 hippo pipewire[1542]: pw.node: (alsa_input.usb-EPOS_EPOS_BTD_800_A000871203310101-00.mono-fallback-93) suspended -> error (Start error: Invalid argument) Jan 7 11:06:18 hippo pipewire[1542]: spa.audioadapter: params Spa:Enum:ParamId:EnumFormat: 0:0 (convert format) Success Jan 7 11:06:18 hippo pipewire[1542]: Object: size 160, type Spa:Pod:Object:Param:Format (262147), id Spa:Enum:ParamId:EnumFormat (3) Jan 7 11:06:18 hippo pipewire[1542]: Prop: key Spa:Pod:Object:Param:Format:mediaType (1), flags Jan 7 11:06:18 hippo pipewire[1542]: Id 1 (Spa:Enum:MediaType:audio) Jan 7 11:06:18 hippo pipewire[1542]: Prop: key Spa:Pod:Object:Param:Format:mediaSubtype (2), flags Jan 7 11:06:18 hippo pipewire[1542]: Id 1 (Spa:Enum:MediaSubtype:raw) Jan 7 11:06:18 hippo pipewire[1542]: Prop: key Spa:Pod:Object:Param:Format:Audio:format (65537), flags Jan 7 11:06:18 hippo pipewire[1542]: Id 259 (Spa:Enum:AudioFormat:S16LE) Jan 7 11:06:18 hippo pipewire[1542]: Prop: key Spa:Pod:Object:Param:Format:Audio:rate (65539), flags Jan 7 11:06:18 hippo pipewire[1542]: Int 16000 Jan 7 11:06:18 hippo pipewire[1542]: Prop: key Spa:Pod:Object:Param:Format:Audio:channels (65540), flags Jan 7 11:06:18 hippo pipewire[1542]: Int 1 Jan 7 11:06:18 hippo pipewire[1542]: Prop: key Spa:Pod:Object:Param:Format:Audio:position (65541), flags Jan 7 11:06:18 hippo pipewire[1542]: Array: child.size 4, child.type Spa:Id Jan 7 11:06:18 hippo pipewire[1542]: Id 2 (Spa:Enum:AudioChannel:MONO) Jan 7 11:06:18 hippo pipewire[1542]: Object: size 216, type Spa:Pod:Object:Param:Format (262147), id Spa:Enum:ParamId:EnumFormat (3) Jan 7 11:06:18 hippo pipewire[1542]: Prop: key Spa:Pod:Object:Param:Format:mediaType (1), flags Jan 7 11:06:18 hippo pipewire[1542]: Id 1 (Spa:Enum:MediaType:audio) Jan 7 11:06:18 hippo pipewire[1542]: Prop: key Spa:Pod:Object:Param:Format:mediaSubtype (2), flags Jan 7 11:06:18 hippo pipewire[1542]: Id 1 (Spa:Enum:MediaSubtype:raw) Jan 7 11:06:18 hippo pipewire[1542]: Prop: key Spa:Pod:Object:Param:Format:Audio:format (65537), flags Jan 7 11:06:18 hippo pipewire[1542]: Choice: type Spa:Enum:Choice:None, flags 24 4 Jan 7 11:06:18 hippo pipewire[1542]: Id 259 (Spa:Enum:AudioFormat:S16LE) Jan 7 11:06:18 hippo pipewire[1542]: Id 259 (Spa:Enum:AudioFormat:S16LE) Jan 7 11:06:18 hippo pipewire[1542]: Prop: key Spa:Pod:Object:Param:Format:Audio:rate (65539), flags Jan 7 11:06:18 hippo pipewire[1542]: Choice: type Spa:Enum:Choice:Range, flags 28 4 Jan 7 11:06:18 hippo pipewire[1542]: Int 16000 Jan 7 11:06:18 hippo pipewire[1542]: Int 48000 Jan 7 11:06:18 hippo pipewire[1542]: Int 16000 Jan 7 11:06:18 hippo pipewire[1542]: Prop: key Spa:Pod:Object:Param:Format:Audio:channels (65540), flags Jan 7 11:06:18 hippo pipewire[1542]: Choice: type Spa:Enum:Choice:None, flags 20 4 Jan 7 11:06:18 hippo pipewire[1542]: Int 1 Jan 7 11:06:18 hippo pipewire[1542]: Prop: key Spa:Pod:Object:Param:Format:Audio:position (65541), flags Jan 7 11:06:18 hippo pipewire[1542]: Array: child.size 4, child.type Spa:Id Jan 7 11:06:18 hippo pipewire[1542]: Id 2 (Spa:Enum:AudioChannel:MONO) Jan 7 11:06:18 hippo pipewire[1542]: spa.audioadapter: failed filter: Jan 7 11:06:30 hippo pipewire[1542]: spa.audioadapter: params Spa:Enum:ParamId:EnumFormat: 0:0 (convert format) Success Jan 7 11:06:30 hippo pipewire[1542]: Object: size 160, type Spa:Pod:Object:Param:Format (262147), id Spa:Enum:ParamId:EnumFormat (3) etc I have packages (with "wire") gstreamer1.0-pipewire:amd64/testing 0.3.42-1 uptodate libpipewire-0.3-0:amd64/testing 0.3.42-1 uptodate libpipewire-0.3-common:all/testing 0.3.42-1 uptodate libpipewire-0.3-modules:amd64/testing 0.3.42-1 uptodate libwireplumber-0.4-0:amd64/testing 0.4.5-1 uptodate pipewire:amd64/testing 0.3.
Bug#1002857: libgoogle-glog-dev: Dependency on libunwind-dev
Package: libgoogle-glog-dev Version: 0.5.0+really0.4.0-2 Severity: normal Dear Maintainer, with the switch to llvm-13 in testing, installing libgoogle-glog-dev has become problematic, it depends on libunwind-dev, but that conflicts with libunwind-13-dev. I couldn't find an official doc on what the LLVM maintainers expect, but it looks like depending on libunwind-x.y-dev may work. I didn't test it though, some libunwind files seem to have moved, and I may have completely misunderstood the relation between the various libunwind packages. -- System Information: Debian Release: bookworm/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'testing'), (500, 'stable'), (50, 'unstable-debug'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.15.0-2-amd64 (SMP w/16 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libgoogle-glog-dev depends on: ii libgflags-dev 2.2.2-2 ii libgoogle-glog0v5 0.5.0+really0.4.0-2 ii libunwind-dev 1.3.2-2 libgoogle-glog-dev recommends no packages. libgoogle-glog-dev suggests no packages. -- no debconf information
Bug#1000708: python3-pot: Incompatible numpy version
Package: python3-pot Version: 0.8.0+dfsg-2+b1 Severity: normal Dear Maintainer, trying to use POT, I see $ python3 Python 3.9.9 (main, Nov 16 2021, 10:24:31) [GCC 11.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import ot Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3/dist-packages/ot/__init__.py", line 26, in from . import lp File "/usr/lib/python3/dist-packages/ot/lp/__init__.py", line 22, in from .emd_wrap import emd_c, check_result, emd_1d_sorted File "ot/lp/emd_wrap.pyx", line 1, in init ot.lp.emd_wrap ValueError: numpy.ndarray size changed, may indicate binary incompatibility. Expected 88 from C header, got 80 from PyObject Maybe this package needs a dependency like python3-numpy-abi9? I am surprised lintian doesn't report missing-dependency-on-numpy-abi for this package if that's the case. -- System Information: Debian Release: bookworm/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'testing'), (500, 'stable'), (50, 'unstable-debug'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.15.0-1-amd64 (SMP w/16 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-pot depends on: ii libc6 2.32-4 ii libgcc-s1 11.2.0-10 ii libgomp1 11.2.0-10 ii libstdc++6 11.2.0-10 ii python33.9.7-1 ii python3-numpy 1:1.19.5-1 ii python3-scipy 1.7.1-2 Versions of packages python3-pot recommends: ii python3-sklearn 0.23.2-5 python3-pot suggests no packages. -- no debconf information
Bug#993337: gcc-11-base: changelog.Debian.gz multiarch inconsistency
Package: gcc-11-base Version: 11.2.0-3 Severity: normal Dear Maintainer, while upgrading other packages, I got Preparing to unpack .../0-gcc-11-base_11.2.0-3_mips64el.deb ... Unpacking gcc-11-base:mips64el (11.2.0-3) ... dpkg: error processing archive /tmp/apt-dpkg-install-bFwhF7/0-gcc-11-base_11.2.0-3_mips64el.deb (--unpack): trying to overwrite shared '/usr/share/doc/gcc-11-base/changelog.Debian.gz', which is different from other instances of package gcc-11-base:mips64el -- System Information: Debian Release: bookworm/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'testing'), (400, 'stable'), (50, 'unstable-debug'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64, ppc64el, mips64el, s390x, armhf Kernel: Linux 5.10.0-8-amd64 (SMP w/16 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information
Bug#993329: libcgal-dev: CGAL/Qt/AlphaShapeGraphicsItem.h in the wrong subpackage?
Package: libcgal-dev Version: 5.3-2 Severity: normal Dear Maintainer, during a partial upgrade, I got The following packages will be upgraded: libcgal-dev libcgal-dev:i386 libcgal-dev:arm64 libcgal-dev:ppc64el libcgal-dev:mips64el libcgal-dev:s390x libcgal-dev:armhf [...] Preparing to unpack .../0-libcgal-dev_5.3-2_armhf.deb ... De-configuring libcgal-dev:s390x (5.2-3) ... De-configuring libcgal-dev:ppc64el (5.2-3) ... De-configuring libcgal-dev:mips64el (5.2-3) ... De-configuring libcgal-dev:i386 (5.2-3) ... De-configuring libcgal-dev:arm64 (5.2-3) ... De-configuring libcgal-dev:amd64 (5.2-3) ... Unpacking libcgal-dev:armhf (5.3-2) over (5.2-3) ... dpkg: error processing archive /tmp/apt-dpkg-install-niPV4E/0-libcgal-dev_5.3-2_armhf.deb (--unpack): trying to overwrite '/usr/include/CGAL/Qt/AlphaShapeGraphicsItem.h', which is also in package libcgal-qt5-dev:mips64el 5.2-3 dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) I am surprised that this header is now in libcgal-dev. If it is there on purpose, some conflicts/replaces fields might be in order. -- System Information: Debian Release: 11.0 APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'testing'), (400, 'stable'), (50, 'unstable-debug'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64, ppc64el, mips64el, s390x, armhf Kernel: Linux 5.10.0-8-amd64 (SMP w/16 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libcgal-dev depends on: ii libboost-dev 1.74.0.3 ii libboost-program-options-dev 1.74.0.3 ii libboost-system-dev 1.74.0.3 ii libboost-thread-dev 1.74.0.3 ii libgmp-dev2:6.2.1+dfsg-1 ii libmpfr-dev 4.1.0-3 ii zlib1g-dev1:1.2.11.dfsg-2 libcgal-dev recommends no packages. Versions of packages libcgal-dev suggests: ii libmpfi-dev 1.5.3+ds-5 ii libntl-dev 11.4.3-1+b1 ii libtbb-dev 2020.3-1 -- no debconf information
Bug#960893: libc++-10-dev: Can't coinstall multiple libc++-dev versions
Hello, just some simple ideas: 1) One way would be to replace the explicit symlinks in /usr/lib/$triplet with alternatives. For instance, in a postinst.in update-alternatives --install /usr/lib/@DEB_HOST_MULTIARCH@/libc++.so libc++.so-@DEB_HOST_MULTIARCH@ /usr/lib/llvm-@VERSION_MAJOR@/lib/libc++.so @VERSION_MAJOR@ --slave /usr/lib/@DEB_HOST_MULTIARCH@/libc++.a libc++.a-@DEB_HOST_MULTIARCH@ /usr/lib/llvm-@VERSION_MAJOR@/lib/libc++.a + the corresponding remove in prerm.in and corresponding sed line in rules (see for instance the package "lapack"). And others for libc++.so.1, libc++abi.so, libc++abi.so.1, maybe more (libomp5?). Using the major version number as priority makes sense to me, but it could also be major*100 for regular toolchains and just major for snapshots or whatever. 2) Imitate gcc, where all the gcc-X packages produce / use libstdc++6 (no version), so we end up with only the most recent one installed. 3) Move the symlinks to the unversioned packages, libc++1-11 would provide the files in /usr/lib/llvm-11/lib, and libc++1 would provide the symlink in /usr/lib/$triplet. And I am sure there are many possible variations, for instance changing the granularity of the choice (just a symlink /usr/lib/llvm to /usr/lib/llvm-11?) If we look at the output of clang++ -v when linking, there is -L/usr/lib/llvm-11/lib, but it comes after -L/usr/lib/$triplet, so even for ideas 1 and 3 and even for static linking, this would end up linking with the default version, as if we had gone with idea 2. I don't know if that's deliberate or a bug. -- Marc Glisse
Bug#982839: faiss: Clarify description about GPU
Source: faiss Version: 1.6.5-1 Severity: normal Dear Maintainer, the Description: field of the faiss packages is a bit misleading. It says "Some of the most useful algorithms are implemented on the GPU.", but I was suspicious when I didn't see anything GPU-related in the dependencies, and indeed after getting the sources I saw in debian/rules -DFAISS_ENABLE_GPU=OFF. Could you clarify the description please? For instance, python3-torch has "This is the CPU-only version of [...]". (of course if you can make a GPU-enabled package for contrib, that would be great, but I am sure you already know that and it isn't the purpose of this report) Thanks to the AI team for the nice work they are doing these days. -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'stable-debug'), (500, 'testing'), (500, 'stable'), (50, 'unstable-debug'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-3-amd64 (SMP w/16 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE 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
Bug#982679: RFP: keops -- Kernel Operations on the GPU, with autodiff, without memory overflows
Package: wnpp Severity: wishlist * Package name: keops Version : 1.4.2 * URL : https://github.com/getkeops/keops * License : MIT Programming Lang: C++, Cuda Description : Kernel Operations on the GPU, with autodiff, without memory overflows The KeOps library lets you compute generic reductions of very large arrays whose entries are given by a mathematical formula. It combines a tiled reduction scheme with an automatic differentiation engine, and can be used through Matlab, Python (NumPy or PyTorch) or R backends. It is perfectly suited to the computation of Kernel matrix-vector products and the associated gradients, even when the full kernel matrix does not fit into the GPU memory. --- I am particularly interested in the python interface (PyKeOps). While this package requires cuda so it can work on the GPU, it also has a useful CPU mode that is usable in 100% free software. I don't know how easy/hard it would be to split between main, contrib (and non-free?) though. The python GPU mode requires some suitable versions of pytorch (new versions of pytorch sometimes break it), and a C++ compiler compatible with cuda (which usually means 1 or 2 versions older than current in debian), so it is helpful if packaging ensures a working combination of packages. I use pykeops directly, but it is also a dependency for other useful packages like geomloss (http://www.kernel-operations.io/geomloss/). I am not planning on packaging it myself, sorry.
Bug#980376: libinput10: Dell 7x50 touchpad right click
Just to confirm: I built the upstream master branch of libinput and installed it manually in /usr/local, and all the buttons are working fine now :-) -- Marc Glisse
Bug#980376: libinput10: Dell 7x50 touchpad right click
Package: libinput10 Version: 1.16.4-3 Severity: normal Dear Maintainer, I recently installed Debian testing on a new Dell Precision 7550. This has 3 physical buttons under the trackpad. And I had the surprise that only the left and middle ones were working (although at some point I think I got evtest or a similar program to see something for the right one, so it doesn't seem physically broken). Right clicks with an external mouse work just fine. In syslog, I see Jan 18 13:19:01 hippo gnome-shell[1590]: libinput error: event14 - DELL09C3:00 0488:120A Touchpad: kernel bug: received BTN_RIGHT button event on a clickpad A search with these strings led me to libinput merge request !516 (there are more details in the earlier !481) which seems to be precisely about my issue, and has a fix in master, although not in the 1.16 branch because it requires a recent libevdev. Since Debian seems to have a recent enough libevdev, I was wondering if you would be willing to backport that patch? Unless you think that release 1.17 is just around the corner. (I did not try building libinput from the master branch yet) -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'stable-debug'), (500, 'testing'), (500, 'stable'), (50, 'unstable-debug'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-1-amd64 (SMP w/16 CPU threads) Kernel taint flags: TAINT_DIE, TAINT_WARN 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 libinput10 depends on: ii libc6 2.31-9 ii libevdev2 1.10.0+dfsg-1 ii libinput-bin 1.16.4-3 ii libmtdev1 1.1.6-1 ii libudev1 247.2-4 ii libwacom2 1.7-1 libinput10 recommends no packages. libinput10 suggests no packages. -- no debconf information
Bug#976069: python3-flatbuffers: Empty package
Package: python3-flatbuffers Version: 1.12.1~git20200711.33e2d80+dfsg1-0.3 Severity: grave Justification: renders package unusable Dear Maintainer, I installed python3-flatbuffers and had the surprise that, in python3, "import flatbuffers" was still giving ModuleNotFoundError: No module named 'flatbuffers' I then checked $ dpkg -L python3-flatbuffers /. /usr /usr/share /usr/share/doc /usr/share/doc/python3-flatbuffers /usr/share/doc/python3-flatbuffers/changelog.Debian.gz /usr/share/doc/python3-flatbuffers/copyright It appears that the package is empty? The package has no Depends: and the description says "This package contains python3 flatbuffers API." so it looks like a bug to me... -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'stable'), (50, 'unstable-debug'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.8.0-3-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information
Bug#971617: closed by Debian FTP Masters (reply to Dominique Dumont ) (Bug#971617: fixed in nqp 2020.09+dfsg-3)
On Sun, 4 Oct 2020, Debian Bug Tracking System wrote:
* rules: copy stage2/*.nqp (Closes: 971617)
I tried on a different computer today, with version 2020.09+dfsg-3 of nqp
/ nqp-data, and while /usr/share/nqp/lib/MASTNodes.nqp exists, I still get
Setting up rakudo (2020.09+dfsg-1) ...
rakudo-helper.pl: Reinstalling all perl6 modules ...
(1/3) reinstall: perl6-tap-harness
Unhandled exception: Missing or wrong version of dependency
'gen/moar/stage2/MASTNodes.nqp' (from 'gen/moar/Pod.nqp')
at :1
(/usr/lib/perl6/lib/Perl6/Pod.moarvm:)
from src/vm/moar/ModuleLoader.nqp:47 (/usr/share/nqp/lib/ModuleLoader.moarvm:)
from src/vm/moar/ModuleLoader.nqp:40
(/usr/share/nqp/lib/ModuleLoader.moarvm:load_module)
from :1
(/usr/lib/perl6/lib/Perl6/Actions.moarvm:)
from src/vm/moar/ModuleLoader.nqp:47 (/usr/share/nqp/lib/ModuleLoader.moarvm:)
from src/vm/moar/ModuleLoader.nqp:40
(/usr/share/nqp/lib/ModuleLoader.moarvm:load_module)
from :1
(/usr/lib/perl6/lib/Perl6/Grammar.moarvm:)
from src/vm/moar/ModuleLoader.nqp:47 (/usr/share/nqp/lib/ModuleLoader.moarvm:)
from src/vm/moar/ModuleLoader.nqp:40
(/usr/share/nqp/lib/ModuleLoader.moarvm:load_module)
from :1
(/usr/lib/perl6/runtime/perl6.moarvm:)
"perl6 /usr/share/perl6/tools/install-dist.p6
--from=/usr/share/perl6/debian-sources/perl6-tap-harness --to=/tmp/0Hj4j1tYTl/build
--for=vendor" un
expectedly returned exit value 1 at /usr/share/perl5/IPC/System/Simple.pm line
578.
IPC::System::Simple::_check_exit("perl6
/usr/share/perl6/tools/install-dist.p6 --from=/usr/shar"..., 1,
ARRAY(0x561b1f0fd8b8)) called at /
usr/share/perl5/IPC/System/Simple.pm line 550
IPC::System::Simple::_process_child_error(256, "perl6 /usr/share/perl6/tools/install-dist.p6 --from=/usr/shar"..., ARRAY(0x561b1f0fd8b8))
called at /usr/share/perl5/IPC/System/Simple.pm line 190
IPC::System::Simple::run("perl6 /usr/share/perl6/tools/install-dist.p6
--from=/usr/shar"...) called at (eval 29) line 12
eval {...} called at (eval 29) line 11
Fatal::__ANON__("perl6 /usr/share/perl6/tools/install-dist.p6
--from=/usr/shar"...) called at /usr/share/perl6/rakudo-helper.pl line 47
main::install("perl6-tap-harness") called at
/usr/share/perl6/rakudo-helper.pl line 109
main::reinstall_all() called at /usr/share/perl6/rakudo-helper.pl line
151
at /usr/share/perl6/rakudo-helper.pl line 47
dpkg: error processing package rakudo (--configure):
installed rakudo package post-installation script subprocess returned error
exit status 1
Errors were encountered while processing:
rakudo
(in strace -f, I don't even see it look for those .nqp files)
--
Marc Glisse
Bug#971617: rakudo: failed upgrade: Missing or wrong version of dependency 'gen/moar/stage2/MASTNodes.nqp'
Package: rakudo
Version: 2020.09+dfsg-1
Severity: important
Dear Maintainer,
on a computer that was up-to-date with testing yesterday, I ran "apt
upgrade" this morning, which tried updating rakudo/nqp/moarvm, but
failed with
Setting up rakudo (2020.09+dfsg-1) ...
rakudo-helper.pl: Reinstalling all perl6 modules ...
(1/3) reinstall: perl6-zef
Unhandled exception: Missing or wrong version of dependency
'gen/moar/stage2/MASTNodes.nqp' (from 'gen/moar/Pod.nqp')
at :1
(/usr/lib/perl6/lib/Perl6/Pod.moarvm:)
from src/vm/moar/ModuleLoader.nqp:47 (/usr/share/nqp/lib/ModuleLoader.moarvm:)
from src/vm/moar/ModuleLoader.nqp:40
(/usr/share/nqp/lib/ModuleLoader.moarvm:load_module)
from :1
(/usr/lib/perl6/lib/Perl6/Actions.moarvm:)
from src/vm/moar/ModuleLoader.nqp:47 (/usr/share/nqp/lib/ModuleLoader.moarvm:)
from src/vm/moar/ModuleLoader.nqp:40
(/usr/share/nqp/lib/ModuleLoader.moarvm:load_module)
from :1
(/usr/lib/perl6/lib/Perl6/Grammar.moarvm:)
from src/vm/moar/ModuleLoader.nqp:47 (/usr/share/nqp/lib/ModuleLoader.moarvm:)
from src/vm/moar/ModuleLoader.nqp:40
(/usr/share/nqp/lib/ModuleLoader.moarvm:load_module)
from :1
(/usr/lib/perl6/runtime/perl6.moarvm:)
"perl6 /usr/share/perl6/tools/install-dist.p6
--from=/usr/share/perl6/debian-sources/perl6-zef --to=/tmp/qzgpwdSHG6/build
--for=vendor" unexpected
ly returned exit value 1 at /usr/share/perl5/IPC/System/Simple.pm line 578.
IPC::System::Simple::_check_exit("perl6
/usr/share/perl6/tools/install-dist.p6 --from=/usr/shar"..., 1,
ARRAY(0x55ccaf960dd0)) called at /
usr/share/perl5/IPC/System/Simple.pm line 550
IPC::System::Simple::_process_child_error(256, "perl6
/usr/share/perl6/tools/install-dist.p6 --from=/usr/shar"...,
ARRAY(0x55ccaf960dd0))
called at /usr/share/perl5/IPC/System/Simple.pm line 190
IPC::System::Simple::run("perl6 /usr/share/perl6/tools/install-dist.p6
--from=/usr/shar"...) called at (eval 25) line 12
eval {...} called at (eval 25) line 11
Fatal::__ANON__("perl6 /usr/share/perl6/tools/install-dist.p6
--from=/usr/shar"...) called at /usr/share/perl6/rakudo-helper.pl line 47
main::install("perl6-zef") called at /usr/share/perl6/rakudo-helper.pl
line 109
main::reinstall_all() called at /usr/share/perl6/rakudo-helper.pl line
151
at /usr/share/perl6/rakudo-helper.pl line 47
dpkg: error processing package rakudo (--configure):
installed rakudo package post-installation script subprocess returned error
exit status 1
Running "apt install -f" now gives the same error. I hesitated about
filing this with perl6-zef 0.8.5-2 instead of rakudo...
-- System Information:
Debian Release: bullseye/sid
APT prefers testing-debug
APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'stable'), (50,
'unstable-debug'), (50, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.8.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages rakudo depends on:
ii libc6 2.31-3
ii libgraph-perl 1:0.9704-1
ii libipc-system-simple-perl 1.30-1
ii libpath-tiny-perl 0.114-1
ii moarvm 2020.09+dfsg-1
ii nqp2020.09+dfsg-2
rakudo recommends no packages.
Versions of packages rakudo suggests:
ii valgrind 1:3.16.1-1
-- no debconf information
Bug#963991: libmkl-rt: libomp-dev dependency too strict
Package: libmkl-rt Version: 2020.1.217-2 Severity: normal Dear Maintainer, I would like to install libomp-11-dev on this computer, but libmkl-rt has a dependency on libomp-dev | libomp-7-dev | libomp-8-dev, and the versions of libomp conflict with each other. As far as I know, llvm aims to keep a compatible ABI on this library. Would it be possible to extend the list of alternatives to more recent libomp-*-dev? You could even preventively add libomp-12-dev so you don't have to add it later. I don't know if it would be ok to depend on the virtual libomp-x.y-dev. Or maybe the dependency could be downgraded to a recommendation, since when it cannot find libiomp5.so it seems to fall back to sequential mode? With MKL_THREADING_LAYER=GNU and a suitable LD_LIBRARY_PATH (gcc's libgomp.so is a bit hidden), it even seems possible to use a threaded mkl without libomp, although that may be asking a bit much from users. I only did some extremely basic testing, I may be completely wrong about things actually "working". (I could probably work around this by rebuilding libomp-dev to depend on the libomp-*-dev I want, or creating fake packages) -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'stable-debug'), (500, 'testing'), (400, 'stable'), (50, 'unstable-debug'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64, ppc64el, mips64el Kernel: Linux 5.6.0-2-amd64 (SMP w/16 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libmkl-rt depends on: ii debconf [debconf-2.0] 1.5.74 ii libatlas3-base [liblapack.so.3]3.10.3-10 ii libblas3 [libblas.so.3]3.9.0-2 ii libc6 2.30-8 ii libgcc-5-dev 5.5.0-12 ii libgcc-6-dev 6.5.0-2 ii libgcc-8-dev 8.4.0-4 ii liblapack3 [liblapack.so.3]3.9.0-2 ii libmkl-locale 2020.1.217-2 ii libmkl-meta-computational 2020.1.217-2 ii libmkl-meta-interface 2020.1.217-2 ii libmkl-meta-threading 2020.1.217-2 ii libomp-dev 1:9.0-49.1 ii libopenblas0-pthread [liblapack.so.3] 0.3.9+ds-3 ii libtbb-dev 2020.2-2 libmkl-rt recommends no packages. libmkl-rt suggests no packages. -- debconf information: * libmkl-rt/use-as-default-blas-lapack: true libmkl-rt/title: * libmkl-rt/exact-so-3-selections: libblas.so.3, liblapack.so.3
Bug#798955: [PATCH] libstdc++: don't use #include_next in c_global headers
On Mon, 20 Apr 2020, Helmut Grohne wrote: Now you are probably going to say that "-isystem /usr/include" is a bad idea and that you shouldn't do that. I'm inclined to agree. This isn't a problem just yet. Debian wants to move /usr/include/stdlib.h to /usr/include//stdlib.h. After that move, the problematic flag becomes "-isystem /usr/include/". Unfortunately, around 30 Debian packages[1] do pass exactly that flag. Regardless whether doing so is a bad idea, I guess we will have to support that. Urgh, no to "support that". I don't like those #include_next of a header with a different name and wouldn't mind seeing them go. But even if your patch, or some other patch, happens to make things kind of work, please do **not** consider this a supported feature, and keep fixing those broken packages (including the big bad cmake which regularly adds such flags to innocent packages). With (or without) your patch, if a user has the bad -isystem and does #include , it will never see libstdc++'s version of stdlib.h, which contains important extra content, so that's still not working properly. -- Marc Glisse
Bug#956870: gnome-shell: Incompatible versions in testing
On Thu, 16 Apr 2020, Simon McVittie wrote: so it would be nice either to downgrade the packages that just migrated to testing, or to boost the migration of gnome-shell to testing This is not something that the maintainers can do unilaterally. We have to rely on the release team to get the new version migrated. Indeed. Documenting this in this bug was also a way to advertise the workaround (google didn't give anything useful when I searched for this particular error message), and to provide information to the release team to help them prioritize things. I didn't mean to imply that the maintainers of this specific package could solve everything, it was just the most natural entry point for me as a user. Thank you for your explanations. -- Marc Glisse
Bug#956870: gnome-shell: Incompatible versions in testing
Package: gnome-shell Version: 3.36.1-5 Severity: important Dear Maintainer, this morning, I ran apt upgrade on a debian testing system, which upgraded a number of packages, including some gnome-related ones 2020-04-16 07:55:37 upgrade nvidia-opencl-common:amd64 440.64-2 440.82-1 2020-04-16 07:55:37 upgrade nvidia-vulkan-common:amd64 440.64-2 440.82-1 2020-04-16 07:55:37 upgrade nvidia-vulkan-icd:amd64 440.64-2 440.82-1 2020-04-16 07:55:38 upgrade libnvidia-glvkspirv:amd64 440.64-2 440.82-1 2020-04-16 07:55:38 upgrade nvidia-driver:amd64 440.64-2 440.82-1 2020-04-16 07:55:39 upgrade nvidia-driver-libs:amd64 440.64-2 440.82-1 2020-04-16 07:55:39 upgrade libgl1-nvidia-glvnd-glx:amd64 440.64-2 440.82-1 2020-04-16 07:55:39 upgrade libgl1-nvidia-glvnd-glx:i386 440.64-2 440.82-1 2020-04-16 07:55:40 upgrade libglx-nvidia0:i386 440.64-2 440.82-1 2020-04-16 07:55:40 upgrade libglx-nvidia0:amd64 440.64-2 440.82-1 2020-04-16 07:55:40 upgrade xserver-xorg-video-nvidia:amd64 440.64-2 440.82-1 2020-04-16 07:55:41 upgrade libnvidia-glcore:amd64 440.64-2 440.82-1 2020-04-16 07:55:42 upgrade libnvidia-glcore:i386 440.64-2 440.82-1 2020-04-16 07:55:43 upgrade nvidia-egl-common:amd64 440.64-2 440.82-1 2020-04-16 07:55:43 upgrade libgles-nvidia2:amd64 440.64-2 440.82-1 2020-04-16 07:55:43 upgrade nvidia-egl-icd:amd64 440.64-2 440.82-1 2020-04-16 07:55:44 upgrade libegl-nvidia0:amd64 440.64-2 440.82-1 2020-04-16 07:55:44 upgrade libnvidia-eglcore:amd64 440.64-2 440.82-1 2020-04-16 07:55:45 upgrade nvidia-smi:amd64 440.64-2 440.82-1 2020-04-16 07:55:45 upgrade libnvidia-ml1:amd64 440.64-2 440.82-1 2020-04-16 07:55:45 upgrade nvidia-driver-bin:amd64 440.64-2 440.82-1 2020-04-16 07:55:46 upgrade nvidia-vdpau-driver:amd64 440.64-2 440.82-1 2020-04-16 07:55:46 upgrade nvidia-kernel-support:amd64 440.64-2 440.82-1 2020-04-16 07:55:46 upgrade nvidia-kernel-dkms:amd64 440.64-2 440.82-1 2020-04-16 07:56:02 upgrade libnvidia-cfg1:amd64 440.64-2 440.82-1 2020-04-16 07:56:03 upgrade nvidia-opencl-icd:amd64 440.64-2 440.82-1 2020-04-16 07:56:03 upgrade libnvcuvid1:amd64 440.64-2 440.82-1 2020-04-16 07:56:04 upgrade libnvidia-opticalflow1:amd64 440.64-2 440.82-1 2020-04-16 07:56:04 upgrade libnvidia-ifr1:amd64 440.64-2 440.82-1 2020-04-16 07:56:04 upgrade libnvidia-fbc1:amd64 440.64-2 440.82-1 2020-04-16 07:56:05 upgrade libnvidia-encode1:amd64 440.64-2 440.82-1 2020-04-16 07:56:05 upgrade libcuda1:amd64 440.64-2 440.82-1 2020-04-16 07:56:05 upgrade nvidia-alternative:amd64 440.64-2 440.82-1 2020-04-16 07:56:06 upgrade libnvidia-compiler:amd64 440.64-2 440.82-1 2020-04-16 07:56:07 upgrade libnvidia-fatbinaryloader:amd64 440.64-2 440.82-1 2020-04-16 07:56:07 upgrade libnvidia-ptxjitcompiler1:amd64 440.64-2 440.82-1 2020-04-16 07:56:08 upgrade nvidia-legacy-check:amd64 440.64-2 440.82-1 2020-04-16 07:56:08 upgrade cdbs:all 0.4.159 0.4.161 2020-04-16 07:56:09 upgrade libcheese8:amd64 3.34.0-1+b1 3.34.0-1+b2 2020-04-16 07:56:09 upgrade libcheese-gtk25:amd64 3.34.0-1+b1 3.34.0-1+b2 2020-04-16 07:56:09 upgrade gnome-desktop3-data:all 3.34.2-2 3.36.1-2 2020-04-16 07:56:10 upgrade cheese:amd64 3.34.0-1+b1 3.34.0-1+b2 2020-04-16 07:56:10 upgrade libcupsfilters1:amd64 1.27.3-1 1.27.4-1+b1 2020-04-16 07:56:11 upgrade cups-filters-core-drivers:amd64 1.27.3-1 1.27.4-1+b1 2020-04-16 07:56:11 upgrade libfontembed1:amd64 1.27.3-1 1.27.4-1+b1 2020-04-16 07:56:12 upgrade cups-filters:amd64 1.27.3-1 1.27.4-1+b1 2020-04-16 07:56:12 upgrade eog:amd64 3.36.1-1 3.36.1-1+b1 2020-04-16 07:56:14 upgrade gir1.2-gnomedesktop-3.0:amd64 3.34.2-2 3.36.1-2 2020-04-16 07:56:15 upgrade nautilus:amd64 3.36.1.1-1 3.36.1.1-1+b1 2020-04-16 07:56:16 upgrade libnautilus-extension-dev:amd64 3.36.1.1-1 3.36.1.1-1+b1 2020-04-16 07:56:16 upgrade libnautilus-extension1a:amd64 3.36.1.1-1 3.36.1.1-1+b1 2020-04-16 07:56:16 upgrade gir1.2-nautilus-3.0:amd64 3.36.1.1-1 3.36.1.1-1+b1 2020-04-16 07:56:17 upgrade libtotem0:amd64 3.34.1-2 3.34.1-2+b1 2020-04-16 07:56:17 upgrade totem-plugins:amd64 3.34.1-2 3.34.1-2+b1 2020-04-16 07:56:17 upgrade totem:amd64 3.34.1-2 3.34.1-2+b1 2020-04-16 07:56:18 upgrade gir1.2-totem-1.0:amd64 3.34.1-2 3.34.1-2+b1 2020-04-16 07:56:18 upgrade gnome-clocks:amd64 3.36.0-1 3.36.0-1+b1 2020-04-16 07:56:23 upgrade gnome-contacts:amd64 3.36-1 3.36-1+b1 2020-04-16 07:56:25 upgrade gnome-settings-daemon:amd64 3.36.0-1 3.36.0-1+b1 2020-04-16 07:56:25 upgrade gnome-control-center:amd64 1:3.36.1-1 1:3.36.1-1+b1 2020-04-16 07:56:26 upgrade gnome-documents:amd64 3.34.0-1 3.34.0-1+b1 2020-04-16 07:56:26 upgrade libgnome-panel0:amd64 3.36.1-1 3.36.1-1+b1 2020-04-16 07:56:27 upgrade gnome-flashback:amd64 3.36.1-1 3.36.1-1+b1 2020-04-16 07:56:27 upgrade gnome-font-viewer:amd64 3.34.0-2 3.34.0-2+b1 2020-04-16 07:56:27 upgrade gnome-panel:amd64 3.36.1-1 3.36.1-1+b1 2020-04-16 07:56:28 upgrade nautilus-extension-gnome-terminal:amd64 3.36.1.1-1 3.36.1.1-2 2020-04-16 07:56:28 upgrade gnome-terminal-data:all 3.36.1.1-1 3.36.1.1-2 2020-04-16 07:56:29 upgrade gnome-terminal:amd64
Bug#950811: python3-pybind11: Wrong path returned by get_include
Package: python3-pybind11
Version: 2.4.3-2
Severity: minor
Dear Maintainer,
>>> import pybind11
>>> pybind11.get_include(True)
'/home/glisse/.local/include/python3.7m'
>>> pybind11.get_include(False)
'/usr/local/include/python3.7'
$ python3 -m pybind11 --includes
-I/usr/include/python3.7m -I/usr/local/include/python3.7
-I/home/glisse/.local/include/python3.7m
None of those paths correspond to the place where pybind11 headers are
actually installed (/usr/include). In most cases it won't matter much
because the compiler will look in /usr/include by default. I wonder if
the body of the function should be replaced with print('/usr/include')
on a platform like Debian...
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500,
'testing'), (500, 'stable'), (50, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.4.0-3-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
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 python3-pybind11 depends on:
ii pybind11-dev 2.4.3-2
ii python3 3.7.5-3
Versions of packages python3-pybind11 recommends:
ii python3-numpy 1:1.17.4-5
python3-pybind11 suggests no packages.
-- no debconf information
Bug#949475: python3-gudhi: Enable Wasserstein distance module
I have no idea right now if the dependency on POT is a long term thing, or if it will disappear in a couple releases. Off-topic for Debian, I guess, but: Have you considered Hera as a way to get efficient Wasserstein distances? https://github.com/GUDHI/gudhi-devel/pull/182 Yes I have, it is likely to be in the next release ;-) - Someone wrote the POT version first, it was easier to merge - The POT version is "exact" and faster than Hera for small point sets - We are going to need the matching soon, not just the cost, and Hera doesn't provide that yet. -- Marc Glisse
Bug#949475: python3-gudhi: Enable Wasserstein distance module
The Wasserstein module will become functional when POT is packaged (see #949381). In case a user is wondering: if you have python3-gudhi and run "pip3 install POT", the Wasserstein module will work, this is only a runtime dependency. Of course it will be even better with a Debian package of POT :-) I have no idea right now if the dependency on POT is a long term thing, or if it will disappear in a couple releases. -- Marc Glisse
Bug#949800: libcgal-qt5-dev: Recommend qt?
Package: libcgal-qt5-dev Version: 5.0-5+b1 Severity: wishlist Dear Maintainer, I notice that libcgal-qt5-dev does not depend in any way on Qt and does not even suggest installing any Qt packages. Before header-only, it depended on libcgal-qt5-13, which in turn installed several Qt dependencies, although probably not enough to do development. It looks like the Suggestions in libcgal-demo are the only ones that actually install Qt dev packages. Do you think it would make sense to have libcgal-qt5-dev recommend some Qt packages? I don't know how much one can do with this package without Qt (I haven't tried). -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'testing'), (500, 'stable'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-2-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE 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 libcgal-qt5-dev depends on: ii libcgal-dev 5.0-5+b1 libcgal-qt5-dev recommends no packages. libcgal-qt5-dev suggests no packages. -- no debconf information
Bug#946673: mercurial: zstd decompressor error: Unknown frame descriptor
Package: mercurial Version: 5.2.1-1 Severity: normal Dear Maintainer, I don't know when exactly this started, but it can't be too long ago. Today I see $ hg clone https://gmplib.org/repo/gmp destination directory: gmp requesting all changes ** unknown exception encountered, please report by visiting ** https://mercurial-scm.org/wiki/BugTracker ** Python 2.7.17 (default, Oct 19 2019, 23:36:22) [GCC 9.2.1 20191008] ** Mercurial Distributed SCM (version 5.2.1) ** Extensions loaded: extdiff, pager Traceback (most recent call last): File "/usr/bin/hg", line 36, in dispatch.run() File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 111, in run status = dispatch(req) File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 250, in dispatch ret = _runcatch(req) or 0 File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 424, in _runcatch return _callcatch(ui, _runcatchfunc) File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 433, in _callcatch return scmutil.callcatch(ui, func) File "/usr/lib/python2.7/dist-packages/mercurial/scmutil.py", line 177, in callcatch return func() File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 414, in _runcatchfunc return _dispatch(req) File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 1174, in _dispatch lui, repo, cmd, fullargs, ui, options, d, cmdpats, cmdoptions File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 862, in runcommand ret = _runcommand(ui, options, cmd, d) File "/usr/lib/python2.7/dist-packages/hgext/pager.py", line 76, in pagecmd return orig(ui, options, cmd, cmdfunc) File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 1185, in _runcommand return cmdfunc() File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 1171, in d = lambda: util.checksignature(func)(ui, *args, **strcmdopt) File "/usr/lib/python2.7/dist-packages/mercurial/util.py", line 1845, in check return func(*args, **kwargs) File "/usr/lib/python2.7/dist-packages/mercurial/commands.py", line 1925, in clone depth=opts.get(b'depth') or None, File "/usr/lib/python2.7/dist-packages/mercurial/hg.py", line 901, in clone depth=depth, File "/usr/lib/python2.7/dist-packages/mercurial/exchange.py", line 1780, in pull _fullpullbundle2(repo, pullop) File "/usr/lib/python2.7/dist-packages/mercurial/exchange.py", line 1673, in _fullpullbundle2 _pullbundle2(pullop) File "/usr/lib/python2.7/dist-packages/mercurial/exchange.py", line 1976, in _pullbundle2 bundle = e.callcommand(b'getbundle', args).result() File "/usr/lib/python2.7/dist-packages/mercurial/thirdparty/concurrent/futures/_base.py", line 457, in result return self.__get_result() File "/usr/lib/python2.7/dist-packages/mercurial/wireprotov1peer.py", line 227, in sendcommands result = fn(**pycompat.strkwargs(args)) File "/usr/lib/python2.7/dist-packages/mercurial/wireprotov1peer.py", line 472, in getbundle return bundle2.getunbundler(self.ui, f) File "/usr/lib/python2.7/dist-packages/mercurial/bundle2.py", line 769, in getunbundler magicstring = changegroup.readexactly(fp, 4) File "/usr/lib/python2.7/dist-packages/mercurial/util.py", line 3585, in readexactly s = stream.read(n) File "/usr/lib/python2.7/dist-packages/mercurial/utils/compression.py", line 378, in read self._decompress(chunk) File "/usr/lib/python2.7/dist-packages/mercurial/utils/compression.py", line 438, in _decompress newbuf = self._decompobj.decompress(chunk) zstd.ZstdError: zstd decompressor error: Unknown frame descriptor while this still works on a stretch system I have access to. Downgrading mercurial to the version from stable does not help, so the issue likely appeared with the upgrade of some dependency. Removing ~/.hgrc does not help. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'testing'), (500, 'stable'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.3.0-2-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE 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 mercurial depends on: ii libc6 2.29-3 ii mercurial-common 5.2.1-1 ii python2.7.17-2 ii python2 2.7.17-2 ii ucf 3.0038+nmu1 Versions of packages mercurial recommends: ii openssh-client 1:8.1p1-1 Versions of packages mercurial suggests: ii kdiff3 1.8.01-1+b1 ii kdiff3-qt 1.8.01-1 pn qct -- no debconf information
Bug#942780: ipe: New version 7.2.13 available upstream
Package: ipe Version: 7.2.9-1+b1 Severity: wishlist Dear Maintainer, thank you for maintaining this package. I recently received some files that I could not open, because they were created with ipe 7.2.12. I notice that we are now quite a few versions behind. It would be nice, when you have time, to package a more recent version (7.2.13 seems to be the current one). I didn't see a watch file for ipe that would warn about new versions (maybe I am not looking in the right place), so I am filing this report. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 'testing'), (400, 'stable'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64, ppc64el, mips64el Kernel: Linux 5.2.0-3-amd64 (SMP w/16 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ipe depends on: ii gsfonts 1:8.11+urwcyr1.0.7~pre44-4.4 ii libc6 2.29-2 ii libcairo2 1.16.0-4 ii libgcc1 1:9.2.1-8 ii libipe7.2.9 7.2.9-1+b1 ii liblua5.3-0 5.3.3-1.1+b1 ii libqt5core5a5.11.3+dfsg1-4 ii libqt5gui5 5.11.3+dfsg1-4 ii libqt5widgets5 5.11.3+dfsg1-4 ii libstdc++6 9.2.1-8 ii sensible-utils 0.0.12 ii texlive-latex-base 2019.20190930-1 ii xdg-utils 1.1.3-1 ii zlib1g 1:1.2.11.dfsg-1+b1 Versions of packages ipe recommends: pn lua5.3 Versions of packages ipe suggests: ii texlive-latex-recommended 2019.20190930-1 -- no debconf information
Bug#942187: libxdmf-dev: conflict with older libxdmf3
Package: libxdmf-dev Version: 3.0+git20190531-1 Severity: normal Dear Maintainer, I upgraded libxdmf-dev and libxdmf3 on my system (more precisely, I ran "sudo apt install libloki-dev" which caused the update of those 2 packages) and got the following error: Unpacking libxdmf-dev (3.0+git20190531-1) over (3.0+git20160803-5+b1) ... dpkg: error processing archive /var/cache/apt/archives/libxdmf-dev_3.0+git20190531-1_amd64.deb (--unpack): trying to overwrite '/usr/lib/x86_64-linux-gnu/xdmf/openmpi/libXdmf.so', which is also in package libxdmf3:amd64 3.0+git20160803-5+b1 It seems that a file was moved from libxdmf3 to libxdmf-dev without adding any conflicts/replaces/breaks (whichever is required in this situation so apt updates things in the right order). It is easy enough to work around but it would still be good to fix it. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'testing'), (500, 'stable'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-3-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE 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 libxdmf-dev depends on: ii libgzstream-dev 1.5+dfsg-4 ii libloki-dev 0.1.7-3+b3 ii libxdmf3 3.0+git20190531-1 libxdmf-dev recommends no packages. libxdmf-dev suggests no packages. -- no debconf information
Bug#934215: qtbase5-dev: trying to overwrite shared ....png which is different from other instances of the package
Package: qtbase5-dev Version: 5.11.3+dfsg1-2+b1 Severity: normal Dear Maintainer, during my daily apt upgrade, I got this error: Unpacking qtbase5-dev:i386 (5.11.3+dfsg1-2+b1) over (5.11.3+dfsg1-2) ... dpkg: error processing archive /tmp/apt-dpkg-install-OL1lMs/021-qtbase5-dev_5.11.3+dfsg1-2+b1_i386.deb (--unpack): trying to overwrite shared '/usr/share/qt5/doc/global/template/images/Qt-logo.png', which is different from other instances of package qtbase5-dev:i386 (I have the amd64 and i386 versions installed) I had to use dpkg --force-overwrite to work around it, which showed the additional messages: Preparing to unpack .../qtbase5-dev_5.11.3+dfsg1-2+b1_i386.deb ... Unpacking qtbase5-dev:i386 (5.11.3+dfsg1-2+b1) over (5.11.3+dfsg1-2) ... dpkg: warning: overriding problem because --force enabled: dpkg: warning: trying to overwrite shared '/usr/share/qt5/doc/global/template/images/Qt-logo.png', which is different from other instances of package qtbase5-dev:i386 dpkg: warning: overriding problem because --force enabled: dpkg: warning: trying to overwrite shared '/usr/share/qt5/doc/global/template/images/ico_out.png', which is different from other instances of package qtbase5-dev:i386 dpkg: warning: overriding problem because --force enabled: dpkg: warning: trying to overwrite shared '/usr/share/qt5/doc/global/template/style/list_arrow.png', which is different from other instances of package qtbase5-dev:i386 dpkg: warning: overriding problem because --force enabled: dpkg: warning: trying to overwrite shared '/usr/share/qt5/doc/global/template/style/list_expand.png', which is different from other instances of package qtbase5-dev:i386 Usually, for a multiarch issue, the +b1 in the version number would make me suspicious, but maybe not here, the image seems to contain a creation time. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'testing'), (500, 'stable'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE 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
Bug#919020: llvm-dev: Provide /usr/lib/bfd-plugins/LLVMgold.so
Package: llvm-dev Version: 1:7.0-47 Severity: normal Dear Maintainer, as requested in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631178 , it would be nice to provide a symlink for LLVMgold.so in /usr/lib/bfd-plugins . Gcc does it for their plugin (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865690). It would let tools like nm, ar, etc understand LTO files automatically. /tmp $ clang e.c -flto -c /tmp $ file e.o e.o: LLVM IR bitcode /tmp $ nm e.o nm: e.o: file format not recognized [adding the symlink] /tmp $ nm e.o T main -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'testing'), (500, 'stable'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages llvm-dev depends on: ii llvm 1:7.0-47 ii llvm-7-dev1:7.0.1-4 ii llvm-runtime 1:7.0-47 llvm-dev recommends no packages. llvm-dev suggests no packages. -- no debconf information
Bug#912998: llvm-toolchain-snapshot: Conflicts not advertised
Source: llvm-toolchain-snapshot Version: 1:8~svn343154-1 Severity: normal Dear Maintainer, I recently tried to upgrade from older libc++-dev (& others). Those were multiarch-capable, so I had installed them for several architectures. This appears to have been broken in the new organisation. For instance /usr/lib/llvm-8/lib/libc++.so.1.0 is not in an arch-specific directory. However, the packages are still advertised as "Multi-Arch: same", so I only noticed during the installation. It would be nice to make the packages multi-arch-friendly again, better than just fixing the Multi-Arch field, although that would be better than nothing. To make progress, on this machine, I removed all foreign versions of those packages and was able to install the llvm-7 version of everything for x86_64. Since I also noticed llvm-8 packages, I decided to try and install them, and again, apt was happy to oblige, until during the installation it noticed some conflicts, like /usr/lib/x86_64-linux-gnu/libc++.a. It kind of looks like libc++1-7 and libc++1-8 are meant to conflict, but if they are not, you might need to use alternatives or diversions. -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'testing'), (500, 'stable'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#648499: gnome sets screen luminosity to the maximum
Hello, this seems to have been fixed somehow, at least I haven't had this issue in a while. I am not using the same computer as back then, so it is not a proof. (going through old bug reports of mine) -- Marc Glisse
Bug#911088: cmake: Recognize /usr/include/x86_64-linux-gnu like /usr/include
Package: cmake
Version: 3.12.3-1
Severity: normal
Dear Maintainer,
I regularly see cmake-generated makefiles with compiler flags like
-isystem /usr/include/x86_64-linux-gnu (or worse with -I). Those horrors
cause no end of trouble. It seems that cmake has special code to avoid
adding -I/usr/include, it would be good to extend it to the multiarch
directory.
Some steps to reproduce easily:
$ cat hello.cpp
int main(){}
$ cat CMakeLists.txt
cmake_minimum_required(VERSION 3.4.0)
project (hello)
add_executable(hello hello.cpp)
target_include_directories(hello SYSTEM PRIVATE /usr/include/x86_64-linux-gnu)
$ cmake . && make VERBOSE=1
[...]
/usr/bin/c++ -isystem /usr/include/x86_64-linux-gnu -o
CMakeFiles/hello.dir/hello.cpp.o -c /tmp/cm/hello.cpp
while if I replace /usr/include/x86_64-linux-gnu with /usr/include
/usr/bin/c++ -o CMakeFiles/hello.dir/hello.cpp.o -c /tmp/cm/hello.cpp
-- System Information:
Debian Release: buster/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'testing'), (500, 'stable'), (50,
'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64, ppc64el, mips64el
Kernel: Linux 4.18.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages cmake depends on:
ii cmake-data3.12.3-1
ii libarchive13 3.2.2-5
ii libc6 2.27-6
ii libcurl4 7.61.0-1
ii libexpat1 2.2.6-1
ii libgcc1 1:8.2.0-7
ii libjsoncpp1 1.7.4-3
ii librhash0 1.3.6-2
ii libstdc++68.2.0-7
ii libuv11.23.1-1
ii procps2:3.3.15-2
ii zlib1g1:1.2.11.dfsg-1
Versions of packages cmake recommends:
ii gcc 4:8.1.0-1
ii make 4.2.1-1.2
Versions of packages cmake suggests:
pn cmake-doc
ii ninja-build 1.8.2-1
-- no debconf information
Bug#892394: [pkg-boost-devel] Bug#892394: boost1.63: build-depends on GCC 6
Dimitri John Ledkov: boost1.65 has been rejected by ftp-masters, on copyright reasons. Hello, could you include a reference to the corresponding discussion, please? I didn't manage to find it on the debian mailing lists. The only potentially relevant thing I found is a discussion in February on the boost mailing list about one stackoverflow snippet, but it does not mention debian at all and seems too small a reason to reject the library. -- Marc Glisse
Bug#865690: cpp-7: Symlink liblto_plugin.so in /usr/lib/bfd-plugins
Package: cpp-7
Version: 7.1.0-7
Severity: normal
Dear Maintainer,
this package provides the plugin
/usr/lib/gcc/x86_64-linux-gnu/7/liblto_plugin.so, which is good (not sure
why it is in package cpp-7 in particular, but I don't care as long as it
is available). However, binutils look for plugins in /usr/lib/bfd-plugins.
So by default:
$ cat e.c
int f(double){}
$ g++ e.c -c && nm e.o
T _Z1fd
$ g++ e.c -c -flto && nm e.o
nm: e.o: plugin needed to handle lto object
0001 C __gnu_lto_slim
0001 C __gnu_lto_v1
If I manually create the directory /usr/lib/bfd-plugins and symlink the
plugin there, I do get
$ nm e.o
T _Z1fd
See for instance https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78795 for
one place where it causes trouble. According to that link, it does not
matter which version of gcc provides the plugin, so you could for
instance provide the symlink with the package cpp from gcc-defaults
(easiest way to have a single version).
-- System Information:
Debian Release: 9.0
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'testing'), (500, 'stable'), (50,
'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64, ppc64el
Kernel: Linux 4.9.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages cpp-7 depends on:
ii gcc-7-base 7.1.0-7
ii libc6 2.24-12
ii libgmp102:6.1.2+dfsg-1
ii libisl150.18-1
ii libmpc3 1.0.3-1+b2
ii libmpfr43.1.5-1
ii zlib1g 1:1.2.8.dfsg-5
cpp-7 recommends no packages.
Versions of packages cpp-7 suggests:
pn gcc-7-locales
-- no debconf information
Bug#845162: ntfs-3g: Please include plugin ntfs-3g-system-compression
Package: ntfs-3g Version: 1:2016.2.22AR.1-3 Severity: normal Dear Maintainer, in order to access many files from my windows 10 partition, I needed to install the plugin from https://github.com/ebiggers/ntfs-3g-system-compression , and things seem to work now. It would be nice if this could be part of the debian package. Apparently it is currently restricted to reading, but since I mount the filesystem read-only anyway, that's not a real limitation for me. -- System Information: Debian Release: stretch/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'stable'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages ntfs-3g depends on: ii fuse 2.9.7-1 ii libc6 2.24-5 ii libgcrypt201.7.3-2 ii libgnutls303.5.6-4 ii libgpg-error0 1.24-2 ii libntfs-3g871 1:2016.2.22AR.1-3 ntfs-3g recommends no packages. ntfs-3g suggests no packages. -- no debconf information
Bug#543816: closed by David Kalnischkies (Re: apt-get update tries to chdir $PWD)
reopen 543816 thanks I can still reproduce it in testing (version 1.0.9.10, sorry, I can see a slightly newer version in unstable, but installing it would upgrade too many things so I did not test). As a user, I mounted a remote directory using sshfs. Inside it, I have a subdirectory with mode 700. As root: # cd /home/glisse/saclay/nancy-mail -su: cd: /home/glisse/saclay/nancy-mail: Permission denied As myself, I changed to that directory, called "sudo apt-get update", and it ended with: Fetched 1,463 kB in 50s (29.0 kB/s) E: Unable to change to /home/glisse/saclay/nancy-mail/ - chdir (13: Permission denied) -- Marc Glisse
Bug#786876: makehuman-data: upgrade conflict
Package: makehuman-data Version: 1.0.2-7 Severity: normal Dear Maintainer, apt-get dist-upgrade caused the following error: dpkg: error processing archive /var/cache/apt/archives/makehuman-data_1.0.2-7_all.deb (--unpack): trying to overwrite '/usr/share/makehuman/apps/devtests.py', which is also in package makehuman 1.0.0~alpha6-5+b1 dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) which was easily solved by apt-get -f install, but still, the package seems to be missing some Replaces: field. Actually, it already has a strange information with Replaces and Provides of itself. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf, powerpc, ppc64el, arm64, s390x, armel Kernel: Linux 3.16.0-4-amd64 (SMP w/8 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 makehuman-data depends on: ii python2.7 2.7.10~rc1-1 makehuman-data recommends no packages. makehuman-data suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#779408: libcgal-dev: multiarch conflict in compiler_config.h
Package: libcgal-dev Version: 4.5.2-1 Severity: normal Dear Maintainer, trying to co-install the armhf version of libcgal-dev on this x86_64 system, I got an error because /usr/include/CGAL/compiler_config.h differs in the 2 packages: --- /usr/include/CGAL/compiler_config.h 2015-02-20 21:14:36.0 +0100 +++ compiler_config.h 2015-02-20 21:11:06.0 +0100 @@ -60,7 +60,7 @@ #define CGAL_USE_CORE 1 -#define CGAL_HAS_QT4 1 - #define CGAL_HAS_IMAGEIO 1 +#define CGAL_HAS_QT4 1 + If there is a way to make the order of the #define more consistant, that will be good. Otherwise, we should consider moving this file to /usr/include/$triplet/CGAL/compiler_config.h :-( -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf, powerpc, ppc64el, arm64, s390x, armel Kernel: Linux 3.16.0-4-amd64 (SMP w/8 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) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#771512: libc++1:armel: libc++.so references __sync_val_compare_and_swap_4
Package: libc++1 Version: 3.5-2 Severity: normal Dear Maintainer, trying to compile any file, I get: $ clang++ -target arm-linux-gnueabi -stdlib=libc++ main.cc /usr/lib/gcc/arm-linux-gnueabi/4.9/../../../../arm-linux-gnueabi/bin/ld: a.out: hidden symbol `__sync_val_compare_and_swap_4' in /usr/lib/gcc/arm-linux-gnueabi/4.9/libgcc.a(linux-atomic.o) is referenced by DSO /usr/lib/gcc/arm-linux-gnueabi/4.9/../../../../arm-linux-gnueabi/bin/ld: final link failed: Bad value clang: error: linker command failed with exit code 1 (use -v to see invocation) Using -stdlib=libstdc++, I need -latomic for almost everything, but it seems to work. I haven't found the equivalent for libc++, -static provides a temporary workaround. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 armhf powerpc ppc64el arm64 s390x armel Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libc++1:armel depends on: ii libc6 2.19-13 ii multiarch-support 2.19-13 libc++1:armel recommends no packages. Versions of packages libc++1:armel suggests: ii clang 1:3.5-25 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#767564: libblitz-doc: fails to upgrade from 'testing' - trying to overwrite /usr/share/info/blitz.info.gz
Package: libblitz-doc Version: 1:0.10-3.1 Followup-For: Bug #767564 Dear Maintainer, the version number used in break+replaces is wrong, it is missing the epoch. So I got today: Unpacking libblitz-doc (1:0.10-3.1) over (1:0.10-1) ... dpkg: error processing archive /var/cache/apt/archives/libblitz-doc_1%3a0.10-3.1_all.deb (--unpack): trying to overwrite '/usr/share/info/blitz.info.gz', which is also in package libblitz0ldbl 1:0.10-1 -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 armhf powerpc ppc64el arm64 s390x Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libblitz-doc depends on: ii libjs-jquery 1.7.2+dfsg-3.2 libblitz-doc recommends no packages. libblitz-doc suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#767582: wine64-tools: conflict with older wine64-dev-tools
Package: wine64-tools Version: 1.6.2-14 Severity: normal Dear Maintainer, apt-get dist-upgrade gave me the following: Unpacking wine64-tools (1.6.2-14) ... dpkg: error processing archive /var/cache/apt/archives/wine64-tools_1.6.2-14_amd64.deb (--unpack): trying to overwrite '/usr/lib/x86_64-linux-gnu/wine/bin/winegcc', which is also in package wine64-dev-tools 1.6.2-8 dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) It was fixed by a later "apt-get -f install", but it would be nice to add a Replaces: or Conflicts: or something field to avoid this issue. Thanks, -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 armhf powerpc ppc64el arm64 s390x Kernel: Linux 3.16-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages wine64-tools depends on: ii libc62.19-12 ii libwine 1.6.2-14 ii libwine-dev 1.6.2-14 wine64-tools recommends no packages. wine64-tools suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737307: libcgal-dev: multiarch support
On Fri, 24 Oct 2014, Joachim Reichel wrote:
I've looked again at multiarch support for CGAL based on your patch. I've
attached my current version of it. The reverse dependencies build fine (yade
fails for unrelated reasons).
One Qt -dev package declares a Conflicts: between the i386 and amd64 variant,
Yes, Qt4 may never get M-A support, but I hope CGAL will soon handle Qt5,
which is already M-A:same (although not all of its dependencies are).
and one GLU -dev package does not support multiarch (do not remember the package
Yes, the X Strike Force has been sloly (but steadily, so that's ok)
marking their packages, and libglu is one of the last remaining.
(Btw, you could add libtbb-dev to the Suggests: now that some packages can
use it)
exact names anymore). That means that some examples (Mesh_3, Image_IO,
Surface_mesher) do not work in a multiarch setup (at least not multiple
architectures at the same time). The same probably holds for the demos.
Yes, I expect that. But it should magically start working when the
dependencies are fixed.
Two questions:
- Why did you add "Pre-Depends: ${misc:Pre-Depends}"? "Pre-Depends:
multiarch-support" should be sufficient, as far as I know.
https://wiki.debian.org/Multiarch/Implementation
says to use ${misc:Pre-Depends}", so that's what I did without thinking
about it. I guess it may help if Debian ever goes through another similar
change. But if you prefer some other way, I don't mind at all.
- Is there any (multiarch-related) reason for moving usr/lib/CGAL to a
subdirectory of usr/lib/$TRIPLET/cmake? Or is just because other packages
already use the "cmake" subdirectory?
CGALConfig.cmake is a generated file that depends on the arch (it contains
the full path to libCGAL.so for instance, because cmake is such a clean
system...), so at least that one needs to be in a path including $TRIPLET.
Then I tried to see where most packages were putting those files (on my
desktop, out of 135 *.cmake files in /usr/lib/x86_64-linux-gnu, 117 are in
the cmake subdirectory) and where cmake is looking by default. I don't
remember if the option to move this one moved them all or something.
Again, whatever works...
While it would be nice to have multiarch support in jessie I think it's a bit
risky to upload such a change shortly before the freeze. I intend to upload it
to experimental such that people can test it, and probably upload it later to
unstable (maybe just after jessie has been released).
Sounds good to me, thanks.
--
Marc Glisse
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#705803: MPFI detection
On Thu, 16 Oct 2014, Joachim Reichel wrote: Actually, MPFI and NTL support was never really enabled (MPFI was only mentioned in the Build-Depends:, NTL was only mentioned in the cmake command line). Really enabling them causes some examples no longer to build (at least Arrangement_on_surface_2). Do the CGAL developers know? (the testsuite webpage doesn't show if mpfi is enabled) I think there was no real request for support for these libraries, so I want to disable support for them for now (or rather, remove the traces that made me believe support was enabled). Besides, disabling MPFI support allows to work on multiarch support for CGAL. Would you maybe keep libmpfi-dev in Suggests: where it can't hurt? For GMPXX I want to re-enable the support since it was accidentally lost in 4.1-1 when the CGAL build system got revamped. And the additional overhead is quite small. Waiting for your feedback before uploading the new version. Your plan sounds very good to me :-) Thanks, -- Marc Glisse -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#705803: MPFI detection
Hi Joachim, I am trying to understand why libmpfi-dev is in Build-Depends of cgal, especially since libmpfi0 is not in Depends of any cgal package. The only reason I could think of was this "bug", so cgal would detect MPFI and enable it by default, but compiler_config.h still has it disabled in 4.5-1. Do you remember why you removed it from Suggests of libcgal-demo and added it to Build-Depends? If you move it back (Suggests of libcgal-dev would also make sense), it will also unblock 737307 (which shouldn't be blocked anyway, build dependencies don't affect multiarch usability of a package). Thanks, -- Marc Glisse -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#762354: libc++: Warning in use_libcxxabi patch
Package: libc++ Version: 3.5-1 Severity: normal Dear Maintainer, libcxx-use_libcxxabi.patch contains: -#ifdef __APPLE__ +#ifdef __APPLE__ || LIBCXXABI which seems wrong. Did you mean: #if defined __APPLE__ || LIBCXXABI or maybe: #if defined __APPLE__ || defined LIBCXXABI ? Currently, clang warns: ../src/new.cpp:20:18: warning: extra tokens at end of #ifdef directive -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 armhf powerpc ppc64el arm64 Kernel: Linux 3.16-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#762188: linux-image-3.16-1-amd64: NFS4 oops: NULL pointer in nfs_delegation_find_inode
Package: src:linux Version: 3.16.2-3 Severity: normal Dear Maintainers, I am seeing kernel oops that seem to be related to nfs4. Things have recently become worse (daily oops), probably due to userland upgrades that are triggering the problem more often. I was seeing the oops with 3.14-2 and tried 3.16-1 but I got the same issue on the first day. It seems to happen mostly in the evening, maybe a couple hours after I log out, though I may be logged in remotely when it happens. My HOME is automounted with -fstype=nfs4,sec=krb5. There is another fs automounted with -fstype=nfs4,sec=sys but I don't think it was used. The log matches this one quite closely: https://retrace.fedoraproject.org/faf/reports/362740/ I took the liberty of including a slightly longer piece of syslog than reportbug had extracted (8 more lines), so it shows the initial error. This is particularly problematic since these days, with systemd, I can't reboot the machine remotely (I have to boot in rescue mode, start network-manager, then resume, or nothing works properly). At least, after stopping automount, the machine still seems usable (without my home directory), which is how I am reporting this. Thanks to whoever made the kernel resilient to errors in one module :-) PS: sorry about the nvidia module, I do try nouveau occasionally... -- Package-specific info: ** Version: Linux version 3.16-1-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.3 (Debian 4.8.3-10) ) #1 SMP Debian 3.16.2-3 (2014-09-13) ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.16-1-amd64 root=UUID=0e2f2fe7-b148-4839-a319-ba19161f7e22 ro single ** Tainted: PDIO (6273) * Proprietary module has been loaded. * Kernel has oopsed before. * Working around severe firmware bug. * Out-of-tree module has been loaded. ** Kernel log: [41204.322521] BUG: unable to handle kernel NULL pointer dereference at 0540 [41204.322527] IP: [] nfs_delegation_find_inode+0x55/0x130 [nfsv4] [41204.322541] PGD 0 [41204.322543] Oops: [#1] SMP [41204.322546] Modules linked in: bnep bluetooth 6lowpan_iphc des_generic cbc nfsv4 dns_resolver cpufreq_userspace cpufreq_conservative cpufreq_stats cpufreq_powersave binfmt_misc cfg80211 rpcsec_gss_krb5 nfsd auth_rpcgss oid_registry nfs_acl nfs lockd fscache sunrpc nvidia(PO) snd_hda_codec_realtek snd_hda_codec_generic evdev hp_wmi sparse_keymap iTCO_wdt rfkill iTCO_vendor_support coretemp snd_hda_intel kvm_intel snd_hda_controller snd_hda_codec kvm snd_hwdep snd_pcm_oss snd_mixer_oss i2c_core psmouse serio_raw pcspkr i7core_edac button lpc_ich edac_core snd_pcm mfd_core snd_timer wmi acpi_cpufreq snd soundcore shpchp processor thermal_sys loop fuse parport_pc ppdev lp parport autofs4 ext4 crc16 mbcache jbd2 btrfs xor raid6_pq hid_generic usbhid hid sd_mod crc_t10dif crct10dif_generic sg sr_mod crct10dif_common cdrom ahci libahci mptsas crc32c_intel scsi_transport_sas ehci_pci uhci_hcd mptscsih ehci_hcd libata mptbase firewire_ohci tg3 firewire_core ptp scsi_mod crc_itu_t pps_core usbcore libphy usb_common floppy [41204.322615] CPU: 0 PID: 1785 Comm: nfsv4.0-svc Tainted: P IO 3.16-1-amd64 #1 Debian 3.16.2-3 [41204.322617] Hardware name: Hewlett-Packard HP Z800 Workstation/0AECh, BIOS 786G5 v01.14 05/26/2009 [41204.322619] task: 88031f08c050 ti: 88030c81c000 task.ti: 88030c81c000 [41204.322621] RIP: 0010:[] [] nfs_delegation_find_inode+0x55/0x130 [nfsv4] [41204.322629] RSP: 0018:88030c81fce0 EFLAGS: 00010286 [41204.322631] RAX: 8800ca35800a RBX: 8800ca358000 RCX: fff8 [41204.322633] RDX: 88030c81fd90 RSI: 8800ca358008 RDI: 880322536400 [41204.322634] RBP: R08: R09: 8800ca358026 [41204.322636] R10: 0094 R11: 0094 R12: 8800ca358008 [41204.322637] R13: R14: 8800ca27a000 R15: 0004 [41204.322639] FS: () GS:88032fc0() knlGS: [41204.322641] CS: 0010 DS: ES: CR0: 8005003b [41204.322643] CR2: 0540 CR3: 01813000 CR4: 07f0 [41204.322645] Stack: [41204.322646] 8800ca35800a fff8 8803225364c0 [41204.322649] 8800ca358000 1127 [41204.322651] 8800ca27a000 0004 a07205cd 88030c81fdb0 [41204.322654] Call Trace: [41204.322663] [] ? nfs4_callback_recall+0x3d/0x140 [nfsv4] [41204.322670] [] ? nfs4_callback_compound+0x41e/0x640 [nfsv4] [41204.322680] [] ? svc_process_common+0x599/0x670 [sunrpc] [41204.322687] [] ? nfs_callback_authenticate+0x50/0x50 [nfsv4] [41204.322695] [] ? svc_process+0x10c/0x160 [sunrpc] [41204.322702] [] ? nfs4_callback_svc+0x3d/0x50 [nfsv4] [41204.322707] [] ? kthread+0xbd/0xe0 [41204.322711] [] ? kthread_create_on_node+0x180/0x180 [41204.322715] [] ? ret_from_fork+0x7c/0xb0 [41204.322718] [] ? kthread_create_on_node+0
Bug#760681: llvm-gcc: Bad gcov wrapper
Package: llvm-gcc Version: 3.4-2 Severity: normal Dear Maintainer, $ /usr/bin/llvm-gcov --version gcov-4.8: invalid option -- 'g' [...] It looks like gcov does not support -fplugin. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 armhf powerpc Kernel: Linux 3.14-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages llvm-gcc depends on: ii dragonegg 3.4-2 ii g++-4.84.8.3-9 ii gcc-4.84.8.3-9 llvm-gcc recommends no packages. llvm-gcc suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#756980: klavaro: conflict with libgtkdatabox-0.9.2-0-dev
Package: klavaro Version: 3.00-1 Severity: normal Dear Maintainer, trying to install klavaro results in: Unpacking klavaro (3.00-1) ... dpkg: error processing archive /var/cache/apt/archives/klavaro_3.00-1_amd64.deb (--unpack): trying to overwrite '/usr/lib/x86_64-linux-gnu/libgtkdatabox.a', which is also in package libgtkdatabox-0.9.2-0-dev 1:0.9.2.0+dfsg-1 klavaro probably should not be shipping that file, or at least have a conflicts: field. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 armhf powerpc Kernel: Linux 3.14-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages klavaro depends on: ii libatk1.0-0 2.12.0-1 ii libc62.19-7 ii libcairo-gobject21.12.16-2 ii libcairo21.12.16-2 ii libcurl3-gnutls 7.37.1-1 ii libgdk-pixbuf2.0-0 2.30.7-1 ii libglib2.0-0 2.40.0-3 ii libgtk-3-0 3.12.2-1+b1 ii libpango-1.0-0 1.36.3-1 ii libpangocairo-1.0-0 1.36.3-1 klavaro recommends no packages. klavaro suggests no packages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#756587: python3-pyfits: fails to configure, syntax error
Package: python3-pyfits Version: 1:3.3-1 Severity: important Dear Maintainer, during apt-get upgrade this morning, I got: Setting up python3-pyfits (1:3.3-1) ... File "/usr/lib/python3/dist-packages/pyfits/scripts/fitscheck.py", line 135 except UserWarning, w: ^ SyntaxError: invalid syntax dpkg: error processing package python3-pyfits (--configure): subprocess installed post-installation script returned error exit status 1 -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 armhf powerpc Kernel: Linux 3.14-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages python3-pyfits depends on: ii libc6 2.19-7 ii libcfitsio3 3.340-3 ii python3 3.4.1-1 ii python3-numpy [python3-numpy-abi9] 1:1.8.1-1+b1 python3-pyfits recommends no packages. Versions of packages python3-pyfits suggests: ii pyfits-utils 1:3.3-1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#726027: Required-Start: $remote_fs for rcS type services (early boot) can lead to dependency loops
On Mon, 28 Jul 2014, Michael Biebl wrote: Am 28.07.2014 17:23, schrieb Marc Glisse: The output of "systemctl list-jobs" and "journalctl -alb" would be helpful for a start. The first only listed: 497 systemd-logind.service start running The second is: http://geometrica.saclay.inria.fr/team/Marc.Glisse/tmp/systemd It seems that the NetworkManager service is the only one really failing, maybe because of policykit. (you can probably ignore the ldap messages, they have always been there) I ran "/etc/init.d/gdm3 stop" before so it wouldn't try to switch tty everytime an attempt to start X failed. I don't see a dependency cycle in the journal output you posted. Indeed. It is surprising, I did see one earlier, I copy-pasted the message in google and that's how I eventually found this bug, but now I don't see it anymore... I have this in syslog from another boot. Ah, could it be from when I tried enabling NetworkManager-wait-online.service? I thought I had removed that as soon as I realized it didn't solve the problem. Jul 28 12:51:12 stedding systemd[1]: Found ordering cycle on basic.target/stop Jul 28 12:51:12 stedding systemd[1]: Found dependency on sysinit.target/stop Jul 28 12:51:12 stedding systemd[1]: Found dependency on nfs-common.service/stop Jul 28 12:51:12 stedding systemd[1]: Found dependency on rpcbind.target/stop Jul 28 12:51:12 stedding systemd[1]: Found dependency on rpcbind.service/stop Jul 28 12:51:12 stedding systemd[1]: Found dependency on network-online.target/stop Jul 28 12:51:12 stedding systemd[1]: Found dependency on network.target/stop Jul 28 12:51:12 stedding systemd[1]: Found dependency on NetworkManager-wait-online.service/stop Jul 28 12:51:12 stedding systemd[1]: Found dependency on basic.target/stop Jul 28 12:51:12 stedding systemd[1]: Breaking ordering cycle by deleting job sysinit.target/stop Jul 28 12:51:12 stedding systemd[1]: Job sysinit.target/stop deleted to break ordering cycle starting with basic.target/stop So I'm not sure if the issue you're seeing is related to this particular bug report. At least the remote_fs -> local_fs change works, though that could be a coincidence. What I see is quite a few of Jul 28 16:38:25 stedding dbus[652]: [system] Failed to activate service 'org.freedesktop.ColorManager': timed out Jul 28 16:38:25 stedding dbus[652]: [system] Failed to activate service 'org.freedesktop.systemd1': timed out Jul 28 16:38:25 stedding dbus[652]: [system] Failed to activate service 'org.freedesktop.PolicyKit1': timed out Which then leads to PolicyKit and as a consequence NM being non-functional. If there is no cycle but messing with the order fixes it, that would point to a missing dependency somewhere I guess? -- Marc Glisse -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#726027: Required-Start: $remote_fs for rcS type services (early boot) can lead to dependency loops
On Mon, 28 Jul 2014, Michael Biebl wrote: Am 28.07.2014 15:53, schrieb Marc Glisse: "makes unrelated software on the system (or the whole system) break", pretty much what I am seeing here. The recent upgrades pulled in systemd (it is very hard to avoid currently) and made the system unbootable. The workaround I found was to boot in debug mode, run A loop does not mean unbootable (therefore adjusting the severity). Actually, I was hasty: it does boot, and I can even login as root, though I have to wait a number of timeouts, I only get the tty1, X fails to start, etc. And most importantly (I didn't have physical access when the issue first happened) the network doesn't work at all. "/etc/init.d/network-manager restart" hangs for a while then annouces it failed. "/etc/init.d/network-manager start" then exit so normal boot would resume. Looking through messages, I noticed that systemd was breaking a loop by disabling (at least) rpcbind and nfs-common and eventually found this bug. Following the instructions, I sed s/remote_fs/local_fs/ for all the Required-Start: in /etc/rcS.d, and the next boot seems to have worked just fine. dependency loops can exist Really, that's not always a bug? an systemd removes services from such loops automatically to break those loops. In your case that doesn't seem to have worked (or there is maybe another issue). Could you please undo the changes you made to your rcS services, enabled the debug shell (systemctl enable debug-shell.service), boot with systemd.log_level=debug, and on next reboot, switch to tty9 to examine the output. The output of "systemctl list-jobs" and "journalctl -alb" would be helpful for a start. The first only listed: 497 systemd-logind.service start running The second is: http://geometrica.saclay.inria.fr/team/Marc.Glisse/tmp/systemd It seems that the NetworkManager service is the only one really failing, maybe because of policykit. (you can probably ignore the ldap messages, they have always been there) I ran "/etc/init.d/gdm3 stop" before so it wouldn't try to switch tty everytime an attempt to start X failed. -- Marc Glisse -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#726027: Required-Start: $remote_fs for rcS type services (early boot) can lead to dependency loops
severity 726027 critical thanks "makes unrelated software on the system (or the whole system) break", pretty much what I am seeing here. The recent upgrades pulled in systemd (it is very hard to avoid currently) and made the system unbootable. The workaround I found was to boot in debug mode, run "/etc/init.d/network-manager start" then exit so normal boot would resume. Looking through messages, I noticed that systemd was breaking a loop by disabling (at least) rpcbind and nfs-common and eventually found this bug. Following the instructions, I sed s/remote_fs/local_fs/ for all the Required-Start: in /etc/rcS.d, and the next boot seems to have worked just fine. Raising the severity so people know to postpone any upgrade that tries to install systemd, unless they are ready to spend some time fixing their system afterwards. (the merge with 738965 doesn't seem to have worked) -- Marc Glisse -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#751689: libtbb-dev: multiarch
Package: libtbb-dev
Version: 4.2~20140122-1.1
Severity: wishlist
Tags: patch
Dear Maintainer,
it would be nice if libtbb-dev could be co-installed for amd64 and i386.
Here is a patch that seems to work for me, though you may want to adapt
it a bit and test it more. I used git for the diff to try and make it
more visible: the files where I added dh-exec need "chmod +x", and I
removed the .dirs files which seem unnecessary.
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable'), (50, 'unstable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
armhf
powerpc
Kernel: Linux 3.14-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libtbb-dev depends on:
ii libtbb2 4.2~20140122-1.1
libtbb-dev recommends no packages.
Versions of packages libtbb-dev suggests:
pn libtbb-doc
pn tbb-examples
-- no debconf information
diff --git a/tbb-4.2~20140122/debian/control b/marc/debian/control
index 9dc785f..f9f3b72 100644
--- a/tbb-4.2~20140122/debian/control
+++ b/marc/debian/control
@@ -1,7 +1,7 @@
Source: tbb
Priority: extra
Maintainer: Steve Capper
-Build-Depends: debhelper (>= 9), dpkg-dev (>= 1.16.1~), libjs-jquery
+Build-Depends: debhelper (>= 9), dh-exec (>=0.3), dpkg-dev (>= 1.16.1~), libjs-jquery
Standards-Version: 3.9.4
Section: libs
Homepage: http://threadingbuildingblocks.org/
@@ -9,6 +9,7 @@ Homepage: http://threadingbuildingblocks.org/
Package: libtbb-dev
Section: libdevel
Architecture: any
+Multi-arch: same
Depends: libtbb2 (= ${binary:Version}), ${misc:Depends}
Suggests: tbb-examples, libtbb-doc
Description: parallelism library for C++ - development files
@@ -25,7 +26,9 @@ Description: parallelism library for C++ - development files
Package: libtbb2
Architecture: any
+Multi-arch: same
Depends: ${shlibs:Depends}, ${misc:Depends}
+Pre-Depends: ${misc:Pre-Depends}
Description: parallelism library for C++ - runtime files
TBB is a library that helps you leverage multi-core processor
performance without having to be a threading expert. It represents a
@@ -41,6 +44,7 @@ Description: parallelism library for C++ - runtime files
Package: libtbb2-dbg
Section: debug
Architecture: any
+Multi-arch: same
Depends: libtbb2 (= ${binary:Version}), ${misc:Depends}
Description: parallelism library for C++ - debugging symbols
TBB is a library that helps you leverage multi-core processor
diff --git a/tbb-4.2~20140122/debian/libtbb-dev.dirs b/tbb-4.2~20140122/debian/libtbb-dev.dirs
deleted file mode 100644
index 13cdd2e..000
--- a/tbb-4.2~20140122/debian/libtbb-dev.dirs
+++ /dev/null
@@ -1,3 +0,0 @@
-usr/include
-usr/lib
-usr/lib/pkgconfig
diff --git a/tbb-4.2~20140122/debian/libtbb-dev.install b/marc/debian/libtbb-dev.install
old mode 100644
new mode 100755
index d1207d3..80f6d75
--- a/tbb-4.2~20140122/debian/libtbb-dev.install
+++ b/marc/debian/libtbb-dev.install
@@ -1,3 +1,4 @@
+#! /usr/bin/dh-exec
include/tbb usr/include
-build/linux_*_release/lib*.so usr/lib
-debian/tbb.pc usr/lib/pkgconfig
+build/linux_*_release/lib*.so usr/lib/${DEB_HOST_MULTIARCH}
+debian/tbb.pc usr/lib/${DEB_HOST_MULTIARCH}/pkgconfig
diff --git a/tbb-4.2~20140122/debian/libtbb-dev.links b/marc/debian/libtbb-dev.links
old mode 100644
new mode 100755
index 670c903..6ec86aa
--- a/tbb-4.2~20140122/debian/libtbb-dev.links
+++ b/marc/debian/libtbb-dev.links
@@ -1,3 +1,4 @@
-usr/lib/libtbb.so.2 usr/lib/libtbb.so
-usr/lib/libtbbmalloc.so.2 usr/lib/libtbbmalloc.so
-usr/lib/libtbbmalloc_proxy.so.2 usr/lib/libtbbmalloc_proxy.so
+#! /usr/bin/dh-exec
+usr/lib/${DEB_HOST_MULTIARCH}/libtbb.so.2 usr/lib/${DEB_HOST_MULTIARCH}/libtbb.so
+usr/lib/${DEB_HOST_MULTIARCH}/libtbbmalloc.so.2 usr/lib/${DEB_HOST_MULTIARCH}/libtbbmalloc.so
+usr/lib/${DEB_HOST_MULTIARCH}/libtbbmalloc_proxy.so.2 usr/lib/${DEB_HOST_MULTIARCH}/libtbbmalloc_proxy.so
diff --git a/tbb-4.2~20140122/debian/libtbb2.dirs b/tbb-4.2~20140122/debian/libtbb2.dirs
deleted file mode 100644
index 6845771..000
--- a/tbb-4.2~20140122/debian/libtbb2.dirs
+++ /dev/null
@@ -1 +0,0 @@
-usr/lib
diff --git a/tbb-4.2~20140122/debian/libtbb2.install b/marc/debian/libtbb2.install
old mode 100644
new mode 100755
index a94ab11..c61a3cd
--- a/tbb-4.2~20140122/debian/libtbb2.install
+++ b/marc/debian/libtbb2.install
@@ -1 +1,2 @@
-build/linux_*_release/lib*.so.* usr/lib
+#! /usr/bin/dh-exec
+build/linux_*_release/lib*.so.* usr/lib/${DEB_HOST_MULTIARCH}
diff --git a/tbb-4.2~20140122/debian/rules b/marc/debian/rules
index 0e0296c..7c95052 100755
--- a/tbb-4.2~20140122/debian/rules
+++ b/marc/debian/rules
@@ -13,7 +13,7 @@ CXXFLAGS+=$(CPPFLAGS)
VERSION = $(shell dpkg-parsechangelog | grep '^Version' | cut -d' ' -f2 | cut -f1 -d-)
debian/tbb.pc: debian/tbb.pc.in
- sed -e"s/@VERSION@/$(VERSION)/g" $< > $@
+ sed -e"s/@VERSION@/$(VERSION)/g;s/@DEB_HOST_MULTIARCH@/$(DEB_HOST_MULTIARCH)/g" $<
Bug#737387: please support multi-arch
Package: libmpfi0
Version: 1.5.1-3
Followup-For: Bug #737387
Dear Maintainer,
following https://wiki.debian.org/Multiarch/Implementation
it seems that the attached patch (hopefully reportbug will have managed
to attach it, otherwise I'll try some other way) is sufficient to
support multi-arch.
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable'), (50, 'unstable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
armhf
powerpc
Kernel: Linux 3.13-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libmpfi0 depends on:
ii libc6 2.18-7
ii libgmp10 2:6.0.0+dfsg-4
ii libmpfr4 3.1.2-1
libmpfi0 recommends no packages.
libmpfi0 suggests no packages.
-- no debconf information
diff -ru mpfi-1.5.1/debian/compat mpfi-1.5.1.MARC/debian/compat
--- mpfi-1.5.1/debian/compat 2014-02-09 22:46:29.0 +0100
+++ mpfi-1.5.1.MARC/debian/compat 2014-05-27 13:54:20.496748793 +0200
@@ -1 +1 @@
-7
+9
diff -ru mpfi-1.5.1/debian/control mpfi-1.5.1.MARC/debian/control
--- mpfi-1.5.1/debian/control 2014-02-09 22:49:47.0 +0100
+++ mpfi-1.5.1.MARC/debian/control 2014-05-27 13:55:46.195982800 +0200
@@ -1,7 +1,7 @@
Source: mpfi
Priority: optional
Maintainer: Laurent Fousse
-Build-Depends: debhelper (>= 7.0.0), dh-autoreconf, libmpfr-dev (>= 2.2.0.dfsg.1), libgmp-dev, texinfo
+Build-Depends: debhelper (>= 9), dh-autoreconf, libmpfr-dev (>= 2.2.0.dfsg.1), libgmp-dev, texinfo
Standards-Version: 3.9.0
Section: math
Homepage: http://mpfi.gforge.inria.fr/
@@ -12,6 +12,7 @@
Section: libdevel
Architecture: any
Depends: libgmp-dev, libmpfr-dev (>= 2.2.0.dfsg.1-1), libmpfi0 (= ${binary:Version}), ${misc:Depends}
+Multi-Arch: same
Description: multiple precision floating-point interval computation library
This package provides a C library of functions for interval arithmetic
computations with arbitrary precision.
@@ -35,6 +36,8 @@
Section: libs
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
+Pre-Depends: ${misc:Pre-Depends}
+Multi-Arch: same
Description: multiple precision floating-point interval computation library
This package provides a C library of functions for interval arithmetic
computations with arbitrary precision.
diff -ru mpfi-1.5.1/debian/libmpfi-dev.install mpfi-1.5.1.MARC/debian/libmpfi-dev.install
--- mpfi-1.5.1/debian/libmpfi-dev.install 2014-02-09 22:46:29.0 +0100
+++ mpfi-1.5.1.MARC/debian/libmpfi-dev.install 2014-05-27 13:54:50.345875385 +0200
@@ -1,3 +1,3 @@
-usr/lib/libmpfi.so usr/lib/
-usr/lib/libmpfi.a usr/lib/
+usr/lib/*/libmpfi.so
+usr/lib/*/libmpfi.a
usr/include/*.h usr/include/
diff -ru mpfi-1.5.1/debian/libmpfi0.install mpfi-1.5.1.MARC/debian/libmpfi0.install
--- mpfi-1.5.1/debian/libmpfi0.install 2014-02-09 22:46:29.0 +0100
+++ mpfi-1.5.1.MARC/debian/libmpfi0.install 2014-05-27 13:55:03.978390088 +0200
@@ -1 +1 @@
-usr/lib/libmpfi.so.*usr/lib/
+usr/lib/*/libmpfi.so.*
Bug#743817: libpoppler-dev: Multi-arch -dev packages
On Sun, 6 Apr 2014, Pino Toscano wrote: What's the use case for marking libpoppler-dev as m-a: same? Uh, so I can cross-compile stuff? (aka "gcc -m32" in the simplest case) Alone it has no value in being so. Even with libpoppler-private-dev? Some dependencies may not be multiarch yet (qtbase5-dev) but I don't think it should prevent from marking libpoppler-qt5-dev (which would then become co-installable automatically when qtbase5-dev is updated), and it doesn't concern libpoppler-dev. - libqt4-dev (for libpoppler-qt4-dev) is not m-a: same safe That one is likely to disappear before anyone changes it... - qtbase5-dev (for libpoppler-qt5-dev) is not m-a: same safe #734677 seems to indicate that this will change soon. - libglib2.0-dev and the gir stuff (for libpoppler-glib-dev) are not m-a: same safe #683593 is not seeing a lot of activity indeed :-( so it is pointless mark those -dev as m-a: same, for now. I was hoping that we could parallelize the multi-arch work so we could get a usable set of multiarch dev packages a bit faster. But if you prefer to wait for the dependencies of your package, that's of course your choice. -- Marc Glisse -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743817: libpoppler-dev: Multi-arch -dev packages
Package: libpoppler-dev Version: 0.24.5-3 Severity: normal Dear Maintainer, it is good that libpoppler44 is Multi-Arch: same (thanks), but it would be even better if the -dev packages were as well. libpoppler-dev has all its content in /usr/lib/$arch (except for changelog and copyright), so it seems really safe. The others should be as well, unless the includes or the gir file contain build-generated arch-specific data. Some dependencies may not be multiarch yet (qtbase5-dev) but I don't think it should prevent from marking libpoppler-qt5-dev (which would then become co-installable automatically when qtbase5-dev is updated), and it doesn't concern libpoppler-dev. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 armhf powerpc Kernel: Linux 3.13-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libpoppler-dev depends on: ii libpoppler44 0.24.5-3 libpoppler-dev recommends no packages. libpoppler-dev suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743618: libc6-dev-i386: /usr/include/sys/file.h conflict between libc6-dev-i386 and libc6-dev-ppc64
Package: libc6-dev-i386 Version: 2.18-4 Severity: normal Dear Maintainer, apt-get install libc6-dev-ppc64 fails with the following error: Unpacking libc6-dev-ppc64 (2.18-4) ... dpkg: error processing archive /var/cache/apt/archives/libc6-dev-ppc64_2.18-4_powerpc.deb (--unpack): trying to overwrite '/usr/include/sys/file.h', which is also in package libc6-dev-i386 2.18-4 Errors were encountered while processing: /var/cache/apt/archives/libc6-dev-ppc64_2.18-4_powerpc.deb Possibly related to #702962. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 armhf powerpc Kernel: Linux 3.13-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libc6-dev-i386 depends on: ii libc6-dev 2.18-4 ii libc6-i386 2.18-4 Versions of packages libc6-dev-i386 recommends: pn gcc-multilib libc6-dev-i386 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#738538: [pkg-boost-devel] Bug#738538: Is boost1.55 really multiarch ?
On Mon, 31 Mar 2014, Dimitri John Ledkov wrote: The problem is that dependencies of the suggested packages are not multiarched, e.g. one cannot co-install libboost-mpi-python1.55-dev. I guess, there is more benefit to allow libboost1.55-dev be multiarched:same (since it's ready), even if all suggests are not multiarch installable. The libboost1.55-dev package is coinstallable across bitness and endianess different systems. I was thinking of python (I hadn't checked) when I wrote "most", but indeed MPI may be an issue. However, those are exceptions, libboost-thread1.55-dev and many others have no problematic dependency. Actually, is it really necessary to wait until all dependencies are multiarch-ready to mark a package? I don't think the content of libboost-mpi1.55-dev will change. If it was marked Multi-Arch: same, it would refuse to co-install because of missing dependencies, but would automatically work when openmpi is updated, no? -- Marc Glisse -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#738538: Is boost1.55 really multiarch ?
Source: libboost1.55-dev Followup-For: Bug #738538 > No, the -dev package is NOT multi-arch. Dear Maintainer, is there a particular obstruction to marking it as multi-arch? I was surprised to notice that it wasn't, when that seemed the whole point of splitting a -tools-dev package. Listing the files in this package, it contains only the headers (not autogenerated, so common to all platforms) and an example, which seems quite safe. (Most) other boost -dev packages are in the same situation with an extra .a/.so pair which is safe as well, so I don't think there is anything to do except pasting the multi-arch line many times in the control file. The longest is obviously building and checking that the resulting x86 and x86_64 (at least) packages can be co-installed, and I can understand if you want to wait for the next upstream release to do that. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 armhf powerpc Kernel: Linux 3.13-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743133: clang-3.5: target selection in manpage
Package: clang-3.5 Version: 1:3.5~svn201651-1 Severity: normal Dear Maintainer, the manpage for clang documents "-arch architecture", which does not work on linux, but fails to mention "-target triplet" which does (assuming you have the correct binutils). Could you please update it so it is less Mac-centric? -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 armhf powerpc Kernel: Linux 3.13-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages clang-3.5 depends on: ii libc62.18-4 ii libclang-common-3.5-dev 1:3.5~svn201651-1 ii libclang1-3.51:3.5~svn201651-1 ii libedit2 3.1-20140213-1 ii libffi6 3.0.13-12 ii libgcc-4.8-dev 4.8.2-16 ii libgcc1 1:4.8.2-16 ii libllvm3.5 1:3.5~svn201651-1 ii libobjc-4.8-dev 4.8.2-16 ii libstdc++-4.8-dev4.8.2-16 ii libstdc++6 4.8.2-16 ii libtinfo55.9+20140118-1 Versions of packages clang-3.5 recommends: ii llvm-3.5-dev 1:3.5~svn201651-1 ii python2.7.5-5 clang-3.5 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#736991: libc++: FTBFS on various architectures
Package: src:libc++ Followup-For: Bug #736991 Dear Maintainer, from a quick test here, it seems that updating the Build-Depends: from clang to clang-3.4 is enough to get rid of this issue. Unless there are plans to make clang point to clang-3.4 soon? Maybe the build-depends could be clang (>= 1:3.4) | clang-3.4 ? -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 armhf powerpc Kernel: Linux 3.13-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737560: libgnutls26: binNMU+multiarch
On Mon, 3 Feb 2014, Andreas Metzler wrote: I think you simply need to exercise your patience a liitle bit. ;-) Now that the i386 binnmu also succeeded all archs should be in sync after the next mirror push. Ah, ok thanks, feel free to close. I reacted a bit quickly because I was already bitten by boost 1.54.0-4+b1 recently, and I didn't think it was likely for the amd64 package to reach testing before the i386 one had time to be built. I'll wait longer next time ;-) -- Marc Glisse -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737560: libgnutls26: binNMU+multiarch
Package: libgnutls26 Version: 2.12.23-10+b1 Severity: normal Dear Maintainer, please make a regular upload to counter the effects of the latest binNMU. It is not possible to have the amd64 and i386 versions co-installed in testing or unstable currently since one has 2.12.23-10+b1 and the other 2.12.23-10. Thanks, -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 armhf powerpc Kernel: Linux 3.12-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737307: libcgal-dev: multiarch support
On Sun, 2 Feb 2014, Joachim Reichel wrote: Unfortunately, MPFI does not support it yet. I've filed a wishlist bug for that. Thanks. I thought MPFI wasn't a dependency of any of the cgal packages, so this shouldn't block. Qt4 is likely to be a bigger issue, though it seems ok to have a multiarch-ready package before all dependencies are ready, and in any case I am more interested in libcgal-dev than the qt part. -- Marc Glisse -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737307: libcgal-dev: multiarch support
Package: libcgal-dev
Version: 4.3-2
Severity: wishlist
Hello,
now that boost supports multiarch installations, it would be nice if
cgal did as well. I am mostly interested in testing i386 applications
but also test armhf with qemu sometimes.
What I am pasting below (based on 4.2) should not be considered a patch
ready to apply, just some ideas that seem to help but might be
completely wrong, I know little about Debian packaging. The files in
/usr/bin are just scripts so it looks like they can remain in
libcgal-dev. I removed FindCGAL.cmake, it seems useless (cmake can find
CGALConfig.cmake without it) and not multiarch-aware (it prevents cmake
from finding CGALConfig.cmake in its new location). I think the
generated config include file ends up being the same on all platforms,
so I didn't try to move it to /usr/include/$(DEB_HOST_MULTIARCH).
Otherwise I just moved stuff around.
diff -ru cgal-4.2/debian/control x/control
--- cgal-4.2/debian/control 2013-07-28 11:04:08.0 +0200
+++ x/control 2014-01-24 22:34:49.499706099 +0100
@@ -14,6 +14,8 @@
Package: libcgal10
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
+Pre-Depends: ${misc:Pre-Depends}
+Multi-Arch: same
Description: C++ library for computational geometry
CGAL (Computational Geometry Algorithms Library) makes the most important
of the solutions and methods developed in computational geometry available
@@ -39,6 +41,8 @@
Package: libcgal-qt4-10
Architecture: any
Depends: libcgal10 (= ${binary:Version}), ${shlibs:Depends}, ${misc:Depends}
+Pre-Depends: ${misc:Pre-Depends}
+Multi-Arch: same
Description: C++ library for computational geometry (support for Qt4)
CGAL (Computational Geometry Algorithms Library) makes the most important
of the solutions and methods developed in computational geometry available
@@ -64,6 +68,7 @@
Depends: libcgal10 (= ${binary:Version}), libboost-dev, libboost-thread-dev,
libboost-system-dev, libboost-program-options-dev, libgmp10-dev, libmpfr-dev,
zlib1g-dev, ${misc:Depends}
+Multi-Arch: same
Description: C++ library for computational geometry (development files)
CGAL (Computational Geometry Algorithms Library) makes the most important
of the solutions and methods developed in computational geometry available
@@ -81,6 +86,7 @@
libcgal-dev, libqt4-dev, ${misc:Depends}
Replaces: libcgal-dev (<< 4.1-1)
Breaks: libcgal-dev (<< 4.1-1)
+Multi-Arch: same
Description: C++ library for computational geometry (development files,
support for Qt4)
CGAL (Computational Geometry Algorithms Library) makes the most important
of the solutions and methods developed in computational geometry available
diff -ru cgal-4.2/debian/libcgal-dev.install x/libcgal-dev.install
--- cgal-4.2/debian/libcgal-dev.install 2012-09-02 12:02:35.0 +0200
+++ x/libcgal-dev.install 2014-01-24 22:40:22.560054330 +0100
@@ -1,11 +1,11 @@
usr/bin/*
usr/include/*
-usr/lib/libCGAL.a
-usr/lib/libCGAL_Core.a
-usr/lib/libCGAL_ImageIO.a
-usr/lib/libCGAL.so
-usr/lib/libCGAL_Core.so
-usr/lib/libCGAL_ImageIO.so
-usr/lib/CGAL/*
-usr/share/cmake-2.8/Modules/*
+usr/lib/*/libCGAL.a
+usr/lib/*/libCGAL_Core.a
+usr/lib/*/libCGAL_ImageIO.a
+usr/lib/*/libCGAL.so
+usr/lib/*/libCGAL_Core.so
+usr/lib/*/libCGAL_ImageIO.so
+usr/lib/*/cmake/CGAL/*
usr/share/man/man1/cgal_create_cmake_script.1
diff -ru cgal-4.2/debian/libcgal-qt4-10.install x/libcgal-qt4-10.install
--- cgal-4.2/debian/libcgal-qt4-10.install 2012-09-02 11:03:57.0
+0200
+++ x/libcgal-qt4-10.install2014-01-24 22:28:30.317648586 +0100
@@ -1 +1 @@
-usr/lib/libCGAL_Qt4.so.* usr/lib
+usr/lib/*/libCGAL_Qt4.so.*
diff -ru cgal-4.2/debian/libcgal-qt4-dev.install x/libcgal-qt4-dev.install
--- cgal-4.2/debian/libcgal-qt4-dev.install 2012-09-02 11:38:15.0
+0200
+++ x/libcgal-qt4-dev.install 2014-01-24 22:28:52.598476927 +0100
@@ -1,5 +1,5 @@
# The next entry is disabled here because it overlaps with the corresponding
# entry in libcgal-dev.install. The files are moved in debian/rules.
# usr/include/CGAL/Qt
-usr/lib/libCGAL_Qt4.a
-usr/lib/libCGAL_Qt4.so
+usr/lib/*/libCGAL_Qt4.a
+usr/lib/*/libCGAL_Qt4.so
diff -ru cgal-4.2/debian/libcgal10.install x/libcgal10.install
--- cgal-4.2/debian/libcgal10.install 2013-03-13 20:00:50.0 +0100
+++ x/libcgal10.install 2014-01-24 22:29:19.179460390 +0100
@@ -1,4 +1,4 @@
-usr/lib/libCGAL.so.* usr/lib
-usr/lib/libCGAL_Core.so.* usr/lib
-usr/lib/libCGAL_ImageIO.so.* usr/lib
+usr/lib/*/libCGAL.so.*
+usr/lib/*/libCGAL_Core.so.*
+usr/lib/*/libCGAL_ImageIO.so.*
usr/share/doc/cgal/changelog usr/share/doc/libcgal10
diff -ru cgal-4.2/debian/rules x/rules
--- cgal-4.2/debian/rules 2013-05-21 23:08:42.0 +0200
+++ x/rules 2014-01-24 22:38:54.672795619 +0100
@@ -13,6 +13,8 @@
export TESTS_IEEE_FPU_OPTION = -mieee -mfp-rounding-mode=d
endif
+export DEB_HOST_MULTIARCH := $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
+
%:
dh $@
@@ -21,12 +23,1
Bug#731082: qemu-user-static: qemu-ppc-static unusable?
I removed ld.so.cache to experiment, and indeed a trivial "hello
world"
program in C works:
#include
int main(){
printf("hello\n");
return 0;
}
(surprisingly, after regenerating ld.so.cache, it keeps working. To make
things simpler, I don't have any ld.so.cache for the rest of this message)
However, the C++ version fails (and almost all C++ programs fail
similarly):
#include
int main(){
std::cout << "hello\n";
return 0;
}
$ qemu-ppc-static cxx
Invalid data memory access: 0xfff4
NIP 0ff65648 LR 0ff65620 CTR 0ff65610 XER
MSR 6040 HID0 HF 6000 idx 0
TB
GPR00 0ff66164 f6fff450 f67cf4a0 f6fff478
GPR04 10010b58 0006 fefefeff 7f7f7f7f
GPR08 8080 f6fff3f0
GPR12 2282 10018b58
GPR16
GPR20
GPR24 1910 0006 f6fff478
GPR28 f67fe018 1910 0ffef904 f6fff478
CR 4280 [ G E - - - - L - ] RES
FPR00 3f847ae14000
FPR04
FPR08
FPR12 3ff0
FPR16
FPR20
FPR24
FPR28
FPSCR
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Unrelated, but I tried generating a static binary to test, and noticed
that the binfmt for qemu didn't recognize that binary. `file` identifies
it as:
ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (GNU/Linux)
instead of:
ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV)
I had to manually call qemu-ppc-static (and it failed like the dynamic
version). Should this format be added to binfmt, or did I mess up getting
such a binary?
--
Marc Glisse
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#731082: qemu-user-static: qemu-ppc-static unusable?
Michael Tokarev wrote: After removing /etc/ld.so.cache it all works fine. So it really looks like a prob with ld.so. Perhaps it's time to reassign this bug to libc6. Ok, that makes sense. I'll let you do the reassignment as I am not very familiar with the BTS (I only just found out that I was supposed to add "cc true" to my .reportbugrc to receive updates on the bug...). Thank you for the investigation, -- Marc Glisse -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#731082: qemu-user-static: qemu-ppc-static unusable?
Package: qemu-user-static Version: 1.7.0+dfsg-2 Severity: normal Dear Maintainer, I managed to run: $ qemu-ppc-static /lib/powerpc-linux-gnu/libc.so.6 which prints the usual text, but so far that's the only program that hasn't failed with: $ qemu-ppc-static ./bin/true Invalid data memory access: 0xb6d15008 NIP f67e257c LR f67e2658 CTR XER MSR 6040 HID0 HF 6000 idx 0 TB GPR00 f67e2634 f6ffecc8 772b5010 GPR04 f67ec31c 000b 0002 GPR08 0030 80b40010 f677500a 0002 GPR12 f67dcb98 f67fea9c f67fe8c4 GPR16 f67fe900 000a GPR20 f67feaf0 f67fd4d8 GPR24 16f9 772b5010 7f51571d c059fff4 GPR28 b6d14ff4 200e f67fdff4 10077fff CR 44282042 [ G G E L E - G E ] RES FPR00 FPR04 FPR08 FPR12 FPR16 FPR20 FPR24 FPR28 FPSCR qemu: uncaught target signal 11 (Segmentation fault) - core dumped (I tested the /bin/true of coreutils_8.21-1_powerpc.deb to make sure it wasn't my cross-compiler that was broken) I must be doing something wrong, but I don't know what, because I followed exactly the same steps as for armhf, and that one is working just fine (thanks!). I also tested on the same system with qemu-ppc (not static), qemu-ppc64abi32, and with the x86 version of qemu-ppc-static, and all failed. It was already failing a lot with version 1.6, but I seem to remember that at least a trivial "return 0" program worked. Other people seem to have more luck, but I have mostly read posts about debootstrap or chroots, not about multiarch setups. According to strace, the segfault happens just after closing /etc/ld.so.cache. On arm, that's followed by a second check for /etc/ld.so.nohwcap and then looking everywhere for libc.so.6. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 armhf powerpc Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash qemu-user-static depends on no packages. Versions of packages qemu-user-static recommends: ii binfmt-support 2.0.16 Versions of packages qemu-user-static suggests: ii sudo 1.8.8-2 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#730622: libopenmpi1.6: conflict with openmpi-checkpoint 1.4.5-1
Package: libopenmpi1.6 Version: 1.6.5-5 Severity: normal Dear Maintainer, during a dist-upgrade, I got: Unpacking libopenmpi1.6 (from .../libopenmpi1.6_1.6.5-5_amd64.deb) ... dpkg: error processing /var/cache/apt/archives/libopenmpi1.6_1.6.5-5_amd64.deb (--unpack): trying to overwrite '/usr/lib/openmpi/lib/openmpi/mca_crs_blcr.so', which is also in package openmpi-checkpoint 1.4.5-1 I think this is usually fixed by adding a Replaces: field, to ensure packages are updated in the right order. (restarting the dist-upgrade with -f seems to have finished the upgrade) -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 armhf powerpc Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libopenmpi1.6 depends on: ii libc6 2.17-93 ii libcr00.8.5-2.1 ii libgcc1 1:4.8.2-1 ii libgfortran3 4.8.2-1 ii libhwloc5 1.7.2-1 ii libibverbs1 1.1.7-1 ii libltdl7 2.4.2-1.3 ii libquadmath0 4.8.2-1 ii libstdc++64.8.2-1 ii libtorque22.4.16+dfsg-1.3 libopenmpi1.6 recommends no packages. libopenmpi1.6 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#727813: pepperflashplugin-nonfree: Specify the arch in sources.list
Package: pepperflashplugin-nonfree Version: 1.1 Severity: normal Dear Maintainer, I installed the package pepperflashplugin-nonfree, but update-pepperflashplugin-nonfree silently failed to do anything. After some debugging, I found out I had to change one line in it: deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main Indeed, I have some foreign architectures configured for which google doesn't provide packages, so apt-get update failed and the script exited. I don't know if we should ignore the apt-get update error, or if we should specify the main architecture in sources.list, or something else... -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 armhf Kernel: Linux 3.10-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages pepperflashplugin-nonfree depends on: ii binutils 2.23.90.20130927-1 ii debconf [debconf-2.0] 1.5.51 ii gnupg 1.4.15-1.1 ii libatk1.0-02.10.0-2 ii libcairo2 1.12.16-2 ii libcurl3-gnutls7.33.0-1 ii libfontconfig1 2.10.2-2 ii libfreetype6 2.4.9-1.1 ii libgcc11:4.8.1-10 ii libglib2.0-0 2.36.4-1 ii libgtk2.0-02.24.21-1 ii libnspr4 2:4.10-1 ii libnss32:3.15.2-1 ii libpango1.0-0 1.32.5-5+b1 ii libstdc++6 4.8.1-10 ii libx11-6 2:1.6.2-1 ii libxext6 2:1.3.2-1 ii libxt6 1:1.1.4-1 ii wget 1.14-4 pepperflashplugin-nonfree recommends no packages. Versions of packages pepperflashplugin-nonfree suggests: ii chromium 30.0.1599.101-1~deb7u1 pn hal ii ttf-dejavu 2.33+svn2514-3 ii ttf-mscorefonts-installer 3.5 ii ttf-xfree86-nonfree4.2.1-3.1 -- debconf-show failed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#724320: gmp: x32: sizeof(mp_limb_t)!=sizeof(void*) is not supported by GAP and PARI
On Fri, 27 Sep 2013, Steve M. Robbins wrote: For readers of gmp-discuss and Daniel Schepler: this concerns a bug reported to Debian regarding GMP on the x32 architecture. In a nutshell: x32 selects a limb size of 8, which means it is larger than a pointer and some software (gap, pari) fail to build. The question is whether it makes sense to change the limb size to 4 on x32. I'd appreciate your thoughts. See full thread at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724320 Hello, the whole point of creating x32 was to benefit from the speed advantages of amd64 without having a pointer size of 64 bits. Those speed advantages include using more registers, but also using hardware 64 bit long long. The speed difference between 32 and 64 bits is very large (a factor >2 for multiplication IIRC, not even counting the fact that we have super-optimized asm for amd64 and may not be spending so much time tweaking the x86 asm for new platforms these days) so it doesn't make sense to me to penalize x32 that way. The assumption that mp_limb_t and void* have the same size is the same kind of problem that we had when people assumed things about long and void*, and most of those got fixed with time (though I know it was very painful to do so in some cases). -- Marc Glisse -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#722541: musixtex: Purging musixtex breaks tex-common
On Thu, 12 Sep 2013, Norbert Preining wrote: On Do, 12 Sep 2013, Marc Glisse wrote: I didn't consciously create it. It says it was auto-generated by update-updmap, in May 2012. It contains the basic stuff (lm-*.map and Hmmm, I don't remember that we created updmap.cfg ever there, I mean by our scripts. Could it be that you called update-updmap by hand as root at some point? I don't remember it at all, but since this was more than a year ago... Maybe if there was an error during an upgrade that mentioned update-updmap, it isn't completely impossible. So I guess the only question is how I ended up with that file (I didn't Do you know/can explain the history of the machine? What was installed, when did you upgrade from what? dpkg.log* only go 1 year back, I am missing a few months for the creation of that file, sorry. Without that, I guess we have no clue how it came into existence. Yes, let's forget it. Thank you for the help, -- Marc Glisse -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#722541: musixtex: Purging musixtex breaks tex-common
On Thu, 12 Sep 2013, Norbert Preining wrote: Hi Marc, On Do, 12 Sep 2013, Marc Glisse wrote: /etc/texmf/web2c/updmap.cfg Did you create this file? It should not be there unless you consciously generated it. I didn't consciously create it. It says it was auto-generated by update-updmap, in May 2012. It contains the basic stuff (lm-*.map and qXX.map), plus extra entries for musixtex.cfg cm-super.cfg cm-super-minimal.cfg tipa.cfg, I don't know if some other package somehow created it. If there is nothing in there, please remove it (or better, rename it). After removing this file, I could purge musixtex with no problem, thanks. So I guess the only question is how I ended up with that file (I didn't do any customization). I guess unless other people have it as well you can close the bug and assume I messed up something (or some old version of some package did). Thank you for your help, -- Marc Glisse -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#722541: musixtex: Purging musixtex breaks tex-common
Package: musixtex Version: 1:0.115.ctan20130123-2 Severity: normal Dear Maintainer, Running sudo apt-get purge musixtex, I got: The following packages will be REMOVED: musixtex* 0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded. After this operation, 9,782 kB disk space will be freed. Do you want to continue [Y/n]? (Reading database ... 298198 files and directories currently installed.) Removing musixtex ... Purging configuration files for musixtex ... Processing triggers for fontconfig ... Processing triggers for man-db ... Processing triggers for tex-common ... Running mktexlsr. This may take some time... done. Running mtxrun --generate. This may take some time... done. Running updmap-sys. This may take some time... updmap-sys failed. Output has been stored in /tmp/updmap.LRcj0sjD Please include this file if you report a bug. Sometimes, not accepting conffile updates in /etc/texmf/updmap.d causes updmap-sys to fail. Please check for files with extension .dpkg-dist or .ucf-dist in this directory dpkg: error processing tex-common (--purge): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: tex-common E: Sub-process /usr/bin/dpkg returned an error code (1) /etc/texmf/updmap.d is empty. The file in /tmp looks like: updmap is using the following updmap.cfg files (in precedence order): /etc/texmf/web2c/updmap.cfg /usr/share/texmf/web2c/updmap.cfg /usr/share/texlive/texmf/web2c/updmap.cfg /usr/share/texlive/texmf-dist/web2c/updmap.cfg dvips output dir: "/var/lib/texmf/fonts/map/dvips/updmap" pdftex output dir: "/var/lib/texmf/fonts/map/pdftex/updmap" dvipdfmx output dir: "/var/lib/texmf/fonts/map/dvipdfmx/updmap" pxdvi output dir: "/var/lib/texmf/fonts/map/pxdvi/updmap" updmap: font lmmi8 is defined multiple times: updmap: lm.map (from /usr/share/texmf/web2c/updmap.cfg) updmap: lm-math.map (from /etc/texmf/web2c/updmap.cfg) (used) updmap: font lmmi6 is defined multiple times: [...] updmap: font t5-lmvtk10 is defined multiple times: updmap: lm.map (from /usr/share/texmf/web2c/updmap.cfg) updmap: lm-t5.map (from /etc/texmf/web2c/updmap.cfg) (used) ERROR: The following map file(s) couldn't be found: musix.map (in /etc/texmf/web2c/updmap.cfg) Did you run mktexlsr? You can disable non-existent map entries using the option --syncwithtrees. Trying to reinstall tex-common keeps failing with the same error, I had to reinstall musixtex to fix it. Trying the purge again fails again in the same way. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.10-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages musixtex depends on: ii dpkg 1.16.10 ii luatex0.70.1.20120524-3 ii tex-common4.03 ii texlive-base 2012.20120611-5 ii texlive-binaries 2012.20120628-4 Versions of packages musixtex recommends: ii ghostscript 9.05~dfsg-8 Versions of packages musixtex suggests: pn m-tx pn pmx -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#705803: Info received (Bug#705803: libcgal-dev: gmpxx and mpfi detection)
(sorry for the late answer, I never received your last comment and only noticed it by chance on the web) I was already about to upload a modified package, but did not manage to do it before my vacation. Now thinking a bit more about the problem I'm no longer sure the outlined solution is the correct one. I am not certain either, but it seemed to make sense to me. If GMPXX/MPFI/NTL support is enabled when building the library itself (and hence defining CGAL_USE_GMPXX/MPFI/NTL in compiler_config.h), won't every application using CGAL get a link dependency to these libraries (assuming it includes a header with #ifdef CGAL_USE_GMPXX/MPFI/NTL)? Only if it really uses it. And it should only use it if that's the best option. For instance, if you compute a Delaunay triangulation with the epick kernel, I don't think it picks up any dependency on any of those 3 libraries. (cmake might link with the whole world by default, or instead forget to link with mpfi, but that's a different issue) For example, there is one example that does no longer build because of that (sorry, don't know the name anymore, but I think the module starts with "A"). Looks like a bug in the build scripts. Isn't the correct solution to enable only support for those libraries that affect the CGAL library itself, and to ask applications using CGAL to add additional -DCGAL_USE_GMPXX/MPFI/NTL flags if they want to make use of these features? (Basically the status quo.) Then you could disable MPFR. Ah, no, GMP is needed for CORE, and cgal can't enable GMP without MPFR... But you could still disable GMP and MPFR after the fact, patching compiler_config.h so that it enables nothing. It is a matter of compromise. Personally, I'd like to be able to compile a program that uses gmpxx without having to pass weird flags like -DCGAL_USE_GMPXX, -lgmpxx should be enough (and possibly not even needed if I don't do I/O, but then even if CGAL_USE_GMPXX is not defined, -lgmpxx may be needed for I/O on gmp types...). And if my program mysteriously becomes twice as slow because I somehow forgot to enable mpfi and cgal thus silently uses a work-around, that's not so good either. And gmpxx/mpfi are small when you are already linking with mpfr+gmp. But I can understand people wanting to control the dependencies of their programs and not just notice in the end which random set of libraries was magically used. So, your choice ;-) -- Marc Glisse PS (unrelated to this issue): it would be nice if you got a chance to start on the multi-arch transition, even if boost/qt prevent you from going all the way for now. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#714593: gnome-bluetooth: 3.8.1-1 fails and breaks gnome desktop
3.4.2-6 ii libatk1.0-02.8.0-2 ii libc6 2.17-6 ii libcairo-gobject2 1.12.14-4 ii libcairo2 1.12.14-4 ii libgdk-pixbuf2.0-0 2.28.2-1 ii libglib2.0-0 2.36.1-2build1 ii libgnome-bluetooth11 3.8.1-1 ii libgtk-3-0 3.4.2-6 ii libpango-1.0-0 1.32.5-5+b1 ii libpangocairo-1.0-01.32.5-5+b1 ii obex-data-server 0.4.5-1+b3 ii obexd-client 0.46-1+b1 ii udev 175-7.2 Versions of packages gnome-bluetooth recommends: ii gnome-control-center 1:3.4.3.1-2 ii gvfs-backends 1.12.3-4 Versions of packages gnome-bluetooth suggests: ii gnome-user-share 3.0.2-1 -- no debconf information -- Marc Glisse -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#708264: mpn/ia64/divrem_2.asm do not restore f17 register
On Thu, 23 May 2013, Bill Allombert wrote: On Thu, May 23, 2013 at 11:36:58AM +0200, Torbjorn Granlund wrote: Thanks for the report! Incidentally, Marco spotted this report someplace, and I committed a fix yesterday. I gather the bug is still present to 5.1.2, so could you advise a fix ? http://gmplib.org:8000/gmp-5.1/rev/394bdf8fdaee -- Marc Glisse -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#705803: libcgal-dev: gmpxx and mpfi detection
Package: libcgal-dev Version: 4.2-1 Severity: wishlist Hello, looking at CGAL/compiler_config.h, I see: #define CGAL_USE_GMP 1 #define CGAL_USE_MPFR 1 //#define CGAL_USE_GMPXX 1 //#define CGAL_USE_LEDA 1 //#define CGAL_USE_MPFI 1 //#define CGAL_USE_RS 1 //#define CGAL_USE_NTL 1 It seems to me that a slight change in build-depends might enable gmpxx, mpfi and possibly ntl. I understand not wanting to add too many little-used dependencies, but at least gmpxx wouldn't be very heavy. -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libcgal-dev depends on: ii libboost-dev 1.49.0.1 ii libboost-program-options-dev 1.49.0.1 ii libboost-system-dev 1.49.0.1 ii libboost-thread-dev 1.49.0.1 ii libcgal10 4.2-1 ii libgmp-dev [libgmp10-dev] 2:5.0.5+dfsg-2 ii libmpfr-dev 3.1.1-1 ii zlib1g-dev1:1.2.7.dfsg-13 libcgal-dev recommends no packages. libcgal-dev suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
