Bug#1069661: samba: apparmor integration broken since change to local systemd units in 2:4.19.4+dfsg-1
Package: samba Version: 2:4.19.5+dfsg-4 Severity: normal Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu noble ubuntu-patch Dear Maintainer, *** /tmp/tmpz7e0qwfp/bug_body In Ubuntu, the attached patch was applied to achieve the following: When samba was updated to ship local systemd service unit files in 2:4.19.4+dfsg-1 the ExecStartPre directive was not included. As such the integration with apparmor via the update-apparmor-samba-profile script was lost. The previously used patch can be dropped as the file that is patched is now not used and instead the locally maintained systemd unit is updated to include this directive instead. debian/changelog from Ubuntu as is follows: * Fix apparmor integration with smbd.service (LP: #2063079) - d/patches: remove unnecessary smbd.service-Run-update-apparmor-samba-profile-befor.patch patch since we don't use the packaging/systemd/smd.service.in template - d/samba.smbd.service: update to invoke update-apparmor-samba-profile help via ExecStartPre directly Thanks for considering the patch. -- System Information: Debian Release: trixie/sid APT prefers noble APT policy: (500, 'noble') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.8.0-28-generic (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled diff -Nru samba-4.19.5+dfsg/debian/patches/series samba-4.19.5+dfsg/debian/patches/series --- samba-4.19.5+dfsg/debian/patches/series 2024-03-05 04:34:57.0 +1030 +++ samba-4.19.5+dfsg/debian/patches/series 2024-04-22 16:08:04.0 +0930 @@ -5,7 +5,6 @@ usershare.patch heimdal-rfc3454.txt add-so-version-to-private-libraries -smbd.service-Run-update-apparmor-samba-profile-befor.patch fix-nfs-service-name-to-nfs-kernel-server.patch ctdb-config-enable-syslog-by-default.patch Force-LDB-as-standalone.patch diff -Nru samba-4.19.5+dfsg/debian/patches/smbd.service-Run-update-apparmor-samba-profile-befor.patch samba-4.19.5+dfsg/debian/patches/smbd.service-Run-update-apparmor-samba-profile-befor.patch --- samba-4.19.5+dfsg/debian/patches/smbd.service-Run-update-apparmor-samba-profile-befor.patch 2023-09-12 02:58:56.0 +0930 +++ samba-4.19.5+dfsg/debian/patches/smbd.service-Run-update-apparmor-samba-profile-befor.patch 1970-01-01 09:30:00.0 +0930 @@ -1,25 +0,0 @@ -From 0ecd28ff3fd7f3d5c20705a2b8233fc8648cbf9c Mon Sep 17 00:00:00 2001 -From: Mathieu Parent -Date: Thu, 21 Feb 2019 21:04:30 +0100 -Subject: [PATCH] smbd.service: Run update-apparmor-samba-profile before start - -Bug-Debian: https://bugs.debian.org/896080 - packaging/systemd/smb.service.in | 1 + - 1 file changed, 1 insertion(+) - -diff --git a/packaging/systemd/smb.service.in b/packaging/systemd/smb.service.in -index 18912ef0e98..6bb24861682 100644 a/packaging/systemd/smb.service.in -+++ b/packaging/systemd/smb.service.in -@@ -10,6 +10,7 @@ NotifyAccess=all - PIDFile=@PIDDIR@/smbd.pid - LimitNOFILE=16384 - EnvironmentFile=-@SYSCONFDIR@/sysconfig/samba -+ExecStartPre=/usr/share/samba/update-apparmor-samba-profile - ExecStart=@SBINDIR@/smbd --foreground --no-process-group $SMBDOPTIONS - ExecReload=/bin/kill -HUP $MAINPID - LimitCORE=infinity --- -2.20.1 - diff -Nru samba-4.19.5+dfsg/debian/samba.smbd.service samba-4.19.5+dfsg/debian/samba.smbd.service --- samba-4.19.5+dfsg/debian/samba.smbd.service 2024-01-31 03:07:18.0 +1030 +++ samba-4.19.5+dfsg/debian/samba.smbd.service 2024-04-22 16:08:18.0 +0930 @@ -9,6 +9,7 @@ PIDFile=/run/samba/smbd.pid LimitNOFILE=16384 EnvironmentFile=-/etc/default/samba +ExecStartPre=/usr/share/samba/update-apparmor-samba-profile ExecStart=/usr/sbin/smbd --foreground --no-process-group $SMBDOPTIONS ExecReload=/bin/kill -HUP $MAINPID LimitCORE=infinity
Bug#957020: Fixed already in upstream commit 017e6c6ab95df55f34e339d2139def83e5dada1f
Upstream fixed this via commit https://github.com/linux-audit/audit-userspace/commit/017e6c6ab95df55f34e339d2139def83e5dada1f however this has not yet been released in an official release.
Bug#375179: Package libxnvctrl from Fedora to build sensors-applet against
libNVCtrl is GPL2 licensed, so this could be packaged separately as done in Fedora and sensors-applet could simply depend on this rather than the proprietary nvidia-settings application: https://admin.fedoraproject.org/pkgdb/packages/name/libXNVCtrl signature.asc Description: This is a digitally signed message part
Bug#375179: Info received (Package libxnvctrl from Fedora to build sensors-applet against)
I realise it depends on it to function, but that doesn't mean it couldn't be built with support for it, so that if a user chooses to install the proprietary drivers, it will automatically support them, and without the drivers it would simply not detect them... its like having the hddtemp code in there but not actually having hddtemp installed - couldn't this be a viable option? signature.asc Description: This is a digitally signed message part
Bug#375179: Info received (Package libxnvctrl from Fedora to build sensors-applet against)
The difference is that if hddtemp is not installed, the hddtemp module simply fails to run the hddtemp program. But if libXNVCtrl is not installed, the whole program will fail to load because of the missing shared library (assuming that libXNVCtrl even is a shared library... back when it was included in nvidia-settings it was only shipped as a static library). But libNVCtrl could be packaged separately (as it is GPL2) and sensors-applet could depend on it, then sensors-applet would load fine and it could all work as I described previously. I think we decided in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=434887 that that way to fix this is to make the various sensors-applet modules into DSOs that can be dlopen'd (or glib equivalent) at runtime. However it's something that I know next to nothing about, so I haven't been able to do it yet. I will get round to it eventually though unless you do first! :) This is also an option, but it would require a large reworking of sensors-applet which at the moment I (like you) don't have time to devote to, so in the meantime this would be a good solution. signature.asc Description: This is a digitally signed message part
Bug#448029: Please package 1.8.2 instead
Hi Sam, I suggest instead packaging the newer version 1.8.2 which includes the relicensed icons rather than simply updating the existing 1.8.1 package. Thanks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#434887: Bug#431718: sensors-applet: sensors-appled nvidia support issues
Howdy all, Upstream agrees that a nice, modular plugin system would be good to allow for easier distribution. However, at this stage I have little time to work on it. If I get some time to try and work on this, I will let you all know. It probably wouldn't be too much effort, since all the sensors stuff is already separated in to individual source files, so they would probably want to utilise the GModule interface (glib's dlopen() wrapper interface)... Cheers Alex On Wed, 2007-07-04 at 16:08 +0200, Filippo Giunchedi wrote: On Wed, Jul 04, 2007 at 02:25:24PM +0100, Sam Morris wrote: Ugh, ctrl+enter is a STUPID choice for a shortcut to send an email you're composing... indeed, change your MUA to something saner g 1) I understand you motivation not to include nvidia support per default to avoid moving the package to contrib. But as there are so many users with nvidia GPUs out there it would perhaps be a nice solution, to provide a 2nd package e.g. sensors-applet-with-nv or something better ;) in contrib. That way each user could choose the one he likes. I've thought about it, but I believe Debian's policy would require that it be an entirely separate source package... which is double the maintenence burden, and I don't know if the ftpmasters would even accept two almost-identical source packages. Given that NVIDIA's own code can't even read the sensors on my graphics card, and that NVIDIA hardware is non-free crap in the first place, my motivation to work on this issue myself is pretty much zero. However if you (or anyone else) would like to maintain a branch of the package I will help you. :) [upstream CCed] I do not know s-a architecture but here's a thought: give a simple interface for external .so to dlopen() at runtime, then the nvidia component can be made an .so and put in contrib in a small source package. OT: Sam: there's no upstream author contact in copyright, do you mind adding? filippo -- Filippo Giunchedi - http://esaurito.net PGP key: 0x6B79D401 random quote follows: What a strange illusion it is to suppose that beauty is goodness. -- Lev Tolstoj signature.asc Description: This is a digitally signed message part
Bug#397313: sensors-applet: Applet does not allow to watch sensors from second chi
Could you please provide some more information - which sensors are detected and which are not? To Sam: I am not completely familiar with the libsensors stuff, and since you wrote the patch for libsensors I thought you may have a better idea of how to tackle this one. Any advice you could give would be great. signature.asc Description: This is a digitally signed message part
Bug#393937: Should be fixed in latest version
Ok, I think I have found the cause of this bug, and it should be fixed in the latest version (1.7.10). Please upgrade and see how you go. signature.asc Description: This is a digitally signed message part
Bug#393937: sensor height not saved on vertical panel
I can't reproduce it. Make sure you close the preferences window before logging out otherwise the settings won't be saved. Can you reproduce it Sam? On Wed, 2006-10-18 at 18:34 +0100, Sam Morris wrote: On Wed, 2006-10-18 at 15:30 +, Joachim Breitner wrote: Package: sensors-applet Version: 1.7.8+dfsg-1 Severity: normal Hi, I have two sensors on a vertical panel. I can set the height to 35 pixels in the settins all right, and it looks good. But when I log in the next time, it is re-set to 42 pixels. Maybe some automatic stuff going on? Perhaps the graph height setting is being reset when the applet launches up instead of being restored from gconf. Any idea, Alex? Greetings, Joachim signature.asc Description: This is a digitally signed message part
Bug#379668: Font size can be changed
The option to change the font size is available in sensors applet 1.7.5, but it is set using a GConf key. This is explained in the help manual under Advanced Options. This bug should be closed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379668: New version lost some nice features
The latest version of sensors-applet (1.7.5) will automatically calculate the layout of sensors based upon the size of your panel. If you want sensors on two lines you will need to ensure the panel is big enough to fit them in, and sensors-applet will automatically lay them out this way. I think Sam will be adding the newest version to Debian testing soon. signature.asc Description: This is a digitally signed message part
Bug#353899: sensors-applet: Won't display i2c-sys sensors info since upgrade to 2.6.15
Hi Sam and Olivier It looks like the newer kernel version places the device files in a different subdirectory and so the previously saved configuration is now invalid. All that needs to be done is to remove the current instance of Sensors Applet from the panel and then readd it so it can redetect the new location of the sensor device files. Cheers Alex On Wed, 2006-02-22 at 16:25 +, Sam Morris wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Olivier Berger wrote: After having upgraded to 2.6.15 in testing recently, I can no longer monitor i2c-sys kind of sensors. sensors gives the following : # sensors it87-isa-0290 Adapter: ISA adapter VCore 1: +1.58 V (min = +1.42 V, max = +1.60 V) VDDQ: +3.36 V (min = +3.14 V, max = +3.47 V) +3.3V: +3.36 V (min = +3.14 V, max = +3.47 V) +5V: +5.16 V (min = +4.76 V, max = +5.24 V) +12V: +11.65 V (min = +11.39 V, max = +12.61 V) -12V: -12.25 V (min = -12.58 V, max = -11.43 V) -5V: -4.94 V (min = -5.29 V, max = -4.77 V) Stdby: +5.11 V (min = +4.76 V, max = +5.24 V) VBat: +3.33 V fan1: 1739 RPM (min =0 RPM, div = 8) M/B Temp:+43 C (low = +15 C, high = +48 C) sensor = thermistor CPU Temp:+46 C (low = +15 C, high = +56 C) sensor = thermistor Temp3: +39 C (low = +15 C, high = +48 C) sensor = thermistor But if I activate fan1 for display in sensors-applet, it displays : Error opening sensor device file /sys/devices/platform/i2c-1/1-0290/fan1 input All the files I can see though are : # ls -R /sys/devices/platform/i2c-9191/ /sys/devices/platform/i2c-9191/: 9191-0290 i2c-adapter:i2c-9191 name power uevent /sys/devices/platform/i2c-9191/9191-0290: alarms fan2_divhwmon:hwmon0 in1_minin3_minin5_min in7_min pwm2 temp1_mintemp3_input bus fan2_input in0_input in2_input in4_input in6_input in8_inputpwm2_enable temp1_type temp3_max driver fan2_minin0_max in2_maxin4_maxin6_maxname pwm3 temp2_input temp3_min fan1_divfan3_divin0_min in2_minin4_minin6_min powerpwm3_enable temp2_maxtemp3_type fan1_input fan3_input in1_input in3_input in5_input in7_input pwm1 temp1_input temp2_minuevent fan1_minfan3_minin1_max in3_maxin5_maxin7_max pwm1_enable temp1_maxtemp2_type /sys/devices/platform/i2c-9191/9191-0290/power: state wakeup /sys/devices/platform/i2c-9191/power: state wakeup Hope this helps. Best regards, Hm, I have almost exactly the same layout as you and haven't come across this problem. Olivier, could you please try the package of 1.6 I have put at http://robots.org.uk/debian/sensors-applet_1.6-1_i386.deb? (It has not yet been uploaded to Debian due to copyright issues). 7e1aeb92b737c57d95e858ab5228febb sensors-applet_1.6-1_i386.deb Alex, could you glance at this and let me know if anything comes to mind? Regards, - -- Sam Morris http://robots.org.uk/ PGP key id 5EA01078 3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD/JCGshl/216gEHgRAhY9AJ94i3PlzLSEPRyH8VYGpQunrdf3xwCfVWkW m/t4rQG5bGfGzezc8cxWp6E= =VNrB -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
