Bug#1060803: marked as pending in gnome-software
Dear Maintainer, I believe you misunderstood the reported issue in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1060803 ie you dropped the patch for to support software-properties-gtk but left the dependency on it, while the request was to move the dependency from a depend to a recommand but keep the patch (ie the patch trigger the gnome software UI if gnome-software-properties-gtk is not installed as requested by the bug reporter). gnome-software-properies is still a dependency but never called even if installed: "Drop patch that hides upstreams Software Sources dialog" https://salsa.debian.org/gnome-team/gnome-software/-/commit/1718e18bf93df01666fe3ee06aef09f674675bfb To me the opposite was asked for: > > > Fair point. We could maybe make it so g-s-p is only a recommended > > > dependency > > > > That is what this request is requesting. Just a change from depend > to > > recommend > > > > > and modify the code so when g-s-p is not available, it > > > falls back to the GS dialog. > > > > I'm not sure what code you're referring to, but when running GNOME > > Software on Debian without s-p-gtk installed, the GS dialog is > instead > > used. > > Neat, looks like I wrote it properly back then :-) > Also appears like the change was reverted upstream a few months ago, > I > wonder why... (we patch it back in at Debian/Ubuntu anyway) > > In any case, I have no objections to moving g-s-p to recommends under > these circumstances :-) Cheers, Alban On Wed, 27 Mar 2024 13:07:46 + Jeremy Bicha wrote: > Control: tag -1 pending > > Hello, > > Bug #1060803 in gnome-software reported by you has been fixed in the > Git repository and is awaiting an upload. You can see the commit > message below and you can check the diff of the fix at: > > https://salsa.debian.org/gnome-team/gnome-software/-/commit/1718e18bf93df01666fe3ee06aef09f674675bfb > > - --- > Drop patch that hides upstreams Software Sources dialog > > Closes: #1060803 > - --- > > (this message was generated automatically) > -- > Greetings > > https://bugs.debian.org/1060803 > >
Bug#787485: marked as pending in gnome-software
Control: reopen -1 This fixup was only applied to the salsa ubuntu branches. "Add patch to disable offline updates" https://salsa.debian.org/gnome-team/gnome-software/-/commit/66efe527de6131a34de142ec2fbbb05f5315e7cc The Debian bug report was closed but the change never reached Debian thus reopening. gnome-software: Allow offline system updates https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787485 Could it be applied to Debian (I have not tested if the patch works with a local rebuild)? This would allow me to upgrade deb packages from gnome-software that would be great. I really don't want to reboot at each Sid package update. Cheers, Alban On Mon, 21 Nov 2022 17:58:44 + Jeremy Bicha wrote: > Control: tag -1 pending > > Hello, > > Bug #787485 in gnome-software reported by you has been fixed in the > Git repository and is awaiting an upload. You can see the commit > message below and you can check the diff of the fix at: > > https://salsa.debian.org/gnome-team/gnome-software/-/commit/66efe527de6131a34de142ec2fbbb05f5315e7cc > > - --- > Add patch to disable offline updates > > Closes: #787485 > LP: #1992498 > - --- > > (this message was generated automatically) > -- > Greetings > > https://bugs.debian.org/787485 > >
Bug#1005227: gnome-software should not recommend fwupd
I am a user, but I will share my findings. On Wed, 09 Feb 2022 14:35:02 +0100 inasprecali wrote: > Package: gnome-software > Version: 3.38.1-1 > Severity: normal > X-Debbugs-Cc: inasprec...@disroot.org > > Dear Maintainer, > > When installing new Debian system (stable release 11.2 at the time of > writing) with as little custom options as possible (e.g., changing none of > the ticks in the screen where you're asked which system components to > install), fwupd ends up being installed and its relative services enabled > and running. Specifically, these services are fwupd.service and > fwupd-refresh.timer, and they show up in "systemctl status" and > "systemctl list-timers" respectively. > > I ran "aptitude why fwupd" to check why it was installed in the first place > (since it did not appear to be installed with desktop environments other > than GNOME) and found out that the package that was pulling fwupd was > gnome-software, which has a "Recommends" dependency on fwupd. > > gnome-software itself ends up being installed together with GNOME as part > of the default install. Since it's a "Recommends" dependency, but not > a "Depends" dependency, it can be removed without an issue. > > However, I think that the "Recommends" dependency itself is a significant > problem, because it violates Debian's "stable" release philosophy. BIOS is not part of the distribution. BIOS upgrades tend to be only for security upgrades or bug fixes so they are already in the Debian stable scope (I would even say it could be a security hole not to upgrade the BIOS nowadays that 90% of BIOS upgrades are only about security fixes). > This > amounts to upgrading firmware-packages "randomly", through an unaudited > process, effectively leaving the user at the mercy of vendors in the LVFS > program. The worst aspect is that, unlike buggy "regular" software which > one can always uninstall via apt, buggy firmware can brick hardware. In > fact, there are precedents of this happening on Ubuntu, for example: > https://github.com/fwupd/fwupd/issues/655 In this link, the upgrade is not automatic. There is a notification and the user acked the upgrade. This upstream report is about user having a buggy firmware version set after hitting the button to upgrade the firmware. https://github.com/fwupd/fwupd/commit/f3fc6461488ba7b3dfad6c4ff33b953a3f1abb8f I have seen an Ubuntu user telling that his BIOS was upgraded without him acknoweldging but I only saw one such report and it might be an Ubuntu program controlling fwupd for the user, even though I doubt they do. https://ubuntuforums.org/showthread.php?t=2475531=2 But not real investigation in these posts. But I have no practical experience with BIOS and fwupd, as my UEFI has no entry in the LVFS db used by fwupd as Lenovo only added their newest systems. Though I had to manually request the UEFI dbx upgrades (not BIOS per se even though updated thtough fwupd). If you have reports of autmotic BIOS upgrades on Debian (or even others reports than Even for non firmwares gnome-software does not do automatic upgrades. https://discuss.getsol.us/d/10282-fwupd tells the BIOS upgrades are automatic for Solus OS then that they are not. None based on experience. > Therefore, my personal recommendation is to remove the "Recommends" > dependency on fwupd from gnome-software (making it an "Suggests" dependency > at most). In fact, due to the potential issues caused by constant firmware > updates, I might recommend making sure that no package such as fwupd ends > up installed by default (of course, users can always install it manually > if they explicitly choose to do so). Of course, although I explained why This is not what Suggest is for. Recommands is to tell that the program still works if the package is missing but will lacks features. fwupd is a recommand per Debian definition. Mangling it into suggest as to not have it installed is abusing the policy. If a package should not be installed it should not be in the dependencies at all. I see the ability to upgrade unsecure BIOS without requiring to be a technician to be an important feature of a Debian system. I am against the "don't touch until it break" when it comes to security and bug fixes. One should not add feature to a stable realease, agreed. Even for BIOS. But these BIOS ugprades are not about adding feature (if only we could have manufacturer provides bug fixes ... they seem to only care about security uploads). You should open a bug report on fwupd for it to not auto upate firmware if it does. But I doubt they do. If it is gnome-software telling fwupd to do the update without the user consent you could reopen the bug against gnome-software. But moving a package from recommands to suggest because upgrading firmware can be risky, I disagree. If you agree with my points, you can send an email to bugnumber-d...@bugs.debian.org to close this report. https://wiki.debian.org/BTS#Closing_bugs As I am neither the
Bug#1066066: Broken videoflip in gstreamer-1.22.0 (Bookworm)
I would suggest fduncanh to submit a MR to https://salsa.debian.org/gstreamer-team/gst-plugins-good1.0 but there does not seem to be a branch for stable. How would one go to submit a MR to gstreamer plugins good? Cheers, Alban On Mon, 11 Mar 2024 18:25:46 -0400 fduncanh wrote: > Package: gstreamer1.0-plugins-good > > Version: 1.22.0-5+deb12u1 > > > A regression inadvertently introduced in GStreamer-1.22.0 breaks user > setting of the "videoflip" feature. > > It was initially fixed in 1.22.3, with three more fix attempts until the > fix stabilized in 1.22.6. > > I have prepared a patch to backport the fix to Debian Bookworm, the > patch and more details are > > available at > https://github.com/FDH2/UxPlay/wiki/patch-for-broken--videoflip-method-in-GStreamer-1.22.0 > > > Since Bookworm will last a long time, it would be good to include this > backport of the fix in some future updates. > > The patch (also attached) includes GStreamer commits > > b17fbb23 > > 2dc0e1ac > > 4c77bc21 > > bbca6cc8 >
Bug#967941: nautilus: fails to generate thumbnails for h264 encoded video files
On Thu, 22 Oct 2020 22:08:37 +0100 Simon McVittie wrote: > Control: reassign 967941 libopenblas0-pthread 0.3.10+ds-2 > Control: affects 967941 + nautilus totem > > On Thu, 22 Oct 2020 at 21:31:41 +0200, Thorsten Ehlers wrote: > > So I dug a little bit deeper into this bug > > Please include some context in replies to bugs: package maintainers will > usually see your messages out of context. > > For the libopenblas0-pthread maintainers: the original bug report is that > h.264 video files were not thumbnailed successfully by GNOME's Nautilus > file manager. The actual thumbnailing is delegated to > totem-video-thumbnailer, from the totem package. > > I can reproduce this with the sample videos from the original bug report > after installing libopenblas0-pthread. After removing libopenblas0- pthread, > the alternative switches to /usr/lib/x86_64-linux- gnu/atlas/libblas.so.3 > and the thumbnailer works again. > > Steps to reproduce: > > $ sudo apt install totem libopenblas0-pthread youtube-dl > $ youtube-dl https://www.youtube.com/watch?v=LTvFsTbyILg > $ youtube-dl https://www.youtube.com/watch?v=l7GX_XII2K0 > $ totem-video-thumbnailer -v Yosemite\ Nature\ Drone\ Video- LTvFsTbyILg.webm tmp.png > (succeeds) > $ totem-video-thumbnailer -v Beautiful\ Nature\ 1080p.- l7GX_XII2K0.mkv tmp.png > > Output: > > TotemVideoThumbnailer-Message: 22:02:21.412: Initialised libraries, about to create video widget > TotemVideoThumbnailer-Message: 22:02:21.436: setting URI file:///home/smcv/tmp/Beautiful%20Nature%201080p.-l7GX_XII2K0.mkv > TotemVideoThumbnailer-Message: 22:02:21.437: Video widget created > TotemVideoThumbnailer-Message: 22:02:21.437: About to open video file > TotemVideoThumbnailer-Message: 22:02:21.713: Checking whether file has cover > TotemVideoThumbnailer-Message: 22:02:21.713: Opened video file: 'Beautiful Nature 1080p.-l7GX_XII2K0.mkv' > TotemVideoThumbnailer-Message: 22:02:21.713: About to seek to 0.33 > TotemVideoThumbnailer-Message: 22:02:21.757: About to get frame for iter 0 > > (totem-video-thumbnailer:98347): GStreamer-WARNING **: 22:02:21.758: failed to create thread: Error creating thread: Resource temporarily unavailable > > (totem-video-thumbnailer:98347): GLib-ERROR **: 22:02:21.763: ../../../glib/gmem.c:112: failed to allocate 3145167 bytes > [1] 98347 trace trap (core dumped) totem-video-thumbnailer -v Beautiful\ Nature\ 1080p.-l7GX_XII2K0.mkv tmp.png > > > and in my case it turned out > > the real problem is libopenblas0-pthread version 0.3.10+ds-2 and - 3. > > > > This package is a dependency of libopenblas0 which is a dependency of Octave and others. > > > > Creating a thumbnail with totem-video-thumbnailer fails for flv and mkv videos like that one mentioned by the OP: > > > > (totem-video-thumbnailer:37500): GStreamer-WARNING **: 21:23:41.129: failed to create thread: Error creating thread: Die Ressource ist zur Zeit nicht verfügbar > > > > (totem-video-thumbnailer:37500): GLib-ERROR **: 21:23:41.131: ../../../glib/gmem.c:112: failed to allocate 3145167 bytes > > Trace/Breakpoint ausgelöst > > > > Installing libopenblas0-pthread_0.3.10+ds-1 or adding the -l option in /usr/share/thumbnailers/totem.thumbnailer works > > around this bug. > > The -l option is documented to disable the time limit for thumbnail the OpenBLAS FAQ tells: https://github.com/OpenMathLib/OpenBLAS/wiki/faq#multi-threaded " If your application is already multi-threaded, it will conflict with OpenBLAS multi-threading. Thus, you must set OpenBLAS to use single thread as following. - export OPENBLAS_NUM_THREADS=1 in the environment variables. Or - Call openblas_set_num_threads(1) in the application on runtime. Or " Would adding openblas_set_num_threads(1) to totem-resource.c be fine? Wouldn't it add a hard dependency to openblas on totem? Should the ffmpeg or gstreamer provide an API to set this openblas number or thread to 1 in case the application is multi-threaded (I believe totem is multi-threaded) to avoid adding such hard dependency in the upper layers if they don't already provides such an API? totem might requiring tweaking the openblas settings as: - not working: LC_ALL=C totem-video-thumbnailer Rogue\ One：\ A\ Star\ Wars\ Story\ Trailer\ #2\ \(Official\)\ \[sC9abcLLQpI\].mp4 a.png (totem-video-thumbnailer:1576790): GLib-ERROR **: 05:17:03.908: ../../../glib/gmem.c:106: failed to allocate 3110543 bytes Trappe pour point d'arrêt et de trace (core dumped) - working: OPENBLAS_NUM_THREADS=1 totem-video-thumbnailer Rogue\ One：\ A\ Star\ Wars\ Story\ Trailer\ #2\ \(Official\)\ \[sC9abcLLQpI\].mp4 a.png and: OPENBLAS_NUM_THREADS= from 1 to 3 is fine, starting at 4 totem errors out with: OPENBLAS_NUM_THREADS=4 totem-video-thumbnailer Rogue\ One：\ A\ Star\ Wars\ Story\ Trailer\ #2\ \(Official\)\ \[sC9abcLLQpI\].mp4 a.png (totem-video-thumbnailer:1576943): GLib-ERROR **: 05:17:26.026: ../../../glib/gmem.c:106: failed to allocate 3404718 bytes Trappe pour point d'arrêt et de
Bug#986432: totem: segfault when opening totem
On Mon, 19 Apr 2021 16:31:34 +0200 =?UTF-8?Q?Bernhard_=c3=9cbelacker?= wrote: > Dear Maintainer, > I tried to have a look and I could reproduce the crash [1]. > > I think this is caused by a call to gtk_list_store_set > in totem_playlist_steal_current_starttime [2]. > There a variadic argument list contains a plain 0, > which might occupy just 32 bit, but gets later interpreted > as gint64, therefore the terminating -1 gets overrun. > > A totem package rebuilt with attached patch does not show > the crash inside the test VM. > > Kind regards, > Bernhard Could you submit a MR upstream for your 32 bits arch patch for totem (critical to armhf use)? https://gitlab.gnome.org/GNOME/totem/-/issues The issue is still there https://gitlab.gnome.org/GNOME/totem/-/blob/master/src/totem-playlist.c?ref_type=heads#L1734 > > [1] > (gdb) bt > #0 strlen () at ../sysdeps/arm/armv6t2/strlen.S:126 > #1 0xb6e82878 in g_strdup (str=0x63fca6aa ) at ../../../glib/gstrfuncs.c:363 > #2 0xb6f47144 in value_collect_string (value=0xbeffee60, n_collect_values=, collect_values=, collect_flags=) at ../../../gobject/gvaluetypes.c:293 > #3 0xb680a3be in gtk_list_store_set_valist_internal (list_store=list_store@entry=0xa0b4c8, iter=iter@entry=0xbeffef44, emit_signal=emit_signal@entry=0xbeffeefc, maybe_need_sort=maybe_need_sort@entry=0xbeffef00, var_args=..., var_args@entry=...) at ../../../../gtk/gtkliststore.c:1033 > #4 0xb680ab52 in gtk_list_store_set_valist (list_store=0xa0b4c8, iter=iter@entry=0xbeffef44, var_args=..., var_args@entry=...) at ../../../../gtk/gtkliststore.c:1137 > #5 0xb680ac1a in gtk_list_store_set (list_store=, iter=0xbeffef44) at ../../../../gtk/gtkliststore.c:1179 > #6 0xb6f91c40 in totem_playlist_steal_current_starttime (playlist=0xa1e100) at ../src/totem-playlist.c:1790 > #7 0xb6f8b590 in update_seekable (totem=0x450140) at ../src/totem-object.c:2524 > #8 property_notify_cb_seekable (bvw=, spec=, totem=0x450140) at ../src/totem-object.c:2616 > #9 0xb6f2b252 in g_closure_invoke (closure=0x6e7048, return_value=return_value@entry=0x0, n_param_values=2, param_values=param_values@entry=0xbefff090, invocation_hint=invocation_hint@entry=0xbefff00c) at ../../../gobject/gclosure.c:810 > #10 0xb6f38768 in signal_emit_unlocked_R (node=node@entry=0x448800, detail=105, instance=0xa6e290, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0xbefff090) at ../../../gobject/gsignal.c:3739 > #11 0xb6f3ce12 in g_signal_emit_valist (instance=instance@entry=0xa6e290, signal_id=signal_id@entry=1, detail=detail@entry=320612, var_args=..., var_args@entry=...) at ../../../gobject/gsignal.c:3495 > #12 0xb6f3d0a2 in g_signal_emit (instance=instance@entry=0xa6e290, signal_id=signal_id@entry=1, detail=105) at ../../../gobject/gsignal.c:3551 > #13 0xb6f2e33e in g_object_dispatch_properties_changed (object=0xa6e290, n_pspecs=1, pspecs=) at ../../../gobject/gobject.c:1206 > #14 0xb6f2faac in g_object_notify_by_spec_internal (pspec=, object=0xa6e290) at ../../../gobject/gobject.c:1299 > #15 g_object_notify (object=0xa6e290, property_name=) at ../../../gobject/gobject.c:1347 > #16 0xb6f9b9ec in got_time_tick (time_nanos=, bvw=bvw@entry=0xa6e290, play=) at ../src/backend/bacon- video-widget.c:2614 > #17 0xb6f9ca02 in bvw_query_timeout (bvw=bvw@entry=0xa6e290) at ../src/backend/bacon-video-widget.c:2830 > #18 0xb6fa0792 in bvw_bus_message_cb (bus=, message=, bvw=0xa6e290) at ../src/backend/bacon-video- widget.c:2485 > #19 0xb6f2d2e8 in g_cclosure_marshal_VOID__BOXEDv (closure=0xaaf750, return_value=, instance=0x9f8bf0, args=..., marshal_data=0x0, n_params=1, param_types=0x7d1118) at ../../../gobject/gmarshal.c:1686 > #20 0xb6f2b3d8 in _g_closure_invoke_va (closure=closure@entry=0xaaf750, return_value=0x0, instance=0x9f8bf0, instance@entry=0x0, args=..., args@entry=..., n_params=n_params@entry=1, param_types=0x7d1118) at ../../../gobject/gclosure.c:873 > #21 0xb6f3cef6 in g_signal_emit_valist (instance=0x0, instance@entry=0x9f8bf0, signal_id=, detail=0, detail@entry=3204445364, var_args=..., var_args@entry=...) at ../../../gobject/gsignal.c:3404 > #22 0xb6f3d0a2 in g_signal_emit (instance=instance@entry=0x9f8bf0, signal_id=, detail=289) at ../../../gobject/gsignal.c:3551 > #23 0xb64b1420 in gst_bus_async_signal_func (bus=0x9f8bf0, message=0xa5405068, data=) at ../gst/gstbus.c:1295 > #24 0xb64b2008 in gst_bus_source_dispatch (source=0xa8a388, callback=0xb64b13e5 , user_data=0x0) at ../gst/gstbus.c:851 > #25 0xb6e6bf4c in g_main_dispatch (context=0x46e678) at ../../../glib/gmain.c:3325 > #26 g_main_context_dispatch (context=context@entry=0x46e678) at ../../../glib/gmain.c:4043 > #27 0xb6e6c1e0 in g_main_context_iterate (context=context@entry=0x46e678, block=block@entry=1, dispatch=dispatch@entry=1, self=) at ../../../glib/gmain.c:4119 > #28
Bug#984639: totem-video-thumbnailer: segfault in totem-video-thumbnailer
On Sat, 06 Mar 2021 11:30:43 +0200 Svjatoslav Agejenko wrote: > Package: totem-video-thumbnailer > Version: totem > Severity: important > X-Debbugs-Cc: svjatos...@svjatoslav.eu > > Dear Maintainer, > > Video thumbnails are not shown in GNOME files. > dmesg output shows errors like this: > > [ 173.111788] qtdemux0:sink[5358]: segfault at 0 ip sp > 7f0ef9d45d18 error 14 in totem-video- thumbnailer[56461b0f5000+3000] > [ 173.111806] Code: Unable to access opcode bytes at RIP 0xffd6. > [ 174.064475] qtdemux0:sink[5395]: segfault at 0 ip sp > 7f50d5f0fd18 error 14 in totem-video- thumbnailer[55c85c214000+3000] > [ 174.064483] Code: Unable to access opcode bytes at RIP 0xffd6. > > Video thumbnails functionality worked well in Debian 10. > It is now broken in Debian 11. This is likely a duplicate of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973942 Can you try to reproduce the segfault from command line by running: /usr/bin/totem-video-thumbnailer --verbose --gst-debug-level=3 -s 256 test.png you should get something like: LC_ALL=C totem-video-thumbnailer Rogue\ One：\ A\ Star\ Wars\ Story\ Trailer\ #2\ \(Official\)\ \[sC9abcLLQpI\].mp4 c.png "(totem-video-thumbnailer:1553984): GLib-ERROR **: 03:32:05.259: ../../../glib/gmem.c:106: failed to allocate 3110543 bytes Trappe pour point d'arrêt et de trace (core dumped)" or even only "Processus stopped" You could then try if /usr/bin/totem-video-thumbnailer -l --verbose --gst-debug-level=3 -s 256 test.png indeed succeed when the former did not. Then it will point at a likely upstream choice to sandbox the totem video thumbanilera bit too much, at least to get old codec decoded. We should investigate if the issue was already rejected upstream. If not open a bug report to have them raise the limit. The segfault in my case was caused by the totem thumbaniler resource sandbox too low which lead to failure to spawn thread and alocate memory ending in a segfault. Note: Without the internal totem limit on the resource usage the thumbnailing is really fast on this box, no way it could reach the 30 seconds limit. So I suppose the cpu and memory limits are at fault. I tried removing libopenblas0-pthread as suggested by https://blog.frehi.be/2021/06/19/missing-video-thumbnails-in-nautilus-in-debian-bullseye/ but the removal installed libopenblas0-openmp with which totem-video- thumnailer still failed only with the "Processus stopped" error. Cheers, Alban
Bug#1070826: totem: Cannot create profiling:/build direcotry errors when quitting totem (even without playback) - Debian packaging?
Package: totem Version: 43.0-3+b1 Severity: normal Dear Maintainer, When I open totem then quit it (whatver I dod inside totem even if I do nothing), I get this error output on the console. It might well be a libdmapsharing library or plugin issue. I do not get this error from th flatpak of totem: Vidéos org.gnome.Totem 43.0 stable flathub user Codecs org.gnome.Totem.Codecs stable flathub user yt-dl totem-pl-parser plugin org.gnome.Totem.Videosite.YouTubeDl stable flathub user profiling:/build:Cannot create directory profiling:/build/reproducible-path/libdmapsharing-3.9.13/libdmapsharing/.libs/libdmapsharing_4_0_la-gst-util.gcda:Skip profiling:/build:Cannot create directory profiling:/build/reproducible-path/libdmapsharing-3.9.13/libdmapsharing/.libs/libdmapsharing_4_0_la-dmap-transcode-wav-stream.gcda:Skip profiling:/build:Cannot create directory profiling:/build/reproducible-path/libdmapsharing-3.9.13/libdmapsharing/.libs/libdmapsharing_4_0_la-dmap-transcode-qt-stream.gcda:Skip profiling:/build:Cannot create directory profiling:/build/reproducible-path/libdmapsharing-3.9.13/libdmapsharing/.libs/libdmapsharing_4_0_la-dmap-transcode-mp3-stream.gcda:Skip profiling:/build:Cannot create directory profiling:/build/reproducible-path/libdmapsharing-3.9.13/libdmapsharing/.libs/libdmapsharing_4_0_la-dmap-transcode-stream.gcda:Skip profiling:/build:Cannot create directory profiling:/build/reproducible-path/libdmapsharing-3.9.13/libdmapsharing/.libs/libdmapsharing_4_0_la-dmap-mdns-publisher-avahi.gcda:Skip profiling:/build:Cannot create directory profiling:/build/reproducible-path/libdmapsharing-3.9.13/libdmapsharing/.libs/libdmapsharing_4_0_la-dmap-mdns-browser-avahi.gcda:Skip profiling:/build:Cannot create directory profiling:/build/reproducible-path/libdmapsharing-3.9.13/libdmapsharing/.libs/libdmapsharing_4_0_la-dmap-mdns-avahi.gcda:Skip profiling:/build:Cannot create directory profiling:/build/reproducible-path/libdmapsharing-3.9.13/libdmapsharing/.libs/libdmapsharing_4_0_la-test-dmap-image-record-factory.gcda:Skip profiling:/build:Cannot create directory profiling:/build/reproducible-path/libdmapsharing-3.9.13/libdmapsharing/.libs/libdmapsharing_4_0_la-test-dmap-image-record.gcda:Skip profiling:/build:Cannot create directory profiling:/build/reproducible-path/libdmapsharing-3.9.13/libdmapsharing/.libs/libdmapsharing_4_0_la-test-dmap-db.gcda:Skip profiling:/build:Cannot create directory profiling:/build/reproducible-path/libdmapsharing-3.9.13/libdmapsharing/.libs/libdmapsharing_4_0_la-test-dmap-container-record.gcda:Skip profiling:/build:Cannot create directory profiling:/build/reproducible-path/libdmapsharing-3.9.13/libdmapsharing/.libs/libdmapsharing_4_0_la-test-dmap-container-db.gcda:Skip profiling:/build:Cannot create directory profiling:/build/reproducible-path/libdmapsharing-3.9.13/libdmapsharing/.libs/libdmapsharing_4_0_la-test-dmap-av-record-factory.gcda:Skip profiling:/build:Cannot create directory profiling:/build/reproducible-path/libdmapsharing-3.9.13/libdmapsharing/.libs/libdmapsharing_4_0_la-test-dmap-av-record.gcda:Skip profiling:/build:Cannot create directory profiling:/build/reproducible-path/libdmapsharing-3.9.13/libdmapsharing/.libs/libdmapsharing_4_0_la-dmap-image-share.gcda:Skip profiling:/build:Cannot create directory profiling:/build/reproducible-path/libdmapsharing-3.9.13/libdmapsharing/.libs/libdmapsharing_4_0_la-dmap-image-record.gcda:Skip profiling:/build:Cannot create directory profiling:/build/reproducible-path/libdmapsharing-3.9.13/libdmapsharing/.libs/libdmapsharing_4_0_la-dmap-image-connection.gcda:Skip profiling:/build:Cannot create directory profiling:/build/reproducible-path/libdmapsharing-3.9.13/libdmapsharing/.libs/libdmapsharing_4_0_la-dmap-utils.gcda:Skip profiling:/build:Cannot create directory profiling:/build/reproducible-path/libdmapsharing-3.9.13/libdmapsharing/.libs/libdmapsharing_4_0_la-dmap-structure.gcda:Skip profiling:/build:Cannot create directory profiling:/build/reproducible-path/libdmapsharing-3.9.13/libdmapsharing/.libs/libdmapsharing_4_0_la-dmap-share.gcda:Skip profiling:/build:Cannot create directory profiling:/build/reproducible-path/libdmapsharing-3.9.13/libdmapsharing/.libs/libdmapsharing_4_0_la-dmap-record-factory.gcda:Skip profiling:/build:Cannot create directory profiling:/build/reproducible-path/libdmapsharing-3.9.13/libdmapsharing/.libs/libdmapsharing_4_0_la-dmap-record.gcda:Skip profiling:/build:Cannot create directory
Bug#1037084: bookworm: When using gdm3 to start non-GNOME wayland sessions, PATH may be set differently
On Mon, 29 Apr 2024 13:09:27 -0700 Jay wrote: > On Sat, Jun 17, 2023 at 4:55 AM Alban Browaeys wrote: > > This bug would likely be fixed by Debian (the systemd package?) > > shipping a /usr/lib/systemd/user-environment-generators/ systemd user > > environment generator with the default PATH Debian already set in > > /etc/profile. > I plan to check with the Debian systemd package maintainers about this option. > > But > > Or ship an /usr/lib/environment.d/*.conf file (which itself is read by > > a systemd user environment generator : /usr/lib/systemd/user- > > environment-generators/30-systemd-environment-d-generator). > This might be the solution we're looking for. A > /usr/lib/environment.d/??-gdm3.conf file > provided by the gdm3 package? No, in that it should not be named after gdm. It is a bit far, but to me your issue is due to gdm3 not overwriting the systemd user environment with its own PATH value anymore. This means that you got things back working by reverting https://gitlab.gnome.org/GNOME/gdm/-/commit/ccecd9c975d04da80db4cd547b67a1a94fa83292 because you made gdm3 overwrite the system user session environment PATH value as it was doing before. So the issue is that the systemd user enviroment is not set properly for Debian specific PATH components (and that gdm3 does not overwrite this systemd user session PATH value anymore if one is set, thus the gdm3 fallback PATH mention in the patch. That is if no PATH value is defined in the environment, then the old behavior of gdm setting it is preserved, but if one is defined, then it is not changed). Thus if you get the wrong PATH value it is not because gdm set it to the wrong value, but because it stopped overweriting the bad value (in that Debian requires a specific value that is not hte default and as no Debian specific config has been provided, the default is wrong). So the issue is, to me, Debian systemd specific and only involves gdm because it has stopped overwriting the systemd default value (which is wrong on Debian because Debian has specific path). The Debian specific defaults are shown in /etc/profile if [ "$(id -u)" -eq 0 ]; then PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" else PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games" fi export PATH Debian systemd package just need to ship a config file to set this PATH value. So a /usr/lib/environment.d/??-debian.conf file shipped by the Debian systemd package is what I deem the correct fix. This bug report should be reassigned to systemd in my opinion. So you were right that reverting commit ccecd9c9 would fix your issue, but not because gdm added a bug but because it stopped hiding an underlying "bug" (well wrong default PATH value in systemd for Debian). It could be that systemd maintainers thing this is gdm job to overwrite their value, though it looks more correct to me to bug them first as they are the one setting the wrong default for Debian (or so I believe, I have not checked extensively if the wrong PATH default value could be fine at the systemd level and be changed afterwards). Cheers, Alban
Bug#1070119: gnome-remote-desktop: missing gnome-remote-desktop user setup in salsa upcoming 46 version
Le mardi 30 avril 2024 à 10:37 -0400, Jeremy Bícha a écrit : > > I believe the bug is import as it prevents opening a new desktop > > session > > (but it still works when connection to an existing session). > > Yes, I've bumped the severity but what do you mean about connecting > to > an existing session? It's not intended to run, for instance, > gnome-remote-desktop 45 with gnome-shell 46 or with gnome-shell 44 > but > I guess the package dependencies aren't set quite that strict. > I meant that as of GS 46 we should be able to login via RDP even if no gnome shell session is opened (or so I understood). I believe the system daemon is required for that. I am also interested in being able to login to a locked gnome shell session, which as far as I understand is possible with gnome shell 46. So I did not mean mixinf gnome-shell/gnome-remote-desktop version. My interest was into connection via RDP to a not unlocked or already opened remote Gnome Shell. As of now I us the "Allow Locked Remote Desktop" extension and gdm3 autologin on the remote gnome shell user session. I would like to get rid of these hacks (especially since I have to set an empty password on my gnome keyring for such a setup). Cheers, Alban
Bug#1070119: gnome-remote-desktop: missing gnome-remote-desktop user setup in salsa upcoming 46 version
Package: gnome-remote-desktop Version: 46.1-1 Severity: normal I believe the bug is import as it prevents opening a new desktop session (but it still works when connection to an existing session). The issue seems to be that the user gnome-remote-desktop is not existing thus the system wide systemd gnome-remote-desktop.service fails to start: journalctl -b -u gnome-remote-desktop.service avril 30 15:47:42 hermes systemd[1]: Starting gnome-remote-desktop.service - GNOME Remote Desktop... avril 30 15:47:42 hermes (p-daemon)[855818]: gnome-remote-desktop.service: Failed to determine user credentials: No such process avril 30 15:47:42 hermes systemd[1]: gnome-remote-desktop.service: Main process exited, code=exited, status=217/USER avril 30 15:47:42 hermes systemd[1]: gnome-remote-desktop.service: Failed with result 'exit-code'. avril 30 15:47:42 hermes systemd[1]: Failed to start gnome-remote-desktop.service - GNOME Remote Desktop. Also there is an error message about being unable to create the gnoem-remote-desktop home /var/lib/gnome-remote-desktop and /etc/gnome-remote-desktop as user and group gnome-remote-desktop: sudo LC_ALL=C dpkg -i gnome-remote-desktop_46.1-1_amd64.deb (Reading database ... 728947 files and directories currently installed.) Preparing to unpack gnome-remote-desktop_46.1-1_amd64.deb ... Unpacking gnome-remote-desktop (46.1-1) over (46.1-1) ... Setting up gnome-remote-desktop (46.1-1) ... /usr/lib/tmpfiles.d/gnome-remote-desktop-tmpfiles.conf:2: Failed to resolve user 'gnome-remote-desktop': No such process /usr/lib/tmpfiles.d/gnome-remote-desktop-tmpfiles.conf:3: Failed to resolve user 'gnome-remote-desktop': No such process Could not execute systemctl: at /usr/bin/deb-systemd-invoke line 148. Processing triggers for gnome-menus (3.36.0-1.1+b2) ... Processing triggers for desktop-file-utils (0.27-2) ... Processing triggers for mailcap (3.70+nmu1) ... Processing triggers for dbus (1.14.10-4+b1) ... Processing triggers for libglib2.0-0t64:i386 (2.80.0-6) ... Processing triggers for libglib2.0-0t64:amd64 (2.80.0-6) ... Processing triggers for man-db (2.12.1-1) ... /usr/lib/tmpfiles.d/gnome-remote-desktop-tmpfiles.conf # tmpfiles.d file to ensure the existence of the home directory for gnome-remote-desktop user d /var/lib/gnome-remote-desktop 0700 gnome-remote-desktop gnome-remote-desktop d /etc/gnome-remote-desktop 0755 gnome-remote-desktop gnome-remote-desktop indeed I have no gnome-remote-desktop user: $ getent passwd|grep gnome I found no issue tracker on the salsa project for gnome-remote-desktop so opened the issue here. Cheers Alban -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 'oldstable-debug'), (500, 'oldoldstable'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.9.0-rc5+ (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 gnome-remote-desktop depends on: ii dconf-gsettings-backend [gsettings-backend] 0.40.0-4+b2 ii fuse33.14.0-5 ii init-system-helpers 1.66 ii libc62.37-19 ii libcairo21.18.0-3+b1 ii libei1 1.2.1-1 ii libepoxy01.5.10-1+b2 ii libfreerdp-server3-3 3.5.1+dfsg1-1 ii libfreerdp3-33.5.1+dfsg1-1 ii libfuse3-3 3.14.0-5 ii libglib2.0-0t64 2.80.0-6 ii libmutter-14-0 46.1-1 ii libnotify4 0.8.3-1+b1 ii libopus0 1.4-1+b1 ii libpipewire-0.3-0t64 1.0.5-1+b3 ii libpolkit-gobject-1-0124-2 ii libsecret-1-00.21.4-1+b1 ii libsystemd0 255.5-1 ii libtss2-esys-3.0.2-0t64 4.0.1-7.2 ii libtss2-mu-4.0.1-0t644.0.1-7.2 ii libtss2-rc0t64 4.0.1-7.2 ii libtss2-tctildr0t64 4.0.1-7.2 ii libwinpr3-3 3.5.1+dfsg1-1 ii libxkbcommon01.6.0-1+b1 ii pipewire 1.0.5-1+b3 ii wireplumber 0.4.17-1+b2 gnome-remote-desktop recommends no packages. gnome-remote-desktop suggests no
Bug#1070074: several errors on tab completion
Package: bash-completion
Followup-For: Bug #1070074
I doubt this issue is related to util-linux-extra being too old.
I had a similar error while pressing "sudo" I got the error:
"sudo bash: _comp_initialize : commande introuvable"
ie "commande introuvable" is "command not found".
It turned out that this error only happens in bash shell I had opened
before the upgrade (the fact you had the issue opening new bash shell is
awakward to me). The bash shell I opened after were fine.
Note the _comp_deprecate_var, _comp_xxx functions are defined in
/usr/share/bash-completion/bash_completion
which is part of the bash-completion package, so upgrading
util-linux-extra can have no effect on them being present or not.
From the error I got above I guess bash completion
/usr/share/bash-completion/completions/*
might get source anew after upgrade while the
/usr/share/bash-completion/bash-completion common function definition
file is not.
A way to workaround this issue would be to source this file in existing
bash shells: "source /usr/share/bash-completion/bash_completion" indeed
fixed my shell with broken "sudo" and missing _comp_initialize
command.
I see no easy fix as as far as I know, the
/usr/share/bash-completion/bash_completion
is imported when the bash shell is started (profile file or bashrc) but it
seems the
completion files can be source during the shell runtime.
Maybe the a check at each completion files function call could be added
to check if /usr/share/bash-completion/bash_completion has changed and
source it when so. But this looks more like an upstream issue
than a Debian specific topic.
NB: I still do not understand why you got the "command not found" when
opening a new bash shell. The new
/usr/share/bash-completion/bash_completion is source from the latest
version at this point.
Maybe your $HOME/.bashrc is not up to date:
/etc/skel/.bashrc: (should be in your $HOME/.bashrc)
# If not running interactively, don't do anything
case $- in
*i*) ;;
*) return;;
esac
(...)
# enable programmable completion features (you don't need to enable
# this, if it's already enabled in /etc/bash.bashrc and /etc/profile
# sources /etc/bash.bashrc).
if ! shopt -oq posix; then
if [ -f /usr/share/bash-completion/bash_completion ]; then
. /usr/share/bash-completion/bash_completion
elif [ -f /etc/bash_completion ]; then
. /etc/bash_completion
fi
fi
/etc/bash.bashrc:
# enable bash completion in interactive shells
#if ! shopt -oq posix; then
# if [ -f /usr/share/bash-completion/bash_completion ]; then
#. /usr/share/bash-completion/bash_completion
# elif [ -f /etc/bash_completion ]; then
#. /etc/bash_completion
# fi
#fi
or it is not imported from your $HOME/.profile which should have:
# if running bash
if [ -n "$BASH_VERSION" ]; then
# include .bashrc if it exists
if [ -f "$HOME/.bashrc" ]; then
. "$HOME/.bashrc"
fi
fi
but even then /etc/profile should have source the common bash completion
functions:
/etc/profile:
/etc/profile.d/bash_completion.sh
# shellcheck shell=sh disable=SC1091,SC2166,SC2268,SC3028,SC3044,SC3054
# Check for interactive bash and that we haven't already been sourced.
if [ "x${BASH_VERSION-}" != x -a "x${PS1-}" != x -a
"x${BASH_COMPLETION_VERSINFO-}" = x ]; then
# Check for recent enough version of bash.
if [ "${BASH_VERSINFO[0]}" -gt 4 ] ||
[ "${BASH_VERSINFO[0]}" -eq 4 -a "${BASH_VERSINFO[1]}" -ge 2 ]; then
[ -r "${XDG_CONFIG_HOME:-$HOME/.config}/bash_completion" ] &&
. "${XDG_CONFIG_HOME:-$HOME/.config}/bash_completion"
if shopt -q progcomp && [ -r /usr/share/bash-completion/bash_completion
]; then
# Source completion code.
. /usr/share/bash-completion/bash_completion
fi
fi
fi
Cheers
Alban
-- System Information:
Debian Release: trixie/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500,
'stable-debug'), (500, 'oldstable-debug'), (500, 'oldoldstable'), (500,
'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1,
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.9.0-rc5+ (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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#1053245: fluidsynth: Fluidsynth starts at boot and blocks the sound device, no obvious way to disable it
On Thu, 2 Nov 2023 23:05:28 +0100 at46 wrote: > I had the same problem and it took me quite some time to find that > fluidsynth was the root cause of this. Fluidsynth was installed as new > dependency from lutris 0.5.14 and blocked my sound device each ~second > boot. > > @Patrick I could check the status with "systemctl --user status > fluidsynth" and disable it with "sudo systemctl --global disable > fluidsynth.service" > fluidsynth and pulseaudio are both user session services. They are started at login (ie not at boot). >From /usr/lib/systemd/user/fluidsynth.service, it seems only pipewire is handled, ie not pulseaudio: " [Unit] Description=FluidSynth Daemon Documentation=man:fluidsynth(1) After=sound.target After=pipewire.service [Service] # added automatically, for details please see # https://en.opensuse.org/openSUSE:Security_Features#Systemd_hardening_effort ProtectSystem=full ProtectHome=read-only ProtectHostname=true ProtectKernelTunables=true ProtectKernelModules=true ProtectKernelLogs=true ProtectControlGroups=true # end of automatic additions # required in order for the above sandboxing options to work on a user unit PrivateUsers=yes Type=notify NotifyAccess=main EnvironmentFile=/etc/default/fluidsynth EnvironmentFile=-%h/.config/fluidsynth ExecStart=/usr/bin/fluidsynth -is $OTHER_OPTS $SOUND_FONT [Install] WantedBy=default.target " Seems you are running native pulseaudio and not pipewire-pulse. Could you try adding pulseaudio.service "pulseaudio.service" to the "After" directive of fluidsynth.service, via systemctl --user edit fluidsynth.service by writing in the editor that will open: " [Unit] After=pipewire.service pulseaudio.service " then running: systemctl --user daemon-reload and logout/login, then check that pulseaudio see your audio device? Still, fluidsynth should be running, so the issue might be otherwise. At least with pipewire/pipewire-pulse/fluidsynth I have all of them up simultaneously for the whole user session. Best regards, Alban
Bug#1066110: tracker-extract: regular crash
On Thu, 21 Mar 2024 20:51:23 +0100 Patrice Duroux wrote: > So did a forcemerge 1066898 1066110 be a better way to proceed? > Yes, that would be fine too as far as I know (I am not a Debian Developer). I believe it will then close this bug report too. By the way I think your question implies that this bug is fixed by 3.7.0-1, isn't it? Cheers, Alban > Le jeu. 21 mars 2024 à 10:40, Alban Browaeys > a écrit : > > > > On Thu, 14 Mar 2024 22:04:33 +0100 intrigeri > > wrote: > > > Hi, > > > > > > I see a similar crash every 2-4 seconds on my sid system since some > > recent > > > upgrade. > > > > > > This looks like > > > https://gitlab.gnome.org/GNOME/tracker-miners/-/issues/312. > > > > > > > > > Looks like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066898 > > > > > I lack time to do this myself but it could be interesting to check if > > > the upstream fix resolves this for you: > > > > > https://gitlab.gnome.org/GNOME/tracker-miners/-/merge_requests/516/diffs > > > … which I understand will be included in 3.7 stable. > > > > > > > > > Should be fixed by 3.7.0-1 which is available in unstable since a day. > > Could you upgrade and clos this bug report if fixed? > > > > Regards, > > Alban > >
Bug#1066110: tracker-extract: regular crash
On Thu, 14 Mar 2024 22:04:33 +0100 intrigeri wrote: > Hi, > > I see a similar crash every 2-4 seconds on my sid system since some recent > upgrade. > > This looks like > https://gitlab.gnome.org/GNOME/tracker-miners/-/issues/312. > Looks like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066898 > I lack time to do this myself but it could be interesting to check if > the upstream fix resolves this for you: > https://gitlab.gnome.org/GNOME/tracker-miners/-/merge_requests/516/diffs > … which I understand will be included in 3.7 stable. > Should be fixed by 3.7.0-1 which is available in unstable since a day. Could you upgrade and clos this bug report if fixed? Regards, Alban
Bug#1064196: tracker-extract: Repeatedly coredumps
Could you install the debug packages so as to get a more complete stacktrace? (I believe nvidia ones at least) Cheers Alban On Sun, 18 Feb 2024 10:11:32 +0100 Nicolas Patrois wrote: > Package: tracker-extract > Version: 3.4.6-3 > Severity: important > Tags: upstream > > Dear Maintainer, > > tracker got installed automatically, why not. > But this morning, tracker-extract coredumps systematically: my old machine was > unusable. > Here is an example of systemd-coredump’s output in the logs: > > févr. 18 09:52:56 [mymachine] systemd-coredump[28563]: [] Process 28551 > (tracker-extract) of user 65534 dumped core. > > Module libnvidia- > fatbinaryloader.so.390.157 without build-id. > Module libcuda.so.1 > without build-id. > Module libsystemd.so.0 > from deb systemd-255.3-2.i386 > Module > libarchive.so.13 from deb libarchive-3.7.2-1.i386 > Module libzstd.so.1 > from deb libzstd-1.5.5+dfsg2-2.i386 > Module libudev.so.1 > from deb systemd-255.3-2.i386 > Stack trace of thread > 28551: > #0 0xb7fa5577 > __kernel_rt_sigreturn (linux-gate.so.1 + 0x577) > #1 0xa1947e5e > n/a (libnvidia-fatbinaryloader.so.390.157 + 0x2e5e) > ELF object binary > architecture: Intel 80386 > > I won’t send send a coredump here (about 20 MB) but if you want one, just ask. > For example there are 43 coredumps in /var/lib/systemd/coredump/, like: > core.tracker- > extract.65534.68bda4c586434f3d9e89df19e3f88eae.28551.170824633700.z st > > Yours, > n. > > > -- System Information: > Debian Release: trixie/sid > APT prefers unstable > APT policy: (500, 'unstable'), (500, 'stable') > Architecture: i386 (i686) > > Kernel: Linux 5.16.0-6-686-pae (SMP w/3 CPU threads; PREEMPT) > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE > Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR:fr:en_GB:en > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages tracker-extract depends on: > ii dconf-gsettings-backend [gsettings-backend] 0.40.0-4+b1
Bug#1066898: tracker-extract: always crash - related to sandboxing making chmod from fontconfig to always fail
Could you publish a tracker-miners 3.7 debian release for unstable? I was preparing a salsa MR but it turns out that tracker-miners 3.7 was released today and contains these two fixes. The chmod sigsys giving an endless loop of coredumps is fixed by: https://gitlab.gnome.org/GNOME/tracker-miners/-/commit/883f97e32e42df4db66005a1e8f48ba084ec7cac reported upstream at https://gitlab.gnome.org/GNOME/tracker-miners/-/issues/320 [46.rc] Program terminated with signal SIGSYS, Bad system call. MR: https://gitlab.gnome.org/GNOME/tracker-miners/-/merge_requests/516 libtracker-miners-common: Disallow chmod/fchmod with soft errors The /etc/fonts/fonts.conf read error is fixed: https://gitlab.gnome.org/GNOME/tracker-miners/-/commit/ce81b1d1c999ee3c0046f3f09876b00028c5cccd libtracker-miners-common: Allow readonly access to /etc/fonts Cheers, Alban On Fri, 15 Mar 2024 06:30:12 +0100 Alban Browaeys wrote: > Package: tracker-extract > Version: 3.7~rc-3 > Severity: grave > Justification: renders package unusable > > Dear Maintainer, > > * What led up to the situation? > I believe upgrading to Sid from Trixie a few days ago. > > > mars 15 06:10:37 hermes tracker-miner-fs-3[1633275]: Fontconfig error: Cannot load default config file: Unable to open /etc/fonts/fonts.conf > mars 15 06:10:37 hermes tracker-miner-fs-3[1633275]: Disallowed syscall "chmod" caught in sandbox > mars 15 06:10:37 hermes systemd[1]: Started systemd-coredump@33956-1633288-0.service - Process Core Dump (PID 1633288/UID 0). > mars 15 06:10:38 hermes systemd[1]: Started drkonqi-coredump-processor@33956-1633288-0.service - Pass systemd- coredump journal entries to relevant user for potential DrKonqi handling. > mars 15 06:10:38 hermes systemd-coredump[1633289]: Removed old coredump core.tracker- extract.1000.4370b7ec7f8d4cf8998826bce50c6f8b.1553954.171047636300. zst. > mars 15 06:10:38 hermes drkonqi-coredump-processor[1633290]: Entry doesn't look like a dump. This may have been a vaccum run. Nothing to process. > mars 15 06:10:38 hermes systemd-coredump[1633289]: [] Process 1633275 (tracker-extract) of user 1000 dumped core. > > Module libsystemd.so.0 from deb systemd-255.4-1+b1.amd64 > Module libudev.so.1 from deb systemd-255.4-1+b1.amd64 > Module libarchive.so.13 from deb libarchive-3.7.2-1.1.amd64 > Module libzstd.so.1 from deb libzstd-1.5.5+dfsg2-2.amd64 > Stack trace of thread 1633287: > #0 0x7f50633aa207 __tgkill (libc.so.6 + 0x10a207) > #1 0x7f50632dc510 __restore_rt (libc.so.6 + 0x3c510) > #2 0x7f50633975a7 __GI___chmod (libc.so.6 + 0xf75a7) > #3 0x7f5062297d68 FcDirCacheWrite (libfontconfig.so.1 + 0xbd68) > #4 0x7f50622a200b FcDirCacheScan (libfontconfig.so.1 + 0x1600b) > #5 0x7f50622a2283 IA__FcDirCacheRead (libfontconfig.so.1 + 0x16283) > #6 0x7f506229c7f1 FcConfigAddDirList (libfontconfig.so.1 + 0x107f1) > #7 0x7f506229c8c4 IA__FcConfigBuildFonts (libfontconfig.so.1 + 0x108c4) > #8 0x7f50622a8d8c FcInitLoadOwnConfigAndFonts (libfontconfig.so.1 + 0x1cd8c) > #9 0x7f5062298f26 FcConfigEnsure (libfontconfig.so.1 + 0xcf26) > #10 0x7f5062298f8d FcConfigInit (libfontconfig.so.1 + 0xcf8d) > #11 0x7f50573a3415 init_in_thread (libpangoft2-1.0.so.0 + 0xc415) > #12 0x7f50638ffab1 g_thread_proxy (libglib-2.0.so.0 + 0x87ab1) > #13 0x7f506332845c start_thread (libc.so.6 + 0x8845c) > #14 0x7f50633a8bbc __clone3 (libc.so.6 + 0x108bbc) > > Stack trace of thread 1633280: > #0 0x7f50633a1059 syscall (libc.so.6 + 0x101059) > #1 0x7f506392dc90 g_cond_wait_until (libglib-2.0.so.0 + 0xb5c90) > #2 0x7f506389c
Bug#1066898: tracker-extract: always crash - related to sandboxing making chmod from fontconfig to always fail
Package: tracker-extract Version: 3.7~rc-3 Severity: grave Justification: renders package unusable Dear Maintainer, * What led up to the situation? I believe upgrading to Sid from Trixie a few days ago. mars 15 06:10:37 hermes tracker-miner-fs-3[1633275]: Fontconfig error: Cannot load default config file: Unable to open /etc/fonts/fonts.conf mars 15 06:10:37 hermes tracker-miner-fs-3[1633275]: Disallowed syscall "chmod" caught in sandbox mars 15 06:10:37 hermes systemd[1]: Started systemd-coredump@33956-1633288-0.service - Process Core Dump (PID 1633288/UID 0). mars 15 06:10:38 hermes systemd[1]: Started drkonqi-coredump-processor@33956-1633288-0.service - Pass systemd-coredump journal entries to relevant user for potential DrKonqi handling. mars 15 06:10:38 hermes systemd-coredump[1633289]: Removed old coredump core.tracker-extract.1000.4370b7ec7f8d4cf8998826bce50c6f8b.1553954.171047636300.zst. mars 15 06:10:38 hermes drkonqi-coredump-processor[1633290]: Entry doesn't look like a dump. This may have been a vaccum run. Nothing to process. mars 15 06:10:38 hermes systemd-coredump[1633289]: [] Process 1633275 (tracker-extract) of user 1000 dumped core. Module libsystemd.so.0 from deb systemd-255.4-1+b1.amd64 Module libudev.so.1 from deb systemd-255.4-1+b1.amd64 Module libarchive.so.13 from deb libarchive-3.7.2-1.1.amd64 Module libzstd.so.1 from deb libzstd-1.5.5+dfsg2-2.amd64 Stack trace of thread 1633287: #0 0x7f50633aa207 __tgkill (libc.so.6 + 0x10a207) #1 0x7f50632dc510 __restore_rt (libc.so.6 + 0x3c510) #2 0x7f50633975a7 __GI___chmod (libc.so.6 + 0xf75a7) #3 0x7f5062297d68 FcDirCacheWrite (libfontconfig.so.1 + 0xbd68) #4 0x7f50622a200b FcDirCacheScan (libfontconfig.so.1 + 0x1600b) #5 0x7f50622a2283 IA__FcDirCacheRead (libfontconfig.so.1 + 0x16283) #6 0x7f506229c7f1 FcConfigAddDirList (libfontconfig.so.1 + 0x107f1) #7 0x7f506229c8c4 IA__FcConfigBuildFonts (libfontconfig.so.1 + 0x108c4) #8 0x7f50622a8d8c FcInitLoadOwnConfigAndFonts (libfontconfig.so.1 + 0x1cd8c) #9 0x7f5062298f26 FcConfigEnsure (libfontconfig.so.1 + 0xcf26) #10 0x7f5062298f8d FcConfigInit (libfontconfig.so.1 + 0xcf8d) #11 0x7f50573a3415 init_in_thread (libpangoft2-1.0.so.0 + 0xc415) #12 0x7f50638ffab1 g_thread_proxy (libglib-2.0.so.0 + 0x87ab1) #13 0x7f506332845c start_thread (libc.so.6 + 0x8845c) #14 0x7f50633a8bbc __clone3 (libc.so.6 + 0x108bbc) Stack trace of thread 1633280: #0 0x7f50633a1059 syscall (libc.so.6 + 0x101059) #1 0x7f506392dc90 g_cond_wait_until (libglib-2.0.so.0 + 0xb5c90) #2 0x7f506389c143 g_async_queue_pop_intern_unlocked (libglib-2.0.so.0 + 0x24143) #3 0x7f50639004ba g_thread_pool_wait_for_new_task (libglib-2.0.so.0 + 0x884ba) #4 0x7f50638ffab1 g_thread_proxy (libglib-2.0.so.0 + 0x87ab1) #5 0x7f506332845c start_thread (libc.so.6 + 0x8845c) #6 0x7f50633a8bbc __clone3 (libc.so.6 + 0x108bbc) Stack trace of thread 1633275: #0 0x7f50639db4a5 elf_get_dynamic_info (ld-linux-x86-64.so.2 + 0x74a5) #1 0x7f50639dc4e5 _dl_map_object (ld-linux-x86-64.so.2 + 0x84e5) #2 0x7f50639d66d1 openaux (ld-linux-x86-64.so.2 + 0x26d1) #3 0x7f50639d5489 __GI__dl_catch_exception (ld-linux-x86-64.so.2 + 0x1489)
Bug#1035749: related bug
On Mon, 8 May 2023 10:18:48 -0700 Carter Smithhart wrote: > https://gitlab.gnome.org/GNOME/mutter/-/issues/2723 another related or > possible dup upstream bug https://gitlab.gnome.org/GNOME/mutter/-/issues/2723 "Crash when dragging something from a XWayland window over a Wayland one" last fix was merged upstream in https://gitlab.gnome.org/GNOME/mutter/-/commit/a86900091de30715da5f2f3181cb5314358e8e13 "wayland: Set compositor when creating MetaWaylandDataSourceXWayland" ie mutter 44.1. This confirms your finding that it should be fixed in mutter 44.1 (in case this was the same bug). I don't know if this bug is present in Debian stable 43.9-0+deb12u1 but it should not be in Debian testing 44.9-1. If you have muttrer above 44.1 in ubuntu can you confirm your issue was fixed, in case your bug is another issue? If it is fixed in 44.1 and not present in 43.9 then the issue is fixed in Debian and this bug report should be closed (even if Ubuntu does not yet ship >= 44.1 as then the issue remains solely on the Ubuntu side). Could you close this report if the issue is not present in the mutter releases shjipped by Debian? Cheers, Alban
Bug#596107: mutter: "Move to another workspace" submenu is not working
TO me this bug is long gone. This bug report should be closed. On Wed, 08 Sep 2010 13:30:11 -0400 Eric Cooper wrote: > Package: mutter > Version: 2.29.0-3 > Severity: normal > > I just replaced metacity with mutter on my system. In the window ops > menu, the submenu for "Move to another workspace" pops up (with the > current workspace grayed out) but doesn't react to the mouse -- > none of the entries highlight or react to mouse clicks. > > However, the submenu *does* respond to up and down arrow keys, and > typing enter selects an entry the way a mouse click should. I am using mutter 45.3-2, so one should check if stable 43.9-0+deb12u1 or oldstable 3.38.6-1~deb11u1 is also fixed in this regards. But the "Move to another workspace" submenu is gone in mutter 45. I have a "move to wokspace left" and "Move to workspace right" Seems to have been reported upstream https://bugzilla.gnome.org/show_bug.cgi?id=597763 " Bug 597763 - With >2 workspaces, Window menu "Move to Another Workspace" menu doesn't work" the fix was pushed to upstream master https://gitlab.gnome.org/GNOME/mutter/-/commit/e590cd2 " Don't screw up the event mask when "managing" our own windows " ie first in mutter tag 2.91.0. Could you close the bug report? Cheers, Alban
Bug#812512: [Pkg-utopia-maintainers] Bug#812512: pkexec tty hijacking via TIOCSTI ioctl
On Sun, 13 Jun 2021 17:10:59 -0700 argv minus one wrote: > On Sun, Jun 13, 2021, 6:14 AM Michael Biebl wrote: > > > Hm, I'm not seeing a patch there. Do you maybe have link to this kernel > > patch? > > > > No, sorry. The existence of such a patch is implied by [1], and there was > an unsuccessful attempt to merge such a patch into upstream Linux [2], but > that's all I know about it. > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1299955#c1 > [2] https://lore.kernel.org/patchwork/patch/793178/ > > > Seems like this was merged in a form in stable by commit 83efeeeb3d04b22aaed1df99bc70a48fe9d22c4d "tty: Allow TIOCSTI to be disabled" (which disable it completely AFAIK) 2022-11-03 (first in v6.2-rc1, not in linux-6.1.y, included in linux-6.3.y, included in linux-6.4.y, included in linux-6.5.y) and fixed up by commit 690c8b804ad2eafbd35da5d3c95ad325ca7d5061 "TIOCSTI: always enable for CAP_SYS_ADMIN" 2023-07-20 which keep it always on for CAP_SYS_ADMIN (to fix braille via brltty) (first in v6.5-rc4, not in linux-6.3.y, included in linux-6.4.y, included in linux-6.5.y). Maybe this "disable flag" could be turned on in the Debian kernel? Still from https://lore.kernel.org/lkml/2ab8580e-bf8e-21bd-6bfa-33e5fa824...@nmatt.com/ it looks like this should not be necessary : " any TIOCSTI protection doesn't matter if the program correctly allocates a tty/pty pair. This protections seeks to protect users from programs that don't do things correctly." Also this looks like a policykit upstream issue. Do policykit devs really told that their employer kernel had this feature disabled so they would not work on fixing this CVE? Scary. Maybe asking Alan Cox for help designing a proper fix for policykit would be better... from his comment no program ought to requires disabling this feature. Regards, Alban
Bug#1058590: getent in polkitd.postinst is broken
> On Wed, 13 Dec 2023 at 13:59:03 +0100, Harald Dunkel wrote: > > Problem with polkitd.postinst: > > > > "getent passwd polkitd" can fail, even though polkitd can be found > > in /etc/passwd. > > In what situation does this fail? On Thu, 14 Dec 2023 11:38:16 +0100 Harald Dunkel wrote: > Hi Simon, > > getent queries all databases, as listed in /etc/nsswitch.conf, AFAIU. > I would suggest to use > > getent -s files passwd polkitd > Sorry I do not understand hw this explain in what situatoin `getent passwd polkitd` fails when polkitd user is in /etc/passwd. Could you be more specific? > to query /etc/passwd only and to ignore remote databases based on LDAP > or NIS or similar. polkitd is supposed to be a local system user. > > I stumbled over this during the upgrade Debian 11 --> 12 in a chroot. > Somehow polkitd couldn't be installed because the polkitd user and group > were missing. Actually I am not sure how this happened, but after > manually adding local user and group entries for polkitd installation > succeeded. > If it works in a chroot after adding the polkitd user to /etc/passwd this might be another issue (ie one where polkitd is not in /etc/passwd ). Could you confirm? Could it be that polkitd user was missing from /etc/passwd in the first place and the `getent` code was OK? So the issue would be why polkitd ended up missing in /etc/passwd. I do not see how other NSS databases could relate to this issue. If polkitd was in /etc/passwd, with or without other NSS DBs "getent passwd polkitd" should work>. Does `getent -s files passwd polkitd` really worked while `getent passwd polkitd` did not? Regards, Alban
Bug#1061599: gnome-online-accounts: cannot login to Nextcloud 26.0.7 since 3.49.0-1 - http 405 method not allowed
On Wed, 21 Feb 2024 01:43:11 +0100 Alban Browaeys wrote: > Note that 3.49.1 also includes a migration to GTK4 and API changes > which would breaks gnome-control-center 45 "Bump soname?" > https://gitlab.gnome.org/GNOME/gnome-online-accounts/-/issues/291 > Though we have gnome-control-center 46~alpha-2 in trixie and 46~beta- 1 > in sid, I don't know which gnome-control-center 46 release was ported > to this API (as I have 1:46~alpha-2 currently I believe it is not > ported yet as it works with gnome-online-accounts 3.49.0). > gnome-control-center 46~beta-1 is supposed to already be ported to the new gnome-online-accounts gtk4 API, from " online-accounts: port to new API" https://gitlab.gnome.org/GNOME/gnome-control-center/-/commit/80fcc8c2f26f7561538418fc5d72e18ecbbe512b so I believe that in sid gnome-control-center 46~beta-1, managing accounts from gnome-online-accounts should already broken. But installing this sid version, I can still show all accounts details with gnome-online-accounts 3.49.0. I can also remove and adda kerberos account. Cheers, Alban
Bug#1061599: gnome-online-accounts: cannot login to Nextcloud 26.0.7 since 3.49.0-1 - http 405 method not allowed
The 405 status was locally and manually fixed by applying the "webdav migration" implemented upstream in merge request 146. That is in ~/.config/goa-1.0/accounts.conf for my owncloud provider, add "remote.php/webdav" to the "https://nextcloud.domain/; in the "Uri" key. I also create CalDavUri and CardDavUri from the "Uri" key but appending "remote.php/dav" to them instead of "remote.php/webdav". I got the clue from the issue "critical when testing new WebDav support on existing nextcloud account: g_uri_peek_scheme: assertion 'uri != NULL' failed" https://gitlab.gnome.org/GNOME/gnome-online-accounts/-/issues/276 ). The fix: "goabackend: migrate existing WebDAV accounts"https://gitlab.gnome.org/GNOME/gnome-online-accounts/-/merge_requests/146 It is merged in 3.49.1 (while Debian is 3.49.0). Note that 3.49.1 also includes a migration to GTK4 and API changes which would breaks gnome-control-center 45 "Bump soname?" https://gitlab.gnome.org/GNOME/gnome-online-accounts/-/issues/291 Though we have gnome-control-center 46~alpha-2 in trixie and 46~beta-1 in sid, I don't know which gnome-control-center 46 release was ported to this API (as I have 1:46~alpha-2 currently I believe it is not ported yet as it works with gnome-online-accounts 3.49.0). Might be the best way for now is to port the merge request 146 to 3.49.0 in Debian trixie. The API breakage in gnome-control-center was done in "goabackend: port to GTK4" https://gitlab.gnome.org/GNOME/gnome-online-accounts/-/merge_requests/142 which is merged into 3.49.1. Cheers, Alban On Sat, 27 Jan 2024 08:11:10 +0100 Alban Browaeys wrote: > Package: gnome-online-accounts > Version: 3.49.0-1 > Severity: important > > > I upgrade gnome-online-accounts from 3.48.0-2 to 3.49.0-1, I still had > Nextcloud ok in gnome-control-center (Settings) 1:46~alpha-2. > Then on one box I rebooted, then I got "Credential have expired" for > Nextcloud in Settings. Trying to authenticate anew gave me "Error > connecting to WebDAV server: Authentication failed". > > I then tried on the other box, which still had nextcloud login ok, where > I also upgraded gnome-control-center but did not yet restart it, to > kill goa-daemon and restart it. Then I ended up with the same error as > wiht the box I rebooted. > > Settings output is: > janv. 27 07:59:10 hermes org.gnome.Settings.desktop[131923]: GLib- GIO: GSocketClient: Starting new address enumeration > janv. 27 07:59:10 hermes org.gnome.Settings.desktop[131923]: GLib- GIO: lookup_by_name_with_flags_async: starting new lookup for cloud.prahal.homelinux.net with GTask 0x5581b3e13eb0, LookupData 0x5581b3ce9500 > janv. 27 07:59:10 hermes org.gnome.Settings.desktop[131923]: GLib- GIO: lookup_by_name_with_flags_async: starting new lookup for cloud.prahal.homelinux.net with GTask 0x5581b3d76160, LookupData 0x5581b3d1c5b0 > janv. 27 07:59:10 hermes org.gnome.Settings.desktop[131923]: GLib- GIO: GSocketClient: Address enumeration succeeded > janv. 27 07:59:10 hermes org.gnome.Settings.desktop[131923]: GLib- GIO: GSocketClient: Starting TCP connection attempt > janv. 27 07:59:10 hermes org.gnome.Settings.desktop[131923]: GLib- GIO: GSocketClient: TCP connection successful > janv. 27 07:59:10 hermes org.gnome.Settings.desktop[131923]: GLib- GIO: GSocketClient: Starting application layer connection > janv. 27 07:59:10 hermes org.gnome.Settings.desktop[131923]: GLib- GIO: GSocketClient: Connection successful! > janv. 27 07:59:10 hermes org.gnome.Settings.desktop[131923]: GoaBackend: goa_dav_client_check(): response (0x5581b422b970, 405) > > Note the 405 status. > Could it be my old Nextcloud version does not support a method call from > goa 0.49.0? >
Bug#1061599: gnome-online-accounts: cannot login to Nextcloud 26.0.7 since 3.49.0-1 - http 405 method not allowed
Package: gnome-online-accounts Version: 3.49.0-1 Severity: important I upgrade gnome-online-accounts from 3.48.0-2 to 3.49.0-1, I still had Nextcloud ok in gnome-control-center (Settings) 1:46~alpha-2. Then on one box I rebooted, then I got "Credential have expired" for Nextcloud in Settings. Trying to authenticate anew gave me "Error connecting to WebDAV server: Authentication failed". I then tried on the other box, which still had nextcloud login ok, where I also upgraded gnome-control-center but did not yet restart it, to kill goa-daemon and restart it. Then I ended up with the same error as wiht the box I rebooted. Settings output is: janv. 27 07:59:10 hermes org.gnome.Settings.desktop[131923]: GLib-GIO: GSocketClient: Starting new address enumeration janv. 27 07:59:10 hermes org.gnome.Settings.desktop[131923]: GLib-GIO: lookup_by_name_with_flags_async: starting new lookup for cloud.prahal.homelinux.net with GTask 0x5581b3e13eb0, LookupData 0x5581b3ce9500 janv. 27 07:59:10 hermes org.gnome.Settings.desktop[131923]: GLib-GIO: lookup_by_name_with_flags_async: starting new lookup for cloud.prahal.homelinux.net with GTask 0x5581b3d76160, LookupData 0x5581b3d1c5b0 janv. 27 07:59:10 hermes org.gnome.Settings.desktop[131923]: GLib-GIO: GSocketClient: Address enumeration succeeded janv. 27 07:59:10 hermes org.gnome.Settings.desktop[131923]: GLib-GIO: GSocketClient: Starting TCP connection attempt janv. 27 07:59:10 hermes org.gnome.Settings.desktop[131923]: GLib-GIO: GSocketClient: TCP connection successful janv. 27 07:59:10 hermes org.gnome.Settings.desktop[131923]: GLib-GIO: GSocketClient: Starting application layer connection janv. 27 07:59:10 hermes org.gnome.Settings.desktop[131923]: GLib-GIO: GSocketClient: Connection successful! janv. 27 07:59:10 hermes org.gnome.Settings.desktop[131923]: GoaBackend: goa_dav_client_check(): response (0x5581b422b970, 405) Note the 405 status. Could it be my old Nextcloud version does not support a method call from goa 0.49.0? PS: I will probably open a bug report against upstream has I believe this issue not to be Debian related. Though I wanted to raise your awareness of the issue (which might not affect all Nextcloud instances), even though this gnome-online-account update already hit testing. Best Regards, Alban I also see that in G_MESSAGES_DEBUG=all /usr/libexec/goa-daemon --replace output: (goa-daemon:128630): goa-daemon-DEBUG: 08:00:12.384: 83448041499: Received EnsureCredentials (owncloud, account_1674792379_0) (goa-daemon:128630): goa-daemon-DEBUG: 08:00:12.384: 83448041568: Handling EnsureCredentials (owncloud, account_1674792379_0) (goa-daemon:128630): GoaBackend-DEBUG: 08:00:12.386: Retrieved keyring credentials for id: account_1674792379_0 (goa-daemon:128630): GLib-GIO-DEBUG: 08:00:12.386: GSocketClient: Starting new address enumeration (goa-daemon:128630): GLib-GIO-DEBUG: 08:00:12.386: lookup_by_name_with_flags_async: starting new lookup for cloud.prahal.homelinux.net with GTask 0x7f6324c4d6f0, LookupData 0x7f6324c4d6a0 (goa-daemon:128630): GLib-GIO-DEBUG: 08:00:12.386: lookup_by_name_with_flags_async: starting new lookup for cloud.prahal.homelinux.net with GTask 0x7f6324c63320, LookupData 0x7f6324c632d0 (goa-daemon:128630): GLib-GIO-DEBUG: 08:00:12.388: GSocketClient: Address enumeration succeeded (goa-daemon:128630): GLib-GIO-DEBUG: 08:00:12.388: GSocketClient: Starting TCP connection attempt (goa-daemon:128630): GLib-GIO-DEBUG: 08:00:12.388: GSocketClient: TCP connection successful (goa-daemon:128630): GLib-GIO-DEBUG: 08:00:12.388: GSocketClient: Starting application layer connection (goa-daemon:128630): GLib-GIO-DEBUG: 08:00:12.388: GSocketClient: Connection successful! (goa-daemon:128630): libsoup-http2-DEBUG: 08:00:12.423: [CLIENT] [C1-S0] [-] [SEND] [SETTINGS] stream_id=0 (goa-daemon:128630): libsoup-http2-DEBUG: 08:00:12.423: [CLIENT] [C1-S0] [-] [SEND] [WINDOW_UPDATE] stream_id=0 (goa-daemon:128630): libsoup-http2-DEBUG: 08:00:12.423: [CLIENT] [C1-S1] [NONE] [SESSION] Request made for cloud.prahal.homelinux.net/ (goa-daemon:128630): libsoup-http2-DEBUG: 08:00:12.423: [CLIENT] [C1-S1] [NONE] [SESSION] State NONE -> WRITE_HEADERS (goa-daemon:128630): libsoup-http2-DEBUG: 08:00:12.423: [CLIENT] [C1-S1] [WRITE_HEADERS] [SEND] [HEADERS] stream_id=1, category=REQUEST finished=1 (goa-daemon:128630): libsoup-http2-DEBUG: 08:00:12.423: [CLIENT] [C1-S1] [WRITE_HEADERS] [SESSION] State WRITE_HEADERS -> WRITE_DONE (goa-daemon:128630): GoaBackend-DEBUG: 08:00:12.423: > OPTIONS / HTTP/2 (goa-daemon:128630): GoaBackend-DEBUG: 08:00:12.423: > Soup-Debug-Timestamp: 1706338812 (goa-daemon:128630): GoaBackend-DEBUG: 08:00:12.423: > Soup-Debug: SoupSession 1 (0x7f63249e4930), SoupMessage 1 (0x7f63246cd830), GSocket 1 (0x7f6324b3f300) (goa-daemon:128630): GoaBackend-DEBUG: 08:00:12.423: > Accept-Encoding: gzip, deflate, br (goa-daemon:128630): GoaBackend-DEBUG: 08:00:12.423: > User-Agent: gnome-online-accounts/3.49.0
Bug#1059729: mutter: gnome-shell restart x11 session fails with window
Package: mutter
Version: 45.2-2.1
Severity: normal
restarting gnome-shell x11 when a window is opened fails with:
"another compositing window manager is already running on screen"
Regression in restaring an x11 session
https://gitlab.gnome.org/GNOME/mutter/-/issues/2873
The merge request https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3329
fixes this cras (though as I told in
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3329#note_1948823
Though I believe the initial code change that introduced this bug should be
fixed too, code change in
https://gitlab.gnome.org/GNOME/mutter/-/commit/761a254e6f8b8643ce6530e85daf041f25edc683
which moved the window redirection in a X11_DISPLAY_OPENED signal handler
(signal that is emitted mulitple times including the one that bug on me, that
is after plugin init).
Though it could be this is already handled by the move of:
meta_x11_display_redirect_windows
from the meta-x11-display.c on_x11_display_opened to the
on_x11_display_setup, leaving only meta_x11_display_redirect_windows
in the X11_DISPLAY_OPENED handler introduced in commit 761a254e.
Maybe leaving this call late after the plugin init is fine.
I attach the MR I applied to test that this MR indeed fixes the restart
issue.
Cheers,
Alban
-- System Information:
Debian Release: trixie/sid
APT prefers testing-debug
APT policy: (500, 'testing-debug'), (500, 'stable-debug'), (500,
'oldstable-debug'), (500, 'testing'), (500, 'stable'), (90, 'unstable-debug'),
(90, 'unstable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.7.0-rc5+ (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 mutter depends on:
ii adwaita-icon-theme45.0-2
ii gnome-settings-daemon-common 45.0-1
ii gsettings-desktop-schemas 45.0-2
ii libc6 2.37-12
ii libgles2 1.7.0-1
ii libglib2.0-0 2.78.3-1
ii libmutter-13-045.2-2.1
ii libwayland-client01.22.0-2.1
ii mutter-common 45.2-2.1
ii zenity4.0.0-1
mutter recommends no packages.
Versions of packages mutter suggests:
ii gnome-control-center 1:45.2-1
ii xdg-user-dirs 0.18-1
-- no debconf information
>From b7a1159a1ecd08b5e6aa1279fea84accf846b411 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jonas=20=C3=85dahl?=
Date: Fri, 20 Oct 2023 15:44:29 +0800
Subject: [PATCH 1/4] x11-display: Make subwindow redirection call mode
specific
This means that for X11 sessions we'll do it before any windows are
mapped, and before any plugin implementation is started. Doing it before
a plugin is started is important, because things that the plugin does
during startup can have consequences on how compositing on Xorg works.
For the Xwayland case, we'll do it relatively in the setup phase. It
appears to have been harmless to do it later in the post-opened signal,
but there is no harm in doing it as one of the earlier steps.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3089
---
src/compositor/meta-compositor-x11.c | 2 ++
src/wayland/meta-xwayland.c | 1 +
src/x11/meta-x11-display.c | 1 -
3 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/compositor/meta-compositor-x11.c
b/src/compositor/meta-compositor-x11.c
index 1ad3327ddf6..ce7bc1945ce 100644
--- a/src/compositor/meta-compositor-x11.c
+++ b/src/compositor/meta-compositor-x11.c
@@ -188,6 +188,8 @@ meta_compositor_x11_manage (MetaCompositor *compositor,
compositor_x11->have_x11_sync_object = meta_sync_ring_init (xdisplay);
+ meta_x11_display_redirect_windows (x11_display, display);
+
return TRUE;
}
diff --git a/src/wayland/meta-xwayland.c b/src/wayland/meta-xwayland.c
index e95ca564010..83f2fcb25d9 100644
--- a/src/wayland/meta-xwayland.c
+++ b/src/wayland/meta-xwayland.c
@@ -1170,6 +1170,7 @@ on_x11_display_setup (MetaDisplay *display,
{
MetaX11Display *x11_display = meta_display_get_x11_display (display);
+ meta_x11_display_redirect_windows (x11_display, display);
meta_xwayland_init_dnd (x11_display);
meta_xwayland_init_xrandr (manager, x11_display);
}
diff --git a/src/x11/meta-x11-display.c b/src/x11/meta-x11-display.c
index 4e98203dd25..c634a71fb2a 100644
--- a/src/x11/meta-x11-display.c
+++ b/src/x11/meta-x11-display.c
@@ -301,7 +301,6 @@ on_x11_display_opened (MetaX11Display *x11_display,
MetaDisplay*display)
{
meta_display_manage_all_xwindows (display);
- meta_x11_display_redirect_windows (x11_display, display);
}
static void
--
GitLab
>From 77fc07943c3171a5e7a047ca34af46feeca347c2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jonas=20=C3=85dahl?=
Date: Fri, 20 Oct 2023 17:03:31 +0800
Subject: [PATCH
Bug#1057362: lives: depends on libavutil56 which is not available in stable or unstable anymore
Package: lives Version: 3.0.2-1.2 Severity: grave Justification: renders package unusable Dear Maintainer, I cannot install lives on a bookworm system as it depends on libvutil56 which is not anymore in Debian stable or unstable repositories. Cheers, Alban -- System Information: Debian Release: trixie/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'stable-debug'), (500, 'oldstable-debug'), (500, 'oldoldstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (90, 'unstable-debug'), (90, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.7.0-rc2+ (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 lives depends on: ii imagemagick 8:6.9.12.98+dfsg1-4 ii imagemagick-6.q16 [imagemagick] 8:6.9.12.98+dfsg1-4 ii libasound21.2.10-1 ii libatk1.0-0 2.50.0-1 ii libavc1394-0 0.5.4-5 ii libavutil56 7:4.3.6-0+deb11u1 ii libc6 2.37-12 ii libcairo-gobject2 1.18.0-1 ii libcairo2 1.18.0-1 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-3 ii libgdk-pixbuf2.0-02.40.2-3 ii libglib2.0-0 2.78.1-4 ii libgtk-3-03.24.38-6 ii libjack-jackd2-0 [libjack-0.125] 1.9.21~dfsg-3 ii libmjpegutils-2.1-0 1:2.1.0+debian-8 ii libpango-1.0-01.51.0+ds-3 ii libpangocairo-1.0-0 1.51.0+ds-3 ii libpng16-16 1.6.40-2 ii libpulse0 16.1+dfsg1-2+b1 ii libraw1394-11 2.1.2-2 ii libswscale5 7:4.3.6-0+deb11u1 pn libunicap2 pn libweed0 ii libx11-6 2:1.8.7-1 pn lives-data pn lives-plugins ii mplayer 2:1.5+svn38423-2+b1 ii mpv 0.36.0-1+b1 pn ogmtools ii perl 5.36.0-10 ii procps2:4.0.4-2 ii sox 14.4.2+git20190427-4 ii zlib1g1:1.2.13.dfsg-3 Versions of packages lives recommends: ii dvgrab 3.5+git20160707.1.e46042e-1+b1 ii ffmpeg 7:6.1-3 ii frei0r-plugins 1.8.0-1+b1 pn icedax pn libtheora-bin ii mencoder2:1.5+svn38423-2+b1 ii mkvtoolnix 80.0-1 pn pulseaudio ii x11-utils 7.7+6 pn youtube-dl Versions of packages lives suggests: pn libdv-bin pn mjpegtools
Bug#1053979: chkrootkit: ignore or lower to info for files owned by installed debian packages and unchanged
Package: chkrootkit
Version: 0.57-2+b1
Severity: wishlist
Dear Maintainer,
when chkrootkit-daily runs (was with old /etc/ckrootkit.conf thus diff mode
false and "-q -n" flags) I get reports for files owned by Debian
packages and that are iso with their installation state:
WARNING: The following suspicious files and directories were found:
/usr/lib/debug/.build-id
/usr/lib/jvm/.java-1.17.0-openjdk-amd64.jinfo
/usr/lib/jvm/.java-1.11.0-openjdk-amd64.jinfo
/usr/lib/python3/dist-packages/fail2ban/tests/files/config/apache-auth/basic/authz_owner/.htaccess
/usr/lib/python3/dist-packages/fail2ban/tests/files/config/apache-auth/basic/authz_owner/.htpasswd
/usr/lib/python3/dist-packages/fail2ban/tests/files/config/apache-auth/basic/file/.htaccess
/usr/lib/python3/dist-packages/fail2ban/tests/files/config/apache-auth/basic/file/.htpasswd
/usr/lib/python3/dist-packages/fail2ban/tests/files/config/apache-auth/digest/.htaccess
/usr/lib/python3/dist-packages/fail2ban/tests/files/config/apache-auth/digest/.htpasswd
/usr/lib/python3/dist-packages/fail2ban/tests/files/config/apache-auth/digest_anon/.htaccess
/usr/lib/python3/dist-packages/fail2ban/tests/files/config/apache-auth/digest_anon/.htpasswd
/usr/lib/python3/dist-packages/fail2ban/tests/files/config/apache-auth/digest_time/.htaccess
/usr/lib/python3/dist-packages/fail2ban/tests/files/config/apache-auth/digest_time/.htpasswd
/usr/lib/python3/dist-packages/fail2ban/tests/files/config/apache-auth/digest_wrongrelm/.htaccess
/usr/lib/python3/dist-packages/fail2ban/tests/files/config/apache-auth/digest_wrongrelm/.htpasswd
/usr/lib/python3/dist-packages/fail2ban/tests/files/config/apache-auth/noentry/.htaccess
/usr/lib/python3/dist-packages/glances/outputs/static/.prettierrc.js
/usr/lib/python3/dist-packages/matplotlib/backends/web_backend/.eslintrc.js
/usr/lib/python3/dist-packages/matplotlib/backends/web_backend/.prettierignore
/usr/lib/python3/dist-packages/matplotlib/backends/web_backend/.prettierrc
/usr/lib/python3/dist-packages/matplotlib/tests/baseline_images/.keep
/usr/lib/python3/dist-packages/matplotlib/tests/tinypages/_static/.gitignore
/usr/lib/python3/dist-packages/matplotlib/tests/tinypages/.gitignore
/usr/lib/python3/dist-packages/numpy/core/include/numpy/.doxyfile
/usr/lib/python3/dist-packages/numpy/f2py/tests/src/assumed_shape/.f2py_f2cmap
/usr/lib/python3/dist-packages/numpy/f2py/tests/src/f2cmap/.f2py_f2cmap
/usr/lib/ruby/gems/3.1.0/gems/typeprof-0.21.2/vscode/.vscode
/usr/lib/ruby/gems/3.1.0/gems/typeprof-0.21.2/vscode/.gitignore
/usr/lib/ruby/gems/3.1.0/gems/typeprof-0.21.2/vscode/.vscodeignore
/usr/lib/ruby/vendor_ruby/rubygems/ssl_certs/.document
/usr/lib/ruby/vendor_ruby/rubygems/optparse/.document
/usr/lib/ruby/vendor_ruby/rubygems/tsort/.document
Could chkrootkit check these files are owned by an installed Debian
package and unmodified and at least lower the status from WARNING to
INFO in the logged output (maybe we do not want them ignored altogether
in the case where a Debian package could be compromised and ship the
dangerous file?)
(ala "dpkg --search /usr/lib/ruby/vendor_ruby/rubygems/tsort/.document")
and that this file is unchanged from its Debian package state (against
/var/lib/dpkg/info/.md5sums)?
I cooked such a script:
for file in $(grep /usr/lib /var/log/chkrootkit/log.today); do for pkg in $(set
-o pipefail; dpkg -S $file 2>/dev/null | sed 's/: .*//' | tr ',' '\n'); do
for md5pkgfile in $(ls /var/lib/dpkg/info/$pkg.md5sums 2> /dev/null); do [ -f
"$file" ] && grep ${file:1} $md5pkgfile | ( read -r md5filepkg filepkgpath;
md5file="$(md5sum "/$filepkgpath" | cut -d' ' -f1)"; [ "x$md5filepkg" =
"x$md5file" ] && echo "Debian unmodified $file" || echo "non Debian or modified
$file"); done; done ;done
gives:
Debian unmodified /usr/lib/jvm/.java-1.17.0-openjdk-amd64.jinfo
(...)
It does not handles directories like /usr/lib/debug/.build-id. Maybe
chkrootkit could check none of the files in such a dot directory are
non Debian packages installed files unmodified and owned by still
installed packages?
Cheers,
Alban
-- System Information:
Debian Release: 12.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable-debug'), (500, 'oldstable-debug'), (500, 'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.1.0-13-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 chkrootkit depends on:
ii libc6 2.36-9+deb12u3
Versions of packages chkrootkit recommends:
ii binutils2.40-2
ii bsd-mailx [mailx] 8.1.2-0.20220412cvs-1
ii cron [cron-daemon] 3.0pl1-162
ii iproute26.1.0-3
ii mailutils [mailx] 1:3.15-4
ii net-tools 2.10-0.1
ii
Bug#1053538: kexec-tools: kexec reboot even if "systemctl reboot" via initscripts - Debian stable and testing
LOAD_KEXEC=true note that this is from a copy of the file I made yesterday, since then I upgrade to the unstable kexec-tools. I can confirm that this bug is not there with the unstable version 1:2.0.27-1 (as the initscripts are no more this was expected). debconf entry: * kexec-tools/load_kexec: true Cheers, Alban Le vendredi 06 octobre 2023 à 10:01 -0600, Khalid Aziz a écrit : > On 10/5/23 3:05 PM, Alban Browaeys wrote: > > Package: kexec-tools > > Version: 1:2.0.25-3+b1 > > Severity: normal > > > > Dear Maintainer, > > When I call "reboot" or "systemctl reboot" I ends up with a kexec > > reboot. > > > > I expect a cold reboot. > > What is the value for LOAD_KEXEC in /etc/default/kexec? > > -- > Khalid > > > > > > > > > I have enabled kexec-tools as it is a dependency of kdump-tools. > > I supposed enabling a kexec kernel was a requirement to get kdump > > tools > > to dump to /var/crash. Maybe I misunderstood. > > > > In the journal I get after systemd telling it is rebooting: > > " > > oct. 05 21:59:59 cyclope systemd-logind[1954]: The system will > > reboot now! > > (...) > > oct. 05 21:59:59 cyclope systemd-logind[1954]: System is rebooting. > > (...) > > oct. 05 22:00:00 cyclope systemd[1]: Stopping kexec-load.service - > > LSB: Load kernel image with kexec... > > (...) > > oct. 05 22:00:02 cyclope kexec-load[6144]: Loading new kernel image > > into memory...done. > > oct. 05 22:00:02 cyclope systemd[1]: kexec-load.service: > > Deactivated successfully. > > oct. 05 22:00:02 cyclope systemd[1]: Stopped kexec-load.service - > > LSB: Load kernel image with kexec. > > oct. 05 22:00:02 cyclope systemd[1]: kexec-load.service: Consumed > > 1.208s CPU time. > > (...) > > oct. 05 22:00:02 cyclope systemd[1]: Stopping kexec.service - LSB: > > Execute the kexec -e command to reboot system... > > (...) > > oct. 05 22:00:02 cyclope kexec[6439]: Will now restart with kexec. > > " > > > > This even though the kexec-tools Debian REAME tells: > > /usr/share/doc/kexec-tools/README.Debian > > "reboot" command with ystemd will by default do a cold reboot. To > > kexec > > a new kernel with systemd, use "systemctl kexec". > > > > I believe this is a new issue maybe from my upgrade in June of > > kexec-tools > > from 1:2.0.20-2.1, 1:2.0.25-3+b1. > > That is I did not change my kexec-tools config and I believe > > monthes ago > > systemctl reboot gave me a cold reboot, not a kexec one. > > Note that it does not means the setup was fine beforehand as I do > > not > > have a single kdump crash file in /var/crash. > > I do not know if kexec reboot was even working with the previous > > version. Now it kexec reboots fine ... but even when I ask > > systemctl for > > a default coldreboot. > > > > I don't believe this affects unstable as kexec-tools 1:2.0.27-1 > > removed the > > initscripts that are called by systemd at reboot. > > > > Maybe this is expected behavior with systemd-sysv installed? > > > > > > Cheers, > > Alban > > > > > > -- System Information: > > Debian Release: trixie/sid > > APT prefers testing-debug > > APT policy: (500, 'testing-debug'), (500, 'stable-updates'), > > (500, 'stable-security'), (500, 'stable-debug'), (500, 'oldstable- > > debug'), (500, 'oldoldstable'), (500, 'testing'), (500, 'stable'), > > (90, 'unstable-debug'), (90, 'unstable'), (1, 'experimental- > > debug'), (1, 'experimental') > > Architecture: amd64 (x86_64) > > Foreign Architectures: i386 > > > > Kernel: Linux 6.5.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) > > Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 kexec-tools depends on: > > ii debconf [debconf-2.0] 1.5.82 > > ii dpkg 1.22.0 > > ii libc6 2.37-12 > > ii libxenmisc4.17 4.17.2-1 > > ii lsb-base 11.6 > > ii sysvinit-utils [lsb-base] 3.08-1 > > > > kexec-tools recommends no packages. > > > > kexec-tools suggests no packages. > > > > -- debconf information: > > * kexec-tools/load_kexec: true > > kexec-tools/use_grub_config: false >
Bug#1053538: kexec-tools: kexec reboot even if "systemctl reboot" via initscripts - Debian stable and testing
Package: kexec-tools Version: 1:2.0.25-3+b1 Severity: normal Dear Maintainer, When I call "reboot" or "systemctl reboot" I ends up with a kexec reboot. I expect a cold reboot. I have enabled kexec-tools as it is a dependency of kdump-tools. I supposed enabling a kexec kernel was a requirement to get kdump tools to dump to /var/crash. Maybe I misunderstood. In the journal I get after systemd telling it is rebooting: " oct. 05 21:59:59 cyclope systemd-logind[1954]: The system will reboot now! (...) oct. 05 21:59:59 cyclope systemd-logind[1954]: System is rebooting. (...) oct. 05 22:00:00 cyclope systemd[1]: Stopping kexec-load.service - LSB: Load kernel image with kexec... (...) oct. 05 22:00:02 cyclope kexec-load[6144]: Loading new kernel image into memory...done. oct. 05 22:00:02 cyclope systemd[1]: kexec-load.service: Deactivated successfully. oct. 05 22:00:02 cyclope systemd[1]: Stopped kexec-load.service - LSB: Load kernel image with kexec. oct. 05 22:00:02 cyclope systemd[1]: kexec-load.service: Consumed 1.208s CPU time. (...) oct. 05 22:00:02 cyclope systemd[1]: Stopping kexec.service - LSB: Execute the kexec -e command to reboot system... (...) oct. 05 22:00:02 cyclope kexec[6439]: Will now restart with kexec. " This even though the kexec-tools Debian REAME tells: /usr/share/doc/kexec-tools/README.Debian "reboot" command with ystemd will by default do a cold reboot. To kexec a new kernel with systemd, use "systemctl kexec". I believe this is a new issue maybe from my upgrade in June of kexec-tools from 1:2.0.20-2.1, 1:2.0.25-3+b1. That is I did not change my kexec-tools config and I believe monthes ago systemctl reboot gave me a cold reboot, not a kexec one. Note that it does not means the setup was fine beforehand as I do not have a single kdump crash file in /var/crash. I do not know if kexec reboot was even working with the previous version. Now it kexec reboots fine ... but even when I ask systemctl for a default coldreboot. I don't believe this affects unstable as kexec-tools 1:2.0.27-1 removed the initscripts that are called by systemd at reboot. Maybe this is expected behavior with systemd-sysv installed? Cheers, Alban -- System Information: Debian Release: trixie/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'oldstable-debug'), (500, 'oldoldstable'), (500, 'testing'), (500, 'stable'), (90, 'unstable-debug'), (90, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 kexec-tools depends on: ii debconf [debconf-2.0] 1.5.82 ii dpkg 1.22.0 ii libc6 2.37-12 ii libxenmisc4.17 4.17.2-1 ii lsb-base 11.6 ii sysvinit-utils [lsb-base] 3.08-1 kexec-tools recommends no packages. kexec-tools suggests no packages. -- debconf information: * kexec-tools/load_kexec: true kexec-tools/use_grub_config: false
Bug#1053306: libxapp1: xapp-sn-watcher.desktop file should be in the xapp-sn-watcher debian package
On Sun, 1 Oct 2023 13:49:56 +0200 Fabio Fantoni wrote: > Il 01/10/2023 12:33, Alban Browaeys ha scritto: > > Package: libxapp1 > > Version: 2.6.1-1 > > Severity: normal > > > > Dear Maintainer, > > I get this error in my logs: > > oct. 01 12:19:15 hermes systemd-xdg-autostart-generator[501717]: Exec binary '/usr/lib/x86_64-linux-gnu/xapps/sn-watcher/xapp-sn- watcher' does not exist: No such file or directory > > oct. 01 12:19:15 hermes systemd-xdg-autostart-generator[501717]: /etc/xdg/autostart/xapp-sn-watcher.desktop: not generating unit, error parsing Exec= line: No such file or directory > > > > it turns out I have libxapp1:amd64 2.6.1-1 installed but not xapp- sn-watcher. > > > > I believe the xapp-sn-watcher.desktop shipped by libxapp1 should be shipped by > > the xapp-sn-watcher package. > > Hi, from the version you are reporting xapp-sn-watcher.desktop is > already in xapp-sn-watcher package: > https://packages.debian.org/sid/amd64/xapp-sn-watcher/filelist > > file was moved latest time in 2.4.2-1 (from xapp package) and first time > in 2.2.6-1 (from libxapp1) > > I suppose the issue you spotted is related to old conffile moved (in > case your system was upgraded and was installed intially with version < > 2.2.6-1, where there was the first move from libxapp1), relating to it > there is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983441 but is > blocked by another bug in dpkg (that I'm unable to fix it) and as wrote > in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886389 is > impossible use rm_conffile in case of move from one binary package to > another of the same source or the file of the new package will be > removed broking it > > since the unexpected case you spotted is more that simply "mark as > obsolete" I think is good to reply on bug #886389 that now seems > considered minor and without progress > I reported to both bug reports because there is something specific to my issue. In my case the desktop file is not only marked as obsolete in the database. It is also still marked as owned by the old package libxapp1 ... weird: $ dpkg -L libxapp1 /. /usr /usr/lib /usr/lib/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu/libxapp.so.2.6.1 /usr/share /usr/share/doc /usr/share/doc/libxapp1 /usr/share/doc/libxapp1/changelog.Debian.gz /usr/share/doc/libxapp1/changelog.gz /usr/share/doc/libxapp1/copyright /usr/lib/x86_64-linux-gnu/libxapp.so.1 /etc/xdg/autostart/xapp-sn-watcher.desktop $ apt policy libxapp1 libxapp1: Installé : 2.6.1-1 Candidat : 2.6.1-1 Table de version : *** 2.6.1-1 500 90 http://ftp.debian.org/debian sid/main amd64 Packages 500 http://deb.debian.org/debian trixie/main amd64 Packages 100 /var/lib/dpkg/status 2.4
Bug#1053377: ghostscript-x: ghostscript 10.02.0~dfsg-2 does not remove ghostscript-x 10.01.2~dfsg-1 automatically
Package: ghostscript-x Version: 10.01.2~dfsg-1 Severity: normal Dear Maintainer, when I attempt an upgrade, the ghostscript upgrade from 10.01.2~dfsg-1 to 10.02.0~dfsg-2 is on hold. This is because I have ghostscript-x 10.01.2~dfsg-1 installed. Looking at the dependencies in aptitude I see that 10.02.0~dfsg-2 conflict with any "ghostscript" package != 10.01.2~dfsg-1 Also ghostscript 10.02.0~dfsg-2 does not conflict with ghostscript-x, only replaces ghostscript-x (< 10.02.0~dfsg-1). This is for unstable and testing. I bet teh aim was to get rid of the ghostscript-x transitional package. Best regards, Alban -- System Information: Debian Release: trixie/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'oldstable-debug'), (500, 'oldoldstable'), (500, 'testing'), (500, 'stable'), (90, 'unstable-debug'), (90, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.4.0-4-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_BAD_PAGE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 ghostscript-x depends on: ii ghostscript 10.01.2~dfsg-1 ghostscript-x recommends no packages. ghostscript-x suggests no packages. -- no debconf information
Bug#1053306: libxapp1: xapp-sn-watcher.desktop file should be in the xapp-sn-watcher debian package
Package: libxapp1 Version: 2.6.1-1 Severity: normal Dear Maintainer, I get this error in my logs: oct. 01 12:19:15 hermes systemd-xdg-autostart-generator[501717]: Exec binary '/usr/lib/x86_64-linux-gnu/xapps/sn-watcher/xapp-sn-watcher' does not exist: No such file or directory oct. 01 12:19:15 hermes systemd-xdg-autostart-generator[501717]: /etc/xdg/autostart/xapp-sn-watcher.desktop: not generating unit, error parsing Exec= line: No such file or directory it turns out I have libxapp1:amd64 2.6.1-1 installed but not xapp-sn-watcher. I believe the xapp-sn-watcher.desktop shipped by libxapp1 should be shipped by the xapp-sn-watcher package. Cheers, Alban -- System Information: Debian Release: trixie/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'oldstable-debug'), (500, 'testing'), (500, 'stable'), (90, 'unstable-debug'), (90, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 libxapp1 depends on: ii libc62.37-10 ii libcairo-gobject21.17.8-3 ii libcairo21.17.8-3 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libglib2.0-0 2.78.0-2 ii libgnomekbd8 3.28.1-1 ii libgtk-3-0 3.24.38-5 ii libpango-1.0-0 1.51.0+ds-2 ii libx11-6 2:1.8.6-1 ii xapps-common 2.6.1-1 Versions of packages libxapp1 recommends: pn libxapp-gtk3-module pn xapp-sn-watcher libxapp1 suggests no packages. -- no debconf information
Bug#1014890: ITP: python3-looseversion -- Version numbering for anarchists and software realists
Thank you. I admit I lowered this packaging priority, as openmediavault did the python-looseversion and salt 3006 on their side (on https://github.com/openmediavault/packages/tree/master/pool/main/p/python-looseversion and https://github.com/openmediavault/packages/tree/master/pool/main/s/salt ). At the same time I have low level bugs on the related box and will attempt to resolve them first as the box is in a specific state where I can reproduce the bug. Cheers, Alban Le lundi 19 juin 2023 à 16:54 -0400, Yaroslav Halchenko a écrit : > Thank you Alban, > > done -- join/finish up > https://salsa.debian.org/python-team/packages/python-looseversion > please > > On Mon, 19 Jun 2023, Alban Browaeys wrote: > > > on January 4th of 2023 you retitled this RFP to ITP. > > > > ITP: python3-looseversion -- Version numbering for anarchists and > > software realists > > > Do you have an early package code or python3-looseversion to share > > (on > > debian salsa or else)? > > > I will have to create such a package otherwise as salt 3006 depends > > upon python3 looseversion (I am building it based upon the salt > > 3005 > > deb pacakging from > > openmediavault > > https://github.com/openmediavault/packages/tree/master/pool/main/s/ > > salt > > ). > > So even if you only did an early frame of it that would avoid > > duplicate > > effort.
Bug#1052299: gnome-boxes: Cannot install "GNOME OS Nightly" - secure-boot set by ovmf while gnome os efi seems not signed
Package: gnome-boxes Version: 45.0-1 Severity: normal Dear Maintainer, If I attempt to create a GNOME OS guest I end up on the edkII console. If inhte console I try to boot the EFI (in FS0: be it bootx64.efi in \EFI\BOOT or systemd-bootx64.efi in EFI\systemd) I get a "Command Error Status: Access Denied" error. I got he clue it might be secure boot related by https://forum.proxmox.com/threads/vm-always-going-into-uefi-interactive-shell.119215/ I also learned that the install was fine with the flatpak, so I compared the VM configurations for GNOME OS: Debian gome-boxes 45: hvm /usr/share/OVMF/OVMF_CODE_4M.ms.fd /home/prahal/.config/libvirt/qemu/nvram/gnomenightly_VARS.fd > Flatpak gnome-boxes 44: hvm Grepping where this secure-boot feature comes from, I ended up on: /usr/share/qemu/firmware/40-edk2-x86_64-secure-enrolled.json Scrambling the target (for example, replacing in "machines", "pc-q35-*" by "pc-q35xxx-*") in this file to avoid its settings being added to (all?) the guest VM I now can install "GNOME OS Nightly x86_64" (ie edk2 boots into the installer and the installer proceeds). This might well be an ovmf bug. Still, as I don' know if gnome-boxes or qemu have flags to avoid ovmf bringing in this secure-boot for all guest setups, I start up the stack. Cheers, Alban -- System Information: Debian Release: trixie/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'oldstable-debug'), (500, 'testing'), (500, 'stable'), (90, 'unstable-debug'), (90, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0+ (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 gnome-boxes depends on: ii dconf-gsettings-backend [gsettings-backend] 0.40.0-4 ii genisoimage 9:1.1.11-3.4 ii libarchive13 3.6.2-1 ii libc62.37-8 ii libcairo21.17.8-3 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libglib2.0-0 2.78.0-1 ii libgtk-3-0 3.24.38-5 ii libgudev-1.0-0 238-2 ii libhandy-1-0 1.8.2-2 ii libosinfo-1.0-0 1.10.0-2 ii libosinfo-bin1.10.0-2 ii libsoup-3.0-03.4.3-1 ii libspice-client-glib-2.0-8 0.42-2 ii libspice-client-gtk-3.0-50.42-2 ii libusb-1.0-0 2:1.0.26-1 ii libvirt-clients 9.7.0-1 ii libvirt-daemon 9.7.0-1 ii libvirt-glib-1.0-0 4.0.0-3 ii libwebkit2gtk-4.1-0 2.40.5-1 ii libxml2 2.9.14+dfsg-1.3 ii tracker 3.6.0-1 ii user-session-migration 0.4.1 Versions of packages gnome-boxes recommends: ii qemu-system-x86 1:8.0.4+dfsg-3+b1 Versions of packages gnome-boxes suggests: ii gnome-connections 45~rc-1 -- no debconf information
Bug#691469: postifx apprently uses mboxo format, which irrecoverably corrupts mail
notforwarded 691469 forwarded 691469 https://marc.info/?l=postfix-users=135129541824896=2 thanks Update the broken gmane link to the postfix user mailing list. TLDR; sum up status of this issue. Fix would probably be to switch to maildir as default. Still, this would require to know if any Debian mail clients relies on /var/spool/mail/ to be in the mbox format. A short term option could be to document this mboxo spurious corruption in the postfix README. All in all this is not a data corruption that renders the emails unreadeable. It merely confuses the reader by changing the quote state of line starting with ">From " if his mail client unquote the quoted From_ lines per mboxo specifications. With mboxo, the email body: >From 1 >From 2 >>From 3 becomes: >From 1 >From 2 >>From 3 A simple upgrade path exists to mboxrd >From 1 >>From 2 >>>From 3 That was deemed a mostly wontfix in 2012 at least for breaking backward compatibilty. https://marc.info/?l=postfix-users=135145804930171=2 (ie ok but an optin) Though it makes no sense to me. A program that read mboxo can also read mboxrd, the only difference is that with the mboxo the program will get an inconsistent content (well corrupted content) while with mboxrd the message could be restored to its intial state (by removoing one '>' from each line starting with any number of '>' followed by "From ". I hope the reason for this wontfix is that no analysis of the changes in behavior was made. This http://jdebp.info/FGA/mail-mbox-formats.html also conclude the same, even if it makes no sense to me: > Conversely, when an "mboxo" reader is used, less message corruption will be observed in the final results if the messages were written by an "mboxo" tool than if they were written by an "mboxrd" tool. To me if an mboxo reader cannot unquote any better than an mboxrd reader would. The difference would be for a reader that does not unescape mbox quoted "From " lines. Emails that had no lines starting with "From " but any starting with any number of '>' followed by "From " would get an extra '>'. This still would require analysis and testing, as all actors tell taht the behavior of mobox readers would change (but they do not give their sources, so the work has to be done anew even if they are right). I still do not see how mboxrd would make mboxo only readers badly behave. Though I believe this should be brought to the upstream mailing list, I am for now trying to update this bug and remove the confusion out of it. Also it was told in 2019 that postfix does not use mboxo for local transport (though it would require checking the code, the documentation is an intent not a proof of the implementation) https://marc.info/?l=postfix-users=156158209919449=2 " List: postfix-users Subject:Re: mbox format? From: Viktor Dukhovni Date: 2019-06-26 20:47:23 Message-ID: 20190626204723.GK84864 () straasha ! imrryr ! org [Download RAW message or body] On Wed, Jun 26, 2019 at 04:27:06PM -0400, Wietse Venema wrote: > Viktor Dukhovni: > > > On Wed, Jun 26, 2019 at 12:39:02PM -0700, Ronald F. Guilmette wrote: > > > > > When Postfix hands a message to something... say a script invoked via > > > some ~/.forward file... which one of these four formats will the message > > > be in? > > > > See: > > https://github.com/vdukhovni/postfix/blob/master/postfix/src/global/mail_copy.c#L235 > > > > So the answer is mboxo. > > According to 'man 8 local', section 'EXTERNAL COMMAND DELIVERY': >The local(8) daemon prepends a "From sender time_stamp" envelope header >to each message, prepends an X-Original-To: header with the recipient >address as given to Postfix, prepends an optional Delivered-To: header >with the final recipient envelope address, prepends a Return-Path: >header with the sender envelope address, and appends no empty line. Oops, sorry, my answer was about delivery by local(8) directly to a mailbox, not a command invoked via a pipe. " >From an inspection of the code the local daemon call mail_copy: https://github.com/vdukhovni/postfix/blob/0abb45ca0732fc039e0f43b66ed441d283eb2565/postfix/src/local/mailbox.c#L212 the same as pipe:https://github.com/vdukhovni/postfix/blob/e5e46ec03f77e0bf837b1ad00cba2663d74a92c3/postfix/src/global/pipe_command.c#L587 mail_copy which translate to mboxo if the MAIL_COPY_QUOTE flag is set. This flag is included in the MAIL_COPY_MBOX one. https://github.com/vdukhovni/postfix/blob/0abb45ca0732fc039e0f43b66ed441d283eb2565/postfix/src/local/mailbox.c#L188 though the pipe only has MAIL_COPY_QUOTE if the pipe '>' flag is set in the "flags=" pipe attribute. https://github.com/vdukhovni/postfix/blob/master/postfix/src/pipe/pipe.c#L913 https://www.postfix.org/pipe.8.html An alternative to mboxrd is client MIME quoted/printable for "From " lines in the body https://marc.info/?l=postfix-users=135161915820930=2 , though it does not fix all thes mboxo
Bug#1031555: new upstream version
On Wed, 7 Jun 2023 11:21:55 +0200 Elimar Riesebieter wrote: > > At https://repo.saltproject.io/#about > > is said there is a 3005.1 version of Salt. > > > > I hope that that release fixes the problems > > that prevent having salt in the next Debian release. > > salt will be dropped in testing. So there won't be any salt package > in stable. Well, salt 3005.1 depends on python3.10 which also won't > be in stable. > > I'm missing a respective statement from the salt maintainers. > > Elimar salt 3006 does support python 3.11 per https://docs.saltproject.io/salt/install-guide/en/latest/topics/salt-python-version-support.html and https://github.com/saltstack/salt/issues/64457 [FEATURE REQUEST] Add Python 3.11 to onedir packages But there are missing dependencies for salt up from 3005. salt 3005 tests require pytest-shell-utilities https://pypi.org/project/pytest-shell-utilities/ from the saltstack project https://github.com/saltstack/pytest-shell-utilities. And 3006 requires python3-looose which are not packaged in Debian at all. Cheers, Alban
Bug#1028421: salt upstream lifecycle details
On Sat, 1 Apr 2023 20:34:04 -0400 Federico Grau wrote: > Adding to this thread/bug-report per salt project and Debian packaging, salt > is unfortunately probably not a good candidate for the Debian ecosystem. > > > The salt project current (2023-04) published lifecycle only lists 1.5 years of > support for typical releases. After that their "extended life support" is > really "best-effort technical support for customers" with "No bug fixes, [or] > security fixes". > > This is clearly short of the Debian stable target support period of 3 years. > > GNOME has way less official security support a period. If Debian only shipped programs that have upstream security support for 3 years then we could as well stop shipping most of Debian. The point of Debian is to provide the security support. Cheers, Alban
Bug#1040329: postfix set-permissions is broken in bookworm and up
On Wed, 05 Jul 2023 17:55:23 -0400 Scott Kitterman wrote: > > Proposed stable update for bookworm in progress. You can follow its status in > bug #1040435. > > Scott K I tested your debdiff from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040435 bookworm2.debdiff upon the pending stable-update and it fixes "postfix set-permissions" fine on stable arm64. Cheers, Alban
Bug#1040329: postfix set-permissions is broken in bookworm and up
Package: postfix Version: 3.7.5-2 Severity: normal Dear Maintainer, Tools such has openmediavault relies on "postfix set-permissions" working. But since Debian postfix salsa commit https://salsa.debian.org/prahal/postfix-dev/-/commit/cdce604abf0284e329bc32161757319834a6cee3 postfix set-permissions is broken as the man pages and readme files listed in /etc/postfix/postfix-files do not exists (they list . while debian compress them and add the gz extension to these files. For one this files list mail.1 while only mail.1.gz exists. $ sudo postfix set-permissions postfix: Postfix is using backwards-compatible default settings postfix: See http://www.postfix.org/COMPATIBILITY_README.html for details postfix: To disable backwards compatibility use "postconf compatibility_level=3.6" and "postfix reload" chown: cannot access '/usr/share/man/man1/mailq.1': No such file or directory The above commit removed the renaming of this manpages and readme files in /etc/postfix/postfix-files to gz files. There are other changes in this commit that are unrelated to this issue. No ratioanle was given for the removal of 05_debian_manpage_differences.diff and 05_debian_readme_differences.diff out that they are deleted "at least for now". Note that postfix-pcre is also affected cat /etc/postfix/postfix-files.d/pcre.files (...) $manpage_directory/man5/pcre_table.5:f:root:-:644 while only /usr/share/man/man5/pcre_table.5.gz is available. This is also handled by the 05_debian_manpage_differences.diff Cheers, Alban -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'oldstable-debug'), (500, 'oldoldstable'), (500, 'stable'), (99, 'testing-debug'), (99, 'testing'), (90, 'unstable-debug'), (90, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-7-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 postfix depends on: ii adduser3.134 ii cpio 2.13+dfsg-7.1 ii debconf [debconf-2.0] 1.5.82 ii dpkg 1.21.22 ii e2fsprogs 1.47.0-2 ii init-system-helpers1.65.2 ii libc6 2.36-9 ii libdb5.3 5.3.28+dfsg2-1 ii libicu72 72.1-3 ii libnsl21.3.0-2 ii libsasl2-2 2.1.28+dfsg-10 ii libssl33.0.9-1 ii netbase6.4 ii ssl-cert 1.1.2 Versions of packages postfix recommends: ii ca-certificates 20230311 ii python3 3.11.2-1+b1 Versions of packages postfix suggests: ii bsd-mailx [mail-reader]8.1.2-0.20220412cvs-1 ii emacs-gtk [mail-reader]1:28.2+1-15 ii evolution [mail-reader]3.46.4-2 ii libsasl2-modules 2.1.28+dfsg-10 ii mutt [mail-reader] 2.2.9-1+b1 pn postfix-cdb pn postfix-doc pn postfix-ldap pn postfix-lmdb pn postfix-mta-sts-resolver pn postfix-mysql ii postfix-pcre 3.7.5-2 pn postfix-pgsql pn postfix-sqlite ii procmail 3.22-27 ii resolvconf 1.91+nmu1 ii s-nail [mail-reader] 14.9.24-2 ii sasl2-bin 2.1.28+dfsg-10 ii thunderbird [mail-reader] 1:102.12.0-1~deb12u1 pn ufw -- debconf information: * postfix/main_mailer_type: No configuration postfix/not_configured: postfix/recipient_delim: + postfix/compat_conversion_warning: true postfix/sqlite_warning: postfix/lmtp_retired_warning: true postfix/chattr: false postfix/relayhost: postfix/destinations: $myhostname, cyclope.prahal.homelinux.net, localhost.prahal.homelinux.net, , localhost postfix/procmail: true postfix/main_cf_conversion_warning: true postfix/kernel_version_warning: postfix/mailname: cyclope.prahal.homelinux.net postfix/tlsmgr_upgrade_warning: postfix/root_address: postfix/bad_recipient_delimiter: postfix/newaliases: false postfix/rfc1035_violation: false postfix/relay_restrictions_warning: postfix/mynetworks: 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128 postfix/dynamicmaps_conversion_warning: postfix/mailbox_limit: 0 postfix/mydomain_warning: postfix/protocols: all postfix/retry_upgrade_warning:
Bug#1014890: ITP: python3-looseversion -- Version numbering for anarchists and software realists
on January 4th of 2023 you retitled this RFP to ITP. > ITP: python3-looseversion -- Version numbering for anarchists and software realists Do you have an early package code or python3-looseversion to share (on debian salsa or else)? I will have to create such a package otherwise as salt 3006 depends upon python3 looseversion (I am building it based upon the salt 3005 deb pacakging from openmediavault https://github.com/openmediavault/packages/tree/master/pool/main/s/salt ). So even if you only did an early frame of it that would avoid duplicate effort. Cheers, Alban On Wed, 13 Jul 2022 14:54:11 -0400 Yaroslav Halchenko wrote: > Package: wnpp > Severity: wishlist > X-Debbugs-Cc: debian-pyt...@lists.debian.org > > * Package name : python3-looseversion > Version : 1.0.1 > Upstream Author : Chris Markiewicz > * URL : https://github.com/effigies/looseversion > * License : Python > Programming Lang: Python > Description : Version numbering for anarchists and software realists > > A backwards/forwards-compatible fork of distutils.version.LooseVersion, > for times when PEP-440 isn't what you need. > . > The goal of this package is to be a drop-in replacement for the original > LooseVersion. It implements an identical interface and comparison logic to > LooseVersion. The only major change is that a looseversion.LooseVersion is > comparable to a distutils.version.LooseVersion, which means tools should not > need to worry whether all dependencies that use LooseVersion have migrated. > . > If you are simply comparing versions of Python packages, consider moving > to packaging.version.Version, which follows PEP-440. LooseVersion is better > suited to interacting with heterogeneous version schemes that do not follow > PEP-440. > > This package would be useful as we plan for adding support for Python 3.12 > which would remove distutils.version.LooseVersion and some packages would need > to "adjust" somehow. In our DataLad project we likely would just go the way > of using this LooseVersion instead of coming up with some "more proper" solution. > >
Bug#1030119: Bug#1018260: openssh-server: fills the log with "deprecated reading of user environment enabled"
Only non patched issue left about pam_env user_readenv is that .pam_environment change the pam_handle environment of the later root running PAM modules from a user controlled file and not being last in the PAM loaded modules it change the environment these other modules have (inclduign any that run as root). Though I wonder if it is a security issue. I mean do these other modules even read this pam_handle environment? THe Fedora patch to turn off user_readenv by default was talking only about subsequent modules in the PAM stack only (and was maintained by the upstream developer if I understood correctly). pam_env does not directly change programs environment and only does changes to the environment associated with pam handle. Application can later retrieve pam's environment via pam_getenvlist and export changes to its environment. Other PAM modules can be affected if they use pam_getenv. also wouldn't running pam_env last in PAM session file workaround this issue if any (though at least on Debian common-password PAM modules run after the session ones) Maybe the issue is the fact that pam_env setup a separate env that could be applied to programs asynchronously. Note that the CVE tells about program not PAM module. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4708 " The pam_env module in Linux-PAM (aka pam) 1.1.2 and earlier reads the .pam_environment file in a user's home directory, which might allow local users to run programs with an unintended environment by executing a program that relies on the pam_env PAM check. " I do not see the difference between changing the environment as a user via $HOME/.profile or $HOME/.pam_environment. A few years ago, I saw no other way than $HOME/.pam_environment to set XDG_CACHE_HOME on one user session only for a Wayland session. https://help.ubuntu.com/community/EnvironmentVariables still advertise $HOME/.pam_environment usage https://wiki.archlinux.org/title/Environment_variables tells that per use system user environment variables are available systemd. Even if $HOME/.pam_environment is deprecated, I believe /etc/security/pam_env.conf or something alike only under system administrator access should provide the ability to define environmet variable for a specific user, which it does currently not allow. GDM and KDE Plasma upstreams source systemd user environment variables in wayland sessions. But what about ssh, Xorg (on Arch OK but on Debian I cannot find the /etc/X11/xinit/xinitrc.d/50-systemd-user.sh equivalent: https://wiki.archlinux.org/title/Systemd/User#DISPLAY_and_XAUTHORITY), "shell" login program (was told soon in 2017 https://in.waw.pl/~zbyszek/blog/environmentd.html, I cannot find a reference in upstream util-linux) and other wayland session manager? Maybe exporting in /etc/profile with "systemctl --user show- environment" would help? Though I agree that systemd user environment variable gracefuly cope with the need to fulfill, there might be works left for it to apply to all login sessions in Debian. Alban History: https://bugzilla.gnome.org/show_bug.cgi?id=736660 Ray Strode [halfline] 2015-08-13 16:06:54 UTC (...) q. By default this option is off as user supplied environment variables in the PAM environment could affect behavior of subsequent modules in the stack without the consent of the system administrator.(...) http://pkgs.fedoraproject.org/cgit/pam.git/tree/pam-1.1.3-nouserenv.patch (...) which is https://src.fedoraproject.org/rpms/pam/blob/f30/f/pam-1.1.3-nouserenv.patch and is now upstream since f83fb5f2 "pam_env: Change the default to not read the user .pam_environment file", ie v1.4.0 https://github.com/linux-pam/linux-pam/commit/f83fb5f2 (it was about changing the default user_readenv to 0) Comment 6 Ray Strode [halfline] 2015-08-13 16:39:49 UTC (...) perhaps it should be in pam_systemd ... maybe I think some distros already use pam_env for the package environment? yea, pam_env would be okay too, and logical perhaps if it wasn't so difficult to achieve the equivalent of FOO="$HOME/bar" with it yea it's very strange it has two different file formats one that allows that kind of thing and one that doesn't and the one which does allow it appears to lack both $HOME and $PATH sometimes well those things are set by gdm after the auth stack has run and pam_env is run as part of the auth stack well in fedora anyway so putting "session optional pam_env.so user_readenv=1 user_envfile=.config/environment" in the very bottom of the pam file would fix that issue oh i guess it wouldn't though since envfiles are the file format that doesn't support substitution hmm its parser actually doesn't care so both formats work in ~/.pam_environment oh interesting, didn't know that it's a rather weird module yea so just making it a session module instead of (or in addition to) and auth module would fix the issue i guess but if we could get systemd
Bug#1037084: bookworm: When using gdm3 to start non-GNOME wayland sessions, PATH may be set differently
GDM imports system user environment variables. This bug would likely be fixed by Debian (the systemd package?) shipping a /usr/lib/systemd/user-environment-generators/ systemd user environment generator with the default PATH Debian already set in /etc/profile. gnome-session importing /etc/profile is a temporary hack, so even for a plain Gnome session this will not work forever without this fix. Or ship an /usr/lib/environment.d/*.conf file (which itself is read by a systemd user environment generator : /usr/lib/systemd/user- environment-generators/30-systemd-environment-d-generator). Cheers, Alban On Sat, 3 Jun 2023 23:07:40 -0700 Jay wrote: > Package: release-notes > X-Debbugs-Cc: jlsan...@protonmail.com > Severity: important > > Starting non-GNOME wayland sessions through GDM leads to a user's PATH > being set to > /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin > instead of /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games > (from /etc/profile). > > Example: Starting sway or plasma-workspace-wayland through gdm and > trying to launch > lutris or gnome-chess only to find out that they won't start even > though they are > installed. It can take some time for a user to find out that the PATH > environment > variable is different. > > This is a regression in bookworm and can surprise users upgrading from bullseye. > > Possible workarounds are: Using a different display manager such as > sddm or starting > the wayland session through tty. > > I first discovered this bug after installing lutris a few months > ago[0] and filed > a few bug reports[1][2]. As bookworm is about to be released, I thought it may > be worthwhile to document this unexpected behavior in its release notes. > > 0: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028543 > 1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942131 > 2: https://gitlab.gnome.org/GNOME/gdm/-/issues/846 > >
Bug#1038150: openssh-client: Please add the openssh-client group rename from "ssh" to "_ssh" to the bookworm release notes
Package: openssh-client Version: 1:9.2p1-2 Severity: important X-Debbugs-Cc: pra...@yahoo.com I cannot login anymore via ssh. I have the openemediavault installed on this box to manage the setup and it set AllowGroups to "root ssh" in /etc/ssh/sshd_config. Thankfully I have a serial console to this ARM board and thus I can still open a terminal on this box. After the request from a user to rename the "ssh" group to free it for its own use, the "ssh" group was rename to "_ssh" in https://salsa.debian.org/ssh-team/openssh/-/commit/18da782ebe789d0cf107a550e474ba6352e68911 But other users as in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990456#35 or tools to manage Debian have come to rely on this "ssh" group. This might be a mistake. Still could you document this critical item in the bookworm release notes? Cheers, Alban -- System Information: Debian Release: 12.0 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'stable'), (500, 'oldstable'), (90, 'experimental') Architecture: arm64 (aarch64) Foreign Architectures: armhf Kernel: Linux 6.1.11-rockchip64 (SMP w/6 CPU threads; PREEMPT) Kernel taint flags: TAINT_CRAP Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to fr_FR.UTF-8), LANGUAGE=fr_FR.UTF-8 Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages openssh-client depends on: ii adduser 3.134 ii libc6 2.36-9 ii libedit2 3.1-20221030-2 ii libfido2-11.12.0-2+b1 ii libgssapi-krb5-2 1.20.1-2 ii libselinux1 3.4-1+b6 ii libssl3 3.0.9-1 ii passwd1:4.13+dfsg1-1+b1 ii zlib1g1:1.2.13.dfsg-1 Versions of packages openssh-client recommends: pn xauth Versions of packages openssh-client suggests: pn keychain pn libpam-ssh pn monkeysphere pn ssh-askpass -- no debconf information
Bug#1029210: smartmontools.service fails since bookworm
A way to avoid the smartmontools systemd service to fail is to switch the Service type from notify to forking. This after adding the "-q nodev0" flag to the /etc/default/smartmontools smart_options variable. systemctl edit smartmontools [Service] Type=forking then systemctl daemon-reload and restart samrtmontools/ Why is smartd of type notify? Does it send notification to systemd via sd_notify? Cheers, Alban On Tue, 13 Jun 2023 03:15:06 +0200 Alban Browaeys wrote: > > Even with "-q nodev0" the service ends up in a failed state (but now > with an exit status of 0/SUCCESS) > > sudo systemctl status smartmontools > × smartmontools.service - Self Monitoring and Reporting Technology (SMART) Daemon > Loaded: loaded (/lib/systemd/system/smartmontools.service; enabled; preset: enabled) > Active: failed (Result: protocol) since Tue 2023-06-13 03:07:54 CEST; 2s ago > Docs: man:smartd(8) > man:smartd.conf(5) > Process: 4072 ExecStart=/usr/sbin/smartd -n $smartd_opts (code=exited, status=0/SUCCESS) > Main PID: 4072 (code=exited, status=0/SUCCESS) > Status: "No devices to monitor" > CPU: 29ms > > juin 13 03:07:54 hercule systemd[1]: Starting smartmontools.service - Self Monitoring and Reporting Technology (SMART) Daemon... > juin 13 03:07:54 hercule smartd[4072]: smartd 7.3 2022-02-28 r5338 [aarch64-linux-6.2.0-rc3-meson64] (local build) > juin 13 03:07:54 hercule smartd[4072]: Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org > juin 13 03:07:54 hercule smartd[4072]: Opened configuration file /etc/smartd.conf > juin 13 03:07:54 hercule smartd[4072]: Drive: DEVICESCAN, implied '- a' Directive on line 21 of file /etc/smartd.conf > juin 13 03:07:54 hercule smartd[4072]: Configuration file /etc/smartd.conf was parsed, found DEVICESCAN, scanning devices > juin 13 03:07:54 hercule smartd[4072]: In the system's table of devices NO devices found to scan > juin 13 03:07:54 hercule systemd[1]: smartmontools.service: Failed with result 'protocol'. > juin 13 03:07:54 hercule smartd[4072]: Unable to monitor any SMART enabled devices. Try debug (-d) option. Exiting... > juin 13 03:07:54 hercule systemd[1]: Failed to start smartmontools.service - Self Monitoring and Reporting Technology (SMART) Daemon. > > My storage as of now is only EMMC and SD. Though at time I can have > external USB HDDs to monitor with smartd. > > Cheers, > Alban > > > On Mon, 10 Apr 2023 15:41:10 +0200 Christian Franke > wrote: > > Possible fix for the package: Add '-q nodev0' or '-q never' to > ExecStart > > in smartmontools.service. > > > > Workaround for users: Add one of these to smartd_opts in > > /etc/default/smartmontools. > > > > Option '-q nodev0' is available since smartmontools 7.3. Then smartd > > will exit with status 0 instead of 17 (default '-q nodev') if there > are > > no devices to monitor. Systemd should no longer report this as a > failed > > service. > > > > With '-q never', smartd will keep running and does nothing. This was > the > > default for '-q' in some previous versions of (only!) the Debian > > package. This Debian-specific patch was reverted later, see: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006630 > > > > Regards, > > > > Christian > > smartmontools.org > >
Bug#1029210: smartmontools.service fails since bookworm
Even with "-q nodev0" the service ends up in a failed state (but now with an exit status of 0/SUCCESS) sudo systemctl status smartmontools × smartmontools.service - Self Monitoring and Reporting Technology (SMART) Daemon Loaded: loaded (/lib/systemd/system/smartmontools.service; enabled; preset: enabled) Active: failed (Result: protocol) since Tue 2023-06-13 03:07:54 CEST; 2s ago Docs: man:smartd(8) man:smartd.conf(5) Process: 4072 ExecStart=/usr/sbin/smartd -n $smartd_opts (code=exited, status=0/SUCCESS) Main PID: 4072 (code=exited, status=0/SUCCESS) Status: "No devices to monitor" CPU: 29ms juin 13 03:07:54 hercule systemd[1]: Starting smartmontools.service - Self Monitoring and Reporting Technology (SMART) Daemon... juin 13 03:07:54 hercule smartd[4072]: smartd 7.3 2022-02-28 r5338 [aarch64-linux-6.2.0-rc3-meson64] (local build) juin 13 03:07:54 hercule smartd[4072]: Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org juin 13 03:07:54 hercule smartd[4072]: Opened configuration file /etc/smartd.conf juin 13 03:07:54 hercule smartd[4072]: Drive: DEVICESCAN, implied '-a' Directive on line 21 of file /etc/smartd.conf juin 13 03:07:54 hercule smartd[4072]: Configuration file /etc/smartd.conf was parsed, found DEVICESCAN, scanning devices juin 13 03:07:54 hercule smartd[4072]: In the system's table of devices NO devices found to scan juin 13 03:07:54 hercule systemd[1]: smartmontools.service: Failed with result 'protocol'. juin 13 03:07:54 hercule smartd[4072]: Unable to monitor any SMART enabled devices. Try debug (-d) option. Exiting... juin 13 03:07:54 hercule systemd[1]: Failed to start smartmontools.service - Self Monitoring and Reporting Technology (SMART) Daemon. My storage as of now is only EMMC and SD. Though at time I can have external USB HDDs to monitor with smartd. Cheers, Alban On Mon, 10 Apr 2023 15:41:10 +0200 Christian Franke wrote: > Possible fix for the package: Add '-q nodev0' or '-q never' to ExecStart > in smartmontools.service. > > Workaround for users: Add one of these to smartd_opts in > /etc/default/smartmontools. > > Option '-q nodev0' is available since smartmontools 7.3. Then smartd > will exit with status 0 instead of 17 (default '-q nodev') if there are > no devices to monitor. Systemd should no longer report this as a failed > service. > > With '-q never', smartd will keep running and does nothing. This was the > default for '-q' in some previous versions of (only!) the Debian > package. This Debian-specific patch was reverted later, see: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006630 > > Regards, > > Christian > smartmontools.org > > >
Bug#1005025: libdvd-pkg fails reporting that the dpkg database is locked
Note that you have to run dpkg as root. Run as normal user, dpkg cannot locak its lock file and error with error "2" (as it cannot lock its lock file). The libdvd-pkg script runs as root so if dpkg returns "2" in its script then it means another program is holding the dpkg lock file. Could you check if this bug is fixed? It looks to me that if dpkg returns error "2" on success then it had a bug. It might well have been fixed since then. Else you might have had the dpkg lock held even after dpkg complete (I don' know if this is possible). Thus dpkg itself would return error 2 because it cannot run as the its lock is held. This would also not be a bug in libdvd-pkg bug a local leftover form a crash which is not in libdvd-pkg scope to fix. Could you close this bug report if the issue is no more on your system? Cheers, Alban On Sat, 05 Feb 2022 18:58:09 +0100 Martin Strauss wrote: > Package: libdvd-pkg > Version: 1.4.2-1-1 > Severity: important > X-Debbugs-Cc: mar...@clan-strauss.de > > Dear Maintainer, > > I upgraded from debian buster to bullseye. Afterwards libdvd-pkg reported the > following error: > > libdvd-pkg: dpkg database is locked. You may need to use command "sudo dpkg- > reconfigure libdvd-pkg". > libdvd-pkg: Building and installation of package(s) [libdvdcss2 libdvdcss-dev] > postponed till after next APT operation. > > This repeats for each "apt update". I spotted the same message on two different > computers, guess more people might be affected. > The package should download libdvdcss2 build and install it, which it doesn't > because of the failed check. > > I tried the proposed "dpkg-reconfigure libdvd-pkg" which just produces the same > message. After some internet search I found the debian bug report #824093. > There someone reported that the check had been broken and provided a patch. > The patch is applied in the current version, however it seems that > the check for the lock is once again broken. > > Basiclly it boils down to the following lines in the script: > /usr/lib/libdvd-pkg/b-i_libdvdcss.sh line 20 > > dpkg -P non-existent-package 2>/dev/null > if [ "$?" -eq 2 ]; then > > It seems the with dpkg in version 1.20.9 the return code is always 2 > independent of whether a package manager like aptitude is running or not. > Same is true for "dpkg -i /dev/zero" which was the previous version. > I checked this on the command line, the return code does not reflect > the lock status. > No idea how to fix this, the returned message is translated, so no good > to use that one. Maybe there is an official way how to do it, searching the > internet didn't help there. Maybe ask the dpkg maintainer? > > -- System Information: > Debian Release: 11.2 > APT prefers stable-updates > APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, > 'stable') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.10.0-11-amd64 (SMP w/4 CPU threads) > Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (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 libdvd-pkg depends on: > ii build-essential 12.9 > ii debconf [debconf-2.0] 1.5.77 > ii debhelper 13.3.4 > ii dh-autoreconf 20 > ii wget 1.21-1+deb11u1
Bug#994081: libdvd-pkg: 1.4.3-1-1 Upgrade Results in 'apt-get check' Failure
Package: libdvd-pkg
Version: 1.4.3-1-1
Followup-For: Bug #994081
Dear Maintainer,
TL;DR: could apt-get be called with "--dry-run" a flag when we call its
"check" command as to get libdvd-pkg triggers script to run?
The error trigger on each installi (or reinstall) or removal of a package.
libdvd-pkg: `apt-get check` failed, you may have broken packages. Aborting...
Adding "set -x" to /usr/lib/libdvd-pkg/b-i_libdvdcss.sh
and removing the stdout and stderr redirection from the "apt-get check"
and "dpkg -P nonexistent-package" calls, I get:
+ . /usr/lib/libdvd-pkg/VARS
+ PKGI=libdvd-pkg
+ DIR=/usr/src/libdvd-pkg
+ PKGG=libdvdcss2
+ PKGG_ALL=libdvdcss2 libdvdcss-dev
+ P88=88libdvdcss-pkg
+ VERGG=1.4.3-1
+ dpkg --status libdvdcss2
+ perl -0ne print $1 if m{^Status:\s+install\s+ok\s+installed}sm and
m{^Version:\s+(\S+)}sm;
+ VERG=1.4.2-1~local
+ dpkg --compare-versions 1.4.3-1~local gt 1.4.2-1~local
+ [ 0 = 0 ]
+ [ -f /usr/src/libdvd-pkg/libdvdcss2-1.4.3-1.is-installed ]
+ dpkg -P non-existent-package
dpkg: warning: ignoring request to remove non-existent-package which isn't
installed
+ [ 0 -eq 2 ]
+ [ ! -s /usr/src/libdvd-pkg/libdvdcss_1.4.3.orig.tar.bz2 ]
+ echo libdvd-pkg: Checking orig.tar integrity...
libdvd-pkg: Checking orig.tar integrity...
+ sha256sum --check --strict
/usr/share/libdvd-pkg/libdvdcss_1.4.3.orig.tar.bz2.sha256
/usr/src/libdvd-pkg/libdvdcss_1.4.3.orig.tar.bz2: OK
+ [ 0 -ne 0 ]
+ apt-get check
E: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process
2522949 (apt)
N: Be aware that removing the lock file is not a solution and may break your
system.
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is
another process using it?
+ [ 100 -ne 0 ]
+ echo libdvd-pkg: `apt-get check` failed, you may have broken packages.
Aborting...
libdvd-pkg: `apt-get check` failed, you may have broken packages. Aborting...
+ exit 0
dpkg only check for /var/lib/dpkg/lock and /var/lib/dpkg/triggers/Lock
"apt-get check" always fails in a trigger as
[200~/var/lib/dpkg/lock-frontend is locked by the parent apt.
So the whole script is nowadays a noop.
I believe passing the "--dry-run" flag to "apt-get check" would keep the
consistency check and allow to the script to fulfill its duty.
-- System Information:
Debian Release: 12.0
APT prefers stable-debug
APT policy: (500, 'stable-debug'), (500, 'oldstable-updates'), (500,
'oldstable-security'), (500, 'oldstable-debug'), (500, 'oldoldstable'), (500,
'stable'), (500, 'oldstable'), (99, 'testing-debug'), (99, 'testing'), (90,
'unstable-debug'), (90, 'unstable'), (1, 'experimental-debug'), (1,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.1.0-7-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 libdvd-pkg depends on:
ii build-essential 12.9
ii debconf [debconf-2.0] 1.5.82
ii debhelper [debhelper-compat] 13.11.4
ii devscripts2.23.4
ii wget 1.21.3-1+b2
Versions of packages libdvd-pkg recommends:
ii libcap2-bin 1:2.66-4
libdvd-pkg suggests no packages.
-- debconf information:
* libdvd-pkg/build: true
libdvd-pkg/post-invoke_hook-remove: false
libdvd-pkg/upgrade:
* libdvd-pkg/post-invoke_hook-install: true
libdvd-pkg/title_u:
* libdvd-pkg/first-install:
libdvd-pkg/title_b-i:
-- debsums errors found:
debsums: changed file /usr/lib/libdvd-pkg/b-i_libdvdcss.sh (from libdvd-pkg
package)
Bug#1015915: pipewire-pulse leaking memory
Can you reproduce with current pipewire? I am running 0.3.70 from experimental but have pipewire rss at 30.0M and pipewire-pulse at 116.9M after 16 hours. You meant pipewire or pipewire-pulse was leaking? Cheers, Alban On Sat, 23 Jul 2022 19:52:44 + Witold Barylulk wrote: > Package: pipewire-pulse > Version: 0.3.56-1 > Severity: normal > X-Debbugs-Cc: witold.bary...@gmail.com > > Starts okish, with rss at around 35MB. But grows about 20MB per hour. > After few days was 2.1GB and didn't stop growing. > > I do not have any special custom configuration. > > -- System Information: > Debian Release: bookworm/sid > APT prefers unstable-debug > APT policy: (500, 'unstable-debug'), (500, 'unstable') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 5.19.0-rc5 (SMP w/32 CPU threads; PREEMPT) > Kernel taint flags: 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) > > Versions of packages pipewire-pulse depends on: > ii init-system-helpers 1.64 > ii pipewire 0.3.56-1 > > pipewire-pulse recommends no packages. > > Versions of packages pipewire-pulse suggests: > ii libspa-0.2-bluetooth 0.3.56-1 > ii pulseaudio-utils 15.0+dfsg1-4+b1 > > -- no debconf information > >
Bug#1031152: system-config-printer: unlock button in system-config-printer provides no elevated permissions dialog
This unlikely to be a bug in system-config-printer as its delegate authentication to polkit and cups-pk-helper. Could you tell if you have cups-pk-helper installed and if running "pkexec ls" from a graphical terminal works? Cheers, Alban To other participants, you have to include the submitter email address in the Cc of your email else the bug report only ends up on the web UI. On Thu, 20 Apr 2023 18:47:25 -0400 Kevin Otte wrote: > On my Debian 11 XFCE machine this works correctly. Make sure "PolicyKit > Authentication Agent" is checked under "Session and Startup" -> > "Application Autostart". > > In Debian 12 under Sway the GNOME Authentication Agent segfaults, but I > will take this up under separate cover. I was able to work around the > issue for the moment by using lxpolkit for the authentication agent instead. > >
Bug#1035280: pipewire-pulse 0.3.70 client side crash when load-module module-zeroconf-discover against a pipewire-pulse with module-native-protocol-tcp and module-zeroconf-publish
The issue was triggered by a LibreElec 11.0.1 box that advertises a PulseAudio protocol tcp service on port 4713 but does not listen there. I believe this could be reproduced via a fake avahi service XML definition. Issue fixed upstream in https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/ffa21d696d7d364e9d46e519b513c2780bd7b6f3 . I made a merge request against salsa debian/experimental at https://salsa.debian.org/utopia-team/pipewire/-/merge_requests/20 On Thu, 04 May 2023 17:11:31 +0200 Alban Browaeys wrote: > reported upstream as > https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3199 > > likely the bug is triggered by the module erroring out when trying to > connect on a non existent remote port. > Then the segfault is bug in pipewire. > > On Tue, 02 May 2023 02:57:36 +0200 Alban Browaeys > wrote: > > Just a quick note that I am able to reproduce this issue with master. > > Though at times it works with upstream master, running from builddir > > via "make run" under the ./pw-uninstalled.sh environment. > > Maybe this only works because the settings are different. > > > > Likely an upstream issue. > > > > Cheers, > > Alban > > > > > > >
Bug#1035280: pipewire-pulse 0.3.70 client side crash when load-module module-zeroconf-discover against a pipewire-pulse with module-native-protocol-tcp and module-zeroconf-publish
reported upstream as https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3199 likely the bug is triggered by the module erroring out when trying to connect on a non existent remote port. Then the segfault is bug in pipewire. On Tue, 02 May 2023 02:57:36 +0200 Alban Browaeys wrote: > Just a quick note that I am able to reproduce this issue with master. > Though at times it works with upstream master, running from builddir > via "make run" under the ./pw-uninstalled.sh environment. > Maybe this only works because the settings are different. > > Likely an upstream issue. > > Cheers, > Alban > >
Bug#1035391: dovecot-fts-xapian: stable version is very slow
Package: dovecot-fts-xapian Version: 1.4.9a-1+deb11u1 Severity: normal Dear Maintainer, The stable package version is very slow, likely due to missing fix https://github.com/grosjo/fts-xapian/commit/6c1518ae8bf3cfc5993d1e653c53c5b9a206cb88 first introduced in 1.4.11. See https://github.com/grosjo/fts-xapian/issues/89 " grosjo commented on Jul 4, 2021 Yes, it seems the detection of the free memory was buggy, and the plugin kept flushing on disk, which destroyed the performance " The stable backports 1.5.5-1~bpo11+1 version fixes this issue. This bug report is there to point to a bug and tell the workaround (install bullseye-backports version). As this is not a security issue I doubt this commit would be added to the bullseye version of the package. stable version was indexing my 56G Maildir for more than a month with 1.4.9a-1+deb11u1 without even having half of it indexed. Cheers, Alban -- System Information: Debian Release: 11.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), (90, 'unstable'), (90, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-0.deb11.6-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1031719: libpipewire-0.3-modules: pipewire module zeroconf discover filters out sources
Likely an upstream issue. I see the headset mic has an IPv6 address: address = [2a01:e0a:8db:8861:dead:beef:0:f0f8] while advertised as IPv4. pipewire now filter IPv6 zeroconf advertisment in its zeroconf-discover module to avoid showing duplicate entries (one for IPv4 the other for IPv6) in the client UI this might be related. The fact that no IPv4 service is advertised (well it is but with an IPv6 address) might explain why the pipewire zeroconf discover module hide your headless mic. You could try older pipewire debs (snapshot.debian.org) as this IPv6 hide was introduced recently or simply open a bug in the upstream bug tracker. This was introduced due to https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2031 The change was made on the publishing side ie the server is the one were you should downgrade pipewire. The version that introduced this behaviour is 0.6.32 so downgtrading to 0.6.31 will do. see https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2861 The fact that an IPv6 address is published in an IPv4 entry might be another upstream pipewire bug namely inhte zeroconf-publish module. Though before reporting to upstream you should try at least pipewire 0.3.70 from debian experimental (and maybe even upstream code). Mind that for me 0.3.70 module-zeroconf-discover module might crash on startup but this is another issue that I am investigating. Might not crash for you (the crash depends on the server box adverstising which will be different for your setup). upstream git code is also affected. This is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035280 not yet reported upstream (as I have a hard time to reproduce properly with my git master build). Cheers, Alban On Tue, 21 Feb 2023 14:45:03 +0100 Landry MINOZA wrote: > Package: libpipewire-0.3-modules > Version: 0.3.65-2 > Severity: normal > > Dear Maintainer, > > Trying to use remote devices with pipewire, I don't see some devices > (specificaly a headset mic in my case). > Reproduce on 2 sid clients. > > I load zeroconf module: > > pactl load-module module-zeroconf-discover > > When listing available devices: > Audio > ├─ Devices: > │ 42. Audio interne [alsa] > │ > ├─ Sinks: > │ * 45. Audio interne Stéréo analogique [vol: 0.40] > │ 62. Starship/Matisse HD Audio Controller Stéréo analogique on landry@demetra [vol: 1.00] > │ 64. [G533 Wireless Headset Dongle] [vol: 1.00] > │ > ├─ Sink endpoints: > │ > ├─ Sources: > │ * 46. Audio interne Stéréo analogique [vol: 1.00 MUTED] > │ 60. Starship/Matisse HD Audio Controller Stéréo analogique on landry@demetra [vol: 1.00] > │ > ├─ Source endpoints: > │ > └─ Streams: > > The headset mic (source [G333 Wireless Headset Dongle] is exposed by > avahi: > > ❯ avahi-browse --resolve _pulse-source._tcp -t > + wlan0 IPv4 landry@demetra: [G533 Wireless Headset Dongle] Mono PulseAudio Sound Source local > + wlan0 IPv4 landry@demetra: Starship/Matisse HD Audio Controller St__r__o a PulseAudio Sound Source local > = wlan0 IPv4 landry@demetra: [G533 Wireless Headset Dongle] Mono PulseAudio Sound Source local > hostname = [demetra.local] > address = [2a01:e0a:8db:8861:dead:beef:0:f0f8] > port = [4713] > txt = ["description=[G533 Wireless Headset Dongle] Mono" "subtype=hardware" "channel_map=mono" "format=s16le" "channels=1" "rate=48000" "device=alsa_input.usb-Logitech_G533_Gaming_Headset- 00.mono-fallback" "cookie=0x4a6f9a3a" "fqdn=demetra" "uname=Linux x86_64 6.1.0-5-amd64" "user-name=landry" "server-version=PipeWire 0.3.65"] > = wlan0 IPv4 landry@demetra: Starship/Matisse HD Audio Controller St__r__o a PulseAudio Sound Source local > hostname = [demetra.local] > address = [10.0.0.144] > port = [4713] > txt = ["description=Starship/Matisse HD Audio Controller St\195\169r\195\169o analogique" "subtype=hardware" "channel_map=front- left,front-right" "format=s32le" "channels=2" "rate=48000" "device=alsa_input.pci-_0a_00.4.analog-stereo" "cookie=0x4a6f9a3a" "fqdn=demetra" "uname=Linux x86_64 6.1.0-5-amd64" "user-name=landry" "server-version=PipeWire 0.3.65"] > > On the remote host, this source is visible and usable: > Audio > ├─ Devices: > │ 44. GM204 High Definition Audio Controller [alsa] > │ 46. [G533 Wireless Headset Dongle] [alsa] > │ 47. Starship/Matisse HD Audio Controller [alsa] > │ 122. Fairphone 4 5G [bluez5] > │ > ├─ Sinks:
Bug#1035280: pipewire-pulse 0.3.70 client side crash when load-module module-zeroconf-discover against a pipewire-pulse with module-native-protocol-tcp and module-zeroconf-publish
Just a quick note that I am able to reproduce this issue with master. Though at times it works with upstream master, running from builddir via "make run" under the ./pw-uninstalled.sh environment. Maybe this only works because the settings are different. Likely an upstream issue. Cheers, Alban
Bug#1035280: pipewire-pulse 0.3.70 client side crash when load-module module-zeroconf-discover against a pipewire-pulse with module-native-protocol-tcp and module-zeroconf-publish
Package: pipewire Version: 0.3.70-1 Severity: important Dear Maintainer, I upgraded pipewire to 0.3.70 on boht the pipewire-pulse client and server side of the native "pulseaudio" tcp tunnel. I restart pipewire and pipewire-pulse user systemd services and then the client box pipewire-pulse started constantly crashing and reloading. systemctl --user status pipewire-pulse × pipewire-pulse.service - PipeWire PulseAudio Loaded: loaded (/usr/lib/systemd/user/pipewire-pulse.service; enabled; preset: enabled) Active: failed (Result: core-dump) since Sun 2023-04-30 02:07:45 CEST; 10s ago Duration: 1.593s TriggeredBy: ○ pipewire-pulse.socket Process: 2254260 ExecStart=/usr/bin/pipewire-pulse (code=dumped, signal=SEGV) Main PID: 2254260 (code=dumped, signal=SEGV) CPU: 1.175s avril 30 02:07:41 cyclope systemd[7728]: Started pipewire-pulse.service - PipeWire PulseAudio. avril 30 02:07:41 cyclope pipewire-pulse[2254260]: mod.pulse-tunnel: failed to connect: Connection refused avril 30 02:07:41 cyclope pipewire-pulse[2254260]: mod.zeroconf-discover: Can't load module: Connexion refusée avril 30 02:07:43 cyclope systemd[7728]: Stopping pipewire-pulse.service - PipeWire PulseAudio... avril 30 02:07:45 cyclope systemd-coredump[2254277]: Process 2254260 (pipewire-pulse) of user 1000 dumped core. Stack trace of thread 2254260: #0 0x7f58a57d0ea0 pw_impl_module_schedule_destroy (libpipewire-0.3.so.0 + 0x72ea0) #1 0x7f58a4c64b0d do_schedule_destroy (libpipewire-module-pulse-tunnel.so + 0x5b0d) #2 0x7f58a5885a4f flush_items (libspa-support.so + 0x6a4f) #3 0x7f58a5885899 source_event_func (libspa-support.so + 0x6899) #4 0x7f58a5887f9e loop_iterate (libspa-support.so + 0x8f9e) #5 0x7f58a57cd78b pw_main_loop_run (libpipewire-0.3.so.0 + 0x6f78b) #6 0x5590e0b4c457 main (pipewire + 0x1457) #7 0x7f58a55a418a __libc_start_call_main (libc.so.6 + 0x2718a) #8 0x7f58a55a4245 __libc_start_main_impl (libc.so.6 + 0x27245) #9 0x5590e0b4c5f1 _start (pipewire + 0x15f1) Stack trace of thread 2254264: #0 0x7f58a5685c06 epoll_wait (libc.so.6 + 0x108c06) #1 0x7f58a5896ec0 impl_pollfd_wait (libspa-support.so + 0x17ec0) #2 0x7f58a5887e1b loop_iterate (libspa-support.so + 0x8e1b) #3 0x7f58a57a7f6c do_loop (libpipewire-0.3.so.0 + 0x49f6c) #4 0x7f58a5605fd4 start_thread (libc.so.6 + 0x88fd4) #5 0x7f58a5685820 __clone (libc.so.6 + 0x108820) Stack trace of thread 2254269: #0 0x7f58a5678fff __GI___poll (libc.so.6 + 0xfbfff) #1 0x7f58a3ec02e1 n/a (libpulse.so.0 + 0x342e1) #2 0x7f58a3eb1fa4 pa_mainloop_poll (libpulse.so.0 + 0x25fa4) #3 0x7f58a3eb2606 pa_mainloop_iterate (libpulse.so.0 + 0x26606) #4 0x7f58a3eb26b0 pa_mainloop_run (libpulse.so.0 + 0x266b0) #5 0x7f58a3ec03b9 n/a (libpulse.so.0 + 0x343b9) #6 0x7f58a3e6133f n/a (libpulsecommon-16.1.so + 0x5b33f) #7 0x7f58a5605fd4 start_thread (libc.so.6 + 0x88fd4) #8 0x7f58a5685820 __clone (libc.so.6 + 0x108820) Stack trace of thread 2254275: #0 0x7f58a5678fff __GI___poll (libc.so.6 + 0xfbfff)
Bug#1025069: pavucontrol
Also could you also give the wireplumber log https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3086#note_1829660 Cheers, Alban Le mardi 11 avril 2023 à 14:30 +0200, Alban Browaeys a écrit : > Le dimanche 09 avril 2023 à 15:03 -0500, Lucas a écrit : > > I should have let you know when I created it, but I still have no > > feedback from a bug report I wrote to the pipewire developers: > > https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3131. > > > > > "Multichannel Output" Profile disappeared after I ran JACK (ardour), > and I only see again now on a fresh startup. > > Do you mean it disappeared from pavucontrol when you run JACK from > ardour ? > > What I meant is that you cannot run pipewire and jackd at the same > time ? I cannot work as one will prevent the other from accessing the > ALSA sound device. > If you want to run JACK application whne running pipewire you can > only do so by pipewire-jackd and disabling jackd. > This is not a pipewire bug. jackd also cannot work if the sound > device is already taken by an alsa program or any other daemon > plugging to the alsa interface (pipewire, pulseaudio), it could work > because for one pulseaudio aut suspend itself from time to time so > the alsa sound device is free when so. But then when pulseaudio will > resume and your jackd daemon is holding on the alsa sound device > pulseaudio will not work. This is not supported (for pulseaudio you > could use the pasuspend tool, still it is hack). > > > Also: > Gnome Settings Output Device contains nothing to select, while Input > allows "Analog Input - STUDIO-CAPTURE" and "STUDIO-CAPTURE Pro". The > only way to have output audio working is to use pavucontrol and > select either of the STUDIO-CAPTURE Profile Configurations > "Multichannel Output", or "Pro Audio". > and: > That "Multichannel Output" Profile disappeared after I ran JACK > (ardour), and I only see again now on a fresh startup. > seems to be two different issue. You should report both in two > diffrent bug report else it the bug report will get confusing soon. > My reply was about the second issue (which to me look like a normal > behavior). > > > For the first one, I am a bit confused. You mean that even in > pavucontrol if you do not switch to the STUDIO-CAPTURE Profile > Configurations "Multichannel Output", or "Pro Audio" you cannot set a > sound output device? > > If you bug report upstream you could try to run pipewire built from > source (you just have to stop pipewire related systemd user services, > ie systemctl --user stop pipewire.service, etc). > Also there is a newer pipewire version 0.3.76 in Debian rc-buggy > (experimental). > > > > I guessed it was a "port detection" issue after reading this > > response on the original poster's bug report: > > https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3086#note_1831991 > > > > Could you provide the same debug logs as this bug reporter did? > > loginctl user-status | grep State > lsof /dev/snd/* > fuser -v /dev/snd/* > aplay -l > journalctl --user -b --unit pipewire.service > > and maybe also > journalctl --user -b --unit pipewire-pulse.service > pipewire --version > > > and why not the output when running gnome-control-center from a > terminal: > gnome-control-center --verbose sound > > Still could you try with pipewire-jack instead of jackd (even if you > prefer to run jackd only while running a jack application. > > Cheers > Alban > > > > > On Sun, Apr 9, 2023 at 1:33 PM Lucas wrote: > > > On Fri, Apr 7, 2023 at 7:57 PM Alban Browaeys > > > wrote: > > > > > > > > Do you have jackd installed and runnning at the same time as > > > pipewire- > > > > pulse? > > > > Maybe you want to try piepwire-jack instead? > > > > > > > > Cheers, > > > > Alban > > > > > > > > > > I appreciate the suggestion, but since I also use multiple > > > devices > > > with JACK, it's only running when I want to record and use a > > > specific > > > profile/device. Ardour will start it using the last used > > > (default) > > > profile, but only when I've not already started JACK from > > > qjackctl to > > > use another profile. I think having it always running may > > > complicate > > > this setup I've grown accustomed to. Are you aware of any issues > > > trying to stop JACK (to use other rates and devices) when using > > > pipewire-jack? > > > > > > Thanks, > > > Lucas > > > > > > -- > > Protect your digital freedom and privacy, eliminate DRM, learn more > > at http://www.defectivebydesign.org/what_is_drm > > On a related note, also see > > https://www.fsf.org/campaigns/surveillance >
Bug#1025069: pavucontrol
Le dimanche 09 avril 2023 à 15:03 -0500, Lucas a écrit : > I should have let you know when I created it, but I still have no > feedback from a bug report I wrote to the pipewire developers: > https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3131. > "Multichannel Output" Profile disappeared after I ran JACK (ardour), and I only see again now on a fresh startup. Do you mean it disappeared from pavucontrol when you run JACK from ardour ? What I meant is that you cannot run pipewire and jackd at the same time ? I cannot work as one will prevent the other from accessing the ALSA sound device. If you want to run JACK application whne running pipewire you can only do so by pipewire-jackd and disabling jackd. This is not a pipewire bug. jackd also cannot work if the sound device is already taken by an alsa program or any other daemon plugging to the alsa interface (pipewire, pulseaudio), it could work because for one pulseaudio aut suspend itself from time to time so the alsa sound device is free when so. But then when pulseaudio will resume and your jackd daemon is holding on the alsa sound device pulseaudio will not work. This is not supported (for pulseaudio you could use the pasuspend tool, still it is hack). Also: Gnome Settings Output Device contains nothing to select, while Input allows "Analog Input - STUDIO-CAPTURE" and "STUDIO-CAPTURE Pro". The only way to have output audio working is to use pavucontrol and select either of the STUDIO-CAPTURE Profile Configurations "Multichannel Output", or "Pro Audio". and: That "Multichannel Output" Profile disappeared after I ran JACK (ardour), and I only see again now on a fresh startup. seems to be two different issue. You should report both in two diffrent bug report else it the bug report will get confusing soon. My reply was about the second issue (which to me look like a normal behavior). For the first one, I am a bit confused. You mean that even in pavucontrol if you do not switch to the STUDIO-CAPTURE Profile Configurations "Multichannel Output", or "Pro Audio" you cannot set a sound output device? If you bug report upstream you could try to run pipewire built from source (you just have to stop pipewire related systemd user services, ie systemctl --user stop pipewire.service, etc). Also there is a newer pipewire version 0.3.76 in Debian rc-buggy (experimental). > I guessed it was a "port detection" issue after reading this response > on the original poster's bug report: > https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3086#note_1831991 > Could you provide the same debug logs as this bug reporter did? loginctl user-status | grep State lsof /dev/snd/* fuser -v /dev/snd/* aplay -l journalctl --user -b --unit pipewire.service and maybe also journalctl --user -b --unit pipewire-pulse.service pipewire --version and why not the output when running gnome-control-center from a terminal: gnome-control-center --verbose sound Still could you try with pipewire-jack instead of jackd (even if you prefer to run jackd only while running a jack application. Cheers Alban > > On Sun, Apr 9, 2023 at 1:33 PM Lucas wrote: > > On Fri, Apr 7, 2023 at 7:57 PM Alban Browaeys > > wrote: > > > > > > Do you have jackd installed and runnning at the same time as > > pipewire- > > > pulse? > > > Maybe you want to try piepwire-jack instead? > > > > > > Cheers, > > > Alban > > > > > > > I appreciate the suggestion, but since I also use multiple devices > > with JACK, it's only running when I want to record and use a > > specific > > profile/device. Ardour will start it using the last used (default) > > profile, but only when I've not already started JACK from qjackctl > > to > > use another profile. I think having it always running may > > complicate > > this setup I've grown accustomed to. Are you aware of any issues > > trying to stop JACK (to use other rates and devices) when using > > pipewire-jack? > > > > Thanks, > > Lucas > > > -- > Protect your digital freedom and privacy, eliminate DRM, learn more > at http://www.defectivebydesign.org/what_is_drm > On a related note, also see > https://www.fsf.org/campaigns/surveillance
Bug#1005369: xserver-xorg-core: Breaks middle button trackpoint scrolling
Could you check that your bug is reproducible with xorg libinput (that you do not want but still if only xserver-xorg-input-synaptics is at fault there should this bug be moved to)? Your issue was with xserver-xorg-core 2:21.1.3-2 and you told that reverting to the version in testing fixed the issue. Which version was this testing xserver-xorg-core that fixed the issue? Nowadays testing and unstable both have xserver-xorg-core 21.1.7-2. With xserver-xorg-input-libinput 1.2.1-1+b1, on my Lenovo Thinkpad Yoga S1 I can scroll with middle button press and trackpoint up and down. If you do not want to even test with xserver-xorg-input-libinput (and xserver-xorg-input-synaptics at least temporiraly uninstalled if installed else it will take precedence. I believe xserver-xorg-input- evdev is lower priority thant xserver-xorg-input-libinput but you might want to temporiraly uninstall it too) could you confirm the issue still exists with current packages (and with all upgrades done ... partial upgrade might break functionality. xserver-xorg-input-synaptics is not supported anymore by gnome. Migrating from Debian to another distribution will not change the fact that any upstreams are now requiring libinput. Cheers, Alban Le mercredi 05 avril 2023 à 23:56 +0200, Salvo Tomaselli a écrit : > Yes it has some options. Not as many as the alternatives. Some of > those options happen to be ones that I change. > > Il giorno mer 5 apr 2023 alle ore 02:22 Alban Browaeys > ha scritto: > > > > I am on a thinkapd (the Yoga S1) and xorg libinput driver works > > fine (I > > configure it through gnome-control-center). > > > > I really do not know what you mean by "avoid libinput's opinions on > > how > > my input should work". Could you give example? > > > > https://www.mankier.com/4/libinput > > these do not count as configuration options? > > > > Cheers, > > > > Alban > > > > > > Le mardi 04 avril 2023 à 21:21 +0200, Salvo Tomaselli a écrit : > > > No the libinput one is bad. > > > > > > libinput's author doesn't want options, so there is no way to > > > have > > > usable input that feels good on thinkpads. > > > > > > I'm using the xserver-xorg-input-evdev one. I guess when Xorg > > > will be > > > kicked out of debian, I will need to move to devuan or something > > > like > > > that, just to avoid libinput's opinions on how my input should > > > work. > > > > > > Il giorno mar 4 apr 2023 alle ore 18:45 Alban Browaeys > > > ha scritto: > > > > > > > > Try removing > > > > xserver-xorg-input-synaptics > > > > then restart xorg. > > > > > > > > xserver-xorg-input-synaptics i sno longer supported by GNOME as > > > > far > > > > as > > > > know. > > > > xserver-xorg-input-libinput is the replacment. > > > > > > > > Cheers, > > > > Alban > > > > > > > > On Sat, 12 Feb 2022 09:53:16 +0100 "Salvo \"LtWorf\" Tomaselli" > > > > wrote: > > > > > Package: xserver-xorg-core > > > > > Version: 2:21.1.3-2 > > > > > Severity: critical > > > > > Tags: upstream > > > > > Justification: breaks unrelated software > > > > > X-Debbugs-Cc: tipos...@tiscali.it > > > > > > > > > > Dear Maintainer, > > > > > > > > > > on thinkpads it is common to scroll by holding down the > > > > > middle > > > > > button > > > > and > > > > > pushing the trackpoint up or down. > > > > > > > > > > After upgrading, this feature is broken. > > > > > > > > > > Reverting to the version found in testing makes it work > > > > > again. > > > > > > > > > > In a wayland session it works (but my keyboard layout doesn't > > > > > exist > > > > in wayland > > > > > so using it permanently is not a viable solution). > > > > > > > > > > It is strange because the input drivers have not received an > > > > > update, > > > > so I'm not > > > > > really sure of what the interaction is here. > > > > > > > > > > Anyway, I'm creating this issue with a high priority in order > > > > > to > > > > > stop > > > > the package > > > > > from migrating and make scrolling suddenly u
Bug#1025069: pavucontrol
Do you have jackd installed and runnning at the same time as pipewire- pulse? Maybe you want to try piepwire-jack instead? Cheers, Alban On Fri, 31 Mar 2023 06:22:38 -0500 Lucas wrote: > Here's a correction: I shutdown and started it again, and the > pavucontrol setup was retained. So, I continued testing by running > ardour, knowing it's set to use JACK through ALSA. It played fine, > but when I quit it, I wasn't able to hear pulseaudio, nor select the > same pavucontrol profile. Luckily, there's a "Pro Audio" > Configuration in pavucontrol that works too. I retested ardour with > it and later standard pulseaudio playback, and it continues to work! > I wouldn't say this is fixed, but I consider it much improved, by > these findings, and almost tolerable. > >
Bug#996367: pipewire issues with M-Audio 410
Alexandre, could you close this bug report as you told it to be solved? See https://www.debian.org/Bugs/Developer#closing That is, if you know the version that fixed the issue, add the pseudo- header Version: if you do not know the version, do not include this Version pseudo- header. If you know what fixed the bug tell in the email body. and then send this email to 996367-d...@bugs.debian.org to close this bug. Cheers, Alban On Fri, 18 Nov 2022 19:33:34 -0300 Alexandre Lymberopoulos wrote: > Hello, Dylan! > > Things are going much better with the new releases: 996367 seems to be > solved, but 997915 persists. For the latter it seems to be something > like capturing sources with different sample rates (like 48Khz and > 44Khz). This guess is due to the resulting sound: the "default" > recording device (as selected with pavucontrol - have pipewire, pulse > and jack installed here! more on this later) have nice sound and the > other sounds like playing a standard 33rpm vinyl in 45rpm (revealing my > age here) with a lot of clips. > > To make things tidy and clean here I would like to know if there is a > way to keep just pipewire running here (over ALSA, probably) and if > there are some mixer software to use with pipewire (ffado-mixer stopped > working with M-Audio 410 here). > > Best, > Alexandre > > === > Alexandre Lymberopoulos - lym...@gmail.com > === > > > On Fri, Nov 18 2022 at 02:54:57 PM +01:00:00, Dylan Aïssi > wrote: > > Hello Alexandre, > > > > My apologies for not responding earlier. > > > > Do you still have these problems with pipewire or have they been > > solved > > with the new versions? > > > > Best, > > Dylan > > > >
Bug#1005369: xserver-xorg-core: Breaks middle button trackpoint scrolling
I am on a thinkapd (the Yoga S1) and xorg libinput driver works fine (I configure it through gnome-control-center). I really do not know what you mean by "avoid libinput's opinions on how my input should work". Could you give example? https://www.mankier.com/4/libinput these do not count as configuration options? Cheers, Alban Le mardi 04 avril 2023 à 21:21 +0200, Salvo Tomaselli a écrit : > No the libinput one is bad. > > libinput's author doesn't want options, so there is no way to have > usable input that feels good on thinkpads. > > I'm using the xserver-xorg-input-evdev one. I guess when Xorg will be > kicked out of debian, I will need to move to devuan or something like > that, just to avoid libinput's opinions on how my input should work. > > Il giorno mar 4 apr 2023 alle ore 18:45 Alban Browaeys > ha scritto: > > > > Try removing > > xserver-xorg-input-synaptics > > then restart xorg. > > > > xserver-xorg-input-synaptics i sno longer supported by GNOME as far > > as > > know. > > xserver-xorg-input-libinput is the replacment. > > > > Cheers, > > Alban > > > > On Sat, 12 Feb 2022 09:53:16 +0100 "Salvo \"LtWorf\" Tomaselli" > > wrote: > > > Package: xserver-xorg-core > > > Version: 2:21.1.3-2 > > > Severity: critical > > > Tags: upstream > > > Justification: breaks unrelated software > > > X-Debbugs-Cc: tipos...@tiscali.it > > > > > > Dear Maintainer, > > > > > > on thinkpads it is common to scroll by holding down the middle > > > button > > and > > > pushing the trackpoint up or down. > > > > > > After upgrading, this feature is broken. > > > > > > Reverting to the version found in testing makes it work again. > > > > > > In a wayland session it works (but my keyboard layout doesn't > > > exist > > in wayland > > > so using it permanently is not a viable solution). > > > > > > It is strange because the input drivers have not received an > > > update, > > so I'm not > > > really sure of what the interaction is here. > > > > > > Anyway, I'm creating this issue with a high priority in order to > > > stop > > the package > > > from migrating and make scrolling suddenly unavailable to other > > people as well. > > > > > > -- Package-specific info: > > > /etc/X11/X does not exist. > > > /etc/X11/X is not a symlink. > > > /etc/X11/X is not executable. > > > > > > VGA-compatible devices on PCI bus: > > > -- > > > 00:02.0 VGA compatible controller [0300]: Intel Corporation > > TigerLake-LP GT2 [Iris Xe Graphics] [8086:9a49] (rev 01) > > > > > > /etc/X11/xorg.conf does not exist. > > > > > > Contents of /etc/X11/xorg.conf.d: > > > - > > > total 0 > > > > > > /etc/modprobe.d contains no KMS configuration files. > > > > > > Kernel version (/proc/version): > > > --- > > > Linux version 5.16.0-1-amd64 (debian-ker...@lists.debian.org) > > > (gcc-11 > > (Debian 11.2.0-16) 11.2.0, GNU ld (GNU Binutils for Debian) > > 2.37.90.20220130) #1 SMP PREEMPT Debian 5.16.7-2 (2022-02-09) > > > > > > Xorg X server log files on system: > > > -- > > > -rw-r--r-- 1 root root 50312 Feb 12 09:43 /var/log/Xorg.0.log > > > > > > Contents of most recent Xorg X server log file > > > (/var/log/Xorg.0.log): > > > - > > > > > > [ 2.949] (--) Log file renamed from "/var/log/Xorg.pid- > > > 579.log" > > to "/var/log/Xorg.0.log" > > > [ 2.951] > > > X.Org X Server 1.21.1.3 > > > X Protocol Version 11, Revision 0 > > > [ 2.951] Current Operating System: Linux galatea 5.16.0-1- > > > amd64 > > #1 SMP PREEMPT Debian 5.16.7-2 (2022-02-09) x86_64 > > > [ 2.951] Kernel command line: BOOT_IMAGE=/boot/vmlinuz- > > > 5.16.0-1- > > amd64 root=UUID=2e600d3e-5bd5-43cd-b826-9213b7bafb99 ro quiet > > > [ 2.951] xorg-server 2:21.1.3-2 > > > (https://www.debian.org/support) > > > [ 2.951] Current version of pixman: 0.40.0 > > > >
Bug#1005359: xserver-xorg-core: Intel HD Graphics 610: blank screen
Your logs shows:
[70.057] (EE) dbus-core: error connecting to system bus:
org.freedesktop.DBus.Error.FileNotFound (Failed to connect to socket
/run/dbus/system_bus_socket: No such file or directory)
Do you have dbus-daemon installed and its server running (systemctl status
dbus.service)?
You also have:
[70.087] (EE) Failed to load module "fbdev" (module does not exist, 0)
and
[70.087] (EE) Failed to load module "vesa" (module does not exist, 0)
you could try installing:
xserver-xorg-video-vesa
and
xserver-xorg-video-fbdev
On Mon, 21 Nov 2022 11:56:44 +0100 Jakub Wilk wrote:
> Control: found -1 2:21.1.4-3
>
> * Jakub Wilk , 2022-02-11 23:17:
> >the X server no longer works for me: I get only blank screen. Worse,
> >the blankness remains even after I zap the server.
>
> I've bisected this; the first bad commit is 4e670f1281ad75c5
> ("modesetting: Add CTM RandR property").
>
> Reverting this commit (on top of 2:21.1.4-3) fixes the bug for me.
You should really open an issue in the upstream bug tracker and give
its url here if so.
By the way how do you proceed to bisect (out of the git workflow, ie to
test than on your Debian setup each bisected version works)?
Cheers,
Alban
Bug#1005368: xserver-xorg-core: Won’t upgrade
Are you still unable to install xserver-xorg-core without having to remove all your drivers packages? Mind you were on unstable and unstable is supposed to have upgrade path breakages from time to time. Have you waited a few days to confirm the issue was not a transistion in progress? Can you close the issue if the issue is gone now? Cheers, Alban On Sat, 12 Feb 2022 09:14:19 +0100 Nicolas Patrois wrote: > Package: xserver-xorg-core > Version: 2:1.20.14-1 > Severity: normal > > Dear Maintainer, > > The package won’t upgrade because it needs to remove driver packages (nearly > every driver packages), including the driver that I’m currently using. > Here is the list of the packages that won’t upgrade: > xserver-xorg-core xserver-xorg-input-libinput xserver-xorg-video- amdgpu > xserver-xorg-video-ati xserver-xorg-video-dummy xserver-xorg-video- fbdev > xserver-xorg-video-intel xserver-xorg-video-qxl xserver-xorg-video- radeon > xserver-xorg-video-vesa xserver-xorg-video-vmware > > Yours, > n. > > > -- Package-specific info: > X server symlink status: > > lrwxrwxrwx 1 root root 13 Oct 16 2009 /etc/X11/X -> /usr/bin/Xorg > -rwxr-xr-x 1 root root 274 Jan 11 15:21 /usr/bin/Xorg > > Diversions concerning libGL are in place > > diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2.0 by glx- diversions > diversion of /usr/lib/powerpc64le-linux-gnu/libGLESv2.so.2 to /usr/lib/mesa-diverted/powerpc64le-linux-gnu/libGLESv2.so.2 by glx- diversions > diversion of /usr/lib/libGL.so.1 to /usr/lib/mesa-diverted/libGL.so.1 by glx-diversions > diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.0.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2.0.0 by glx- diversions > diversion of /usr/lib/libGLESv2.so.2 to /usr/lib/mesa- diverted/libGLESv2.so.2 by glx-diversions > diversion of /usr/lib/arm-linux-gnueabihf/libGL.so to /usr/lib/mesa- diverted/arm-linux-gnueabihf/libGL.so by glx-diversions > diversion of /usr/lib/i386-linux-gnu/libGLX_indirect.so.0 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLX_indirect.so.0 by glx- diversions > diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 by glx- diversions > diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so by glx- diversions > diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2 to /usr/lib/mesa- diverted/i386-linux-gnu/libGLESv2.so.2 by glx-diversions > diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.1.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2.1.0 by glx- diversions > diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2.1.0 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2.1.0 by glx- diversions > diversion of /usr/lib/x86_64-linux-gnu/libGLESv2.so.2 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2 by glx- diversions > diversion of /usr/lib/x86_64-linux-gnu/libGLX_indirect.so.0 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLX_indirect.so.0 by glx- diversions > diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2 by glx- diversions > diversion of /usr/lib/x86_64-linux-gnu/libGLESv2.so.2.1.0 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2.1.0 by glx- diversions > diversion of /usr/lib/powerpc64le-linux-gnu/libGLESv1_CM.so to /usr/lib/mesa-diverted/powerpc64le-linux-gnu/libGLESv1_CM.so by glx- diversions > diversion of /usr/lib/aarch64-linux-gnu/libGLESv1_CM.so.1.1.0 to /usr/lib/mesa-diverted/aarch64-linux-gnu/libGLESv1_CM.so.1.1.0 by glx- diversions > diversion of /usr/lib/powerpc64le-linux-gnu/libGL.so.1.2.0 to /usr/lib/mesa-diverted/powerpc64le-linux-gnu/libGL.so.1.2.0 by glx- diversions > diversion of /usr/lib/libGLESv1_CM.so.1.1.0 to /usr/lib/mesa- diverted/libGLESv1_CM.so.1.1.0 by glx-diversions > diversion of /usr/lib/powerpc64le-linux-gnu/libGLESv2.so to /usr/lib/mesa-diverted/powerpc64le-linux-gnu/libGLESv2.so by glx- diversions > diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1 by glx- diversions > diversion of /usr/lib/aarch64-linux-gnu/libGL.so.1.2.0 to /usr/lib/mesa-diverted/aarch64-linux-gnu/libGL.so.1.2.0 by glx- diversions > diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so by glx- diversions > diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1.2.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1.2.0 by glx-diversions > diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 by glx-diversions > diversion of /usr/lib/libGL.so.1.2.0 to /usr/lib/mesa- diverted/libGL.so.1.2.0 by glx-diversions > diversion of
Bug#1005369: xserver-xorg-core: Breaks middle button trackpoint scrolling
Try removing xserver-xorg-input-synaptics then restart xorg. xserver-xorg-input-synaptics i sno longer supported by GNOME as far as know. xserver-xorg-input-libinput is the replacment. Cheers, Alban On Sat, 12 Feb 2022 09:53:16 +0100 "Salvo \"LtWorf\" Tomaselli" wrote: > Package: xserver-xorg-core > Version: 2:21.1.3-2 > Severity: critical > Tags: upstream > Justification: breaks unrelated software > X-Debbugs-Cc: tipos...@tiscali.it > > Dear Maintainer, > > on thinkpads it is common to scroll by holding down the middle button and > pushing the trackpoint up or down. > > After upgrading, this feature is broken. > > Reverting to the version found in testing makes it work again. > > In a wayland session it works (but my keyboard layout doesn't exist in wayland > so using it permanently is not a viable solution). > > It is strange because the input drivers have not received an update, so I'm not > really sure of what the interaction is here. > > Anyway, I'm creating this issue with a high priority in order to stop the package > from migrating and make scrolling suddenly unavailable to other people as well. > > -- Package-specific info: > /etc/X11/X does not exist. > /etc/X11/X is not a symlink. > /etc/X11/X is not executable. > > VGA-compatible devices on PCI bus: > -- > 00:02.0 VGA compatible controller [0300]: Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics] [8086:9a49] (rev 01) > > /etc/X11/xorg.conf does not exist. > > Contents of /etc/X11/xorg.conf.d: > - > total 0 > > /etc/modprobe.d contains no KMS configuration files. > > Kernel version (/proc/version): > --- > Linux version 5.16.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-11 (Debian 11.2.0-16) 11.2.0, GNU ld (GNU Binutils for Debian) 2.37.90.20220130) #1 SMP PREEMPT Debian 5.16.7-2 (2022-02-09) > > Xorg X server log files on system: > -- > -rw-r--r-- 1 root root 50312 Feb 12 09:43 /var/log/Xorg.0.log > > Contents of most recent Xorg X server log file (/var/log/Xorg.0.log): > - > [ 2.949] (--) Log file renamed from "/var/log/Xorg.pid-579.log" to "/var/log/Xorg.0.log" > [ 2.951] > X.Org X Server 1.21.1.3 > X Protocol Version 11, Revision 0 > [ 2.951] Current Operating System: Linux galatea 5.16.0-1-amd64 #1 SMP PREEMPT Debian 5.16.7-2 (2022-02-09) x86_64 > [ 2.951] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.16.0-1- amd64 root=UUID=2e600d3e-5bd5-43cd-b826-9213b7bafb99 ro quiet > [ 2.951] xorg-server 2:21.1.3-2 (https://www.debian.org/support) > [ 2.951] Current version of pixman: 0.40.0
Bug#1033572: samba: 2:4.17.6+dfsg-1 has not reached testing after more than 10 days
Package: samba
Version: 2:4.17.5+dfsg-2
Severity: normal
Dear Maintainer,
I have noticed that even though 2:4.17.6+dfsg-1 has reached stable backports
(bullseye-backports)
it has not reached bookworm testing from more than 10 days.
This, even though it has build in unstable for all architecture that are
already in testing and I see no new RC critical bug to samba (maybe one
if its child packages?).
Is there a known issue which prevent the transitition?
Having a version in bullseye-backports newer than testing spam me with upgrade
available
while I cannot upgrade to bullseye-backports per it depends on older
python than my current 4.17.5 bookworm samba. This is minor but if could
be fixed would help lower maintainence burden.
Cheers,
Alban
-- Package-specific info:
* /etc/samba/smb.conf present, and attached
* /var/lib/samba/dhcp.conf not present
-- System Information:
Debian Release: 11.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable-debug'), (500, 'stable'), (100, 'unstable-debug'), (100,
'testing-debug'), (100, 'testing'), (90, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.0.0-0.deb11.6-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 samba depends on:
ii init-system-helpers 1.60
ii libbsd0 0.11.3-1
ii libc62.36-8
ii libcups2 2.4.2-2
ii libgnutls30 3.7.9-1
ii libldap-2.5-02.5.13+dfsg-2~bpo11+1
ii libldb2 2:2.6.1+samba4.17.5+dfsg-2
ii libpam-modules 1.4.0-9+deb11u1
ii libpam-runtime 1.4.0-9+deb11u1
ii libpopt0 1.18-2
ii libtalloc2 2.4.0-f2
ii libtasn1-6 4.16.0-2+deb11u1
ii libtdb1 1.4.8-2
ii libtevent0 0.14.1-1
ii passwd 1:4.13+dfsg1-1+b1
ii procps 2:3.3.17-5
ii python3 3.11.2-1
ii python3-dnspython2.3.0-1
ii python3-samba2:4.17.5+dfsg-2
ii samba-common 2:4.17.5+dfsg-2
ii samba-common-bin 2:4.17.5+dfsg-2
ii samba-libs 2:4.17.5+dfsg-2
ii tdb-tools1.4.7-2~bpo11+1
Versions of packages samba recommends:
pn attr
ii logrotate 3.18.0-2+deb11u1
ii python3-markdown3.4.1-2
pn samba-ad-provision
pn samba-dsdb-modules
pn samba-vfs-modules
Versions of packages samba suggests:
pn bind9
pn bind9utils
pn ctdb
pn ldb-tools
pn ntp | chrony
pn ufw
ii winbind 2:4.17.5+dfsg-2
-- no debconf information
#
# Sample configuration file for the Samba suite for Debian GNU/Linux.
#
#
# This is the main Samba configuration file. You should read the
# smb.conf(5) manual page in order to understand the options listed
# here. Samba has a huge number of configurable options most of which
# are not shown in this example
#
# Some options that are often worth tuning have been included as
# commented-out examples in this file.
# - When such options are commented with ";", the proposed setting
#differs from the default Samba behaviour
# - When commented with "#", the proposed setting is the default
#behaviour of Samba but the option is considered important
#enough to be mentioned here
#
# NOTE: Whenever you modify this file you should run the command
# "testparm" to check that you have not made any basic syntactic
# errors.
#=== Global Settings ===
[global]
## Browsing/Identification ###
# Change this to the workgroup/NT-domain name your Samba server will part of
workgroup = ILIADE
Networking
# The specific set of interfaces / networks to bind to
# This can be either the interface name or an IP address/netmask;
# interface names are normally preferred
; interfaces = 127.0.0.0/8 eth0
# Only bind to the named interfaces and/or networks; you must use the
# 'interfaces' option above to use this.
# It is recommended that you enable this feature if your Samba machine is
# not protected by a firewall or is a firewall itself. However, this
# option cannot handle dynamic or non-broadcast interfaces correctly.
; bind interfaces only = yes
Debugging/Accounting
# This tells Samba to use a separate log file for each machine
# that connects
log file = /var/log/samba/log.%m
# Cap the size of the individual log files (in KiB).
max log size = 1000
# We want Samba to only log to /var/log/samba/log.{smbd,nmbd}.
# Append syslog@1 if you want important messages to be sent to syslog too.
logging = file
# Do something sensible when Samba crashes: mail the admin a backtrace
panic action = /usr/share/samba/panic-action %d
### Authentication ###
#
Bug#942433: samba: Cannot mount share on samba3 server from samba4 client: protocol negotiation failed
On Mon, 31 Oct 2022 10:43:49 +0300 Michael Tokarev wrote: > Control: tag -1 + moreinfo > > Hi! > > This bug appears to be about an old samba version (4.11). > There were a few corner cases with old protocols negotiation > fixed meanwhile, including some bugs reported in the Debian BTS. > > Current 4.16 client can mount shares from older servers, including > old samba and windows XP, provided there's a way to enable older > protocols. > > It looks like what's left is a way for qemu slirp (usermode) > networking to be able to add an option to enable old protocols > when running smbd. And this is definitely a qemu job to do. > > What do you think? > > Thanks, > > /mjt > > mjt, it looks like you forgot to send your email to the two bug reporter, or did you send this email to the initial reporter Igor and the qemu user Jordi that hijacked this bug in another batch? Cheers, Alban
Bug#1031505: redmine: Install (upgrade) 5.x on Bullseye fails on NameError Redmine::Plugin
Forwarding to submitter per he was not included in the recipients (forwarding to the bug report does not forward to submitter): On Fri, 17 Feb 2023 23:48:18 +0100 Jakob Haufe > We discussed this in IRC (#debian-ruby in OFTC, feel free to pass by) > and couldn't reproduce the problem. > > We installed redmine 4.0 from buster backports and updated the VM to > bullseye, once by installing only the minimum set of packages from > backports and once by installing as much as possible from backports. > > Both installs and updates worked fine. > > To help investigate this further, could you please provide us with the > following: > > 1. Any plugins you have installed in redmine, either via the Debian > repository or manually. > 2. The output of apt-forktracer (from the package with the same name). > > Cheers, > sur5r > > -- > ceterum censeo microsoftem esse delendam. Indeed you probably have a redmine plugin that requires an upgrade to a version of this plugin that supports redmine5. Cheers, Alban
Bug#1029444: dmraid: remove force_load dm-raid45 not shipped by Debian
package dmraid fixed 1029444 1.0.0.rc16-12 thanks Le samedi 28 janvier 2023 à 07:43 +0100, László Böszörményi (GCS) a écrit : > On Sun, Jan 22, 2023 at 5:57 PM Alban Browaeys > wrote: > > Package: dmraid > > Version: 1.0.0.rc16-8+b1 > [...] > > on each Debian box with dmraid installed (here by suggestion from > > gparted), > > one gets a message at boot (from initrd stage): > > modprobe: module dm-raid45 not found in modules.dep > It has been fixed long time ago for Bookworm. For me it seems you > are > using Bullseye. > > > it has been 15 years since the issue has been reported and it was > > told to patch the kernel with alpha > > code in Debian bug #411172 . (there was also a patch included in > > the debian package to > > translate raid-45 calls to raid456 which is in the Debian kernel > > but it is told not to work in htis bug report > > - was dmraid 1.0.0.rc14-1). > > > > Is there any reason to ship an initramfs that request an out-of- > > tree module for all Debian users with dmraid installted ? > > > > May I request that the call to force_load dm-raid45 be removed for > > now and replaced by a force_load raid456 > > when support is implemented? > Can you confirm that when you have _up-to-date Bookworm_ running you > have this message? > > Regards, > Laszlo/GCS Indeed I reported this bug for the bullseye version. I mark this as fixed in version 1.0.0.rc16-12. Best regards, Alban
Bug#1029663: Fwd: Bug#993806: kodi: No audio on DVD playback, AC3 Support
Summarizing the AAC to AC3 issue with stable Debian. https://bugzilla.rpmfusion.org/show_bug.cgi?id=6000 tells that inital ffmpeg 4.4 support has to be added but is not enough. Ine has to also add https://github.com/xbmc/xbmc/pull/20678 ffmpeg: Set audio channel count on AVFrame #20678, kodi patch for to fix AAC to AC3 transcoding. I admit I am not sure I can reproduce with my setup (pipewire and only stereo devices) to try if it is enough (or even not already fixed in bullseye-backports). I tried but am unable to find how to "disabling AAC passthrough for Pulseaudio via pavucontrol" and "enabling the AC3 transcoding setting in Kodi". Could you be more specific about the steps? Cheers, Alban On Mon, 26 Sep 2022 22:48:36 +0200 Markus Koller wrote: > Hey Alban, > > I ended up switching to the Flatpak version of Kodi to avoid these issues, > so unfortunately I can't easily test (especially since I'm also using sid, > which I see is on an alpha version of Kodi 20 now). > > > How did you do AC3 to AAC transcoding (playing DVD with kodi 19?). > > It was the other way around, transcoding from AAC to AC3. > You can achieve that by disabling AAC passthrough for Pulseaudio via > pavucontrol, and enabling the AC3 transcoding setting in Kodi. > > IIRC it only affected source files with AAC tracks, normal AC3 passthrough > still worked. > > > Mind that upstream kodi ships ffmpeg 4.3.2 so maybe ffmpeg version > > above that one has a regression (since fixed in ffmpeg 5.1 because > > debian kodi 20 with debian ffmpeg 5.1 has DVD audio working). > > So maybe it was this debian ffmpeg 4.3.2 that you reverted to back > > then, hard to tell. > > I checked my dpkg logs but they don't go back far enough :( > FWIW the Flatpak version of Kodi 19.4-Matrix seems to ship with ffmpeg > 4.3.4. > > > (maybe pipewire supports passwthrough nowadays, hard to tell) > > It actually does! But I found it to be buggy (especially with E-AC3 and > DTS), so I'm staying on Pulseaudio for now. > > Greetings, > Markus
Bug#1029663: kodi: no audio when AAC to AC3 transcoding
package kodi fixed 1029663 2:20.0+dfsg-1 thanks Please close this bug report per ffmpeg 4.4 is not in any Debian release and kodi 19 which is in bullseye does not have this bug with buslleye ffmpeg 4.3. I mark this bug as fixed in kodi 20 as the commits to fix this bug with ffmpeg 4.4 are in kodi 20. But even kodi 19.1 and kodi 19.4 are not affected anymore since ffmpeg 5 has different packages then ffmpeg 4 in Debian. Cheers, Alban
Bug#1029663: kodi: no audio when AAC to AC3 transcoding
The upstream bug report log (before it was fixed with previously mentionned pull request) https://github.com/xbmc/xbmc/issues/20398 AC3 transcoding fails on Kodi 20 Cheers, Alban
Bug#1028434: kodi: FTBFS in bullseye (fatal error: date/tz.h: No such file or directory)
Sorted out that libdate-tz-embedded and libhowardhinnant-date-dev are the from the same source. On Thu, 26 Jan 2023 08:47:33 +0100 Alban Browaeys wrote: > date/tz.h: No such file or directory > > This date/tz.h comes from kodi source directory ./libdate-tz- > embedded/include/date/tz.h > > It is not included in the bullseye debian/rules but in the bullseye- > backports one it is by > DATE_COMPONENT = libdate-tz-embedded > KODI_OPTS=\ > (...) > -DDATE_INCLUDE_DIR:PATH=$(CURDIR)/$(DATE_COMPONENT)/include > > > override_dh_auto_configure: > (...) > dh_auto_configure -- $(KODI_OPTS) > > > > > > my pbuilder dh_auto_configure (bullseye build environment but building > bullseye-backports kodi 19.4): > dh_auto_configure -- -DVERBOSE=1 -DUSE_LTO=5 - > DCMAKE_BUILD_TYPE=RelWithDebInfo -DENABLE_AIRTUNES=ON - DENABLE_ALSA=ON > -DENABLE_AVAHI=ON -DENABLE_BLURAY=ON -DENABLE_CEC=ON -DENABLE_DBUS=ON - > DENABLE_DEBUGFISSION=OFF -DENABLE_DVDCSS=OFF -DENABLE_EVENTCLIENTS=ON - > DENABLE_INTERNAL_CROSSGUID=OFF -DENABLE_INTERNAL_DATE=OFF - > DENABLE_INTERNAL_FFMPEG=OFF -DENABLE_INTERNAL_KISSFFT=OFF - > DENABLE_MICROHTTPD=ON -DENABLE_MYSQLCLIENT=ON -DENABLE_NFS=ON - > DENABLE_OPTICAL=ON -DENABLE_PULSEAUDIO=ON -DENABLE_SMBCLIENT=ON - > DENABLE_UDEV=ON -DENABLE_UPNP=ON -DENABLE_VAAPI=ON -DENABLE_VDPAU=ON - > DENABLE_XSLT=ON - > DLIBDVDREAD_URL=tools/depends/target/libdvdread/libdvdread-$(grep > VERSION tools/depends/target/libdvdread/DVDREAD-VERSION | sed > 's/^[^=]*=//').tar.xz - > DLIBDVDNAV_URL=tools/depends/target/libdvdnav/libdvdnav-$(grep VERSION > tools/depends/target/libdvdnav/DVDNAV-VERSION | sed > 's/^[^=]*=//').tar.xz -DENABLE_LIRCCLIENT=ON -DNEON=False - > DCORE_PLATFORM_NAME="x11 wayland gbm" -DAPP_RENDER_SYSTEM=gl - > DDATE_LIBRARY_RELEASE:FILEPATH=/build/kodi- 19.4+dfsg2/lib/date/libdate- > tz.a -DDATE_INCLUDE_DIR:PATH=/build/kodi-19.4+dfsg2/libdate-tz- > embedded/include -DWITH_ARCH=x86_64-linux > > > > your dh_auto_configure: > dh_auto_configure -- -DVERBOSE=1 -DUSE_LTO=1 - > DCMAKE_BUILD_TYPE=RelWithDebInfo -DENABLE_AIRTUNES=ON - DENABLE_ALSA=ON > -DENABLE_AVAHI=ON -DENABLE_BLURAY=ON -DENABLE_CEC=ON -DENABLE_DBUS=ON - > DENABLE_DVDCSS=OFF -DENABLE_EVENTCLIENTS=ON - > DENABLE_INTERNAL_CROSSGUID=OFF -DENABLE_INTERNAL_FFMPEG=OFF - > DENABLE_MICROHTTPD=ON -DENABLE_MYSQLCLIENT=ON -DENABLE_NFS=ON - > DENABLE_OPTICAL=ON -DENABLE_PULSEAUDIO=ON -DENABLE_SMBCLIENT=ON - > DENABLE_UDEV=ON -DENABLE_UPNP=ON -DENABLE_VAAPI=ON -DENABLE_VDPAU=ON - > DENABLE_XSLT=ON -DDATE_URL=tools/depends/target/date/libdate-tz- $(grep > VERSION tools/depends/target/date/DATE-VERSION | sed > 's/^[^=]*=//').tar.xz - > DLIBDVDREAD_URL=tools/depends/target/libdvdread/libdvdread-$(grep > VERSION tools/depends/target/libdvdread/DVDREAD-VERSION | sed
Bug#1028434: kodi: FTBFS in bullseye (fatal error: date/tz.h: No such file or directory)
date/tz.h: No such file or directory This date/tz.h comes from kodi source directory ./libdate-tz- embedded/include/date/tz.h It is not included in the bullseye debian/rules but in the bullseye- backports one it is by DATE_COMPONENT = libdate-tz-embedded KODI_OPTS=\ (...) -DDATE_INCLUDE_DIR:PATH=$(CURDIR)/$(DATE_COMPONENT)/include override_dh_auto_configure: (...) dh_auto_configure -- $(KODI_OPTS) my pbuilder dh_auto_configure (bullseye build environment but building bullseye-backports kodi 19.4): dh_auto_configure -- -DVERBOSE=1 -DUSE_LTO=5 - DCMAKE_BUILD_TYPE=RelWithDebInfo -DENABLE_AIRTUNES=ON -DENABLE_ALSA=ON -DENABLE_AVAHI=ON -DENABLE_BLURAY=ON -DENABLE_CEC=ON -DENABLE_DBUS=ON - DENABLE_DEBUGFISSION=OFF -DENABLE_DVDCSS=OFF -DENABLE_EVENTCLIENTS=ON - DENABLE_INTERNAL_CROSSGUID=OFF -DENABLE_INTERNAL_DATE=OFF - DENABLE_INTERNAL_FFMPEG=OFF -DENABLE_INTERNAL_KISSFFT=OFF - DENABLE_MICROHTTPD=ON -DENABLE_MYSQLCLIENT=ON -DENABLE_NFS=ON - DENABLE_OPTICAL=ON -DENABLE_PULSEAUDIO=ON -DENABLE_SMBCLIENT=ON - DENABLE_UDEV=ON -DENABLE_UPNP=ON -DENABLE_VAAPI=ON -DENABLE_VDPAU=ON - DENABLE_XSLT=ON - DLIBDVDREAD_URL=tools/depends/target/libdvdread/libdvdread-$(grep VERSION tools/depends/target/libdvdread/DVDREAD-VERSION | sed 's/^[^=]*=//').tar.xz - DLIBDVDNAV_URL=tools/depends/target/libdvdnav/libdvdnav-$(grep VERSION tools/depends/target/libdvdnav/DVDNAV-VERSION | sed 's/^[^=]*=//').tar.xz -DENABLE_LIRCCLIENT=ON -DNEON=False - DCORE_PLATFORM_NAME="x11 wayland gbm" -DAPP_RENDER_SYSTEM=gl - DDATE_LIBRARY_RELEASE:FILEPATH=/build/kodi-19.4+dfsg2/lib/date/libdate- tz.a -DDATE_INCLUDE_DIR:PATH=/build/kodi-19.4+dfsg2/libdate-tz- embedded/include -DWITH_ARCH=x86_64-linux your dh_auto_configure: dh_auto_configure -- -DVERBOSE=1 -DUSE_LTO=1 - DCMAKE_BUILD_TYPE=RelWithDebInfo -DENABLE_AIRTUNES=ON -DENABLE_ALSA=ON -DENABLE_AVAHI=ON -DENABLE_BLURAY=ON -DENABLE_CEC=ON -DENABLE_DBUS=ON - DENABLE_DVDCSS=OFF -DENABLE_EVENTCLIENTS=ON - DENABLE_INTERNAL_CROSSGUID=OFF -DENABLE_INTERNAL_FFMPEG=OFF - DENABLE_MICROHTTPD=ON -DENABLE_MYSQLCLIENT=ON -DENABLE_NFS=ON - DENABLE_OPTICAL=ON -DENABLE_PULSEAUDIO=ON -DENABLE_SMBCLIENT=ON - DENABLE_UDEV=ON -DENABLE_UPNP=ON -DENABLE_VAAPI=ON -DENABLE_VDPAU=ON - DENABLE_XSLT=ON -DDATE_URL=tools/depends/target/date/libdate-tz-$(grep VERSION tools/depends/target/date/DATE-VERSION | sed 's/^[^=]*=//').tar.xz - DLIBDVDREAD_URL=tools/depends/target/libdvdread/libdvdread-$(grep VERSION tools/depends/target/libdvdread/DVDREAD-VERSION | sed 's/^[^=]*=//').tar.xz - DLIBDVDNAV_URL=tools/depends/target/libdvdnav/libdvdnav-$(grep VERSION tools/depends/target/libdvdnav/DVDNAV-VERSION | sed 's/^[^=]*=//').tar.xz -DENABLE_LIRCCLIENT=ON -DNEON=False - DCORE_PLATFORM_NAME="x11 wayland gbm" -DAPP_RENDER_SYSTEM=gl Note the missing: -DDATE_LIBRARY_RELEASE:FILEPATH=/build/kodi- 19.4+dfsg2/lib/date/libdate-tz.a -DDATE_INCLUDE_DIR:PATH=/build/kodi- 19.4+dfsg2/libdate-tz-embedded/include Those were added to the bullseye-backports branch https://salsa.debian.org/multimedia-team/kodi-media-center/kodi/-/commit/e7b14cb2206bebd5668f33a5e076fde124721898 So maybe this should be backported to bullseye versoin as date/tz.h is not provided by any Debian package in bullseye (and maybe in unrelated libhowardhinnant-date-dev in bullseye-backports and above). Cheers, Alban
Bug#1029663: Fwd: Bug#993806: kodi: No audio on DVD playback, AC3 Support
Summarizing the AAC to AC3 issue with stable Debian. https://bugzilla.rpmfusion.org/show_bug.cgi?id=6000 tells that inital ffmpeg 4.4 support has to be added but is not enough. Ine has to also add https://github.com/xbmc/xbmc/pull/20678 ffmpeg: Set audio channel count on AVFrame #20678, kodi patch for to fix AAC to AC3 transcoding. I admit I am not sure I can reproduce with my setup (pipewire and only stereo devices) to try if it is enough (or even not already fixed in bullseye-backports). I tried but am unable to find how to "disabling AAC passthrough for Pulseaudio via pavucontrol" and "enabling the AC3 transcoding setting in Kodi". Could you be more specific about the steps? Cheers, Alban On Mon, 26 Sep 2022 22:48:36 +0200 Markus Koller wrote: > Hey Alban, > > I ended up switching to the Flatpak version of Kodi to avoid these issues, > so unfortunately I can't easily test (especially since I'm also using sid, > which I see is on an alpha version of Kodi 20 now). > > > How did you do AC3 to AAC transcoding (playing DVD with kodi 19?). > > It was the other way around, transcoding from AAC to AC3. > You can achieve that by disabling AAC passthrough for Pulseaudio via > pavucontrol, and enabling the AC3 transcoding setting in Kodi. > > IIRC it only affected source files with AAC tracks, normal AC3 passthrough > still worked. > > > Mind that upstream kodi ships ffmpeg 4.3.2 so maybe ffmpeg version > > above that one has a regression (since fixed in ffmpeg 5.1 because > > debian kodi 20 with debian ffmpeg 5.1 has DVD audio working). > > So maybe it was this debian ffmpeg 4.3.2 that you reverted to back > > then, hard to tell. > > I checked my dpkg logs but they don't go back far enough :( > FWIW the Flatpak version of Kodi 19.4-Matrix seems to ship with ffmpeg > 4.3.4. > > > (maybe pipewire supports passwthrough nowadays, hard to tell) > > It actually does! But I found it to be buggy (especially with E-AC3 and > DTS), so I'm staying on Pulseaudio for now. > > Greetings, > Markus
Bug#1029663: Fwd: Bug#993806: kodi: No audio on DVD playback, AC3 Support
Summarizing the AAC to AC3 issue with stable Debian. https://bugzilla.rpmfusion.org/show_bug.cgi?id=6000 tells that inital ffmpeg 4.4 support has to be added but is not enough. Ine has to also add https://github.com/xbmc/xbmc/pull/20678 ffmpeg: Set audio channel count on AVFrame #20678, kodi patch for to fix AAC to AC3 transcoding. I admit I am not sure I can reproduce with my setup (pipewire and only stereo devices) to try if it is enough (or even not already fixed in bullseye-backports). I tried but am unable to find how to "disabling AAC passthrough for Pulseaudio via pavucontrol" and "enabling the AC3 transcoding setting in Kodi". Could you be more specific about the steps? Cheers, Alban On Mon, 26 Sep 2022 22:48:36 +0200 Markus Koller wrote: > Hey Alban, > > I ended up switching to the Flatpak version of Kodi to avoid these issues, > so unfortunately I can't easily test (especially since I'm also using sid, > which I see is on an alpha version of Kodi 20 now). > > > How did you do AC3 to AAC transcoding (playing DVD with kodi 19?). > > It was the other way around, transcoding from AAC to AC3. > You can achieve that by disabling AAC passthrough for Pulseaudio via > pavucontrol, and enabling the AC3 transcoding setting in Kodi. > > IIRC it only affected source files with AAC tracks, normal AC3 passthrough > still worked. > > > Mind that upstream kodi ships ffmpeg 4.3.2 so maybe ffmpeg version > > above that one has a regression (since fixed in ffmpeg 5.1 because > > debian kodi 20 with debian ffmpeg 5.1 has DVD audio working). > > So maybe it was this debian ffmpeg 4.3.2 that you reverted to back > > then, hard to tell. > > I checked my dpkg logs but they don't go back far enough :( > FWIW the Flatpak version of Kodi 19.4-Matrix seems to ship with ffmpeg > 4.3.4. > > > (maybe pipewire supports passwthrough nowadays, hard to tell) > > It actually does! But I found it to be buggy (especially with E-AC3 and > DTS), so I'm staying on Pulseaudio for now. > > Greetings, > Markus
Bug#993806: Fwd: Bug#993806: kodi: No audio on DVD playback, AC3 Support
package kodi clone 993806 -1 submitter -1 Markus Koller retitle -1 kodi: no audio when AAC to AC3 transcoding thanks I clone the bug report to account for the fact the AAC to AC3 transcoding is a recent issue while the DVD audio missing is an older one on Debian. So different bugs. On Mon, 26 Sep 2022 22:48:36 +0200 Markus Koller wrote: > Hey Alban, > > I ended up switching to the Flatpak version of Kodi to avoid these issues, > so unfortunately I can't easily test (especially since I'm also using sid, > which I see is on an alpha version of Kodi 20 now). > > > How did you do AC3 to AAC transcoding (playing DVD with kodi 19?). > > It was the other way around, transcoding from AAC to AC3. > You can achieve that by disabling AAC passthrough for Pulseaudio via > pavucontrol, and enabling the AC3 transcoding setting in Kodi. > > IIRC it only affected source files with AAC tracks, normal AC3 passthrough > still worked. > > > Mind that upstream kodi ships ffmpeg 4.3.2 so maybe ffmpeg version > > above that one has a regression (since fixed in ffmpeg 5.1 because > > debian kodi 20 with debian ffmpeg 5.1 has DVD audio working). > > So maybe it was this debian ffmpeg 4.3.2 that you reverted to back > > then, hard to tell. > > I checked my dpkg logs but they don't go back far enough :( > FWIW the Flatpak version of Kodi 19.4-Matrix seems to ship with ffmpeg > 4.3.4. > > > (maybe pipewire supports passwthrough nowadays, hard to tell) > > It actually does! But I found it to be buggy (especially with E-AC3 and > DTS), so I'm staying on Pulseaudio for now. > > Greetings, > Markus
Bug#1029444: dmraid: remove force_load dm-raid45 not shipped by Debian
I found out that dmraid will be removed with trixie. So you might want to let this bitrot. This is not critical and will be fixed either way by dmraid removal. Still, this would be fine for bookworm not to have this error at boot. Cheers, Alban
Bug#1029444: dmraid: remove force_load dm-raid45 not shipped by Debian
Package: dmraid Version: 1.0.0.rc16-8+b1 Severity: normal Dear Maintainer, on each Debian box with dmraid installed (here by suggestion from gparted), one gets a message at boot (from initrd stage): modprobe: module dm-raid45 not found in modules.dep it has been 15 years since the issue has been reported and it was told to patch the kernel with alpha code in Debian bug #411172 . (there was also a patch included in the debian package to translate raid-45 calls to raid456 which is in the Debian kernel but it is told not to work in htis bug report - was dmraid 1.0.0.rc14-1). Is there any reason to ship an initramfs that request an out-of-tree module for all Debian users with dmraid installted ? May I request that the call to force_load dm-raid45 be removed for now and replaced by a force_load raid456 when support is implemented? This message is spurious and can cause confusion as a red herring that something is wrong when all is fine. dm-raid45 is not supported by Debian. And shipping code that has seen no update since 2009 in every dmraid install seems a bit dangerous either way. Users that install this dm-raid456 modules can add dm-raid45 into /etc/initramfs-tools/modules either way. Best regards, Alban -- Package-specific info: --- dmraid -r -vvv output --- dmraid -s -vv output --- /proc/partitions: major minor #blocks name 80 976762584 sda 811024000 sda1 82 266240 sda2 83 131072 sda3 84 66701052 sda4 85 650240 sda5 86 167772160 sda6 87 712990720 sda7 88 17100800 sda8 8 16 15638616 sdb 70 83212 loop0 71 64748 loop1 72 64792 loop2 73 40600 loop3 74 56944 loop4 75 168712 loop5 76 40576 loop6 77 93888 loop7 79 56948 loop9 78 4 loop8 7 10 51024 loop10 7 16 266968 loop16 7 13 446776 loop13 7 11 166776 loop11 7 12 50812 loop12 7 15 140432 loop15 7 14 140560 loop14 110 951800 sr0 1111048575 sr1 --- initrd.img-6.0.0-0.deb11.6-amd64: gzip: /boot/initrd.img-6.0.0-0.deb11.6-amd64: not in gzip format cpio: premature end of archive --- /proc/modules: dm_mirror 28672 0 - Live 0x dm_region_hash 24576 1 dm_mirror, Live 0x dm_log 20480 2 dm_mirror,dm_region_hash, Live 0x dm_snapshot 53248 0 - Live 0x dm_bufio 40960 1 dm_snapshot, Live 0x dm_mod 180224 4 dm_mirror,dm_log,dm_snapshot,dm_bufio, Live 0x --- /proc/cmdline initrd=\2b483dcbcecb6729df407c5b5382b0d1\6.0.0-0.deb11.6-amd64\initrd.img-6.0.0-0.deb11.6-amd64 root=UUID=2a13ddb2-5a46-4180-bbc9-8f4044369dd1 ro zswap.enabled=Y zswap.zpool=zsmalloc zswap.compressor=lz4 zswap.max_pool_percent=20 cgroup_enable=memory cgroup_memory=1 swapaccount=1 log_buf_len=4M i8042.kbdreset=1 crashkernel=auto quiet splash crashkernel=384M-:128M systemd.machine_id=2b483dcbcecb6729df407c5b5382b0d1 -- System Information: Debian Release: 11.6 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), (500, 'oldstable'), (90, 'unstable'), (90, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-0.deb11.6-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dmraid depends on: ii dmsetup 2:1.02.185-2 ii libc62.36-5 ii libdmraid1.0.0.rc16 1.0.0.rc16-8+b1 ii libselinux1 3.4-1 ii libsepol13.1-1 ii udev 247.3-7+deb11u1 dmraid recommends no packages. dmraid suggests no packages. -- no debconf information
Bug#1029052: black: might want to strengthen the dependency on python3-click to the 8 release in bookworm
Package: black Version: 22.12.0-1 Severity: normal Dear Maintainer, I ran ansible-lint which depends on black. It outputted a warning: WARNING Ignore loading rule from /usr/lib/python3/dist-packages/ansiblelint/rules/jinja.py due to cannot import name 'ParameterSource' from 'click.core' (/usr/lib/python3/dist-packages/click/core.py) If I upgrade from python3-lick 7.1.2-1 bullseye to bookworm 8.1.3-2 this warning disappear. ansible-lint has no direct dependency on python3-click. This dependency is pulled via ansible-lint dependency on black. Cheers, Alban -- System Information: Debian Release: 11.6 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), (500, 'oldstable'), (90, 'unstable'), (90, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-0.deb11.2-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages black depends on: ii python33.10.6-1 ii python3-click 8.1.3-2 ii python3-mypy-extensions0.4.3-2 ii python3-pathspec 0.10.1-1 ii python3-pkg-resources 59.6.0-1.2 ii python3-platformdirs 2.5.2-1 ii python3-tomli 1.2.2-2~bpo11+1 ii python3-typing-extensions 3.7.4.3-1 black recommends no packages. Versions of packages black suggests: pn python-black-doc -- no debconf information
Bug#962844: mdadm: Assembling RAID using IMSM in initrd fails due to lack of module efivarfs
On Sun, 7 Feb 2021 20:32:08 -0800 Felix Lechner wrote: > Hi Chris, > > On Sun, Feb 7, 2021 at 9:22 AM Chris Hofstaedtler wrote: > > > > friendly ping here, are you planning to fix this for bullseye? > > Thanks for the reminder! I will probably include efivars in the next > couple of days. > > Kind regards > Felix > You probably want to include efivarfs (efivars is obsolete and removed in linux kernel 6). Thus the current patch has no effect on bullseye- backports, testing and up. efivarfs is available since linux 3.10. So maybe including efivarfs only is a better option (since with efivars being removed I get a warning at boot from initramfs that it cannot load unavailable efivars module. Cheers, Alban
Bug#1026170: barrier: Do you plan to switch from debauchee upstream to input-leap one?
Package: barrier Version: 2.3.3+dfsg-1.1 Severity: wishlist A group of developper forked barrier to a new Github repository: https://github.com/input-leap/input-leap Note that the built binaries are still named barrier, barrierc, barriers so the package should conflict if a new debian package name is created. Maybe a new name for those binaries could be asked for, I have not checkd the issue tracker for if it was already asked for. Cheers, Alban -- System Information: Debian Release: 11.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), (90, 'testing-debug'), (90, 'unstable'), (90, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-0.deb11.2-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 barrier depends on: ii libavahi-compat-libdnssd1 0.8-5+deb11u1 ii libc6 2.36-4 ii libgcc-s1 12.2.0-9 ii libqt5core5a 5.15.4+dfsg-5 ii libqt5gui5 5.15.4+dfsg-5 ii libqt5network5 5.15.4+dfsg-5 ii libqt5widgets5 5.15.4+dfsg-5 ii libssl1.1 1.1.1n-0+deb11u3 ii libstdc++6 12.2.0-9 ii libx11-6 2:1.8.1-2 ii libxext6 2:1.3.3-1.1 ii libxi6 2:1.8-1+b1 ii libxinerama1 2:1.1.4-2 ii libxrandr2 2:1.5.2-2+b1 ii libxtst6 2:1.2.3-1 ii openssl1.1.1n-0+deb11u3 barrier recommends no packages. barrier suggests no packages. -- no debconf information
Bug#1025785: dkms: error message that tells that signing will not be made not outputted
Package: dkms Version: 3.0.8-3 Severity: normal When dkms filas to find the sign-file if I add "set -x" in dkms script I get: + echo 'Binary /usr/lib/linux-kbuild-6.0.0-0.deb11/scripts/sign-file not found, modules won'\''t be signed' on hte console. But without set -x I get no message. It makes it hard to know what was wrong. Console on acpi-cal-dkms install: " Preparing to unpack .../acpi-call-dkms_1.1.0-6_all.deb ... Unpacking acpi-call-dkms (1.1.0-6) ... Setting up acpi-call-dkms (1.1.0-6) ... Loading new acpi-call-1.1.0 DKMS files... Building for 6.0.0-0.deb11.2-amd64 Building initial module for 6.0.0-0.deb11.2-amd64 Done. acpi_call.ko: Running module version sanity check. - Original module - No original module exists within this kernel - Installation - Installing to /lib/modules/6.0.0-0.deb11.2-amd64/updates/dkms/ depmod... " /var/lib/dkms/acpi-call/kernel-6.0.0-0.deb11.2-amd64-x86_64/log/make.log " DKMS make.log for acpi-call-1.1.0 for kernel 6.0.0-0.deb11.2-amd64 (x86_64) Fri Dec 9 02:23:27 CET 2022 make: Entering directory '/usr/src/linux-headers-6.0.0-0.deb11.2-amd64' CC [M] /var/lib/dkms/acpi-call/1.1.0/build/acpi_call.o MODPOST /var/lib/dkms/acpi-call/1.1.0/build/Module.symvers CC [M] /var/lib/dkms/acpi-call/1.1.0/build/acpi_call.mod.o LD [M] /var/lib/dkms/acpi-call/1.1.0/build/acpi_call.ko BTF [M] /var/lib/dkms/acpi-call/1.1.0/build/acpi_call.ko Skipping BTF generation for /var/lib/dkms/acpi-call/1.1.0/build/acpi_call.ko due to unavailability of vmlinux make: Leaving directory '/usr/src/linux-headers-6.0.0-0.deb11.2-amd64' " Cheers, Alban -- System Information: Debian Release: 11.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), (500, 'oldstable'), (90, 'unstable-debug'), (90, 'testing-debug'), (90, 'unstable'), (90, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-0.deb11.2-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dkms depends on: ii build-essential12.9 ii clang-11 [c-compiler] 1:11.0.1-2 ii dctrl-tools2.24-3+b1 ii dh-dkms3.0.8-3 ii dpkg-dev 1.20.12 ii gcc [c-compiler] 4:10.2.1-1 ii gcc-10 [c-compiler]10.2.1-6 ii gcc-11 [c-compiler]11.3.0-5 ii gcc-9 [c-compiler] 9.3.0-22 ii kmod 28-1 ii lsb-release11.1.0 ii make 4.3-4.1 ii patch 2.7.6-7 Versions of packages dkms recommends: ii fakeroot 1.25.3-1.1 ii linux-headers-amd64 [linux-headers-generic] 6.0.3-1~bpo11+1 ii sudo 1.9.5p2-3 Versions of packages dkms suggests: ii e2fsprogs 1.46.2-2 ii menu 2.1.48 -- no debconf information
Bug#1025783: dkms: n isnging per the sign-file is not found - wrong kernielver for kbuild linux
Package: dkms
Version: 3.0.8-3
Severity: important
Dear Maintainer,
When I install a dkms module the /var/lib/dkms MOK is not created and no
signing happens at build time.
Debugging with set -x the dkms script
dkms prepare_signing step here fails per:
+ module=acpi-call
+ module_version=1.1.0
+ kernelver=6.0.0-0.deb11.2-amd64
+ arch=x86_64
+ do_build
+ prepare_signing
+ '[' '!' '' ']'
+ case "$running_distribution" in
+ sign_file=/usr/lib/linux-kbuild-6.0.0-0.deb11/scripts/sign-file
+ echo 'Sign command: /usr/lib/linux-kbuild-6.0.0-0.deb11/scripts/sign-file'
+ [[ ! -f /usr/lib/linux-kbuild-6.0.0-0.deb11/scripts/sign-file ]]
+ echo 'Binary /usr/lib/linux-kbuild-6.0.0-0.deb11/scripts/sign-file not found,
modules won'\''t be signed'
+ return
+ prepare_build
ie the kernel path is wrong (kernelvers set to linux-kbuild-6.0.0-0.deb11
instead of linux-kbuild-6.0).
The signing script is correctly available in:
/usr/lib/linux-kbuild-6.0/scripts/sign-file.
So the MOK is not generated and the dkms modules are not signed.
iNote that upstream added a workaround for dkms modules built against local
kernel source
from user build.
https://github.com/dell/dkms/commit/a6cb5540f191c427d19af90c7b518be674921775
This may workaround this bug has
/lib/modules/6.0.0-0.deb11.2-amd64/build/scripts/sign-file
also points to this script. Still the debian specific code does not work
(though once the upstream
fallback will be in debian, this issue will not be important anymore).
uname -a
Linux cyclope 6.0.0-0.deb11.2-amd64 #1 SMP PREEMPT_DYNAMIC Debian
6.0.3-1~bpo11+1 (2022-10-29) x86_64 GNU/Linux
I don't know how to generate the string linux-kbuild-6.0 thus this bug report.
dkms does
debian* )
sign_file="/usr/lib/linux-kbuild-${kernelver%.*}/scripts/sign-file"
Cheers,
Alban
-- System Information:
Debian Release: 11.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable-debug'), (500, 'stable'), (500, 'oldstable'), (90, 'unstable-debug'),
(90, 'testing-debug'), (90, 'unstable'), (90, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.0.0-0.deb11.2-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages dkms depends on:
ii build-essential12.9
ii clang-11 [c-compiler] 1:11.0.1-2
ii dctrl-tools2.24-3+b1
ii dh-dkms3.0.8-3
ii dpkg-dev 1.20.12
ii gcc [c-compiler] 4:10.2.1-1
ii gcc-10 [c-compiler]10.2.1-6
ii gcc-11 [c-compiler]11.3.0-5
ii gcc-9 [c-compiler] 9.3.0-22
ii kmod 28-1
ii lsb-release11.1.0
ii make 4.3-4.1
ii patch 2.7.6-7
Versions of packages dkms recommends:
ii fakeroot 1.25.3-1.1
ii linux-headers-amd64 [linux-headers-generic] 6.0.3-1~bpo11+1
ii sudo 1.9.5p2-3
Versions of packages dkms suggests:
ii e2fsprogs 1.46.2-2
ii menu 2.1.48
-- no debconf information
Bug#989463: provide /var/lib/shim-signed/mok/MOK.(priv|pem|der)
dkms in bullseye has a sign script that expect the mok key to be in
/root (not /var/lib/dkms/:
dkms: /etc/dkms/sign_helper.sh
/lib/modules/"$1"/build/scripts/sign-file sha512 /root/mok.priv /root/mok.der
"$2"
dkms in bookworm has no sign_tool script anymore but from
https://salsa.debian.org/debian/dkms/-/blob/debian/3.0.8-3/dkms.in via
do_build then preapre_signing it sets sign_file:
debian* )
sign_file="/usr/lib/linux-kbuild-${kernelver%.*}/scripts/sign-file"
and a MOK location (and also generate this MOK if mok_singing_key is
not defined in /etc/dkms/framework.conf):
if [[ -z "${mok_signing_key}" ]]; then
# No custom key specified, use the default key created by
update-secureboot-policy for Ubuntu
# Debian's update-secureboot-policy has no --new-key option
case "$running_distribution" in
ubuntu* )
mok_signing_key="/var/lib/shim-signed/mok/MOK.priv"
mok_certificate="/var/lib/shim-signed/mok/MOK.der"
(...)
if [ ! "${mok_signing_key}" ]; then
mok_signing_key="/var/lib/dkms/mok.key"
fi
echo "Signing key: $mok_signing_key"
if [ ! "${mok_certificate}" ]; then
mok_certificate="/var/lib/dkms/mok.pub"
fi
echo "Public certificate (MOK): $mok_certificate"
# scripts/sign-file.c in kernel source also supports using
"pkcs11:..." as private key
if [[ "$mok_signing_key" != "pkcs11:"* ]] && ( [ ! -f
"$mok_signing_key" ] || [ ! -f "$mok_certificate" ] ); then
echo "Certificate or key are missing, generating self signed
certificate for MOK..."
openssl req -new -x509 -nodes -days 36500 -subj "/CN=DKMS
module signing key" \
-newkey rsa:2048 -keyout "$mok_signing_key" \
-outform DER -out "$mok_certificate" > /dev/null 2>&1
fi
https://salsa.debian.org/debian/dkms/-/blob/debian/3.0.8-3/dkms_framework.conf
# Location of the key and certificate files used for Secure boot.
# mok_signing_key can also be a "pkcs11:..." string for PKCS#11 engine,
as
# long as the sign_file program supports it.
# (default: /var/lib/dkms):
# mok_signing_key=/var/lib/dkms/mok.key
# mok_certificate=/var/lib/dkms/mok.pub
Thus for Debian the the MOK key is generated by dkms on first dkms
build, in /var/lib/dkms, or points the mok_signing_key and
mok_signing_certificate defined by the user in /etc/dkms/framework.conf
So I conclude that the dkms part is nearly done. Only it does not work
(at least on my box due to dkms looking for the sign-file kernel scipt
at the wrong location) but the most critical issue is that the way it
is done it is likely to break interactivity (it will ask on standard
input for the key password while running dkms build, but what if dkms
build is called while installing a module dkms package, or in a
graphical package manager).
At least the way it is done in ubuntu we have debhelper steps in shim-
signed to ask for the password (and they are already there in debian
too).
I believe dkms is not the best suited to manage the MOK generation.
shim-signed is a better fit.
Dkms modules signing is another issue. Handling it in dkms at module
build step is fine and should be kept. But when a new MOK key is
generated or replaced by a new one the dkms modules should be signed
anew with this new key. And dkms does not look like the best place to
handle that use case.
Cheers,
Alban
NB: The dkms prepare_signing step here fails per:
+ prepare_signing
+ '[' '!' '' ']'
+ case "$running_distribution" in
+ sign_file=/usr/lib/linux-kbuild-6.0.0-0.deb11/scripts/sign-file
+ echo 'Sign command: /usr/lib/linux-kbuild-6.0.0-0.deb11/scripts/sign-
file'
+ [[ ! -f /usr/lib/linux-kbuild-6.0.0-0.deb11/scripts/sign-file ]]
+ echo 'Binary /usr/lib/linux-kbuild-6.0.0-0.deb11/scripts/sign-file
not found, modules won'\''t be signed'
+ return
ie the kernel path is wrong. The script is available in:
/usr/lib/linux-kbuild-6.0/scripts/sign-file.
So the MOK is not generated and the dkms modules are not signed.
Bug#989463: provide /var/lib/shim-signed/mok/MOK.(priv|pem|der)
On Thu, 18 Nov 2021 13:32:58 +0100 Thomas Goirand wrote: > On 11/18/21 7:15 AM, Tomas Pospisek wrote: > > On Thu, 18 Nov 2021, Thomas Goirand wrote: > > > >> On 11/17/21 11:01 AM, Tomas Pospisek wrote: (...) > >> Hopefully, we can have the automation to sign DKMS modules in a non-leaf > >> package. I would strongly suggest we get a package with a very explicit > >> name in it, like "dkms-automatic-mok-signing" so it would do the work. I > >> would absolutely *not* go the path of disabling secure boot when a DKMS > >> module gets installed... > > > > Since I have not looked further I am *guessing* that Ubuntu does the > > automatic creation of the MOK key in the shim-signed package. So I think > > it should be possible to lift Ubuntu's work out of there and also put it > > into the shim-signed package, into postinst or so. > > > > *t > > As I understand, doing updates of shim-signed requires a signature from > Microsoft, so probably it's not the best place to do some change. https://salsa.debian.org/efi-team/shim-signed/-/tree/master/ The efi binaries are signed but not the package itself. Modifying the package postinst and its update-secureboot-policy script are fine. > > As for module automatic signatures, maybe this could go into the dkms > package itself, with some kind of configuration? Again, just a > suggestion... :) > https://git.launchpad.net/~ubuntu-core-dev/shim/+git/shim-signed/tree/openssl.cnf https://git.launchpad.net/~ubuntu-core-dev/shim/+git/shim-signed/tree/update-secureboot-policy This ubuntu update-secureboot-policy has a --new-key flag to generate the MOK in /var/lib/shim-signed/mok/. https://git.launchpad.net/~ubuntu-core-dev/shim/+git/shim-signed/tree/debian/shim-signed.postinst calls update-secureboot-policy --new-key on configure. It also sign the dkms modules. Cheers, Alban
Bug#909015: abiword: Crashes on startup with GLib-ERROR
> this crash seems to be caused by a broken opengl configuration.
> It could still be seen with buster when e.g. someone has the
> nvidia-driver-libs-nonglvnd installed without the kernel module
loaded.
>
> Unfortunately there is no output at stdout that would point
> the user to that direction. Instead the application just crashes.
>
> With attached patch the cogl initialization would at least just fail
and
> clutter could write an error message to stdout.
> Unable to initialize Clutter: Unable to initialize the Clutter
backend: no available drivers found.
>
> Kind regards,
> Bernhard
Thanks for your work !
Note, your patch should limit itself to initialize num_extensions to
zero. Seems it was enough to fix the issue on your setup.
The other parts of the patch touches the gles not the gl code so it
does not run on your test setup. (ie gles is not run if nvidia GLX is
involved only gl. The gdb output you pasted to the bug report shows it:
#6 0xb5e46426 in _cogl_driver_update_features (ctx=0x988688, error=0xbfeecfa8)
at driver/gl/gl/cogl-driver-gl.c:380
).
Maybe a patch local to debian would do per upstream is archived
https://discourse.gnome.org/t/retiring-clutter-and-friends/8949 "
Clutter, Cogl, Clutter-GTK, and Clutter-GStreamer will be moved to the
Archive group in GitLab 3 once GNOME 42 is released in March. You won’t
be able to file new issues, or open new merge requests. No new releases
will be made.
ebassi Emmanuele Bassi GNOME Team Feb 16 2022
"
If your are at ease with gitlab you could submit a Merge Request
to https://salsa.debian.org/gnome-team/cogl/-/tree/debian/master as a
patch file under debian/patches.
Best bet for abiword is to move out of clutter and clutter-gtk to fix
this issue (as the abiword stack trace the crashes happens in the call
gtk_clutter_init
#17 0xb60f65f2 in gtk_clutter_init (argc=0xbfeed254, argv=0xbfeed17c) at
./gtk-clutter-util.c:233
libabiword-3.0 3.0.5~dfsg-3.2 in bookworm does not depend on libclutter (thus
libcogl20) anymore.
bullseye libabiword-3.0 3.0.4~dfsg-3 still does thought.
The clutter-gtk library was included in abiword as it is a dependency of
libchamplain-gtk (which abiword
be linked against optionaly).
The abiword debian package stopped requiring libchamplain-gtk-0.12-dev in
abiword 3.0.5~dfsg-2 per
https://salsa.debian.org/debian/abiword/-/blob/debian/3.0.5_dfsg-2/debian/control
thus the binary does not link to libchamplain-gtk anymore since libabiword-3.0
3.0.5~dfsg-2.
Note that if one rebuild the package and has libchamplain-gtk-0.12-dev the
clutter gtk dependency will
come back per champlain-gtk is not explicitly disabled in the abiword
debian/rules.
https://salsa.debian.org/debian/abiword/-/blob/debian/latest/src/wp/ap/gtk/ap_UnixApp.cpp#L1300
#ifdef WITH_CHAMPLAIN
ClutterInitError err = gtk_clutter_init (, );
if (err != CLUTTER_INIT_SUCCESS) {
g_warning("clutter failed %d, get a life.", err);
}
#endif
There is no logged output from abiword about the crash because to get
clutter/cogl debug output
one has to set an environment variables
https://wiki.gnome.org/Projects/Clutter/Profiling
Setting COGL_DEBUG=all will output a lot of debug output (sadly Debian
libclutter-1.0 is built with debug at
minimum so CLUTTER_DEBUG=all does not give clutter debug messages).
Best Regards,
Alban
Bug#1025516: bugs.debian.org: affects from a library bug report against an application cannot be limited to a version
Package: bugs.debian.org Severity: wishlist I would like to leave a bug report with its "affects" mark but version this one. This as a bug report (#909015) against a libcogl20 issue which is marked as "affects" abiword per abiword crashes due to this libcogl20 issue (but only on specific setups). It turns out that abiword (in fact libabiword-3.0) does not link to clutter/cogl (via its libchamplain-gtk-0.12-dev build depedency) anymore in bookworm ie since libabiword-3.0 3.0.5~dfsg-2. But I see no mean to set thhis libcogl20 bug as affects libabiword-3.0 but only below the 3.0.5~dfsg-2 version. PS: an extreme use case would be to be able to set affects an application but on multiple versions range (ie only not all versions). Or maybe affects should simply not get used to tag an application as affected by a library bug. Your call. Best regards, Alban
Bug#1025500: libvpl-dev: Shouldn't libvpl-dev depends on its library libvp2.
Package: libvpl-dev Version: 2022.2.4-1 Severity: important Dear Maintainer, If I install libvp-dev and rebuild handbrake with --enable-qsv the build fails. I have to also install libvp2 by hand (and will have to add both to the build-depends to submit a patch if so). All other -dev packages in Debian that I lloked at depends on their library pacakge but not yours. From a google search, I have not found the Debian policy requirement for that though. Note that other pacakges depends on hte exact same versoin of the libaray and dev package. Probably vi a dh helper. The expected outcome is that with adding libvpx-dev to the build depends of handbrake would be enough for it to build and run against libvp2 too without having to hardcode this dependency. Cheers, Alban -- System Information: Debian Release: 11.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), (90, 'testing-debug'), (90, 'unstable'), (90, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-0.deb11.2-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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#931591: Buster: upgraded Handbrake crashes on encode with custom preset
On Wed, 14 Aug 2019 16:38:13 -0700 Seth Foley
wrote:
> Installed gdb, updated sources, installed the two debug symbol
packages,
> and ran those commands. (I had not rebooted since the crash on
Tuesday.)
>
> The output of coredumpctl is attached.
>
> I also copied the core dump file in case it's wanted later.
>
> Thanks, --SF
Do you by any change know the path name to this external (5 TB) disk ?
It is probably /media// so the output of "lsblk -f" would do.
Or if you selected a subfolder on this external drive partition the
name of this subfolder.
It could be your system encoding is not UTF-8. "locale" command output
in your user session would help. Though debuggus output your system
locale as en_US.UTF-8 so unlikely. Still this output may give a clue.
I believe that handbrake did not support your destination directory
name (or file name) and thus bailed out and the job ended up with no
filenname set as destination. Thus the crash in ffmpeg code.
Or maybe the external drive partition was read only due to an hardware
issue, and handbrake bailed out due to that.
Also the bug may be already fixed (hard to tell without a reproducer),
if you still have the setup could you retry (you can downgrade
handbrake by installing a downloaded buster deb package
at https://packages.debian.org/buster/handbrake then clock on your
architecture). handbrake should not allow a job with a Destination
structure without a File field.
Still it would help a lot to find with which destination folder name it
fails.
Maybe it could get sorted out by reading the source but it will take a
certain amount of time.
my encode log shows a "File" field in the "Destination" structure.
Yours not. It may be why the gdb trace shows a filename=0x0 (ie no
filename) passed to ffmpeg avio_open2.
Mine:
"Destination": {
"AlignAVStart": false,
"ChapterList": [
{
"Name": "Chapter 1"
},
{
"Name": "Chapter 2"
},
{
"Name": "Chapter 3"
}],
"ChapterMarkers": true,
"File": "/media/prahal/4061-08F6/output_file.mkv",
"InlineParameterSets": false,
"Mp4Options": {
"IpodAtom": false,
"Mp4Optimize": false
},
"Mux": "mkv"
},
Yours:
"Destination": {
"AlignAVStart": false,
"ChapterList": [
{
"Name": "Chapter 1"
},
{
"Name": "Chapter 2"
},
{
"Name": "Chapter 3"
},
{
"Name": "Chapter 4"
},
{
"Name": "Chapter 5"
},
{
"Name": "Chapter 6"
}
],
"ChapterMarkers": true,
"InlineParameterSets": false,
"Mp4Options": {
"IpodAtom": false,
"Mp4Optimize": false
},
"Mux": "mkv"
},
You gdb shows a 0x0 (null) filename passed to the ffmpeg library, which
is likely not supported by this library call, thus that points to an
handbrake bug:
#2 0x7f7cebc48102 in ffurl_alloc
(puc=0x7f7cd67fa820, filename=0x0, flags=2, int_cb=0x7f7cc19b8708)
at src/libavformat/avio.c:295
#3 0x7f7cebc48a2e in ffurl_open_whitelist
(puc=puc@entry=0x7f7cd67fa820, filename=,
flags=flags@entry=2, int_cb=, options=options@entry=0x0,
whitelist=whitelist@entry=0x0, blacklist=0x0, parent=0x0) at
src/libavformat/avio.c:314
#4 0x7f7cebc4d187 in ffio_open_whitelist
(s=0x7f7cc19b8260, filename=, flags=flags@entry=2,
int_cb=, options=options@entry=0x0,
whitelist=whitelist@entry=0x0, blacklist=0x0)
at src/libavformat/aviobuf.c:1167
#5 0x7f7cebc4d1ee in avio_open2
(s=, filename=, flags=flags@entry=2,
int_cb=, options=options@entry=0x0) at
src/libavformat/aviobuf.c:1181
#6 0x561ecd32d8fd in avformatInit (m=0x7f7cc19b7870) at
../libhb/muxavformat.c:179
#7 0x561ecd2e4112 in muxInit (muxer=0x7f7cc03ea500,
job=0x7f7cc004a340)
at ../libhb/muxcommon.c:649
#8 0x561ecd317e56 in do_job (job=0x7f7cc004a340) at
../libhb/work.c:1758
You also have in your encode.log
[19:00:07] * destination
[19:00:07]+ (null)
[19:00:07]+ container: Matroska (libavformat)
[19:00:07] + chapter markers
while here I have:
[21:46:17] * destination
[21:46:17]+ /media/prahal/4061-08F6/output_file.mkv
[21:46:17]+ container: Matroska (libavformat)
[21:46:17] + chapter markers
Note that my encode job output is via handbrake 1.2.2+ds1-1 with its
dependencies mostly downgraded to buster versions. And I cannot
reproduce with by selecting an usb drive with no label but UUID 4061-
08F6 for its partition as handbrake "destination".
Cheers,
Alban
Bug#974768: handbrake: Saving custom presets in custom category is broken
You can close this bug report as I can reproduce when I installed stretch handbrake_1.2.2+ds1-1_amd64.deb with its required dependencies from strech (libdvdread4_6.0.1-1, libx265-165_2.9-4, libx264- 155_0.155.2917+git0a84d98-2). This even with bookworm libgtk-3-0 3.24.35-2 and all other dependencies untouched. And with only change being upgrading handbrake 1.5.1+ds1-3 (bookworm and sid) and handbrake 1.3.1+ds1-2+b3 (bullseye stable) the issue is fixed. Best Regards, Alban
Bug#974768: handbrake: Saving custom presets in custom category is broken
package handbrake fixed 974768 1.3.1+ds1-2+b3 thanks On Sat, 14 Nov 2020 21:38:27 +0100 =?utf-8?q?Johan_Kr=C3=B6ckel?= wrote: > Package: handbrake > Version: 1.2.2+ds1-1 > Severity: normal > > Creating a custom preset category in the GUI is not possible. Saving a new preset with the option "new category" enabled fails silently. This issue is not reproducible here with handbrake 1.5.1+ds1-3 (bookworm and sid) and bullseye (stable) 1.3.1+ds1-2+b3. I set a preset category name by clicking on hte "presets" menu entry then its "save as" submenu entry, then in the category dropdown I select "Add New Category" and enter "test" as name in the category name input entry, then click OK and my preset is then available i the presets drowdown under the "Custom" section. Could you try anew and close the issue ? Maybe this issue was unrelated to handbrake itself as my gtk3 GUI framework is newer than stable. I have bookworm libgtk-3-0 3.24.35-2. I set the issue as fixed in (at least) 1.3.1+ds1-2+b3 but if it is not an handbrake bug per se it will require reopening and reassigning. Cheers, Alban
Bug#897975: [gdm3]
The wayland issue should be gone in bookworm/sid. As stated in https://gitlab.gnome.org/GNOME/gdm/-/issues/103, https://gitlab.gnome.org/GNOME/gdm/-/merge_requests/128 is merged (in gdm 40). It supersedes https://gitlab.gnome.org/GNOME/gdm/merge_requests/37 I cannot tell about the initial gdm3 "ICELockAuthFile fail: Already exists" Xorg related issue. It seems unrelated. Cheers, Alban
Bug#897975: [gdm3]
The wayland issue should be gone in bookworm/sid. As stated in https://gitlab.gnome.org/GNOME/gdm/-/issues/103, https://gitlab.gnome.org/GNOME/gdm/-/merge_requests/128 is merged (in gdm 40). It supersedes https://gitlab.gnome.org/GNOME/gdm/merge_requests/37 I cannot tell about the initial gdm3 "ICELockAuthFile fail: Already exists" Xorg related issue. It seems unrelated. Cheers, Alban
Bug#1019486: gdm3: Gdm3 crashes (oh no something has gone wrong)
On Sat, 10 Sep 2022 13:22:03 + Christophe TROESTLER wrote: > > My best guess is that this issue is caused by your mixing and matching pieces from Unstable and Testing. > > Aha, thanks, that was the cause. (I seldom use unstable but I wanted to know whether the latest gnome-shell stopped leaking memory.) > > The issue looks like resolved. Could you close the bug report? Best Regards, Alban
Bug#1010088: gdm3 - Login fails and returns to login or blank screen
On Sun, 24 Apr 2022 04:23:21 +0100 Philip Wyett wrote: > Package: gdm3 > Version: 42.0-1 > Severity: serious > Tags: bookworm sid > > Login fails and returns to login or a blank screen. > > Platform is VM with virtio graphics. Could you share your VM settings? sudo virsh dumpxml Kind regards, Alban > Regards > > Phil > > -- > *** Playing the game for the games own sake. *** > > Associations: > > * Debian Maintainer (DM) > * Fedora/EPEL Maintainer. > * Contributor member of the AlmaLinux foundation. > > WWW: https://kathenas.org > > Twitter: @kathenasorg > > Instagram: @kathenasorg > > IRC: kathenas > > GPG: 724AA9B52F024C8B
Bug#1001362: gnome-control-center: Please Suggest or Recommend power-profiles-daemon
package gnome-control-center fixed 1001362 1:42.0-2 thanks power-profiles-daemon was added as a recommand in https://salsa.debian.org/gnome-team/gnome-control-center/-/commit/cbcba952c8a7801da2290e90b95746082721a0da which was first shipped in Debian in 1:42.0-2. On Thu, 09 Dec 2021 09:34:39 +0100 =?utf-8?b?SsOpcsOpbXkgTGFs?= wrote: > Package: gnome-control-center > Version: 1:41.2-1 > Severity: wishlist > > Hi, > > if power-profiles-daemon is installed, gnome-control-center displays controls > for choosing power profile. > > However gnome-settings-daemon also makes use of power-profiles- daemon, > so maybe the dependency should be on it or on some other gnome package. > > > -- System Information: > Debian Release: bookworm/sid > APT prefers stable-security > APT policy: (500, 'stable-security'), (500, 'unstable'), (101, 'testing') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.15.0-2-amd64 (SMP w/4 CPU threads) > Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (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 gnome-control-center depends on: > ii accountsservice 0.6.55-3 > ii apg 2.2.3.dfsg.1-5+b2 > ii colord 1.4.5-3 > ii desktop-base 11.0.3 > ii desktop-file-utils 0.26-1 > ii gnome-control-center-data 1:41.2-1 > ii gnome-desktop3-data 41.1-1 > ii gnome-settings-daemon 41.0-2 > ii gsettings-desktop-schemas 41.0-2 > ii libaccountsservice0 0.6.55-3 > ii libatk1.0-0 2.36.0-2 > ii libc6 2.32-5 > ii libcairo2 1.16.0-5 > ii libcheese-gtk25 41.1-1 > ii libcheese8 41.1-1 > ii libcolord-gtk1 0.1.26-2+b1 > ii libcolord2 1.4.5-3 > ii libcups2 2.3.3op2-7 > ii libepoxy0 1.5.9-2 > ii libfontconfig1 2.13.1-4.2 > ii libgcr-base-3-1 3.40.0-3+b1 > ii libgdk-pixbuf-2.0-0 2.42.6+dfsg-2 > ii libglib2.0-0 2.70.2-1 > ii libgnome-bluetooth13 3.34.5-4 > ii libgnome-desktop-3-19 41.1-1 > ii libgoa-1.0-0b 3.40.1-2 > ii libgoa-backend-1.0-1 3.40.1-2 > ii libgsound0 1.0.3-2 > ii libgtk-3-0 3.24.30-4 > ii libgtop-2.0-11 2.40.0-2 > ii libgudev-1.0-0 237-2 > ii libhandy-1-0 1.5.0-1 > ii libibus-1.0-5 1.5.25-3 > ii libkrb5-3 1.18.3-7
Bug#873197: gnome-control-center: touchpad lost functionality after debian 8 -> 9 upgrade
On Fri, 25 Aug 2017 15:05:48 +0200 Rafal Pietrak wrote: > Package: gnome-control-center > Version: 1:3.22.2-3 > Severity: important > > Dear Maintainer, > > * What led up to the situation? > > upgrade from debian jessie to debian stretch > > * What exactly did you do (or not do) that was effective (or > ineffective)? > > gnome-control-center settings are ineffective > > * What was the outcome of this action? > > none control-center does not effect the scrolling-mode > > * What outcome did you expect instead? > > 1. "natural scrolling" (following the "paper", istead of "window") > 2. tap2click - no such option, and does not work by default (e.g there > is no way to switch it on) > This is a duplicate of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=821352. That is you have to check that xserver-xorg-input-synaptics is removed and xserver- xorg-input-libinput is installed. GNOME does not support xserver-xorg- input-synaptics anymore. If you still have the issue could you confirm this fixes it? Could you close this bug report if you are still on GNOME Xorg and do not experience the issue anymore? Kind regards, Alban > > -- System Information: > Debian Release: 9.1 > APT prefers stable > APT policy: (500, 'stable') > Architecture: amd64 (x86_64) > > Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) > Locale: LANG=pl_PL.utf8, LC_CTYPE=pl_PL.utf8 (charmap=UTF-8), LANGUAGE=pl_PL.utf8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages gnome-control-center depends on: > ii accountsservice 0.6.43-1 > ii apg 2.2.3.dfsg.1-4+b1 > ii colord 1.3.3-2 > ii desktop-file-utils 0.23-1 > ii gnome-control-center-data 1:3.22.2-3 > ii gnome-desktop3-data 3.22.2-1 > ii gnome-settings-daemon 3.22.2-2+deb9u2 > ii gsettings-desktop-schemas 3.22.0-1 > ii libaccountsservice0 0.6.43-1 > ii libatk1.0-0 2.22.0-1 > ii libc6 2.24-11+deb9u1 > ii libcairo-gobject2 1.14.8-1 > ii libcairo2 1.14.8-1 > ii libcanberra-gtk3-0 0.30-3 > ii libcanberra0 0.30-3 > ii libcheese-gtk25 3.22.1-1+b1 > ii libcheese8 3.22.1-1+b1 > ii libclutter-1.0-0 1.26.0+dfsg-3 > ii libclutter-gtk-1.0-0 1.8.2-2 > ii libcolord-gtk1 0.1.26-1.1 > ii libcolord2 1.3.3-2
Bug#1005264: gnome-control-center: touchpad options in gnome conrol center not work atall and not respond to chaning settings
On Thu, 10 Feb 2022 08:09:44 +0330 alireza wrote: > Package: gnome-control-center > Version: 1:41.2-1 > Severity: important > X-Debbugs-Cc: alireza...@gmail.com > > Dear Maintainer, > > *** Reporter, please consider answering these questions, where appropriate *** > > * What led up to the situation? upgrading > * What exactly did you do (or not do) that was effective (or > ineffective)? upwidgetgrading to gnome 41 > * What was the outcome of this action? disabling touchpad > settings > * What outcome did you expect instead? that settings on touchapd take effect Could it be a duplicate of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=821352, that is xorg synaptics driver is not compatibale with GNOME anymore. Could you tell if you are running a Gnome Xorg session or a Wayland one ? If Xorg a session do you have xserver-xorg-input-synaptics installed? gnome has removed support for this synaptics driver around 2016 and only supports changing settings to the xserver-xorg-input-libinput driver. Kind regards, Alban
Bug#1013171: gnome-control-center does not start on gnome Wayland
On Sat, 18 Jun 2022 11:13:43 +0200 Giacomo Mulas wrote: > Package: gnome-control-center > Version: 1:42.2-1 > Severity: important > > Dear Maintainer, > > after some recent upgrade (I cannot pin down which one exactly, I have an up > to date sid system), gnome-control-center does not display any window any > more when running in a gnome wayland session. It still does work properly > in a gnome on Xorg session. It is not the only one showing this behaviour, > the same happens (to me) with at least gnome-software, gnome- extensions-app, > extension-manager. The problem is identical even with all gnome extensions > disabled, so it does not depend on this. This was likely not a gnome-control-center issue if it also affect other gnome-software. Was this fixed by an upgrade since then? From the strace I see you have an nvidia graphic card. Could you try wayland with nouveau? The bug is probably in the nvidia code. > I attach at the end environment and strace for both gnome-control- center on > wayland (which shows no window) and on xorg (which works correctly). Please > let me know if there is some test I may run to help track this problem down. > > Thanks in advance, best regards > Giacomo Mulas > > -- System Information: > Debian Release: bookworm/sid > APT prefers unstable > APT policy: (401, 'unstable'), (10, 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 5.18.0-1-amd64 (SMP w/12 CPU threads; PREEMPT) > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE > Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 gnome-control-center depends on: > ii accountsservice 22.08.8-1 > ii apg 2.2.3.dfsg.1-5+b2 > ii colord 1.4.6-1 > ii desktop-base 11.0.3 > ii desktop-file-utils 0.26-1 > ii gnome-control-center-data 1:42.2-1 > ii gnome-desktop3-data 42.2-1 > ii gnome-settings-daemon 42.2-1 > ii gsettings-desktop-schemas 42.0-1 > ii libaccountsservice0 22.08.8-1 > ii libadwaita-1-0 1.1.2-1 > ii libc6 2.33-7 > ii libcairo2 1.16.0-5 > ii libcolord-gtk4-1 0.3.0-3 > ii libcolord2 1.4.6-1 > ii libcups2 2.4.2-1 > ii libepoxy0 1.5.10-1 > ii libfontconfig1 2.13.1-4.4 > ii libgcr-base-3-1 3.41.0-4 > ii libgdk-pixbuf-2.0-0 2.42.8+dfsg-1 > ii libglib2.0-0 2.72.2-2 > ii libgnome-bg-4-1 42.2-1 > ii libgnome-bluetooth-ui-3.0-13 42.1-1 > ii libgnome-desktop-4-1 42.2-1
